ubuntu,debian,redhat -linuxany.com

Setting Up A High-Availability Load Balancer (With Failover and Session Support) With HAProxy/Heartbeat On Debian Etch

This article explains how to set up a two-node load balancer in an active/passive configuration with HAProxy and heartbeat on Debian Etch. The load balancer sits between the user and two (or more) backend Apache web servers that hold the same content. Not only does the load balancer distribute the requests to the two backend Apache servers, it also checks the health of the backend servers. If one of them is down, all requests will automatically be redirected to the remaining backend server. In addition to that, the two load balancer nodes monitor each other using heartbeat, and if the master fails, the slave becomes the master, which means the users will not notice any disruption of the service. HAProxy is session-aware, which means you can use it with any web application that makes use of sessions (such as forums, shopping carts, etc.).

From the HAProxy web site: “HAProxy is a free, very fast and reliable solution offering high availability, load balancing, and proxying for TCP and HTTP-based applications. It is particularly suited for web sites crawling under very high loads while needing persistence or Layer7 processing. Supporting tens of thousands of connections is clearly realistic with todays hardware. Its mode of operation makes its integration into existing architectures very easy and riskless, while still offering the possibility not to expose fragile web servers to the Net.”

I do not issue any guarantee that this will work for you!

1 Preliminary Note
In this tutorial I will use the following hosts:

We also need a virtual IP address that floats between lb1 and lb2: 192.168.0.99
Here’s a little diagram that shows our setup:

The shared (virtual) IP address is no problem as long as you’re in your own LAN where you can assign IP addresses as you like. However, if you want to use this setup with public IP addresses, you need to find a hoster where you can rent two servers (the load balancer nodes) in the same subnet; you can then use a free IP address in this subnet for the virtual IP address. Here in Germany, Hetzner is a hoster that allows you to do this – just talk to them.

http1 and http2 are standard Debian Etch Apache setups with the document root /var/www (the configuration of this default vhost is stored in /etc/apache2/sites-available/default). If your document root differs, you might have to adjust this guide a bit.

To demonstrate the session-awareness of HAProxy, I’m assuming that the web application that is installed on http1 and http2 uses the session id JSESSIONID.

2 Preparing The Backend Web Servers
We will configure HAProxy as a transparent proxy, i.e., it will pass on the original user’s IP address in a field called X-Forwarded-For to the backend web servers. Of course, the backend web servers should log the original user’s IP address in their access logs instead of the IP addresses of our load balancers. Therefore we must modify the LogFormat line in /etc/apache2/apache2.conf and replace %h with %{X-Forwarded-For}i:

http1/http2:

Also, we will configure HAProxy to check the backend servers’ health by continuously requesting the file check.txt (translates to /var/www/check.txt if /var/www is your document root) from the backend servers. Of course, these requests would totally bloat the access logs and mess up your page view statistics (if you use a tool like Webalizer or AWstats that generates statistics based on the access logs).

Therefore we open our vhost configuration (in this example it’s in /etc/apache2/sites-available/default) and put these two lines into it (comment out all other CustomLog directives in your vhost configuration):

This configuration prevents that requests to check.txt get logged in Apache’s access log.

Afterwards we restart Apache:

… and create the file check.txt (this can be an empty file):

We are finished already with the backend servers; the rest of the configuration happens on the two load balancer nodes.

3 Installing HAProxy
Unfortunately HAProxy is available as a Debian package for Debian Lenny (testing) and Sid (unstable), but not for Etch. Therefore we will install the HAProxy package from Lenny. To do this, open /etc/apt/sources.list and add the line deb http://ftp2.de.debian.org/debian/ lenny main; your /etc/apt/sources.list could then look like this:

lb1/lb2:

Of course (in order not to mess up our system), we want to install packages from Lenny only if there’s no appropriate package from Etch – if there are packages from Etch and Lenny, we want to install the one from Etch. To do this, we give packages from Etch a higher priority in /etc/apt/preferences:

