Ausgangssituation¶

Ausgegangen wird von zwei fertig konfigurierten Maschinen mit Ubuntu Server 8.04 LTS, die weitestgehend die gleiche Konfiguration haben. Dazu gehört neben aktuellen Patches eine funktionstüchtige Installation der später zu hostenden Dienste (in diesem Fall MySQL), IDS (Intrusion Detection System), Monitoring (mon), Backup, Cronjobs für Zeitsync etc. Der HA-Verbund soll im folgenden Beispiel mehreren Web- und Applikationsserver eines Rechenzentrums Datenbanken zur Verfügung stellen. Die beiden eingesetzten Maschinen heißen sqlrz-master und sqlrz-slave. Der Masterserver ist der aktive, der Slave der Standbyserver.

Beide Maschinen haben je eine Netzwerkkarte für das lokale Netz, über welches die Systeme einzeln ansprechbar sind und worüber z.B. Updates aus dem Internet geholt werden. Zudem gibt es ein weiteres Netzwerk, das HA-Netz, welches nur zwischen diesen beiden Servern besteht. Dieses muss in einem eigenen Subnetz liegen, in welchem keine anderen Hosts auftauchen und ist idealerweise über einen separaten Switch geschaltet, der mit dem lokalen Netzwerk nicht verbunden ist.

Die Festplatten sollten in beiden Maschinen etwa gleich schnell sein, da eine ungleiche Performanceverteilung erfahrungsgemäß auch das schnellere System erheblich ausbremsen kann.

Diese beiden Server sollen nun eine MySQL-Instanz hochverfügbar machen, ohne die MySQL-eigene Clustertechnologie zu nutzen. Die hier gezeigte HA-Lösung ist übrigens die von MySQLAB/SUN empfohlene Alternative zum "echten" Cluster.

Einige Angaben hier machen in der eigenen Umgebung so keinen Sinn, müssen also entsprechend angepasst werden (IPs, Dienste, Namen, Auswahl des Dateisystems etc.)! Alle hier beschriebenen Aktionen müssen außerdem als root durchgeführt werden.

Ein Datenlaufwerk soll später unter /home/data eingebunden werden, wobei dieses per DRBD übers Netzwerk als RAID1 betrieben wird. Es wurde bei der Installation der Server auf beiden bereits angelegt. Beide Server haben lokal je zwei Platten im Softraid1, welches (bis auf /boot) mit LVM2 partitioniert wurde. Die Volumegruppe heißt vg00, die Datenpartition sqldata. Letztere ist erreichbar unter /dev/mapper/vg00-sqldata.

Die Aktivierung der Dienste und das Switchen der DRBD-Rollen übernimmt später Heartbeat.

Netzwerkkonfiguration¶

Die IP-Konfiguration wird als erstes vorgenommen. Beide Server bekommen je eine IP aus dem Netz 10.110.214.0/24 auf ihre 2. Netzwerkkarte. Danach wird die Datei /etc/hosts auf beiden Rechnern wie folgt konfiguriert:

sqlrz-master

1
2
3
4
5
6

127.0.0.1       localhost
127.0.1.1       sqlrz-master
192.168.9.3     sqlrz-master.fkc.firma  sqlrz-master
# HA-Netz
10.110.214.1    sqlrz-master.fkc.firma  sqlrz-master
10.110.214.2    sqlrz-slave.fkc.firma   sqlrz-slave

sqlrz-slave

1
2
3
4
5
6

127.0.0.1       localhost
127.0.1.1       sqlrz-slave
192.168.9.4     sqlrz-slave.fkc.firma  sqlrz-slave
# HA-Netz
10.110.214.1    sqlrz-master.fkc.firma  sqlrz-master
10.110.214.2    sqlrz-slave.fkc.firma   sqlrz-slave

Damit greifen beide Server auf den jeweils anderen über die HA-Adresse zu. Diese wird dann auch verwendet, um die DRBD- und Heartbeat-Zugriffe zu transportieren. Der Name des Partners kann nun außerdem ohne DNS und IMMER auf die HA-Adresse aufgelöst werden.

Zum Überprüfen wird auf beiden Rechnern der jeweils andere über seinen Namen angepingt. Die Antwort sollte über die HA-Adresse kommen.

root@sqlrz-master:~# ping sqlrz-slave 

PING sqlrz-slave.fkc.firma (10.110.214.2) 56(84) bytes of data.
64 bytes from sqlrz-slave.fkc.firma (10.110.214.2): icmp_seq=1 ttl=64 time=3.64 ms

Die nächsten Schritte sind auf beiden Maschinen parallel durchzuführen!

Software installieren¶

Folgende Pakete müssen installiert werden:

• heartbeat

• drbd8-utils

Befehl zum Installieren der Pakete:

sudo apt-get install heartbeat drbd8-utils 

Oder mit apturl installieren, Link: apt://heartbeat,drbd8-utils

Hier soll es die Version 8 (bzw. 0.8) sein. Da in Hardy DRBD8 bereits in linux-ubuntu-modules enthalten ist, muss nur drbd8-utils für die Verwaltungstools installiert werden.

Als nächstes muss die DRBD-Konfiguration angepasst werden. Dazu wird die Datei /etc/drbd.conf in einem Editor geöffnet. Sie enthält bereits mehrere vorkonfigurierte Abschnitte, die gelöscht oder zumindest deaktiviert werden müssen (auskommentieren). Sie können natürlich auch als Quelle für eigene Konfigurationen dienen. Was die Optionen genau bedeuten, ist in der Original-Konfig ausführlich beschrieben, hier nur ein paar Worte zur Protokollversion.

Es gibt drei Arten, wie DRBD mit den Daten umgeht, um sicherzustellen, dass sie geschrieben wurden:

• Protokoll A: asynchronr Replikationsmodus - die Daten gelten als sicher, sobald sie von der lokalen HDD als geschrieben gemeldet und in den TCP-Sendepuffer geschrieben wurden.

• Protokoll B : semi-synchroner Replikationsmodus - die Daten gelten als sicher, sobald sie von der lokalen HDD als geschrieben gemeldet wurden und der DRBD-Partner-Node den Datenempfang bestätigt hat.

• Protokoll C: synchroner Replikationsmodus - die Daten gelten als sicher, sobald sie auf ALLEN beteiligten Platten (lokal und anderer Node) geschrieben wurden.

Nur die Protokollversion C bietet vollständige Redundanz. Die Versionen A und B bergen die Gefahr, dass bei einem Ausfall des Primary Node Daten verloren gehen, da sie auf dem Secondary Node noch nicht vollständig geschrieben wurden. Deshalb ist C auch die am häufigsten eingesetzte Protokollversion.

In diesem Beispiel sieht die Datei so aus:

### globale Angaben ###
global {
    # an Statistikauswertung auf usage.drbd.org teilnehmen?
    usage-count yes;
}
### Optionen, die an alle Ressourcen vererbt werden ###
common {
  syncer { 
    rate 100M; 
  }
}
### Ressourcenspezifische Optionen
resource home-data {
  # Protokoll-Version
  protocol C;
  
  startup {
    # Timeout (in Sekunden) für Verbindungsherstellung beim Start
    wfc-timeout         0;
    # Timeout (in Sekunden) für Verbindungsherstellung beim Start 
    # nach vorheriger Feststellung von Dateninkonsistenz
    # ("degraded mode")
    degr-wfc-timeout  120;
  }
  disk {
    # Aktion bei EA-Fehlern: Laufwerk aushängen
    on-io-error detach;
  }
  net {
    ### Verschiedene Netzwerkoptionen, die normalerweise nicht gebraucht werden, ###
    ### die HA-Verbindung sollte generell möglichst performant sein...           ###
    # timeout           60;
    # connect-int       10;
    # ping-int          10;
    # max-buffers     2048;
    # max-epoch-size  2048;
  }
  syncer {
    # Geschwindigkeit der HA-Verbindung
    rate 100M;
  }
  on sqlrz-master {
    ### Optionen für Master-Server ###
    # Name des bereitgestellten Blockdevices
    device     /dev/drbd0;
    # dem DRBD zugrunde liegendes Laufwerk
    disk       /dev/mapper/vg00-sqldata;
    # Adresse und Port, über welche die Synchr. läuft
    address    10.110.214.1:7788;
    # Speicherort der Metadaten, hier im Laufwerk selbst
    meta-disk  internal;                 
  }
  on sqlrz-slave {
    ## Optionen für Slave-Server
    # Name des bereitgestellten Blockdevices
    device     /dev/drbd0;
    # dem DRBD zugrunde liegendes Laufwerk
    disk       /dev/mapper/vg00-sqldata;
    # Adresse und Port, über welche die Synchr. läuft
    address    10.110.214.2:7788;
    # Speicherort der Metadaten, hier im Laufwerk selbst
    meta-disk  internal;
  }
}

Nun sollte geprüft werden, dass die angegebene Partition nicht in der /etc/fstab eingetragen ist (ohne Dateisystem steht sie normalerweise sowieso nicht drin, aber falls man sie doch schon vorher formatiert haben sollte...). Sollte man tatsächlich vorher formatiert haben, kann man das Dateisystem mit folgendem Befehl wieder zerstören, die Optionen count und bs sollten multipliziert in etwa der Größe der Partition entsprechen:

dd if=/dev/zero bs=10M count=100 of=/dev/mapper/vg00-sqldata; sync 

Jetzt wird das Modul geladen und der Autostart aktiviert.

modprobe drbd
echo 'drbd' >> /etc/modules
update-rc.d drbd defaults                     

Der letzte Befehl bringt u.U. eine Meldung, dass der Link bereits existiert - das ist ok.

Ein Test, ob das Modul geladen wurde:

lsmod | grep drbd 

drbd                  225200  0
cn                     18248  1 drbd

Nun kann DRBD gestartet werden.

/etc/init.d/drbd restart
drbdadm create-md home-data
drbdadm up home-data 

Nun kann erstmals der Status abgefragt werden. An dieser Stelle zeigt sich dann, ob alles richtig gemacht wurde. Wenn es funktioniert, sieht die Ausgabe so aus:

cat /proc/drbd 

version: 8.0.11 (api:86/proto:86)
GIT-hash: b3fe2bdfd3b9f7c2f923186883eb9e2a0d3a5b1b build by phil@mescal, 2008-02-12 11:56:43
 0: cs:Connected st:Secondary/Secondary ds:Inconsistent/Inconsistent C r---
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0
        resync: used:0/31 hits:0 misses:0 starving:0 dirty:0 changed:0
        act_log: used:0/127 hits:0 misses:0 starving:0 dirty:0 changed:0

Wenn nicht, ist das an dem WFConnection (Waiting for Connection) bzw. Unknown erkennbar:

cat /proc/drbd 

version: 8.0.11 (api:86/proto:86)
GIT-hash: b3fe2bdfd3b9f7c2f923186883eb9e2a0d3a5b1b build by phil@mescal, 2008-02-12 11:56:43
 0: cs:WFConnection st:Secondary/Unknown ds:Inconsistent/DUnknown C r---
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0
        resync: used:0/31 hits:0 misses:0 starving:0 dirty:0 changed:0
        act_log: used:0/127 hits:0 misses:0 starving:0 dirty:0 changed:0

Dann hilft auf beiden Rechnern evtl. folgendes:

drbdadm disconnect home-data
drbdadm detach home-data 

Danach sind die Schritte weiter oben zu wiederholen, also ab drbd restart.

Ab jetzt sind die weiteren Schritte nur noch auf dem jeweils angegebenen Rechner durchzuführen.

Konsistenz herstellen¶

Dass /proc/drbd die Konsistenz der Devices leugnet, hat einen Grund: es ist noch kein primäres Device angegeben worden. Erst wenn das erledigt ist, weiß DRBD, welches der Laufwerke den tatsächlichen Laufwerkszustand angibt und synchronisiert diesen auf das sekundäre Device.

Genau das wird jetzt getan:

root@sqlrz-master:~# drbdadm -- -o primary home-data
root@sqlrz-master:~# cat /proc/drbd 

version: 8.0.11 (api:86/proto:86)
GIT-hash: b3fe2bdfd3b9f7c2f923186883eb9e2a0d3a5b1b build by phil@mescal, 2008-02-12 11:56:43
 0: cs:SyncSource st:Primary/Secondary ds:UpToDate/Inconsistent C r---
    ns:73236 nr:0 dw:0 dr:81312 al:0 bm:4 lo:1 pe:5 ua:253 ap:0
        [>....................] sync'ed:  0.8% (10168/10239)M
        finish: 0:14:13 speed: 12,180 (12,180) K/sec
        resync: used:1/31 hits:4820 misses:5 starving:0 dirty:0 changed:5
        act_log: used:0/127 hits:0 misses:0 starving:0 dirty:0 changed:0

Hier ist nun zu sehen, dass der Sync-Prozess begonnen hat und wie weit er fortgeschritten ist. Der jeweilige Server gibt seine eigenes Rolle und seinen Zustand übrigens immer als erstes an, d.h. st:Primary/Secondary ds:UpToDate/Inconsistent zeigt, dieser Server ist der Primäre und sein Laufwerkszustand ist aktuell. Beim Slave sieht das also so aus: st:Secondary/Primary ds:Inconsistent/UpToDate.

In der Logdatei /var/log/syslog sollte der Syncvorgang folgende Spuren hinterlassen:

root@sqlrz-master:~# tail -20 /var/log/syslog 

Jun  9 11:48:02 sqlrz-master kernel: [1890704.201139] drbd0: conn( StandAlone -> Unconnected )
Jun  9 11:48:02 sqlrz-master kernel: [1890704.201214] drbd0: Starting receiver thread (from drbd0_worker [26327])
Jun  9 11:48:02 sqlrz-master kernel: [1890704.201236] drbd0: receiver (re)started
Jun  9 11:48:02 sqlrz-master kernel: [1890704.201239] drbd0: conn( Unconnected -> WFConnection )
Jun  9 11:48:30 sqlrz-master kernel: [1890732.551619] drbd0: Handshake successful: DRBD Network Protocol version 86
Jun  9 11:48:30 sqlrz-master kernel: [1890732.551631] drbd0: conn( WFConnection -> WFReportParams )
Jun  9 11:48:30 sqlrz-master kernel: [1890732.551636] drbd0: Starting asender thread (from drbd0_receiver [23389])
Jun  9 11:48:30 sqlrz-master kernel: [1890732.552213] drbd0: Becoming sync source due to disk states.
Jun  9 11:48:30 sqlrz-master kernel: [1890732.552216] drbd0: Writing meta data super block now.
Jun  9 11:48:30 sqlrz-master kernel: [1890732.568799] drbd0: writing of bitmap took 1 jiffies
Jun  9 11:48:30 sqlrz-master kernel: [1890732.568805] drbd0: 25 GB (6553391 bits) marked out-of-sync by on disk bit-map.
Jun  9 11:48:30 sqlrz-master kernel: [1890732.568808] drbd0: Writing meta data super block now.
Jun  9 11:48:30 sqlrz-master kernel: [1890732.569987] drbd0: peer( Unknown -> Secondary ) conn( WFReportParams -> WFBitMapS ) pdsk( DUnknown -> Inconsistent )
Jun  9 11:48:30 sqlrz-master kernel: [1890732.569995] drbd0: Writing meta data super block now.
Jun  9 11:48:31 sqlrz-master kernel: [1890732.611974] drbd0: conn( WFBitMapS -> SyncSource )
Jun  9 11:48:31 sqlrz-master kernel: [1890732.611984] drbd0: Began resync as SyncSource (will sync 26213564 KB [6553391 bits set]).
Jun  9 11:48:31 sqlrz-master kernel: [1890732.611987] drbd0: Writing meta data super block now.
Jun  9 11:55:39 sqlrz-master kernel: [1891160.009582] drbd0: Resync done (total 428 sec; paused 0 sec; 61244 K/sec)
Jun  9 11:55:39 sqlrz-master kernel: [1891160.010205] drbd0: conn( SyncSource -> Connected ) pdsk( Inconsistent -> UpToDate )
Jun  9 11:55:39 sqlrz-master kernel: [1891160.010210] drbd0: Writing meta data super block now.

Sollte einer der Nodes später ausgetauscht oder neu aufgesetzt werden, muss er erneut in den DRBD-Verbund aufgenommen werden, wobei die Vorgehensweise dieselbe bleibt.

Dateisystem erstellen und einbinden¶

Nach dem Synchronisieren kann dann das eigentliche Laufwerk /dev/drbd0 gemounted und formatiert werden. Das geschieht erstmal per Hand, später übernimmt das Heartbeat.

