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

Archive for June, 2011

Today, June 8th, is World IPv6 Day. What does that mean exactly? Well, the internet is running out of IPv4 addresses and today, some companies around the world are testing out their sites using IPv6, a networking protocol that aims to replace IPv4 in the coming years. So, today is the day to raise awareness of IPv6. It’s NOT a transition day – the transition will take years to accomplish – it IS a time to evaluate your IPv6-readiness on your sites, applications, hardware, software or anything that uses IP addressing protocols.

HappyIPv6day_sm

IPv4 Networking Protocol

IPv4 is a networking address space that most of us should be familiar with. It is a numeric, 32-bit only, and takes the form of XXX.XXX.XXX.XXX (so like 192.168.100.000). There is a physical limitation to the number of IPv4 addresses you can have, 2^32 or 4,294,967,296 to be exact, and we are running out pretty quickly. Every website has an IP address bound to it. We, as consumers, are used to typing in domain names (like www.GoGrid.com). But what happens is that the domain name is translated into an IPv4 address (like 216.93.160.144). Think of IP addresses like an “internet phone number”. Nowadays, we click on a name (e.g., a domain name) to call someone. In the past, we dialed a phone number (e.g., an IP address).

Remember, not all of those combinations can be used as some are reserved:

Reserved address blocks
CIDR address block Description Reference
0.0.0.0/8 Current network (only valid as source address) RFC 1700
10.0.0.0/8 Private network RFC 1918
127.0.0.0/8 Loopback RFC 5735
169.254.0.0/16 Link-Local RFC 3927
172.16.0.0/12 Private network RFC 1918
192.0.0.0/24 Reserved (IANA) RFC 5735
192.0.2.0/24 TEST-NET-1, Documentation and example code RFC 5735
192.88.99.0/24 IPv6 to IPv4 relay RFC 3068
192.168.0.0/16 Private network RFC 1918
198.18.0.0/15 Network benchmark tests RFC 2544
198.51.100.0/24 TEST-NET-2, Documentation and examples RFC 5737
203.0.113.0/24 TEST-NET-3, Documentation and examples RFC 5737
224.0.0.0/4 Multicasts (former Class D network) RFC 3171
240.0.0.0/4 Reserved (former Class E network) RFC 1700
255.255.255.255 Broadcast RFC 919

(table source: Wikipedia)

When you think about it, Cloud Computing is burning through IP addresses pretty quickly. For example, every GoGrid customer is allocated a block of IPv4 addresses to use with their infrastructure. That’s a lot of IP addresses that we are giving away. And, as more and more sites or infrastructures are created, more IPv4 addresses are being consumed. Since there is a finite amount of these addresses, companies need to start thinking about transitioning over to the new IPv6 protocol.

Also, cell phones & other public internet-enabled devices are consuming these limited IPv4 addresses (even if using DHCP – Dynamic Host Configuration Protocol – where IP addresses are applied for a specific time duration and then released back to a pool). So, as society becomes even more internet-enabled, this pool of IPv4 availability dries up even more quickly.

Do you get the point? When you think about it, running out of IPv4 addresses is really the sign of growth and the internet is expanding. This is a good thing.

IPv6 Networking Protocol

IPv6 builds for tomorrow’s growth and beyond.  Instead of being limited to numeric addresses only, IPv6 is 128-bit and is alpha-numeric. IPv6 takes the form of:

760px-Ipv6_address_leading_zeros.svg

(image source: Wikipedia)

Using “simple” math, that means that theoretically you can have 2^128 addresses or 340 undecillion (3.4 x 10^38) addresses. Let’s take a look at that number:

  • 2^128
  • 340,282,366,920,938,463,463,374,607,431,768,211,456
  • 340 undecillion, 282 decillion, 366 nonillion, 920 octillion, 938 septillion, 463 sextillion, 463 quintillion, 374 quadrillion, 607 trillion, 431 billion, 768 million, 211 thousand and 456
  • 340 billion billion billion billion
  • 340 trillion trillion trillion

