Stonith und das Quorum

Ein Zwei-Knoten-Cluster wie im Beispiel leidet unter einem Problem, das sich auf das sogenannte Quorum bezieht. Das Quorum im Cluster-Kontext ist die Zahl der Clusterknoten, die mindestens vorhanden sein müssen, damit der Cluster-Manager den Cluster für funktional hält. Im Normalfall existieren zwei Knoten, und ein Quorum ist gegeben. Fällt allerdings ein Knoten aus, wäre kein Quorum mehr da. Pacemaker würde in der Standardkonfiguration alle Ressourcen anhalten und auf ein neues Quorum warten. Der Effekt ist freilich ungewollt. Deshalb gilt es, bei einem frischen Pacemaker-Cluster diesen Effekt abzustellen.

Ein entsprechender »property« -Eintrag existiert; er heißt »no-quorum-policy« . Der nötige Wert ist »ignore« . Er lässt sich mithilfe der CRM-Shell setzen: Mittels »crm configure« landet man direkt im Konfigurationsmodul von Pacemaker; der passende Befehl lautet danach » property no-quorum-policy="ignore"« . Übrigens: Die CRM-Shell unterstützt die automatische Komplettierung mittels [TAB] – hinter »no-quorum-policy=« hätte die CRM-Shell mit [TAB] beispielsweise alle möglichen Parameter aufgelistet, die für diesen Konfigurationswert vorhanden sind.

Für das Beispiel ist eine zweite Konfigurationsänderung notwendig, die sich auf STONITH bezieht. STONITH heißt »Shoot The Other Node In The Head« ; es handelt sich um einen Fencing-Mechanismus, der es Pacemaker auf einem Knoten des Clusters erlaubt, den anderen Knoten neu zu starten, sollte dieser Probleme verursachen. STONITH ist insbesondere im Kontext von Datensicherheit wichtig, weil sie verhindert, dass mehrere Knoten zeitgleich zum Beispiel dieselben Platten mounten. Dafür wird das konkurrierende System gewaltsam angehalten,

Die Technik wird üblicherweise mittels IPMI- oder ILO-Karten realisiert; aber auch andere Varianten existieren. In einem 2-Knoten-Cluster ist STONITH nicht zwingend notwendig – gerade dann nicht, wenn die Cluster-Knoten mehrere und voneinander unabhängige Kommunikationspfade haben. Im Beispiel bleibt es daher deaktiviert. Das geht mit »property stonith-enabled="false"« – ebenfalls im »configure« -Menü der CRM-Shell.

Die Änderung der Quorum-Policy sowie der STONITH-Funktion sind schließlich in den Cluster-Manager mittels »commit« zu übermitteln – das gilt für alle Änderungen, die wie beschrieben im »crm configure« -Menü der Shell ausgeführt werden.

Die erste Ressource

Grundsätzlich ist Pacemaker jetzt einsatzbereit – Gelegenheit, die erste Ressource in die Clusterkonfiguration zu übernehmen. Einzelne Ressourcen sind in Pacemaker stets »primitive« -Ressourcen; der Befehl, um sie in die CIB einzubauen, heißt genauso und gehört zum »configure« -Menü der CRM-Shell. Er kennt verschiedene Parameter und Optionen. Grundsätzlich hat er folgende Syntax:

primitive 
<!-- START: including template: design/standard/templates/content/datatype/view/ezxmltags/emphasize.tpl (design:content/datatype/view/ezxmltags/emphasize.tpl) -->
Name_der_Ressource RA-Klasse
<!-- STOP: including template: design/standard/templates/content/datatype/view/ezxmltags/emphasize.tpl (design:content/datatype/view/ezxmltags/emphasize.tpl) -->
[
<!-- START: including template: design/standard/templates/content/datatype/view/ezxmltags/emphasize.tpl (design:content/datatype/view/ezxmltags/emphasize.tpl) -->
:Provider
<!-- STOP: including template: design/standard/templates/content/datatype/view/ezxmltags/emphasize.tpl (design:content/datatype/view/ezxmltags/emphasize.tpl) -->
]: 
<!-- START: including template: design/standard/templates/content/datatype/view/ezxmltags/emphasize.tpl (design:content/datatype/view/ezxmltags/emphasize.tpl) -->
Name-des-RA params Parameter
<!-- STOP: including template: design/standard/templates/content/datatype/view/ezxmltags/emphasize.tpl (design:content/datatype/view/ezxmltags/emphasize.tpl) -->

