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.

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”

2. Choose “Cloud Server”

3. Filter for “Gluster” & choose that image

4. Accept the Terms

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

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.

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.

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.

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 -

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.

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

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

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.

This is the 3^rd 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.

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.

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.

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.

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

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:

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.

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.”

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.

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.

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.

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

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.

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”.

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.

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

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.

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.

The second part of this objective is to bring up private network connectivity on the Ubuntu server – in this case 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.

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

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.

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.

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>

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.

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

Restart SNMPD

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

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.

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

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.

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”

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. )

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.

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

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).

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!

One of the best open-source tools ever created and maintained is Cacti. Cacti can be used to monitor and log critical information for your servers, applications and other network devices. The monitored data can be graphed in a variety of ways and becomes a valuable resource when troubleshooting problems and projecting future resource utilization.

However, the initial configuration can take hours to complete, not including the server OS install process and pre-configuration.

Deploying Cacti Easily in GoGrid

To make this process a bit easier for GoGrid users, I have performed the routine installation of Cacti 0.8.6 along with the package requirements within a Community GSI (GoGrid Server Image). Also, I have added DenyHosts for added system level protection. The ssh_banner will provide the details of what was configured on the system. All that needs to be done is going into your account within the GoGrid portal, clicking on the Add button and filter for “Cacti”.

The select “Add Cloud Server”:

Filter for “Cacti“. You will then see the Cacti image. Highlight that image and click the Next button to deploy into your GoGrid infrastructure environment.

Now simply name your Cacti Monitoring Server and give it an available public IP, along with the amount of RAM you need. 2GB is usually a good baseline.

Click Save and then the server will enter the deployment process. You will see it on your Grid in the amber state.

In a few minutes the server will show green and you will be able to find the login information under the Passwords tab.

Use the login provided in the Passwords tab (within the “Support” section of the portal) to SSH into the server as root. Now, read the ssh_banner (also posted here in this blog) for more detailed information on the system.

More about Cacti

The online community that contributes to Cacti is huge. There are so many host templates out there ranging from Windows pagefault to Zeus ZXTM load balancer. The Import and Export tools that Cacti has built in become very useful in regards to using and sharing templates within the community.

If you are totally new to Cacti – then I highly recommend you review the manual.

http://www.cacti.net/downloads/docs/html/

Also – comb through the forums for more insight and possible answers to your questions.

http://forums.cacti.net

SSH_BANNER Information

Below is the SSH_BANNER that will display within SSH on the server you deployed using the Cacti Community GSI.

SSH_BANNER:

—–Community GSI Setup Report—–

    Steps accomplished to make this Community GSI: 

1. Enabled RPMForge repository  
2. Installed PHP5
3. Installed Cacti 0.8.6     
4. Installed MySQL Server 5.0.7
5. Installed DenyHosts (please update ADMIN_EMAIL in /etc/denyhosts/denyhosts.cfg
   with your email
6. Set httpd, mysqld, snmpd, denyhosts to start on boot
7. Created MySQL user cacti and new database named cacti
8. Set password for database to < omitted > - recommend you change this to your own pw.
9. Imported cacti settings from cacti.sql into cacti database
10. After this VM is deployed - log into Cacti from servers IP - http://cacti/
   (don't forget the trailing '/')
11. Follow GUI Login steps to complete installation. The initial user/pw is admin/admin
    Login with this and then you will be prompted to update pw.
12. Modify /etc/httpd/conf.d/cacti.conf --- change "Allow" line to IP(s) you want to give
    access to this graphing utility. Now it is set to all.
13. The forums.cacti.net is a good place to find device templates.
    http://www.debianhelp.co.uk/cactitemplates.htm is a good source for templates and
    documentation
14. Copy the above information and then feel free to delete this ssh_banner file. It is
    located in /etc/ssh/ssh_banner
15. Also don’t forget to assign your new Cacti Monitoring Server a private IP from your
    private network.
    This is the preferred way to communicate with your other servers on GoGrid.
16. Update IPTables to meet your firewalling needs. 

----Community GSI Setup Report----

Deploy the new Community GSI and start monitoring your applications and servers today! Once you have what you want in your Cacti setup (in regards to devices being monitored) then save your server image using MyGSI functionality. The image that you save will be private and securely accessed only from your account. You can later redeploy it to commit new devices to the configuration and then resave.

More tutorials on the way!