Failover Services with CARP

    Brief introduction

    The protocol itself is very well written on Wikipedia. Anyone interested in details and history - there . In a nutshell, we can say this: it is a redundancy protocol that allows two or more computers on the same subnet to have the same IP address at the same time, and it is possible to configure this group of computers as interchangeable (the main computer is disconnected / broken - instead, immediately but it is taken for work by another, whose priority is higher) and so on in a circle, thereby ensuring almost 100% accessibility of services. CARP is native to OpenBSD, FreeBSD, and NetBSD. On Linux with a kernel above 2.4 it is available through ucarp.

    A bit messy, but in the future, I hope, the situation will become clearer.


    For this description, I used Debian GNU / Linux 4.0 under VMWare ESX. We will test the Apache web server service.

    Start. Installation

    First of all, put ucarp. Under Debian everything is extremely simple:

    apt-get install ucarp

    Installing from sorts should not cause too much difficulty

    tar jxf ucarp-1.2.tar.bz2
    cd ucarp-1.2
    make install

    At the same time, we set up a web server

    apt-get install apache2

    UCARP Configuration

    The main part of the configuration is common for both the wizard and the slave (

    we will consider the differences separately) First of all, create a .conf file in which we write the parameters for starting ucarp and the configuration of virtual interfaces

    mkdir /etc/ucarp
    touch /etc/ucarp/ucarp.conf


    # Интерфейс на котором будет запущен ucarp

    # Виртуальный интерфейс которому будет присвоен виртуальный ip кластера

    # Действительный ip интерфейса. Естественно для каждого узла он будет своим.

    # CARP ID виртуального сервера

    # Интервал для сравнения узлов, в секундах.
    # Чем он меньше, тем выше приоритет слейва

    # Пароль дла hmac шифрования соединения (посредством sha1).

    # Виртуальный ip по которому будет доступен кластер

    # Маска нашего сегмента сети

    # Путь к скриптам которые будут запущены при активации/деактивации узла

    Now it's time to write scripts that will raise the virtual interface when management (wizard status) will go to the current host and vice versa.

    cd /etc/ucarp
    touch ./
    touch ./


    source /etc/ucarp/ucarp.conf


    source /etc/ucarp/ucarp.conf
    ifconfig $UCARP_IF_ALIAS down will be launched when the node is activated. Parameters for the alias, virtual interface, address and mask are taken from the ucarp.conf file. As soon as the node loses the status of the master, starts and the virtual interface shuts down.

    The next step is to create a script to launch UCARP itself (alternatively, you can create an init script). We call the script and put it in / etc / ucarp.

    source /etc/ucarp/ucarp.conf

    ucarp /
    --interface=$UCARP_INTERFACE /
    --srcip=$UCARP_SRCIP /
    --vhid=$UCARP_VHID /
    --pass=$UCARP_PASS /
    --advbase=$UCARP_ADVBASE /
    --preempt /
    --addr=$UCARP_ADDR /
    --daemonize /
    --upscript=$UCARP_UPSCRIPT /

    The first line connects our ucarp.conf config, all variables are taken from there. The --daemonize option starts UCARP in daemon mode. An important option is --preemt which will be present only for the wizard. The last step is to make our scripts run from under the root

    chmod 0700 /etc/ucarp/*.sh

    To start testing, I cloned MasterVm and made changes to the following parameters

    - ip address
    - Hostname
    - UCARP_SRCIP in /etc/ucarp/ucarp.conf

    also in the file /var/www/apache2-default/index.html indicated the name of the server to know which node I get to.


    Launch the wizard and slave using the script /etc/ucarp/ Since we specified the --daemonize option, no messages will be displayed. Through ifconfig on the wizard we see the launched virtual interface:

    eth0 Link encap: Ethernet HWaddr 00: 22: 15: 6a: 80: d8
              inet addr: Bcast: Mask:
              inet6 addr: fe80 :: 250: 56ff: fe82: 352c / 64 
              UP BROADCAST RUNNING MULTICAST MTU: 1500 Metric: 1
              RX packets: 402618 errors: 0 dropped: 0 overruns: 0 frame: 0
              TX packets: 9019 errors: 0 dropped: 0 overruns: 0 carrier: 0
              collisions: 0 txqueuelen: 1000
              RX bytes: 34064624 (32.4 MiB) TX bytes: 623570 (608.9 KiB)
              Interrupt: 177
    eth0: 0 Link encap: Ethernet HWaddr 00: 22: 15: 6a: 80: d8
              inet addr: Bcast: Maske:
              UP BROADCAST RUNNING MULTICAST MTU: 1500 Metric: 1
              Interrupt: 177

    There is no virtual interface on the slave, of course, it will only be launched when the status of the master is transferred. The ucap node status is written to / var / log / syslog. It looks something like this:

    On the master:

    Nov 26 03:49:17 vmdebian01 ucarp[2327]: [WARNING] Switching to state: MASTER
    Nov 26 03:49:17 vmdebian01 ucarp[2327]: [WARNING] Spawning [/etc/ucarp/ eth0]

    On the slave

    Nov 26 03:50:24 vmdebian02 ucarp[3802]: [WARNING] Switching to state: BACKUP
    Nov 26 03:50:24 vmdebian02 ucarp[3802]: [WARNING] Spawning [/etc/ucarp/ eth0]

    When accessing the virtual ip, we find ourselves on server number 1 (running as a master). When the wizard is disconnected from the network, the slave immediately changes its status and launches an interface that is accessible via the ip / mac cluster. The reloading of the page in the browser shows that we are already on server number 2. When the wizard is connected, everything returns to its place.


    Of course, all of the above is a simplified version of the ucarp configuration. in real life, you’ll also have to think about synchronizing the level of applications, sessions if it is a web server, files in case of ftp, etc.

    Also popular now: