Allen Unkenrufen zum Trotz ist die E-Mail nach wie vor das Kommunikationsmedium Nummer eins im Unternehmen. Deshalb geben wir in der Februar-Ausgabe eine ... (mehr)

Pacemaker ein Schnippchen schlagen

Admins wissen aus Erfahrung, dass DRBD in freier Wildbahn nur selten alleine auftritt. Häufig paart sich die Lösung mit Pacemaker, dem Cluster-Manager des Linux-HA-Stacks. Das ist nicht unbedingt ein Vorteil: Die Geschichte von Pacemaker führt über Heartbeat 2, den damaligen Nachfolger des ursprünglichen Heartbeats von Suse. Während es bei Heartbeat noch möglich war, den Cluster mittels einer einzelnen Konfigurationsdatei zu steuern, brachte Heartbeat 2 eine interne Konfiguration in XML ("CIB" für "Cluster Information Base") mit, in die Admins per XML-Snippet händisch Einträge einbauen sollten. Diese Aktion hat das Vertrauen in den Linux-HA-Stack so nachhaltig erschüttert, dass Pacemaker auf einer Beliebtheitsskala von 1 bis 10 bis heute die Note "Fukushima" bekommt – obwohl es mittlerweile brauchbare Konfigurationswerkzeuge gibt.

Auch aus Admin-Sicht nervt Pacemaker, gerade in der Kombination mit DRBD: Im Pacemaker-Sprech ist eine DRBD-Ressource stets eine "Master-Slave-Ressource", bei deren Verwaltung Pacemaker besondere Grundsätze beachten muss. Es reicht also nicht, die Ressource in Pacemaker als normale "primitive"-Ressource zu konfigurieren. Über den Umweg der Master-Slave-Ressource steuert Pacemaker den Zustand der DRBD-Ressource: Mittels des von Linbit bereitgestellten "drbd"-Resource-Agents schaltet er eine DRBD-Ressource in den "Secondary"- Modus, wenn sie in Pacemaker den "Slave"-Status erhält. Will Pacemaker jene DRBD-Ressource auf einem spezifischen Host nutzen, schaltet er sie dort in den "Master"-Modus und weist den "drbd"-Resource-Agent so an, sie auf Ebene von DRBD in den "Primary"-Modus zu versetzen.

Theoretisch klingt das gut – über das Konstrukt kann Pacemaker DRBD sinnvoll verwalten und dort in den Primary-Modus schalten, wo die Ressource aktiv genutzt werden soll. Doch die DRBD-Entwickler selbst haben bereits ihre Zweifel geäußert, ob das Konstrukt "Master-Slave-Resource" tatsächlich hilfreich ist. In der neuen Version von DRBD bieten sie deshalb eine Möglichkeit, das Problem bereits auf Ebene der Speichertechnologie zu umgehen. Das "Auto-Promote"-Feature sorgt dafür, dass eine DRBD-Ressource automatisch in den "Primary"-Modus übergeht, wenn sie auf einem Host genutzt werden soll – und auf allen anderen Hosts im Secondary-Modus läuft. Das rettet die DRBD-Entwickler freilich auch vor einem Haufen Anpassungen, die DRBD 9 auf Pacemaker-Ebene für den "drbd"-Resource-Agent nötig gemacht hätte.

drbdmanage übernimmt die Verwaltung

Zwei große Neuerungen hat der Artikel bis dato vorgestellt: Die Fähigkeit in DRBD 9, über mehrere Knoten zu replizieren, sowie das Auto-Promote-Feature, das Magie auf Ebene des Cluster-Managers überflüssig macht. Mit eben diesen Funktionen assoziieren die Admins DRBD 9 üblicherweise. Die wohl wichtigste Änderung für Admins sind allerdings beide Funktionen nicht. Admins werden sich besonders über "drbdmanage" freuen, das zusammen mit DRBD 9 seinen Einstand gibt und die Art und Weise verändert, wie DRBD-Ressourcen verwaltet werden (Bild 1).

Bild 1: Mittels "drbdmanage" lassen sich Ressourcen direkt auf der Kommandozeile anlegen.

Bisher haben Administratoren die DRBD-Konfiguration semi-automatisch erledigt. Nach der DRBD-Installation legten sie eine Konfigurationsdatei für DRBD selbst und eine für jede DRBD-Ressource an. "drbdadm" erledigte dann den Rest und rief im Hintergrund "drbdsetup" auf, das die DRBD-Ressourcen im Kernel so konfigurierte wie vom Nutzer angegeben. Für Ressourcen zwischen zwei Knoten funktioniert dieser Ansatz zufriedenstellend. Für DRBD 9 allerdings, so war man bei Linbit sicher, würde man einen umfassenderen Ansatz benötigen. Robert Altnöder steuerte diesen Ansatz bei: "drbd­manage" ist ein Framework, das sich durch den Nutzer per Kommandozeile steuern lässt und im Hintergrund für DRBD passende Konfigurationsdateien generiert und lädt.

Geschrieben ist die Umgebung in Python, außerdem verwendet sie DBus, um mit den anderen Systenkomponenten zu kommunizieren. Im Hintergrund setzt sie zudem auf LVM: Den verfügbaren physischen Speicher stellt der Admin in Form von LVM-Physical-Volumes zur Verfügung, die "drbdmanage" sogleich in Beschlag nimmt. Mittels einer Reihe von "drbdmanage"-Befehlen auf der Kommandozeile sorgt der Admin dafür, dass das "drbd"-Kernel-Modul auf allen Hosts zur Verfügung steht. Danach legt er mittels "drbdmanage" einen MESH-Cluster an, dem alle beteiligten Knoten angehören.

Am Ende des Vorgangs nutzt der Admin "drbdmanage" dann bloß noch, um innerhalb dieses MESH-Clusters neue DRBD-Ressourcen anzulegen. Der Rest passiert quasi automatisch: "drbd-manage" legt entsprechende Konfigurationen an, startet auch die DRBD-Ressourcen und sagt dem Admin schließlich, auf welchen Hosts die neue Ressource zur Verfügung steht (Bild 2). Linbit vermarktet dieses Feature als Option für "nahtlose" Skalierbarkeit: Geht der verfügbare Platz für neue Ressourcen aus, hängt der Admin zusätzliche Knoten ins Rack und vergrößert so den Platz, der für "drbdmanage" zur Verfügung steht. Ganz so komfortabel wie Ceph oder GlusterFS mit ihren vielen Frontends ist die Lösung mit DRBD freilich nicht, verglichen mit den Vorgängerversionen ist DRBD 9 hier aber wirklich weiter. Der Wert von "drbdmanage" für Admins ist insofern gar nicht hoch genug zu schätzen.

Bild 2: "drbdmanage nodes" gibt einen schnellen Überblick darüber, welche Knoten gerade aktiv am Cluster beteiligt sind.

Das liegt auch daran, dass "drbdmanage" eine großartige Schnittstelle bietet, um die Automatisierung von DRBD 9 über verschiedene Frameworks zu realisieren. Wie "cephdeploy" bei Ceph müssen Puppet, Chef & Co. nämlich "drbdmanage" bloß noch installieren und anschließend angeben, welche DRBD-Ressourcen vorhanden sein sollen. Den Rest erledigt "drbdmanage" auf Zuruf automatisch, sodass in der Automatisierungslösung viele Funktionen gar nicht mehr zu implementieren sind. Der Autor dieses Artikels stellt unter [2] ein Puppet-Modul bereit, das die grundlegenden Schritte auf Systemen mit Ubuntu 14.04 übernimmt. Das Modul wickelt die Installation des DRBD-9-Kernelmoduls genauso ab wie jene von "drbd-utils" und "drbdmanage".

Abschließend erhält der Admin die Möglichkeit, per "drbdmanage" eigene Ressourcen anzulegen und zu nutzen. "drbd-utils" hat übrigens auch eine kleine, aber feine Änderung zwischen DRBD 8 und DRBD 9 durchgemacht: Künftig entwickelt Linbit Werkzeuge wie "drbdadm" & Co. unabhängig vom Kernel-Modul. Das geht mit dem Versprechen einher, die Kompatibilität von "drbdadm" mit verschiedenen DRBD-Versionen besser zu kontrollieren. Bisher sah der Admin häufig eine Kompatibilitätswarnung, wenn er ein "drbdadm" von DRBD 8.4 mit DRBD 8.3 im Kernel nutzte. Damit ist künftig Schluss.

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

Ausgabe /2022