Zeus is a new GoGrid partner that provides a software load balancing product as a partner image called “Zeus Load Balancer 200Mbps”. There are three immediate features that come to mind when thinking about how to leverage Zeus within GoGrid: Load Balancing, Failover and Clustering. Note that this first image is a preview with certain feature set. It contains the majority of Zeus features but is capped at two clustered servers and 200 Mbits of bandwidth. Additional images are expected to be released by the end of the year.

This tutorial assumes that you have basic understanding of Linux and SSH as well as basic load balancing and failover strategies.

Cross Data Center Load Balancing / Failover

One of the main uses cases for Zeus is to load balance servers in the same data center. However, a more interesting use case is to quickly and easily load balance web servers within one data center and support failover to another data center. The process is straight forward. First, deploy the Zeus partner image as a VM with 1G RAM in the US-West-1. This example assumes that you already have web servers running on both the US-West-1 and US-East-1 data centers.

Once the Zeus image has been deployed, SSH into the server using the root login. Your logins can be found in the GoGrid web portal by clicking on the server icon, then Tools > Passwords.

We recommend changing your automatically created, default password as soon as you login.

The Message of the Day (MOTD) will have links to additional information and support. To begin, run the configuration (/usr/local/zeus/zxtm/configure). Note that you will be prompted to enter the license key. The key is located at /root/license.txt.

Once the configuration is complete, launch the web interface, typically https://IP_ADDRESS:9090

When you first launch the Zeus admin portal, you will be presented with a warning from your browser. This is because the Load Balancer requires a secure connection and is using a self-signed certificate. Most likely, your browser won’t recognize the certification and present a warning. Bypass the warnings and set an exception for this IP address.

Alternately, you can bypass the warnings but not set an exception and enter your own certificate once you are in the Admin portal:

