High-availability ad absurdum – instant messenger cluster using DRBD and Finch (Pidgin)

It is often unjustifiable said that implementing high-availability under Linux is way too complex. Of course you will have to be patient while spending some time in learning the required basics – but all this is feasible for an experienced administrator (or someone who wants to be such an administrator some day). This example shows how easy a simple 2-node cluster can be built.

When it is necessary to keep data synchronous between multiple hosts, implementing a DRBD (Distributed Replicated Block Device) might be the most elegant and easiest solution.

You can attach a dedicated LUN to your servers and file the application (which shall be protected using the cluster) on it. In combination with heartbeat, Pacemaker or similiar HA solutions, DRBD is the core of high-available Linux applications.

Ths concept is simple and brilliant at the same time – there are no bounds to the wide range of possibilities like the following slightly escapist example shows.

High-availability ad absurdum

If you’re communicating online you surely know plenty of instant messengers, including the three well-known ones Skype, ICQ and Jabber. To use these protocols also under Linux there are multiprotocol messengers like Pidgin. There is a special version of Pidgin which uses a curses command-line instead of a graphical user interface – Finch. This tools is used as mission-critical application in an active/passive heartbeat cluster in this example. The result is a high-available instant messenger that automatically fails over to another node (in another fire area) without loosing its configuration and data. I’m sure that some readers will now start thinking about how they could live without such an application before. 🙂

AufbauIn this example two Raspberry Pi are used behind two conventional DSL routers. Thanks to a port forwarding (which has to be created equivalently on both routers) it is possible to access those hosts using SSH from “out there” (WAN) – you might want to choose a more secure port instead of the standard port 22. Using a tool named GNU screen a started terminal session running finch can be continued at any time – using this you have access to your personal “chat shell” from every host connected to the internet. Both routers are connected to a IPsec VPN in this example. The Raspberry Pi are able to ping and communicate with each other using a secured tunnel – even though they are in two different network segments.

Using a tool called heartbeat the nodes are checked for availability later – for this mechanism the VPN between the routers is used – another possibility is to implement a point-to-point VPN between the nodes (e.g. using OpenVPN). If a cluster node fails, the other node is informed about the failure and takes over access to the shared storage (discussed later!) and restarts the application as soon as possible (active/passive cluster principle).

Beside the two Raspberry Pi two USB sticks are needed as replicated block device – DRBD doesn’t like pseudo-devices like files created with dd. Application configuration and protocol files of Finch are saved on this “cluster disk” so that the application always has the same data – independent of the node it’s currently running on.

Design and network

For this example I registered a NoIP hostname – after registration the dynamic hostname can be updated using a special Linux utility provided by NoIP. This tool needs to be compiled and installed on the two Raspberry Pi:

both-nodes # apt-get install gcc curl
both-nodes # wget http://www.no-ip.com/client/linux/noip-duc-linux.tar.gz
both-nodes # tar xfz noip-duc-linux.tar.gz
both-nodes # cd noip-*
both-nodes # make && make install
Please enter the login/email string for no-ip.com  
Please enter the password for user '...'  ***
Please enter an update interval:[30]  44640

By default, the NoIP client is running in the background – and that’s exactly what we don’t want in this cluster setup. The IP needs to be updated in case of a failover performed by heartbeat. If the applications fails over from one node to another the hostname needs to be updated to ensure that access to the correct node is possible. Testing the compiled tool is necessary to guarantee that it is working as expected:

any-node # /usr/local/bin/noip2 -i $(curl --silent http://icanhazip.com)
any-node # ping chat.noip.com

Additional packages for drbd and heartbeat have to be installed:

both-nodes # apt-get install drbd8-utils heartbeat


Before the shared cluster storage is created, it is necessary to ensure that the both nodes are able to communicate with each other. It is recommended to create a local entry in the /etc/hosts file (to be independent of a possibly faulty DNS service) – even if you have a working DNS. After that pinging the nodes has to work:

both-nodes # vi /etc/hosts
....   hostA.fqdn.dom hostA   hostB.fqdn.dom hostB


node-a # ping hostA
node-a # ping hostB
node-b # ping hostA
node-b # ping hostB

The connected USB sticks are re-partitioned (existing partitions are removed) – a Linux partition (type 83) is created. After that the DRBD configuration file is altered:

both-nodes # fdisk /dev/sda < < EOF



