Support: 1-800-961-4454
Sales Chat
1-800-961-2888

Simple Load Balancing on Cloud Servers

11

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.

Prerequisites

Hardware

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

Software

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 “http://domain.com/balancer-manager.” 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.

ProxyPass

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.

Summary

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

About the Author

This is a post written and contributed by Brandon Woodward.


More
11 Comments

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.

avatar Adrian Otto [Racker] on November 30, 2009 | Reply

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

avatar Rackspace Cloud Computing & Hosting | Simple Load Balancing on … | ArtykułyNet on November 30, 2009 | Reply

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.

avatar Grant on November 30, 2009 | Reply

[…] Simple Load Balancing on Cloud Servers. Category: […]

avatar Daily Digest for December 1st | piersonthe.net on December 1, 2009 | Reply

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 (http://ha.ckers.org/slowloris/). Better alternatives are e. g.: squid, HAproxy, nginx and lighttpd. Apache belongs BEHIND a load balancer!

avatar Soenke on December 1, 2009 | Reply

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?

avatar scott on December 1, 2009 | Reply

#Soenke, Slowloris doesn’t affect load balancing servers “I guess”

avatar Mamod on December 2, 2009 | Reply

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.

avatar Hector Paz on December 3, 2009 | Reply

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?

avatar msu on December 21, 2009 | Reply

Hi everyone, the latest post has good questions in it… but yet no replies. Anyone?

avatar Christophe Deliens on March 21, 2011 | Reply

MSU: You can prevent failure by setting up two load balancers that have failover capability via Heartbeat. http://www.linux-ha.org/wiki/Heartbeat As for monitoring, you may want to check with Cloud Kick, they have alot of nice monitoring tools for Cloud Servers.

avatar Brandon Woodward on March 24, 2011 | Reply

Leave a New Comment

(Required)


Racker Powered
©2014 Rackspace, US Inc.