Uh…that’s a LOT of numbers!

Let’s put it another way:

  • a 70 kg body, has approximately 7×10^27 atoms in it (7 and 27 zeros)
  • there are 6.79 billion people in the world (2009 estimate)
  • that means there are 4.753*10^37 atoms in all of the people of the world
  • which means that there are 7.16 IPv6 addresses available for every atom of living people in the world

I don’t think that we will be running out of IPv6 addresses in our lifetimes!

GoGrid and IPv6

GoGrid helped with World IPv6 day. We enabled IPv6 networking within Compuware’s IPv6 Website Performance Testing Page, a GoGrid customer, where you can determine how IPv4 and IPv6-enabled websites compare in terms of site performance. GoGrid is currently executing a comprehensive IPv6 roadmap, and the Compuware development project represents a technology preview that demonstrates a complete rollout of IPv6 within GoGrid’s infrastructure.

GomezIPv6-sample

Engineering teams from both GoGrid and Compuware collaborated to design and implement a custom solution within GoGrid’s infrastructure to allow Compuware to enable the first ever Gomez IPv6 Website performance test.

Today we issued a Press Release about our work with Gomez & Compuware related to World IPv6 Day.

Be sure that if you have an IPv6-enabled site that you run the Compuware/Gomez Performance test to see how your sites perform.

What You Can Do Now

Again, the goal of World IPv6 Day is to raise the awareness of the depletion of IPv4 addresses and to nudge companies along in their efforts to begin utilizing the new IPv6 protocols. It’s essentially a “test flight” for major web companies and other industry players to come together by enabling IPv6 on their main websites for 24 hours. If you remember the days of Y2K, this can be likened to a similar effort. No, the Internet won’t crash or stop working if you aren’t IPv6 ready today, but in order to save costs and effort in the future, companies should definitely start their long term plans and preparations of this inevitability. GoGrid, for example, expects to have IPv6 compatibility by the end of 2011.

So, take a deep breath, stop worrying about all of those IPv6 digits and what they mean, and start driving ahead in your planning for enabling IPv6 within your software, devices and infrastructure.


So far, in the GoGrid Cloud Survey Report series, we received data from over 500 CTOs, developers and IT professionals that answered the questions “What is Cloud Computing?” and “Does Your Company Use Cloud Services?”; even more interesting was the information these respondents gave that showed a Significant Increase in IaaS Adoption in 2011.

The insights we have received have been fascinating and we will continue to break down the survey results and release the findings here on the GoGrid Blog. This week we discuss the data received from our IT respondents on how they currently use cloud computing and what use cases would cause a migration to cloud computing services.

Cloud Computing Use Cases

Because cloud computing spans SaaS, PaaS and IaaS, it isn’t a surprise that many of our respondents use cloud computing services. Our first post in the series highlighted the fact that 65% of IT professionals surveyed use cloud computing in some way, shape or form. What is surprising are the use cases we received when we asked, “What use cases are you currently using in the cloud?”

Survey_use_cases_1

With a market saturated with SaaS e-mail and productivity applications, we found it interesting that the top use cases were for testing, development and production environments. Additionally, the chart shows a fairly decent distribution of use cases; each category received a healthy amount of usage.

That’s where the IT industry stands currently; but it is also intriguing to see what use cases will drive cloud adoption in the future.

Migrating to the Cloud

Our last post in the series exposed that many IT professionals plan to increase IaaS usage throughout 2011. This new data aligned perfectly with that prediction when we asked the following question:

survey_use_cases_2

Testing and development maintained the top spot, but there was a significant jump in physical data center use cases. Only 36.9% of respondents currently use the cloud for the physical data center, but nearly 50% of the IT professionals surveyed saw this as a reason to migrate to the cloud.

The data from this chart shows that each of these use cases are beneficial and create a compelling reason for IT professionals to migrate to cloud computing solutions. The next post in our series will be focusing on security requirements in the cloud. You’ll be able to see how your requirements stack up compared to the rest of the industry!

For more information on our survey methodology or to see all of our results, please download the Cloud Survey Report.

