HA Fencing bei Update einer anderen Node

[TanDE]

Guten Morgen zusammen,

wir hatten letzte Woche einen sehr seltsamen Fall. Wir betreiben seit mehreren Jahren ein 10 Node PVE Cluster (inkl. CEPH) und hatten bis jetzt noch nie nennenswerte Probleme. Das Cluster läuft extrem stabil und wir sind sehr zufrieden. Aber: Wir haben letzte Woche das Cluster von 7.3 auf 7.4 aktualisiert und bei dem Update einer einzelnen Node sind zwei unbeteiligte Nodes in den Status Fencing gegangen und haben einen Neustart durchgeführt. Da nun (neben den VMs) drei (von insgesamt. 7) CEPH Nodes down waren, gab es massive IO Probleme und dies hat weitere VMs zum crashen gebracht.

Jetzt meine Frage: Was kann hier passiert sein? Warum startet der HA Daemon zwei (unbeteiligte) und einwandfrei laufende Hosts neu, wenn auf einer einzelnen leeren Maschine gerade ein Update durchgeführt wird?

Hier ein paar Eckdaten:

• Update von PVE 7.3.6 auf die letzte Version 7.4
• OVS im Einsatz
• CEPH Stand ist (noch) Pacific (16.2.13)
• CEPH NoOut Flag war aktiv, ansonsten war das Cluster vollständig "Healthy"
• Das Problem ist bei dem Update von Host 2 von 10 aufgetreten.
• Der Host war leer (keine VM).
• Das Problem ist am Ende des Updates aufgetreten, da wo die Dienste jeweils neu gestartet werden. Ich glaube, beim Neustart des HA Managers sind kurz danach die beiden anderen Hosts (noch 7.3er Stand) einfach neu gestartet (Fencing).
• Alle Server haben 4x 25 Gbit/s (jeweils 2x in LACP Teams). Corosync hat 2 separate Netze (Rings) über die separaten LACP Teams. Die Netze laufen auch auf separate Switche, die jeweils mit 2x 100 Gbit/s gestacked sind.
• Cluster / HA Master Node war wieder eine ganz andere (nicht beteiligte).
• Wir haben auf 4 Hosts CEPH Monitore und Manager aktiv. Beide unerwartet neu gestarteten Nodes hatten einen Monitor und Manager aktiv. Die Node, wo das Update lief nicht.
• Beim anschließenden Update der restlichen Nodes gab es keinerlei Probleme (außer ggf. kurze IO Waits beim Peering).

Hatte jemand von euch schon mal ein ähnliches Problem? Unser Vertrauen ist gerade etwas getrübt, wenn bei so einer "Standard Prozedur" (die nie Probleme gemacht hat) plötzlich derart massive Probleme auftreten. Vor allem waren die beiden neu gestarteten Hosts absolut unauffällig und fehlerfrei.

Das einzig interessante, was ich auf den beiden neu gestarteten Nodes finden kann, ist:

root@pve04:/var/log# cat syslog | grep pve-ha
Aug 31 16:09:30 pve04 pve-ha-lrm[3812]: lost lock 'ha_agent_pve04_lock - cfs lock update failed - Device or resource busy
Aug 31 16:09:30 pve04 pve-ha-lrm[3812]: status change active => lost_agent_lock
Aug 31 16:09:30 pve04 pve-ha-crm[3340]: loop take too long (31 seconds)
Aug 31 16:09:30 pve04 pve-ha-crm[3340]: status change slave => wait_for_quorum
Aug 31 16:12:25 pve04 pve-ha-crm[3020]: starting server
Aug 31 16:12:25 pve04 pve-ha-crm[3020]: status change startup => wait_for_quorum
Aug 31 16:12:26 pve04 pve-ha-lrm[3029]: starting server
Aug 31 16:12:26 pve04 pve-ha-lrm[3029]: status change startup => wait_for_agent_lock
Aug 31 16:12:35 pve04 pve-ha-crm[3020]: status change wait_for_quorum => slave
Aug 31 16:13:32 pve04 pve-ha-lrm[3029]: successfully acquired lock 'ha_agent_pve04_lock'
Aug 31 16:13:32 pve04 pve-ha-lrm[3029]: watchdog active
Aug 31 16:13:32 pve04 pve-ha-lrm[3029]: status change wait_for_agent_lock => active
Aug 31 16:13:32 pve04 pve-ha-lrm[8482]: starting service vm:112
Aug 31 16:13:32 pve04 pve-ha-lrm[8483]: starting service vm:386
Aug 31 16:13:32 pve04 pve-ha-lrm[8485]: starting service vm:411

und

Aug 31 16:09:30 pve03 pve-ha-lrm[3898]: lost lock 'ha_agent_pve03_lock - cfs lock update failed - Device or resource busy
Aug 31 16:09:30 pve03 pve-ha-lrm[3898]: status change active => lost_agent_lock
Aug 31 16:09:31 pve03 pve-ha-crm[3283]: loop take too long (31 seconds)
Aug 31 16:09:31 pve03 pve-ha-crm[3283]: status change slave => wait_for_quorum
Aug 31 16:12:51 pve03 pve-ha-crm[2992]: starting server
Aug 31 16:12:51 pve03 pve-ha-crm[2992]: status change startup => wait_for_quorum
Aug 31 16:12:52 pve03 pve-ha-lrm[3001]: starting server
Aug 31 16:12:52 pve03 pve-ha-lrm[3001]: status change startup => wait_for_agent_lock
Aug 31 16:13:01 pve03 pve-ha-crm[2992]: status change wait_for_quorum => slave
Aug 31 16:13:33 pve03 pve-ha-lrm[3001]: successfully acquired lock 'ha_agent_pve03_lock'
Aug 31 16:13:33 pve03 pve-ha-lrm[3001]: watchdog active
Aug 31 16:13:33 pve03 pve-ha-lrm[3001]: status change wait_for_agent_lock => active
Aug 31 16:13:33 pve03 pve-ha-lrm[8101]: starting service vm:390
Aug 31 16:13:33 pve03 pve-ha-lrm[8100]: starting service vm:203

Und zu COROSYNC:

Aug 31 16:09:08 pve03 corosync[1984]:   [KNET  ] link: host: 8 link: 0 is down
Aug 31 16:09:08 pve03 corosync[1984]:   [KNET  ] host: host: 8 (passive) best link: 1 (pri: 1)
Aug 31 16:09:09 pve03 corosync[1984]:   [TOTEM ] Token has not been received in 6150 ms
Aug 31 16:09:20 pve03 corosync[1984]:   [QUORUM] Sync members[3]: 3 4 8
Aug 31 16:09:20 pve03 corosync[1984]:   [QUORUM] Sync left[7]: 1 2 5 6 7 9 10
Aug 31 16:09:20 pve03 corosync[1984]:   [TOTEM ] A new membership (3.60b) was formed. Members left: 1 2 5 6 7 9 10
Aug 31 16:09:20 pve03 corosync[1984]:   [TOTEM ] Failed to receive the leave message. failed: 1 2 5 6 7 9 10
Aug 31 16:09:30 pve03 corosync[1984]:   [QUORUM] Sync members[3]: 3 4 8
Aug 31 16:09:30 pve03 corosync[1984]:   [QUORUM] Sync joined[2]: 4 8
Aug 31 16:09:30 pve03 corosync[1984]:   [QUORUM] Sync left[9]: 1 2 4 5 6 7 8 9 10
Aug 31 16:09:30 pve03 corosync[1984]:   [TOTEM ] A new membership (3.613) was formed. Members joined: 4 8 left: 4 8
Aug 31 16:09:30 pve03 corosync[1984]:   [TOTEM ] Failed to receive the leave message. failed: 4 8
Aug 31 16:09:30 pve03 corosync[1984]:   [TOTEM ] Retransmit List: 1 2
Aug 31 16:09:30 pve03 corosync[1984]:   [QUORUM] This node is within the non-primary component and will NOT provide any services.
Aug 31 16:09:30 pve03 corosync[1984]:   [QUORUM] Members[3]: 3 4 8
Aug 31 16:09:30 pve03 corosync[1984]:   [MAIN  ] Completed service synchronization, ready to provide service.
Aug 31 16:09:49 pve03 corosync[1984]:   [QUORUM] Sync members[3]: 3 4 8
Aug 31 16:09:49 pve03 corosync[1984]:   [QUORUM] Sync joined[2]: 4 8
Aug 31 16:09:49 pve03 corosync[1984]:   [QUORUM] Sync left[2]: 4 8
Aug 31 16:09:49 pve03 corosync[1984]:   [TOTEM ] A new membership (3.61b) was formed. Members joined: 4 8 left: 4 8
Aug 31 16:09:49 pve03 corosync[1984]:   [TOTEM ] Failed to receive the leave message. failed: 4 8
Aug 31 16:09:49 pve03 corosync[1984]:   [TOTEM ] Retransmit List: 1
Aug 31 16:09:49 pve03 corosync[1984]:   [QUORUM] Members[3]: 3 4 8
Aug 31 16:09:49 pve03 corosync[1984]:   [MAIN  ] Completed service synchronization, ready to provide service.
Aug 31 16:09:58 pve03 corosync[1984]:   [KNET  ] link: host: 8 link: 1 is down
Aug 31 16:09:58 pve03 corosync[1984]:   [KNET  ] host: host: 8 (passive) best link: 1 (pri: 1)
Aug 31 16:09:58 pve03 corosync[1984]:   [KNET  ] host: host: 8 has no active links

