HA-Workshop, Teil 7: GFS mit DRBD und Pacemaker

Nichts exklusiv

Cluster-Dateisysteme wie GFS2 und OCFS2 ermöglichen vielen Clients den gleichzeitigen Zugriff auf ein Storage-Device. Dank DRBD und Pacemaker wird der Dienst so auf günstige Weise redundant – allerdings hat die Sache ein paar Haken.
Wer sein System permanent überwacht, hat den Grundstein dafür gelegt Engpässe zu vermeiden und Fehler frühzeitig zu erkennen. Neben dem Platzhirsch Nagios ... (mehr)

Auf Cluster-Dateisysteme trifft man häufig in Hochverfügbarkeitsclustern. Die bekanntesten Filesysteme dieser Art sind GFS2 und OCFS2, aber auch Lustre genießt einiges an Aufmerksamkeit und NFS bietet in Version 4 einen ähnlichen Dienst an (pNFS). Über den Sinn und Unsinn von Cluster-Filesystemen lässt sich trefflich streiten (siehe auch den Kasten "Die Gefahren von DRBD im Dual-Primary Modus"). Wenn aber die Entscheidung für ein solches Dateisystem gefallen ist, dann helfen Pacemaker und DRBD dabei, den Dienst hochverfügbar zu machen.

Der folgende Artikel beschreibt am Beispiel von GFS, wie sich auf aktuellen Systemen Pacemaker zum Cluster-Manager für Cluster-Dateisysteme aufschwingt. Leider gibt es unter den vier "großen" Enterprise-Distributionen – Debian, Ubuntu, SLES und RHEL – einiges an Uneinigkeit darüber, wie ein Setup dieser Art am besten aussehen sollte. Ein dicker Riss trennt dabei insbesondere Red Hat von den anderen drei Distributionen.

Zur Geschichte von GFS

Das Cluster-Dateisystem GFS existiert im Grunde bereits seit 1995, richtig an Verbreitung gewann die Software allerdings erst als Red Hat den damaligen Hersteller Sistina im Jahre 2005 kaufte und anfing, die Entwicklung voranzutreiben. Offiziell hielt GFS Einzug in Linux, als Linus Torvalds es zum Bestandteil der Kernelversion 2.6.19 machte. GFS2 war damit später dran als OCFS2, das es schon in den Kernel 2.6.16 schaffte.

GFS setzt im Kernel auf die Strukturen des Distributed Lock Managers (DLM). Diese Software, die ebenfalls aus der Feder von Red-Hat-Entwicklern stammt, ist im Wesentlichen ein großes Framework, das den gleichzeitgen Zugriff auf Storage-Ressourcen koordiniert. GFS2 funktioniert nur, wenn der Distributed Lock Manager aktiv ist und keine Probleme hat. Red Hats Wunsch, auch andere Software-Produkte mögen den DLM verwenden, ging in Erfüllung: cLVM, die Cluster-Variante von LVM, verwendet den DLM ebenfalls – wohl nicht zuletzt deshalb, weil Red Hat massiv an der LVM-Entwicklung beteiligt ist.

Wer DLM und GFS nutzen möchte, muss dafür einerseits sicherstellen, dass die entsprechenden Kernel-Module geladen sind. Andererseits braucht jede der beiden Komponenten auch ein Gegenstück im Userland, welches die Kommunikation mit den Kernel-Modulen übernimmt und eine Schnittstelle für andere Programme bietet. Ein Control-Daemon für GFS sorgt beispielsweise dafür, dass zwischen den Knoten eines GFS-Clusters tatsächlich auch der gewünschte Datenaustausch stattfindet.

Und genau hier liegt der Hund begraben: Um sich die Arbeit zu ersparen, einen eigenen Cluster-Manager für GFS zu implementieren (so, wie es zum Beispiel Oracle bei OCFS2 gemacht hat), waren bei GFS die Control-Daemons und der Red-Hat-eigene Cluster-Manager »Cman« stets eng verzahnt. Was sich aber in den letzten drei Jahren bei der Integration von GFS in die verfügbaren Cluster-Manager abspielte, mutet für Außenstehende an wie eine schlechte Komödie.

Tunnelblick

Als sich Corosync – maßgeblich von Red Hat propagiert – als Lösung der Zukunft in Sachen Cluster-Kommunikation herausstellte, gewann Pacemaker zusehends an Bedeutung. Red Hat stellte daraufhin für den DLM wie auch für GFS sogenannte »Control Daemons« her, mit denen sich die Software in Pacemaker integrieren ließ. Die Binaries dafür heißen »dlm_controld.pcmk« und »gfs_controld.pcmk« und werden aus Pacemaker heraus wie alle anderen Ressourcen auch über Resource Agents gestartet. Weil sowohl der DLM als auch GFS zwischenzeitlich zu Teilen von Red Hats Cluster Suite (RHCS) geworden waren, wurden auch die Control-Daemons für Pacemaker mit der RHCS zusammen ausgeliefert. Bis einschließlich RHCS 3.0 war die Welt also in Ordnung, wenn Pacemaker und GFS zusammen funktionieren sollten.

In der Red Hat Cluster Suite 3.1 kam dann allerdings der Sinneswandel: Red Hat beschloss, sein eigenes Cluster-Produkt massiv umzubauen. Das führte dazu, dass Pacemaker – dessen Hauptentwickler in der Zwischenzeit von Red Hat engagiert worden war – eine Schnittstelle für Cman bekam. Über diese sollte der CRM dann mit den Tools kommunizieren, die den DLM und GFS kontrollieren. In den Augen Red Hats waren die Pacemaker-Control-Daemons für DLM und GFS damit überflüssig, sie wurden kurzerhand entfernt.

Novell hat allerdings aus nachvollziehbaren Überlegungen heraus große Skrupel, die RHCS zum Bestandteil des eigenen Produktes zu machen, obwohl das lizenztechnisch freilich möglich wäre. Stattdessen pflegt Suse künftig die alten Control-Daemons der RHCS 3.0 auf eigene Faust weiter. Derzeit gibt es also zwei Methoden, um GFS auf Linux mit Pacemaker zu verheiraten – und sie unterscheiden sich stark voneinander: Auf RHEL 6 braucht es Pacemaker mit Cman-Integration, auf Debian, Ubuntu und SLES kommt hingegen die alte Variante zum Einsatz, die eigene Control-Daemons in Pacemaker für DLM und GFS vorsieht.

Die nächste grundlegende Änderung im Hinblick auf GFS kommt übrigens ganz bestimmt: Die weiteren Pläne von Red Hat sehen vor, Cman komplett durch Pacemaker zu ersetzen. In nicht allzu ferner Zukunft ist deshalb damit zu rechnen, dass Red Hat die Control-Daemons für Cman kompatibel mit Pacemaker macht – um genau dort anzukommen, wo das Unternehmen in Version 3.0 der RHCS schonmal war.

Grau ist alle Theorie, deshalb folgen nun Taten: Den Anfang macht ein GFS-Cluster-Setup für Debian, Ubuntu und SLES. Debian und Ubuntu liefern Pacemaker in ihren Standard-Distributionen zwar mit, allerdings ist die feilgebotene Version bereits etwas angestaubt. Im Ubuntu-HA-PPA [1] oder im Backports-Verzeichnis für Squeeze [2] finden sich für die Systeme aber aktualisierte Pacemaker-Pakete. Wer SLES auf seinen Servern einsetzt, braucht für GFS die High Availability Extension (HAE), in der die Pakete für GFS enthalten sind. Alternativ finden sich im Internet auch Pakete von Drittanbietern.

comments powered by Disqus

Artikel der Woche

Setup eines Kubernetes-Clusters mit Kops

Vor allem für Testinstallationen von Kubernetes gibt es einige Lösungen wie Kubeadm und Minikube. Für das Setup eines Kubernetes-Clusters in Cloud-Umgebungen hat sich Kops als Mittel der Wahl bewährt. Wir beschreiben seine Fähigkeiten und geben eine Anleitung für den praktischen Einsatz. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite