Proxmox Node aus einem Cluster entfernen Drucken

Ein Proxmox-Cluster lässt sich relativ unkompliziert um weitere Nodes erweitern. Einen bestehenden Node wieder zu entfernen, erfordert dagegen etwas mehr Vorbereitung.

Vielleicht soll ein älterer Server durch neue Hardware ersetzt werden. Vielleicht wird ein Testcluster verkleinert oder ein defekter Host soll dauerhaft aus der Cluster-Konfiguration verschwinden.

Für das eigentliche Entfernen stellt Proxmox den Befehl pvecm delnode bereit. Bevor wir diesen ausführen, müssen wir allerdings sicherstellen, dass der betreffende Host keine Aufgaben mehr innerhalb des Clusters übernimmt.

Besonders bei Clustern mit High Availability oder Ceph kann es sonst schnell zu Problemen kommen. Ein fehlender Quorum-Voter, nicht mehr erreichbare virtuelle Maschinen oder unvollständige Ceph-Replikation sind nur einige mögliche Folgen.

In dieser Anleitung entfernen wir zunächst einen Node aus einem normalen Proxmox-Cluster. Anschließend betrachten wir die Besonderheiten bei HA, Ceph und Zwei-Node-Clustern.

1. Ausgangssituation und Voraussetzungen

Wir gehen davon aus, dass unser Proxmox-Cluster aus vier Nodes besteht.

Unser Ziel ist es, pve4 vollständig aus dem Cluster zu entfernen.

Die übrigen drei Nodes sollen anschließend wie gewohnt weiterarbeiten.

Bevor wir beginnen, sollten folgende Voraussetzungen erfüllt sein:

• Der Cluster funktioniert ordnungsgemäß und besitzt Quorum.

• Alle benötigten VMs und Container wurden auf andere Nodes verschoben oder gesichert.

• Auf dem zu entfernenden Node befinden sich keine benötigten lokalen Daten mehr.

• Bestehende Replikationsjobs wurden berücksichtigt und entfernt.

• HA-Ressourcen und Abhängigkeiten wurden überprüft.

• Falls Ceph verwendet wird, können die verbleibenden Nodes die Daten weiterhin sicher bereitstellen.

Gerade den letzten beiden Punkten sollte man in einer produktiven Umgebung genügend Aufmerksamkeit schenken.

Wichtig: Die folgenden Schritte entfernen einen Node dauerhaft aus der Cluster-Konfiguration. Sie sind nicht mit dem vorübergehenden Abschalten eines Servers für Wartungsarbeiten gleichzusetzen.

Wer einen Node lediglich für ein Update oder einen Hardwaretausch kurzzeitig außer Betrieb nehmen möchte, sollte ihn normalerweise nicht aus dem Cluster entfernen.

2. Cluster-Status überprüfen

Bevor wir Änderungen vornehmen, melden wir uns auf einem vorhandenen Cluster-Node an.

In unserem Beispiel verwenden wir pve1:

ssh root@192.168.10.11

Anschließend überprüfen wir den aktuellen Cluster-Status:

pvecm status

Bei einem gesunden Vier-Node-Cluster sollte die Ausgabe unter anderem folgende Informationen enthalten:

Nodes:            4
Expected votes:   4
Total votes:      4
Quorum:           3

Quorate:          Yes

Die genaue Darstellung kann je nach Proxmox-Version abweichen.

Entscheidend ist zunächst:

Quorate: Yes

Zusätzlich lassen wir uns die vorhandenen Nodes anzeigen:

pvecm nodes

Hier sollten alle vier Hosts auftauchen.

Falls bereits vor der Entfernung Probleme mit Corosync oder dem Quorum bestehen, sollten wir diese zunächst beheben.

Einen Node aus einem ohnehin instabilen Cluster zu entfernen, kann die Fehlersuche erheblich erschweren.

3. Virtuelle Maschinen und Container verschieben

Bevor wir pve4 entfernen, müssen alle darauf befindlichen virtuellen Maschinen und Container berücksichtigt werden.

Am einfachsten kontrollieren wir dies über die Proxmox-Weboberfläche.

Dort wählen wir den betreffenden Node aus und prüfen, welche Gäste noch vorhanden sind.

Alternativ können wir direkt auf pve4 folgende Befehle ausführen:

qm list

Für virtuelle Maschinen und:

pct list

für LXC-Container.

Virtuelle Maschinen migrieren

Wenn die Voraussetzungen erfüllt sind, können wir eine VM auf einen anderen Node migrieren.