Use your admin login (again, http://IP_ADDRESS:9090) to access the web interface. One of the first things that you want to do is to create the pool of IP addresses that you want to load balance.

• Click on the icon that says “Services”. You will then see a page with several tabs. Click on the tab called “Pools”. Look for the section that says “Create a new Pool”. First you will want to enter the IP address of the backup server in the US-East-1 Data Center. I have one setup using port 80 and I am calling the pool “East”. You can also set the type of monitoring you want against the pool. Since these are web servers, I am selecting “Simple HTTP” – this ensures that the web server is up and running. For example, if you use Ping, this tells you that the server is responding but not necessarily if the web server itself is down. The click “Create Pool”.
• Next, go back to “Create new Pool” and enter the IP addresses of the two VMs that contain your website in US-West-1 and set the port (typically 80). Give it a name – I am going to call this one, “West1″. Set the monitor here to “Simple HTTP”. Click “Create Pool”. You will now see an option to set the Failure Pool – enter the first pool that you create (“East”).
• Below Basic Settings is a section titled “Load Balancing”. You can also set the algorithm here – in this case, I set Round Robin which will attempt to balance traffic evenly between the nodes.

Next you will want to create a “Virtual Server” (Zeus’ terminology) which means to create a Traffic Manager (TM) instance on your server. Click on the “Virtual Servers” tab to create one. I have created one called “Clustered_TM”. Since I am balancing Web servers, I have set the Internal Protocol to “HTTP” and the Port to “80”. Note the Default Traffic Pool – this is the pool of web servers that I just created (“West1”). Set Enabled to “Yes” and hit the “Update” button to activate the load balancer.

The Zeus TM constantly monitors health so if there are any issues with the servers (such as a server no longer responding) in the pool, it will report it on the main page. Zeus can use different types of checks – in addition to ping, you can also check HTTP, DNS, FTP and others.

You may notice a few warnings when you setup Zeus. Here are some tips to help clear them.

1. Java: Cannot start Java Runner, program ‘java’ not found
   • Go to the System icon and click on the “Global Settings” tab. Scroll down to the Java Extensions bullet and select “No” for java!enabled. This is really only used if you are coding in the API and not if you are working via the UI.
2. Cannot Bind to Port 80
   • This is typically due to Apache2 running on Ubuntu. This should already be disabled by default but you can also manually stop it. SSH into your Zeus VM and enter: service apache2 stop

In this configuration, two servers are handling traffic evenly in the West. If one of the servers in the West nodes should fail, then the load balancer will send traffic to the server that is still running. If both should fail, the failure pool will activate, and traffic will route to the East server. Note that due to the distance from the West load balancer, there will be latency, however this will ensure that the website will still run even if there are issues with both servers in the West region.

Another useful feature is the ability to track activity and connections on the load balancer. First, click on the “Activity” icon and then the “Connections” tab. Since both the West servers are up and running, you can see that the traffic is balancing between those two servers.

Clustering

The previous section only demonstrated setting up Zeus as a single instance. Zeus gives you the ability to setup a clustered pair, in order to provide coverage should one of the Zeus instances go down.

In order to build a cluster, you will need to configure a few things. First deploy a second instance of the Zeus image.

You will need to make some manual changes to the VMs first.

1. SSH into your first Zeus server.
2. Change to the proper directory: cd /etc/
3. Edit the hosts file and include an entry for the second Zeus server that you just deployed
   • i.e. (173.1.45.149 31852-1-67347) in the example
4. Save and Exit
5. SSH into your second Zeus server
6. Edit the hosts file and include an entry for the first Zeus server
7. Login to the GoGrid portal and restart both servers.

These steps make it easier for the Zeus servers to talk to each other. After the servers have restarted, go to the Admin page and run the following steps:

• Click on the System icon and then the “Traffic Managers” tab.
• Scroll down to the bottom and select “Join a Cluster”.
• You will be presented with a Wizard that will guide you to adding the server to a cluster. Follow the instructions on the Wizard to join a cluster (it should auto-detect other Zeus instances in your VLAN).
• This screenshot shows an existing cluster member since I already have this server as part of Zeus cluster.

Once the servers are in a cluster, they will share configurations so you can administer the cluster from either server.

The last step is to make the cluster invisible to the end user. You will need to use an additional public IP in order to do this. Click on the Services icon. Select the “Traffic IP Groups” tab.

Give the Traffic IP Group a name. In this example, I have created one called “Cluster_Traffic”. Add an unassigned public IP address. (IP addresses can be found within the List view under the Network section within the GoGrid portal.) Note that this is a Zeus setting. Even though it will be “taken” by Zeus, the GoGrid portal will still show this IP address as Unassigned.

You can then use this IP address as the outbound IP for your web cluster. It will leverage the use of both Zeus load balancers, automatically and transparently managing failover and traffic.

Zeus gives you the flexibility to launch load balancers as you need them and to directly manage as many server pools as you require. Although load balancing across data centers is possible, latency will not make this an elegant solution – you will need to implement global load balancing. Contact Zeus if you are interested in using this option. If you want to learn more about Zeus, you can get additional information and support from www.zeus.com/community/documentation.

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.

The cloud is great for so many things. You can create a web presence in a matter of hours or completely implement an N-tiered, redundant, elastic, secure globally-available cloud topology. Spinning up infrastructure via a web portal or API in minutes via a few clicks of a mouse is a dramatic transformation from the days of racking and stacking servers, untangling miles of cat5/6 cables, connecting load balancers and firewalls to the mix and hooking up storage devices. And let’s not forget about physical security, power supplies, cooling and network redundancy. The neat thing about the cloud is that all of the stuff has become really easy to do and you can do it very quickly.

GoGrid has a long history of enabling IT infrastructure solutions for companies across the world. We have built out core services and offerings to allow businesses to build want they want quickly, efficiently and with state-of-the-art cloud technology. But just because you have great tools at your disposal doesn’t mean that your cloud environment will magically create itself. And that is something that we realize and understand at GoGrid.

Architect for Success

Cloud computing can be almost magical at times, but we need to remember the processes and best practices for security and ensuring redundancy that we are accustomed to using, and adapt and use them within the cloud as well.

A few weeks ago, I wrote a post “Things to Think About When Building Secure Infrastructure” where I made a few points about “assumption,” namely, assuming that whatever cloud vendor you choose, they will take care of everything for you. Regardless of the cloud vendor, you need to do your due diligence and update your standard operating procedures to reflect how cloud computing works. It is different than traditional IT in many ways. For example, in the GoGrid cloud, you can create a cloud server, harden it with security software and configurations and then save it as a MyGSI (as “server image”). Then, as you need to scale out your infrastructure, you can do this not only quickly, but securely as well, by deploying clones or instances of that hardened server. With a traditional, physical deployment, it takes much longer and there is no guarantee that you will have each and every security patch in place on every server.

You must design any IT environment, cloud or not, for resiliency and redundancy. Obviously, the level to which you do this really requires you to fully understand the needs of both your organization and your customers. A QA environment, for example, probably doesn’t need as much redundancy as an eCommerce site does. A great recent example of this is with the Amazon Web Services (AWS) outage that took place on April 21^st, 2011.

Amazon is the cloud vendor of thousands of companies worldwide. When their outage hit their US-East facility, it brought down a large number of high-profile sites and countless “regular” sites as well. However, missing from the list of affected sites was one Amazon’s most famous customers, Netflix, who, because of solid standard operating procedures and designing for the cloud, weathered the outage just fine. As stated on the Netflix blog: “…our systems are designed explicitly for these sorts of failures. When we re-designed for the cloud this Amazon failure was exactly the sort of issue that we wanted to be resilient to.”

There is an important lesson here – your ability to recover is a direct result of the amount of effort and planning you put in prior to prevent something catastrophic from happening. Or, to use a cliché here, an ounce of prevention is worth a pound of cure.

Leverage ALL of your Tools

From GoGrid’s perspective, it is our goal to provide cloud infrastructure designed to transform IT. GoGrid’s custom-built management layer leverages hosting and IT technology expertise that we have gained through years of experience. Our technology enables our customers to construct their businesses, solutions and architectures using solutions never before seen in the marketplace.

Many think of cloud computing as containing simply the raw building materials required to craft an IT topology – but actually, it is much more than that. But that depends on the provider. Many cloud providers merely provide the tools and leave the rest up to you. At GoGrid, our goal is to make complex infrastructure easy by providing not only full management of the entire infrastructure as a suite of services (e.g., the VMs, physical servers, load balancers, cloud storage, firewalls, etc.) but also in the form of education and consultation.

We recognized that it is critical to have best-in-class cloud solutions available to our customers when they are building out their architecture. In order to provide these industry-leading solutions, we have also partnered with many leaders with various specialty solutions and showcase these partners within the GoGrid Exchange. This ecosystem of partner solutions continues to grow regularly. There are solutions in Software/Applications, Development/Testing, Disaster Recovery & Backup, Cloud Management, Security, Monitoring and Reporting.

Some GoGrid Recommendations

While GoGrid provides you with the components and solutions from which to fully construct your infrastructure, there are times where a Partner solution or additional service might be worth implementing. You can see some GoGrid and GoGrid Partner options below:

Load Balancing – create redundancy by routing traffic between multiple servers/locations. Load balancers distribute workload across multiple computers to minimize response time, optimize throughput and avoid overload. Should a server encounter an issue, load balancers automatically route traffic to other available resources, thereby eliminating downtime or outages.

• Option #1: GoGrid’s built-in F5 hardware-based load balancing can route traffic around your infrastructure within a pre-defined data center.
• Option #2: Use a GoGrid Partner Server Image (PGSI) from Zeus Technologies to enable global load-balancing between data centers and do more with your traffic flow.

Firewall – a hardware or software-based firewall is designed to either permit or block particular pre-configured types of network transmission based on a set of rules. Firewalls, when properly configured, protect against unauthorized access to infrastructure and can prevent threats from the public internet. Be sure that you have your servers and infrastructure secure using some sort of firewall.

• Option #1: When a service is created (virtual or physical), it has standard OS firewalls implemented (e.g., iptables or Windows Firewall). Do note, we always recommend going into those new servers immediately and changing the randomly-created default password, as well as running system updates to ensure that your server is fully patched.
• Option #2: Use a GoGrid Partner server image by Gazzang ezEncrypt for application-level encryption of data within a MySQL database or a GoGrid PGSI from CloudPassage Halo for hardened server images that are monitored to maintain maximum security.
• Option #3: Sign up for GoGrid’s Fortinet Firewall or Cisco ASA 5510 for dedicated multi-threat prevention hardware to fully harden your environment.

Backups – a backup is essentially a copy of data. Backups act as a means to recover from a data loss or to recover data from a historical period of time. There are various types of backup solutions (e.g., incremental vs. complete) you can employ so it is important to carefully consider items like the frequency of backups, the location(s) where the backups are stored and the type of data you are backing up. Having backups of your environment and data is critical, and you should always have these backups in multiple, distinct locations for better loss prevention.

• Option #1: Persistent storage on the Virtual Machine is a good place to start. Even if your server is restarted, the data will persist. You can also use GoGrid’s Cloud Storage which is dynamically scalable and attachable to your VMs. Cloud Storage can be used as a back-up solution in conjunction with other solutions (e.g., 3^rd party or off-site solutions).
• Option #2: Use a GoGrid PGSI from GlusterFS as an ideal solution for a software-only, highly available, scalable, NAS storage system for a managed storage pool.
• Option #3: If your environment requires critical data backup with the option of quick recovery, talk to a GoGrid Account Manager about Managed Storage and Backup solutions.

There are other GoGrid Partners with PGSI solutions within the Exchange as well and the list will continue to grow. But the thing to remember here is there is a reason why we have worked diligently to have relationships with these vendors. They make our infrastructure solutions even better because they are experts within their particular niche. We provide the infrastructure tools, components and services, the management layers, the education and consultation to make your cloud a success. Our Partners, in turn, provide you with solutions even beyond that.

So here’s the bottom line, you can build just about whatever you want with the cloud. Just don’t lose sight on the fact that your solution is only as resilient, robust, secure or available as to what you put in it. So talk to your cloud vendor, employ security and redundancy best practices, and leverage the expertise of partner solutions.

Some pretty big things are happening at GoGrid. Today we announced the release of our Image Rights Management (IRM) service for GoGrid Partners, a very powerful technology that assists with the software and licensing management in the cloud, specifically within the GoGrid Exchange. As many of you may know, GoGrid Exchange is a catalogue of software server images and solutions from Independent Software Vendors (ISVs) that are available on-demand for those who use GoGrid cloud infrastructure. IRM adds several benefits for ISVs and, in turn, customers.

To better explain IRM technology and why it is so important, I sat down with Raja Srinivasan, VP of Cloud Computing at Zeus Technologies, and our very own Paul Lancaster, Manager of Cloud Ecosystems at GoGrid. They discuss how IRM is the solution to licensing software in the cloud and what the GoGrid Exchange means for partners and customers.

Raja and Paul highlight many of the benefits of the GoGrid Exchange as well as focus on our new IRM technology. They break them down into two main areas.

Benefits for Partners:

• License Management – IRM technology automatically verifies if the software is correctly licensed to run within the GoGrid cloud, and will automatically take pre-defined actions should the licensing be invalid.
• Software Management – Simply update your software on the GoGrid Exchange and it is automatically made available to your customers.
• Easier to Deliver Support – When a customer has a support need, the ISV can quickly understand exactly what kind of infrastructure the software is running on so they can identify the support issue faster.
• Easy Payments – GoGrid handles the invoicing of customers for both Partner Image licensing and infrastructure usage, and then pays the Partner for the Partner Service Image usage.

Benefits for GoGrid Customers:

• Single-Button Install – Customers can find the software solution they want on exchange.gogrid.com and instantly install it with little to no configuration.
• Software Management – Users are automatically kept up to date with the latest versions of the software they installed from the Exchange.
• Unified Invoicing – GoGrid handles the billing for Exchange Partner server images as well as infrastructure costs within a single invoice. Customers can manage their software and infrastructure payments from a single portal on a single bill.
• Flexibility & Scalability – the GoGrid Exchange allows customers to get the software they want when they want it. Also, customers aren’t locked into any multi-year licensing deals. The Exchange makes software solutions in the cloud highly efficient and ready to scale with your company.

We’re very excited about the release of IRM what this means for our customers and the cloud computing industry.

For more information, please read our Press Release titled “GoGrid Enhances Partner Exchange Platform with New Image Rights Management Technology” which is available in the Press Release section of the GoGrid site.

For more information, please visit http://exchange.gogrid.com