Licence to kill

Die meisten Resource Agents überprüfen beim Aufruf mit »monitor« nur oberflächlich, ob ein Programm läuft. Meist schauen sie nach, ob ein entsprechender Prozess in der Prozesstabelle zu finden ist und ob dieser auf »kill -0« noch reagiert. Nicht selten erfüllen Applikationen zwar diese beiden Bedingungen, funktionieren aber trotzdem nicht mehr richtig.

Beispiele sind virtuelle Maschinen, deren »kvm« -Prozess zwar noch läuft, die aber auf »ping« nicht mehr antworten, sowie Asterisk, das nicht mehr reagiert, obwohl der Prozess noch läuft. Die Autoren von Resource Agents müssen sich um diese Probleme selbst kümmern. Für die beiden angegebenen Beispiele ist das passiert: Sowohl »ocf:heartbeat:VirtualDomain« als auch »ocf:heartbeat:asterisk« bieten erweiterte Testmechanismen, um Fehlurteilen vorzubeugen.

Monitor-Skripte

Der Virtual-Domain-Agent erledigt das über den Parameter »monitor_scripts« in der CRM-Konfiguration. Hier gibt der Admin eine Liste von Skripten an, die Pacemaker während der »monitor« -Operation aufruft, jeweils getrennt durch ein Komma. Falls der Clusteradmin hier externe Skripte angibt, bezieht der Resource Agent deren Rückgabewerte in das Ergebnis von »monitor« ein.

Zusatzskripte (Abbildung 3) können beliebige Funktionen testen. Empfehlenswert ist etwa ein Skript, das »ping« mit der IP der virtuellen Maschine aufruft und 0 zurückliefert, falls diese auf Pings antwortet, oder 1, falls nicht.

Abbildung 3: Soll der Resource Agent mehr können, als das Vorhandensein eines Prozesses zu testen, müssen RA-Autoren dies in die Skripte einbauen.

Der spezialisierte Asterisk-Agent »ocf:heartbeat:asterisk« kennt eine sehr ähnliche Funktion. Ist auf dem Zielsystem das Programm »sipsak« installiert und definiert der Admin in der CRM-Konfiguration den Parameter

monitor_sipuri="sip:IP."

dann schickt der Agent bei jedem Monitoring-Aufruf einen SIP-Request an den Asterisk-Server. Kommt auf den Request eine brauchbare Antwort, gilt die Operation als erfolgreich abgeschlossen. Andernfalls markiert Pacemaker den Vorgang als »failed« und spielt das übliche Programm ab.

Übrigens: Hat der Admin nach dem Fehlschlagen einer Monitor-Operation die Ursache für das Problem beseitigt, hilft der Befehl »crm resource cleanup Name_der_Ressource« auf der Bash, um den »Failcount« der Ressource auf 0 zurückzusetzen. Das stellt die Ausgangssituation wieder her (Abbildung 4).

Abbildung 4: Die Ressource p_filesystem:1 ist zwischenzeitlich abgestürzt, aber Pacemaker hat das automatisch korrigiert. crm_mon -1 -rf zeigt, ob in der Vergangenheit Ressourcen abgestürzt sind.