Aug 31 16:09:05 pve04 corosync[1991]:   [KNET  ] link: host: 8 link: 1 is down
Aug 31 16:09:05 pve04 corosync[1991]:   [KNET  ] host: host: 8 (passive) best link: 0 (pri: 1)
Aug 31 16:09:09 pve04 corosync[1991]:   [TOTEM ] Token has not been received in 6150 ms
Aug 31 16:09:20 pve04 corosync[1991]:   [QUORUM] Sync members[3]: 3 4 8
Aug 31 16:09:20 pve04 corosync[1991]:   [QUORUM] Sync left[7]: 1 2 5 6 7 9 10
Aug 31 16:09:20 pve04 corosync[1991]:   [TOTEM ] A new membership (3.60b) was formed. Members left: 1 2 5 6 7 9 10
Aug 31 16:09:20 pve04 corosync[1991]:   [TOTEM ] Failed to receive the leave message. failed: 1 2 5 6 7 9 10
Aug 31 16:09:30 pve04 corosync[1991]:   [QUORUM] Sync members[3]: 3 4 8
Aug 31 16:09:30 pve04 corosync[1991]:   [QUORUM] Sync left[7]: 1 2 5 6 7 9 10
Aug 31 16:09:30 pve04 corosync[1991]:   [TOTEM ] A new membership (3.60f) was formed. Members
Aug 31 16:09:30 pve04 corosync[1991]:   [QUORUM] Sync members[3]: 3 4 8
Aug 31 16:09:30 pve04 corosync[1991]:   [QUORUM] Sync joined[1]: 3
Aug 31 16:09:30 pve04 corosync[1991]:   [QUORUM] Sync left[8]: 1 2 3 5 6 7 9 10
Aug 31 16:09:30 pve04 corosync[1991]:   [TOTEM ] A new membership (3.613) was formed. Members joined: 3 left: 3
Aug 31 16:09:30 pve04 corosync[1991]:   [TOTEM ] Failed to receive the leave message. failed: 3
Aug 31 16:09:30 pve04 corosync[1991]:   [QUORUM] This node is within the non-primary component and will NOT provide any services.
Aug 31 16:09:30 pve04 corosync[1991]:   [QUORUM] Members[3]: 3 4 8
Aug 31 16:09:30 pve04 corosync[1991]:   [MAIN  ] Completed service synchronization, ready to provide service.
Aug 31 16:09:49 pve04 corosync[1991]:   [QUORUM] Sync members[3]: 3 4 8
Aug 31 16:09:49 pve04 corosync[1991]:   [TOTEM ] A new membership (3.617) was formed. Members
Aug 31 16:09:49 pve04 corosync[1991]:   [QUORUM] Sync members[3]: 3 4 8
Aug 31 16:09:49 pve04 corosync[1991]:   [QUORUM] Sync joined[1]: 3
Aug 31 16:09:49 pve04 corosync[1991]:   [QUORUM] Sync left[1]: 3
Aug 31 16:09:49 pve04 corosync[1991]:   [TOTEM ] A new membership (3.61b) was formed. Members joined: 3 left: 3
Aug 31 16:09:49 pve04 corosync[1991]:   [TOTEM ] Failed to receive the leave message. failed: 3
Aug 31 16:09:49 pve04 corosync[1991]:   [QUORUM] Members[3]: 3 4 8
Aug 31 16:09:49 pve04 corosync[1991]:   [MAIN  ] Completed service synchronization, ready to provide service.

Host ID 8 war die Node, bei der gerade das apt full-upgrade lief...

Das Syslog auf dieser Node 8 sieht wie folgt aus (der Vollständigkeit halber):

Aug 31 16:09:19 pve08 pve-ha-lrm[4135]: unable to write lrm status file - unable to open file '/etc/pve/nodes/pve08/lrm_status.tmp.4135' - Transport endpoint is not connected
Aug 31 16:09:19 pve08 pve-ha-crm[3729]: status change slave => wait_for_quorum
Aug 31 16:09:30 pve08 pve-ha-crm[3729]: status change wait_for_quorum => slave
Aug 31 16:09:30 pve08 pve-ha-crm[3729]: status change slave => wait_for_quorum
Aug 31 16:09:30 pve08 pve-ha-lrm[4135]: received signal TERM
Aug 31 16:09:30 pve08 pve-ha-lrm[4135]: restart LRM, freeze all services
Aug 31 16:09:30 pve08 pve-ha-lrm[4135]: unable to update lrm status file - not quorate?
Aug 31 16:09:30 pve08 pve-ha-lrm[4135]: unable to write lrm status file - unable to open file '/etc/pve/nodes/pve08/lrm_status.tmp.4135' - Permission denied
Aug 31 16:09:35 pve08 pve-ha-lrm[4135]: server stopped
Aug 31 16:09:36 pve08 systemd[1]: pve-ha-lrm.service: Succeeded.
Aug 31 16:09:36 pve08 systemd[1]: pve-ha-lrm.service: Consumed 2d 17h 51min 18.688s CPU time.
Aug 31 16:09:37 pve08 pve-ha-lrm[34307]: starting server
Aug 31 16:09:37 pve08 pve-ha-lrm[34307]: status change startup => wait_for_agent_lock
Aug 31 16:09:38 pve08 pve-ha-crm[3729]: received signal TERM
Aug 31 16:09:38 pve08 pve-ha-crm[3729]: server received shutdown request
Aug 31 16:09:38 pve08 pve-ha-crm[3729]: server stopped
Aug 31 16:09:39 pve08 systemd[1]: pve-ha-crm.service: Succeeded.
Aug 31 16:09:39 pve08 systemd[1]: pve-ha-crm.service: Consumed 2h 5min 24.776s CPU time.
Aug 31 16:09:40 pve08 pve-ha-crm[34353]: starting server
Aug 31 16:09:40 pve08 pve-ha-crm[34353]: status change startup => wait_for_quorum

