Verständnisfrage zu Corosync und Fencing

[Indurad_IT]

Guten Morgen,

wir haben letzten November unser 3-Node-Cluster auf Proxmox 7.1-7 geupdatet, danach hatten wir das gleiche Problem mit den neustartenden Servern wie hier:
https://forum.proxmox.com/threads/unexpected-restart-of-all-cluster-nodes.97021/

Deswegen haben wir einen separates 1GBit Corosync Netzwerk eingerichtet wie es empfohlen wurde.
Leider haben wir seit ein paar Tagen das Problem, dass sich nach längerer Uptime irgendwann unsere 10GBit Netzwerkkarten aufhängen, das heißt der Server ist nicht mehr über die IP-Adressen für Cluster und Ceph erreichbar (Intel X710, neueste Firmware, Probleme mit dem i40e-Treiber).

Dabei ist aufgefallen, das dass Fencing nicht so funktioniert wie wir uns das wünschen:
Mit den akuellen Einstellungen wird ein Server nicht gefenced, wenn er über Cluster- und Ceph-Netzwerk nicht erreichbar ist, über das Corosync-Netzwerk aber schon.
Wenn wir Corosync über die gleiche Netzwerkkarte wie das Cluster-Netzwerk laufen lassen würden, hätten wir dieses Problem nicht und der Server würde gefenced sobald die 10GBit-Karte ausfällt.

Wenn ich richtig verstanden habe wie Corosync funktioniert, würde es nichts bringen die IP-Adressen für Cluster und Ceph als zusätzliche Links einzutragen, da über Corosync nur geprüft wird ob ein Server überhaupt noch erreichbar ist.
D.h. wenn die beiden IP-Adressen von den 10GBit-Karten nicht mehr erreichbar sind, der Server aber über die IP der 1GBit-Karte weiterhin antwortet, würde er nicht gefenced werden. Oder hab ich das falsch verstanden?

Gibt es Möglichkeiten solche Probleme abzufangen?


Im Anhang die Netzwerkkarten mit IP-Adressen und welches Netzwerk dran hängt.
Sowie die aktuellen Corosync.conf

1GB = eno1 > 192.168.2.1/24 (corosync)
10GB = enp19s0f0 >  10.133.4.60/24 (Clusternetwork)
10GB = enp19s0f1 >  10.134.10.18/24 (Ceph)

logging {
  debug: off
  to_syslog: yes
}

nodelist {
  node {
    name: Node1
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 192.168.2.1
  }
  node {
    name: Node2
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 192.168.2.2
  }
  node {
    name: Node3
    nodeid: 3
    quorum_votes: 1
    ring0_addr: 192.168.2.3
  }
}


quorum {
  provider: corosync_votequorum
}

totem {
  cluster_name: PVE-SBL
  config_version: 5
  interface {
    linknumber: 0
  }
  ip_version: ipv4-6
  secauth: on
  version: 2
}

 

[mira]

Corosync ist für die Erreichbarkeit und den Datenaustausch zwischen den Clusternodes verantwortlich.
Das heißt, solange hier noch eine Verbindung herrscht, werden die Nodes weiterhin als `Online` gesehen.

Findet sich denn etwas im Journal/den Syslogs zu dem Problem mit den NICs?
Ist das BIOS aktuell? Habt ihr schon Kernel 5.15 probiert?

Manche Hersteller unterstützen auch Watchdogs für Hardware, z.b. wenn eine NIC nicht mehr funktioniert. Dies ist jedoch nichts das PVE unterstützt.

 

[Indurad_IT]

@mira vielen dank für deine Antwort

Im Journal/Syslog ist keine eindeutige Fehlermeldung zu finden, was die Probleme erklären würde.
Ist ein sehr merkwürdiges verhalten, was es schwer macht die Probleme weiter einzugrenzen.
Die Netzwerkkarte ist up, hat eine IP-Adresse und Link (bestätigt sogar das Switch) aber ist nicht erreichbar, nach einem Reboot funktioniert wieder alles ganz normal.

Wir haben gestern den Kernel 5.15 installiert, bis jetzt hatten wir keine Probleme aber wir werden es weiter beobachten.

Ich schaue mir das Thema Watchdogs an.