XML aufgeteilt

Die Konfigurationsdatei besteht aus einzelnen Abschnitten. Globale Parameter wie beispielsweise der Clustername gehören in den Abschnitt »cluster« . Anweisungen für das CMAN-Plugin kommen in den Abschnitt »cman« . In Listing 1 stehen hier die beiden Anweisungen »two_node« und »expected_votes« . Die erste Anweisung teilt dem Clustermanager mit, dass der aktuelle Cluster lediglich aus zwei Knoten besteht und zur Berechnung des Quorums nur eine einzige Stimme notwendig ist.

Bestehen Cluster aus mehr als zwei Knoten, sind zum Erlangen des Quorums mindestens die Stimmen der Hälfte der verfügbaren Clusterknoten plus eins (n/2+1) notwendig. Ein 2-Knoten-Cluster stellt somit eine Ausnahme dar, dies verdeutlicht der Parameter »expected_votes« noch einmal. Üblicherweise ist der hier angegebene Wert identisch mit der Anzahl der Clusterknoten, in einem 2-Knoten-Cluster ist dies jedoch nicht so.

Zusätzlich zu den bereits genannten Parametern können Sie hier eine Multicast-Adresse, einen alternativen UDP-Port (Default: 5405) für den CMAN-Empfangs-Socket oder die Cluster-ID festlegen. Ist keine Cluster-ID definiert, generiert der Cluster selbst eine. Dies kann unter Umständern zu Problemen führen, wenn mehrere Cluster im gleichen Netzwerk vorhanden sind und zufällig die gleiche ID generiert wurde.

Zur Verschlüsselung des Datenverkehrs generiert CMAN einen Schlüssel auf Basis des Clusternamens. Wollen Sie stattdessen lieber einen anderen Schlüssel verwenden, können Sie ihn mit Hilfe der Anweisung »keyfile« ebenfalls in diesem Abschnitt angeben. Da CMAN jedoch nur ein Modul von vielen innerhalb des Corosync-Framework ist, können Sie natürlich auch Anweisungen für die weiteren Module in der Konfigurationsdatei »cluster.conf« angeben.

Beispielsweise bietet das Totem-Protokoll die Möglichkeit, einen Timeout für das Totem-Token festzulegen ( »<totem token="30000"/>« ). Das Token wandert zwischen den einzelnen Clusterknoten hin und her. Verstreicht der mittels »timeout« angegebene Zeitraum beim Versenden des Token, wird der Knoten als defekt angesehen und aus dem Cluster entfernt.

Ebenfalls sehr hilfreich ist die Logging-Anweisung. Hiermit können Sie die Logs aller am Cluster beteiligten Subsysteme entweder in eine Logdatei schreiben, an Syslog senden oder auf dem Bildschirm ausgeben. Jedes Subsystem kann dabei seine eigene Logdatei bekommen. Listing 2 zeigt ein Beispiel. Weitere Corosync-spezifische Parameter entnehmen Sie der Hilfe-Seite von »corosync.conf« .

Clusterknoten

Die nächste Sektion »clusternodes« beschreibt die einzelnen Knoten des Clusters und bestimmt deren Eigenschaften. So bekommt jeder Clusterknoten einen Namen, eine Voting-Stimme und eine ID zugewiesen. Die Kommunikation der Clusterknoten untereinander findet über das Netzwerk statt, über das die hier angegebenen Knoten-Namen aufgelöst werden können. Wenn Sie also Ihren Datenverkehr vom Clusterverkehr trennen möchten, achten Sie darauf, die passenden DNS-Namen anzugeben.

Bekommt ein Clusterknoten mehr als eine Stimme, gilt die oben erwähnte Quorum-Regel nicht mehr, da die Anzahl der verfügbaren Stimmen und nicht die Anzahl der Clusterknoten als Grundlage der Quorum-Berechnung dient. Existiert beispielsweise ein Cluster mit drei Knoten, müssen zum Erreichen des Quorums mindestens zwei Rechner online sein (3/2+1=2), sonst ist der Cluster nicht »quorate« und kann keinen HA-Service verwalten. Bekommt ein Knoten aber zwei Stimmen statt nur einer, reicht es aus, wenn dieser Rechner alleine online ist, damit der Cluster noch über das Quorum verfügt, selbst dann, wenn beide anderen Rechner offline sind.

Als weitere Eigenschaft können Sie jedem Knoten mindestens eine Referenz auf ein Fencing-Gerät zuordnen. Das Gerät selbst ist dann im Abschnitt »fence« näher zu beschreiben. Die Konfiguration dafür ist in Listing 3 dargestellt.

Die Konfiguration des Fencing-Subsystems ist von größter Wichtigkeit. Sollte der Clustermanager nicht in der Lage sein, einen ausgefallen Rechner aus dem Cluster zu lösen, also auf ein Fencing-Event eine positive Rückmeldung des Fencing-Daemon zu bekommen, dann wird der Ressourcen-Manager den HA-Service, der eventuell auf diesem Knoten läuft, nicht auf einem anderen Knoten neu starten.

Dies geschieht aus gutem Grund, da es ja durchaus möglich sein kann, dass ein Rechner nur temporär hängt und nach einer gewissen Zeit wieder zum Leben erwacht und auf seine Ressourcen genau dann zugreift, wenn ein zweiter Rechner dasselbe macht. Eine Beschädigung der Daten kann in einem solchen Fall die Folge sein.

Wenn Sie die Datei »cluster.conf« auf einen anderen Clusterknoten kopieren und dort mittels »/etc/init.d/cman start« den Clustermanager starten, sollten Sie beim Aufruf von »cman_tool status« eine Ausgabe wie in Listing 4 sehen.

Beachten Sie, dass die aktuelle Cluster-Suite-Version 3.0 kein Cluster-Konfigurationssystem mehr enthält. Somit besteht auch nicht mehr die Möglichkeit, bei einem laufenden Clustermanager Änderungen an der Konfigurationsdatei mittels »ccs_tool update« zu übertragen. Sie können stattdessen jedoch eine neue Version der Cluster-Konfiguration mittels »cman_tool version -r Versionsnummer« dem Cluster bekannt machen und auf die anderen Knoten übertragen.

Die grundlegenden Konfigurationsschritte für den Clustermanager sind somit erledigt. Dass nun die Corosync-Datenbank die einzelnen Parameter kennt, bestätigt das Tool »corosync-objctl« :

# corosync-objctl | grep cluster.name
cluster.name=iscsicluster

Möchten Sie die Konfiguration lieber auf einem LDAP-Sever vornehmen, lässt sich eine bestehende XML-Config leicht ins LDIF-Format verwandeln ( Listing 5 ). Mittels »ldapadd« können Sie die so erzeugte LDIF-Datei dann in Ihren LDAP-Server importieren. Beachten Sie, dass Sie hierfür erst die passende LDAP-Schemadatei aus dem Ordner »/usr/share/doc/cman-version/« dem LDAP-Server bekanntgeben müssen, sonst kennt er die verwendeten Objektklassen und Attribute nicht und der Import der LDIF-Datei schlägt fehl.