We're Hiring!  
Toll Free US & Canada: 1(877) 946-4743   Worldwide: +1(415) 869-7444

How to Configure Static Routes to Traverse Traffic on CloudLink

Written by on Feb 1st, 2012 | Filed under: Cloud Computing, Cloudcenter, Datacenter, Features, General, GoGrid, Hosting, Public Cloud
440 views

CloudLink is infrastructure so it can enable many use cases. However, you will be unable to use it until you configure your servers to use static routes. The rest of this post will describe how to create a static route from one server in US-West-1 to servers in US-East-1. This assumes that you have not already assigned a private IP to the West server. This guide assumes that you have a basic knowledge of Linux and/or Windows and with the basic principles of networking.

Find your Private IPs

wpid3499-media_1316553859879.png
First, you will need to find your private IPs. You can find your private IP block by going to the GoGrid portal, selecting the List tab and then Network. Under Type: Private you will see your private IP blocks. In this example, this is a listing of private IP blocks for US-West-1. US-East-1 has a DIFFERENT private IP block. The gateway is +1 from the first number in your private IP block (10.109.32.1) in the example above.

If you want to assign a private IP to a server in US-West-1, you would select it from the list in the screenshot – just pick one that you have not already assigned somewhere else. Take note of the subnet as you will need it later.

Assign a Private Static IP on Ubuntu / Debian

wpid3501-media_1316554724715.png

To assign a private IP, you can update the interface directly. Enter the following at the prompt or use your favorite Linux editor.

nano /etc/network/interfaces

Within the file enter the following (the IP is just an example, use one of your own. Don’t enter the text in the brackets):

auto eth1
iface eth1 inet static
address 10.100.10.3 [a private IP address in the West ]
netmask 255.255.255.0

Save the file.

This step assigns a private IP from your West block to a single Ubuntu / Debian server. You will need to activate the new IP so restart your network interface.

ifdown eth1

and then enter:

ifup eth1

Assign a Private IP to a Windows Server

wpid3503-media_1318009486218.png

For Windows users, you will need to do the following.

  1. Click on Start > Control Panel > Network Connections.
  2. Select Local Area Connection 2.
  3. Click Properties.
  4. Double-click TCP/IP in the scroll box.
  5. Enable the radio button titled Use the Following IP Address.
  6. Assign a PrivateIP address to this machine
    1.     You can find your private IP block by going to the GoGrid portal, selecting the List tab and then Network.
    2.     Under Type: Private you will see your private IP blocks. If this Windows Server is in the West, make sure to use IPs that have US-West-1 in the Datacenter column.
    3.     Select an available private IP address and note the Subnet Mask
  7. Enter the subnet mask as found on your list of private IP blocks.
  8. Leave the gateway blank.
  9. You can enter GoGrid’s name servers under DNS if you are so inclined.
  10. Continue to click OK to exit each subsequent window.
  11. To confirm changes were successful, open a command prompt window and type 
    ipconfig /all
  12. Those steps will assign a private IP address to a particular machine. Make sure to enable “Local Area Connection 2”.

Create a static route on your Linux server

Once you have assigned a private IP to your server, you will then need to create a static route to your East private IP block. The IPs below are examples only, use your own IPs when you enter the command! This command will work on Ubuntu, Debian, Red Hat, and CentOS.

At the command line type:

route add -net 10.200.10.0 netmask 255.255.255.0 gw 10.100.10.1

This adds a route from your US-West-1 server to your US-East-1 private IP block (the 10.200.10.0 netmask… of the code) via the US-West-1 private gateway (10.100.10.1).

Persisting the static route on Linux

The command entered in the previous step will only keep the route while your session is active. In order to have the route stay through reboots, you will need to update configuration files on your server. Please see the wiki for instructions on how to set persistence and for configuring CentOS or Red Hat Enterprise Linux (RHEL).

Create a static route on your Windows server

wpid3505-media_1318528285041.png

Windows

  1. Open a command prompt by clicking on Start > Run
  2. Type “cmd” and click OK.
  3. Enter the command 
    route add -p 10.200.10.0 [East private IP block] mask 255.255.255.0 [West Gateway IP]
    1. where [West Gateway IP] is +1from your first IP address in your Private Network block available in the GoGrid user interface. If your Windows Server is in the WEST then you will want to use the Gateway IP for the US-West-1 private network. So in the screenshot above, 10.109.32.1 is the gateway NOT 10.109.32.0. You will want to connect to the East private IP block, so the number after p is the first available number in your East Private IP block.
    2. For example, you would enter something like: 
      route add -p 10.200.10.0 mask 255.255.255.0 10.109.32.1

      The p flag ensures that the route is persistent across reboots.

Testing the connection

If you want to test ping, you will need to assign a private IP to the server that you want to ping and also define a static route back to the IP blocks in the other datacenter. In this example, since you have setup a Windows machine with a route from West to East, you will need to setup a static route on an East server that you want to ping back to the West.

For example, you can execute the route command if you don’t want to persist the route for Windows:

route add 10.109.32.0 netmask 255.255.255.0 10.200.10.1

And for Linux machines:

route add -net 10.109.32.0 netmask 255.255.255.0 gw 10.200.10.1

This command sets a static route to your West private IP block through your East gateway.

ping 10.200.10.5

If you can successfully ping that configured US-East-1 private IP from your Windows server in US-West-1 then this has been configured correctly.

You’re done!

media_1327956022202.png
That’s all you need to do to start using CloudLink. You will need to set static routes for any server that is going to use this product. CloudLink is just the first step is GoGrid’s plan to continually innovate and expand our offerings to our customers. As GoGrid expands globally, so will all our products including CloudLink. As you grow your company internationally, GoGrid will be ready to grow with you!


No Comments Enjoyed this post? Subscribe via RSS. Thanks for visiting!

How To Build a Virtual Private Cloud on GoGrid

Written by on Dec 14th, 2011 | Filed under: Cloud Computing, Features, General, GoGrid, How To, Private Cloud, Public Cloud
1,225 views

At GoGrid, we are often asked to provide solutions for a variety of use cases. More often than not, businesses are not looking for “standard” cloud implementations. And what really is “standard?” When you think about it, every business has unique needs in order to satisfy their cloud challenges. We help companies craft these solutions daily and we call it Creating a Cloud Fingerprint. But, as is the nature of cloud computing, many users desire to figure it out themselves, simply because solutions can be architected fairly easily, and if it isn’t quite right, they can be modified.

In our regular discussions with companies looking for information on how they can benefit from cloud Infrastructure as a Service, we often come across the same set of hurdles, namely:

  • Most established companies have an existing infrastructure investment, and may not be willing or able to sacrifice these investments,
  • Some infrastructure components may not be generally available through IaaS vendors, such as Enterprise security or storage infrastructure,
  • Some applications or data will be deemed “too sensitive” for the cloud due to internal objections or compliance constraints,
  • Maintaining and growing an on-premise solution or even data center is not only difficult, but extremely expensive,
  • Doing a full migration to the cloud comes with a very high conversion and operational cost,
  • Business simply are unsure as to how to best leverage cloud computing.

With these challenges in mind, we have a solution that allows business not only to utilize their existing infrastructure, but also leverage GoGrid’s public cloud to create a Virtual Private Cloud on GoGrid.

But, addressing the points above is critical in the solution. Therefore, we wanted to be sure:

  • Customers could retain their existing infrastructure,
  • GoGrid’s platform is used as an EXTENSION of that infrastructure,
  • GoGrid’s customers have a wide range of network security options/policies available,
  • Customers are able to fully leverage the advantages of cloud infrastructure, and the elimination of capital expenditures and their associated resource costs,
  • A customer can fully utilize their existing infrastructure investment.

The GoGrid Solution

The solution is actually quite straight forward. And it aids customers in potentially moving on-premise infrastructure to the cloud in the future at a gradual pace. As we all know, a picture is worth 1000 words:

GoGrid-virtual-private-cloud-2

Each GoGrid account includes dedicated Layer-2 Public and Private VLANs —  this means that GoGrid completely and securely segregates each customer’s data in motion from every other GoGrid customer’s. It also means that all virtual and physical servers can speak directly to each other over high-throughput, low-latency gigabit networks.

Capitalizing on this built-in security and performance, GoGrid can add a full-featured network firewall, completely controlling network traffic per customers’ specifications.

