Duell der Datenbanken: In einem Shootout messen sich MySQL und PostgreSQL. Der Schwerpunkt vom ADMIN 06/2011 überprüft, wer schneller ist und gibt einen ... (mehr)

Anpassen der DRBD-Konfiguration

»drbdadm« ist das Werkzeug, mit dem Admins ihre DRBD-Ressourcen auf der Kommandozeile verwalten sollen. Im Hintergrund ruft es »drbdsetup« auf, das die Kommunikation mit DRBDs Kernel-Modul abwickelt. »drbdsetup« hat aber auch noch einen anderen Nutzen: Mit ihm lassen sich im laufenden Betrieb zumindest einige Konfigurationsparameter einer Ressource anpassen. Das beste Beispiel dafür ist die Syncer-Rate, die festlegt, wie viel Bandbreite die DRBD-Resynchronisation höchstens in Anspruch nehmen darf. Wenn nach längeren Ausfällen große Mengen an Daten zu resynchronisieren sind, wirkt sich das unter Umständen negativ auf die Performance des Storage-Systems aus. Mittels »drbdset-up« lässt sich das unterbinden. Um die Synchronisationsrate so anzupassen, lautet der korrekte Befehl »drbdsetup /dev/drbd Minor -r Rate « . »Minor« ist dabei durch die Minor-Nummer der Ressource zu ersetzen und »Rate« durch die gewünschte Rate samt Größeneinheit, also beispielsweise »60M« für 60 Megabyte pro Sekunde.

Änderungen an der DRBD-Konfiguration, die so vorgenommen werden, sind nach dem nächsten Neustart der Ressource verschwunden. Sollen sie permanent sein, empfiehlt sich eine andere Funktion, diesmal wieder von »drbdadm« : der »adjust« -Befehl. Er liest die derzeit auf der Platte liegende Config ein und passt die Parameter der gerade laufenden Ressourcen entsprechend an. Eine Änderung in der Konfigurationsdatei einer Ressource mit anschließendem »drbdadm adjust Ressource « führt also ebenfalls dazu, dass die neue Konfiguration on-the-fly aktiv wird – und nach dem nächsten Neustart noch vorhanden ist. Vorsicht ist bei »drbdadm adjust« trotzdem geboten: Manche Parameter müssen auf beiden Hosts zwingend identisch sein, sonst trennt DRBD die Verbindung zwischen den Clusterknoten. Genauere Informationen enthält der DRBD User's Guide unter [2] .

Split-Brain-Situationen mit DRBD

DRBD ist darauf ausgelegt, dass der eine Knoten eines Clusters weiß, was der andere Knoten gerade tut – oder sicher annehmen kann, dass der zweite Knoten außer Betrieb ist. Aus diesem Grunde sei dringend dazu geraten, dass zwischen zwei Clusterknoten mindestens zwei Kommunikationspfade existieren, um auch den Ausfall beispielsweise eines Switches noch zu kompensieren.

Verlieren beide Clusterknoten zu irgendeinem Zeitpunkt all ihre Pfade zur Kommunikation, während sie ansonsten noch funktionstüchtig sind, so ist das für den Cluster eine Katastrophe. Denn solch ein Szenario führt zwangsläufig zu Datenkorruption. Die Clustermanager auf beiden Seiten des Clusters glauben, der andere Clusterknoten sei weg und sie müssten sofort sämtliche Cluster-Dienste alleine anbieten. Solange eine DRBD-Ressource auf einem Host den Diskstate »UpToDate« hat, hindert der DRBD-Treiber den Cluster Resource Manager nicht daran, die Ressource in den primären Modus umzuschalten. So nimmt das Unglück seinen Lauf: Pacemaker macht genau das auf beiden Clusterknoten. Und wenn wenigstens ein Kommunikationspfad wieder funktioniert und die Ressourcen die Verbindung wiederherstellen könnten, stellen sie fest, dass auf beiden Seiten unterschiedliche Veränderungen passiert sind. Dieses Szenario heißt "Split-Brain": Alleine weiß der Cluster nun nicht mehr, welcher der beiden Datensätze der Richtige ist.

Fakt ist: Sollen nicht die Inhalte der beiden Ressourcen händisch wieder zusammengeführt werden, geht definitiv einer der Datensätze verloren. Im DRBD-Sprachgebrauch ist vom "Split-Brain Victim" und vom "Split-Brain Survivor" die Rede. Die Daten von Ersterem gehen den Bach runter, Letztere bleiben erhalten.

comments powered by Disqus
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

Ausgabe /2023