• Name der Ressource ist eine frei wählbare Zeichenkette. Die komplette Bezeichnung des Ressource-Agents mag umständlich wirken, ist aber notwendig, um OCF-Agents entsprechend abbilden zu können.
• RA-Klasse kann derzeit entsprechend der Erklärung weiter oben entweder »heartbeat« , »lsb« oder »ocf« sein.
• Provider kommt nur bei OCF-Agents zum Einsatz und bezeichnet den Provider, der zu einem OCF-Agent gehört – die eckigen Klammern sind in diesem Falle wegzulassen.
• Name des RA ist selbsterklärend.
• Das Schlüsselwort »params« legt Parameter fest, die sich auf die Konfiguration des Resource Agents beziehen.

[Tab] führt zu einer Übersicht aller Parameter, die der jeweilige Ressource-Agent unterstützt. Auch bei der Angabe des RAs ist es übrigens für jedes der drei Felder möglich, sich mit [Tab] eine Liste aller verfügbaren Einträge anzeigen zu lassen. Das hilft, falls der Name eines RAs nicht oder nur ungefähr bekannt ist.

Ein praktisches Beispiel: Pacemaker soll sich um die Verwaltung einer IP-Adresse kümmern. Der entsprechende Ressource-Agent dafür heißt »IPaddr2« ; er ist ein OCF-Resource Agent vom Provider »heartbeat« und benötigt mindestens zwei Parameter – die eigentliche IP-Adresse und die Netmask dieser IP. Die passende Konfigurationszeile Zeile könnte so aussehen:

primitive p_ip1 ocf:heartbeat:IPaddr2 params ip=192.168.0.10 cidr_netmask=24

Diese Konfigurationszeile führt dazu, dass Pacemaker im Falle eines Failovers die IP auf dem jeweils verbliebenen Cluster-Knoten mit genau diesen Parametern starten würde. Noch nicht abgedeckt ist im Beispiel die Situation, dass die IP-Adresse aus irgendwelchen Gründen von dem System, auf dem sie läuft, verschwindet. Es ist deshalb notwendig, die Ressource-Definition um eine »Operation« zu erweitern – nämlich um eine Monitoring-Operation. In Ressource-Definitionen leiten sich Operationen mit dem Schlüsselwort »op« ein. Anders als bei den Parametern, wo nur einmal »params« steht, ist jede Operation mit »op« einzuleiten. Um dafür zu sorgen, dass Pacemaker in einem Interval von 15 Sekunden überprüft, ob die IP noch existiert, reicht es, am Ende der Zeile oben »op monitor interval=15s« einzufügen. Das sorgt für Ressourcen-Monitoring. Nach dem Hinzufügen einer Primitive-Ressource schaltet Pacemaker die neue Konfiguration durch »commit« scharf.

Statusinformationen über den Cluster sind für den Administrator wichtig. Mit »crm_mon« ( Abbildung 4 ) steht ein Werkzeug zur Verfügung, um sich schnell einen Überblick über den Zustand des Systems zu verschaffen ( Abbildung 5 ). »crm_mon -1« zeigt den gegenwärtigen Zustand an und beendet sich danach wieder. Dagegen führt »crm_mon« zu einer Cluster-Konsole, die jeder neue Event aktualisiert. Erweitert um die Parameter »-rf« zeigt der CRM-Monitor auch Fehler sowie deaktivierte Ressourcen an.

Abbildung 5: Mittels des Werkzeugs cl_status erfährt man mehr über seinen Cluster – vorausgesetzt, dieser nutzt Heartbeat.

Abbildung 4: crm_mon zeigt, was los ist – auf diesem Cluster ist einiges im Argen.