[[Vorlage(archiviert)]]
[[Vorlage(Fortgeschritten)]]

{{{#!vorlage Wissen
[:sudo:Als Administrator arbeiten]
[:Editor: Umgang mit Editor] 
[:Dienste: Starten, Stoppen und Entfernen von Diensten] 
[:Internet_und_Netzwerk: Netzwerkkenntnisse allgemein]
}}}

[[Inhaltsverzeichnis]]

[wikipedia: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.

{{{#!vorlage Warnung
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.
}}}

{{{#!vorlage 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.

{{{#!vorlage 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
{{{#!code bash
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
{{{#!code bash
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.

{{{#!vorlage Befehl
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:

{{{#!vorlage Paketinstallation
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.

{{{#!vorlage 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:

{{{#!vorlage Befehl
dd if=/dev/zero bs=10M count=100 of=/dev/mapper/vg00-sqldata; sync
}}}

Jetzt wird das Modul geladen und der Autostart aktiviert.

{{{#!vorlage Befehl
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:

{{{#!vorlage Befehl
lsmod | grep drbd
}}}
{{{
drbd                  225200  0
cn                     18248  1 drbd
}}}

Nun kann DRBD gestartet werden.

{{{#!vorlage Befehl
/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:

{{{#!vorlage Befehl
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:

{{{#!vorlage Befehl
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:

{{{#!vorlage Befehl
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:

{{{#!vorlage Befehl
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:

{{{#!vorlage Befehl
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:

{{{#!vorlage Befehl
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.

{{{#!vorlage Befehl
root@sqlrz-master:~# mkfs.xfs /dev/drbd0
}}}

Einbinden:

{{{#!vorlage Befehl
root@sqlrz-master:~# mount /dev/drbd0 /home/data
}}}

Zum Testen kann auch mal eine Datei erstellt werden.

{{{#!vorlage Befehl
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.

{{{#!vorlage Befehl
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.

{{{#!vorlage Befehl
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'''):

{{{#!vorlage Befehl
drbdadm attach home-data
}}}

Trennen der Verbindung von Laufwerk und DRBD-Ressource:

{{{#!vorlage Befehl
drbdadm detach home-data
}}}

Verbinden des DRBD-Treibers mit dem anderen Node:

{{{#!vorlage Befehl
drbdadm connect home-data
}}}

Bestehende DRBD-Verbindung zum anderen Node trennen:

{{{#!vorlage Befehl
drbdadm disconnect home-data
}}}

Masterrolle agbgeben:

{{{#!vorlage Befehl
drbdadm secondary home-data
}}}

Masterrolle übernehmen:

{{{#!vorlage Befehl
drbdadm primary home-data
}}}

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

{{{#!vorlage Befehl
drbdadm adjust home-data
}}}

Statusabfrage der Verbindung:

{{{#!vorlage Befehl
drbdadm role home-data
}}}

{{{
Primary/Secondary
}}}

Statusabfrage der Datensynchronisation:

{{{#!vorlage Befehl
drbdadm dstate home-data
}}}

{{{
UpToDate/UpToDate
}}}

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

{{{#!vorlage Befehl
drbdadm invalidate home-data
}}}

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

{{{#!vorlage Befehl
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

{{{#!vorlage Befehl
root@sqlrz-master:~# drbdadm disconnect home-data
root@sqlrz-master:~# drbdadm detach home-data
}}}

bzw.

{{{#!vorlage Befehl
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:

{{{#!vorlage Befehl
root@sqlrz-master:~# drbdadm down home-data
}}}

und

{{{#!vorlage Befehl
root@sqlrz-slave:~# drbdadm up home-data
}}}

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

{{{#!vorlage Befehl
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:

{{{#!vorlage Befehl
vim /etc/ha.d/haresources
}}}

{{{#!code bash
sqlrz-master 192.168.10.2 drbddisk::home-data Filesystem::/dev/drbd0::/home/data::xfs mysql mon
}}}

{{{#!vorlage Warnung
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 ü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

{{{#!code bash
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

{{{#!code bash
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

{{{#!code bash
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.

{{{#!vorlage Warnung
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.

{{{#!vorlage Befehl
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.

{{{#!vorlage Warnung
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 '''S'''hoot '''T'''he '''O'''ther '''N'''ode '''I'''n '''T'''he '''H'''ead. 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:

{{{#!code bash
# 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 ==

 * [http://www.linux-ha.org Linux-HA Projekt] {en} 
 * [http://www.linux-magazin.de/heft_abo/ausgaben/2004/07/reservespieler Artikel zu älteren Versionen von Heartbeat & DRBD bei Linux-Magazin.de] {de} 
 * [http://www.linbit.com/ Linbit: Hersteller von DRBD] {de}
 * [http://www.drbd.org/ Linbit: Technische Details und Dokumentation zu DRBD] {en} 
 * [http://usage.drbd.org/ Linbit: DRBD Nutzerstatistiken] {en} 

#tag: Netzwerk, Hardware, System, Installation, Server, Kommunikation, Heartbeat, Hochverfügbarkeit, DRBD, RAID