In the Virtual Private Cloud (VPC) configuration, all traffic is denied to and from the Internet, but all traffic is allowed over the secure, encrypted point-to-point link between the customer’s cloud infrastructure at GoGrid, and their on-premise or hosted infrastructure. Of course, this policy set can be modified to add more or less restrictive policies, for example to allow database or remote management traffic only over the VPN, but allow secure web services (HTTPS) over the Internet or an IP range.

What is depicted above is the linking of two distinct infrastructures, one within GoGrid and one as a customer’s on-premise environment. The linkage is done simply by using a VPN/Firewall solution, which creates and encrypted tunnel between the two locations: GoGrid cloud and customer’s location. This is a dramatically over-simplified representation, so let’s take a look at one possible solution in a bit more detail.

GoGrid-virtual-private-cloud-details

The solution above requires the following items:

Within GoGrid

  • A GoGrid Account
  • A Managed Hardware Firewall
    • Cisco ASA-Series Firewall (Single Tenant)
    • Fortinet Firewall (Multi-Tenant)

Within Customer’s On-Premise Infrastructure

  • A VPN termination appliance at the customer’s location, such as a Cisco, Juniper or Netscreen device

In order to set up this configuration or other versions of GoGrid’s Virtual Private Cloud solution, we recommend that you have a discussion with a Cloud Specialist or Solutions Architect, as it is important to not only properly configure the environment, but also, you will need to order some managed firewall solutions.

Pricing starts around $200/month for a Virtual Private Cloud implemented with the Fortinet Firewall, and $350/month for a managed Cisco ASA 5510 dedicated to a single customer account. These charges are in addition to associated GoGrid infrastructure and bandwidth costs.

Who Might Benefit from a Virtual Private Cloud?

The nice thing about cloud computing is that it can be a solution for just about any use case. Having flexibility to construct solutions using a variety of cloud services allows customers to truly craft their Cloud Fingerprint. In the case of Virtual Private Clouds, we see them as being beneficial for Internal Applications where security of data is paramount. Core private data is maintained within a customer’s location, however, if transmitted to the cloud, it is done via a securely, encrypted tunnel. Some environments that may require this include:

  • Microsoft Exchange
  • Microsoft SharePoint
  • Billing & Financial Systems

Similarly, Virtual Private Clouds can be used for Intranet solutions as well as SaaS applications. Lastly, having a pre-constructed Virtual Private Cloud allows you the flexibility to Cloud Burst should your internal environment suddenly need to leverage more capacity or compute power from GoGrid’s public cloud.

And, as your company’s business and infrastructure grows, you may want to consider a migration to GoGrid’s Hosted Private Cloud which offers the benefits, capabilities and flexibilities of GoGrid’s public cloud, but within a single-tenant environment, one that is dedicated to your company solely.

Regardless, the important point here is to carefully plan for your future infrastructure growth. Don’t do it alone either. Ask your peers as well as your cloud partner to provide you with best practice solutions to make you successful and timely in your efforts.


No Comments Enjoyed this post? Subscribe via RSS. Thanks for visiting!

How To Set Up Private IP Segregation with CloudPassage in the GoGrid Cloud

Written by on Sep 29th, 2011 | Filed under: Cloud Computing, Cloud Server, General, GoGrid, GoGrid Exchange, How To, Images, Partners
1,867 views

CloudPassage is a key security partner that has images available on the GoGrid Partner Exchange. The CloudPassage images on GoGrid come pre-installed with their Halo daemon. This is available on CentOS, Debian, Red Hat, and Ubuntu on both 32-bit and 64-bit flavors. Alternately, you can launch a GoGrid base image and install the Halo daemon on your own. This tutorial assumes that you have a basic understanding of Linux and SSH as well as basic firewall strategies. It also assumes that you know how to configure private IPs so that will not be covered here.

Launch a server with the CloudPassage Halo daemon

wpid3389-media_1316643201731.png

In your account, add a cloud server. You will be presented with a screen where you can select all the images available to customers on GoGrid. If you enter “Halo” in the name field, it will filter for only the CloudPassage partner images. For this tutorial, I will be using the Ubuntu x64 version on US-West-1.

Register for CloudPassage

wpid3391-media_1316643490064.png

While your server is spinning up, go ahead and go to this link and register for CloudPassage (if you haven’t already). One of the advantages of CloudPassage is that you can centrally manage your security from a single web site.

Retrieving your CloudPassage API key

wpid3393-media_1316644604455.png

