16.09.2020
Pacemaker – Problem: Eine Node scheint nicht mehr synchron zu sein (crm status Ausgaben weichen ab)
Obwohl beide Nodes als "online" angezeigt werden, zeigt eine der Nodes im Cluster andere Ausgaben in crm_mon oder crm status als die zweite. Die Cluster Konfiguration st aus irgendeinem Grund auf beiden Systemen auseinander gedriftet.
Problem
Eine der Nodes im Cluster zeigt eine andere Ausgabe in
crm_mon oder
crm status als die andere Node (zum Beispiel eine hat den Maintenance Mode akzeptiert, die andere nicht). Beide Nodes sind aber oben als
Online: [...] gekennzeichnet. Das syslog zeigt Einträge wie diese:
Jan 28 20:45:00 test cib: [4574]: notice: cib_server_process_diff: Not applying diff 0.970.7 -> 0.970.8 (sync in progress) Jan 28 20:45:00 test cib: [4574]: notice: cib_server_process_diff: Not applying diff 0.970.8 -> 0.970.9 (sync in progress) Jan 28 20:45:00 test cib: [4574]: notice: cib_server_process_diff: Not applying diff 0.970.9 -> 0.970.10 (sync in progress) ODER Jan 28 20:45:02 test cib: [4015]: ERROR: validate_cib_digest: Digest comparision failed: expected 8e90120c95fc5e7b4815e388b6effd76 (/var/lib/heartbeat/crm/cib.EhkT8Z), calculated 68ae85a215453ccbf5ffadee5f305b89 Jan 28 20:45:02 test cib: [4015]: ERROR: retrieveCib: Checksum of /var/lib/heartbeat/crm/cib.TdopvL failed! Configuration contents ignored! Jan 28 20:45:02 test cib: [4015]: ERROR: retrieveCib: Usually this is caused by manual changes, please refer to http://clusterlabs.org/wiki/FAQ#cib_changes_detected Jan 28 20:45:02 test cib: [4015]: ERROR: crm_abort: write_cib_contents: Triggered fatal assert at io.c:662 : retrieveCib(tmp1, tmp2, FALSE) != NULL Jan 28 20:45:02 test cib: [4574]: WARN: Managed write_cib_contents process 4015 killed by signal 6 [SIGABRT - Abort]. Jan 28 20:45:02 test cib: [4574]: ERROR: Managed write_cib_contents process 4015 dumped core Jan 28 20:45:02 test cib: [4574]: ERROR: cib_diskwrite_complete: Disk write failed: status=134, signo=6, exitcode=0 Jan 28 20:45:02 test cib: [4574]: ERROR: cib_diskwrite_complete: Disabling disk writes after write failure ODER Jan 28 23:48:17 test heartbeat: [23084]: ERROR: glib: mcast_write: Unable to send HBcomm packet vlan100 239.0.0.42:694 len=67419 [-1]: Message too long Jan 28 23:48:17 test heartbeat: [23084]: ERROR: write_child: write failure on mcast vlan100.: Message too long
Analyse
In diesem Fall ist die Cluster Konfiguration (cib.xml) aus irgendeinem Grund (z.B. cleanup) auf beiden Systemen auseinander gedriftet. Die Versionen stimmten nicht mehr überein, der "Current DC" zeigt meist den richtigen Stand. (In einem Fall passiert:) Irgendwann hat das fehlerhafte System nochmal aufgeholt, aber ist direkt danach wieder abgedriftet. Später sind dann aus unbekannten Gründen (vermutlich wegen diversen IP Failovers) Netzwerkfehler wie oben beschrieben aufgetreten.
Lösung 1
Wenn der reagierende Host (meist Current DC im crm_mon) sich mit
crm configure property maintenance-mode=true in den Maintenance Mode versetzen lässt, kann man den nicht mehr responsiven Knoten auf dessen Konsole per
crm node standby evtl. aus dem Cluster bekommen, dann z.B. Heartbeat neustarten.
Lösung 2
Letzter-Ausweg Potentiell sehr gefährlich. Daher Verwendung auf eigene Gefahr und Verantwortung (hier dokumentiert als "letzter Ausweg" wenn gar nichts mehr geht):
- Gefahren: Verlust der Konfiguration, komplizierte Split-Brain Szenarien
- Alternative 1: Kill des crmd und alle anderen Heartbeat Prozesse auf dem System das nicht mehr reagiert, danach wieder anstarten.
- Alternative 2: cib.xml zurücksetzen (gefährlich bei falscher Ausführung, hat in einem Fall aber geholfen):
- Nun sollten die Knoten sich sehen und wieder synchron sein
- Wenn die Probleme weiter auftreten, könnte es sich um ein Netzwerkproblem handeln.