Dazu wählen wir in der Weboberfläche die betreffende virtuelle Maschine aus und klicken auf:

Migrate

Anschließend wählen wir den Ziel-Node aus.

Besitzt die VM ihre Festplatten auf einem gemeinsamen Storage, kann die Migration unter geeigneten Voraussetzungen im laufenden Betrieb erfolgen.

Bei lokalem Storage müssen die Daten dagegen zusätzlich auf den Ziel-Node übertragen werden.

Das kann je nach Größe der virtuellen Festplatten etwas Zeit in Anspruch nehmen.

Über die Kommandozeile kann eine Migration beispielsweise so gestartet werden:

qm migrate 100 pve2 --online

Dabei ist 100 die VM-ID und pve2 unser gewünschter Ziel-Node.

Dieser Befehl setzt voraus, dass die VM online migriert werden kann und ihre Storage- und Netzwerkkonfiguration dafür geeignet sind. Lokale Datenträger benötigen gegebenenfalls zusätzliche Migrationsoptionen oder eine vorherige Verschiebung.

Container verschieben

Auch vorhandene LXC-Container müssen auf andere Nodes übertragen oder gesichert werden.

Dafür steht ebenfalls die Migrationsfunktion der Weboberfläche zur Verfügung.

Ob ein Container während der Migration weiterlaufen kann oder gestoppt werden muss, hängt unter anderem von seiner Konfiguration und den verwendeten Storage-Systemen ab.

Nachdem alle Gäste verschoben wurden, kontrollieren wir erneut:

qm list
pct list

Auf dem zu entfernenden Node sollten jetzt keine benötigten VMs oder Container mehr vorhanden sein.

Ein zusätzlicher Blick auf die lokalen Datenspeicher lohnt sich trotzdem. Dort können noch Backups, ISO-Dateien oder andere Daten liegen, die bei einer späteren Neuinstallation verloren gehen würden.

4. Replikationsjobs überprüfen und entfernen

Ein Punkt, der beim Entfernen eines Proxmox-Nodes häufig übersehen wird, sind bestehende Replikationsjobs.

Proxmox kann virtuelle Maschinen zwischen verschiedenen Nodes replizieren, beispielsweise mithilfe von ZFS.

Wenn pve4 als Ziel eines solchen Replikationsjobs eingetragen ist, müssen wir diesen Job vor dem Entfernen des Nodes löschen oder entsprechend neu konfigurieren.

Besonders tückisch ist dabei, dass sich die Richtung eines Replikationsjobs bei einer Migration ändern kann.

Es reicht deshalb nicht immer aus, die Replikationskonfiguration nur vor dem Verschieben der VMs zu überprüfen.

Am besten kontrollieren wir sie nach Abschluss sämtlicher Migrationen noch einmal.

Über die Weboberfläche finden wir die Replikationsjobs unter:

Datacenter → Replication

Alternativ können wir die vorhandenen Jobs über die Kommandozeile anzeigen:

pvesr list

Alle Replikationsjobs, die den zu entfernenden Node betreffen, müssen vor dem endgültigen Entfernen bereinigt sein.

Warum ist das so wichtig?

Bleibt ein Replikationsjob auf einen nicht mehr existierenden Cluster-Node zurück, kann dieser unter Umständen nicht mehr regulär über die vorgesehenen Verwaltungsfunktionen entfernt werden.

Das lässt sich durch eine kurze Kontrolle vor dem eigentlichen Löschvorgang vermeiden.

5. High-Availability-Konfiguration berücksichtigen

Wird Proxmox HA verwendet, sollten wir zusätzlich prüfen, ob der betreffende Node noch für hochverfügbare Ressourcen vorgesehen ist.

Den aktuellen HA-Status können wir mit folgendem Befehl anzeigen:

ha-manager status

Alternativ öffnen wir:

Datacenter → HA

Hier sehen wir, welche VMs und Container durch den HA-Manager verwaltet werden.

Bevor wir einen Node dauerhaft entfernen, müssen diese Ressourcen auf den verbleibenden Nodes betrieben werden können.

Dabei sollten wir nicht nur die aktuelle Platzierung betrachten.

Auch HA-Regeln können noch auf pve4 verweisen.

Wartungsmodus für die Vorbereitung nutzen

Für das kontrollierte Räumen eines HA-Nodes stellt Proxmox einen Wartungsmodus bereit.

Diesen können wir beispielsweise mit folgendem Befehl aktivieren:

