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.

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

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019