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

Archive for the ‘Load Balancer’ Category

Cloud Computing is fantastic! Where else can you provision infrastructure on the fly, scale it up (add more CPU/RAM/Storage) and out (add more instances of cloud servers) and grow your infrastructure based on your business demands. At GoGrid, we believe in making complex infrastructure easy by providing you with tools to create, manage and scale your GoGrid cloud infrastructure using our web-based portal or programmatic API. But did you know that you can also create and manage your GoGrid cloud infrastructure while you are on the go using your iPhone? Back in 2010, we launched our iPhone application and we designed it to scale as we added new data centers. The application fully supports our San Francisco, Ashburn and Amsterdam data centers simply because we built the app on top of our API.

iphone-app-icon

Are you a mobile apps developer? I would love to see what magic you can do with the GoGrid API in making the next generation Android or iPad application. Feel free to leave a comment on this post.

So, how do you set up the GoGrid iPhone application once you have downloaded it from the iTunes App Store? It’s pretty easy so I wanted to show the steps on setting it up in this article.

Create an API Key within the GoGrid Web Portal

The first step it to create an API key within the GoGrid web portal. You need to have a GoGrid account for this. (For those who are new to GoGrid and want to test it out specifically with the iPhone application, go to the GoGrid sign-up page and in the “Promo Code” field, enter “GGiPhone1″ and receive a $100 service credit!)

  1. Log into the GoGrid portal.
  2. Navigate to My Account > API Keys:
    API-dashboard
  3. On the left, click on “Add an API key” and a new window will open:
    Create-API-key
  4. Fill in the information. The Shared Secret is needed within the iPhone app in order to authenticate you to your infrastructure. Also, it is recommended that you use a “Super User” role so that you have full functionality within the iPhone application. Set the status to “Enabled” as well.
  5. Click Save and your API key will be created.
    API-key-created
  6. Once the key has been created, be sure to capture it. You will need the key and the Shared Secret in the iPhone application. If you ever need to see the Shared Secret in the future, simply click on the key to see the details:
    API-key-details

That’s it! With the two API key items, you are now ready to set up the iPhone application to control your infrastructure.

Setting Up Your GoGrid Account on the iPhone Application

Be sure that you first download the FREE GoGrid iPhone application from the iTunes App Store. Armed with the API Key and the Shared Secret, you are ready to configure the iPhone App. Here’s what you need to do.

  1. Launch the GoGrid iPhone application.
  2. If this is the first time that you have used the iPhone application, you will be prompted to enter an optional passcode. You can skip this step if you want, otherwise, we do recommend that you enter a 4-digit passcode:
    IMG_1264
  3. Once you have set up a passcode (or authenticate in if you are a returning user), click on the “Add a New Account” in the Accounts pane:
    Photo May 10, 8 13 33 AM
  4. In the New Account pane, enter in a Name for your Account (note, this is a local name only and is not transmitted back to the portal) and your API Key and Shared Secret:
    Photo May 10, 8 14 38 AM
  5. Click the Done button and your new account will show in the Accounts pane:
    Photo May 10, 8 14 48 AM
  6. Now click “Log In” to connect to your GoGrid infrastructure. (Note: you must have an Internet connection in order to do this.) The first screen that you will see are your GoGrid Cloud Servers:
    Photo May 10, 8 15 03 AM

Now that you have your GoGrid infrastructure connected to the iPhone app, you probably wonder what you can do with it. Also, if you ever want to remove access to your GoGrid infrastructure on the iPhone application, the easiest way to do this is to simply delete the API Key from within the GoGrid portal.

Managing your GoGrid Infrastructure via the iPhone Application

There are a variety of things that you can do with the GoGrid iPhone application once you have it configured, namely:

  • View/Add/Delete/Restart GoGrid Cloud Servers
  • View/Add/Edit/Delete F5 Load Balancers
  • View Status of Objects and IP Addresses
  • View Server User and Passwords
  • View and Filter GoGrid Job History
  • View Current Billing Information
  • Multiple Datacenter Support
  • Multiple Account Support
  • Access additional information about GoGrid