ha-manager crm-command node-maintenance enable pve4

Dadurch wird der Node für den HA-Betrieb in den Wartungszustand versetzt. Der HA-Manager versucht anschließend, verwaltete Ressourcen entsprechend ihrer Regeln und der verfügbaren Infrastruktur auf andere Nodes zu verschieben.

Der Wartungsmodus ist allerdings kein Ersatz für eine vollständige Kontrolle.

Wir sollten danach überprüfen, ob tatsächlich alle betroffenen HA-Ressourcen den Node verlassen haben.

Auch die vorhandenen HA-Regeln müssen angepasst werden, damit sie später nicht mehr auf pve4 verweisen.

Wichtig: Der Wartungsmodus dient hier nur dazu, den Node kontrolliert zu räumen. Das dauerhafte Entfernen aus dem Cluster ist ein separater Vorgang.

6. Besonderheit: Proxmox Cluster mit Ceph

Bis hierhin unterscheiden sich die Vorbereitungen kaum von gewöhnlichen Wartungsarbeiten.

Sobald der zu entfernende Node allerdings Teil eines Ceph-Clusters ist, wird die Angelegenheit deutlich anspruchsvoller.

Ceph verteilt Daten über mehrere OSDs und Hosts.

Ein Node kann dabei unterschiedliche Aufgaben übernehmen:

• OSDs für die eigentliche Datenspeicherung

• Ceph Monitors (MON)

• Ceph Managers (MGR)

• CephFS Metadata Server (MDS)

Bevor wir einen solchen Node aus Proxmox entfernen, müssen seine Ceph-Dienste kontrolliert aus dem bestehenden Ceph-Cluster entfernt werden.

Ceph-Zustand überprüfen

Zunächst kontrollieren wir auf einem Node mit Ceph-Zugriff:

ceph -s

Im Idealfall meldet Ceph:

HEALTH_OK

Ein bestehender HEALTH_WARN sollte vor der Entfernung untersucht werden. Insbesondere Warnungen bezüglich fehlender Replikate, voller Datenträger oder nicht verfügbarer OSDs dürfen nicht ignoriert werden.

Anschließend betrachten wir die OSD-Verteilung:

ceph osd tree

Damit können wir erkennen, welche OSDs dem Node pve4 zugeordnet sind.

Reicht die verbleibende Ceph-Infrastruktur aus?

Das ist die entscheidende Frage.

Angenommen, unser Cluster besitzt vier Ceph-Nodes mit jeweils mehreren OSDs. Dann können wir einen Node möglicherweise entfernen, sofern die übrigen Hosts genügend Kapazität und ausreichende Redundanz besitzen.

Problematischer wird es, wenn wir einen Drei-Node-Ceph-Cluster auf zwei Nodes reduzieren möchten.

Bei einer üblichen Konfiguration mit drei Replikaten und einer Verteilung über unterschiedliche Hosts lässt sich die bisherige Redundanz mit nur zwei verbleibenden Hosts nicht aufrechterhalten.

In diesem Fall sollte zunächst geeignete zusätzliche Storage-Kapazität beziehungsweise ein Ersatz-Node bereitgestellt werden.

Die vorhandenen Ceph-Pool-Einstellungen, insbesondere size, min_size und die verwendete CRUSH-Regel, müssen vor einer solchen Änderung überprüft werden.

Ein Node sollte keinesfalls entfernt werden, wenn dadurch die Mindestanzahl verfügbarer Replikate unterschritten oder der Storage unbenutzbar würde.

7. Ceph-OSDs kontrolliert entfernen

Wenn die Voraussetzungen erfüllt sind, können wir die OSDs des betreffenden Nodes nacheinander entfernen.

Dabei sollte nicht versucht werden, alle OSDs gleichzeitig zu löschen.

Stattdessen nehmen wir jeweils einen OSD aus der Datenverteilung und warten darauf, dass Ceph die notwendigen Datenverschiebungen abgeschlossen hat.

Angenommen, auf pve4 befindet sich ein OSD mit der ID 4.

Zunächst setzen wir diesen OSD auf out:

ceph osd out 4

Ceph beginnt daraufhin, die betroffenen Daten entsprechend der vorhandenen Pool- und CRUSH-Konfiguration auf andere OSDs zu verteilen.

Den Fortschritt beobachten wir mit:

ceph -s

Zusätzlich können wir kontrollieren, wie viele Placement Groups noch dem betreffenden OSD zugeordnet sind.

Bevor wir ihn stoppen, prüfen wir, ob dies sicher möglich ist:

ceph osd ok-to-stop 4

Erst wenn Ceph den Vorgang als sicher bewertet und die erforderlichen Datenverschiebungen abgeschlossen sind, stoppen wir den OSD.

Das lässt sich in der Proxmox-Weboberfläche unter:

Node → Ceph → OSD

durchführen.

Dort wählen wir den OSD aus und verwenden zunächst Out, anschließend Stop und schließlich Destroy.

Alternativ steht dafür nach erfolgreicher Sicherheitsprüfung der CLI-Befehl zur Verfügung:

pveceph osd destroy 4

!Achtung: pveceph osd destroy entfernt den OSD dauerhaft. Der Vorgang kann nicht einfach rückgängig gemacht werden!

Wer zusätzlich die bisherige Datenträgerkonfiguration bereinigen möchte, kann die entsprechende Cleanup-Option verwenden. Dabei werden auch vorhandene OSD-Datenträgerstrukturen entfernt.

Nach jedem entfernten OSD sollte der Ceph-Zustand erneut überprüft werden.

Erst wenn der Cluster wieder gesund ist und ausreichende Redundanz besitzt, fahren wir mit dem nächsten OSD fort.

Weitere Ceph-Dienste entfernen

Nachdem alle OSDs von pve4 entfernt wurden, müssen gegebenenfalls noch weitere Ceph-Dienste berücksichtigt werden.

Dazu zählen:

CephFS Metadata Server: Falls der Node einen MDS betreibt, muss dieser kontrolliert entfernt werden.

Ceph Monitor: Bevor wir einen Monitor löschen, muss sichergestellt sein, dass die verbleibenden Monitors weiterhin eine funktionsfähige Mehrheit bilden.

Ceph Manager: Auch der Manager-Dienst muss gegebenenfalls auf einem anderen Host verfügbar sein.

Die entsprechenden Funktionen befinden sich in der Proxmox-Weboberfläche unter den jeweiligen Ceph-Bereichen.

Erst wenn keine Ceph-Dienste mehr auf pve4 betrieben werden und die übrige Ceph-Infrastruktur gesund ist, können wir mit der eigentlichen Entfernung des Proxmox-Nodes fortfahren.

Gegebenenfalls muss zum Abschluss auch der leere Host-Eintrag aus der Ceph-CRUSH-Hierarchie entfernt werden.

Wichtig: Die Entfernung eines Ceph-Nodes sollte bei produktiven Umgebungen immer als eigener Wartungsvorgang geplant werden. Der dafür benötigte Zeitraum hängt wesentlich von der Datenmenge, verfügbaren Kapazität und Netzwerkleistung ab.

8. QDevice vor dem Entfernen berücksichtigen

Falls unser Cluster ein QDevice verwendet, müssen wir dieses vor einer Änderung der Cluster-Mitgliedschaft entfernen.

Auf einem vorhandenen Cluster-Node führen wir dazu aus:

pvecm qdevice remove

Anschließend kontrollieren wir:

pvecm status

Das ist besonders bei kleinen Clustern wichtig, weil sich durch das Entfernen des QDevice die Anzahl der Quorum-Stimmen verändert.

Nach Abschluss der Node-Entfernung kann das QDevice bei Bedarf erneut eingerichtet werden.

Bei einem Cluster mit drei regulären Nodes ist ein zusätzliches QDevice normalerweise nicht erforderlich.

9. Proxmox Node endgültig entfernen

Nachdem alle Vorbereitungen abgeschlossen sind, können wir den eigentlichen Node aus dem Cluster entfernen.

Vorher kontrollieren wir noch einmal, dass:

• keine benötigten VMs oder Container mehr auf pve4 liegen,

• keine Replikationsjobs mehr auf den Node verweisen,

• keine HA-Ressourcen mehr dort betrieben werden,

• vorhandene Ceph-Dienste vollständig entfernt wurden,

• der verbleibende Cluster weiterhin funktionsfähig ist.

Anschließend fahren wir den zu entfernenden Node kontrolliert herunter:

shutdown -h now

Dieser Befehl wird auf pve4 ausgeführt.

Nun müssen wir sicherstellen, dass dieser Host nicht erneut mit seiner bisherigen Cluster-Konfiguration gestartet wird.

Das ist besonders wichtig.

Ein bereits entfernter Node darf nicht einfach wieder eingeschaltet werden und versuchen, mit seiner alten Corosync-Konfiguration am bestehenden Cluster teilzunehmen.

Node mit pvecm delnode entfernen

Nachdem pve4 heruntergefahren wurde, melden wir uns auf einem der verbleibenden Nodes an, beispielsweise auf pve1.

Dort führen wir folgenden Befehl aus:

pvecm delnode pve4

Proxmox entfernt damit den entsprechenden Node aus der Cluster-Konfiguration.

Da pve4 bereits heruntergefahren wurde, kann bei diesem Vorgang unter Umständen folgende Meldung erscheinen:

Could not kill node
(error = CS_ERR_NOT_EXIST)

Diese Meldung bedeutet nicht zwangsläufig, dass die Entfernung fehlgeschlagen ist.

Sie kann lediglich darauf hinweisen, dass Corosync den bereits offline befindlichen Node nicht mehr erreichen konnte.

Deshalb überprüfen wir anschließend die Mitgliederliste.

10. Cluster nach der Entfernung kontrollieren

Zunächst führen wir aus:

pvecm nodes

In unserer Beispielumgebung sollten jetzt nur noch folgende Nodes vorhanden sein:

pve1
pve2
pve3

Danach überprüfen wir den Cluster-Status:

pvecm status

Für einen normalen Drei-Node-Cluster erwarten wir nun beispielsweise:

Nodes:            3
Expected votes:   3
Total votes:      3
Quorum:           2

Quorate:          Yes

Damit wissen wir, dass der Cluster weiterhin die benötigte Mehrheit besitzt.

Falls Ceph verwendet wird, sollten wir zusätzlich dessen Zustand überprüfen:

ceph -s

Bei HA-Clustern kontrollieren wir außerdem:

ha-manager status

Erst wenn alle beteiligten Systeme wieder ordnungsgemäß arbeiten, ist die Entfernung abgeschlossen.

11. Verbleibende Konfigurationsdateien bereinigen

Nach dem Entfernen eines Nodes kann dessen Verzeichnis im gemeinsamen Cluster-Dateisystem weiterhin vorhanden sein.

Dieses befindet sich unter:

/etc/pve/nodes/

Für unseren entfernten Node lautet das entsprechende Verzeichnis:

/etc/pve/nodes/pve4/

Darin können sich beispielsweise noch alte Konfigurationen oder andere nodebezogene Dateien befinden.

Bevor dieses Verzeichnis gelöscht wird, sollte deshalb überprüft werden, ob noch Daten enthalten sind, die benötigt werden.

Wir können den Inhalt zunächst anzeigen:

ls -la /etc/pve/nodes/pve4/

Nur wenn sicher ist, dass darin keine benötigten Informationen mehr liegen, sollte das verbliebene Node-Verzeichnis bereinigt werden.

Auch bestehende HA-Regeln und SSH-Vertrauensstellungen können nach der Entfernung noch Einträge zum alten Node enthalten.

Diese sollten ebenfalls überprüft und bei Bedarf angepasst werden.

Wird später ein Server mit derselben IP-Adresse oder demselben Hostnamen neu installiert, können ansonsten beispielsweise Konflikte bei der SSH-Host-Key-Prüfung auftreten.

Proxmox stellt für die Aktualisierung der Cluster-Zertifikate und SSH-Fingerprints unter anderem folgenden Befehl bereit:

pvecm updatecerts

Er sollte allerdings nur dann eingesetzt werden, wenn die entsprechende Situation dies tatsächlich erfordert.

12. Besonderheit: Node aus einem Zwei-Node-Cluster entfernen

Ein Sonderfall entsteht, wenn unser Cluster aus lediglich zwei Nodes besteht.

Angenommen, wir haben:

pve1
pve2

und möchten pve2 entfernen.

Sobald wir diesen Host herunterfahren, verbleibt nur noch pve1.

In einem gewöhnlichen Zwei-Node-Cluster ohne QDevice besitzt dieser einzelne Node dann kein Quorum mehr.

Der Befehl:

pvecm delnode pve2

kann deshalb mit einer Fehlermeldung abbrechen.

Für eine solche Situation bietet Proxmox die Möglichkeit, die erwartete Anzahl der Stimmen vorübergehend anzupassen.

Auf dem verbleibenden Node können wir dafür verwenden:

pvecm expected 1

Anschließend lässt sich der bereits heruntergefahrene Node entfernen:

pvecm delnode pve2

Achtung: pvecm expected 1 sollte nicht als allgemeine Lösung für Quorum-Probleme verwendet werden.

Dieser Eingriff ist nur für kontrollierte Situationen vorgesehen, in denen eindeutig feststeht, welcher Node weiterbetrieben wird und dass keine zweite aktive Cluster-Partition existiert.

In einem produktiven Cluster sollte man damit besonders vorsichtig umgehen.

Wer einen Zwei-Node-Cluster dauerhaft betreiben möchte, sollte sich außerdem mit der Verwendung eines QDevice beschäftigen.

13. Kann ein entfernter Node später wieder beitreten?

Ja, grundsätzlich kann dieselbe Hardware später wieder Teil des Clusters werden.

Allerdings sollte ein entfernter Node nicht einfach unverändert neu gestartet werden.

Er besitzt noch lokale Informationen zur bisherigen Cluster-Mitgliedschaft und könnte dadurch Konflikte verursachen.

Der von Proxmox empfohlene Weg besteht deshalb darin, den Server vor einem erneuten Beitritt frisch zu installieren.

Danach kann der Host wie ein neuer Node wieder hinzugefügt werden.

Der Vorgang ist in unserer Anleitung Proxmox Node zu einem bestehenden Cluster hinzufügen beschrieben.

Eine Trennung ohne Neuinstallation ist technisch ebenfalls möglich, allerdings deutlich fehleranfälliger.

Insbesondere wenn der getrennte Node weiterhin Zugriff auf denselben Shared Storage hat, können Konflikte bei VM-IDs, Locks und gemeinsam genutzten Daten entstehen.

Für produktive Systeme würde ich deshalb grundsätzlich eine saubere Neuinstallation bevorzugen.

14. Node-Entfernung in einer Testumgebung ausprobieren

Das Entfernen eines Cluster-Nodes gehört zu den administrativen Aufgaben, die sich nur begrenzt theoretisch vermitteln lassen.

Gerade wenn Quorum, Ceph und High Availability beteiligt sind, hilft es, den Vorgang einmal vollständig in einer isolierten Umgebung durchzuspielen.

Dabei lassen sich beispielsweise folgende Szenarien untersuchen:

• Einen Node aus einem Drei- oder Vier-Node-Cluster entfernen

• Vorhandene VMs auf andere Nodes migrieren

• Änderungen am Quorum beobachten

• Einen Ceph-OSD kontrolliert außer Betrieb nehmen

• HA-Ressourcen vor einer Node-Entfernung verschieben

• Einen entfernten Node neu installieren und wieder hinzufügen

Solche Tests sollten nicht unvorbereitet in produktiven Clustern stattfinden.

Mit unserer Proxmox-Schulungsumgebung lassen sich mehrere Proxmox-Nodes für einen frei wählbaren Nutzungszeitraum bereitstellen.

Dadurch können Administratoren die Cluster-Konfiguration selbst aufbauen, unterschiedliche Betriebszustände testen und anschließend einzelne Nodes gezielt wieder entfernen.

Gerade für Schulungen oder die Vorbereitung größerer Infrastrukturänderungen ist das eine gute Möglichkeit, Erfahrungen zu sammeln, ohne bestehende Produktivsysteme zu gefährden.

Fazit

Einen Proxmox-Node aus einem bestehenden Cluster zu entfernen, ist technisch mit einem einzigen Befehl möglich.

Der eigentliche Aufwand liegt allerdings in der Vorbereitung.

Alle virtuellen Maschinen und Container müssen berücksichtigt werden, Replikationsjobs dürfen nicht zurückbleiben und die verbleibenden Nodes müssen auch nach der Entfernung noch Quorum besitzen.

Bei Clustern mit Ceph kommen zusätzliche Anforderungen hinzu. Hier muss insbesondere sichergestellt werden, dass genügend Storage-Kapazität und Redundanz erhalten bleiben.

Wer diese Punkte sorgfältig überprüft und den Node erst nach Abschluss aller Vorbereitungen mit pvecm delnode entfernt, kann einen bestehenden Cluster kontrolliert verkleinern oder alte Hardware durch neue Systeme ersetzen.

Weiterführende Artikel

• Proxmox Cluster – der vollständige Guide

• Proxmox Cluster erstellen – Schritt-für-Schritt-Anleitung

• Proxmox Cluster mit 2 Nodes: Quorum und QDevice

• Proxmox Node zu einem Cluster hinzufügen

• Proxmox Cluster vollständig auflösen (folgt)

• Proxmox Ceph Cluster einrichten (folgt)

Offizielle Dokumentation: Proxmox VE – Cluster Manager