[SOLVED] Proxmox VE nachträglich clustern

[kamikaze2508]

Hallo zusammen,

ich hätte mal eine Frage. Ich betreibe eine Proxmox-VE-Instanz mit diversen VMs und Containern auf einem MSI Cubi 5-Barebone. Nun habe ich mir einen weiteren Cubi 5 zugelegt und möchte nun meine bestehende Proxmox-Instanz mit den vorhandenen VMs und Containern clustern. Ist es möglich den bestehenden Host in eine Cluster-Konfiguration (inkl. Q-Device) zu überführen, ohne die VMs und LXCs vorher wegzusichern? Ich habe schon das Internet dazu durchsucht, allerdings konnte ich zu meiner Frage nichts finden. Der bestehende Barebone besitzt zwei SSDs. Davon wird die erste SSD als System-Platte verwendet mit Partitionen für "BIOS boot", EFI und LVM (thin). Die zweite SSD hat zwei Partitionen, ZFS und "ZFS reserved" und ist als Speicher für die VMS und Container zuständig. Siehe Screenshot. Proxmox VE läuft derzeit unter Version 8.2.4. Der zweite Barebone erhält die identische Hardware-Konfiguration.

Über eine Antwort würde ich mich freuen.

Vielen Dank und Gruß

Christian

 

[waltar]

