Simple Load Balancing on Cloud Servers

By Brandon Woodward, RHCE

In this article, I will walk you through creating a simple software load balancer using our Cloud Servers product. This is an entry-level job using simple readily available packages from any of the distributions repositories. I’ll be using Apache as our load balancer (Apache can be used as many things including a load balancer) in conjunction with the Apache module mod_proxy and mod_proxy_balancer. Both are available through CentOS and I’ll be using this as my base install.

The main thing that I want you to take out of this is that you can use Cloud Servers to scale horizontally. You can only scale a server vertically (i.e. more memory, processor) as a web head so far and eventually you won’t receive better performance from a faster server. This is when you need horizontal expansion and will need to add drone servers behind a smart host, each working a piece of workload.



We are going to use a total of 3 boxes to start out with:

•    One 256M Cloud Server to be used as the load balancer
•    Two Cloud Servers to be used as dumb web heads


The software for all three servers will be the same technically where they will be running the same packages. We’ll throw in only two software groups.

•    Update your system to all the newest goodies:

•    Apache and all its goodies, CentOS makes this ultra simple with the groupinstall feature:

•    I will be installing links to a text based web browser in case we ever need to check that a particular web head is displaying the page it is supposed to be behind the load balancer (this is optional):

Server Configuration

Web Servers

This is going to be the easiest part of the entire configuration. Since the webheads are really just drones, they’re only going to be doing grunt work and need no special configurations. That’s right, you don’t even open the httpd.conf file, just put a file called index.html in /var/www/html/index.html. In this file you can put any distinguishing characteristics you want. I put “It works, you are looking at WebHead #” where # is the numerical identifier of that particular webhead.

Load Balancer

This is the tricky part of the operation. I’ll walk through each step and then bring it together at the end for you so you know what the end product should be. All of the configurations that we are going to go through should be placed at the bottom of /etc/httpd/conf/httpd.conf in a standard Virtual Host to work.

Unwanted Requests

We are not working as a Forwarding Proxy (better known as an Open Proxy, and it’s bad news as it allows people to mask their identity by using your server to view web pages for them, it has its uses but not in this scenario). Turning off ProxyRequests will help avoid any unwanted traffic.

The Balance

In this part of the Virtual Host we will be naming our web heads and declaring how we will be balancing. The BalanceMember directive is how you declare the webheads. Of course you can add as many as you would like, using these as templates. The ProxySet directive declares how you would like to balance. We’re going to use a “byrequest” balancing algorithm which is the same as a Round Robin, so for each new request you will get a new webhead. The order is sequential and although there are better and smarter algorithms out there, this is the easiest to configure and you need no knowledge of networking theory. All of this will be wrapped in <Proxy> tags, which is how Apache knows to send it to mod_proxy. The “balancer://mycluster” identifier is only an identifier although you could technically call it what you want as long as you put the “balancer://” prefix.

Keep in mind you will want to contact your webheads from the load balancer with their private IPs (this will keep your bandwidth charges down to a minimum by keeping all inter server communication between on the private network, where bandwidth is free).

Balance Manager

Optional Step
This is a tool packaged with the mod_proxy_balancer tool and it allows you to make configurations from a gui tool through the web browser. It is viewable at “” Keep in mind that these changes die after you restart Apache. I won’t go over how to use this tool, but it is available to you.


This is the last part of the configuration and just adds the situations that will need to be proxied. We don’t want to proxy the balancer-manager, but we do want to proxy everything else.


If you have all this in your httpd.conf on your load balancer Cloud Server and start up Apache, you should be able to view your domain name that is properly pointed to your load balancer. When you hit refresh it should hop between your two webheads saying, “It works, you are looking at WebHead 1” or “It works, you are looking at WebHead 2.” Congratulations, you are now balancing.

What I have done for you is combine all the things we’ve learned into a helpful packaged VirtualHost. You just need to trade out all the necessary values that are specific to your configuration like the domain name and the IP addresses to your webheads. Also, there are some security additions that are explained in the comments; everything is commented so you don’t have to refer back to this article to make changes later.

Enhanced by Zemanta
  • Was this article helpful ?
  • Yes   No


  1. When using this setup, be sure to use the WORKER MPM (not PREFORK) in the Apache that’s running the load balancer. This will keep your memory utilization low, and will allow you to set sensible concurrency by controlling the number of worker threads on your load balancer.

    Note that PHP only works with PREFORK, so you can’t use WORKER on your web heads if you’re running PHP on them. Don’t attempt to mix and match app servers and load balancers. Use dedicated cloud servers for load balancing, as Brandon did in his example above.

  2. […] is the original post: Rackspace Cloud Computing & Hosting | Simple Load Balancing on … Kontynuuj czytanie » || Napisał dnia: 01.12.09. || Tagi:balance, declare-the-webheads, […]

  3. Out of curiosity, why Apache over a more purpose-built software package like nginx? I’m running several machines behind nginx on Rackspace Cloud Servers and would love to compare notes.

  4. Using Apache as a load balancer is “worst practise”. Apache is known to be one of the easiest “DoSable” daemons. Just check for example the slowloris worm ( Better alternatives are e. g.: squid, HAproxy, nginx and lighttpd. Apache belongs BEHIND a load balancer!

  5. Doesn’t Rackspace limit the network throughput according to the size of your instance? So even if you have larger instances serving the actual pages (which might have 100Mb/s throughput), your site’s throughput will be limited to that of the small 256MB proxy instance on the front (which I think is 10Mb/s).

    Is there anything that can be done about this?

  6. I’d recommend haproxy as a better solution for load balancing. I have this solution running in the cloud with excellent results and using lesser resources (memory and cpu)
    @Mamod: HAProxy and nginx are not affected by slowloris.

  7. How do you deal with the load balancer instance dying? Is there a way to configure something like Amazon’s CloudWatch to restart the node? And how about ensuring you get the same IP so your DNS entries still work?

  8. You really make it appear really easy together with your
    presentation however I to find this matter to be actually one thing which I believe I’d
    by no means understand. It sort of feels too complex and extremely broad for me.
    I am looking ahead on your subsequent put up, I will
    attempt to get the dangle of it!

  9. You really make it appear so easy with your presentation however I to find
    this topic to be really one thing that I think I would by no means
    understand. It seems too complex and extremely large for me.

    I’m having a look forward to your next put
    up, I’ll attempt to get the hold of it!