Services mit Distributed Replicated Block Device (DRBD) hochverfügbar machen

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.

Services mit Distributed Replicated Block Device (DRBD) hochverfügbar machenMan 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.

Image

filoo ClouDEasy

Sie wollen eine sichere ClouD? Dann haben Sie diese mit ClouDEasy soeben gefunden. Hier bekommen Sie eine skalierbare Lösung, mit der Sie sofort loslegen können. Es gibt keine lange Einarbeitungszeit – diese ClouD funktioniert einfach. Jetzt direkt informieren  

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.

, , ,


Weitere Artikel zum Thema lesen

Wie das mit dem Backup und den Snapshots funktioniert

Hosting

Wie das mit dem Backup und den Snapshots funktioniert

Snapshots oder dateibasierte Einzelsicherung: Welche Backup-Szenarien sollen bei Ihnen möglich sein?

weiter lesen

ADACOR-Infrastruktur im Rechenzentrum von e-shelter

Cloud, Domains, Hosting, IT Security

ADACOR-Infrastruktur im Rechenzentrum von e-shelter

Die wichtige strategische Bedeutung sorgt für hohe Anforderungen an ein betriebssicheres RZ.

weiter lesen

Server Backup – So funktioniert es beim Hosting

Hosting

Server Backup – So funktioniert es beim Hosting

Ihre Fragen an unser Sales-Team. Welche Backup-Möglichkeiten bietet die ADACOR?

weiter lesen


Neueste Nachrichten von ADACOR

IT-News

Neue Ideen für Teamevents

Teamevents helfen, das Wir-Gefühl zu stärken, die Arbeitsmoral zu erhöhen und Mitarbeiter langfristig an das Unternehmen zu binden.

weiter lesen

Cloud

Hybrid Cloud in vielen Unternehmen bereits Realität

Einsatzmöglichkeiten der Hybrid Cloud und wieso sie die jeweiligen Nachteile von Private und Public Cloud minimiert.

weiter lesen

IT Security

Hintergründe und aktuelle Informationen zur WannaCry-Attacke

Zum Heulen - wie die bislang größte Malware-Attacke ihren Ausgang nahm und welche Gegenmaßnahmen möglich sind.

weiter lesen

Diese Seite verwendet Cookies, welche uns helfen, unsere Services anzubieten und zu verbessern.
Erfahren Sie mehr über unsere Cookie-Richtlinien. Durch die Nutzung dieser Website erklären Sie sich mit der Nutzung von Cookies einverstanden.