Viele Grüße
Tan

 

[shanreich]

Servus!

Man sieht in den Logs, dass sich diese Nodes vom eigentlichen Cluster und dann ihre eigene Partition gebildet haben:

Aug 31 16:09:08 pve03 corosync[1984]:   [KNET  ] link: host: 8 link: 0 is down
Aug 31 16:09:08 pve03 corosync[1984]:   [KNET  ] host: host: 8 (passive) best link: 1 (pri: 1)
Aug 31 16:09:09 pve03 corosync[1984]:   [TOTEM ] Token has not been received in 6150 ms
Aug 31 16:09:20 pve03 corosync[1984]:   [QUORUM] Sync members[3]: 3 4 8
Aug 31 16:09:20 pve03 corosync[1984]:   [QUORUM] Sync left[7]: 1 2 5 6 7 9 10

Das dürfte aber wohl auch nicht 100%ig geklappt haben, da diese Nodes dann konstant neu synchronisieren bis sie sich schlussendlich fencen. Interessant wäre wohl auch, wie die ganze Situation von einem unbeteiligtem Node ausgesehen hat.

Es sieht so aus als gab es da Probleme mit dem Netzwerk, aber genaueres lässt sich allein auf Basis der Syslogs nicht genau sagen - da wären auf jeden Fall vollständige Syslogs + Upgrade Logs + System Reports sehr interessant.

----------

Interessant ist auch, dass der eine Node link 0 als down erachtet:

Aug 31 16:09:08 pve03 corosync[1984]:   [KNET  ] link: host: 8 link: 0 is down
Aug 31 16:09:08 pve03 corosync[1984]:   [KNET  ] host: host: 8 (passive) best link: 1 (pri: 1)

Der andere allerdings link 1:

Aug 31 16:09:05 pve04 corosync[1991]:   [KNET  ] link: host: 8 link: 1 is down
Aug 31 16:09:05 pve04 corosync[1991]:   [KNET  ] host: host: 8 (passive) best link: 0 (pri: 1)

Warum das der Fall ist, ist schwer zu sagen.

----------

Generell empfehlen wir für Corosync keinen Bond zu verwenden, da Corosync bereits Redundanz und automatisches Switching eingebaut hat, wenn man mehrere Netzwerke konfiguriert hat.

----------

Generell empfiehlt es sich auch bei Updates und Netzwerk-Wartung HA zu deaktivieren. Ihr könnt das mit folgendem Skript machen:

for res in $(ha-manager status | grep service | awk '{print $2}'); do echo "setting to 'ignored': $res"; ha-manager set $res --state ignored; done

HA kann dann wieder mit folgendem Skript aktiviert werden:

for res in $(ha-manager status | grep service | awk '{print $2}'); do echo "setting to 'ignored': $res"; ha-manager set $res --state started; done

 

[Falk R.]

Stefan hat das schon passend geschrieben.
Ja ich kenne solche Probleme aus der Praxis wenn das Netzwerk nicht sauber ist.
Ohne das genaue Layout eures Netzwerks zu kennen, ist das nicht ganz so einfach.

Ist bei euch zufällig das Ceph Netzwerk gleichzeitig Corosync link 0?
Ich habe bei kleineren Clustern schon Traffic bis 60GBit gesehen beim reboot eines Nodes, weil das noout bei Ceph vergessen wurde. Da fängt Ceph ja direkt mit umverteilen der PGs an. Und 2x 25G ist bei einem so großen Cluster ganz schnell gesättigt.

 

[TanDE]

Servus!

Man sieht in den Logs, dass sich diese Nodes vom eigentlichen Cluster und dann ihre eigene Partition gebildet haben:

Aug 31 16:09:08 pve03 corosync[1984]:   [KNET  ] link: host: 8 link: 0 is down
Aug 31 16:09:08 pve03 corosync[1984]:   [KNET  ] host: host: 8 (passive) best link: 1 (pri: 1)
Aug 31 16:09:09 pve03 corosync[1984]:   [TOTEM ] Token has not been received in 6150 ms
Aug 31 16:09:20 pve03 corosync[1984]:   [QUORUM] Sync members[3]: 3 4 8
Aug 31 16:09:20 pve03 corosync[1984]:   [QUORUM] Sync left[7]: 1 2 5 6 7 9 10

Das dürfte aber wohl auch nicht 100%ig geklappt haben, da diese Nodes dann konstant neu synchronisieren bis sie sich schlussendlich fencen. Interessant wäre wohl auch, wie die ganze Situation von einem unbeteiligtem Node ausgesehen hat.

