How To Set Up High Availability Web Applications in the Cloud using GoGrid

April 14th, 2009 by - 70,240 views

Web Applications like WordPress, Drupal, Joomla, SugarCRM and others are all the rage and have been for quite a while. The huge availability of Open Source applications, typically based on Linux, Apache, mySQL and PHP (LAMP stacks) that you can find in SourceForge or other repositories, makes the implementation of powerful web-based solutions a snap. Once you find the web application of your dreams, the next step is finding a hosting provider. There are many VPS (Virtual Private Server) hosting providers that offer shared hosting at pennies on the dollar. But with those VPS solutions, you are left with exactly that, a “shared” environment. So, if someone else on your shared server is running bad scripts or code that sucks up resources on your server, you are affected with little or no recourse to resolve other than to complain, moan or move to a different provider.

So, as you grow (or as your service deteriorates due to the resource-sucking of others on your shared box), you are left with a decision of what to do next. Many people choose the most obvious upgrade path of leasing a dedicated server (e.g., at ServePath, we offer dedicated, managed hosting) or colocating (where you bring your own hardware and a hosting provider like Coloserve leases space, power, cooling, security and bandwidth). But now, you have another option that truly fits the model of delivering scalable web hosting…put in in the Cloud, with GoGrid, for example.

Recently I helped map out the implementation of a secure, redundant, load-balanced web application in the Cloud using GoGrid.

Original Setup

A client originally set up the following implementation of a WordPress blog on GoGrid:

  • One Web/Application Server
    • CentOS 32-bit
    • 2 GB RAM
    • LAMP stack
    • Web Application – WordPress 2.7
  • One DB Server
    • CentOS 64-bit
    • 2 GB RAM
    • mySQL 5.0


There were some immediate concerns that we noticed after evaluating the original design:

  • No ability to gracefully scale with traffic demands
  • There was a Public IP connection to DB Server
  • No “root” password set on DB Server
  • No DB backups
  • No Web Server redundancy

While this setup is not all that bad (at least in comparison to a VPS solution), it is not ideal. After we put our heads together, we came up with a much more elegant solution that uses many of the advantages of the Cloud, but also capitalizing on standard high-availability network infrastructures as available on GoGrid.

Optimized Setup

Ideally, when you set up a redundant, high-availability network, you want to eliminate various points of failure as well as optimize the infrastructure to handle demand yet be scalable as well. With traditional or Do-It-Yourself hosting, people frequently either over-buy or under-buy their infrastructure which either wastes times, money and/or resources or cripples you when you are successful and can’t keep up with demand. I recommend that you read Randy Bias’ Whitepaper called “Scaling Your Internet Business” for some scalability insight.

So, what we wanted to achieve with our re-design was something much more secure and reliable. What we came up with is not necessarily a de facto standard, but rather a recommendation and a “how-to-implement” guide. You can obviously do more (e.g., more servers) or take shortcuts. It’s really your call. Here is what we did as a “better” solution.

  • Two Web/Application Servers
    • CentOS 64-bit
    • 1 GB RAM
    • LAMP Stack
    • Web Application – WordPress 2.7
  • One DB Server
    • CentOS 64-bit
    • 2 GB RAM
    • mySQL 5.0
  • GoGrid Cloud Storage
  • F5 Load Balancing


That was the list of GoGrid infrastructure components we ended up using. But HOW and WHY we used these is the important thing to document here. Once again, a quick laundry list:

  • Why Load-Balance? GoGrid offers free F5 Load Balancing. It is very important for a high-availability, redundant web application infrastructure to use a load balancer. It can, based on the configuration, equally spread traffic between all of your web-servers, as well as automatically fail over traffic to a different server should one go down, without downtime or interruption to service.
  • Why use Cloud Storage?There are many reasons why to use Cloud Storage in this type of environment:
    • GoGrid provides 10 GB of free Cloud Storage which can be mounted by your Web, Application and/or DB servers. Free is always nice!
    • Cloud Storage has high-throughput via gigabit connections, redundancy from daily backups and is infinitely scalable. Cloud Storage was GREAT for our solution, because we configured the WordPress environment to actually look at a “symlink”((symbolic-link, like an alias or pointer to another file or directory or location)) on the Web Server that connects to the physical files residing on Cloud Storage.
    • Web Application Clustering – one of the biggest issues with running hosted PHP Web applications (for example), is that you have to keep the PHP files locally on a server. This makes setting up a “clustered” environment much more difficult as you need to update multiple files on multiple servers should you have to change or update code. While you could set up some sort of complex “rsync” session, this gets complicated and potentially confusing. By pointing all of the Web/App Servers to Cloud Storage, the source files (PHP files) are at a single point and much more easy to manage.
    • It can act as a repository for back-ups from DB servers and/or Web servers
  • Why reduce the amount of RAM on the Web/App Servers? Most of the processing power is needed at the database level and not necessarily at the Web/Application level. So, by splitting the RAM out from one 2GB server into two servers with 1GB of RAM each, there is no direct cost impact, yet you gain redundancy. Also, since 10GB of data on Cloud Storage is free, you do not need to use the persistent storage available on the Web/App servers (note: more RAM = larger persistent file storage).
  • Why multiple Servers? First, please see earlier point re: load balancer. GoGrid uses an algorithm to determine which node new Servers are instantiated, ensuring that servers are distributed over different nodes. If a GoGrid node encounters an issue and potentially rendering a server as inaccessible, the load balancer will automatically route traffic to other available servers on different nodes. Since new server instantiations are automatically created on different nodes, the built-in GoGrid redundancy enables high-availability.

