Cluster wieder zerbrochen

[bforpc]

Moin,

Ich habe ein Cluster aus 5 Nodes an 3 Standorten. Alle Nodes basieren auf Debian Bookworm mit
pve-manager/8.1.3/b46aac3b42da5d15 (running kernel: 6.5.11-6-pve).
Ich musste heute an allen 3 Standorten die FireWall updaten. Danach war das Cluster defekt. Gleiches passierte schon mal im Sommer diesen Jahres.
3 Nodes an einem Standort sind noch ein Cluster, die beiden externen sind raus.
Neustart auf allen Nodes der PVE & Corosync Dienste brachte keine Verbesserung.
Logs sind leider absolut nichtssagend (also keine Info, die auf den Fehler hinweisen könnte). Auf den beiden externen Nodes gibt es diverse Fehler, welche auf das nicht existierende quorom verweisen. Sonst nichts.

Im Sommer hatte ich es nach langem erfolglosen Suche so gelöst, dass ich das Cluster aufgelöst und neu gebaut habe. Aber das kann doch nicht die einzige Möglichkeit sein.

Bitte um Hilfe, da ich dringend Replikation vor dem Fest durchführen muss.

Bfo

 

[sb-jw]

Ich musste heute an allen 3 Standorten die FireWall updaten. Danach war das Cluster defekt. Gleiches passierte schon mal im Sommer diesen Jahres.
3 Nodes an einem Standort sind noch ein Cluster, die beiden externen sind raus.

Die Updates hast du aber nicht alle parallel gemacht, oder?

Ansonsten ist Corosync über mehrere Standorte auch potenziell eher nicht möglich. Die Latenz ist vermutlich zu hoch. Es wird auch nicht empfohlen einen Cluster über mehrere Standorte aufzubauen. Selbst in einem Rechenzentrum wo du eine direkte Darkfibre hast würde ich sowas vermeiden wollen.

 

[fabian]

ohne config und logs wirds eher schwierig sein dir zu helfen. grundsaetzlich braucht corosync einen stabilen, low-latency link, bin mir nicht sicher ob das bei dir gegeben ist.

bitte also von allen nodes posten:
- pveversion -v
- /etc/pve/corosync.conf
- pvecm status

dann, auf allen nodes:
- systemctl stop pve-ha-lrm pve-ha-crm
- systemctl stop pve-cluster corosync

jetzt auf die uhr schauen, und falls probleme auftauchen, von allen nodes die logs ab diesem zeitpunkt ("journalctl --since XXX") posten!

dann, auf den nodes nacheinander und immer warten bis es stabil ist
- systemctl start corosync
- "corosync-quorumtool -s" -> alle nodes auf denen bisher corosync gestartet worden ist muessen mit einem vote aufscheinen, und wenn du das kommando auf allen nodes auf denen du bis jetzt corosync gestartet hast gleichzeitig ausfuehrst sollten alle dieselbe "ring ID" aufweisen => erst wenn beides der fall ist mit dem naechsten node weitermachen

wenn corosync mit allen 5 nodes stabil laeuft, node fuer node "systemctl start pve-cluster" ausfuehren (und immer dazwischen abwarten/logs anschauen/corosync-quorumtool output analysieren)

abschliessen auf allen nodes die HA services wieder starten ("systemctl start pve-ha-lrm pve-ha-crm")

meine vermutung ist allerdings, dass du mit einem cluster pro standort besser dran waerst (replikation ueber standorte ginge dann z.b. mit pve-zsync)

 

[bforpc]

Hallo,

also das Cluster lief ja einwandfrei bisher (seit 2,5 Jahren). Selbst bei einem Node, der nicht 24/7 online ist. Der kam immer wieder "zurück" ins Cluster, sobald er online war.
Die FW Updates wurden alle heute Morgen (nacheinander) gemacht. Die Latenz ist gering (Ping ~10ms) zwischen den externen beiden Nodes und den 3 Nodes im Hause. Ich bin mir fast sicher, dass es nicht mit der Latenz zusammen hängt.

Es muss doch eine Möglichkeit geben, das wieder zusammen zu setzen.
Darüber hinaus eine bessere Log Ausgabe wäre auch wünschenswert.

Bfo

 

[fabian]

es gibt zwei sachen die bei corosync besonders aufwaendig sind:
- cluster cold starts (wahrscheinlich dein fall)
- regelmaessig "flappende" links (also link up, down, up, down, up, down - mit jeweils genug "up" um einen re-sync anzustossen aber nicht fertig zu bringen)

was genau bei dir das problem ist kann ich dir nicht sagen wenn du keine config und logs postest

 

[Falk R.]

Hallo,

also das Cluster lief ja einwandfrei bisher (seit 2,5 Jahren). Selbst bei einem Node, der nicht 24/7 online ist. Der kam immer wieder "zurück" ins Cluster, sobald er online war.
Die FW Updates wurden alle heute Morgen (nacheinander) gemacht. Die Latenz ist gering (Ping ~10ms) zwischen den externen beiden Nodes und den 3 Nodes im Hause. Ich bin mir fast sicher, dass es nicht mit der Latenz zusammen hängt.

