Im Kapitel DRBD: Raid1 über LAN (Setup) wurde ein rudimentäres Setup eines DRBD-Clusters vorgestellt und im Kapitel DRBD: Ausfall eines Nodes wurden die notwendigen Maßnahmen beschrieben, welche nötig sind, wenn ein Node im Cluster ausfällt. Nun wäre es jedoch wünschenswert, wenn der Ausfall eines Nodes (vor allem des »Primary Node«) automatisch erkannt wird und der »Secondary Node« automatisch zum »Primary Node« heraufgestuft wird und die Ressourcen auch ohne Eingriff des Administrators weiterhin zur Verfügung stehen. Letztlich ist das ja der Anspruch an einem »Hochverfügbarkeits-Cluster« (HA-Cluster). Diese Vorgabe kann mit dem Hochverfügbarkeits-Feature »heartbeat«¹⁾ unter Linux realisiert werden.

»heartbeat« testet dabei ständig über das Netzwerk, ob sein Partner noch verfügbar bzw »am Leben« ist. Bleibt der erwartete »Herzschlag« des Partners aus, geht der überlebende Partner her und übernimmt die Funktionen des ausgefallenen Partners. Dieses Tutorial demonstriert dies am Beispiel eines DRBD-Volumes.

Zuerst wird auf beiden Nodes das Paket »heartbeat« aus dem Debian Repository installiert:

# aptitude update
# aptitude install heartbeat

»heartbeat« benötigt drei Konfigurationsdateien, welche Sie selbst anlegen müssen und auf beiden Nodes gleich sein müssen:

/etc/ha.d/ha.cf: Die zentrale Konfigurationsdatei von »heartbeat«:

# /etc/ha.d/ha.cf Main-Config-File
 
# Disable cluster node auto-discovery.
# This requires that cluster nodes be listed explicitly, using the node options.
autojoin none
 
# Heartbeat cluster members
node server1 server2
 
# Heartbeat communication timing
keepalive 1
warntime 10
deadtime 30
initdead 120
 
# Heartbeat communication paths
udpport 694
ucast eth0 192.168.167.135
ucast eth0 192.168.167.136
 
# Don't fail back automatically
auto_failback off
 
# Monitoring of network connection to default gateway
ping 192.168.167.2

• autojoin: Mit »none« wird die automatische Erkennung der Cluster-Node abgeschaltet, stattdessen müssen diese mit der »node« Option explizit angegeben werden. Dadurch beschleunigt den Cluster-Start bei einer festen Anzahl bekannter Cluster-Nodes.
• node: Die Angabe der Cluster-Nodes entsprechend der Ausgabe des Kommandos »uname -a«
• keepalive: Angabe in Sekunden definiert den Interval in dem ein »keep-alive« Paket gesendet wird.
• warntime: Angabe in Sekunden nachdem eine Warnung geloggt wird, dass der Replikationspartner möglicherweise nicht mehr verfügbar ist.
• deadtime: Angabe in Sekunden nachdem der nicht mehr antwortende Replikationspartner als nicht mehr verfügbar erkannt wird.
• initdead: Angabe in Sekunden wie lange beim Booten auf andere Nodes im Cluster gewartet werden soll.
• udpport: Gibt den »heartbeat« Kommunikationsport der Replikationspartner an.
• ucast: Gibt die Adressen der zu überwachenden Replikationspartner an.
• auto_failback: Auf »off« gesetzt wird das automatische Umschalten des (Master-) Primary-Nodes verhindert, nachdem dieser sich zurück meldet. Unter bestimmten Umständen kann das automatische Zurückschalten einen Ping-Pong Effekt zwischen den »heartbeat« Partnern verursachen. Die allgemeine Empfehlung lautet dieses Feature zu deaktivieren.
• ping: Gibt eine Adresse im Netzwerk an, welche zusätzlich überprüft wird, um festzustellen ob der lokale Node noch mit dem Netzwerk verbunden ist. Hier im Beispiel wurde die Adresse des Standardgateways angegeben.

/etc/ha.d/authkeys: Die Authentifizierung-Datei, damit sich beide Partner gegenseitig authentifizieren können:

auth 1
1 sha1 shared_secret

• auth: Hier wird eine fortlaufende Nummer, beginnend mit »1« als Index angegeben.
• 1: Hier wird für den ersten Index der Verschlüsselungsalgorithmus »sha1« und das zu verwendende Passwort (Hier im Beispiel) »shared_secret« angegeben.

/etc/ha.d/haresources: Welche Ressourcen überwacht und ggf auf dem anderen Node gestartet werden müssen:

server1 192.168.167.168 drbddisk::r0 Filesystem::/dev/drbd0::/drbd_data::ext3

• server1: Gibt den Node an, welche standardmäßig der »Primary-Node« ist. Dieser Wert zB von der og Option »auto_failback« ausgewertet.
• 192.168.167.168: Gibt eine virtuelle Adresse an, über welche beide Nodes angesprochen werden können. Diese darf nicht schon zB in der Datei »/etc/network/interfaces« konfiguriert werden, sondern wird durch »heartbeat« selbst bereitgestellt.
• drbddisk::r0 Filesystem::/dev/drbd0::/drbd_data::ext3: Gibt das DRBD-Device, seinen Mountpunkt und das Dateisystem an.

