HA-Serie, Teil 8: OCF-Agenten selbst programmieren

Agentenausbildung

Wer die Fähigkeiten von Pacemaker und besonders die Monitoring-Funktion bestmöglich ausnutzen möchte, setzt auf Resource Agents nach OCF-Standard. Gibt es für ein bestimmtes Programm noch keinen, heißt es Hand anlegen.
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)

In den bisherigen Artikeln der HA-Serie spielten die Resource Agents eine eher untergeordnete Rolle, sie waren im Wesentlichen Erfüllungsgehilfen. Die unscheinbare Schicht der Agents im Cluster-Stack ist in Wirklichkeit aber von großer Bedeutung für die Funktionalität des gesamten Clusters. Denn nur wenn die Resource Agents gut funktionieren, kann der Cluster seine Aufgabe perfekt wahrnehmen. Deshalb sind qualitativ hochwertige Resource Agents wichtig. Wenn für ein bestimmtes Programm ein guter Agent fehlt, dann kann es sich für den Admin des Clusters durchaus lohnen, selbst einen OCF-kompatiblen Agent aus der Taufe zu heben. Das erspart ihm in Zukunft wahrscheinlich viel Ärger, denn nicht standardkonforme Init-Skripte, die sich in Pacemaker ja als LSB-Klasse verwenden lassen, bringen den Cluster schnell aus dem Tritt.

Wer schon mal in der Nacht einen Samba-Cluster repariert hat, weil das Samba-Init-Skript, das Debian liefert, das »monitor« -Target nicht ordentlich unterstützt, kann hiervon ein Lied singen.

Wo Resource Agents ansetzen

Der Linux-Cluster-Stack besteht aus mehreren Komponenten – Corosync oder Heartbeat übernehmen die Cluster-Kommunikation, Pacemaker kümmert sich um die Cluster-Dienste (im Fachjargon "Ressourcen") und die Storage-Komponente ist in der Mehrzahl der Fälle DRBD. Die Ressourcen-Schicht, also Pacemaker, besteht intern aus mehreren einzelnen Teilen, die ineinandergreifen, um den Cluster bestmöglich zu steuern ( Abbildung 1 ). Pacemaker selbst ist der »crmd« , der clusterweite Resource Manager, der sicherstellt, dass insgesamt alle konfigurierten Dienste wie gewünscht gestartet sind. Er läuft auf jedem System, genauso wie der » lrmd« , der »Local Resource Management Daemon« . Der »lrmd« kommt aus dem »cluster-glue« -Paket, dessen Installation Voraussetzung für Pacemaker ist. Er nimmt Befehle von »crmd« entgegen und setzt sie adäquat um. Auch der »lrmd« startet selbst allerdings keine Programme – an dieser Stelle kommen die Resource Agents ins Spiel, denn diese ruft der »lrmd« auf, wenn ein Dienst auf einem Cluster-Knoten in Bewegung zu setzen ist.

Abbildung 1: Deutlich zu erkennen sind die Prozesse

Resource Agents kommen üblicherweise aus drei verschiedenen Kategorien oder Klassen: LSB Agents sind Init-Skripte und liegen im Ordner »/etc/init.d« . Heartbeat Agents sind für den nunmehr veralteten Heartbeat 1 gedacht und gelten als deprecated. Die dritte und höchste Klasse sind die OCF Resource Agents. Sie folgen dem »Open Cluster Framework« -Standard, der spezifisch erfunden wurde, um qualitativ besonders hochwertige Agents zu ermöglichen. Wer in der Cluster-Welt etwas auf sich hält, verwendet diese Agent-Klasse bevorzugt.

Die Vorteile von OCF

Welche Vorteile bietet der OCF-Standard genau? Zunächst haben Admins dank der OCF-Spezifikation die Möglichkeit, Konfigurationsparameter einer Ressource direkt in der CRM-Konfiguration von Pacemaker festzulegen. Pacemaker gibt die Parameter unverändert an den Resource Agent weiter, der die Informationen dann in Befehle umsetzt. Ein klassisches Beispiel ist der Resource Agent, der sich um Cluster-IP-Adressen kümmert, also »ocf:heartbeat:IPaddr2« . Er bekommt per CRM-Konfiguration stets den Parameter »ip« mit auf den Weg und weiß so, welche IP die Cluster-IP ist. Ähnlich funktioniert der Filesystem-Agent, der aus der CRM-Konfiguration sämtliche Informationen bezieht, die er braucht, um ein Dateisystem zu mounten. Konfigurationsparameter funktionieren nur bei OCF-Agents, LSB-Skripte und Heartbeat Agents unterstützen das Feature nicht. Bei ihnen lassen sich zwar auch Parameter-Zeilen in der CRM-Shell eintragen, diese ignoriert Pacemaker aber vollständig.

Der zweite große Vorteil der OCF-Agents besteht darin, dass sie unabhängig von der Distribution funktionieren, auf der sie eingesetzt werden. Dadurch ist es problemlos möglich, eine Cluster-Konfiguration ohne Änderung von einem Debian-System auf ein SLES-System zu übernehmen. Man kann sogar den Resource Agent als File auf den anderen Rechner kopieren und dort laufen lassen – wenn er dem OCF-Standard folgt, wird er hüben wie drüben klaglos funktionieren. Die Interoperabilität erstreckt sich übrigens auch auf Nicht-Linux-Systeme: Theoretisch soll der Cluster-Stack auch auf den üblichen BSD-Derivaten funktionieren. Allerdings dürfte das bisher nur sehr rudimentär in der Praxis getestet worden sein. Prinzipiell gilt aber, dass ein Agent überall dort funktioniert, wo der Cluster-Stack ebenfalls funktioniert.Nicht zuletzt trifft der OCF-Standard auch detaillierte Aussagen darüber, welchen Rückgabewert ein Agent in Abhängigkeit bestimmter Ereignisse an den »lrmd« zu liefern hat. Auf diese Weise bekommt der Cluster-Admin schnell einen Überblick über Missstände, falls im Cluster etwas schiefläuft.

Die Gründe, auf OCF zu setzen, sind also vielseitig. Umso ärgerlicher ist es, wenn für eine bestimmte Applikation kein OCF-Agent vorhanden ist. Ein Grund zum Verzweifeln ist das aber nicht, denn mit den dazugehörigen Dokumenten und ein bisschen Bastelei lässt sich ein qualitativ hochwertiger Resource Agent nach OCF-Standard selbst herstellen.

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