Es sieht so aus als gab es da Probleme mit dem Netzwerk, aber genaueres lässt sich allein auf Basis der Syslogs nicht genau sagen - da wären auf jeden Fall vollständige Syslogs + Upgrade Logs + System Reports sehr interessant.

----------

Interessant ist auch, dass der eine Node link 0 als down erachtet:

Aug 31 16:09:08 pve03 corosync[1984]:   [KNET  ] link: host: 8 link: 0 is down
Aug 31 16:09:08 pve03 corosync[1984]:   [KNET  ] host: host: 8 (passive) best link: 1 (pri: 1)

Der andere allerdings link 1:

Aug 31 16:09:05 pve04 corosync[1991]:   [KNET  ] link: host: 8 link: 1 is down
Aug 31 16:09:05 pve04 corosync[1991]:   [KNET  ] host: host: 8 (passive) best link: 0 (pri: 1)

Warum das der Fall ist, ist schwer zu sagen.

----------

Generell empfehlen wir für Corosync keinen Bond zu verwenden, da Corosync bereits Redundanz und automatisches Switching eingebaut hat, wenn man mehrere Netzwerke konfiguriert hat.

----------

Generell empfiehlt es sich auch bei Updates und Netzwerk-Wartung HA zu deaktivieren. Ihr könnt das mit folgendem Skript machen:

for res in $(ha-manager status | grep service | awk '{print $2}'); do echo "setting to 'ignored': $res"; ha-manager set $res --state ignored; done

HA kann dann wieder mit folgendem Skript aktiviert werden:

for res in $(ha-manager status | grep service | awk '{print $2}'); do echo "setting to 'ignored': $res"; ha-manager set $res --state started; done

Hallo Stefan,

vielen Dank für deine Antwort. Das habe ich im Log auch gesehen, aber nicht verstanden, warum diese 3 Hosts plötzlich eine eigene Partition bilden, das würde dann zumindest das Fencing erklären. PVE08 war während des Updates kurzzeitig nicht erreichbar, da die OpenvSwitch Dienste neu gestartet wurden. das sieht man auch auf allen anderen Hosts (host 8 link 0 und 1 down). Auf PVE03 wurde der link 1 down erst 50s später protokolliert, keine Ahnung warum. Zu dem Zeitpunkt gab es auch keinen nennenswerten Traffic (u.a. wg. CEPH Flag NoOut).

Danke für den Tipp bezgl. den Bonds. Ich glaube aber nicht, das dies hier die Ursache war. Netzwerkprobleme schließe ich tatsächlich aus, da ich ansonsten keinerlei Anzeichen dafür sehe (in dem Moment wo PVE03 und PVE04 die eigene Partition gebildet haben). Sonst hätte man auf anderen Hosts auch mehr OSD Timeouts und Corosync Meldungen sehen müssen. Die Switch Logs sind auch unauffällig.

Unser Netzwerksetup sieht aktuell wie folgt aus:
Bond 0 (2x 25 Gbit/s) - VM Traffic / Cluster Link 0 (über separate VLANS)
Bond 1 (2x 25 Gbit/s) - CEPH / Cluster Link 1 (über separate VLANS)

Bezgl. HA Deaktivierung: Ich kannte nur den Weg über CRM/LRM Daemons stoppen (in der richtigen Reihenfolge) und davor habe ich mich etwas gesträubt). Ich werde deine Variante das nächste Mal anwenden. Ist das auch irgendwo bei euch in der Doku hinterlegt? Einiziger Nachteil: Ich nutze HA Gruppen (preferred_pveXX) um Hosts vor einem Update leer zu migrieren (indem die jeweilige Prio in der Gruppe reduziert wird). Der HA Manager verteilt dann die VMs nach unseren Vorgaben auf die anderen Hosts und das klappt auch super.

Das wird dann nicht mehr möglich sein, oder? Oder kann man "nur" das Cluster Fencing deaktivieren??

Die Logs findest du hier (auf Grund der Größe / PW: proxmox):
Log Files

PVE03 = Host mit unerwartetem Neustart (Fencing)
PVE04 = Host mit unerwartetem Neustart (Fencing)
PVE05 = Unbeteiligter Host / HA Master
PVE08 = Host mit dem Upgrade von 7.3 auf 7.4 Update

Viele Grüße
Tan

 

[TanDE]

Stefan hat das schon passend geschrieben.
Ja ich kenne solche Probleme aus der Praxis wenn das Netzwerk nicht sauber ist.
Ohne das genaue Layout eures Netzwerks zu kennen, ist das nicht ganz so einfach.

Ist bei euch zufällig das Ceph Netzwerk gleichzeitig Corosync link 0?
Ich habe bei kleineren Clustern schon Traffic bis 60GBit gesehen beim reboot eines Nodes, weil das noout bei Ceph vergessen wurde. Da fängt Ceph ja direkt mit umverteilen der PGs an. Und 2x 25G ist bei einem so großen Cluster ganz schnell gesättigt.

Hi Falk,

vielen Dank für deine Nachricht. Ich habe mal ein paar Infos zum Netzwerksetup in meiner letzten Antwort ergänzt. Ich schließe hier aber Netzwerkprobleme aus, da es dafür keine weiteren Anzeichen gibt.

Corosync link 0 und CEPH sind vollständig separiert. Wir hatten bis jetzt auch noch nie Probleme / Beeinträchtigungen bei z.B. neuen OSDs und einem sehr ordentlichen Rebuild Traffic (auf Grund der Netzwerk Bandbreite, eingesetzter Hardware und Separierung der Netze).

Um so mehr wundert mich der Vorfall... :-/

LG Tan

 

[Falk R.]

Hi Falk,

vielen Dank für deine Nachricht. Ich habe mal ein paar Infos zum Netzwerksetup in meiner letzten Antwort ergänzt. Ich schließe hier aber Netzwerkprobleme aus, da es dafür keine weiteren Anzeichen gibt.

Corosync link 0 und CEPH sind vollständig separiert. Wir hatten bis jetzt auch noch nie Probleme / Beeinträchtigungen bei z.B. neuen OSDs und einem sehr ordentlichen Rebuild Traffic (auf Grund der Netzwerk Bandbreite, eingesetzter Hardware und Separierung der Netze).

Um so mehr wundert mich der Vorfall... :-/

LG Tan

Hast du auf den Switches mal geschaut, ob da eventuell Fehler bei einem Port sind?

 

[TanDE]

Hast du auf den Switches mal geschaut, ob da eventuell Fehler bei einem Port sind?

Ja, alles unauffällig. Keine CRC Fehler, Discards o.ä. (Port Counter sind 26 Wochen alt).
Wir betreiben aber auch ein sehr detailliertes Monitoring der Umgebung und der VMs. Allg. "Konnektivitätsprobleme" (Packet Loss, etc.) wären dann schon aufgefallen.

Der Punkt ist ja: Die beiden Hosts (die unerwartet neu gestartet sind) liefen bis zu dem Zeitpunkt völlig einwandfrei (inkl. der VMs). Netzwerkprobleme hätten wir dann mindestens im CEPH oder direkt auf den Kunden VMs sehen müssen.

Btw: Ich könnt es ja noch verstehen, wenn durch eine Fehlkonfiguration eines Bonds dann ein einzelner anderer Host beeinträchtigt wäre, aber gleich ZWEI?? Außerdem ist das ja nicht das erste Cluster Upgrade mit genau diesem Netzwerk Setup und das ist noch nie passiert.

 

[shanreich]

Es sieht für mich schon so aus, als ob das Netzwerk da Probleme hat. In den Logs sieht man in den Tagen davor viele Meldungen mit Retransmit List:, was auf generelle Probleme mit dem Netzwerk hindeutet.

Bspw:

pve08-syslog.txt:Aug 30 08:36:18 pve08 corosync[2092]:   [TOTEM ] Retransmit List: 1326238
pve08-syslog.txt:Aug 30 08:36:18 pve08 corosync[2092]:   [TOTEM ] Retransmit List: 1326238 1326239
pve08-syslog.txt:Aug 30 08:36:18 pve08 corosync[2092]:   [TOTEM ] Retransmit List: 1326238 1326239 132623a
pve08-syslog.txt:Aug 30 08:36:18 pve08 corosync[2092]:   [TOTEM ] Retransmit List: 1326238 1326239 132623a 132623b
pve08-syslog.txt:Aug 30 08:36:18 pve08 corosync[2092]:   [TOTEM ] Retransmit List: 1326238 1326239 132623a 132623b 132623c
pve08-syslog.txt:Aug 30 08:36:18 pve08 corosync[2092]:   [TOTEM ] Retransmit List: 1326238 1326239 132623a 132623b 132623c 132623d

oder

pve04-syslog.txt:Aug 27 04:10:06 pve04 corosync[1991]:   [TOTEM ] Retransmit List: cccfc7
pve04-syslog.txt:Aug 27 05:01:34 pve04 corosync[1991]:   [TOTEM ] Retransmit List: cdf2c8 cdf2c9 cdf2cb cdf2cc cdf2cd
pve04-syslog.txt:Aug 27 05:01:34 pve04 corosync[1991]:   [TOTEM ] Retransmit List: cdf2c8 cdf2c9 cdf2cb cdf2cc cdf2cd
pve04-syslog.txt:Aug 27 05:01:34 pve04 corosync[1991]:   [TOTEM ] Retransmit List: cdf2c8 cdf2c9 cdf2cb cdf2cc cdf2cd cdf2d0
pve04-syslog.txt:Aug 27 05:01:34 pve04 corosync[1991]:   [TOTEM ] Retransmit List: cdf2c8 cdf2c9 cdf2cb cdf2cc cdf2cd cdf2d0

Das sind nur einige Auszüge, da findet man davor / danach einiges was nicht mit den Updates in Verbindung zu bringen ist. Das ist ein sehr starker Indikator, dass das Netzwerk öfter mal Probleme hat. Nachdem da auch der VM-Traffic drüber geht, kann es gut sein, dass der dann Corosync beeinträchtigt. Corosync braucht zwar nicht viel Bandbreite, aber ist sehr empfindlich bezüglich Latenz weshalb es bei viel Traffic dann zu Problemen kommen kann. Da braucht man dann auch gar keinen Packet Loss o.Ä. - eine höhere Latenz reicht da schon aus.

