Die Spiegelung von Servern ist heute das gängigste Mittel, um redundante Ressourcen zu schaffen und damit eine hohe ausfallsichere IT-Umgebung (HA – High-Availability) zu gewährleisten. Das Konzept sieht vor, einzelne mögliche Ausfallverursacher ("Single Points of Failure" oder "SPoF") zu identifizieren und die Ausfallwahrscheinlichkeit durch mehrfach vorhandene Ressourcen zu reduzieren. Denn ein Fehler im schwächsten Glied einer Systemkette verursacht einen Ausfall des Gesamtsystems.
Erfahrungswerte zeigen, dass die Hardware für die meisten Ausfälle verursacht und deswegen der größte Risikofaktor ist. Andererseits ist der Ansatz, Software redundant zu halten, kaum praktikabel und verursacht einen zu hohen Administrationsaufwand. Ein Single-System in der IT besitzt daher, um als ausfallsicher gegen einen SpoF zu gelten, wenigstens je zwei Netzteile, Prozessoren, Ethernet- und/oder HBA-Verbindungen (Fibre Channel, InfiniBand, Fibre Connection) sowie ein Raid-Speichersystem. Eine größere Ausfallsicherheit erhält man durch den Einsatz von zwei Komplettsystemen, wie beim von unserer Schwesterpublikation TecChannel getesteten Hochverfügbarkeits-Cluster. Dabei wird das Master-System auf ein sekundäres System gespiegelt und über die Software "heartbeat" überwacht. Bei Ausfall des Masters übernimmt das sekundäre System dessen Funktionen.
Wichtig ist allerdings, dass das sekundäre System mit denselben Daten agieren kann wie der Master. Hier kann man entweder ein teures Shared-Storage-System einsetzen oder die Daten vom Master zum Slave replizieren. Bei einem reinen Datenbankserver ist das noch relativ einfach zu realisieren, denn die meisten Datenbanken verfügen über einen eingebauten Mechanismus zur Replikation der Daten.
Deutlich aufwendiger wird die ganze Sache jedoch, wenn auch Dateien repliziert werden sollen, etwa Konfigurationen oder Web-Inhalte. Hier kann man sich händisch per rsync ein Verfahren zusammenstricken oder gleich auf DRBD setzen und eine für die Anwendung transparente Datenreplikation implementieren.
Distributed Replicated Block Device
Raid 1 (Mirroring) auf reiner Festplattenbasis kopiert Blöcke auf ein anderes, aber meist gleich aufgebautes Speichermedium im System selbst. Die Entfernung zwischen den Datenträgern ist nur gering, dafür sind Bandbreite und Performance recht hoch. Möchte man diese Spiegelung über Systeme vornehmen, die einige Kilometer voneinander entfernt aufgebaut sind, bietet sich eine Verbindung über das Internet an. Hier kommt etwa das "Distributed Replicated Block Device" (DRBD) als Steuerungsinstanz für diesen Kopierprozess zum Einsatz.
Bei DRBD handelt es sich um einen Blockdevice-Treiber für Linux, der speziell für den Aufbau von Hochverfügbarkeits-Clustern entwickelt wurde. DRBD kann Datenblöcke über das verbindungsorientierte TCP/IP Protokoll transferieren – und arbeitet damit quasi als Netzwerk-Raid 1.
Günstigstenfalls nutzt man einen dedizierten (Ethernet-)Link für die DRBD-Verbindung. Jedes beliebige R/W-Blockdevice für die Daten (unter Linux "/dev/[hs]daX") kann dazu verwendet werden. Eine so genannte Block-Map dient dazu, das Datenaufkommen für die Replikation zu minimieren, in dem nur geänderte Blocke transferiert werden.
Beide Endsysteme von DRBD müssen bereit sein, um eine Verbindung über TCP/IP zu etablieren. Ist es einer der Partner nicht, muss definiert werden, was passieren soll. Über Timeouts wird dieses Verhalten gesteuert, damit nicht beide Seiten blockiert sind, wenn die Gegenseite Datenpakete nicht beantwortet.
DRBD wurde von Philipp Reisner (Firma Linbit) unter der Lizenz der GPL entwickelt. Zusammen mit seinem Kollegen Lars Ellenberg wartet Philipp Reisner die Software und entwickelt sie weiter. Der kommerzielle Nachfolger "DRBD+" erlaubt einen Abgleich über drei anstelle von zwei Block-Devices bis 16 TB und einen Multi-Primary-Betrieb. Die Quellen von DRBD stehen unter http://oss.linbit.com/drbd/ zur freien Verfügung.
Anwendungen für DRBD
Mit DRBD lässt sich beispielsweise der Zugriff auf eine Datenbank an einer Firmenaußenstelle optimieren, indem eine Kopie der Daten vor Ort gehalten wird. Kopie heißt in diesem Fall kein Zugriff, so lange die originale Datenbank, das heißt das Blockdevice, im Status "primary" aktiv ist. Im Fehlerfall würde die Datenbank diese gespiegelten Daten nutzen und so den Service aufrechterhalten können.
Ein Webserver in Amerika kann seine Daten auf einen Webserver in Europa spiegeln und so den Zugriff im Fehlerfall auf den europäischen Server umlegen. Eine re-dundante Datenhaltung ist in den meisten Clustern eine Grundvoraussetzung.
Ohne DRBD wird dies in Form von so genannten shared Storages realisiert, also gemeinsam genutztem Speicher (SAN). Dieser Speicher muss, da nur einmal vorhanden, im Storage-System (SAN) gespiegelt werden (Raid 1, Raid 5), um redundant vorhanden zu sein.
Mit DRBD lässt sich diese doppelte oder dreifache (DRBD+) Datenhaltung im Gegensatz zu einem hochverfügbaren Storage Area Network auch mit preiswerten Standard-Festplatten realisieren.
Funktionsweise in der Praxis
DRBD arbeitet bis Version 0.7 nach dem Primary-Secondary-Prinzip (analog Master-Slave) und kopiert Blöcke immer vom primären zum sekundären System, wobei die Rollenverteilung dynamisch verändert werden kann. In der Regel kommt ein Blockdevice ("/dev/sdXy"), also eine Partition der Festplatte oder gar die ganze Festplatte zum Einsatz.
In den meisten Linux-Distributionen ist DRBD bereits in den Kernel integriert (als Modul "drbd"). Wird das Modul in den Kernel geladen, stehen die Device-Knoten "/dev/drbdX" zur Verfügung – je nach Einstellung in der Konfigurationsdatei "/etc/drbd.conf" (siehe Kasten "Device-Knoten" auf der nächsten Seite). Hier ist das Modul "drbd” in den Kernel geladen, es sind zwei DRBD-Devices angelegt und die Kernel-Prozesse sind gestartet.
Damit sind die wesentlichen Voraussetzungen für die Funktion bereits gegeben. Je nachdem, welches DRBD-Device in der Konfiguratiosdatei zugeordnet wurde, sind pro Device die drei Prozesse aktiv:
• zdrbdX_receiver
• zdrbdX_asender
• zdrbdX_worker X:0..n
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.