Es muss doch eine Möglichkeit geben, das wieder zusammen zu setzen.
Darüber hinaus eine bessere Log Ausgabe wäre auch wünschenswert.

Bfo

Laut vielen "offiziellen" Dokumentationen soll man Corosync nie mit Latenzen über 5ms betreiben, da ab dann sich die Fehler häufen.
Um den Cluster wieder ans Rennen zu bringen, solltest du die Anleitung von Fabian Schritt für Schritt abarbeiten.

Generell, Corosync Verbindungen niemals über Firewalls, entweder ich habe eine stabile Layer2 Verbindung oder es gibt keinen Cluster.
Ich habe bei einem Kunden auch eine 2,5km Glasfasterstrecke zwischen den RZ, aber da haben wir Redundante 40G Verbindungen und die Latenz immer um 1ms.

Hast du wie empfohlen einen zweiten Ring für Corosync definiert? Wenn ja, wie sieht die Verbindung aus?

 

[bforpc]

ohne config und logs wirds eher schwierig sein dir zu helfen. grundsaetzlich braucht corosync einen stabilen, low-latency link, bin mir nicht sicher ob das bei dir gegeben ist.

bitte also von allen nodes posten:
- pveversion -v
- /etc/pve/corosync.conf
- pvecm status

dann, auf allen nodes:
- systemctl stop pve-ha-lrm pve-ha-crm
- systemctl stop pve-cluster corosync

jetzt auf die uhr schauen, und falls probleme auftauchen, von allen nodes die logs ab diesem zeitpunkt ("journalctl --since XXX") posten!

dann, auf den nodes nacheinander und immer warten bis es stabil ist
- systemctl start corosync
- "corosync-quorumtool -s" -> alle nodes auf denen bisher corosync gestartet worden ist muessen mit einem vote aufscheinen, und wenn du das kommando auf allen nodes auf denen du bis jetzt corosync gestartet hast gleichzeitig ausfuehrst sollten alle dieselbe "ring ID" aufweisen => erst wenn beides der fall ist mit dem naechsten node weitermachen

wenn corosync mit allen 5 nodes stabil laeuft, node fuer node "systemctl start pve-cluster" ausfuehren (und immer dazwischen abwarten/logs anschauen/corosync-quorumtool output analysieren)

abschliessen auf allen nodes die HA services wieder starten ("systemctl start pve-ha-lrm pve-ha-crm")

meine vermutung ist allerdings, dass du mit einem cluster pro standort besser dran waerst (replikation ueber standorte ginge dann z.b. mit pve-zsync)

Hallo Fabian,

habe die gefragten Infos angehängt (die *.txt sind die nodes).
Sobald auf den 2 externen Nodes "systemctl start corosync" mit sofortigem "corosync-quorumtool -s" aufegrufen wurde, kam ein Ergebnis. 1-2 Sekunden später nochmal eine "corosync-quorumtool -s" kommt nur ein "Cannot initialize CMAP service".
Die Node ID der beiden externen Nodes war (kurzzeitig) eine andere als die der 3 Nodes des "Home Clusters".


Bfo

 

[fabian]

die logs fehlen immer noch ("journalctl --since XXX" wobei XX der punkt ist wo du angefangen hast corosync am ersten node wieder zu starten). die fehlermeldung klingt so als wuerde corosync gar nicht (mehr) laufen..

 

[Falk R.]

@bforpc ich will dir dein Weihnachten nicht vermiesen, aber ich persönlich würde den Cluster einmal neu machen und dann richtig aufbauen.
Wenn du nur die Verbindung über die Firewalls mit 10ms Latenz hast, solltest du da keinen Cluster über die langsame Strecke bauen.
Ich kenne deine ganzen Rahmenparameter nicht, aber oft gibt es eine elegantere Lösung als das was du jetzt hast.

 

[bforpc]

die logs fehlen immer noch ("journalctl --since XXX" wobei XX der punkt ist wo du angefangen hast corosync am ersten node wieder zu starten). die fehlermeldung klingt so als wuerde corosync gar nicht (mehr) laufen..

Anbei noch die Log von sweet

Bfo

 

[fabian]

"Dec 22 10:01:28 sweet corosync[850169]: [CMAP ] Received config version (16) is different than my config version (15)! Exiting"

wann hast du denn die corosync config zuletzt editiert? bitte sicherstellen dass sie auf allen nodes ident ist, dann nochmal probieren..

 

[bforpc]

Hallo Fabian,

die hatte ich auf den 3. Nodes heute Morgen aus lauter Frust um 1 erhöht. Dies wurde aber nicht mehr ausgerollt.
Ich habe das jetzt auf sweet gleich gesetzt ... und sweet ist wieder im Cluster.
Gleich gilt für den Node "cb"... Soweit erstmal so gut. Die Frage ist: was ist der Grund, bzw. was war der Grund, dass es die beiden Nodes wieder zum Cluster gefunden haben?

