OCF - Open Cluster Framework

In den ORDIX News 2/2008 und 1/2009 haben wir bereits über ein Kundenprojekt berichtet, bei dem Heartbeat in der Version 2 auf insgesamt drei Clustern konfiguriert wurde. In diesem Projekt wurde auch ein eigenes OCF-Skript geschrieben, welches zum Starten und Stoppen der VMware-Gäste genutzt wird. In diesem Artikel möchten wir näher auf die so genannten OCF-Resourceagents eingehen, die in Heartbeat-Version 2 eingesetzt werden können.

Cluster-Skripte

Abb. 1: Konfiguration des eigenen Skriptes mit Hilfe der GUI von Heartbeat-Version 2. Vergrößern.

<parameters> <parameter name="vmxpath" unique="0" required="1"> <longdesc lang="en"> VMX configuration file path </longdesc> <shortdesc lang="en">VMX file path</shortdesc> <content type="string"/> </parameter> <parameter name="vmwarecmdbin" unique="0" required="1"> <longdesc lang="en"> vmware-cmd executable path </longdesc> <shortdesc lang="en">vmware-cmdbin path</shortdesc> <content type="string" default="/usr/bin/vmware-cmd"/> </parameter> </parameters>

Abb. 2: Die Ausgabe eines OCF-Skriptes beim Aufruf mit dem Argument meta-data.

# ocf-tester -n vmware_test1 -o vmxpath=/vmware/guests/Win- dows2003.vmx /usr/lib/ocf/resource.d/ORDIX/vmware Beginning tests for /usr/lib/ocf/resource.d/ORDIX/vmware... *Your agent does not support the notify action (optional) *Your agent does not support the demote action (optional) *Your agent does not support the promote action (optional) *Your agent does not support master/slave (optional) *Your agent does not support the reload action (optional) /usr/lib/ocf/resource.d/ORDIX/vmware passed all tests

Abb. 3: Benutzung des Tools ocf-tester zur Prüfung eines OCF-Skriptes.

In hochverfügbaren Umgebungen werden die Dienste von der Cluster-Software gestartet, gestoppt und kontrolliert. Die Schnittstelle zwischen dem Cluster und den Diensten ist bei Heartbeat mit Hilfe von Shell-Skripten implementiert. Der Vorteil liegt hier auf der Hand: Shell-Skripte können individuell angepasst und verändert werden. Bei Heartbeat-Version 2 gibt es insgesamt vier verschiedene Arten von Shell-Skripten (Resourceagents), die für die Kontrolle der Ressourcen genutzt werden können:

LSB (Linux Standard Base)
LSB-Skripte sind die normalen init-Skripte, welche im Verzeichnis /etc/init.d abgelegt sind. Zum Starten oder Stoppen eines Dienstes übergibt der Cluster die Argumente start/stop an die Skripte. Wichtig ist auch, dass die Skripte zusätzlich das Argument status verstehen, da hiermit der Cluster überprüft, ob eine Ressource gestartet oder gestoppt worden ist. Über Rückgabewerte entscheidet der Cluster, ob der Befehl erfolgreich war oder fehlgeschlagen ist.

Heartbeat-Version 1
Die Skripte der Heartbeat-Version 1 befinden sich im Verzeichnis /etc/ha.d/resource.d. Sie dienen vorwiegend dazu, cluster-interne Aufgaben durchzuführen, wie z. B. das Erstellen der virtuellen IP-Adressen, das Versenden von E-Mails oder Net-Send-Nachrichten bei Veränderungen von Ressourcen. Aber auch Skripte, die für das Mounten/Unmouten von Dateisystemen genutzt werden, sind hier zu finden. Skripte der Heartbeat-Version erwarten die Argumente start, stop und status sowie Argumente, die skript-abhängig sind, wie z. B. IP-Adressen, E-Mail Adressen oder Dateisystemnamen.

OCF (Open Cluster Framework)
OCF-Skripte stellen die modernste und bevorzugte Art der Skripte dar. Zusätzlich zu den Argumenten start und stop beherrschen diese auch die Argumente monitor,meta-data und validate-all, einige auch promote, demote oder notify. OCF-Skripte sind in dem Verzeichnis /usr/lib/ocf/resource.d/PROVIDER beheimatet.

STONITH (Shoot the other node in the head)
STONITH-Skripte werden für das Fencing genutzt. Hiermit sollen gefährliche Situationen, wie das doppelte Mounten desselben SAN-Dateisystems, verhindert werden. Dieses geschieht durch das Ausschalten des Partnerknotens oder das Deaktivieren von FibreChannel Ports.