Zwischen 16:09 und 16:22 sieht man auch dass die heartbeat_checks von den OSDs auf pve08 zu quasi allen hosts failen, was ein weiterer Indikator dafür ist, dass da das Netzwerk da zumindest komplett weg war:

   7579 10.254.12.1
   7734 10.254.12.2
  34626 10.254.12.3
  23102 10.254.12.4
   7441 10.254.12.6
      2 10.254.12.8
  10272 10.254.12.9

------

Habt Ihr Netzwerk-Monitoring? Wie schaut denn der Traffic zu dem Zeitpunkt aus?

Es sieht auf jeden Fall so aus als konnte nach dem OVS-Restart Host 8 nur mehr Hosts 3 & 4 finden und die haben dann für kurze Zeit eine Partition gebildet - aber sich dann auch wieder recht schnell wieder verloren. Ebenso haben dann die Hosts 3 & 4 nicht mehr den Anschluss an den quoraten Teil gefunden, weshalb sie sich dann gefenced haben. Das deutet alles auf irgendein grundlegendes Problem mit dem Netzwerk hin. Bonds verkomplizieren das ganze noch wesentlich, da gibt es dann oft Situationen, die komisch aussehen (so wie hier) und quasi unmöglich zu debuggen sind. Es wird auch schwer sein das Ganze im Nachhinhein 100%ig aufzuklären, speziell, wenn man keine Corosync Debug-Logs hat. Derartige Symptomatiken kenne ich allerdings ganz gut mittlerweile und in jedem Fall war es dann irgendein unterliegendes Problem mit dem Netzwerk - in welcher Form auch immer. Ich gehe stark davon aus, dass das auch hier so ist. Ich würde stark dazu raten Corosync ein komplett eigenes Netzwerk zu geben für den Anfang.

Einiziger Nachteil: Ich nutze HA Gruppen (preferred_pveXX) um Hosts vor einem Update leer zu migrieren (indem die jeweilige Prio in der Gruppe reduziert wird). Der HA Manager verteilt dann die VMs nach unseren Vorgaben auf die anderen Hosts und das klappt auch super.

Das wird dann nicht mehr möglich sein, oder? Oder kann man "nur" das Cluster Fencing deaktivieren??

Man kann das Fencing leider nicht deaktivieren, ohne HA zu deaktivieren. Man müsste wohl die VMs migrieren und dann HA deaktivieren und updaten. Danach kann man HA wieder aktivieren, um die VMs wieder zu verschieben. Ist wohl etwas mehr Aufwand, aber ad hoc fällt mir keine bessere Möglichkeit ein.

 

[Falk R.]

Hi Tan,
wollen wir dem ganzen etwas auf den Grund gehen? Mich interessiert die Ursache auch.
Benutzt ihr für die 25G Verbindungen DAC oder SFP28? Wenn ihr Fiber benutzt, habt ihr auch schon mal auf die Transceiver Statistiken geschaut?

 

[TanDE]

Hallo zusammen,

weiter unten mal die Netzwerkauslastung der 4 physikalischen NICs auf PVE03. Da ist wirklich nichts los, erst nach dem Reboot kommt etwas Traffic (knapp jeweils 2 Gbit/s pro NIC im Bond) für den CEPH Sync. Ich würde bei so einem Phänomen normalerweise auch direkt auf Netzwerk tippen (die Retansmission Einträge im Log schaue ich mir mal an), aber: ich kann mir immer noch nicht vorstellen, warum der Link Down auf Host 8 (durch den OVS Neustart) andere Hosts mit runter zieht, zumal die Bonds auch über zwei physikalische Switche geführt werden (btw: die DELL Switche unterstützen dies / VLT Domain).

@shanreich

Zwischen 16:09 und 16:22 sieht man auch dass die heartbeat_checks von den OSDs auf pve08 zu quasi allen hosts failen, was ein weiterer Indikator dafür ist, dass da das Netzwerk da zumindest komplett weg war:

Da wurde der OVS Dienst nach dem Update auf PVE08 neu gestartet und die Maschine war nicht mehr erreichbar, bis ich dann etwas später per iDRAC ein Power Off eingeleitet habe.

@Falk R. Ja, sehr gerne ;-) Wir nutzen ausschließlich DAC an den SFP28 Ports der DELL Switche (zu den Hosts).

 

[TanDE]

Man kann das Fencing leider nicht deaktivieren, ohne HA zu deaktivieren. Man müsste wohl die VMs migrieren und dann HA deaktivieren und updaten. Danach kann man HA wieder aktivieren, um die VMs wieder zu verschieben. Ist wohl etwas mehr Aufwand, aber ad hoc fällt mir keine bessere Möglichkeit ein.

Deine Einzeiler setzen aber "nur" den HA-Status aller VMs auf ignored, auch die, die kein HA aktiv haben und setzt anschließend blind bei allen wieder auf started (selbst wenn die VMs bewusst gestoppt sind). Das ist ja nicht immer gewollt / gewünscht. ;-)

Betrifft das dann auch das HW Cluster HA (Fencing etc.) oder nur die VMs?

 

[Falk R.]

Nutzt ihr zufällig LACP auf einem VLT?
VLT ist die MLAG Umsetzung von Dell (Force10).
MLAG ist nur ein LAG und kann kein LACP Protokoll sprechen.

Du hast oben nur Bond geschrieben.

 

[TanDE]

Nutzt ihr zufällig LACP auf einem VLT?
VLT ist die MLAG Umsetzung von Dell (Force10).
MLAG ist nur ein LAG und kann kein LACP Protokoll sprechen.

Du hast oben nur Bond geschrieben.

Guten Morgen Falk,

das stimmt so nicht so ganz :-/ (vielleicht war das in älteren Versionen der Fall). Unsere Dell EMC mit OS10 unterstützten LACP im Port-Channel innerhalb einer VLT Domain und das ist auch Best Practice (siehe unten).

Laut Recherche müsste das aber auch schon bei älteren FTOS Versionen möglich gewesen sein:



Beispiel eines Port-Channels (Mode active) bei uns:

 

[Falk R.]

OK, dann hat DELL da etwas nachgelegt seit dem Kauf von Force10. Man lernt nie aus.

 

[TanDE]

OK, dann hat DELL da etwas nachgelegt seit dem Kauf von Force10. Man lernt nie aus.

Ist das in der IT nicht immer so Man lernt eigentlich nie aus...

Ich habe gerade im Monitoring kurz vor dem Fencing ganz kleine Ausreißer bei der Latenz von der Monitoring Probe Richtung PVE03 (Cluster Link 0) gesehen, aber im Syslog ist nichts zu finden. Das kann doch nicht ausreichen, um einen Host komplett aus dem Cluster zu werfen!? Vor allem nicht, wenn es noch einen zweiten Ring / Link gibt.



Auf PVE04 sieht alles top aus. Monitoring Probe lag auf PVE07.

 

[Falk R.]

Was ist das für eine Spalte mit den 27% und 100%?

 

[TanDE]

Was ist das für eine Spalte mit den 27% und 100%?

Ausfallzeit innerhalb des 30s Mess-Intervals. Wir messen alle 30s mit 5 Pings / ICMP Request und jeweils 5ms Pause um auch Paketverluste erkennen zu können.

 

[Falk R.]

Das erklärt schon einiges, der Ping ist ausgefallen und dann kommt nach 60 Sekunden das Fencing. Soweit alles korrekt.
Nur die Frage, warum der Ping ausgefallen ist.
Ganz früher hatte ich paar mal Probleme in den ARP Tables von Switches gesehen, die auch immer wieder sporadische Ausfälle gemacht haben. Aber solche Phänomene habe ich die letzten 8 Jahre nicht mehr gesehen. Aber trotzdem könnt ihr mal gucken, ob es da Auffälligkeiten gibt.

 

[TanDE]

Das erklärt schon einiges, der Ping ist ausgefallen und dann kommt nach 60 Sekunden das Fencing. Soweit alles korrekt.
Nur die Frage, warum der Ping ausgefallen ist.
Ganz früher hatte ich paar mal Probleme in den ARP Tables von Switches gesehen, die auch immer wieder sporadische Ausfälle gemacht haben. Aber solche Phänomene habe ich die letzten 8 Jahre nicht mehr gesehen. Aber trotzdem könnt ihr mal gucken, ob es da Auffälligkeiten gibt.

Ich glaube, das liest du falsch.

Um 16:09:30 Uhr haben aus unerklärlichen Gründen die Server 3 + 4 + 8 eine neue Partition gegründet (Node 8 war der einzige Host, woran gearbeitet wurde - Update), Um 16:10 - 16:11 hat der Server einen Reboot durchgeführt, deshalb der Packet Loss / Ping Verlust. Vorher gab es keine Probleme (laut Monitoring). Warum dann das Host Fencing???



PVE04 hat zur gleichen Zeit einen Reboot durchgeführt (auch Fencing).

Ich sehe immer noch keine "Netzwerk Probleme" an den beiden Hosts die so etwas auslösen könnten. Die Monitoring Probe in einer VM auf PVE07 hat NULL Paketverluste zum PVE04 gemessen und trotzdem hat dieser sein Fencing durchgeführt. Das fühlt sich gerade mehr nach Software Bug an als Infrastrukturprobleme.

 

[TanDE]

@shanreich Wären jetzt tatsächlich beide Bonds auf dem PVE03 ausgefallen (und somit beide Corosync Links), müsste ich dann nicht im Log etliche OSD Heartbeat Timeout Meldungen finden?

Um 16:09 war das Netzwerk vom (leeren!) Host PVE08 weg (wg. dem OVS Update/Restart), die OSD Heartbeat Meldungen machen hier natürlich Sinn. Alles andere vorher irgendwie nicht...