DRBD Primary-Secondary Cluster unter Debian

Allgemeines

DRBD (Distributed Replicated Block Device) ist eine Software, die es ermöglicht ein blockbasierendes Gerät eines produktiven Systems auf ein anderes in Echtzeit über TCP/IP zu spiegeln. Schreibvorgänge gelten dabei erst als abgeschlossen, wenn das zweite System dem ersten meldet, dass der Schreibzugriff erfolgreich war.

DRBD stellt auf allen Komponenten eine Verbindung zwischen der eigentlichen lokalen Partition (zum Beispiel /dev/sdb1) und dem virtuellen Device /dev/drdbN her, welches aber nicht direkt angesprochen und nur auf dem aktiven System verwendet werden kann. Den Hosts wird dazu ein entsprechender Status, entweder primär oder sekundär, zugewiesen.

Bei einem Ausfall des produktiven Systems (primary), wird dieses als inaktiv markiert, so dass dem bis dahin sekundären Server, der Status primär zugewiesen werden kann. Das kann manuell aber auch mit Hilfe von Heartbeat automatisch erfolgen.

Punkt 1: Installation von DRBD 8.3.x unter Debian 7 (Wheezy)

Primary und Secondary:

Nun prüfen wir ob das Module drbd geladen wurde, dies sollte automatisch geschehen und ist Out-of-the-Box Reboot fest.

Punkt 2: Konfigurationsdateien /etc/drbd.conf erstellen

Primary und Secondary:

Zuerst leeren wir die Datei /etc/drbd.conf und fügen auf beiden Nodes den selben Inhalt ein.

Achtung!
Der Node Name muss uname -n entsprechen !

Informationen zu den Variablen

usage-count – Daten werden an DRBD übermittelt und mitgezählt
rate – 100M entsprechen 1GBit/s
ressource – Die Ressource die mit z.B. drbdadm angesprochen werden kann
protocol – „A“ entspricht einer Asynchronen Replikation Primary/Secondary

• after-sb-0pri regelt das Verhalten, wenn beide Nodes den Status Secondary haben. In diesem Fall findet keine automatische Synchronisation statt
• after-sb-1pri regelt das Verhalten, wenn einer von den beiden Nodes Primary ist. Dieser Punkt ist für die Kombination von Heartbeat und DRBD wichtig, da DRBD hier dafür sorgt das ein Node Primary wird
• after-sb-2pri regelt das Verhalten, wenn beide Nodes Primary sind. Auch hier wird nichts gemacht und es wird getrenntIn den meisten Setups ist der Automatismus NICHT erwünscht und sollte NICHT in der Config stehen.

Punkt 3: DRBD Device vorbereiten

Primary und Secondary:

Nun muss das DRBD Device, für die Ressource r0, auf beiden Nodes initialisiert werden.

Jetzt muss DRBD auf beiden Nodes gestartet werden.

Primary:

Jetzt könnt ihr die Primary Node bestimmen.

Die Ausgabe, ähnlich wie bei mdadm, von cat /proc/drbd dürfte wie folgt aussehen.

oder

Die folgende Zeile sagt euch ob die Node Primary und UpToDate ist.

Nun kann ein Dateisystem erstellt und eingehangen werden.

Beispiel /etc/fstab Eintrag.

Achtung!
Nur auf der Primary Node ausführen! Die Secondary Node kann das Dateisystem nicht mounten, da es read-only ist.

Punkt 4: Status prüfen

Der DRBD Status kann ähnlich wie bei einem Raid1 (mdadm) über das „/proc“-Filesystem geprüft und auf beiden Hosts abgefragt werden. In der folgenden Ausgabe sieht man, das sowohl der Server auf dem die Abfrage abgesetzt wurde (primär), als auch auf dem sekundären System keine Probleme existieren und die Daten „UpToDate“ sind.

Hier ist eine laufende Synchronisation vom aktuellen Master (Primary) zum inkonsistenten Slave (Secondary) zu sehen.

In der nächsten Ausgabe ist zu erkennen, dass der Slave ausgefallen ist bzw. dieser nicht vom Master erreicht werden kann. Hier muss nur das sekundäre System wieder in Betrieb genommen und anschließend der Status erneut geprüft werden.

Falls der Master ausfällt, könnte die Ansicht auf dem Slave wie folgt aussehen. Hier kann das sekundäre System auf „primär“ gesetzt werden, sobald sichergestellt ist, dass der Master wirklich nicht erreichbar ist.

In der folgenden Ausgabe sind beide Komponenten inkonsistent, was nur bei der Ersteinrichtung auftreten sollte. Hier ist es nur noch möglich den primären Host zu forcieren. Ein einfaches „drbdadm primary r0“ wird fehlschlagen.

Punkt 5: Failover – Primary <-> Secondary

Sollte die Primary Node ausfallen könnt Ihr die Secondary Node zum Primary machen und das DRBD Device mounten.

Die /proc/drbd Datei sollte dann wie folgt aussehen.

WFConnection = Waiting For Connection
Achtung!
Der alte Primary kann ohne Probleme nach dem Ausfall wieder gestartet werden, das INIT Script startet den DRBD Dienst automatisch und wird zum Secondary Node.

Punkt 6: Manueller Failover

Um einen manuellen Failover durchzuführen, sind folgende Schritte notwendig.

1. Stoppen des Netzwerks der Ressource, damit diese nicht mehr vom Slave aus erreichbar ist und Entfernen des Devices /dev/drbd0, damit kein Zugriff mehr darauf erfolgen kann.

Auch folgender Shortcut für diese beiden Befehle wäre möglich. Er ist auch zu empfehlen, wenn ein disconnect erfolgreich ist, ein detach aber nicht funktioniert.

2. Setzen des Status „Primary“ auf dem Slave.

Failover erzwingen, da Zugriff auf Master nicht mehr möglich ist:

Manchmal muss ein Failover erzwungen werden. Zum Beispiel kam es in der Vergangenheit bei einem Setup zu dem Problem, dass der Master bzw. primäre Server Out-Of-Memory war und der Zugriff nicht mehr funktionierte. Die Webserver konnten damit keine Seiteninhalte laden und auch „detached“ funktionierte nicht. Die Kommunikation zwischen den DRBD-Hosts war aber weiterhin vorhanden, so dass der Slave nicht mittels „drbdadm primary r0“ zum primären System gesetzt werden konnte. Hier könnte es helfen mittels IPTables den Zugriff vom defekten Master auf den Slave zu blockieren.

Punkt 7: Split Brain

Recovery aus Split Brain:

Auf dem vormals Primary:

auf dem vormals Secondary (Split Brain Survivor)