Constraints in Pacemaker

Ressourcen in einem Pacemaker-Cluster-Setup können auf verschiedene Arten voneinander abhängen. Dabei kann es sich einerseits um Abhängigkeiten handeln, die ein Administrator festlegt. Ein typisches Beispiel wäre der Wunsch, dass verschiedene Dienste immer auf dem gleichen Host laufen sollen, um so ein klassisches Aktiv-Passiv-Setup mit einem "Standby-Knoten" zu erreichen. Aber auch intrinsische Abhängigkeiten sind denkbar: Sind wie im Beispiel eine DRBD-Ressource und dazugehöriges Dateisystem vorhanden, dann muss das Dateisystem stets auf dem Knoten gestartet werden, auf dem auch das DRBD-Laufwerk im »Primary« -Modus ist – denn nur dort kann es überhaupt gemountet werden. In Pacemaker lassen sich solche Abhängigkeiten mit den sogenannten Constraints abbilden. Zur Verfügung stehen Order-Constraints, Colocation-Constraints und Location-Constraints.

Die drei Begriffe sind Umschreibungen für sehr komplexe Vorgänge, die in Pacemaker ablaufen, um festzulegen, wo eine Ressource laufen soll. Pacemaker bringt eine eigene Komponente mit, die sich ausschließlich dieser Frage widmet: Die Policy Engine, die in der Prozesstabelle als »pengine« zu finden ist. Die Policy Engine arbeitet intern mit Punktwerten. Geht es um die Frage, wo eine spezifische Komponente laufen soll, spielt eben diese Policy Engine alle denkbaren Szenarien durch und nutzt schließlich die Option mit der höchsten Punktzahl. Der Admin hat durch das händische Setzen von Constraints die Möglichkeit, selbst Punkte zu verteilen und damit die Entscheidung im Punktewettkampf zu beeinflussen.

Colocation-Constraints

Mittels Colocation-Constraints legt der Administrator fest, dass zwei Ressourcen auf dem gleichen Host laufen müssen, sollen oder nicht laufen dürfen. Die Syntax eines Colocation-Constraints ist grundsätzlich diese:

colocation 
<!-- START: including template: design/standard/templates/content/datatype/view/ezxmltags/emphasize.tpl (design:content/datatype/view/ezxmltags/emphasize.tpl) -->
Name Punktzahl: 
<!-- 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) -->
Ressource, die folgt Ressource,
<!-- 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) -->
die grundsätzlich startbar sein muss
<!-- STOP: including template: design/standard/templates/content/datatype/view/ezxmltags/emphasize.tpl (design:content/datatype/view/ezxmltags/emphasize.tpl) -->

Obwohl es sich bei Colocation-Constraints nicht um typische Ressourcen handelt – das Gleiche trifft übrigens auf Orders und Locations ebenso zu – brauchen auch diese Einträge einen eindeutigen Namen in der CIB. Dieser ist per »Name« festzulegen. »Punktzahl:« kann grundsätzlich jeder beliebige Zahlenwert sein. In der Praxis finden sich hier aber meistens die Einträge »inf:« und »-inf:« . Entsprechend ist dann auch die Rede von »Infinity-Colocations« und »Minus-Infinity-Colocations« . Legt der Admin den Wert auf »inf:« fest, bedeutet das, dass zwei Ressourcen stets auf dem gleichen Host zu starten sind – kann eine Ressource nicht gestartet werden, so darf auf dem Host auch die andere nicht laufen.

»inf:« ist die zweithöchste Punktzahl, die ein Admin vergeben kann. Über »inf:« rangiert bloß noch »-inf:« , was das genaue Gegenteil bewirkt: Es besagt, dass zwei auf diese Weise voneinander ausgeschlossene Ressourcen unter keinen Umständen auf dem gleichen Rechner laufen dürfen.

Die beiden Argumente für den Colocation-Constraint bezeichnen die zwei Ressourcen, die miteinander verbunden werden. Die angegebene Reihenfolge ist wichtig, denn das zweite Argument bezeichnet jeweils die Ressource, die auf einem Cluster-Knoten laufen können muss, bevor Pacemaker überhaupt prüft, ob die andere Ressource dort ebenfalls zu starten ist. Sprachlich hilft die Formulierung "Die erste angegebene Ressource folgt der zweiten angegebenen Ressource" als Eselsbrücke; doch ist der Merksatz unpräzise, denn zunächst trifft eine Colocation keine Aussage darüber, in welcher Reihenfolge zwei Ressourcen auf einem Knoten zu starten sind. In der Praxis wirkt sich die hier verwendete Reihenfolge insbesondere bei Colocation-Constraints mit dem Punktwert »-inf:« aus: Pacemaker sorgt dann nämlich dafür, dass die im Colocation-Constraint an zweiter Stelle stehende Ressource jedenfalls auf einem Cluster-Knoten gestartet wird, die andere aber auf dem gleichen Knoten keinesfalls. Analog dazu ist die Eselsbrücke bei »-inf:« -Constraints auch "Die erste angegebene Ressource folgt der zweiten angegebenen Ressource nie". Ist in einer solchen Situation kein zweiter Cluster-Knoten mehr vorhanden, bleibt die erste angegebene Ressource dann einfach gestoppt.