Once you have registered, you will want to pull your CloudPassage API key. Navigate to “Settings > Site Administration > API Keys” to retrieve your CloudPassage API key. Check your email spam folder if you haven’t received an email from CloudPassage. To have future emails from CloudPassage delivered to your Inbox, add cloudpassage.com to your safe senders list.

Upgrade your existing daemon

Log back into the Ubuntu server that you just provisioned. It’s a good practice to change the pre-assigned password so do that first. Next, you will want to upgrade the existing Halo daemon to make sure that you are using the latest version.

Run at the prompt:

apt-get update && apt-get install cphalo

Start the daemon with your API key

wpid3395-media_1316645014628.png

At the prompt enter:

/etc/init.d/cphalod start --api-key= <your CloudPassage API Key here>

to start the CloudPassage Halo daemon on your cloud server.
This will start the daemon and link the server to your account on Cloud Passage. If you go to Servers > Server Access you will see your server listed.

Create a new Firewall Policy

wpid3397-media_1316645198365.png

Next, go to Policies > Firewall Policies. Click on the button “Add New Firewall Policy”.
You will then be presented with a page where you can set the inbound and outbound rules.

I am going to create a rule on the private network (eth1) that allows only one private IP address to access this server. For the first inbound rule, select “eth1″ from the Interface drop-down.

Determine which IP can access your server

wpid3399-media_1316645536132.png

CloudPassage has the concept of IP Zones which is a grouping of IP addresses. At the Source drop-down, select “Add New” to create a new IP Zone. I have created a new Zone called “Access OK” and assigned it only one IP address. You can also assign a block of IPs or separate IP addresses. Click the Create button which will set the IP Zone as the default selection for the Source drop-down. Leave Service as “any, ” Conn. State as “Any”. Action as “ACCEPT”.

Set the default-deny rule

wpid3401-media_1316645951502.png

For this tutorial, I am just setting up access for one private IP into this server and blocking every other IP. This will only work if you configure a static private IP for the server you want to give access to. Alternately, you can select a predefined Server Group in the Source drop-down but servers will only appear there if you install the Halo daemon. Since our images are set to use DHCP for private IP assignment, you will still need to set a static private IP for this to work.

A best practice is set the last rule as a default-deny. This will prevent any other connections from accessing the server. Note that this configuration is only to control private IPs – this policy has no rules for public traffic. Realistically, you will want to control this as well in order to prevent external access to your servers. However, this tutorial is focused on demonstrating that private IPs can also be controlled centrally.

Click on the “Add” link as shown on the screen shot. This creates a default-deny rule. Make sure to select “eth1″ for the Interface drop-down or else you will lock out your public access as well.

Click Apply once you have made that change.

Assign the Policy to your server

wpid3403-media_1316646874105.png

First, go to Servers > Firewall Management. Your server will most likely not be assigned to any server group so it will be in the (1) Unassigned Group. Since the Firewall Policy is assigned at a group level, create a new group for this server by (2) clicking on the Link “Add a New Group”.

Select the Firewall Policy for the Group

wpid3405-media_1316647288936.png

After clicking on “Add a New Group” you will see a form where you can select the Policy that you just created and name the new group. Note that this policy is set GROUP wide so you can assign any new servers to this group and it will then have that Firewall policy applied. I have named this group “Private Network” and selected the Firewall Policy that I just created “Private Network Access”. Click “Save” when you are done with this form.

Move your server from Unassigned to the new group

wpid3407-media_1316647493896.png

Now that you have create a new Server Group, you will want to move your server to that group. (1)Click on the check box on the right of the server and on the (2) Actions drop-down select “Move Server(s). You will then be presented with a form – simply select the new group that you created (called Private Network in this tutorial) and then click the “Move Servers” button.

You’re done!

This configuration will then allow for you to assign certain private IPs to have access to your server while blocking others. This will help a few use cases:

1. You have a group of users who each have 3 servers and want only the three that they own to access each other via the private network. You can configure cloud passage to allow access to those 3 servers and block the other users servers. This will provide private network isolation that can be centrally managed via the CloudPassage Portal.
2. You have a group of web servers but you only want one to access your back-end servers via the private network.

Using CloudPassage is a great way to centrally manage security on any numbers of servers that you might have running on the GoGrid cloud. While, this tutorial has focused on the private network, CloudPassage is also excellent at manage firewalls for public access as well. Install their image and start using it to protect your servers today!