While I’m not going to walk through each and every function of the iPhone application, here are some highlights:

View/Edit your Cloud Servers:

Photo May 10, 8 15 03 AM Photo May 10, 8 16 21 AM Photo May 10, 8 16 33 AM

View your Load Balancers:

Photo May 10, 8 15 08 AM Photo May 10, 8 15 47 AM

Add/Edit your Load Balancers:

Photo May 10, 8 15 33 AM Photo May 10, 8 16 08 AM

View/Filter your IP addresses:

Photo May 10, 8 15 18 AM Photo May 10, 8 15 25 AM

View your Job History:

Photo May 10, 8 16 50 AM

View Account/Passwords and more:

Photo May 10, 8 16 57 AM Photo May 10, 8 17 03 AM

So, if you are a current GoGrid user and have an iPhone, I encourage you to download the GoGrid iPhone application and start managing your infrastructure on the go. And perhaps, if you are a mobile or web developer, the fact that the iPhone application was built completely using our API might inspire you to craft your own mobile or web interface to control GoGrid infrastructure. If you do create something interesting and innovating, please do share it with me with your contact information so that I can check it out!


As of today, GoGrid has released multiple images of the leading software load balancer, Riverbed Stingray! The following images are available on the GoGrid Partner Exchange in both San Francisco and Amsterdam:

  • Riverbed 7.4 Simple Load Balancer 10 Mbps
  • Riverbed 8.1 Load Balancer 10 Mbps
  • Riverbed 8.1 Load Balancer 200 Mbps
  • Riverbed 8.1 Load Balancer 200 Mbps WAF
wpid3797-Stingray.png

Note that the Riverbed 7.4 image is still Zeus branded. We have made that available in order for users to have access to the Simple Load Balancer on GoGrid. It currently supports up to 10Mbps bandwidth and basic load balancing. It does not have clustering, SSL decryption, health checks or any advanced load balancing features.

The Riverbed 8.1 Load Balancer 10 Mbps Load Balancer supports bandwidth up to 10Mbps, clustering, no SSL, and basic load balancing.

The Riverbed 8.1 Load Balancer 200 Mbps Load Balancer supports bandwidth up to 200Mbps, clustering, no SSL, and basic load balancing.

The Riverbed 8.1 Load Balancer 200 Mbps Load Balancer WAF supports bandwidth up to 200Mbps, clustering, SSL, load balancing, health checks and integrated Web Application Firewall.

Finding the Images

wpid3789-media_1327947751889.png

The images are available via our image selector. In order to find and launch the Riverbed images, click on “Add Cloud Server” for the Data Center that you want to use. In the “Name” field type “Riverbed” and then hit enter. This will filter for just the Riverbed images.

The charges are monthly and you will be charged after you deploy the image. There is a special promotion occurring for Amsterdam regarding deployment of the Riverbed images. Please contact your GoGrid Sales Representative for more details.

Deploying the Load Balancer

wpid3795-media_1328226831712.png

The deployment of Stingray is similar to the setup for Zeus. The main difference is the setup is now automated and the license is automatically applied. Note that these instructions ONLY apply to the Riverbed 8.1 versions. These are the basic steps.

  1. Select the Load Balancer image based on your needs. For this example, I will select “Riverbed 8.1 Load Balancer 10Mbps”. Click “Next” and then enter a Server Name, select an IP and the amount of RAM – I recommend using at least 1 GB of RAM on the server. This will generate a Virtual Machine with the software pre-deployed after you click “Save”.
  2. All the Stingray Images run on Ubuntu x64 base images. You will need to access the server via SSH using the root login. Your logins can be found in the GoGrid web portal by clicking on the server icon, then Tools > Passwords.
  3. One of the main differences with this version is that the installer starts immediately upon login and applies the appropriate license. Type “accept” at the prompt to begin the installer or press “return” to abort. If you do not accept the license terms, please delete the server.
  4. The script will configure the Load Balancer for you and generate a temporary password. The password for the Load Balancer will be documented at the end of the script so look for it there. Make sure to take note of it since you will need it to login to the GUI.
  5. You will be returned to the prompt – at this point I recommend changing the server password (note that this is NOT the password for the load balancer). This is the password that you will use to access the server again via SSH. In case you have forgotten, the command to enter a new password for Ubuntu is “passwd”.

Launching the UI

wpid3793-media_1328220648196.png

Launch your favorite browser and enter the IP address of the server with the port 9090. For example, you would enter something like:

https://190.10.1.1:9090

Since you are connecting via SSL with a self-signed certificate, your browser will give you a warning message. Since this is your own server, you can bypass the message (assuming that you entered the address correctly) and set an exception for this address.

Once you have cleared the warning page, you will be presented with the Riverbed Stingray GUI. At the login screen, enter the following:

Username: admin

Password: [the password generated for you by the system in the previous step]

Update the Admin Password

wpid3791-media_1328220486670.png

Go to the tab “System”.

Select Users > Local > Admin

Change your admin password on this screen. You can also create other accounts from the User tab.

All the Stingray 8.1 licenses in GoGrid allow for clustering and passive health checks. You can configure this on the GUI – the process is the same as the Zeus Load Balancer so you can refer to my previous blog post for more details – “How to Configure Zeus’ New Load Balancer in the GoGrid Cloud“. You can just scroll past the SSL Certificate graphic to bypass the Zeus-specific instructions and into the details on how to add servers to a pool and configure the load balancer.

You can also refer to the Riverbed Quick Start Guide on our wiki.

Since this is a partner image, all support will go through Riverbed. There is extensive documentation on the Riverbed support website as well.

With four different images to chose from, you will now have the flexibility to select the features and price point that work best for you. From controlling traffic to a single web server to managing a large pool of servers across multiple data centers, GoGrid with Riverbed Load Balancers offers the right, scalable solutions for your unique Cloud Fingerprint.


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.

Zeus_motd

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.

Zeus_FFuntrusted

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

Zeus_SSLcert

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.

Zeus_West1

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.

Zeus_TM

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.

Zues_connections

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.

Zeus_joincluster

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.

Zeus_TrafficIP

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.


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.

clip_image002

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 21st, 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 Balancingcreate 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., 3rd 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.


We absolutely LOVE hearing how GoGrid customers are using our cloud solutions to create unique “cloud fingerprints” and environments using the features and data centers of GoGrid. Paul Trippett just published a very interesting write-up of an infrastructure environment that addresses many of the common concerns facing any company looking to provide a highly-redundant infrastructure while also ensuring a solid Service Level Agreement (SLA) for their customers.

customer_showcase_GoGrid_logo_sm

You can find Paul’s original write-up titled “Utilizing GoGrid’s Multiple Data Centers for Routing and Failover” on his site. With his permission, we have reposted the article so that others can learn, mimic and build upon his unique scenario.

At the beginning of the year one of our customers asked us if we can provide an SLA for StormRETS and with it, the sound gritting teeth suddenly echoed around the room. As you can imagine, this caused more questions than which we actually had answers for:

blockquote_2 What kind of SLA did we want to provide and what could we realistically provide?

Our hosting provider, at the time, had an SLA which entailed “We don’t give any guarantee that your servers will be available, but if for any reason they are unavailable we will get the back up and running as soon as we can.”, erm, how on earth can we build a SLA based on that. It was decided at this time we would migrate our servers to another hosting provider, one at least with a SLA we can build on and a company we can actually contact directly should a problem arise.

Any migrations we did needed to address the following issues:

  • System Monitoring — Constant monitoring for potential problems.
  • Network Downtime — If its a localized network issue, secondary DR fail-over site.
  • Server Downtime — Multiple Servers or Secondary DR fail-over site.
  • Software foul ups — Unit Testing and run the system on multiple servers.
  • Server Software Updates — Multiple Servers.
  • Maintenance Schedules — Multiple Servers.
  • High Traffic Spikes –  Multiple Servers.
  • Botched Deploys — DR fail-over.
  • Drunk SysAdmins

We decided it would be a good idea to setup a second data center in the case of a failure of the primary, but, what’s the point in having all this extra duplicated capacity we’re not using, it makes sense to put it to good use by directing traffic to our nearest data center and failing all traffic over in case of a major outage.

DNS Failover and Load Balancing
The problem with this is that DNS fail-over or geo-aware DNS was extremely expensive. We just couldn’t justify a spend of more than $200 a month for something we could setup ourselves on a few VPS boxes scattered around the globe for $50 a month. Anycast DNS is severely overrated, it makes sense yes but not at the prices being asked. Sometimes answers comes from strange places, while doing some whois searches on start-up companies, which we knew would be looking at this same problem, we found Zerigo who have recently started offering geo-aware DNS at prices starting at $20 per month. After running some tests there response times aren’t to shabby either!

Cloud Hosting
There are more than enough blog posts about choosing a cloud provider. We looked at the more common providers including Amazon, Rackspace and GoGrid, in the end we decided on GoGrid. GoGrid offer a really good SLA, they have telephone support and multiple data centers ready for you to use.

blockquote_2GoGrid offer a really good SLA, they have telephone support and multiple data centers ready for you to use.

With every GoGrid account comes two /28 blocks of routable IP addresses, one in each data center. This is an awesome feature, usually when you create a new VPS you are assigned a random IP address from a huge pool, deleting a VPS would mean you lost that IP address, with GoGrid you can delete a VPS and re-assign its IP address to another VPS meaning all your IP addresses are always contiguous and easy to remember. Due to GoGrid’s network setup you cant use all the IP addresses as some are reserved for the default gateway, network broadcast, and a further 3 IP address reserved in the middle of the pool for the active and standby load balancers.

GoGrid provides free fault tolerant F5 load balancers with their service, allowing you to setup up to 3 load balanced IP addresses per data center. In our old setup we had setup Load balancers ourselves running on CentOS and NGINX but using GoGrid for this saves us time and money, and gives us one less thing we have to worry about and manage ourselves.

Network Setup
Our network setup is nothing new, but the data we have, needs to be retrieved and processed quickly via our API. Our average API response time is currently 0.07 seconds against approx 1,000,000 property records and we don’t want any redundancy we put in place to affect that time. Additional locations should be as autonomous as possible with little or no inter-site communication caused by an API request and be able to handle another data center going down.

Cluster14

Above you can see the basic network diagram of what we have setup and running:

  • Zerigo DNS to load balance between the two data centers and fail-over requests to another data-center in case of a failure.
  • GoGrid f5 load balancers in each location to load balance requests across the web servers in each location.
  • OpenVPN Servers to bridge the two networks for passing replication data between the data centers.
  • MySQL circular replication between the two sites.
  • CouchDB multi master replication between the two sites.

A lot of the fail-over is left up to the platform to decide. Every minute the monitoring system calls into the system via a URL, this script checks a few key things, such as MySQL and CouchDB availability, if any of these tests fail the script returns a failure status and the DNS automatically switches. We use 3 minute TTL’s on the majority of our DNS records, so in theory fail-over should take no longer than 3-5 minutes to complete.

With our new setup we can now redirect traffic to our second data center while performing maintenance on the other, and we are in a much better position to provide an SLA to our customers, but even after these major first steps we are still not in a position to provide an SLA quite yet. Over the coming weeks we will be running various performance tests and fail-over testing to verify that both data centers will be able to work independently of the other, based on these performance tests we will be able to devise how much capacity we have and at which points we need to start considering upgrades and adding capacity.

Do you have an environment running on GoGrid that you think is unique, helpful for others to see and learn from or are particularly proud of? If so, drop me an email: michael [at] GoGrid.com.