Abbildung 1: Ein Blick ins Syslog der Slave-Maschine verrät: Nach Ausfall des Produktivservers ist sie der Master.

Wichtige Daemons hält Sysadmin-Kolumnist Charly Kühnast gern auf zwei oder mehr Servern vor. Fällt einer davon aus, soll der Dienst auf dem zweiten Server starten und unter der gleichen IP-Adresse erreichbar sein – ein Szenario, das auch ohne den Herzschlag von Pacemakers auskommt.

Diensten, ohne die so ziemlich alles andere auch ausfällt, gönne ich gerne einen Doppelgänger. Wenn der Master irgendwann ausfällt oder wenn ich schlicht den zugehörigen Server zur Wartung herunterfahre, soll der Dienst auf dem zweiten Server automatisch starten und möglichst unter der gleichen IP-Adresse erreichbar sein wie vorher.

Dazu muss diese IP-Adresse schnell und ohne viel Aufwand auf die Ersatzmaschine umziehen. Solche Adressen nennt man Floating-IPs. Als Umzugsunternehmer käme das Duo Pacemaker und Corosync [1] in Betracht. Aber die beiden können sehr viel mehr als das, sodass sie mir für das simple Failover-Szenario überdimensioniert erscheinen.

Denn es geht auch eine Nummer kleiner, etwa mit Keepalived [2], das zum Standardumfang vieler Distributionen gehört und sich auch auf der Delug-DVD findet. Also installiere ich Keepalived und gehe direkt in medias res. Dort warten zwei Server mit den IP-Adressen 10.0.0.1 und 10.0.0.2 auf mich. Meine Floating-IP soll 10.0.0.100 sein.

Der kleine Unterschied

Die Konfigurationsdatei »/etc/keepalived/keepalived.conf« sieht wie in Listing 1 aus. Sie unterscheidet sich auf beiden Maschinen nur in einer Kleinigkeit: in der Zeile »priority« . Hier muss ich auf einem der beiden Server eine kleinere Zahl eintragen als bei der anderen, um klarzustellen, wer der Master ist. Dieser Server erhält per Default die Floating-IP, der andere bekommt sie nur, wenn der Master nicht erreichbar ist. Zum Austausch des Status dient das Protokoll VRRP (Virtual Router Redundancy Protocol).

Um Dienste an eine IP binden zu können, die auf dem System (noch) nicht existiert, ist es erforderlich, die »/etc/sysctl.conf« zu ändern:

sudo echo "net.ipv4.ip_nonlocal_bind = 1" >> /etc/sysctl.conf
sudo sysctl -p

Jetzt kann ich Keepalived mit »sudo service keepalived start« starten. Die Floating-IP erscheint auf dem Server mit dem höheren »priority« -Wert. Fahre ich den Server herunter, kann ich im Syslog der sekundären Maschine beobachten, wie sie in die Rolle des Master schlüpft (siehe Abbildung 1).

Abbildung 1: Ein Blick ins Syslog der Slave-Maschine verrät: Nach Ausfall des Produktivservers ist sie der Master.

01 ! Configuration File for keepalived
02
03 global_defs {
04    notification_email {
05      charly@kuehnast.com
06    }
07    notification_email_from ha_test@kuehnast.com
08    smtp_server localhost
09    smtp_connect_timeout 30
10 }
11
12 vrrp_instance VI_1 {
13     state MASTER
14     interface eth0
15     virtual_router_id 51
16     priority 100
17     advert_int 1
18     authentication {
19         auth_type PASS
20         auth_pass meinpasswort
21     }
22     virtual_ipaddress {
23         10.0.0.100
24     }
25 }

Der Autor

Charly Kühnast administriert Unix-Systeme im Rechenzentrum Niederrhein. Zu seinen Aufgaben gehören Sicherheit und Verfügbarkeit der Firewalls und der DMZ.