DRBD
Archivierte Anleitung
Dieser Artikel wurde archiviert. Das bedeutet, dass er nicht mehr auf Richtigkeit überprüft oder anderweitig gepflegt wird. Der Inhalt wurde für keine aktuell unterstützte Ubuntu-Version getestet. Wenn du Gründe für eine Wiederherstellung siehst, melde dich bitte in der Diskussion zum Artikel. Bis dahin bleibt die Seite für weitere Änderungen gesperrt.
Artikel für fortgeschrittene Anwender
Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.
Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:
DRBD steht für Distributed Replicated Block Device und ist ein Open Source-Treiber, welcher Geräte im System bereitstellt, die als Blockdevice eingebunden werden können. Es ist eine Technik, die ein RAID1 (Spiegelung) übers Netzwerk mittels TCP/IP ermöglicht. Diese kostengünstige Hochverfügbarkeitslösung (HA) wird vor allem für die Ausfallsicherheit in Rechenzentren eingesetzt und ist in einem privaten Netzwerk weniger gefragt.
Funktionsweise¶
Dabei arbeitet ein Server im "Cold Standby", der andere Server stellt aktiv Dienste bereit. Geht dieser Master-Server offline, fährt Heartbeat auf dem anderen, dem Slave, sämtliche Ressourcen hoch inkl. dem/den DRBD-Device(s). Auch zur Wartung ist solch ein Takeover praktisch, da der Master hinterher z.B. repariert, geupdatet o.ä. werden kann. Im Anschluss an derartige Arbeiten synchronisiert DRBD selbstständig das/die Laufwerk(e) und Heartbeat übergibt die Ressourcen zurück an den Master. Generell sorgt der DRBD-Treiber selbstständig dafür, dass auf allen beteiligten Systemen die Daten synchron vorliegen und verweigert z.B. die Übergabe der Dienste, solange der zukünftige Masterserver nicht komplett aktualisiert wurde.
Achtung!
Wichtig zu wissen ist dabei, dass man niemals versuchen sollte, an per DRBD gespeicherten Daten zu kommen, ohne DRBD dazu zu benutzen, jedenfalls nicht, wenn man vorhat das Device weiterhin zu benutzen.
Hinweis:
Auch befreit DRBD nicht von der Pflicht zur Datensicherung, da Fehler oder Aktionen im Dateisystem in Echtzeit auf alle anderen DRBD-Partner übertragen werden. Ist das Dateisystem defekt oder die Datei gelöscht, ist das auf allen Partnern so!
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.
Hinweis:
Dieses Anleitung ist auf die Hochverfügbar-Machung der meisten anderen Dienste übertragbar, z.B. auf Apache oder Samba. Wichtig ist allerdings, dass z.B. Logs, Sessions etc. ebenfalls auf dem Share-Laufwerk liegen, damit bei einer Übernahme der Dienste des anderen Servers der Betrieb nahtlos weitergehen und später auch nachverfolgt werden kann. Bei Backups z.B. ist darauf zu achten, dass das Datenlaufwerk später über DRBD immer nur einem Rechner, nämlich dem gerade aktuellen Master zugänglich ist.
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.
Hinweis:
Die Datei /etc/drbd.conf muss auf beiden Maschinen identisch sein!
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 |
Achtung!
Wichtig ist für alle Ressourcen, dass sie nicht beim Booten aktiviert werden dürfen, sondern dass das nun eben Heartbeat übernimmt. Das gilt für ALLE Angaben! Diese Konfiguration muss ebenfalls auf beiden Rechnern gleich sein.
sqlrz-master
ist der HA-Master, der standardmäßig die Ressourcen bereitstellt und der (je nach Konfig) auch nach einem Ausfall ggf. wieder automatisch übernimmt192.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 anmysql
undmon
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.
Achtung!
Wenn man eine Verschlüsselung einsetzt, sollte die Datei /etc/ha.d/authkeys mittels chmod auf den Rechtemodus 600 gesetzt werden!
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.
Achtung!
Beim Wechsel der Rollen sollte man immer darauf achten, dass beide DRBD-Nodes UpToDate sind. Der jeweils aktive HA-Master ist auch der maßgebende Host für das DRBD-Device - seine Daten gelten als aktuell!
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¶