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:

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 sein¹⁾ 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-Brains²⁾ 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-Header³⁾ 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.

#!/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

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.

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.

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:

• Die Festplatte »/dev/sdb« einbauen und partitionieren
• Installation der drbd8-utils:
  

  root@server1:~# aptitude install drbd8-utils
  Die folgenden NEUEN Pakete werden zusätzlich installiert:
    drbd8-utils 

• Die Konfogurationsdatei »/etc/drbd.conf« vom noch existierenden Node kopieren:
  

  root@server1:~# scp root@192.168.167.135:/etc/drbd.conf /etc/

• Die lokale Datei »/etc/hosts« anpassen:
  <code bash|/etc/hosts>127.0.0.1 localhost
  127.0.1.1 server1.localdomain server1
  192.168.167.135 server1
  192.168.167.136 server2</code>
  * Das DRBD-Metadata-Storage anlegen:
  

  root@server1:~# drbdadm create-md r0

  
  * DRBD Daemon starten:
  

  root@server1:~# /etc/init.d/drbd start
  Starting DRBD resources:[ d(r0) ].

  
  
  Danach startet DRBD automatisch die Synchronisation und der neu hinzugefügte Node bindet sich als »Secondary Node« ins System ein:
  
  

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