Bfo

 

[fabian]

ich komme mir zwar vor wie eine gebetsmuehle - aber ohne logs kann ich dir nicht sagen was das (urspruengliche) problem war - ausser dass laufender betrieb und neu aufsyncen nach einem totalausfall des netzwerks zwei verschiedene paar schuhe sind, und nur weil das eine halbwegs stabil laeuft, dass andere nicht zwangslaeufig auf anhieb klappen muss das letzte problem war auf jeden fall die config version, aber wenn das erst als teil der loesungsversuche passiert ist dann kanns wohl nicht die eigentliche ursache gewesen sein.

 

[bforpc]

ich komme mir zwar vor wie eine gebetsmuehle - aber ohne logs kann ich dir nicht sagen was das (urspruengliche) problem war - ausser dass laufender betrieb und neu aufsyncen nach einem totalausfall des netzwerks zwei verschiedene paar schuhe sind, und nur weil das eine halbwegs stabil laeuft, dass andere nicht zwangslaeufig auf anhieb klappen muss das letzte problem war auf jeden fall die config version, aber wenn das erst als teil der loesungsversuche passiert ist dann kanns wohl nicht die eigentliche ursache gewesen sein.

Hallo Fabian,

korrekt und nachvollziehbar was du schreibst.
Ich beobachte das jetzt weiter. Habe mir einen Link zu diesem Thread gesetzt für den Fall der Fälle.

Vielen Dank für die Hilfe bis hierhin.

Bfo

 

[Falk R.]

Hallo Fabian,

korrekt und nachvollziehbar was du schreibst.
Ich beobachte das jetzt weiter. Habe mir einen Link zu diesem Thread gesetzt für den Fall der Fälle.

Vielen Dank für die Hilfe bis hierhin.

Bfo

Vielleicht solltest du nicht bis zum nächsten Crash warten, sondern das Cluster Design eventuell mal Überdenken und Überarbeiten.
Eventuell hilft dir als Gedankenstütze der Cluster Network Teil:
https://pve.proxmox.com/wiki/Cluster_Manager#_cluster_network

Wenn du sonst Fragen zum Design hast, auch über mehrere Datacenter, dann bekommst du hier im Forum auch Hilfe und Tipps.
Ich habe einige Kunden mit mehreren Datacenter in verschiedensten Konstellationen und ich gebe meine Erfahrungen gern weiter.

 

[bforpc]

Vielen lieben Dank.
Das mache ich.
Es bestätigt mir auch, dass wir auf das richtige Pferd gesetzt haben ;-) Meine "profi" Schulung letztens bei der inett war sehr interessant. Hat sich gelohnt. Nochmals: Danke!!!

Bfo

 

[Falk R.]

Ohne dein genaues Setup zu kennen, schon mal ein Tip.
Du hast garantiert ein Netzwerk für PVE Management und die VMs, das Migrationsnetzwerk was auch für Replikation genutzt wird hoffentlich getrennt.
In der Regel hast du auf dem Management nicht so oft Vollauslastung (bevorzugt als Ring0) und das Migrationsnetzwerk ist während Replikationen oder Migrationen in der Regel zu 100% ausgelastet (als Ring1 nutzen). Somit hättest du Redundanz und die primäre Corosync Verbindung recht stabil.

Und falls du ihn sprichst, viele Grüße an Marco.

 

[bforpc]

Ohne dein genaues Setup zu kennen, schon mal ein Tip.
Du hast garantiert ein Netzwerk für PVE Management und die VMs, das Migrationsnetzwerk was auch für Replikation genutzt wird hoffentlich getrennt.
In der Regel hast du auf dem Management nicht so oft Vollauslastung (bevorzugt als Ring0) und das Migrationsnetzwerk ist während Replikationen oder Migrationen in der Regel zu 100% ausgelastet (als Ring1 nutzen). Somit hättest du Redundanz und die primäre Corosync Verbindung recht stabil.

Und falls du ihn sprichst, viele Grüße an Marco.

Das Cluster aus den 3 Nodes ist mit einem redundanten Netz ausgestattet, die beiden externen nicht. Die beiden Externen syncen nicht viel. Bis dato ist die externe Auslastung minimal.

Danke.
Bfo

ps. Marco Gabriel hatte ich auf der Schulung (so dachte ich) zum ersten mal persönlich kennen gelernt ... und dabei festgestellt, das sich vor 18 Jahren bei ihm (bei der Inett) mal eine Schulung zum Thema "rechtkonforme E-Mail Archivierung" gehalten hatte... die Welt ist ein Dorf )))

 

[Falk R.]

Wenn die externen kein redundantes Netz haben, dann hast du für Corosync auch keinen zweiten Ring definiert.
Entweder man kann das Netzwerk vernünftig redundant auslegen oder die externen Nodes bitte nicht in den Cluster aufnehmen. Also potentiell rauswerfen.
Auch alle anderen Clustertechnologien, egal ob HyperV oder vSphere mögen soetwas nicht und man findet immer eine passende Alternative die zu den Gegebenheiten passt.