Konfigurationsbeispiel
Nehmen wir vier gleich große Partitionen "/dev/sda1" und "/dev/sda2" auf Server alpha und "/dev/sdb3" und "/dev/sdb1" auf Server beta – und ernennen alpha zum Primärsystem für "sda" und beta für "sdb1". Dann müssten die Daten, die wir auf das Blockdevice "/dev/sda1" schreiben, irgendwie auf das Blockdevice "/dev/sdb3" auf beta gelangen.
DRBD klingt sich nun transparent ein, und zwar so, dass wir "/dev/sda1" und "/dev/sdb3" als DRBD-Device "/dev/drbd1" definieren. Im nächsten Schritt mounten wir unser Dateisystem "/test1" von alpha nicht mehr von "/dev/sda1", sondern von "/dev/drbd1". Auf alpha können wir mit "/test1" nun ganz normal arbeiten. Kopieren wir nun die Datei testfile.txt auf "/test1", schreibt der Kernel die vom Dateisystem belegten Blöcke lokal auf "/dev/sda1" und der DRBD-Treiber diese Daten transparent auch auf "/dev/sdb3" auf beta, und somit sind beide /test1-Dateisysteme auf beiden Systemen identisch. Analog gilt dies für DRBD0.
Sobald alpha als Primary für DRBD1 definiert ist, synchronisiert der DRDB-Treiber beide Block-Devices miteinander, und in Folge müssen nur noch die Differenzen im Betrieb abgeglichen werden. Die Metadaten geben Auskunft darüber, welche Datenblöcke zu synchronisieren sind. Die Netzwerk-bandbreite, die für diese Synchronisierung zur Verfügung steht, stellen Sie in der Konfigurationsdatei ein (Syncer: rate 10M).
Lesezugriffe und Journaling-Filesysteme
Ein lesender Zugriff erfolgt immer vom lokalen Disksystem. Der Schreibvorgang muss auf allen Systemen entweder lokal oder remote erfolgen und kann je nach Protokoll auch den Schreibprozess auf dem Primärsystem verzögern. Metadaten von so genannten Journaling-Dateisystemen müssen in der richtigen Reihenfolge auf die Disk geschrieben werden, beispielsweise muss das so genannte "Commit Record" als letztes in den Journal-Bereich geschrieben werden. Da Linux auf den Abschluss solcher zwingender Schreiboperationen wartet, bis es neue Schreibzugriffe erlaubt, kommt es zu Blockierungen. Dies muss der DRBD-Treiber koordinieren.
Seit Version 0.7 lässt sich ein so genanntes "active set" mit vorgegebener Größe definieren. Damit dauert die gesamte Synchronisation zwischen einer und drei Minuten abhängig von der Device-Größe.
Sicherheit und Performance
Drei Protokolle (ABC) erlauben je nach Erfordernissen der Anwendung (Sicherheit beziehungsweise Performance) unterschiedliche Arten von Quittierungen des Schreibvorgangs an den Secondary:
Protokoll A: Bei dieser Variante signalisiert der Treiber das lokale Schreiben auf der Disk und das Verlassen des Pakets über das Netzwerk-Interface. Ob das Paket auch auf der anderen Seite ankommt, bleibt offen. Dieses Protokoll eignet sich nicht für transaktionsbasierte Anwendungen.
Protokoll B: Funktioniert analog zu Protokoll A. Hier meldet der Treiber jedoch erst dann einen Erfolg, wenn die Daten lokal geschrieben wurden und die Gegenseite den Empfang quittiert hat. Fällt die Gegenseite aus, bevor die Daten physisch geschrieben worden sind, gibt es eine Inkonsistenz zwischen den beiden Systemen. Da hier auf eine Quittierung gewartet wird, sollte dieses Protokoll nicht bei Verbindungen mit hohen Latenzzeiten eingesetzt werden, da die Senderseite zu stark ausgebremst wird.
Protokoll C: Dies ist das transaktionssicherste Protokoll, da es einen erfolgreichen Schreibvorgang dann zurückmeldet, wenn die Blöcke auch auf der Secondary-Seite erfolgreich auf das physische Medium geschrieben worden sind.
Für die interne Map alloziert DRBD pro Gigabyte Diskspeicher 32 KB Hauptspeicher, und dieser Wert skaliert linear. Für seine Metadaten, die intern und extern abgelegt sein können, nutzt DRBD für 1 GB Blockdevices 2 MB und für 4 TB Devices 128 MB Metadaten.
Multi-Primary-Betrieb
Herkömmliche Dateisysteme (xfs, jfs, ext3) erlauben nur einen Zugriff pro System. Würde ein zweites System parallel darauf schreiben, käme es zu Inkonsistenzen, da das erste System davon nichts mitbekäme und seinen Datenbestand für aktuell hält. So genannte Cluster- oder Global-Dateisysteme erlauben den gleichzeitigen Zugriff schreibend und lesend von mehreren Systemen aus. Vertreter diese Art sind beispielsweise das Oracle Cluster Filesystem 2 (OCFS2) oder das AIX Global Filesystem (GFS). OCFS2 ist seit Kernel 2.6.16 Bestandteil des Linux-Kernels. Bei diesen FileSystemen unterstützt DRBD seit Version 8.0 auch den Multi-Primary-Betrieb, bei dem beide Systeme als primär agieren und schreiben dürfen.
Schutz vor Anwenderfehlern
DRBD schützt den Benutzer automatisch vor einigen der gängigsten Fehler in der Bedienung:
• Während DRBD den Deviceknoten "/dev/sda1” nutzt, kann diese nicht nativ gemountet werden ("mount /dev/sda1 /test1").
• Aktivieren des Primary auf beta, während alpha ebenfalls Primary ist ("beta> drbdadm primary r1")
Man könnte nun auf beta das Dateisystem (das Blockdevice) schreibgeschützt (read-only) mounten, in der Regel wird aber eine Cluster-Software (heartbeat) zum Einsatz kommen und nur das Dateisystem des Primary mounten. Ab Version 8.0.x können beide Seiten das Filesystem als Primary nutzen, wenn ein Shared-Filesystem wie GFS oder OCFS2 eingesetzt wird (Option: "net { allow-two-primaries }").
Für den automatischen Start von DRBD bringen die meisten Linux-Distributionen bereits ein passendes SysV-Startscript unter "/etc/init.d/drbd" mit, so dass Sie lediglich den Dienst aktivieren müssen.
Dieser Beitrag stammt aus der CW-Schwesterpublikation Tecchannel.