Configuring Heartbeat links

I’ve heard from the guys at MySQL that the configuration of Heartbeat communication paths in ha.cf seems to be confusing to some. So, here’s our best practice summary:

• Never configure fewer than two communication paths. And I mean, never. Never. If you do, that’s an accident (read: split brain) waiting to happen.
• On the device that you run your DRBD replication over, if it uses a direct back-to-back connection to the peer node (like it should), configure a bcast link. Simple and easy to configure, and since you’re not sharing that link with anything other than DRBD replication, those broadcast packets won’t harm or affect anything else.
• For the device that’s connected to your LAN, use mcast. If you are deploying multiple clusters, make sure you choose a unique multicast address for every cluster. If you don’t, you will get confusing log messages about the node receiving unknown heartbeat packets. Also, don’t accidentally disable multicast traffic on that interface (it’s normally enabled by default).
• Optionally, if you have a direct serial connection available between nodes, add a serial path. Important note: serial links tend to be very flaky if used with Heartbeat 2 CRM-enabled clusters. If for some reason you must use a serial link between two CRM-enabled cluster nodes, be sure to set your baud rate to 115200 and test thoroughly. See the baud option.

Here is a sample configuration (note that eth2 is the DRBD interface, and bond0 is the one connected to the LAN):

mcast bond0 239.0.0.43 694 1 0
bcast eth2
keepalive 2
warntime 15
deadtime 30
initdead 120
crm yes
node joe
node jane

By the way, you needn’t necessarily use a bonding device here. That bond0 might just as well be eth0, eth1, or a even a non-Ethernet device. As long as you can run IP over it, it’s good. This is true for bcast, mcast and ucast links. serial, well, that’ll work only over a serial link.

And, of course, you never, ever want to reuse signing keys (as specified in authkeys) across cluster boundaries. Together with a re-used multicast address, that’s a sure-fire recipe for disaster, so stay away from that. If you’re getting tired of thinking up authentication keys, look here.