So, HOW did we do it all? We have published a very detailed Wiki article titled “How to Set Up a Load Balanced and Redundant Web Application on GoGrid” which goes through the following items (note: the steps listed in the wiki article assume that you have fairly good familiarity with Linux and system administration therein):

There are obvious permutations that can be implemented on top of this design that we have outlined. You could add more Web/App Servers, connect via Cloud Connect to a dedicated or colocated environment, or change the backup timing and strategies, for example.

Also, with the design we wrote, there still remains one important single point-of-failure, that of the MySQL database. Within the next few weeks, we will be compiling a “How To” on setting up a MySQL Replication environment within GoGrid in a Master-Master configuration, using many of the same methodologies outlined within the GoGrid Wiki article. However, assuming that you have fairly strong knowledge of restoring MySQL databases from MySQL dump backups, you can quickly create a new MySQL server and restore data from a previous backup, should you happen across a server failure.

How are you using GoGrid for your Web Applications? Do you have a particular infrastructure implementation that you are proud of? I want to know!

The following two tabs change content below.

Michael Sheehan

Michael Sheehan, formerly the Technology Evangelist for GoGrid, is a recognized technology, social media, and cloud computing pundit and blogger who writes regularly about technology news and trends.

14 Responses to “How To Set Up High Availability Web Applications in the Cloud using GoGrid”

  1. [...] Read more from the original source: How To Set Up High Availability Web Applications in the Cloud … [...]

  2. TheMadHat says:

    Stuck on step 10 of Configuring CentOS Servers to Access Cloud Storage: i've got through to ifup eth1 and when I run ifconfig it's running. however, when I do the route add command it gives me "SIOCADDRT: Network is unreachable"

    I've tried

    route add -net netmask gw [1st private ip]
    route add -net netmask gw [1st private ip] eth1
    route add -net netmask gw [1st private ip] dev eth1

    route command shows two lines for eth1, but no gateway. Can't ping cloud either.


  3. Bryan says:


    I'm not sure if you're running the actual command as written above, but you need to replace [1st private IP] with the first IP available in your private IP block. This is usually a 10.x.x.1 address.



  4. TheMadHat says:

    Seriously? Of course I'm putting in the first private IP. I just didn't want to go look it up when I was typing that. If you must know, like it makes any difference, it's

  5. Bryan says:

    Sorry, I was just making sure. You should be using the first available IP that is visible in your network widget in the GoGrid UI. The .1 address is actually the gateway for your private VLAN. If you look in the network widget in your customer portal, you'll see that we do not display the .1 address. I'll be updating the documentation to reflect that.



  6. TheMadHat says:

    I also tried and – same response. When I called support they told me I should be using .1

  7. [...] How To Set Up High Availability Web Applications in the Cloud using GoGrid [...]

  8. TheMadHat says:

    Support figured out my issue. I had assigned a public IP to eth1 instead of a private IP in ifcfg. Got it pinging cloud. Will update when I'm done with all the steps!

    • Wagner Silva says:

      I'm really new on this businnes ok?! Sorry for the question that comes.
      If I have just one 2Gb server, the installed OS (suppose Win 2008) it's gonna consume about 350Mb of RAM. This way I'll have 1.640Gb to mannage all the users.

      If I have two 1Gb servers, the installed OSs will consume 700Mb of RAM. This way I'll have 1.3Gb to mannage all the users.

      Is this logic correct or I miss something?

      Obs: I told you, I new in this business.

  9. Wagner Silva says:

    This is not supposed to be an REPLY!
    I create a New post under.

  10. Wagner Silva says:

    350 Mb / h = US$ 0.065 / h = US$ 1.56 / day = US$ 10.91 / week = US$ 46.76 / month

    In other words, if I setup two 1Gb servers I will spend more US$ 46.76 per month instead I setup a 2Gb server.
    Or I "invest" US$ 46.76 / month for realibility and split the 2Gb server in two.

  11. Pinaki says:


    Could you please share the solution of replication?

  12. S Ludlow says:

    Where is this wiki? The link… points to nothing and searching for 'how to' on the wiki has 0 search results. GoGrid has no documentation on getting started or best practices.

Leave a reply