Eine DRBD-Statusabfrage sollte nun folgendes Bild liefern:

root@sqlrz-master:~# cat /proc/drbd 

version: 8.0.11 (api:86/proto:86)
GIT-hash: b3fe2bdfd3b9f7c2f923186883eb9e2a0d3a5b1b build by phil@mescal, 2008-02-12 11:56:43
 0: cs:Connected st:Primary/Secondary ds:'UpToDate/UpToDate' C r---
    ns:0 nr:10485404 dw:10485404 dr:0 al:0 bm:640 lo:0 pe:0 ua:0 ap:0
        resync: used:0/31 hits:654698 misses:640 starving:0 dirty:0 changed:640
        act_log: used:0/127 hits:0 misses:0 starving:0 dirty:0 changed:0

Jetzt wird das Dateisystem erstellt.

root@sqlrz-master:~# mkfs.xfs /dev/drbd0 

Einbinden:

root@sqlrz-master:~# mount /dev/drbd0 /home/data 

Zum Testen kann auch mal eine Datei erstellt werden.

root@sqlrz-master:~# touch /home/data/test 

Wenn man das Device auf dem anderen Rechner einbinden will, muss man vorher die DRBD-Rolle runterstufen, da nur ein DRBD-Partner exklusiv auf die Platten zugreifen darf. Vorher muss das Device noch umountet werden, sonst gibts eine Fehlermeldung.

root@sqlrz-master:~# umount /home/data
root@sqlrz-master:~# drbdadm secondary home-data 

Auf dem anderen Rechner kann man nun das DRBD-Device auf primär schalten und seinerseits mounten. Dann sollte die Datei test sichtbar werden.

root@sqlrz-slave:~# drbdadm primary home-data
root@sqlrz-slave:~# mount /dev/drbd0 /homedata
root@sqlrz-slave:~# ls /home/data 

test

Die Daten werden nun auf beiden Platten gleichzeitig geschrieben.

Nützliche Kommandos für drbdadm¶

Der Befehl drbdadm ist vergleichbar mit mdadm bei Softraids. Er kann mit verschiedenen Parametern dazu benutzt werden, DRBD-Devices wie oben bereits gezeigt zu erstellen, aber auch zu ändern, zu (de-)aktivieren oder zu löschen.

Volle Neusynchronisation von /dev/drbd0 mittels der DRBD-Ressource 'home-data' (Status in /proc/drbd):

drbdadm attach home-data 

Trennen der Verbindung von Laufwerk und DRBD-Ressource:

drbdadm detach home-data 

Verbinden des DRBD-Treibers mit dem anderen Node:

drbdadm connect home-data 

Bestehende DRBD-Verbindung zum anderen Node trennen:

drbdadm disconnect home-data 

Masterrolle agbgeben:

drbdadm secondary home-data 

Masterrolle übernehmen:

drbdadm primary home-data 

Übernahme von Änderungen an /etc/drbd.conf:

drbdadm adjust home-data 

Statusabfrage der Verbindung:

drbdadm role home-data 

Primary/Secondary

Statusabfrage der Datensynchronisation:

drbdadm dstate home-data 

UpToDate/UpToDate

Eigene Daten als ungültig markieren um Resync auszulösen (nur als Secondary!):

drbdadm invalidate home-data 

Daten des Partnernodes als ungültig markieren um Resync auszulösen (nur als Primary!):

drbdadm invalidate-remote home-data 

Für gewöhnlich ist ein manuelles Auslösen der Resynchronisation nicht nötig - Heartbeat erkennt selbstständig, ob ein Secondary-Node outdated ist oder nicht und startet sie ggf. automatisch.

Um die DRBD-Ressource an den Partnernode zu übergeben, kann man statt

root@sqlrz-master:~# drbdadm disconnect home-data
root@sqlrz-master:~# drbdadm detach home-data 

bzw.

root@sqlrz-slave:~# drbdadm attach home-data
root@sqlrz-slave:~# drbdadm syncer home-data
root@sqlrz-slave:~# drbdadm connect home-data 

auch die Kurzformen verwenden:

root@sqlrz-master:~# drbdadm down home-data 

und

root@sqlrz-slave:~# drbdadm up home-data 

Setzt man die Befehle einzeln manuell ab, muss man vorher mittels

root@sqlrz-master:~# drbdadm secondary home-data 

den Master von Primary auf Secondary herunterstufen. Der Parameter up übernimmt das jedoch selbstständig.

Integration in Heartbeat¶

Heartbeat übernimmt in Zukunft das Mounten, weshalb das Device auf beiden Rechnern nicht in der /etc/fstab stehen darf!

In der Heartbeat-Ressourcenkonfiguration wird folgendes notiert:

vim /etc/ha.d/haresources 

1

sqlrz-master 192.168.10.2 drbddisk::home-data Filesystem::/dev/drbd0::/home/data::xfs mysql mon

• sqlrz-master ist der HA-Master, der standardmäßig die Ressourcen bereitstellt und der (je nach Konfig) auch nach einem Ausfall ggf. wieder automatisch übernimmt

• 192.168.10.2 ist eine IP-Adresse auf einem virtuellen Interface, die durch Heartbeat konfiguriert wird; sie darf nicht in /etc/network/interfaces stehen!

• drbddisk::home-data Filesystem::/dev/drbd0::/home/data::xfs gibt das DRBD-Device, seinen Mountpunkt und das Dateisystem an

• mysql und mon sind Dienste, die mit gestartet werden, da deren Ressourcen wiederum auf dem DRBD-Laufwerk liegen

Beim Booten werden die Ressourcen in dieser Reihenfolge eingebunden, etwaige darüber notierte Dienste oder IPs werden zuvor gestartet. Daher sollten die eigentlichen Dienste erst zum Schluss gestartet werden, wenn alles andere bereits verfügbar ist.

Heartbeat selbst wird über die Dateien /etc/ha.d/ha.cf und /etc/ha.d/authkeys konfiguriert. Sie sehen wie folgt aus:

/etc/ha.d/ha.cf auf sqlrz-master

1
2
3
4
5
6

auto_failback   off
ucast   eth2 10.110.214.2
node    sqlrz-slave
node    sqlrz-master
keepalive       2
deadtime        30

/etc/ha.d/ha.cf auf sqlrz-slave

1
2
3
4
5
6

auto_failback   off
ucast   eth2 10.110.214.1
node    sqlrz-slave
node    sqlrz-master
keepalive       2
deadtime        30

/etc/ha.d/authkeys auf beiden Maschinen

1
2
3
4

auth 1
1 crc
#2 sha1 HI!
#3 md5 Hello!

Die Option ucast gibt in /etc/ha.d/ha.cf die Methode und das Interface sowie die Zieladresse für die Heartbeatverbindung an. Hier wird der Heartbeat per Unicast an die Adresse des jeweiligen HA-Partners gesendet. Es gibt auch eine Möglichkeit, Broadcasts zu verwenden, allerdings sollte bei zwei Nodes Unicast verwendet werden. Weiterhin werden die Nodes namentlich aufgelistet sowie Timeouts definiert.

Mittels auto_failback wird angegeben, ob der Masterserver automatisch die Masterrolle übernehmen soll, sobald er wieder verfügbar ist (z.B. nach einem Reboot). Diese Option sollte allerdings mit Bedacht gesetzt werden, da bei einem Fehler beim Binden der Ressourcen ein Ping-Pong-Effekt entstehen kann, bei dem die Server die Rollen immer wieder hin und her switchen. Es kann durchaus sinnvoller sein, die Rückgabe der Masterrolle manuell vorzunehmen

In der Datei /etc/ha.d/authkeys wird eine eventuelle Verschlüsselung der Heartbeatverbindung konfiguriert. Zur Verfügung stehen die Modi SHA, MD5 und CRC. SHA gilt als sicherste Methode, MD5 als zweitsicherste und bei CRC wird gar nicht verschlüsselt. Bei einer direkten Verbindung über ein einzelnes Netzwerkkabel oder einen separaten Switch ist keine Verschlüsselung nötig. Verwendet man das HA-Interface aber an einem auch anderweitig genutzten Switch/Hub oder über ein öffentlichen Netzwerk, sollte SHA zum Einsatz kommen. Beim Einsatz einer Verschlüsselung wird hinter dem Namen der Methode (in einer nummerierten Liste) das entsprechende Kennwort notiert. Der Parameter auth gibt die zu verwendende Methode anhand ihrer Listenposition an.

