Alle großen Distributoren liefern bei ihren Corosync-Paketen die von den Autoren zur Verfügung gestellte Standard-Konfiguration mit. Das ist vor allem deshalb sehr praktisch, weil darin nur eine einzige Zeile zu verändern ist, damit Corosync läuft. Corosyncs Konfigurationsdatei ist
»/etc/corosync/corosync.conf
«
(
Abbildung 1
); in der Standardversion dieser Datei findet sich ein einzelner Eintrag für einen Kommunikationsstring, der allerdings auf die Loopback-Adresse 127.0.0.1 konfiguriert ist. Hinter
»bindnetaddr
«
in diesem
»interface
«
-Eintrag gehört die Adresse eines Netzwerkes, über das die beiden Clusterknoten miteinander reden. Ist die Änderung vollzogen, kopiert man die Datei auf den anderen Knoten. Im Anschluss erstellt
»corosync-keygen
«
einen Authentifizierungsschlüssel in
»/etc/corosync/authkey
«
, der ebenfalls auf den anderen Knoten zu kopieren ist. Danach genügt es, Corosync zu starten. Unter Debian oder Ubuntu ist gegebenenfalls vorher noch in der Datei
»/etc/default/corosync
«
Corosync zu aktivieren.
Übrigens: Wer einen zweiten Kommunikationsring verwenden will, kann einen
»interface
«
-Eintrag nach dem Muster des bereits vorhandenen Absatzes hinzufügen, muss diesem aber eine entsprechend erhöhte
»ringnumber
«
sowie eine andere Multicast-Adresse angeben. Außerdem ist in diesem Falle der Wert hinter
»rrp_mode
«
auf
»active
«
zu setzen.
Wer statt Corosync lieber Heartbeat verwendet, bearbeitet für die Funktion des Cluster Communication Managers vor allem
»ha.cf
«
in
»/etc/ha.d
«
. Im Standard-Lieferumfang für Heartbeat fehlt diese Datei leider vollständig, sodass sie erst händisch anzulegen ist. Im
Listing 1
finden Sie ein vollständiges Beispiel. Die einzelnen Zeilen haben diese Funktionen:
Listing 1
Exemplarische ha.cf
keepalive 2
«
sorgt dafür, dass Heartbeat alle 2 Sekunden alle anderen Cluster-Knoten anpingt und auf Antwort wartet. Kommt auf diese Pings keine Antwort, schreibt Heartbeat mit
»warntime 20
«
nach 20 Sekunden eine entsprechende Warnung ins Logfile. Nach 30 Sekunden erklärt Heartbeat einen Link zu einem Clusterknoten für tot, wenn
»deadtime 30
«
gesetzt ist.initdead 30
«
legt fest, dass Heartbeat nach dem Programmstart bis zu 30 Sekunden wartet, bis alle festgelegten Clusterknoten vorhanden sind.logfacility local0
«
legt die Syslog-Facility fest, die Meldungen von Heartbeat erhalten sollen.bcast ethx
«
sowie
»mcast br0 ...
«
legen die Kommunikationspfade fest, die Heartbeat verwenden darf.node alice
«
und
»node bob
«
definieren von vornherein, welche Knoten im Cluster vorhanden sind.autojoin none
«
verhindert, dass andere Clusterknoten automatisch in den Cluster-Verbund aufgenommen werden, ohne in der Konfigurationsdatei zu stehen.crm yes
«
aktiviert Pacemaker. An dieser Stelle könnte auch
»crm respawn
«
stehen. Der Unterschied zwischen
»yes
«
und
»respawn
«
ist, dass bei Ersterem Heartbeat einen Reboot des Servers initiiert, falls
»crmd
«
unerwartet abstürzt. Mit
»respawn
«
wird Pacemaker einfach neu gestartet.Auch Heartbeat wünscht sich einen Authentifizierungsschlüssel, um sich bei den anderen Clusterknoten vorstellen zu können. Der Schlüssel liegt in
»/etc/ha.d/authkeys
«
, bei Heartbeat gibt es aber kein Werkzeug, das diese Datei anlegt. Ein Beispiel – alle Teile mit Ausnahme von
foobar
sind zu übernehmen – könnte so aussehen:
auth 2 2 sha1 <!-- START: including template: design/standard/templates/content/datatype/view/ezxmltags/emphasize.tpl (design:content/datatype/view/ezxmltags/emphasize.tpl) -->foobar <!-- STOP: including template: design/standard/templates/content/datatype/view/ezxmltags/emphasize.tpl (design:content/datatype/view/ezxmltags/emphasize.tpl) -->
Ist
»authkeys
«
an ihrem angestammten Platz, startet
»/etc/init.d/heartbeat
«
Heartbeat sowie Pacemaker. Ob Pacemaker läuft, ist mit der obigen Konfiguration nach ungefähr einer Minute daran zu erkennen, dass
»crm_mon -1 -rf
«
beide Clusterknoten als
»online
«
sieht.