Chapter 5. Creating an initial Heartbeat configuration

Table of Contents

5.1. The ha.cf file
5.2. The authkeys file
5.3. Propagating the cluster configuration to cluster nodes
5.4. Starting Heartbeat services
5.5. Where to go from here

For any Heartbeat cluster, the following configuration files must be available:

5.1. The ha.cf file

The following example is a small and simple ha.cf file:

autojoin none
mcast bond0 239.0.0.43 694 1 0
bcast eth2
warntime 5
deadtime 15
initdead 60
keepalive 2
node alice
node bob
pacemaker respawn

Setting autojoin to none disables cluster node auto-discovery and requires that cluster nodes be listed explicitly, using the node options. This speeds up cluster start-up in clusters with a fixed small number of nodes.

This example assumes that bond0 is the cluster’s interface to the shared network, and that eth2 is the interface dedicated for DRBD replication between both nodes. Thus, bond0 can be used for Multicast heartbeat, whereas on eth2 broadcast is acceptable as eth2 is not a shared network.

The next options configure node failure detection. They set the time after which Heartbeat issues a warning that a no longer available peer node may be dead (warntime), the time after which Heartbeat considers a node confirmed dead (deadtime), and the maximum time it waits for other nodes to check in at cluster startup (initdead). keepalive sets the interval at which Heartbeat keep-alive packets are sent. All these options are given in seconds.

The node option identifies cluster members. The option values listed here must match the exact host names of cluster nodes as given by uname -n.

pacemaker respawn enables the Pacemaker cluster manager, and ensures that Pacemaker is automatically restarted in case of a failure.

[Note]Note

Prior to Heartbeat release 3.0.4, the pacemaker keyword was named crm. Newer versions still retain the old name as a compatibility alias, but pacemaker is the preferred syntax.