Seltsames HA Verhalten

K

kutscher_tom

New Member
Dec 17, 2025
3
0
1
Hallo,

ich bin gerade dabei Proxmox zu testen. Habe ein Cluster aus 4 Servern aufgebaut. Das ganze erst mal ohne shared Storage sondern mit Replikation. Soweit läuft alles prima. Bei diversen Tests habe ich jetzt folgendes Problem festgestellt:
Server 1 habe ich herunter gefahren, um einen Ausfall zu simulieren
Server 2 - 4 laufen weiter und alle VMs sind darauf verteilt
Auf Server 3 wird jetzt ein rebtot initiiert.
Jetzt versucht server 3 die laufenden VMs auf Server 1 zu migrieren, was aber nicht geht, weil der ja aus ist. Müsste er nicht automatisch auf Server 2 und 4 migrieren? Hab ich etwas falsch eingestellt oder ist das ein Bug?
 
Wie sehen deine Netzwerk- und Storagehardware (Festplatten,SSDs) aus? Für einen Cluster werden sehr niedrige Netzwerklatenzen, im Idealfall durch eigene Netzwerke für die Clusterkommunikation und den Storage-Traffic (Migration/Replication) benötigt:
https://pve.proxmox.com/wiki/Cluster_Manager#pvecm_cluster_network

Heißt: Wenn bei dir sowohl die Replikation als auch der corosync-Traffic des Clusters als auch der reguläre Netzwerktraffic des Hosts und der VMs/Container über die gleiche Leitung läuft, dann wundert es mich nicht, dass das Probleme macht. Das mit den reboot klingt nach genau so einen Szenario ;)
 
Hm, es ist aktuell ein Testaufbau. Alles ist über 1 Gibt/s verkabelt und die Festplatten sind alles NVME. Traffic gibt es außer paar pings keinen, da keine Produktiven Systeme auf den VMs laufen.
wenn alle 4 Server online sind, funktioniert auch alles wie erwartet.
 
Das heißt nur eine Netzwerkverbindung? 1Gbit/s ist grundsätzlich ok (man darf natürlich keine Wunder bei der übertragungsgeschwindigkeit erwarten), alles über einen Netzwerklink zu schicken nicht (aus den von mir verlinkten Teil der Doku):

Cluster Network​

The cluster network is the core of a cluster. All messages sent over it have to be delivered reliably to all nodes in their respective order. In Proxmox VE this part is done by corosync, an implementation of a high performance, low overhead, high availability development toolkit. It serves our decentralized configuration file system (pmxcfs).

Network Requirements​

The Proxmox VE cluster stack requires a reliable network with latencies under 5 milliseconds (LAN performance) between all nodes to operate stably. While on setups with a small node count a network with higher latencies may work, this is not guaranteed and gets rather unlikely with more than three nodes and latencies above around 10 ms.
The network should not be used heavily by other members, as while corosync does not uses much bandwidth it is sensitive to latency jitters; ideally corosync runs on its own physically separated network. Especially do not use a shared network for corosync and storage (except as a potential low-priority fallback in a redundant configuration).
Before setting up a cluster, it is good practice to check if the network is fit for that purpose. To ensure that the nodes can connect to each other on the cluster network, you can test the connectivity between them with the ping tool.
If the Proxmox VE firewall is enabled, ACCEPT rules for corosync will automatically be generated - no manual action is required.

https://pve.proxmox.com/wiki/Cluster_Manager#pvecm_cluster_network
Click to expand...

Man beachte "not used heavily by other members", "ideally corosync run on it's own physically seperated network"/"do not use a shared network for corosync and storage (except as a potential low-priority fallback in a redundant configuration)."."hile on setups with a small node count a network with higher latencies may work, this is not guaranteed and gets rather unlikely with more than three nodes and latencies above around 10 ms."

Ich sehe da gleich mehrere Punkte, die (je nachdem wie dein Netzwerk aufgebaut ist), die Probleme machen könnten.
 
ich finde es interessant, dass das mit dem 4 node cluster überhaupt funktioniert.
eigentlich müssten die 2 überlebenden nodes doch fencen und rebooten, da 50% der quorum-votes weg sind und die 2 überlebenden nodes somit kein quorum mehr hinbekommen (dafür bräuchten sie mindesten 51%).

daher nimmt man eigentlich immer ungerade node-zahlen, so dass ein 50/50 split nicht passieren kann.

dass das trotzdem weiterläuft ist überraschend für mich.
 
  • Like