Das eigene OCF-Skript

Für seine eigenen OCF-Skripte erstellt man sich unter /usr/lib/ocf/resource.d bevorzugt ein eigenes Unterverzeichnis, in dem man die Skripte ablegt. Im Unterverzeichnis heartbeat befinden sich die mitgelieferten OCF-Skripte. Der Cluster durchsucht automatisch alle Verzeichnisse unterhalb von /usr/lib/ocf/resource.d nach vorhandenen Skripten. Wie in Abbildung 1 dargestellt, sieht man unter Class/Provider seinen selbst definierten Provider-Namen. Die beiden Parameter vmxpath und vmwarecmdbin müssen gesetzt werden. Weitere Attribute sind optional und können über Add Parameter hinzugefügt werden. Den konfigurierten Parametern werden vom Cluster beim Aufruf des OCF-Skriptes automatisch Variablen zugewiesen. Der Wert von vmxpath wird in der Variable OCF_RESKEY_vmxpath stehen und vmwarecmdbin der Variable OCF_RESKEY_vmwarecmdbin zugewiesen. Innerhalb des Skriptes kann man dann mit Hilfsmitteln der Shell auf die Variablen zugreifen.

Shell-Internals

OCF-Skripte sind normale Shell-Skripte, die bestimmte Argumente erwarten, wie z. B. meta-data. Ruft man ein OCF-Skript mit dem Argument meta-data auf, liefert es in XML-Sprache die möglichen, auswertbaren Parameter. In Abbildung 2 ist die Ausgabe von meta-data für das vmware-Skript abgebildet. vmwarecmdbin ist hier schon mit einem Defaultwert belegt und der Pfad für die VMware-Gastkonfigurationsdatei (vmxpath) muss noch gesetzt werden. Außer dem Argument meta-data können auch noch andere übergeben werden. Für die Entwicklung von eigenen OCF-Resource-Skripten ist es wichtig, die richtigen Rückgabewerte zurückzugeben.

Mögliche Parameter und Rückgabewerte:

• start
  Startet die Ressource. Gibt einen Rückgabewert von "0" zurück, wenn der Dienst erfolgreich gestartet werden konnte. Alle anderen Rückgabewerte bedeuten "fehlgeschlagen".
• stop
  Stoppt die Ressource. Gibt bei erfolgreichem Beenden einen Rückgabewert von "0" zurück. Alle anderen Rückgabewerte bedeuten "fehlgeschlagen".
• monitor
  Prüft den Status der Ressource. Ein Rückgabewert von "0" bedeutet, dass die Ressource läuft, eine "7", dass sie gestoppt wurde und alle anderen Rückgabewerte, dass die Prüfung fehlgeschlagen ist. Das Monitoring darf immer nur den Localhost prüfen, nicht den Status der anderen Knoten.
• meta-data
  Gibt Informationen über die Ressource als XML-Code zurück. Der Rückgabewert ist "0".
• validate-all
  Prüft die gesetzte Umgebungsvariable. Gibt einen Rückgabewert von "0" zurück, wenn die Parameter gültig sind, eine "2", wenn die Parameter ungültig sind und eine "6", wenn die Ressource nicht konfiguriert ist.

Parameter, die bei Master/Slave- oder Clone-Ressourcen verwendet werden:

• promote
  Befördert die lokale Instanz der Ressource zum Master (Primary). Gibt "0" als Rückgabewert zurück.
• demote
  Befördert die lokale Instanz der Ressource zum Slave (Secondary). Gibt "0" als Rückgabewert zurück.

Fehlersuche in OCF-Skripten

Da OCF-Skripte ganz normale Shell-Skripte sind, können diese auch außerhalb des Clusters in der Shell aufgerufen, eingesehen und analysiert werden. Zudem liefert das Heartbeat-Paket ein Kommandozeilen-Tool namens ocf-tester mit, mit dem OCF-Skripte getestet werden können. Abbildung 3 zeigt ein Beispiel.

Fazit

Heartbeat-Version 2 hat für die meisten Einsatzgebiete passende Skripte parat. Normalerweise bringen die Cluster-Dienste ihre Start/Stopp-Skripte schon mit. Falls dies einmal nicht der Fall sein sollte oder spezielle Anpassungen notwendig sind, ist es sehr einfach, für den Cluster ein passendes Skript zu erstellen oder zu erweitern. Mit Hilfe des ocf-tester können Skripte, die dem OCF-Standard entsprechen, mit Übergabeparametern gefüttert und auf das korrekte Antwortverhalten geprüft werden.

Christian Fertsch (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen