Highly Available Apache with mod_jk load balanced Tomcat

This how-to describes the procedure for setting up a highly available setup in which a pair of apache servers are load balancing a pair of tomcat servers. I have tested this configuration with Red Hat Enterprise 4, Fedora Core 5, Debian GNU/Linux 3.1 and CentOS 4. Technically this should work on any Unix capable of running apache+mod_jk, tomcat and heartbeat.

Pre-requisites

A pair of linux machine with Apache web server running with the default configuration.

Assumptions

Hostnames – webhst01, webhst02 Domain – Unixclinic.net IP addresses – 192.168.1.1, 192.168.1.2

This is described in another post – Setting Up Tomcat and Apache

Setting up highly available Apache

We need to install “heartbeat” on both the machines for making apache as highly available. Except for Red Hat Enterprise linux, heartbeat is in the package set of Fedora, Debian and CentOS. CentOS packages work on Red Hat enterprise linux.

On Fedora and CentOS

yum install heartbeat

On Debian

apt-get install heartbeat

Configuring heartbeat

With a high availability set-up, its recommended that the heartbeat travels over a separate link. But in my setup, the servers were geographically separate location (in two different data centres) and hence I had to send the heartbeat over standard ethernet link. But this does not make any difference to the working of the servers.

Heartbeat can be configured for active -standby mode or active-active mode. Active-Standby mode – One host remains active for all the HA services (known as primary host) and the other remains standby. Active-Active mode – Service-1 is primary at one node and service-2 primary at second node, so both nodes are active at the same time but offering different services. In case any one of these nodes fails, heartbeat transfer the services to the other host.

/etc/hosts file

In a highly available environment all nodes should be able to see each other irrespective of whether the DNS server is available or not. The /etc/hosts file is typically used in this case. Add the following two lines in the /etc/hosts file in both the hosts.

192.168.1.1 webhst01.unixclinic.net webhst01
192.168.1.2 webhst02.unixclinic.net webhst02

You should be able to ping both servers i.e. both servers should be able to see each other.

/etc/ha.d/ha.cf file

This is the heartbeat configuration file and has to be configured identically on all the nodes of the set-up. Its quite possible that you do not want to exceed more than two nodes in the highly available set-up. If you are sure about that then there is not need to use multicast for heartbeat and unicast can be used. If unicast is used then the only difference between this file in the two nodes is the IP address of the host to unicast to.

# File          - ha.cf
# Purpose       - Heartbeat configuration file
#       ATTENTION: As the configuration file is read line by line,
#               THE ORDER OF DIRECTIVE MATTERS!
# Author        - Ajitabh Pandey
# History       -
#       ver 0.1 -  Created the file on 31st Oct 2006 - AP
#
debugfile /var/log/ha-debug # Debug messages are logged here
logfile /var/log/ha-log     # all heart-beat log messages are stored here
logfacility     local0      # This is the syslog log facility
keepalive 2                 # no of secs between two heartbeats
deadtime 30                 # no of secs after which a host is considered dead if not responding
warntime 10                 # no of secs after which late heartbeat warning will be issued
initdead 120                # After starting up heartbeat no of secs to wait for other
                            # host to respond to heartbeat before considering it dead
udpport 695                 # This is the UDP port for the bcast/ucast communication
bcast   bond0               # this is the interface to broadcast
auto_failback on            # resources are automatically failback to its primary node
node webhst01               # first node in the setup
node webhst02               # second node in the setup

/etc/ha.d/haresources

This file contains a list of all resources being managed by heartbeat and their primary nodes.

I will discuss Active-standby in this post:

Here webhst01 will host the IP address 192.168.1.5 and the httpd and hence any services under this IP address will also be hosted on this. In case this host fails this IP address will be taken over by webhst02.

webhst01.bds.tv 192.168.1.3 httpd

/etc/ha.d/authkeys

This file must be owned, readable and writeable by root only, otherwise heartbeat will refuse to start. Also this file must be same on all the nodes.

auth 1
1 crc

Configuring Apache

httpd.conf

Depending on distribution being used, this file can be present at different locations. Red Hat, Fedora and CentOS will have this file as /etc/httpd/conf/httpd.conf and Debian and derivatives will have this as /etc/apache2/apache2.conf.

We will make apache listen only on the service IP address.

Listen 192.168.1.3:80

I normally use name based virtual hosts, even if there is a single website to be hosted. So I will create a virtual host

<VirtualHost NameVirtualHost *:80>
    ServerName   webhst.unixclinic.net
    ServerAlias  webhst
    ServerAdmin  webmaster@unixclinic.net
    DocumentRoot /var/www/webhst.unixclinic.net
</VirtualHost>

Now since this IP address can be taken over by any machine in the cluster, we have to make sure that apache webserver does not start up automatically on this system.

On Red Hat and derivatives its easy:
chkconfig httpd remove

On Debian and derivatives:

update-rc.d -f apache2 remove && update-rc.d apache2 stop 45 S .

Start heartbeat and do fail-over testing

On Red Hat and derivatives

service heartbeat start

On Debian and derivatives

invoke-rc.d heartbeat start

The activities can be seen in /var/log/ha-log file on both the nodes. Fail-over testing can be done as below:

  1. Shutdown primary node, while keeping the secondary running. Secondary should take over the services when primary goes down.
  2. Bring primary node up while the secondary is running the services, the services should automatically be fallback to primary.
This entry was posted in FLOSS and tagged , , , . Bookmark the permalink.

Leave a Reply