cloud_survey_graphic


In my previous post, “Set Up A Cacti Monitoring Server in Minutes with this GoGrid Community Server Image”, I showed how to use a Community GSI to quickly and easily set up a monitoring server on GoGrid running Cacti. In this second part of the Cacti GoGrid Community GSI blog series, I would like to walk you through how I connected my Cacti server up to an Ubuntu server (a node in my Glusterfs file storage array). First we will review the objectives we are looking to achieve and then dive into each one.

Objectives:

  1. Confirm private network configuration on both Cacti server and Ubuntu server, and test connectivity.
  2. Enable SNMP server and configure SNMP rocommunity string on Ubuntu servers.
  3. Establish SNMP agent listening IP address
  4. Create “Device” in Cacti console and confirm SNMP connectivity to Ubuntu server
  5. Create Graphs – CPU usage, Load Average, Memory Usage, PING Latency, Processes, Eth0 Traffic, Eth1 Traffic
  6. Repeat process for other Ubuntu servers in your network.

Confirm private network configuration on both Cacti server and Ubuntu server, and test connectivity

On GoGrid, you have the ability to network your servers together over a private network allocated to your account. (Note: all private networking within GoGrid is free.) We need to take advantage of this secure communication method to allow your Cacti server SNMP access to your servers. I recommend you use the private network IP range that is specified in your account – under the “List” tab then “Network”.

List_tab

List_tab2

In this example we will be using the 10.129.151.0/24 network (yours will be different).

First, log into the Cacti server and assign a private IP address to the eth1 interface. To do this open up the /etc/sysconfig/network-scripts/ifcfg-eth1 file and configure the IPADDR parameter and NETMASK parameter. Now save the file and toggle the interface /etc/init.d/network restart or ifdown eth1 and ifup eth1.

I would recommend using ifdown (which brings a specific network interface in this case we would specify eth1 right after command) and following the completion of that command execute the ifup (which will bring up a specified interface). This serves the same function as restarting networking but doesn’t touch the other interfaces that we don’t need to restart.

Cacti_privatenetwork

Once this is done – confirm you now have a private IP address on the eth1 interface.

Cacti_Private_nic_confirmation

While we are at it – let’s add the host name of the Ubuntu server to the /etc/hosts file. You need to open up the /etc/hosts file and add a line containing the 10.x.x.x address you are going to give the Ubuntu host. In this case, the Ubuntu server has a hostname equal to Gluster2.

Gluster2_PING

Renaming our Cacti server is the last step before we log out. The hostname of a GoGrid system is a unique string after initial deployment. Let’s change this to something that is more descriptive of what the host is. While in the Cacti server – modify the line HOSTNAME in /etc/hostname to “Cacti”, see image below. After saving and closing this file, reboot your Cacti system for this hostname change to take effect.

Cacti_hostname2

The second part of this objective is to bring up private network connectivity on the Ubuntu server – in this case Gluster2.

Gluster2

Log the Ubuntu server via SSH and open up the file – /etc/network/interfaces. In Ubuntu, the networking configurations for all interfaces are contained this file unlike the Cacti server which is running on CentOS. The screen shot below shows how I changed the eth1 inet from DHCP to Static and added the address and netmask parameters.

Gluster_privatenetwork_interface_eth1

After the file /etc/network/interfaces has been updated – the network interface needs to be restarted.

interface_restart

You should now be able to ping the Cacti server via its private IP address. You may also want to add the Cacti server to the /etc/hosts file on your Ubuntu server. This is the same file and location as on a CentOS server (The Cacti image is saved on CentOS 5.5). After you have confirmed private network connectivity between the two servers, you can move onto the next objective.

Enable SNMP server and configure SNMP rocommunity string on Ubuntu servers.

This objective requires us to log into the Ubuntu server via SSH. From the SSH login, we need to install the necessary packages to get SNMP running on your Ubuntu server. Run the command below.

Gluster_Install_SNMPD

snmpd will be installed and configured to start on boot automatically

