| Seite 1: | Linux-Cluster in der Praxis |
| Seite 2: | Anwendungen für DRBD |
| Seite 3: | Konfigurationsbeispiel |
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.
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.
