Kommunikationspfade

Ein abschließendes Wort zur Cluster-Konfiguration – grundsätzlich gilt: Die Knoten eines Clusters sollten redundant miteinander kommunizieren können, also mindestens zwei voneinander unabhängige Kommunikationspfade zur Verfügung haben. Falls ein Kommunikationspfad stirbt, steht der andere noch immer zur Verfügung. Sowohl Heartbeat als auch Corosync unterstützen Setups mit zwei Kommunikationspfaden. Achten Sie darauf, dass bei mindestens einem Kommunikationspfad eine direkte Verbindung zwischen den zwei Clusterknoten existiert – also eine, die nicht durch Switches geht. Wenn DRBD im Cluster zum Einsatz kommt, kann der zweite Pfad auch einen eventuellen Back-to-Back-Link verwenden.

Ressourcen

Zentral ist im Pacemaker-Kontext der Begriff der Ressource. Er wird einem im Cluster-Kontext immer wieder begegnen. Er meint nichts anderes als einen Dienst, der von Pacemaker verwaltet wird. Es kann sich also um eine DRBD-Ressource handeln, um eine MySQL-Instanz oder auch um eine IP-Adresse.

Pacemaker selbst ist der Ressourcen-Manager – aber wie wickelt er das Management von Ressourcen eigentlich ab? Wenn Pacemaker den Dienst MySQL starten soll, ruft das Programm nicht »/usr/sbin/mysqld« mit den passenden Parametern auf. Stattdessen bedient er sich einer eigenen Shell-basierten API. Außerdem verwendet Pacemaker einige Wasserträger, die ihm das Starten und Stoppen von Ressourcen abnehmen. Die Abbildung 2 zeigt, wie Dienste von Pacemaker gestartet werden.

Abbildung 2: Pacemaker startet eine Applikation via Cluster Resource Manager, Local Resource Manager und Resource Agent.

Pacemaker, der – einmal gestartet – in der Prozess-Tabelle als »crmd« erscheint, läuft auf jedem Clusterknoten. Zusätzlich dazu läuft ebenso auf jedem Clusterknoten der Dienst »lrmd« , der »Local Resource Management Daemon« . Die einzige Aufgabe des LRMDs ist es, Befehle von Pacemaker auf der einen Seite entgegenzunehmen und im Anschluss Shell-Skripte aufzurufen, um den von Pacemaker gewünschten Vorgang durchzuführen.

Diese Shell-Skripte nennen sich im Cluster-Jargon »Resource Agents« . Sie sind dafür verantwortlich, das passende Binary mit den konfigurierten Parametern aufzurufen. Pacemaker unterstützt momentan drei Arten eben dieser Resource Agents: Zum einen Heartbeat-1-kompatible Agents, die allerdings als veraltet gelten, außerdem unterstützt es LSB-Agents, die gemeinhin auch als Init Scripts bezeichnet werden und schließlich gibt es noch die Königsklasse der Resource Agents: OCF-basierte Agents (Abbildung 3). Sie verwenden einen eigenen Standard, der speziell für die Benutzung im Cluster gestaltet worden ist. Grundsätzlich gilt: Damit ein Skript in Pacemaker als Resource-Agent eingesetzt werden kann, muss es mindestens die Parameter »start« , »stop« und »monitor« kennen. Vorsicht ist auf Debian-Systemen geboten, denn viele Init-Skripte bei Debian kennen das »monitor« -Argument nicht.

Abbildung 3: Die OCF-Resource-Agents liegen typischerweise im Ordner /usr/lib/ocf/resource.d/[UCC:x00-fake-italic]Provider.

OCF-Resource-Agents weisen im Gegensatz zu den beiden anderen Gruppen eine Besonderheit auf, denn sie gehören jeweils zu einem eigenen »Provider« , sind also nochmals in Gruppen aufgeteilt. Der DRBD-Resource-Agent kommt vom Provider »linbit« , der Resource-Agent für das Mounten von Dateisystemen kommt vom Anbieter »heartbeat« . Die Anbieter der am häufigsten genutzten Resource Agents werden schnell geläufig. Und das ist gut so – wer regelmäßig Pacemaker-Cluster administriert, sollte sich jedenfalls die Namen der drei Kategorien sowie die Bezeichnung der wichtigsten OCF Resource Agents sehr gut merken.