Menü
Ein Beitrag von Adacor

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

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.

, , ,

Die besten IT-News per E-Mail

Immer als Erster über brandaktuelle IT-Themen informiert sein!


Weitere Artikel zum Thema lesen

Was ist CoroSync?

Hosting, IT-News

Was ist CoroSync?

Die CoroSync Cluster Engine ist das Herzstück innerhalb eines Linux High-Availability-Clusters (Linux-HA), welche in Verbindung mit weiteren Komponenten für die Überwachung aller angeschlossenen Knoten...

weiter lesen

Beim Monitoring der Infrastruktur setzt ADACOR auf Nagios und Bacula

Hosting, IT Security

Beim Monitoring der Infrastruktur setzt ADACOR auf Nagios und Bacula

24/7 Monitoring der Infrastruktur und sicheres Backup sorgen für eine hohe Verfügbarkeit der Server-Infrastruktur.

weiter lesen

E-Commerce Hosting

Hosting

Neue Hosting-Lösung für E-Commerce

Adacor hat seine langjährige Erfahrung mit Produkten und Services zur Umsetzung von E-Commerce-Projekten jetzt erstmalig in einer Solution zusammengefasst.

weiter lesen


Neueste Nachrichten von Adacor

Cloud

Was macht Cloud-Dienste sexy?

Die reflexartige Antwort ist häufig mit dem Thema “Kostenersparnis“ verbunden. Doch dies sollte nicht einziges Ziel sein.

weiter lesen

IT-Compliance

IT Security

IT-Compliance mit System

Wie sich Gesetze und Regeln in der IT einhalten lassen. Ein Drei-Punkte-Programm zur Einhaltung von IT-Compliance.

weiter lesen

Passwortsicherheit – Jedes Zeichen zählt!

IT Security

Sicherheitslücke bei WordPress: So lässt sich Phishing verhindern

Neue Serverkonfiguration schützt einfach und effektiv beim Phishing von Reset-Links.

weiter lesen

Diese Website verwendet Cookies. Mit der weiteren Nutzung der Website stimmen Sie unserer Datenschutzerklärung zu.
Für weitere Informationen klicken Sie bitte hier.