PVE Host reboot, weil ?

[frantek]

Ich habe hier einen Cluster aus 3 Nodes mit Ceph. Gestern hat der eine Node wegen irgend welcher Cluster- und/oder Ceph-Probleme gebootet. Ich bin aber nicht in der Lage das Log zu interpretieren um die Ursache zu ermitteln. Was war die Ursache? Der Länge wegen ist das Log im Anhang. Nach dem was in der Datei steht wurde direkt der Reboot ausgelöst.

pve-manager/8.3.4/65224a0f9cd294a3 (running kernel: 6.8.12-8-pve)

 

[itNGO]

So auf den ersten Blick würde ich sagen dein Corosync hat die Verbindung verloren und der node wurde "gefenced"...

 

[itNGO]

Hier noch die ausführliche Antwort ausm LLM, ich bin der selben Meinung:


Aus dem Logverlauf sieht man ganz klar, dass sich der Node “pve02” vom Cluster trennt (Corosync verliert die Links zu den anderen Knoten, die Token-Timeouts treten auf, und der Node verliert das Quorum). Anschließend versucht Proxmox/pmxcfs ständig, Daten (cpg_send_message) an die anderen Cluster-Knoten zu senden, bekommt aber keine Bestätigung mehr und meldet schließlich „retried 100 times … failed**“. Das ist ein typischer Ablauf, wenn das Cluster-Netz (Corosync) aus Sicht dieses Knotens „wegbricht“ und er somit seine Anbindung verliert.

Da der Node ein Teil des HA-Clusters ist, greift das Self-Fencing (HA-Funktion): der Node, der sich vom restlichen Quorum isoliert fühlt, versucht nicht mehr, alleine weiterzulaufen, sondern rebootet sich hart, um Split-Brain-Szenarien oder gleichzeitige Nutzung derselben Ressourcen zu verhindern.

 

[frantek]

Hmmm ... danke. Auf das mit dem LLM komm ich immer von alleine nicht ... ich bin alt Wen hast du da was genau gefragt?

Ok, aber wie finde ich heraus, warum er die Verbindung verloren hat? Zum Aufbau: Es sind drei Minisforum MS 01 und das Cluster-Netz ist ein Ring über Thunderbolt. An das LAN sind die Hosts per 10GE DAC-Kabel angebunden. Mich würde die Ursache interessieren.

 

[itNGO]

Du hast also nur "einen" Ring für den Cluster?.... wenn da also was "hickst" dann kann er nicht auf einen 2ten wechseln..... Das würde ich dringend empfehlen.

 

[frantek]

Ich könnte auch noch einen zweiten und auch einen dritten und vierten Ring bauen, nur weiss ich immer noch nicht was hier die Quelle des Problems war und kann somit die Ursache nicht bekämpfen ...

 

[itNGO]

Entschuldige, ich dachte das ist selbsterklärend. Netzwerk im einzigen Corosync-Ring unterbrochen zum Node. Daher hat der Node sich selbst "gefenced" und rebootet.

Warum deine Netzwerkkarte ggf. die Verbindung verloren hat, geht aus dem Log-Auszug nicht hervor. Da müsste man mehr Daten/Logs haben.... Das kann auch einfach eine hohe Auslastung auf dem Netzwerkinterface gewesen sein. Corosync reagiert sehr empfindlich auf Latenzen....

 

[mr44er]

nur weiss ich immer noch nicht was hier die Quelle des Problems war und kann somit die Ursache nicht bekämpfen

Wie schon gesagt wurde, griff hier das fencing.
Aber warum das getriggert wurde, ist Spekulation da ich mich mit Thunderbolt gar nicht auskenne.
Möglich wäre, dass das device zu lange in einem tieferen Energiesparmodus verweilte und dann nicht rechtzeitig wieder hochkam. Wenn die 3 Nodes generell unterschiedliche Hardware haben/sind, passiert das möglicherweise dort nicht.

Auch ich empfehle mindestens einen zweiten Ring, einerseits damit sowas eher nicht mehr passiert, andererseits zur weiteren Diagnosebeobachtung.

 

[frantek]

Das sind drei identische PCs, die auch in keiner weise dazu kommen sollten irgend etwas in den Energiesparmodus zu versetzen. Über den 25GE Thunderbolt-Ring läuft auch den Ceph-Traffic. Jeder Host hat 2 SSDs als OSDs, also gibt es insgesamt 6 OSDs.

Wie auch immer, ich habe noch je einen freien 10GE und zwei freie 2,5GE Ports. Damit kann ich noch einen zweiten Ring bauen, auch wenn der nur einen Bruchteil der Bandbreite hat.

 

[Falk R.]

Es gibt verschiedene Möglichkeiten einen Ring zu bauen. Wenn du z.B. mit Spanning Tree arbeitest, kann dir das Protokoll auch auf dem zweiten Ring, die gleichen Probleme Produzieren. Wenn du einen kleinen 1G Switch hast, würde ich lieber diesen benutzen.