both-nodes # cp /etc/drbd.conf /etc/drbd.conf.initial
both-nodes # vim /etc/drbd.conf
resource drbd1 {
  protocol C;

  syncer {
    rate 75K;
    al-extents 257;
  on hostA.fqdn.dom {
    device    /dev/drbd1;
    disk      /dev/sda1;
    meta-disk internal;
  on hostA.fqdn.dom {
    device    /dev/drbd1;
    disk      /dev/sda1;
    meta-disk internal;


A volume drbd1 which is respectively synchronized to the device /dev/sda1 on the nodes hostA.fqdn.com and hostB.fqdn.com is defined.

The following line is very important:

rate 75K;

This line defines the maximal synchronization rate in byte per second – in this case 75 KB/s. The synchronization is speed depends on different factors and shall be choosed carefully. For example, the defined speed rate should not exceed the maximal speed provided by the used storage medium. If DRBD and application use the same network segment (it is better to have an additional network for DRBD) you will have to consider the needs of the other network traffic.

A rule of thumb is to set the value of syncer rate to the 0.3 times of the effective network bandwidth – there is an example in the drbd handbook:

110 MB/s bandwidth * 0.3 = 33 MB/s
syncer rate = 33M;

If the network isn’t able to provide the definied maximal speed the speed is automatically throttled. More information about synchronization can be found in the handbook of DRBD: [click me!].

Afterwards the volume is created, activated and formatted on one node. After this, the new volume is mounted:

node-a # drbdadm create-md drbd1

==> This might destroy existing data! < ==
Do you want to proceed? [need to type 'yes' to confirm] yes ...

node-a # drbdadm up drbd1
node-a # drbdadm primary drbd1
node-a # mkfs.ext4 /dev/drbd1
both-nodes # mkdir /finch
node-a # mount /dev/drbd1 /finch

The changes are catched up on the other node – this can take some time for the first initialization (time for a coffee!). In my case the initialization of a 256 MB USB stick took about one hour using a VPN with 75 kbit/s upload rate. The status can be seen by reading the file /proc/drbd:

node-b # drbdadm connect drbd1
node-b # uptime
 16:40:30 up  2:08,  1 user,  load average: 0,20, 0,16, 0,10

both-nodes # cat /proc/drbd
version: 8.3.13 (api:88/proto:86-96)
srcversion: A9694A3AC4D985F53813A23

 1: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r-----
    ns:0 nr:104320 dw:104320 dr:0 al:0 bm:6 lo:1 pe:2321 ua:0 ap:0 ep:1 wo:f oos:148564
        [=======>............] sync'ed: 42.0% (148564/252884)K
        finish: 0:32:11 speed: 64 (24) want: 71,680 K/sec

Once the synchronization is finished, it is necessary to check whether changes are replicated and roles can be switched. To check this, the following tasks are executed:

  • creating a file on the primary DRBD node, creating MD5 sum
  • unmounting the file system, downgrading to secondary role
  • upgrading the second DRBD node, mounting file system
  • find file, check MD5 sum
  • delete file and create another file
  • resetting the roles

In this example only the primary node is able to access the volume exclusively, the secondary node has no access to the volume. If you want both nodes to be able to access the volume (e.g. if you’re implementing an active/active cluster) ext4 is not the file system to choose. In such a scenario you will have to choose a cluster filesystem like GFS or OCFS2. These filesystems offer special locking mechanisms to manage the access to the volume for the individual nodes.

node-a # dd if=/dev/zero of=/finch/bla.bin bs=1024k count=1
node-a # md5sum /finch/bla.bin > /finch/bla.bin.md5sum
node-a # umount /finch
node-a # drbdadm secondary drbd1

node-b # drbdadm primary drbd1
node-b # mount /dev/drbd1 /finch
node-b # ls /finch
lost+found    bla.bin    bla.bin.md5sum
node-b # md5sum -c /finch/bla.bin.md5sum
/finch/bla.bin: OK
node-b # rm /finch/bla.bin*
node-b # dd if=/dev/zero of=/finch/foo.bin bs=1024k count=1
node-b # md5sum /finch/foo.bin > /finch/foo.bin.md5sum
node-b # umount /finch
node-b # drbdadm secondary drbd1

node-a # drbdadm primary drbd1
node-a # mount /dev/drbd1 /finch
node-a # ls /finch
lost+found    foo.bin    foo.bin.md5sum
node-a # md5sum -c /finch/foo.bin.md5sum
/finch/foo.bin: OK

Seems to work like a charm! 🙂


Like mentioned before, the multi-protocol messenger Finch (Pidgin) is used as mission-critical application in this scenario. It is a proper behaviour to provide a dedicated service user and a unique UID in order to ensure that the application can be started in a script executed by heartbeat on a node afterwards. To start the tool in the background and enable it to be access remotely, GNU Screen is used as terminal multiplexer.

both-nodes # apt-get install screen finch
both-nodes # useradd -u 1337 -m -d /finch/home su-finch
both-nodes # gpasswd -a su-finch tty
both-nodes # passwd su-finch

Adding the user su-finch to the group tty is necessary to ensure that GNU screen is able to access the terminal if it is started using the su mechanism.

First of all finch can be configured to use an instant messenger account:

node-a # su - su-finch
node-a # screen
node-a # finch

finch (curses)If you have used Pidgin before, you might recognize the buddy list and chat windows.

Windows are switched using key combinations – in combination with GNU screen it is also possible to use mouse navigation. Some important pre-defined key combinations:

  • next window: ALT + N
  • previous window: ALT + P
  • close selected window: ALT + C
  • open context menu: F11
  • open action menu: ALT + A
  • open menu of current window: CTRL + P

heartbeat – computer, are you still alive?

heartbeat is – as its name implies – primarly used for ensuring the availability of the particular cluster nodes. The tool communicates constantly with neighbor cluster nodes using a encrypted tunnel and is able to react fast on failures. If such a failure occurs. pre-defined scripts are executed to compensate the failure. In this example two cluster resources are restarted on the next available node: the shared DRBD storage and the service finch.

STONITHIt might be necessary in a cluster to ensure that faulty nodes wont continue serving their services (depending on size and application) to avoid data corruption and service misfunction. This mechanism is called STONITH (Shoot the other node in the head). There are plenty of interfaces which can be used to make sure that the faulty cluster node “keeps down” – for example:

  • servers remote interface (iLO, DRAC, LOM,…)
  • UPS the server is connected to
  • PDU (Power Distribution Unit) the cluster node is consuming power from
  • blade enclosure management interface

If STONITH is not used, data corruption and application failure might occure in extreme cases when both cluster nodes are hold that they are the only active node and run the application (e.g. because of a network failure). Of course STONITH can also be implemented under Linux – amongst others using heartbeat or Pacemaker. But in this example, this would go beyond the scope of this well-arranged scenario. 😉

Applications can be served in a cluster using heartbeat very easy because conventional init scripts are used for service management. In an ideal case symbolic links can be used to integrate a service into a cluster.

In this example an used-defined init script which starts Finch and updates the NoIP hostname is created.

First of all, a cluster-wide configuration file (/etc/ha.d/ha.cf) is created. This configuration file includes essential parameters like log files and thresholds:

node-a # vi /etc/ha.d/ha.cf
debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility local0
keepalive 10
deadtime 30
warntime 20
initdead 60
ucast eth0
udpport 694
auto_failback off
node hostA.fqdn.dom
node hostB.fqdn.dom


node-b # vi /etc/ha.d/ha.cf
ucast eth0


The file differs between the nodes in one line (ucast) – the appropriate IP address of the other node is used.

Some explanations of the individual parameters:

  • debugfile / logfile / logfacility – debug- and generic log, used Syslog facility
  • keepalive – time frame keepalives are sent
  • warntime – time frame nodes are threaten to fail
  • deadtime – time frame a node seems to be dead
  • initdead – time frame a node is removed from the cluster
  • ucast – IP address, unicast heartbeat packages are sent to
  • udpport – UDP port
  • auto_failback – defines whether failed cluster nodes shall receive their former resources (if they were preferred nodes for particular resources)
  • node – defines the given cluster nodes

Because the cluster communication is done encrypted, a file /etc/ha.d/authkeys has to be created on both nodes.:

both-nodes # vi /etc/ha.d/authkeys
auth 1
1 sha1 verylongandultrasavepasswordphrase08151337666

Afterwards the cluster resources are mentioned in the file /etc/ha.d/haresources:

both-nodes # vi /etc/ha.d/haresources
hostB.fqdn.dom  drbddisk::drbd1 Filesystem::/dev/drbd1::/finch::ext4    finch

This file lists all available cluster nodes and – separated using a tab – preferred resources. In this example there are two hosts, the second one is the primary cluster node for the following resources:

  • exclusive used DRBD volume drbd1
  • ext4 file system on /dev/drbd1, mounted as /finch
  • the service finch (/etc/init.d/finch)

This means: if both cluster nodes are available, the above mentioned resources are always running on node 2 (hostB.fqdn.dom). If this node fails, the resouces are restarted on node 1 (hostA.fqdn.dom). Automatic resource restarting after the failed cluster node becomes available again is avoided because of the setting “auto_failback off” (in the file /etc/ha.d/ha.cf).

At last the init script for starting and stopping the finch service needs to be created – like other init scripts, this script is created under /etc/init.d/finch:

# vi /etc/init.d/finch
# finch        Startup script for finch including noip update

start() {
        /usr/local/bin/noip2 -i $(curl --silent http://icanhazip.com) >/dev/null 2>&1
        chmod g+rw $(tty)
        su -c "screen -d -m" su-finch
        return $RESULT
stop() {
        /usr/bin/killall -u su-finch
        return $RESULT
status() {
        su -c "screen -ls" su-finch
        cat /proc/drbd
        dig +short foo.noip.com
        return $RESULT

case "$1" in
        echo $"Usage: finch {start|stop|status}"
        exit 1

exit $RESULT

This init script recognizes the parameters start, stop and status – it might almost be LSB-compatible. 🙂

Depending on the parameter a GNU screen sessing is started or stopped using the user account of su-finch (service user) – the status parameter lists current DRBD and IP mappings including current sessions.

Whenever heartbeat starts or stops finch ressources, this script is used.

Function test

Ok, this sounds nice – but is it working at all?

Of course it is – the following video shows a demonstration of cluster failover:



Clusternode-Überwachung mit IcingaIt is a proper behaviour to monitor a mission-criticial application. Beside the availability of the appropriate cluster nodes, the state of DRBD and heartbeat is of note, too. While the availability of the heartbeat service can be checked easily using the Nagios/Icinga plugin check_procs, there is a special shell script for DRBD (free to download) on the website MonitoringExchange: [click me!]

This script can be included into Nagios or Icinga and used easily, e.g. in this example on a passive Icinga instance:

# cat /etc/icinga/commands.cfg
# 'check_drbd' command definition
define command{
        command_name    check_drbd
        command_line    $USER2$/check_drbd -d $ARG1$ -e "Connected" -o "UpToDate" -w "SyncingAll" -c "Inconsistent"

# cat /etc/icinga/objects/hostA.cfg
define service{
        use                             generic-service
        host_name                       hostA
        service_description             HW: drbd1
        check_command                   check_drbd!1

In this example the available of the DRBD volume /dev/drbd1 is checked. If the script answer (based on the content of the file /proc/drbd) is not “Connected/UpToDate“, a failure has occured. If the volume is synchronizing (SyncingAll), Nagios/Icinga reports a warning – an inconsistent volume (Inconsistent) forces a critical event.


It is no doubt that this scenario is rather escapist than realistic – it is just for fun. I just wanted to show how easy implementing high-availability under Linux can be. There are many ways to get it working – heartbeat and DRBD is only one of many HA constellations. The topic isn’t that complex as often unjustifitable said. In the first step it is irrelevant whether a database or an instant messenger is “clustered” using heartbeat – the implementation effort is manageable.

heartbeat is said to be obsolete – Pacemaker and OpenAIS/Corosync are two more modern utitilies that can be used in combination with DRBD to implement more complex and larger HA scenarios.

As a matter of principle hardware components should be designed redundant before implementing software HA solutions. In this example, there are some architecture mistakes that should be fixed in case of practical application:

  • no dedicated network for node communication (heartbeat network)
  • no redundant storage for cluster storage (RAID volume)
  • network adapters are not redundant (no double NICs/teaming or appropriate connected switches; LACP?)
  • no redundant power supply

At least dedicaded fire areas had been chosen for this scenario (the Raspberry Pi are located in two different flats)! 🙂

However – if you’re interested in keeping your instant messenger redundant, you know how to do this now. 😉

Sharing is caring

Leave a Reply