(The terms etch and lenny refer to the appropriate terms in /etc/apt/sources.list; if you’re using stable and testing there, you must use stable and testing instead of etch and lenny in /etc/apt/preferences as well.)

Afterwards, we update our packages database:

… upgrade the installed packages:

… and install HAProxy:

4 Configuring The Load Balancers
The HAProxy configuration is stored in /etc/haproxy.cfg and is pretty straight-forward. I won’t explain all the directives here; to learn more about all options, please read http://haproxy.1wt.eu/download/1.3/doc/haproxy-en.txt and http://haproxy.1wt.eu/download/1.2/doc/architecture.txt.

We back up the original /etc/haproxy.cfg and create a new one like this:

lb1/lb2:

Afterwards, we set ENABLED to 1 in /etc/default/haproxy:

5 Setting Up Heartbeat
We’ve just configured HAProxy to listen on the virtual IP address 192.168.0.99, but someone has to tell lb1 and lb2 that they should listen on that IP address. This is done by heartbeat which we install like this:

lb1/lb2:

To allow HAProxy to bind to the shared IP address, we add the following line to /etc/sysctl.conf:

… and run:

Now we have to create three configuration files for heartbeat, /etc/ha.d/authkeys, /etc/ha.d/ha.cf, and /etc/ha.d/haresources. /etc/ha.d/authkeys and /etc/ha.d/haresources must be identical on lb1 and lb2, and /etc/ha.d/ha.cf differs by just one line!

lb1/lb2:

somerandomstring is a password which the two heartbeat daemons on lb1 and lb2 use to authenticate against each other. Use your own string here. You have the choice between three authentication mechanisms. I use md5 as it is the most secure one.

/etc/ha.d/authkeys should be readable by root only, therefore we do this:

lb1/lb2:

lb1:

Important: As nodenames we must use the output of

on lb1 and lb2.

The udpport, bcast, mcast, and ucast options specify how the two heartbeat nodes communicate with each other to find out if the other node is still alive. You can leave the udpport, bcast, and mcast lines as shown above, but in the ucast line it’s important that you specify the IP address of the other heartbeat node; in this case it’s 192.168.0.101 (lb2.example.com).

On lb2 the file looks pretty much the same, except that the ucast line holds the IP address of lb1:

lb2:

lb1/lb2:

The first word is the output of

on lb1, no matter if you create the file on lb1 or lb2! It is followed by our virtual IP address (192.168.0.99 in our example).

Finally we start heartbeat on both load balancers:

lb1/lb2:

Then run:

lb1:

… and you should find that lb1 is now listening on the shared IP address, too:

You can check this again by running:

As lb2 is the passive load balancer, it should not be listening on the virtual IP address as long as lb1 is up. We can check that with:

lb2:

The output should look like this:

The output of

shouldn’t display the virtual IP address either:

6 Starting HAProxy
Now we can start HAProxy:

lb1/lb2:

7 Testing
Our high-availability load balancer is now up and running.

You can now make HTTP requests to the virtual IP address 192.168.0.99 (or to any domain/hostname that is pointing to the virtual IP address), and you should get content from the backend web servers.

You can test its high-availability/failover capabilities by switching off one backend web server – the load balancer should then redirect all requests to the remaining backend web server. Afterwards, switch off the active load balancer (lb1) – lb2 should take over immediately. You can check that by running:

lb2:

You should now see the virtual IP address in the output on lb2:

The same goes for the output of

When lb1 comes up again, it will take over the master role again.

8 HAProxy Statistics
You might have noticed that we have used the options stats enable and stats auth someuser:somepassword in the HAProxy configuration in chapter 4. This allow us to access (password-protected) HAProxy statistics under the URL http://192.168.0.99/haproxy?stats.

If you don’t need the statistics, just comment out or remove the stats lines from the HAProxy configuration.

您还可能感兴趣的内容

• 负载均衡软件比较(HA/LVS/Nginx)
• Heartbeat CRM模式
• apache优化列表
• Apache 记录代理后的用户来源ip
• LVS DR模式修改超时时间