Cluster mit offline Nodes

8032

New Member
Aug 23, 2023
4
2
3
Hallo,
ich habe eine relativ potente Maschine auf der eine Node in einem Cluster läuft. Diese würde ich aber gerne ausschalten, wenn ich sie nicht brauche (die meiste Zeit der Fall).
Daher meine Frage, ist es möglich einen Cluster so zu konfigurieren, dass man einzelne Nodes nur bei Bedarf einschaltet und die Container auf den verbleibenden Nodes sich normal neustarten lassen bzw verhalten?

Ich mag den Gedanken die Nodes zentral zu verwalten und LCX/VMs von einer Node auf eine andere verschieben zu können.
 
ist es möglich einen Cluster so zu konfigurieren, dass man einzelne Nodes nur bei Bedarf einschaltet und die Container auf den verbleibenden Nodes sich normal neustarten lassen bzw verhalten?
Naja, die Idee eines Clusters (mit HA) ist ja gerade, dass alles weiterhin funktioniert, wenn einige Nodes nicht verfügbar sind. Die magische Grenze liegt knapp oberhalb der Hälfte der Anzahl der Nodes.

Wenn dein Cluster 8 Nodes hat, dürfen 3 heruntergefahren werden (oder eben ausfallen).

Wenn dann ein weiterer (der Vierte) ausfällt, landest du allerdings sofort in der Problemzone.

Such hier im Forum mal nach "pvecm expected". Das ist der Gummihammer, mit dem man auf diesen 50%-Nagel einprügeln kann.


Viele Grüße
PS: willkommen im Club :-)
 
  • Like
Reactions: 8032
zur Zeit unterdrück ich das Verhalten mit "pvecm expected 1", ich habe aber gelesen™, dass dies keinen Neustart des Nodes/Clusters(?) überlebt und dementsprechend jedes Mal eine Interaktion erfordert...

Aber wenn dies die einzige Möglichkeit ist, kann man ja damit arbeiten.

Danke.
 
Korrekt.

Man kann das natürlich in eine crontab "@reboot" schreiben oder sich einen systemd.service/-Timer bauen, dann wird das eben jeweils automatisch beim/nach dem Starten ausgeführt. Empfehlenswert ist das aber eher nicht.

Ein massiver Vorteil von PVE ist ja, dass es ein offenes Debian als Grundlage hat. Basteln geht immer...
 
zur Zeit unterdrück ich das Verhalten mit "pvecm expected 1", ich habe aber gelesen™, dass dies keinen Neustart des Nodes/Clusters(?) überlebt und dementsprechend jedes Mal eine Interaktion erfordert...

Aber wenn dies die einzige Möglichkeit ist, kann man ja damit arbeiten.

Danke.
Ich möchte darauf hinweisen, dass mit pvecm expected 1 die Nodes in einer split brain Situation landen können, weil dann ja alle Nodes unabhängig voneinander das pmxcfs aktualisieren können. Falls nur 2 Nodes vorhanden sind, (oder generell eine ungerade Zahl an Nodes) empfiehlt sich ein external vote device, siehe https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_corosync_external_vote_support

Auch ist dies nicht die einzige Möglichkeit, es gibt da schon ein paar corosync Parameter [0] mit denen man basteln kann, wird aber nicht supported [1]. Also wirklich nur für nicht-produktiv Cluster!

[0] https://manpages.debian.org/unstable/corosync/votequorum.5.en.html
[1] https://forum.proxmox.com/threads/corosync-last-man-standing.70505/
 
da wir noch einige Linuxgeräte im Zoo haben, hab ich mich für das vote device entschieden... das erscheint mir "sauberer".

Ich danke euch.
 
  • Like
Reactions: UdoB and Chris
Hier im Homelab sitzen auch 4 unclustered PVE Nodes. Von Cross-Cluster Migraton habe ich leider nichts, da das genau wie eine normale Migration in einem Cluster, nicht mit ZFS Native Encryption klappt. Wenn ich da VMs migieren will, dann geht das leider halt nur über Backup+Restore vom PBS.
Alle 4 Nodes in einem webUI zu haben ist mir auch echt nicht wichtig. Da kann ich auch einfach 4 Tabs öffnen. HA brauche ich hier auch nicht. Was mich nervt ist das Synchronhalten der Aliases, IP sets und Security Groups, welche ich dann händisch immer 4-fach im webUI hinzufügen/abändern muss, damit die Gäste nach "Migration" auch noch auf dem neuen Node laufen und nicht die Firewall dicht macht, weil auf einen dort nicht existierendem Alias oder Security Group verwiesen wird.
Cluster ist hier aber auch nicht wirklich eine Option, da hier nur ein Node 24/7 läuft und die anderen 3 Nodes vom Orchestrator nur nach Bedarf angeschaltet, hochgefahren, entschlüsselt und nach getaner Arbeit auch wieder runtergefahren werden (Stromkosten... :().

Das beste was mir da einfällt wäre Node A (der 24/7 läuft) 2 Votes zu geben, einem qDevice 2 Votes und den anderen 3 Nodes (Node B, C und D) jeweils einen Vote.
Dann hätte ich 7 Votes und Quorum wenn der Node A + qDevice 24/7 laufen würden während Node B+C+D abgeschaltet wären. Sollte mir das qDevice oder Node A wegsterben, dann starte ich halt Node B+C oder C+D um wieder Quorum zu haben.
Aber so richtig gefallen will mir das auch nicht.

Wäre halt echt schön wenn man eine Art Master-Node hätte der dann die Konfigs wie Aliases, IP Sets und Security Groups etc auf die Slave-Nodes pushen könnte sobald diese verfügbar sind, ohne dass man da einen Cluster mit Quorum und Co bräuchte. Oder von mir aus auch Slave Nodes die gewünschte Konfigs vom Master-Node pullen.

Ich könnte mir da zwar was selbst zusammenbasteln mit sshfs und rsync, was dann genau das tut, aber so richtig wohl ist mir dabei dann auch nicht.
Da vergesse ich dann bestimmt ein paar Spezialfälle und ich zerschieße mir selbst die PVE Konfigs oder ein PVE Upgrade ändert da etwas und verursacht neue Probleme...

Ich hatte da schon einmal gefragt, aber sowas wie ein Cross-Cluster-Konfig-Sync ist wohl bisher leider nicht geplant. :(
 
Last edited:
es würde ja reichen wenn die pve-node eine option hätte, mit der man das gewicht der node manuell (oder automatisch?) um eins erhöhen könnte
 
es würde ja reichen wenn die pve-node eine option hätte, mit der man das gewicht der node manuell (oder automatisch?) um eins erhöhen könnte
kann man auch, ist halt nicht offiziell supported und muss in einer config eingetragen werden nano /etc/pve/corosync.conf
einfach bei deiner 24/7 node drei oder vier eintragen und die andere die ausgeschaltet wird auf 1 lassen (nicht vergessen die anzahl der gesamt stimmen unten einzutragen / passen zu verändern)

Edit: bezüglich der von Chris angesprochenen Split Brain situation wenn du mit pvecm expected 1 quorum overrulest, bei zwei nodes darfst du halt den command immer nur auf einer (deiner 24/7 primär node) ausführen und niemals auf beiden nodes gleichzeitig zusätzlich solltest du sowieso immer regelmäßig backups von deinen configs machen falls doch mal was schiefgeht (kann auch wegen was ganz anderem passieren),
mach am besten vom gesamten /etc/pve ordner 1x/Tag in der nach mit nen script ne kopie / backup bevorzugt auf nen externen storage (kann auch ein usb stick sein)
 
Last edited:
  • Like
Reactions: 8032
Ich hatte da schon einmal gefragt, aber sowas wie ein Cross-Cluster-Konfig-Sync ist wohl bisher leider nicht geplant. :(
Hab bei mir sogar ein ähnliches setup in meinem privaten cluster laufen,
Kat1: 3-4 Nodes laufen 24/7
Kat2: 2 Tagsüber
Kat3: 15+ Nur wenn sie gebraucht werden, sind aber trotzdem im cluster damit sie direkt ready to go sind falls mans braucht und ich vms hin und her migrieren kann.

Man muss die stimmen halt einfach dementsprechend vergeben, Kat1 -1 Node muss gemeinsam mehr stimmen haben als alle anderen, sagen wir mal, jede Node in Kat1 hat 100 Stimmen, Kat3 sind ja nicht so wichtig deswegen jede nur 1 Stimme. Kat2 geben wir jeder Node 10 Stimmen, so hat Kat1 immer die überhand (das -1 ist nur für den Fall, das eine der 24/7 Nodes ausfällt)

TLDR: Kat2 & 3 darf gemeinsam zu keiner Zeit mehr als 50% der stimmen haben
 
Last edited:

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!