This site best when viewed with a modern standards-compliant browser. We recommend Firefox Get Firefox!.

Linux-HA project logo
Providing Open Source High-Availability Software for Linux and other OSes since 1999.

USA Flag UK Flag

Japanese Flag


About Us

Contact Us

Legal Info

How To Contribute

Security Issues

This web page is no longer maintained. Information presented here exists only to avoid breaking historical links.
The Project stays maintained, and lives on: see the Linux-HA Reference Documentation.
To get rid of this notice, you may want to browse the old wiki instead.

1 February 2010 Hearbeat 3.0.2 released see the Release Notes

18 January 2009 Pacemaker 1.0.7 released see the Release Notes

16 November 2009 LINBIT new Heartbeat Steward see the Announcement

Last site update:
2021-01-20 13:41:10

Two Apache Web Servers in an Active/Active Configuration

This configuration is for a high-availability server which provides two IP addresses (, and to be failed over between the nodes of our cluster, and an Apache server for each IP address. We will set this up as an active/active configuration.

/etc/ha.d/ file

logfacility daemon         # Log to syslog as facility "daemon"
node paul silas            # List our cluster members
keepalive 1                # Send one heartbeat each second
warntime  3                # Warn when heartbeats are late
deadtime 10                # Declare nodes dead after 10 seconds
bcast eth0 eth1            # Broadcast heartbeats on eth0 and eth1 interfaces
ping             # Ping our router to monitor ethernet connectivity
auto_failback yes          # Keep resources on their "preferred" hosts - needed for active/active
respawn hacluster /usr/lib/heartbeat/ipfail  # Failover on network failures

See the ipfail page for more information on ipfail.

/etc/ha.d/haresources file

paul  apache::/apache1dir/
silas  apache::/apache2dir/

The first word (paul or silas) on the line represents the "preferred" host for the service. The remainder of the line is the list of resources (services) which are part of this ResourceGroup. In this case, each ResourceGroup consists of only two resources -- an IP address, and the apache web server. is a shorthand notation for IPaddr::, and is a similar shorthand for IPaddr::

Because auto_failback was enabled, when paul joins the cluster it will regain the address. Similarly, when silas joins the cluster, it will regain its ( service address. If an active/passive configuration is desired, then simply change auto_failback to no.

The apache resource agent which comes with Heartbeat supports starting multiple instances of Apache by command-line parameters. The parameter which we've given it tells it where to find its configuration file. So, for our example, we've put the files for the server (normally paul) under /apache1dir, and those for the server (normally silas) under /apache2dir.

/etc/ha.d/authkeys file

/etc/ha.d/authkeys must be mode 600. See the section on GeneratingAuthkeysAutomatically for information how to generate good keys automatically.

auth 1
1 sha1 PutYourSuperSecretKeyHere

Apache Directives

To get the different Apache instances to bind to the correct IP addresses, you have to tell them which IP addresses they should bind to.

This is done by the Apache Listen directive. In /apache1dir/, this directive should be included


In /apache2dir/, this directive should be included


Init Directives

It is important that you not let Apache be started by init at boot time. If you do that, then both init and Heartbeat will "fight" for control of Apache, and it won't work. You have to let Heartbeat control all resources that you include in haresources. To disable Apache from starting at boot time, issue the following command on both paul and silas:

/sbin/chkconfig apache off

or if you're using the httpd service script instead of the apache script:

/sbin/chkconfig httpd off

Special Considerations

For the purposes of this example, we assume that somehow both sets of Apache configuration files, and both web sites content are being "magically" maintained on both machines and are sufficiently similar that no one will complain when failovers occur between nodes. You can use periodic rsync for this if that meets your needs. Alternatively, one can use shared disk or DRBD when they need to be truly identical to the millisecond.