Wechsel der Rollen¶

Sollte der Masterserver zu Wartungszwecken außer Betrieb genommen werden, kann man die Masterrolle an den Slaveserver übergeben.

root@sqlrz-master:~# /etc/init.d/heartbeat standby 

Auch die Rückgabe der Dienste an den Master kann so vom Slave angewiesen werden. Der Fortschritt lässt sich in /var/log/syslog beobachten. Dort werden auch eventuelle Fehler bei der Übergabe vermerkt, in diesem Fall kann die Übergabe nicht erfolgreich abgeschlossen werden.

Wenn am Slave Wartungsarbeiten vorgenommen werden müssen, kann dieser einfach vom Netz genommen werden. Sobald die HA-Verbindung wieder steht, wird automatisch ein Resync angestoßen.

Man sollte sich nicht allein auf die Automatik von Heartbeat, die Rollenübergabe bei Fehlern abzubrechen, verlassen. Im laufenden Betrieb ist das zwar in der Regel kein Problem, vor allem beim späteren Hinzufügen eines neuen Nodes sollte man äußerste Vorsicht walten lassen und alle Meldungen genau lesen. Ein vorheriges Backup ist natürlich sowieso Pflicht.

Split-Brain-Situation¶

In Einzelfällen kann es vorkommen, dass die Server einwandfrei funktionieren, ihre Heartbeat-Verbindung aber gestört ist, z.B. beim Ausfall eines HA-Interfaces oder des verbindenden Switches. In diesem Fall "denken" beide Server, sie wären der zuletzt übrig gebliebene und beanspruchen die Ressourcen für sich. Das kann z.b. bei von Heartbeat verwalteten IPs schwere Netzfehler verursachen, da diese dann doppelt vorhanden wären. Die DRBD-Datenträger würde sich mit unterschiedlichen Daten füllen, die nicht mehr synchronisiert werden könnten. Oder beide Server gehen wegen Fehlern vollständig vom Netz.

Um diese Situation zu vermeiden, gibt es eine Technik namens STONITH. Diese Abkürzung steht für Shoot The Other Node In The Head. Gemeint ist eine gezielte Abschaltung des jeweils anderen Nodes, indem über per Netzwerk konfigurierbare Stromverteiler (meist Net-PDU o.ä. genannt) dem jeweils anderen Node der Strom angeschaltet wird. Die Hardware dafür ist allerdings recht teuer und meist nicht ohne erheblichen Scripting-/Programmieraufwand einzubinden.

Statusabfrage für Backupscripts¶

Wenn man per Cron ein Backupskript laufen lässt, welches auch die Daten der HA-Dienste sichert, sollte man eine Abfrage zum aktuellen Status des DRBD-Laufwerks machen. So kann man sicherstellen, dass das System auch Zugriff auf die Ressourcen nehmen kann, außerdem kann man so das Skript auf alle beteiligten Partnersystemen laufen lassen, wobei es nur auf dem aktiven Master seine Arbeit komplett durchführt. Eine Abfrage könnte so eingebaut werden:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# Pruefung, ob Master oder Slave
check_primary () {
  local PRIMARY=1
  local RESSTRING=
  local DRBDCMD=/sbin/drbdadm

        # Variable enthält 'Primary' oder 'Secondary'
        RESSTRING=`$DRBDCMD state all | sed -e 's/\/.*$//'`
        if [ "$RESSTRING" != "Primary" ]; then
                PRIMARY=0
        fi
        return $PRIMARY
}
# Falls nicht DRBD-Primary, dann Ende
check_primary
if [ "$?" = "0" ]; then
    echo "Error: I'm not primary! Cancelling Script..."
    exit 1
fi

Links¶

• Linux-HA Projekt 🇬🇧

• Artikel zu älteren Versionen von Heartbeat & DRBD bei Linux-Magazin.de 🇩🇪

• Linbit: Hersteller von DRBD 🇩🇪

• Linbit: Technische Details und Dokumentation zu DRBD 🇬🇧

• Linbit: DRBD Nutzerstatistiken 🇬🇧