Falsch verstanden

Für den Clustermanager ist das fatal, denn aufgrund der Fehlermeldung vermutet er, der Dienst laufe nicht. Versucht er im Anschluss den Dienst zu starten, führt das meist zu einem Chaos im Cluster. Der Aufruf eines Init-Skripts mit dem »monitor« -Kommando bringt dem Admin bereits vorher beruhigende Gewissheit. Gibt der Agent einen plausiblen Wert zurück, ist das Init-Skript fit für den Monitoring-Einsatz in Pacemaker.

Wenn klar ist, dass alle Agents in einem Pacemaker-Setup den Parameter »monitor« kennen, spricht nichts dagegen, die Funktion tatsächlich auch in der Pacemaker-Konfiguration zu verwenden. Als bevorzugtes Tool, um das Clustersetup anzupassen, gilt die CRM-Shell (Abbildung 1), sie lässt sich auf Pacemaker-Systemen durch den Aufruf von »crm configure« in der Bash starten.

Abbildung 1: crm ra info gibt die Informationen zu einem Resource Agent aus. Besondere Monitoring-Fähigkeiten sind üblicherweise hier vermerkt.

Der Befehl führt unmittelbar in das »configure« -Menü. Es schadet nicht, zuvor sicherzustellen, dass in der Umgebungsvariablen »$EDITOR« tatsächlich der Kommandozeilen-Editor der eigenen Präferenz steht. Denn der nächste Befehl auf der CRM – »edit« – startet diesen Editor und lädt die existierende Clusterkonfiguration.

Primitive-Monitoring

Das Monitor-Feature bezieht sich jeweils auf einfache Ressourcen, in Pacemaker-Sprech Primitives genannt. Im Falle einer vorhandenen Konfiguration finden sich in der CRM-Konfiguration vermutlich mehrere Ressourcen dieses Typs. Sie unterstützen jeweils zwei Arten von Konfigurationseinstellungen: Parameter, die über den Resource Agent unmittelbar auf die Eigenschaften des jeweiligen Programms Einfluss nehmen, und Operationen. Erstere werden in der Konfiguration einer »primitive« -Ressource mit dem Schlüsselwort »params« eingeleitet.

Zusätzlich gibt es das Keyword »op« , das die so genannten Operations einleitet. Über diese legt der Administrator fest, wie Pacemaker mit bestimmten Ressourcen umgehen soll. Drei Operationen gehören zum Standardrepertoire: Über »start« und »stop« stellt der Clusteradmin Toleranzwerte für die Timeouts beim Starten und beim Stoppen ein. Die dritte ist die »monitor« -Operation (Abbildung 2). Sie bringt Pacemaker dazu, den Resource Agent für diese Ressource regelmäßig mit dem »monitor« -Befehl aufzurufen und aus den Resultaten Rückschlüsse zu ziehen.

Abbildung 2: Das Monitoring auf Ressourcen-Ebene aktivieren Admins, indem sie die monitor-Operation für die primitive hinzufügen.

Um das Monitoring für eine »primitive« -Ressource zu aktivieren, ist die folgende Zeile in deren Konfiguration notwendig:

op monitor interval="60s" timeout="30s"

Diese Operation veranlasst Pacemaker jede Minute zu testen, ob der Dienst noch läuft. Bekommt der Clustermanager nach 30 Sekunden keinen Rückgabewert vom aufgerufenen Programm, gilt die Operation als gescheitert und Pacemaker initiiert einen Neustart der Ressource. Das Gleiche tut er, sollte der Test einer Ressource ergeben, dass diese nicht läuft. Außerdem setzt der Schrittmacher in diesem Falle den »failcount« der Ressource um 1 hoch, loggt also mit, dass die Ressource abgestürzt ist.