Corosync Quorum weg, nachdem 1/3 Hosts neustartete

[intecsoft]

Einer von 3 Servern ('server-02') im Cluster wurde durch Watchdog neugestartet. Die Ursache wird aktuell noch untersucht.
Kurz danach sind die beiden übrigen Server aber ebenfalls neugestartet.

Feb 13 04:22:28 server-01 corosync[2282]:   [QUORUM] Sync members[2]: 4 6
Feb 13 04:22:28 server-01 corosync[2282]:   [QUORUM] Sync left[1]: 5
Feb 13 04:22:28 server-01 corosync[2282]:   [QUORUM] Members[2]: 4 6
Feb 13 04:22:50 server-01 corosync[2282]:   [QUORUM] Sync members[2]: 4 6
Feb 13 04:22:50 server-01 corosync[2282]:   [QUORUM] Members[2]: 4 6
Feb 13 04:24:38 server-01 corosync[2282]:   [QUORUM] Sync members[1]: 6
Feb 13 04:24:38 server-01 corosync[2282]:   [QUORUM] Sync left[1]: 4
Feb 13 04:24:38 server-01 corosync[2282]:   [QUORUM] This node is within the non-primary component and will NOT provide any services.
Feb 13 04:24:38 server-01 corosync[2282]:   [QUORUM] Members[1]: 6
Feb 13 04:24:38 server-01 pmxcfs[463829]: [status] notice: node lost quorum
Feb 13 04:24:39 server-01 pve-ha-crm[491226]: status change slave => wait_for_quorum
Feb 13 04:25:12 server-01 pvescheduler[859420]: jobs: cfs-lock 'file-jobs_cfg' error: no quorum!
Feb 13 04:25:12 server-01 pvescheduler[859419]: replication: cfs-lock 'file-replication_cfg' error: no quorum!
Feb 13 04:25:21 server-01 watchdog-mux[2123]: client watchdog expired - disable watchdog updates
Feb 13 04:25:22 server-01 corosync[2282]:   [QUORUM] Sync members[2]: 4 6
Feb 13 04:25:22 server-01 corosync[2282]:   [QUORUM] Sync joined[1]: 4
Feb 13 04:25:22 server-01 corosync[2282]:   [QUORUM] This node is within the primary component and will provide service.
Feb 13 04:25:22 server-01 corosync[2282]:   [QUORUM] Members[2]: 4 6
Feb 13 04:25:22 server-01 pmxcfs[463829]: [status] notice: node has quorum
Feb 13 04:25:23 server-01 watchdog-mux[2123]: exit watchdog-mux with active connections
Feb 13 04:25:23 server-01 kernel: [37179171.019381] IPMI Watchdog: Unexpected close, not stopping watchdog!
Feb 13 04:25:23 server-01 systemd[1]: watchdog-mux.service: Succeeded.
Feb 13 04:25:23 server-01 systemd[1]: watchdog-mux.service: Consumed 21min 55.451s CPU time.
Feb 13 04:25:29 server-01 pve-ha-crm[491226]: status change wait_for_quorum => slave
Feb 13 04:25:33 server-01 pve-ha-lrm[491165]: watchdog update failed - Broken pipe

Feb 13 04:22:28 server-03 corosync[11041]:   [QUORUM] Sync members[2]: 4 6
Feb 13 04:22:28 server-03 corosync[11041]:   [QUORUM] Sync left[1]: 5
Feb 13 04:22:28 server-03 corosync[11041]:   [QUORUM] Members[2]: 4 6
Feb 13 04:22:50 server-03 corosync[11041]:   [QUORUM] Sync members[2]: 4 6
Feb 13 04:22:50 server-03 corosync[11041]:   [QUORUM] Members[2]: 4 6
Feb 13 04:24:38 server-03 corosync[11041]:   [QUORUM] Sync members[1]: 4
Feb 13 04:24:38 server-03 corosync[11041]:   [QUORUM] Sync left[1]: 6
Feb 13 04:24:38 server-03 corosync[11041]:   [QUORUM] This node is within the non-primary component and will NOT provide any services.
Feb 13 04:24:38 server-03 corosync[11041]:   [QUORUM] Members[1]: 4
Feb 13 04:24:38 server-03 pmxcfs[2602990]: [status] notice: node lost quorum
Feb 13 04:24:45 server-03 pve-ha-crm[2631689]: watchdog closed (disabled)
Feb 13 04:24:45 server-03 pve-ha-crm[2631689]: status change lost_manager_lock => wait_for_quorum
Feb 13 04:25:14 server-03 pvescheduler[2604459]: jobs: cfs-lock 'file-jobs_cfg' error: no quorum!
Feb 13 04:25:14 server-03 pvescheduler[2604458]: replication: cfs-lock 'file-replication_cfg' error: no quorum!
Feb 13 04:25:21 server-03 watchdog-mux[2225]: client watchdog expired - disable watchdog updates
Feb 13 04:25:22 server-03 corosync[11041]:   [QUORUM] Sync members[2]: 4 6
Feb 13 04:25:22 server-03 corosync[11041]:   [QUORUM] Sync joined[1]: 6
Feb 13 04:25:22 server-03 corosync[11041]:   [QUORUM] This node is within the primary component and will provide service.
Feb 13 04:25:22 server-03 corosync[11041]:   [QUORUM] Members[2]: 4 6
Feb 13 04:25:22 server-03 pmxcfs[2602990]: [status] notice: node has quorum
Feb 13 04:25:23 server-03 watchdog-mux[2225]: exit watchdog-mux with active connections
Feb 13 04:25:23 server-03 kernel: [37120846.913243] IPMI Watchdog: Unexpected close, not stopping watchdog!
Feb 13 04:25:23 server-03 systemd[1]: watchdog-mux.service: Succeeded.
Feb 13 04:25:23 server-03 systemd[1]: watchdog-mux.service: Consumed 23min 2.257s CPU time.
Feb 13 04:25:25 server-03 pve-ha-crm[2631689]: ERROR: unable to open watchdog socket - No such file or directory

für mich sieht es so aus als hätten sich server-01 und server-03 nicht mehr gefunden,
was Watchdog triggert und als sich beide wieder gefunden haben, konnte der Watchdog-Updater nicht sauber reaktiviert werden.

Hat jemand eine Idee, warum 1. sich beide Server nicht mehr gefunden haben könnten
und 2. warum der Watchdog nicht reaktiviert werden konnte?

EDIT:
das Netzwerk ist für Proxmox-Frontend/Ceph-Frontend, Ceph-Backend und die VMs jeweils als Bond (active-backup) ausgelegt,
wodurch ich Netzwerkprobleme mal ausschließen würde

 

[Falk R.]

Dazu müssten wir wissen, wie dein Netzwerk aussieht. Dann kann man eventuell helfen.

 

[intecsoft]

Alle 3 Server haben jeweils 4x10Gb und 4x 1Gb wovon jeweils 3 pro Server genutzt werden.
Jeweils 1x 10G und 1x 1G sind als Bond (active/backup) konfiguriert und dienen als:
- Proxmox-GUI und Ceph-Frontend
- Ceph-Backend
- Interface für VM-Bridge

Bei den 3 10G-Netzen ist jeweils ein unmanaged Switch installiert und bei den 1G-Fallbacknetzen
ist insgesamt 1 Switch aktiv und der die Netze per VLANs getrennt.
Die Verbindung zur restlichen IS samt Firewall geht dann von den Switchen jeweils weg,
sollte aber meiner Meinung nach ab hier keine Rolle mehr spielen.
Die MTU beträgt 9198 weil das das Maximum einer der involvierten NICs ist.

 

[Falk R.]

Ist das Setup mit dem Failover von 10 auf 1 GBit gut getestet? hat noch jeder Verbindung wenn mal nur 1 Port schwenkt?
Ist die MTU auf dem Switch so eingestellt?
Nutzt ihr Jumbo Frames auch für Corosync? Welche Netzwerke werden für Corosync genutzt und welches Netz ist primär?

 

[intecsoft]

Corosync läuft über das "Primärnetz" mit, welches ich oben als "Proxmox-GUI und Ceph-Frontend" bezeichnet habe.
Demnach greifen die Jumboframes auch für Corosync. Stellt das ein Problem dar?

Die Failover-Tests führe ich noch mal aus. Ggf. dauert das etwas, da das im laufenden Betrieb tagsüber etwas
schwierig ist, falls doch etwas ausfällt.

 

[Falk R.]

Wenn du da so komische Jumbo Frames aktiv hast, weiß ich nicht ob es Probleme gibt. Normalerweise ist max. Jumbo Size von 9000 erlaubt.
Die Switches müssen ja dann dementsprechend größere Pakete transportieren können wegen dem Overhead.
Hast du mehrere Netze für Corosync angegeben?

 

[intecsoft]

Du hast Recht, dass die MTU max. 9000 sein sollte (https://en.wikipedia.org/wiki/Jumbo_frame).
Das war mir bisher nicht bekannt.
Ich stelle das entsprechend um und teste noch mal die Fallbacklösung.

Was mich stutzig macht, ist, dass Netzwerkprobleme als Ursache nur Sinn ergeben, wenn der eine Server und zeitgleich z.B. der Switch
des Primärnetzes Probleme hatten.

Die Corosync-Konfig ist nach der Standardinstallation nicht verändert worden
und nutzt nur bond0 vom Primärnetz.

 

[Falk R.]

Anscheinend funktioniert die Verbindung zwischen Primärswitch und dem Fallback VLAN auf dem Gigabit nicht ganz richtig.

Ich habe zuhause auch 40G / 10G für Ceph und 10G / 1G VMs. Das funktioniert schon, wenn die Switchkonfigurationen sauber sind.

 

[intecsoft]

Die MTU ist inzwischen bei 9000.
Das habe ich bei den Servern und auch bei dem Switch der Fallbacknetze umgestellt.
Der Switch der Primärnetze ist unmanaged.

Ich habe die Tests soeben durchgeführt.
Ich habe mich erst an das bond1 (Ceph-Backend) per

echo enp67s0f0 > /sys/class/net/bond1/bonding/active_slave; sleep 5; echo eno1np0 > /sys/class/net/bond1/bonding/active_slave

rangetestet und mit

ping -W 1 HOST

von den beiden übrigen Servern getestet.
Das selbe dann in einer Screensession für bond0 (Screen weil ich den Server über bond0 erreichen muss).
Das lief alles reibungslos durch.

Dann habe ich jeweils bond0 und bond1 auf das Fallback-Interface gelegt und die Verbindungen zwischen den Servern per iperf durchgemessen.
Alles lief ohne Probleme.

 

[Falk R.]

Auf dem Switch MUSS die MTU größer 9000 sein, Mindestens 9128 und wenn der Switch das Unterstützt mache ich immer direkt 10000.

Mach mal Ping mit 9k Paketen

 

[intecsoft]

Warum sollte die MTU am Switch größer sein müssen als die der Server?
Standard ist ja 1500 (so also auch am Switch und bei Debian) - also auch gleich.

Ping läuft überall sauber durch, wenn alle bond01 auf 10G sind, je ein Host auf 1G ist oder alle auf 1G sind; Beispiel:
root@is-master-25:~# ping -W 1 -M do -s 8972 is-master-24

root@server01:~# ping -W 1 -M do -s 8972 server02
PING server02 (FOO) 8972(9000) bytes of data.
8980 bytes from server02 (FOO): icmp_seq=1 ttl=64 time=0.401 ms
8980 bytes from server02 (FOO): icmp_seq=2 ttl=64 time=0.413 ms
8980 bytes from server02 (FOO): icmp_seq=3 ttl=64 time=0.423 ms
8980 bytes from server02 (FOO): icmp_seq=4 ttl=64 time=0.433 ms
8980 bytes from server02 (FOO): icmp_seq=5 ttl=64 time=0.409 ms
8980 bytes from server02 (FOO): icmp_seq=6 ttl=64 time=0.416 ms
8980 bytes from server02 (FOO): icmp_seq=7 ttl=64 time=0.403 ms

 

[Falk R.]

Du schickst ja nur 8972er Pakete und keine 9000er. Bei meinen Switches ist Default Jumbo MTU = 9216.
Wie du ja selbst merkst hast du einen Overhead.