Reactions: Johannes S
@Johannes S das mit der Spezifikation ist ja schön und gut. Aber ich habe wie gesagt einen Testaufbau, da ist kein großer Traffic und die VMs ändern sich auch nicht. Die Replikation ist jeweils in unter 1 Sekunde abgeschlossen. Außerdem funktioniert ja allesreibungslos , wenn 4 Server in Betrieb sind.
Mein konkretes Problem ist ja folgendes: Server 1 ist aus, Server 3 soll rebtoten und versucht eine Migration auf Server 1 der aber gar nicht verfügbar ist. Im HA Manager werden alle zustände (Server 1 offline, Server 3 Maintenance) richtig erkannt.

@beisser so weit bin ich ja nicht gekommen. Der Reboot von Server 3 ist ja daran gescheitert, dass er es nicht geschafft hat, die VMs zu migrieren. Wenn alle 4 Codes online sind, funktioniert alles problemlos. Ich kann VMs von Hand migrieren, sie migrieren automatisch wenn ich nen rebtot mache usw.... Nur für den Fall, dass ein Node nicht verfügbar ist gibt es das Problem. Und das verstehe ich eben nicht. Ich hätte erwartet, dass HA auch weiterhin die VMs auf den verbleibenden Nodes migrieren kann, auch wenn einer mal längere Zeit ausfällt. Sowas kann ja durch einen Hardwaredefekt durchaus mal vor kommen.
 
meine antwort war auch weniger auf dein aktuelles problem mit der migration bezogen (zu dem ich leider auch keine antwort kenne), sondern viel mehr auf den umstand, dass du eine gerade anzahl an nodes hast.
selbst wenn die migration bei dir funktioniert, würde ich erwarten, dass die zwei überlebenden nodes dann neu starten, weil sie nicht mehr mindestens 51% der quorum-votes haben.
um sowas zu vermeiden ist es ratsam entweder eine ungerade anzahl an nodes zu verwenden, oder ein 5. gerät (raspi oder ähnliches) zu nehme und dort ein qdevice zu installieren. das gibt dann einen extra vote und die überlebenden nodes + qdevice haben dann immer mindestens 60% der votes.
ist nur ein freundlicher hinweis.
 
  • Like
Reactions: Johannes S
kutscher_tom said:
Aber ich habe wie gesagt einen Testaufbau, da ist kein großer Traffic und die VMs ändern sich auch nicht. Die Replikation ist jeweils in unter 1 Sekunde abgeschlossen. Außerdem funktioniert ja allesreibungslos , wenn 4 Server in Betrieb sind.
Mein konkretes Problem ist ja folgendes: Server 1 ist aus, Server 3 soll rebtoten und versucht eine Migration auf Server 1 der aber gar nicht verfügbar ist. Im HA Manager werden alle zustände (Server 1 offline, Server 3 Maintenance) richtig erkannt.
Click to expand...

Naja ich finde es ja sinnlos einen Testaufbau zu haben, der in entscheidenden Punkten nicht der Produktion entspricht, da man damit keine aussagekräftigen Ergebnisse kriegt. Neben dem Hinweis zum qdevice von beisser: Hast du denn in den servern nur eine Netzwerkkarte? Falls ja, dann USB-Ethernet-Adapter für kleines Geld kaufen und damit dann das corosync-Netzwerk bauen. Falls nein: Bitte mal versuchen (kann auch mit einen billig-switch oder als meshed-netzwerk passieren) ob der Fehler mit einen dezidierten Netzwerk noch auftritt.
 
Klingt doch alles Plausibel. Vermutlich hast du die Replikation zwischen Host 1 und 3 aktiv, dann will er die VMs auf den Host verschieben wo die andere Kopie der Disk liegt.
Wenn du den Host3 rebooten würdest, wäre der ganze Cluster down, daher immer nur einen Host offline nehmen bei einem 4 Node Setup.
Bei 5 Nodes kannst du 2 offline nehmen, aber auch da muss du mit der Verfügbarkeit der Daten schauen, bei Replikation. Replikation nutze ich daher nur bei 2 Node Setups.
 
  • Like
Reactions: Johannes S
beisser said:
aber auch bei 2-node setups das qdevice nicht vergessen, oder der überlebende node kackt auch ab, während du den anderen rebootest ;)
Click to expand...
Das ist für mich so selbstverständlich, dass ich vergessen habe es zu erwähnen. Danke dafür. ;)
 
  • Like
Reactions: Johannes S
beisser said:
das war mehr an diejenigen gerichtet, die das lesen und das umsetzen wollen, weniger an dich :)
Click to expand...
So war das auch gemeint, schön dass du das ergänzt hast, für die Leute.
 
You must log in or register to reply here.
Top Bottom