Inhaltsverzeichnis

DRBD: Ausfall eines Nodes

Note: Ausgangslage dieses Tutorials ist das aus dem Tutorial DRBD: RAID1 über LAN erstellte Setup, zweier »DRBD-Nodes«.

Timing Trouble

Mit einem ganz anderen Problem hatte ich im Vorfeld zu kämpfen. Nach einem Neustart eines beliebigen Nodes, wurde das im LAN verteilte DRBD-Volume nicht wieder automatisch hergestellt. Sollte es aber, zumindest mindestens dann, wenn der »Secondary Node« neu gestartet wurde. Statt dessen wurde ich beim Booten des »Secondary Nodes« mit folgender Meldung konfrontiert:

»block drbd0: bind before connect failed, err = -99«

und im Syslog findet sich passend dazu noch etwas mehr Information:

/var/log/syslog

Dec 30 15:26:43 server2 kernel: [    4.164983] block drbd0: conn( StandAlone -> Unconnected ) 
Dec 30 15:26:43 server2 kernel: [    4.165011] block drbd0: Starting receiver thread (from drbd0_worker [1399])
Dec 30 15:26:43 server2 kernel: [    4.166285] block drbd0: receiver (re)started
Dec 30 15:26:43 server2 kernel: [    4.166286] block drbd0: conn( Unconnected -> WFConnection ) 
Dec 30 15:26:43 server2 kernel: [    4.166289] block drbd0: bind before connect failed, err = -99
Dec 30 15:26:43 server2 kernel: [    4.166345] block drbd0: conn( WFConnection -> Disconnecting )

Sollte eigentlich nicht sein1) und es hat mich einen ganzen Abend gekostet darauf zu kommen, was das Problem sein könnte. Nachdem ich stundenlang mit den Möglichkeiten zur automatischen Auflösung eines Split-Brains2) experimentiert habe (»after-sb-0pri«, »after-sb-1pri«, »after-sb-2pri«) bin ich dann darauf gekommen, dass der DRBD-Daemon einfach zu früh startet und noch bevor das Netzwerk zur Verfügung steht versucht wird, den Replikationspartner zu kontaktieren.

Obwohl das Init-Skript von DRBD »/etc/init.d/drbd« einen korrekten LSB-Header3) besitzt und ich die Startreihenfolge manuell auf ganz zum Ende in Runlevel 2 gesetzt habe…: 

root@server1:/etc/rc2.d# mv S19drbd S99drbd

…hat mir vermutlich der DHCP Server in Verbindung mit meinen VMs auf SSD Platten in die Suppe gespuckt. Das Teil bootet einfach so schnell, dass es vom DHCP Server noch keine IP-Adresse bekommen hat, bevor der DRBD-Daemon startet. Abhilfe hat jetzt ein »sleep 5« Kommando im Init-Skript »/etc/init.d/drbd« geschaffen, welches die weitere Ausführung des Skripts für fünf Sekunden anhält… Mann Mann.

/etc/init.d/drbd

#!/bin/bash
#
# chkconfig: - 70 08
# description: Loads and unloads the drbd module
#
# Copright 2001-2008 LINBIT Information Technologies
# Philipp Reisner, Lars Ellenberg
#
### BEGIN INIT INFO
# Provides: drbd
# Required-Start: $local_fs $network $syslog
# Required-Stop:  $local_fs $network $syslog
# Should-Start:   sshd multipathd
# Should-Stop:    sshd multipathd
# Default-Start:  2 3 4 5
# Default-Stop:   0 1 6
# X-Start-Before: heartbeat corosync
# X-Stop-After:   heartbeat corosync
# Short-Description:    Control drbd resources.
### END INIT INFO
 
sleep 5
 
DEFAULTFILE="/etc/default/drbd"
DRBDADM="/sbin/drbdadm"
DRBDSETUP="/sbin/drbdsetup"
PROC_DRBD="/proc/drbd"
MODPROBE="/sbin/modprobe"
RMMOD="/sbin/rmmod"
UDEV_TIMEOUT=10
ADD_MOD_PARAM=""
.
.
.

Was lernen wir daraus? Ein Netzwerksubsystem zu starten ist die eine Sache, eine funktionierende Netzwerkverbindung aufzubauen wieder eine ganz andere… Kannte ich bislang eigentlich nur von Windows XP ;-)

Ausfall des Secondary Nodes

Nachdem nun das Startproblem behoben war, hat DRBD sich so verhalten wie es sollte. Dazu habe ich den »Secondary Node« abgeschaltet, auf dem »Primary Node« Daten gelöscht und neue hinzugefügt und den »Secondary Node« wieder gestartet. Nachdem der »Secondary Node« wieder gestartet war, haben sich die DRBD-Volumes wieder verbunden und der »Primary Node« hat automatisch die Daten synchronisiert, ein »dstat -n -N eth0« auf dem »Primary Node« hat dies angezeigt.

Ausfall des Primary Nodes

Note: Im Kontext dieses Abschnittes wird davon ausgegangen, dass als Ausgangslage der »server1« der »Primary-« und »server2« der »Secondary-Node« ist.

Temporärer Neustart

Beim Ausfall des »Primary Nodes« verhält es sich nicht ganz so trivial, wie beim Ausfall des »Secondary Nodes«. Ein automatisches Verbinden der Ressourcen findet hier nicht statt. Hingegen fällt auch der »Primary Node« auf einen »Secondary Node« zurück: 

root@server1:~# cat /proc/drbd 
version: 8.3.7 (api:88/proto:86-91)
srcversion: EE47D8BF18AC166BE219757 
 0: cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate C r----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

