Gruppen

Gruppen sind in Pacemaker eine admin-freundlichere Methode, um Ressourcen, die stets auf dem gleichen Host laufen und in einer bestimmten Reihenfolge gestartet werden müssen, miteinander zu verbinden. Die Syntax ist

group 
<!-- START: including template: design/standard/templates/content/datatype/view/ezxmltags/emphasize.tpl (design:content/datatype/view/ezxmltags/emphasize.tpl) -->
Name Resource 1 Resource 2 ...
<!-- STOP: including template: design/standard/templates/content/datatype/view/ezxmltags/emphasize.tpl (design:content/datatype/view/ezxmltags/emphasize.tpl) -->

Master-Slave-Setups lassen sich nicht in Gruppen integrieren, werden bei Bedarf aber mittels Colocation- und Order-Constraints mit diesen verbunden. Denkt man sich im Beispiel des Artikels die Ressource für MySQL mit dem Namen »res_mysql« hinzu, so könnte eine Gruppe dafür so aussehen:

group g_mysql res_fs_mysql res_mysql

Die Resource-Stickiness

Die in früheren Zeiten durchaus beliebte Auto-Fail-Back-Funktion fristet heute eher ein Nischendasein. Schließlich bringt es keinen Mehrwert, einen Dienst, der auf einem Clusterknoten tadellos funktioniert, grundlos auf einen anderen Server zu migrieren. In der Standard-Konfiguration ist das Feature in Pacemaker trotzdem aktiv – über einen Umweg, der mit dem schon erwähnten Punktesystem zu tun hat. Denn auch die Frage, ob eine Ressource auf dem Knoten eines Clusters, auf dem sie gerade läuft, weiterlaufen soll, wird über die schon erwähnte Policy-Engine beantwortet.

Grundsätzlich gilt: Pacemaker ist ab Werk darauf ausgelegt, dass ein von ihm verwalteter Cluster symmetrisch ist. Das heißt, dass die anfallende Last der Ressourcen möglichst gleichmäßig auf die verfügbaren Knoten zu verteilen ist. Ohne besondere Voreinstellung bekommt eine Ressource deshalb dafür, dass sie auf Knoten A oder auf Knoten B läuft, keine Punkte. Pacemaker startet eine Ressource 1 auf Knoten A und eine Ressource 2 auf Knoten B. Fällt Knoten B aus, wandert die Ressource 2 auf Knoten A. Kommt Knoten B zurück in den Cluster, hat Pacemaker die Möglichkeiten "Lassen, wo es ist" oder "Auf den anderen Knoten verschieben". Beide Varianten haben gleich viele Punkte – 0 ab Werk – und Pacemaker verschiebt die Ressource.

Um des Problems Herr zu werden, empfiehlt sich das Setzen des Attributes »resource-stickiness« . Der Wert legt fest, wie viele Punkte eine Ressource dafür bekommt, dass sie auf einem Cluster-Knoten bereits läuft. Wenn der Wert auf 200 gesetzt ist, bekäme die Variante "Lassen, wo es ist" aus dem Beispiel gerade 200 Punkte und die Variante "Auf den anderen Knoten verschieben" immer noch 0 Punkte – das Verschieben wäre verhindert. Der Wert »resource-stickiness« lässt sich für alle Ressourcen im Cluster mit diesem Befehl festlegen:

rsc_defaults resource-stickiness="200"

Damit ist der automatische Fail-Back dauerhaft unterbunden.

Constraints in Pacemaker sind sehr komplex. Die zuvor gegebenen Erklärungen reichen zwar für alltägliche Einsatzszenarien in Pacemaker, kratzen ansonsten aber bloß an der Oberfläche. Wer sich mit den Interna genauer befassen möchte, findet in Andrew Beekhofs Dokumentation [6] genauere Informationen.

Bisher besteht die Cluster-Konfiguration aus der »primitive« -Ressource für DRBD, der dazu gehörenden Master-Slave-Regel sowie dem Dateisystem. Für einen funktionierenden HA-Cluster mit MySQL fehlen noch zwei Dinge, nämlich die Datenbank selbst sowie die Service-IP, unter der die Datenbank erreichbar sein soll. Die Einrichtung einer IP-Adresse geschieht analog zur Erklärung im ersten Teil des Workshops. Wenn auf den beiden Cluster-Knoten die IP-Adressen 192.168.0.1 sowie 192.168.0.2 sind und die Service-IP 192.168.0.3 sein soll, genügt in Pacemaker diese primitive Ressource:

primitive res_ip_mysql ocf:heartbeat:IPaddr2 params ip="192.168.0.3" cidr_netmask="24" op monitor interval="20s"