Ja, das ist normal so. Neue Nodes dürfen aber noch NICHTS eingerichtet haben (also frisch installiert) und sollten dem gleichen pve Release entsprechen (insofern ggf. erst ein Update auf deinem 1. (alten, prod mit vm/lxc) pve machen, dann neue Nodes installieren und updaten, joinen.

 

[kamikaze2508]

Hallo waltar,
vielen Dank für deine Antwort.
Wenn ich dich richtig verstanden habe, würde ich meinen bestehenden Node auf 8.3 heben und anschließend auf diesem das Cluster erzeugen. Das sollte keinen Einfluss auf die dort laufenden VMs und LXC haben, richtig? Anschließend dann den zweiten Node installieren und joinen.

Mir stellt sich nun noch die Frage, wie gehe ich mit dem lokalen Storage für die VMs und LXC um. Ich habe mir folgendes Video bei YouTube angesehen: https://www.youtube.com/watch?v=im4URPtI_tE. Dort wird auch ein 2 Knoten-Cluster erstellt. Bei Minute 9:07 wird nach dem erstellen des Clusters erst auf beiden Nodes die Datenplatte hinzugefügt. In meinem Fall habe ich die ja aber schon vor dem Erstellen des Clusters. Wie muss ich dann in meinem Fall vorgehen, damit ich keinen Datenverlust erleide?

 

[waltar]

Ein Clusterjoin hat nichts mit Storagenutzung zu tun, deine Nodes können völlig unterschiedlich sein. Du mußt dir halt nur Gedanken darüber machen, wie du vm/lxc migrieren möchtest, entweder brauchst du ein shared storage oder eben Platz für lokale Kopien ala lvm/zfs.

 

[kamikaze2508]

Ok, das heißt, ich muss dann lediglich, wie im Video gezeigt, auf dem zweiten Node die Datenplatte, bzw -partition erstellen, ohne den Haken bei "Add Storage" zu setzen und anschließend im Bereich Cluster bei Storage die Partition auswählen und beide Nodes auswählen.

 

[waltar]

Beide Nodes auswählen ist keine gute Idee bei einem lokalen zfs, denn wie könnte eine vm auf anderem Node damit weiterlaufen, wenn du den Node ausmachst ?!

 

[UdoB]

Beide Nodes auswählen ist keine gute Idee bei einem lokalen zfs, denn wie könnte eine vm auf anderem Node damit weiterlaufen, wenn du den Node ausmachst ?!

In meinem Homelab ist "local-zfs" ausdrücklich auf allen Nodes verfügbar - im obigen Screenshot steht bei mir "All (No restrictions)". Das ist die Voraussetzung dafür, dass die (ZFS-) Replikation ohne Tricks funktioniert und PVE damit dann sogar High-Availability anbietet. Der eigentlich nur lokale existierende ZFS-Storage mit dem Namen "local-zfs" wird mit Hilfe der Replikation formal zu einem "Shared Storage".

Wenn bei mir ein Node ausfällt oder (ohne jegliche weitere Vorbereitung, aber mit Replikation und "HA-enabled") herunterfährt, starten nach 1-2 Minuten bestimmte VMs auf dem Nachbarknoten, exakt genau so wie das auch bei echtem "Shared Storage" der Fall ist.

Oder rede ich am Thema vorbei???

 

[waltar]

Wir haben keine zfs Replikation, kann ich insofern nicht nachvollziehen, aber anscheinend ist local-zfs shared to all wohl doch richtig (auch wenn ich der Logik nicht folgen kann, denn eine Replikation liegt ja auf anderem Host und wird ja auch nicht auf 1. benutzt, schon unlogisch - was hat sharing mit Abgleich zu tun, wenn es geshared wäre bräuchte man ja keinen Abgleich, insofern theo. eher umgekehrt, aber egal, muß man nur wissen, wie sich das die pve Entwickler gedacht haben und wünschen...).

 

[kamikaze2508]

In meinem Homelab ist "local-zfs" ausdrücklich auf allen Nodes verfügbar - im obigen Screenshot steht bei mir "All (No restrictions)". Das ist die Voraussetzung dafür, dass die (ZFS-) Replikation ohne Tricks funktioniert und PVE damit dann sogar High-Availability anbietet. Der eigentlich nur lokale existierende ZFS-Storage mit dem Namen "local-zfs" wird mit Hilfe der Replikation formal zu einem "Shared Storage".

Wenn bei mir ein Node ausfällt oder (ohne jegliche weitere Vorbereitung, aber mit Replikation und "HA-enabled") herunterfährt, starten nach 1-2 Minuten bestimmte VMs auf dem Nachbarknoten, exakt genau so wie das auch bei echtem "Shared Storage" der Fall ist.

Oder rede ich am Thema vorbei???

Nein, genau darum geht es. Ich habe das so aus dem Video verstanden. Nachdem man bei dem local-zfs-Storage beide Nodes ausgewählt hat, wird es auch auf dem zweiten Node, bei dem man zuvor den Haken bei "Add Storage" entfernt hat, auch angezeigt. Und über die anschließend einzurichtende Replikation werden die VMs und Container in einem eingestellten Intervall zwischen den Nodes synchronisiert.

In dem Video wird halt nur erwähnt, dass man die lokalen Storages, die man nachher im Cluster "gemeinsam" verwenden will, erst anlegen soll, nachdem man das Cluster aufgebaut hat. Da ich ja aber ein bestehendes System zu einem Cluster erweitern will, ist mein lokales Storage (auf einer Extra-SSD) bereits auf dem ersten Node vorhanden. Jetzt stellt sich mir die Frage, ob, wenn das Storage für den Cluster-Betrieb ausgewählt wird, die Daten weiterhin beibehalten werden, oder ob das lokale Storage des ersten Node einmal neu initialisiert wird und somit die dort abgespeicherten VMs und Container verloren gehen.

 

[UdoB]

Ich habe das so aus dem Video verstanden.

Das habe ich mir allerdings nicht angesehen

...die Daten weiterhin beibehalten werden, oder ob das lokale Storage des ersten Node einmal neu initialisiert wird und somit die dort abgespeicherten VMs und Container verloren gehen.

Nein, da wird nichts gelöscht/initialisiert/formatiert.

Der erste Node darf ja bereits "irgendwelche" VMs enthalten. Nur der neu hinzukommende Node soll/muss leer sein.

Die "Philosophie" von PVE ist möglicherweise etwas gewöhnungsbedürftig: beim "Datacenter --> Storage --> Add --> ZFS" wird kein ZFS-Pool (und auch kein -Dataset) angelegt, was mit Verlust bereits vorhandener Daten einher gehen könnte. Es wird lediglich dem PVE - also der Software, die PVE ausmacht - mitgeteilt, dass ein solcher ZFS-Storage existiert und genutzt werden darf/soll.

(( Genau wie Storage --> Add --> NFS keinen Fileserver erzeugt. ))

Falls dieser Storage auf dem neuen Node aber gar noch nicht existiert, muss er natürlich angelegt werden, bevor er genutzt werden kann. Das ist ein anderer Schritt unter <neuerNode> --> Disks --> ZFS. Ob das vor oder nach dem Cluster-Join geschieht, ist vollkommen egal.

Falls in dem ZFS Pool auf dem neu hinzugefügtem Node bereits Daten liegen würden, verblieben die auch weiterhin dort. Falls diese zu (nicht erlaubten!) "alten" VMs auf diesen Node gehören würden, wären sie allerdings anschliessend "unsichtbar", weil der Zustand des Clusters vom ersten, also dem alten, Knoten übernommen wird. Es ist kein "merge" vorgesehen, der neue Node ist ja per Definition leer.

Die Storages sollen (bzw. müssen!) auf allen Nodes denselben Namen haben, nur dann klappt die Replikation.

Am besten einfach ausprobieren

 

[kamikaze2508]

Hallo Udo,
vielen Dank für die Aufklärung. Dann kann ich das ja entspannt so umsetzen, wie ich mir das vorgestellt habe.