Lösungen und Tipps von den mpex Profis

mpex Techblog

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):
    • Heartbeat in Maintenance Mode versetzen, auf Node wo es möglich ist
    • Sicherheitskopien des kompletten /var/lib/heartbeat/crm auf allen Nodes erstellen (unbedingt mit "cp -a")
    • Auf allen Nodes Heartbeat stoppen, dort wo nicht möglich alle Prozesse killen
      ps ax | grep heartbeat
    • Auf allen Nodes rm /var/lib/heartbeat/crm/* (löscht alle CIB Dateien, wir haben ja eine Sicherung)
    • Auf der Node, deren CIB man am ehesten vertraut (Sichtprüfung), die cib.xml aus der Sicherung zurückkopieren
      cp -a cib.xml /var/lib/heartbeat/crm
    • <!> cib.xml nochmal editieren, wenn "maintenance-mode" auf "false" ist, dann zu "true" ändern; wenn gar nicht vorhanden, dann maintenance-mode Eintrag manuell erzeugen (innerhalb von "cluster_property_set"):
      <nvpair id="cib-bootstrap-options-maintenance-mode" name="maintenance-mode" value="true"/>
    • Heartbeat auf dem System anstarten, wo man die cib.xml wiederhergestellt hat
    • Warten bis crm_mon die Node wieder Up zeigt (kann dauern), wegen Maitnenancen Mode werden evtl. nicht alle Primitives angezeigt, das ist ok
    • Nun auf der zweiten Node heartbeat anstarten, es kann eine halbe Ewigkeit dauern, bis sich was auf der Node in crm_mon zeigt!
  • Nun sollten die Knoten sich sehen und wieder synchron sein
  • Wenn die Probleme weiter auftreten, könnte es sich um ein Netzwerkproblem handeln.

Kann mpex weiterhelfen?

Mit über 20 Jahren Erfahrung im Bereich Managed Hosting haben wir ein umfangreiches Repertoire an Problemlösungen angesammelt, die uns beim Betrieb von Serverumgebungen auf höchstem technischen Niveau geholfen haben. Unsere Systeme bauen komplett auf Open-Source-Technologien auf. Damit sind wir flexibel und können bei technischen Schwierigkeiten direkt selbst eingreifen. Analog zur Open-Source-Idee haben wir uns für diesen Techblog entschieden, um unsere Expertise und Problemlösungen mit dir zu teilen. Dazu zählen Technologien wie Bacula, Debian, Pacemaker, Puppet, diverse allgemeine Serverprobleme und noch vieles darüber hinaus. Wenn du mehr über unsere individuellen Business-Lösungen erfahren und dich als Admin auf deine Kernkompetenzen konzentrieren möchtest, sprich uns einfach an. Wir realisieren das Managed Hosting deiner Anwendung und kümmern uns in Zukunft um all solche Probleme.

Zum Kontaktformular
mpex GmbH
Weitere Blog Artikel
27.09.2020

Pacemaker – Problem: libvirt-Gast reagiert nicht auf ACPI-Poweroff-Event

Der libvirt-Gast reagiert nicht auf das ACPI-Poweroff-Event. Es ist Vorsicht geboten, denn nach 1:25 Minuten setzt Pacemaker den `virsh destroy` nach und richtet damit möglicherweise Schaden an.

Artikel lesen
23.09.2020

Server – Problem: Keine Tastatur verfügbar (z.B. via IPMI)

Wenn das initrd ein Fehler hat, funktionieren Tastatureingaben, z.B. Passworteingabe beim Entschlüsseln oder zum Benutzen der Busybox Shell, nicht.

Artikel lesen

Kontaktformular - Sprechen Sie uns an!

Sprechen Sie uns an!

Sie wollen mehr über uns und unsere Leistungen erfahren? Lernen Sie uns im persönlichen Gespräch kennen!

Telefon: +49 30 780 97 180
E-Mail: info@mpex.de