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.
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:
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:
Kommt es in einem solchen Szenario zum Ausfall eines Cluster-Knotens, führt der ClusterManager auf dem überlebenden Knoten die folgenden Schritte aus:
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.
Activity Log
Schreiboperation reicht DRBD an das lokale Blockgerät weiter, schicktden Datenblock aber auch gleichzeitig über das Netzwerk. Fällt der aktive Knoten aus, kann es aufgrund des zufälligen Timingverhaltens dazukommen, dass zu diesem Zeitpunkt die lokale Schreiboperation bereitsabgeschlossen ist, nicht aber das Versenden über das Netzwerk. DiesenDatenblock gilt es daher wieder zu entfernen, sobald der ausgefalleneKnoten wieder verfügbar ist. DRBD führt zu diesem Zweck das ActivityLog (AL). Als Teil der DRBD-Metadaten führt das AL Buch, welche Blöckein letzter Zeit beschrieben wurden. Existierte das AL nicht, müsste DRBDnach jedem Ausfall eines aktiven Knotens bei dessen Wiederherstellungdas gesamte Device neu synchronisieren.Die Größe des AL ist konfigurierbar, und es lässt sich an die gewünschteResynchronisationszeit sowie an den Durchsatz des zugrunde liegenden