2 Comments Enjoyed this post? Subscribe via RSS. Thanks for visiting!

How to Set Up a Gluster File System within the GoGrid Cloud (Part 1)

Written by on Aug 19th, 2011 | Filed under: Cloud Server, General, GoGrid, GoGrid Exchange, How To, Images, Partners, Storage
2,254 views

In this blog post series, I want to take a closer look at a storage technology called Gluster File System, and how it can be set up (this article), connected to (article #2) and expand storage (article #3). This is the first blog post of the series and I will review what GlusterFS is, why you would consider using it, and how to deploy it using the GoGrid GlusterFS Partner GSI.

image

GoGrid offers a great storage solution called Cloud Storage. But what if you want to deploy your own storage so that you can directly control performance and redundancy? What software would you use to provide this? The simple answer is Gluster. It is a powerful software-based storage solution that offers a centralized controlled storage pool management system that is very easy to use.

There are many different ways to take advantage of the GlusterFS storage solution. (Note: in the descriptions below a “brick” is a GoGrid Virtual Server.)

1. Distributed Volumes:

“Distributed volumes distribute files throughout the bricks in the volume. You can use distributed volumes where the requirement is to scale storage and the redundancy is either not important or is provided by other hardware/software layers.” – Gluster.org

2. Replicated Volumes:

“Replicated volumes replicate files throughout the bricks in the volume. You can use replicated volumes in environments where high-availability and high-reliability are critical.” – Gluster.org

3. Striped Volumes:

“Stripes data across bricks in the volume. For best results, you should use striped volumes only in high concurrency environments accessing very large files.”

These storage volume options seem very familiar, don’t they? Well, if you are familiar with the different RAID configurations of hard drives in server deployments, you will notice similarities with these options. For example, the “Distributed Volume” for Gluster is essentially a RAID 0. You sacrifice redundancy to gain superior performance and ease of capacity scaling.

The Replicated Volume is similar to a RAID 10 or RAID 1 where data integrity, redundancy and reliability are very important. However, the cost to scale is more since you need to basically add GoGrid Virtual Servers (bricks) in pairs to maintain the Replicated Volume structure.

The Striped Volume is similar to RAID 5 where data is striped across the GoGrid Virtual Servers (bricks). This comes in very handy when you are dealing with very large files (multiple GB files) and when the file is accessed multiple servers will stream the data to the web-server needing the file – offering very fast reads.

For my blog post, I am going to configure a 4 server Distributed Volume Gluster setup using the GoGrid Gluster Partner Image. I am going to deploy 4 x 8GB Gluster servers. Each Gluster server will have 384GB of storage available. In the Distributed Volume setup (similar to RAID 10), I will have 384GB x2 worth of space equaling approximately 768GB of usable space.

First step is to deploy the 4 new GoGrid Gluster Virtual Servers using the GoGrid Partner GSI. I log into my portal and then follow the next steps:

1. Click “Add”

Add_Button

2. Choose “Cloud Server”

Add_Cloud Server

3. Filter for “Gluster” & choose that image

Select_Gluster_Image

4. Accept the Terms

Partner_Image_Agreement

5. Fill in the server information (name, public IP, description, memory allotment)

Gluster_Server_Information_Save

6. Repeat this process 3 more time but using different server name and public IP address.

Once you have all 4 of your new Gluster servers deployed, you can then view the Support → Passwords page in your portal to find the login information. With this login information, you can run this command from your local Linux workstation to change the hostname, set the private IP address and reboot each system. Run the following Bash script from your Linux workstation. The script will prompt you for the server address and root login, and also ask for the hostname and private IP address/netmask you want to use. If you don’t want to use this script, simply log into each system manually, update the host names and private IP addresses, and then reboot.

https://github.com/sepulworld/Remote_Linux_System_Update/blob/master/system_update.sh

I should now be able to log into all 4 systems and see the appropriate hostnames and IPs on each.

Gluster_4_systems

This looks good – if you don’t see the right hostnames or IPs on one or more of the systems, double check what is configured in the /etc/sysconfig/network file and in the /etc/sysconfig/network-scripts/ifcfg-eth1 file. Also, confirm if your host performed the intended reboot (this is necessary for the host name to update at the command line).

From one of your Gluster servers, confirm private network connectivity by pinging each of the other Gluster servers via their private IP addresses. See image below.

Ping_Gluster_Systems

Once this has been confirmed, we can take a look and see if the Gluster process is already running. It is configured on this GoGrid Partner Image to start on boot.

Gluster_Process_Login

Now I need to configure the trusted server storage pool. Basically, I log into just one of my 4 Gluster servers (I choose Gluster_1) and I run a single command to put each of the other 3 members into the trusted server storage pool.

[root@Gluster_1 ~]# gluster peer probe 10.129.151.107

See image here -

Gluster_Peer_probe

Next, I run the command to create the distributed volume using my 4 Gluster servers.

command: gluster volume create DataStore1 replica 4 transport tcp 10.129.151.105:/store1 10.129.151.98:/store2 10.129.151.108:/store3 10.129.151.107:/store4

You can name the directories anything you want. I used “store1” thru “store4”. You can also name the volume whatever you would like. I choose DataStore1.

Gluster_Volume_creation

Now let’s start the Volume with one simple command: gluster volume start DataStore1

Start_Gluster_Volume

And finally let’s view the volume information: gluster volume info DataStore1

Show_Volume_Info

Helpful link:

http://gluster.com/community/documentation/index.php/Main_Page

If you run into any issues or have questions about the Gluster Partner GSI, please email gogrid-beta@gluster.com

That is it! You have successfully deployed the GoGrid Gluster servers from the GoGrid Partner GSI and configured 4 of them in a new replicated storage volume. My next blog post will cover deploying a web-server and connecting to this new storage volume. The third and final post will cover how to scale your replicated storage volume on GoGrid.

I hope you found this tutorial helpful. Stay tuned for Parts 2 and 3. Please let me know if you have any questions.


No Comments Enjoyed this post? Subscribe via RSS. Thanks for visiting!

How to Monitor Your Windows 2008 Server on GoGrid with Cacti 0.8.7g

Written by on Jun 14th, 2011 | Filed under: Cloud Computing, Cloud Server, FAQs, General, GoGrid, How To, Images, Open Source, Public Cloud, Windows
4,322 views

This is the 3rd and final post in my setup and use of the GoGrid Community GSI server for Cacti Monitoring. In my first post, “Set Up A Cacti Monitoring Server in Minutes with this GoGrid Community Server Image,,” I covered how to deploy Cacti in your GoGrid environment using a Community GSI. My second post, “How to Monitor Your Ubuntu Server on GoGrid in 6 Steps Using Cacti 0.8.7g,” I discussed how to initiate monitoring of your GoGrid Ubuntu server. Now to round things off, I want to show you how to link up your Cacti monitoring server to a Windows Server 2008 server on your GoGrid network. The base install of Cacti 0.8.7g will allow you to monitor the server’s bandwidth utilization, Ethernet errors, number of logged in users, and total number of processes. There are other templates available to monitor other components and services on your Windows server, but they require using an additional SNMP service beyond the Microsoft SNMP service. My blog post won’t get into the latter, but I will cover the former.

Objectives:

  1. Configure GoGrid private network connectivity on Windows 2008 Server and test connectivity to Cacti server
  2. Configure and start Microsoft SNMP service on your Windows 2008 Server
  3. Add new Cacti device
  4. Create graphs to log Local Connection and Local Connection 2 bandwidth and errors, Logged in Users, and server processes

Configure GoGrid private network connectivity on Windows 2008 Server and test connectivity to Cacti server

Below we see that we have a server (“Web2”) deployed on GoGrid with a public IP. Let’s log into this server and configure the private network with a private IP from the same subnet of the Cacti Monitor server. As I described in my previous post – I am using the prescribed private IP subnet from my GoGrid portal, contained under the List tab and then under Network – Private Network.

Selection_101

Once logged into the Windows 2008 server (“Web2”), I go to the Network and Sharing Center which is found by first going to the Start button. From here I need to open up Local Area Connection 2. This is the private network interface that plugs into your own private VLAN on GoGrid. I enter the “Properties” button and then open up “Internet Protocol Version 4 (TCP/IPv4)”. By default GoGrid will enable DHCP for this private network interface. If you have a DHCP server, your server can receive private IP addresses upon initial boot up. Perhaps I will cover this in a different post. For now, we need to configure the interface with a static IP available from our example private subnet 10.129.151.0/24. The subnet will be randomly generated for each customer account. I show you how to find this in my previous post, “How to Monitor Your Ubuntu Server on GoGrid in 6 Steps Using Cacti 0.8.7g.” Following the nomenclature – keeping the last octet of the 32bit address space the same as the public to make IP address association easier – I give this system the private IP address 10.129.151.110. The .110 matches up with the last 3 digits of the public IP address 173.204.58.110. This isn’t necessary, but helps you identify systems and know their private IP address based upon their public address and vice versa. See the image below of me assigning the private IP address.

Private_Network_Config_WindowsServer

Now, open up a command prompt >Go to Start, then Run – type in cmd and hit “enter”. I now test connectivity to the 10.129.151.0/24 network by pinging the gateway IP – 10.129.151.1. I get a response, so I can move on. If you don’t get a response, double check the private IP address you used and make sure the Subnet mask is correct. You can also test connectivity by pinging the private IP address of your Cacti Monitoring server. Remember, your 10.x.x.x/24 network will be different than my example subnet. Please check your portal for what you should be using.

Private_Network_Config_WindowsServer_verification

Configure and start Microsoft SNMP service on your Windows 2008 Server

Check to see if you have the SNMP Service running already on your Windows system. By default, this server role in Windows Server 2008 on GoGrid isn’t installed and running. Go to Start -> Administrative Tools -> Services. SNMP Trap may be there, but we also need SNMP Service. To install SNMP Service go to Start -> Administrative Tools -> Server Manager -> Select Features -> Add Features. From here find and check SNMP Services (which covers SNMP Service and SNMP WMI Provider). See image below.

enable_snmp1

Click Next and this will begin the install process of this feature on Windows.

enable_snmp2

Once the SNMP Service is installed, we can go to the Services page to find and configure the SNMP Service with the appropriate community and host IP address to accept SNMP calls from.

First go to the Services page – Start -> Administrative Tools -> Services or from Run type services.msc

Find the local service – SNMP Service and right click it and go to properties. From here you need to give the service the community string that you will set on the Cacti server and the private IP address of your Cacti Monitor server. This is under Accepted Community Names and Accept SNMP packets from these hosts. See image below:

SNMP_Conf_Windows

Add new Cacti device

This step is same “create a device” step that I outlined in my previous post – except the details of the host will be different.

Create_Device1

The IP, hostname and template used in the screen shot below represent my example Windows 2008 server named “Web2.” I chose the Host Template Windows 2000/XP Host –> selected SNMP v2 -> put in the community string I chose, and clicked “create.”

New_Device_Web2_Windows_Server

You should see the SNMP information for the host quickly appears near the upper left portion of the screen. If you see an error here, you will need to check your private network connectivity between the two servers and check the SNMP Service configuration on the Windows 2008 server.

With the new device in place on Cacti, we can now create the graphs.

Create graphs to log Local Connection and Local Connection 2 bandwidth and errors, Logged in Users, and server processes

From the device we just created, go to Create Graphs for this Host.

Create_Graphs1

From this page we want to add a check to the following graph templates seen below in the image:

  1. Logged in Users
  2. Processes
  3. Local Connection
  4. Local Connection 2

Once you have done this, click Create at the bottom of the page.

Create_Graphs2

We will do this again for the In/Out Errors/Discarded Packets option next.

  1. Change the “Select a graph type:” near the bottom of the Create Graph page to In/Out Errors/Discarded Packets
  2. Next check box the “Local Area Connection” and “Local Area Connection 2”
  3. Finally click the Create button at the bottom.

Create_Graphs3

After about 5 minutes, the graph icons will be available and your data will then begin to accumulate for your viewing.

network_graph

Processes_graph

Logged_in_User

I hope this blog series was helpful for you. The GoGrid Cacti Monitor – Community GSI is a great server-based application that can easily be deployed to a GoGrid virtual server, and configured to communicate via SNMP with your servers on the GoGrid network. The information gathered will give you real-time and historical interface bandwidth, server performance, and other important system level information.

Be sure to check out other Community or Partner Server Images available on GoGrid. The GoGrid Exchange has many pre-configured software solutions that can be deployed to your GoGrid architecture in a matter of minutes.


No Comments Enjoyed this post? Subscribe via RSS. Thanks for visiting!