Ohne weiterführende Konfiguration des Systems wird auch der »Secondary Node« nicht automatisch zum »Primary Node« heraufgesetzt, dass ist Sache des Administrators oder einer entsprechenden Anwendung (dazu später mehr).

Um den herabgestuften Node nun wieder zum »Primary Node« zu machen genügt es, folgendes Kommando auf dem ehemaligen »Primary Node« auszuführen: 

root@server1:~# drbdadm primary r0

Und das drbd-Volume neu zu mounten: 

root@server1:~# mount -t ext3 /dev/drbd0 /drbd_data/

Das ganze gilt aber nur für den Fall, dass der »Primary Node« nur mal eben schnell neu gestartet wird oder aus einem anderen Grund kurzzeitig die Verbindung der beiden Nodes unterbrochen wird.

Totalausfall des Primary Nodes

Ganz anders ist das Problem gelagert, wenn der »Primary Node« komplett ausfällt oder zumindest solange, dass auf die Verfügbarkeit der Daten nicht gewartet werden kann. Eine erste Maßnahme dürfte sein, den »Secondary Node« zum »Primary Node« heraufzustufen, um die Daten erst mal wieder zur Verfügung zu haben. Deshalb wird auf dem »Secondary-Node« folgendes Kommando ausgeführt, um ihn zum »Primary-Node« zu machen. 

root@server2:~# drbdadm primary r0

Danach das DRBD-Volume mounten: 

root@server2:~# mount -t ext3 /dev/drbd0 /drbd_data/

Und die Daten sind nun am »server2« verfügbar: 

root@server2:~# ls -l /drbd_data/
insgesamt 1501504
drwx------ 2 root root     16384 30. Dez 17:00 lost+found
-rw-r--r-- 1 root root 512000000 30. Dez 21:45 testfile4.dd
-rw-r--r-- 1 root root 512000000 31. Dez 13:29 testfile5.dd
-rw-r--r-- 1 root root 512000000 30. Dez 17:16 testfile.dd

Nun kann die Reparatur oder Neuinstallation des ausgefallenen Servers beginnen. Wenn Sie sich für einen komplett neuen Server entscheiden müssen, gilt zu beachten, dass das neu bereitgestellte Volume für den DRBD-Spiegel auf keinen Fall kleiner sein darf, als das bereits vorhandene. Gehen Sie im Grunde genommen so vor, wie bei der Installation des neuen Nodes im Tutorial DRBD: RAID1 über LAN beschrieben. Hie in meinem Beispiel habe ich einen Snapshot des »server1« wieder eingespielt, der mich in die Grundinstallation des Systems, ohne DRBD zurück gebracht hat. Die notwendigen Schritte in diesem Szenario waren:

Note: Wenn Sie einen neuen Server einsetzen, müssen Sie darauf achten, dass Sie die neue IP-Adresse und den neuen Hostnamen in den Konfigurationsdateien »/etc/hosts« und »/etc/drbd.conf« Ihrem neuen Setup entsprechend anpassen.

Split-Brain

Wenn alle Cluster-Partner gleichzeitig die Verbindung verlieren, kommt es zu einem undefinierten Zustand, welcher »Split-Brain«4) genannt wird. In diesem Fall funktionieren noch mindestens zwei Nodes, jedoch ist keine Koordination zwischen ihnen mehr möglich. In unserer Beispielkonfiguration hier ist ein Split-Brain nicht weiter schlimm, die Ressourcen sind weiterhin verfügbar und da eh nur einer der beiden Nodes als alleinige Ressource zur Verfügung steht, besteht keine Gefahr von Inkonsistenzen. Dramatischer wirkt sich da eine »Split-Brain« Situation in einem Clusterverband aus, welcher motiviert zB zur Lastverteilung, mehrere oder alle Nodes als Ressource zur Verfügung zu stellen. Im Falle einer »Split-Brain« Situation werden unkontrolliert an alle Ressourcen Daten gesendet, welche sich dann in einem undefinierten Zustand befinden. Da alle Nodes irgendwelche Daten erhalten haben, können diese nur noch sehr schwer zusammengeführt werden.

Erkennen können Sie eine »Split-Brain« Situation zB durch folgende Meldung im Syslog:

block drbd0: Split-Brain detected, dropping connection!

Eine »Split-Brain« Situation kann in »DRBD« manuell durch folgende Kommandos aufgelöst werden:

Entscheiden Sie zuerst, welcher Node die aktuellen Daten enthält. IdR ist dies der »Primary-Node«, zumindest in unserem Setup. Auf dem Node, welcher die ungültigen Daten enthält (hier im Beispiel der »Secondary Node«) führen Sie folgende Kommandos aus, um seine Daten als ungültig zu markieren: 

root@server2:~# drbdadm disconnect r0
root@server2:~# drbdadm secondary r0
root@server2:~# drbdadm -- --discard-my-data connect r0

Danach sollte die »Split-Brain« Situation bereits wieder aufgehoben sein. Sollte der »Primary-Node« jedoch auch im »Stand-Alone« Modus stecken, schieben Sie auf dem anderen Node noch folgendes Kommando hinterher: 

root@server1:~# drbdadm connect r0

Verwandte Artikel:
-> DRBD: Raid1 über LAN (Setup)
-> DRBD: Integration in Heartbeat

— pronto 2013/01/01 14:47

1) http://www.drbd.org/users-guide-8.3/s-node-failure.html
2) http://www.drbd.org/users-guide/s-split-brain-notification-and-recovery.html
3) http://wiki.debian.org/LSBInitScripts
4) http://de.wikipedia.org/wiki/Split_Brain_%28Informatik%29