DRBD ist die geläufige Abkürzung für Distributed Replicated Block Device. Bei der ADACOR kommt DRBD als „Allzweckwaffe“ zum Einsatz um einen Service hochverfügbar zu machen. Doch werfen wir zuerst einen Blick darauf, was DRBD genau darstellt.
So lässt sich aus technischer Sicht die Verteilung der Daten eines Block-Devices einer Festplatte oder Partition über das Netzwerk bezeichnen.
Hierzu verwendet DRBD standardmäßig das TCP-Protokoll über Port 7788 aufwärts, um Schreibzugriffe auf alle angeschlossenen Knoten zu replizieren.
Man kann DRBD auch als eine RAID1-Lösung über das Netzwerk kennzeichnen, in der es drei verschiedene Replikations-Modi gibt. Wobei letztere von DRBD als Protokolle bezeichnet werden:
1. Protokoll A – Asynchrone Replikation
In diesem Fall meldet DRBD nach einem lokalen Schreibzugriff auf der aktiven Node der Applikation den Schreibzugriff als beendet, sobald die Daten vollständig auf das lokale Block-Device geschrieben wurden und das Replikations-Paket im lokalen TCP-Puffer abgelegt wurde, um die Wartezeiten auf Abschluss der Schreiboperation innerhalb der Applikation so niedrig wie möglich zu halten.
Dieses Protokoll kommt vor allem zum Einsatz, wenn davon ausgegangen werden muss, dass die Replikation über das Netzwerk entweder ausgelastet ist oder mit hohen Latenzen zu rechnen ist.
2. Protokoll B – Semi-Synchrone Replikation
Dieses Protokoll bietet etwas mehr Datensicherheit als Protokoll A, da die Applikation darauf wartet bis das Replikations-Paket über das Netzwerk seine Zielrechner (alle im Cluster befindlichen Knoten) erreicht hat. Erst dann meldet das DRBD die Schreiboperation als beendet und die Applikation wird weiter ausgeführt.
3. Protokoll C – Synchrone Replikation
Dies ist die sicherste und aus Sicht der Applikation langsamste Methode der Replikation. Bei der synchronen Replikation meldet DRBD die Schreiboperation erst als beendet, wenn das Replikations-Paket seine Zielrechner über das Netzwerk erreicht hat. Dazu muss jeder Knoten die Schreiboperation auf der physikalischen Festplatte abgeschlossen haben. Erst daran anschließend wird die Applikation weiter ausgeführt, die den Schreibzugriff ausgeführt hat.
Im Gegensatz zu einem echten RAID1 bietet DRBD keinerlei Performance Verbesserungen, da reine Lese-Zugriffe ausschließlich auf dem aktiven Knoten, d.h. lokal, erfolgen und nicht über das Netzwerk verteilt werden können.
Das am häufigsten eingesetzte Protokoll ist das Protkoll C. Es wird empfohlen, für die Replikation eine dedizierte Verbindung zwischen den Knoten zu verwenden, um keine unnötigen Wartezeiten innerhalb der Applikation zu erzeugen, weil z.B. das Netzwerk zu diesem Zeitpunkt ausgelastet ist.
DRBD kommt vor allem in Hochverfügbarkeitsumgebungen zum Einsatz, um im Fall eines Ausfalls eines Knotens im Clusterverbund, die Dienste auf einer anderen Maschine hochzufahren und möglichst den gleichen Datenbestand auf allen Knoten zu haben.
Cloud Journey für den Mittelstand
Die Grundlagen einer erfolgreichen Cloud Journey
- - Antworten auf Ihre wichtigsten Fragen der Cloud Migration.
- - Handfeste Beispiele für unterschiedliche Szenarien
- - In drei Stufen ein digital erfolgreiches Unternehmen werden
Anwendungsmöglichkeiten von DRBD
- Klassische Hochverfügbarkeitslösungen innerhalb eines Cluster-Verbunds im activ/ passive Modus.
- Vorhalten und Replikation von Datenbanken auf Dateisystemebene, ohne eine Replikation auf Applikationsebene einzurichten.
- Verschachtelung und Replikation von Daten über mehrere Knoten hinweg (Three-Node-Setup)
Durch ein sog. Device-Stacking ist es ebenfalls möglich weitere Knoten in einen Active-Passive Cluster hinzuzufügen, der außerhalb des Clusters ebenfalls die Daten aus dem DRBD-Verbund vorhalten kann.
Damit ist es möglich außerhalb eines Active-Passive Failover-Clusters, die Daten auf eine Maschine zu replizieren.
Bei der Umsetzung lassen sich die verschiedenen Protokolle von DRBD miteinander kombinieren, um die bestmögliche Performance innerhalb des Cluster-Verbunds zu erhalten.
Einsatz von DRBD bei ADACOR
Wir nutzen DRBD als „Allzweckwaffe“, um einen Service hochvergfübar zu machen. Viele Services bieten eingebaute Mechanismen zur Hochverfügbarkeit, z. B. MySQL Replikation. Bei Services, die dies nicht leisten oder deren Konfiguration und Betrieb dadurch sehr aufwendig wird, setzen wir DRBD im Failovercluster ein. So basiert zum Beispiel die Storagecluster unserer Cloud Infrastruktur auf DRBD.
Aktuell haben wir DBRD eingesetzt, um für ein Kundenprojekt das CMS Firstspirit hochverfügbar zu machen. Gemeinhin wird von e-spirit eine SAN-Lösung eingesetzt die mit wesentlich mehr Kosten verbunden ist. Gemeinsam mit einem Geschäftspartner haben wir die Variante mit DRBD erarbeitet. In Zusammenarbeit mit Corosync und Pacemaker sind automatische Failover ohne Impact auf die bereitgestellten Services möglich.
Vorteile und Nachteile von DRBD
DRBD hat den Nachteil, dass lediglich ein Knoten (der aktive) vollständigen Lesezugriff auf die Daten innerhalb eines DRBD-Clusters hat. Dieser Nachteil liegt jedoch nicht ursächlich im DRBD, sondern in den sich darüber befindenden Dateisystemem (ext3, extf, xfs).
Mit dem Einsatz von DRBD im Gegensatz zu gemeinsam genutzten Speichersystemen innerhalb eines Clusters, fällt der dadurch entstehende Single Point of Failure weg, da ein aktiver Cluster Knoten immer lokal auf die vorhandenen Daten zugreift.
Im Falle eines Fehlers auf dem aktiven Knoten findet im Idealfall ein Failover auf den nächsten Cluster-Knoten statt, der dann alle Aufgaben des ausgefallen Knotens übernimmt und dann auf alle Daten innerhalb des DRBD zugreifen kann.