Zum Schluss muss noch »heartbeat« auf beiden Rechnern gestartet werden:

# /etc/init.d/heartbeat start
Starting High-Availability services: IPaddr[3121]: INFO:  Resource is stopped
Done.

Nachdem auf beiden Servern »heartbeat« gestartet ist, werden beiden Server permanent überwacht und beim Ausfall des »Primary-Nodes« wird automatisch auf den verbliebenen Node umgeschaltet. Zu beachten ist jetzt allerdings, dass Sie die beiden Server von Ihren Clients aus mit ihrer virtuellen IP-Adresse (hier »192.168.167.168«) ansprechen müssen und nicht mehr mit ihren nativen IP-Adressen.

Im Prinzip erkennt das System jetzt selbstständig den Ausfall seines Kommunikationspartners, Sie können jedoch auch manuell zB den »Primary-Node« in einen Wartungsmodus schalten, was die Rollen und Ressourcen automatisch auf den zweiten Node überträgt. Führen Sie dazu auf dem Node, welcher in den Wartungsmodus gehen soll folgendes Kommando aus:

root@server1:~# /etc/init.d/heartbeat standby
auto_failback: off
Attempting to enter standby modehb_standby[3749]: Going standby [all].
Done.

Auf dem zweiten Node können Sie zur gleichen Zeit folgendes im Syslog mitverfolgen:

root@server2:~# tail -f /var/log/syslog
Jan  1 20:01:05 server2 heartbeat: [1660]: info: server1 wants to go standby [all]
Jan  1 20:01:05 server2 kernel: [ 5765.284241] block drbd0: peer( Primary -> Secondary ) 
Jan  1 20:01:05 server2 heartbeat: [1660]: info: standby: acquire [all] resources from server1
Jan  1 20:01:05 server2 heartbeat: [2537]: info: acquire all HA resources (standby).
Jan  1 20:01:05 server2 ResourceManager[2551]: [2562]: info: Acquiring resource group: server1 192.168.167.168 drbddisk::r0 Filesystem::/dev/drbd0::/drbd_data::ext3
Jan  1 20:01:05 server2 IPaddr[2574]: [2594]: INFO:  Resource is stopped
Jan  1 20:01:05 server2 ResourceManager[2551]: [2611]: info: Running /etc/ha.d/resource.d/IPaddr 192.168.167.168 start
Jan  1 20:01:05 server2 IPaddr[2624]: [2648]: INFO: Using calculated nic for 192.168.167.168: eth0
Jan  1 20:01:05 server2 IPaddr[2624]: [2654]: INFO: Using calculated netmask for 192.168.167.168: 255.255.255.0
Jan  1 20:01:05 server2 IPaddr[2624]: [2676]: INFO: eval ifconfig eth0:0 192.168.167.168 netmask 255.255.255.0 broadcast 192.168.167.255
Jan  1 20:01:05 server2 IPaddr[2612]: [2695]: INFO:  Success
Jan  1 20:01:05 server2 ResourceManager[2551]: [2725]: info: Running /etc/ha.d/resource.d/drbddisk r0 start
Jan  1 20:01:05 server2 kernel: [ 5765.689793] block drbd0: role( Secondary -> Primary ) 
Jan  1 20:01:05 server2 Filesystem[2744]: [2788]: INFO:  Resource is stopped
Jan  1 20:01:05 server2 ResourceManager[2551]: [2803]: info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd0 /drbd_data ext3 start
Jan  1 20:01:05 server2 Filesystem[2810]: [2838]: INFO: Running start for /dev/drbd0 on /drbd_data
Jan  1 20:01:05 server2 kernel: [ 5765.769955] kjournald starting.  Commit interval 5 seconds
Jan  1 20:01:05 server2 kernel: [ 5765.771110] EXT3 FS on drbd0, internal journal
Jan  1 20:01:05 server2 kernel: [ 5765.771135] EXT3-fs: mounted filesystem with ordered data mode.
Jan  1 20:01:05 server2 Filesystem[2804]: [2855]: INFO:  Success
Jan  1 20:01:05 server2 heartbeat: [2537]: info: all HA resource acquisition completed (standby).
Jan  1 20:01:05 server2 heartbeat: [1660]: info: Standby resource acquisition done [all].
Jan  1 20:01:06 server2 heartbeat: [1660]: info: remote resource transition completed.

Wenn der Server seinen Wartungsmodus beendet hat und wieder als »Primary Node« zur Verfügung steht führen Sie das og Kommando einfach auf dem derzeitigen »Primary Node« aus, um die Verhältnisse wieder zu tauschen:

root@server2:~# /etc/init.d/heartbeat standby
auto_failback: off
Attempting to enter standby modehb_standby[2915]: Going standby [all].
Done.

Es versteht sich bei der Funktionsweise dieses hier vorgestellten DRBD-Volumes von selbst, dass keinerlei Eingriff notwendig ist, wenn der Server zur Wartung abgeschaltet wird oder offline geht, welcher aktuell die Rolle des »Secondary-Nodes« hält.

Verwandte Artikel:
-> DRBD: Raid1 über LAN (Setup)
-> DRBD: Ausfall eines Nodes

— pronto 2013/01/01 18:46

»prontosystems.org -- we are connecting more than computers«