Haresources

Note
In Heartbeat clusters with Pacemaker (aka. the CRM) enabled (see the crm option), haresources is no longer used. Pacemaker uses a different file that is automatically synchronized to all nodes in the cluster.

Details on Pacemaker configuration can be found in the Pacemaker documentation and manual.

Configuring Cluster Services
Once you've got your ha.cf set up, you need to configure haresources. This file specifies the services for the cluster and who the default owner is. The haresources file is one of the most important files to configure when using Heartbeat.

The general form of a line in the haresources file is simple: preferred-node resourcename ...

The list of resources on a line is referred to as a resource group.

The preferred-node is the node that this resource group would prefer to be run on. Continuations of lines can be made with '\' characters at the end of the line.

Heartbeat resources are acquired (started) in a left-to-right order, and released (stopped) in a right-to-left order.

Note that it is absolutely mandatory for the haresources files to be identical on both machines.

This preferred-node is the nominal owner of the resources. That is, this is the machine who will own them if both machines are available and you have selected auto_failback on. A fairly common error is to think that you have to tell each machine to own the same set of resources on both machines. By doing this, you have directed Heartbeat to make each machine owner of the same set of resources, and you wind up with both machines trying to run the same resources at the same time. If you do this, BadThingsWillHappen.

Note: Make sure that the first resource in each resource group is unique because the first resource will be used as resource group name.

Examples
For our example, we'll assume the high availability services are Apache and Samba. The IP for the cluster is mandatory, and don't configure the cluster IP outside of the haresources file!. The haresources will need one line:

linuxha1.linux-ha.org 192.168.85.3 httpd smb So, this line dictates that on startup, have linuxha1 serve the IP 192.168.85.3 and start Apache and Samba as well. On shutdown, Heartbeat will first stop smb, then Apache, then give up the IP. This assumes that the command "uname -n" spits out "linuxha1.linux-ha.org" - yours may well produce "linuxha1" and if it does, use that instead!

Note: httpd and smb are the name of startup scripts for Apache and Samba, respectively. Heartbeat will look for startup scripts of the same name in the following paths:
 * /etc/ha.d/resource.d
 * /etc/init.d

These scripts must start services via "scriptname start" and stop them via "scriptname stop". So you can use any services as long as they conform to the above standard.

Should you need to pass arguments to a custom script, the format would be: scriptname::argument

So, if we added a service "maid" which needed the argument "vacuum", our haresources line would modify to the following: linuxha1 192.168.85.3 httpd smb maid::vacuum This brings us to some added flexibility with the service IP address. We are actually using a shorthand notation above. The actual line could have read (we've canned the maid):

linuxha1 IPaddr::192.168.85.3 httpd smb Where IPaddr is the name of our service script, taking the argument 192.168.85.3. Sure enough, if you look in the directory /etc/ha.d/resource.d, you will find a script called IPaddr. This script will also allow you to manipulate the netmask, broadcast address and base interface of this IP service. To specify a subnet with 32 addresses, you could define the service as (leaving off the IPaddr because we can!):

linuxha1 192.168.85.3/27 httpd smb This sets the IP service address to 192.168.85.3, the netmask to 255.255.255.224 and the broadcast address would default to 192.168.85.31 (which is the highest address on the subnet). The last parameter you can set is the broadcast address. To override the default and set it to 192.168.85.16, your entry would read:

linuxha1 192.168.85.3/27/192.168.85.16 httpd smb You may be wondering whether any of the above is necessary for you. It depends. If you've properly established a net route (independent of Heartbeat) for the service's IP address, with the correct netmask and broadcast address, then no, it's not necessary for you. However, this case won't fit everybody and that's why the option's there! In addition, you may have more than one possible interface that could be used for the service IP. Read on to see how Heartbeat treats this...

Once you straighten out your haresources file, copy ha.cf and haresources to /etc/ha.d and you're ready to start!