After successful installation of the packages for SNMP, it is time to edit the snmp.conf. Here we need to add the unique read-only community (rocommunity) string identifier and the host (Cacti) that will be accessing this server via SNMP inquires.

Gluster_Enter_SNMPD_conf

If you are following along on your own – add your own unique string anywhere in this file and reference your Cacti server’s private IP address which should be different than mine.

rocommunity <unique string> <private IP of your Cacti server>

Gluster_rocommunity_setting

Establish SNMP agent listening IP address

Next edit the file /etc/default/snmpd. This file contains default SNMP configurations. We are interested in modifying the default interface the SNMP daemon will be listening on. By default, this interface is 127.0.0.1. We need to change this setting to the local 10.x.x.x interface of the Cacti host.

Gluster_SNMP_Default_Interface1

Modify this entry to reflect your private IP address (your private IP address will be different than mine):

Gluster_SNMP_Default_interface2

Restart SNMPD

snmpd_restart_gluster

Check to make sure SNMPD is listening on the right IP with netstat –lpn | grep snmpd

netstat_snmpd_listening_port

We are now ready to create the device in Cacti for monitoring. If you don’t see the snmpd process listening on your correct private IP – check the configuration in /etc/default/snmpd again. If you don’t get anything back from this command then confirm that snmpd is started and running properly with /etc/init.d/snmpd status

Create “Device” in Cacti console and confirm SNMP connectivity to Ubuntu server

Our next objective requires us to log into the Cacti graphical interface as admin. In the last Cacti blog post – I had you deploy the server and do the initial log in which will require you to update the admin login password to a password of your own. I use my web-browser and point to the public IP address of the Cacti server via http://<public_IP>/cacti/

Once you have successfully logged in – go to the “Create devices” on the main page. Refer to image below.

Cacti_CreateDevice

On the “devices” page click on the “Add” button.

Cacti_CreateDevice2

Here is where we will set the Description, Hostname, Host Template, SNMP version, SNMP Community, and Notes. Once this information is filled out appropriately, click on the “Create” button.

Cacti_Configure_new_Device

Create Graphs – CPU usage, Load Average, Memory Usage, PING Latency, Processes, Eth0 Traffic, Eth1 Traffic

If the device was created successfully, the SNMP information will be displayed for the device near the top of the device page. If you get an SNMP Error message there, then it is possible your private networking on one or both of the hosts is not configured properly or SNMP was not configured properly on the Ubuntu server.

Next, click on “Create Graphs for this Host”

Cacti_Configure_Save_Generate_Graphs1

This will take you to a new page where you can select the graphs available from the template used for this device. Remember, the template we set was the ucd/net SNMP host template. Put a check box next to the items you want to graph (CPU usage, Load Average, Memory Usage, PING Latency, Processes, Eth0 Traffic, Eth1 Traffic) and click “Create”.

**Note – it will take 5 minutes for the Cacti poller to start gathering data and populating into the rrd file This is the default /etc/crontab setting for poller execution. (An rrd file is essentially the data base the Cacti poller creates and uses to house data gathered from the device. )

Cacti_Configure_Save_Generate_Graphs2

After a few minutes Cacti will have built out the rrd file for this device and gathered initial data to be viewed in graphs. To get there go to “Graphs” in the upper left and then to “Lists” on the upper right side.

Cacti_Click_on_Graph

Cacti_click_on_List_view

From here we select the host “Gluster2” and filter for the graphs available for this device. See image below.

Cacti_View_new_Graphs

Click on each graph and you should see data being graphed (If you receive a “broken image” wait for a few minutes as Cacti may not have enough data to present a graph yet).

Cacti_graph1

Cacti_Graph2

Cacti_graph3

Repeat process for other Ubuntu servers in your network.

Repeat this process on other Ubuntu servers on your network. Shortly, I will follow up with a blog post on how to monitor your Windows server via Cacti! Remember to look for my Community GoGrid Server Image (CGSI) within GoGrid to get you up and running with Cacti in a matter of minutes!

Questions? Leave a comment!