SPOF-Elimination

Eine oft übersehene Schwäche in konventionellen Cluster-Architekturen ist der Umstand, dass die verwendete Shared-Storage-Hardware selbst einen Single Point of Failure (SPOF) darstellt. Zwar legen Hersteller von Storage-Hardware grundsätzlich großen Wert darauf, ihre Subsysteme redundant auszuführen: Redundante RAID-Controller, Multipath-I/O und natürlich redundante Platten sind selbstverständlich. Was aber, wenn das Subsystem als Ganzes einer tropfenden Klimaanlage, Kondensfeuchtigkeit oder einem Brand ausgesetzt ist?

DRBD eliminiert diese Schwächen. Die durch DRBD synchronisierten Cluster-Knoten können sich im selben Rack ebenso wie in unterschiedlichen Brandabschnitten oder in unterschiedlichen Gebäuden befinden. Auch die geografische Verteilung (etwa der Betrieb in zwei verschiedenen Städten) ist ohne weiteres machbar, sofern nur eine Netzwerkverbindung mit brauchbarer Bandbreite und Latenz zur Verfügung steht. Natürlich bieten auch viele Hersteller von Storage-Hardware synchrone Datenreplikation auf Blockebene an, oft in Controller Firmware implementiert. Allerdings sind die Preise für entsprechende Hard- oder Software zumeist sehr hoch.

Integration in Cluster-Management-Software

DRBD ist grundsätzlich mit jedem Cluster-Manager zu betreiben; am häufigsten anzutreffen ist jedoch eine Implementation gemeinsam mit Heartbeat, dem Cluster-Manager aus dem Linux-HA-Projekt. Vor der Betrachtung der Integration in Heartbeat lohnt jedoch ein Blick auf all jene Operationen, die DRBD auch vollständig unabhängig vom Cluster-Manager beherrscht:

• Permanente, synchrone Replikation von Schreiboperationen vom primären zum sekundären Knoten,
• Effiziente Resynchronisation nach Ausfall eines Knotens,
• Manuelle oder automatische Bereinigung von Split-Brain-Situationen.

Was im Verantwortungsbereich des Cluster-Managers verbleibt, ist die Beförderung (Promotion) eines DRBD-Device in die primäre Rolle sowie die Degradierung (Demotion) in die sekundäre. Dies erfolgt typischerweise in Verbindung mit der Aktivierung und Deaktivierung anderer Cluster-Ressourcen, wie etwa Dateisystemen oder Applikationen. Zu den Ressourcen eines mittels DRBD hochverfügbar gemachten Datenbankservers würden beispielsweise folgende gehören:

• Ein DRBD-Blockdevice als Grundlage für die Datenbankdateien,
• Das auf diesem Blockdevice konfigurierte Dateisystem,
• Der Datenbank-Ressourcen-Agent selbst.

Kommt es in einem solchen Szenario zum Ausfall eines Cluster-Knotens, führt der ClusterManager auf dem überlebenden Knoten die folgenden Schritte aus:

• Beförderung des DRBD-Blockdevice in den Primary-Status,
• Wiederherstellung des auf diesem Device abgelegten Dateisystems (typischerweise durch eine Reparatur mittels »fsck« oder bei heutigen Dateisystemen realistischer durch ein Journal-Replay),
• Mounten dieses Dateisystems an seinem konfigurierten Mountpoint,
• Starten des Datenbankserver-Prozesses.

Durch die synchrone Natur der DRBD-Blockreplikation ist dabei gewährleistet, dass der Zustand des Blockdevice auf dem übernehmenden Knoten exakt dem des ursprünglich aktiven Knotens entspricht. Für Datenbankapplikationen ist dabei besonders der Umstand interessant, dass dies gleichzeitig auch Transaktionssicherheit impliziert.