Information & Consulting

Heartbeat dient dazu zwei Rechner zu einem Cluster zusammenzuschweißen und Ressourcen gemeinsam zur Verfügung zu stellen. Jeder Rechner behält seine eigene Identität, nach außen hin wird zusätzlich eine High-Availability-Adresse zur Verfügung gestellt. Diese existiert jeweils nur auf einem der beiden Rechner.

Damit Änderungen auf dem Master auch auf dem Slave vorhanden sind, wenn dieser Master ist, bietet es sich an, das Dateisystem im laufenden Betrieb permanent zu spiegeln. Bei einem NAS ist das natürlich kein Thema. Wenn jedoch lokale Platten zum Einsatz kommen, bietet es sich an, via cron und rsync den Master dauernd zu spiegeln.

Beim Spiegeln sollte man tunlichst darauf achten, welche Dateien vom Master kopiert werden. Bei manchen Statusdateien zieht es Probleme nach sich, wenn die zugehörigen Daten nicht ebenfalls vorhanden sind. Heartbeat legt auch einige Dateien an, die man tunlichst nicht spiegeln sollte. In /var/lib/heartbeat liegt z.B. hb_uuid, die einen eindeutigen Namen des Knotens enthält.

   heartbeat[2874]: 2008/10/13_10:01:25 WARN: nodename node01 uuid changed to node02
   heartbeat[2874]: 2008/10/13_10:01:26 WARN: nodename node02 uuid changed to node01
   heartbeat[2874]: 2008/10/13_10:01:26 ERROR: should_drop_message: attempted replay attack [node01]? [gen = 1224687043, curgen = 1224687044]
   heartbeat[2874]: 2008/10/13_10:01:26 ERROR: should_drop_message: attempted replay attack [node01]? [gen = 1224687043, curgen = 1224687044]

Diese Meldungen findet man zuhauf in den Logdateien, wenn Heartbeat soweit verwirrt ist, weil die uuid auf beiden Knoten im Cluster die gleiche ist. Auf einem der Rechner diese Datei zu löschen hilft.