Pattarin - stock.adobe.com
Proxmox-Cluster planen: Netzwerk, Storage, Knotenrollen
Ein gut geplanter Proxmox-Cluster nutzt strukturiertes Netzdesign, passende Storage-Modelle und definierte Knotenrollen, um Migrationen, HA und SDN kontrolliert bereitzustellen.
Ein Proxmox-Cluster basiert auf einem Multi-Master-Modell. Jeder Host besitzt Zugriff auf das Cluster-Dateisystem pmxcfs, das Konfigurationsdateien synchron hält. Dieser Mechanismus bildet die Basis aller Verwaltungsfunktionen.
Das Cluster-System pmxcfs speichert VM-Definitionen, Containerparameter, Storage-Konfigurationen, Firewall-Objekte, SDN-Einträge, Rollenmodelle, Benutzerrechte und viele weitere Metadaten. Jede Änderung wird über Corosync an alle Knoten übertragen.
Für einen stabilen Cluster ist ein funktionierendes Quorum zwingend erforderlich. Corosync nutzt Quorumprozesse, um sicherzustellen, dass Entscheidungen nur gültig sind, wenn eine Mehrheit der Knoten beteiligt ist. Dabei dient Corosync in Proxmox als Kommunikationsdienst zwischen den Cluster-Knoten. Der Dienst überträgt Statusmeldungen, Mitgliedschaftsinformationen und Abstimmungsergebnisse. Jeder Knoten erfährt damit zuverlässig, welche Hosts erreichbar sind und welche nicht. Auf dieser Grundlage berechnet der Cluster sein Quorum. Entscheidungen wie Migrationen, HA-Aktionen oder Konfigurationsänderungen gelten nur dann als gültig, wenn Corosync bestätigt, dass eine ausreichende Zahl an Knoten beteiligt ist. Dadurch verhindert der Cluster widersprüchliche Zustände, die auftreten könnten, wenn isolierte Knoten eigenständig Änderungen durchführen. Ohne Quorum blockiert Proxmox kritische Vorgänge. Migrationen, Replikationen und HA-Aktionen werden verweigert, um Konsistenzprobleme zu vermeiden.
Diese Mechanismen führen zu einer zentralen Erkenntnis. Ein Cluster muss immer auf einer strukturierten, vorab definierten Architektur aufbauen. Unabhängig von realen IP-Adressen, Hostnamen oder VLAN-Werten wird der Planungsprozess in logisch getrennte Bereiche gegliedert. Die Beispielwerte in den folgenden Abschnitten dienen nur der Veranschaulichung und ersetzen keine individuellen Entwürfe für produktive Systeme.
Strukturierter Ansatz für das Netzwerkdesign
Ein tragfähiges Netzdesign trennt die Verkehrsarten eindeutig voneinander. Diese Trennung erhöht die Stabilität und verbessert das Fehlerverhalten. Bewährt haben sich drei logische Netzwerkbereiche, die in praktisch allen Szenarien Einzug finden:
- Das Verwaltungsnetz führt die Weboberfläche, die API von pveproxy, den Zugriff per SSH sowie die Corosync-Kommunikation. Dieses Netz sollte klar separiert sein, da es bei Störungen direkten Einfluss auf Cluster-Aktionen hat.
- Ein Storage-Netz transportiert NFS-, iSCSI- oder Ceph-Datenströme. Die Lasten dieser Transportwege sind erheblich. Eine klare Abgrenzung zum Verwaltungsbereich hält Latenzen niedrig und verhindert Engpässe bei Migrationen.
- Ein VM-Netz bindet virtuelle Maschinen (VM) und Container an produktive Netze an. Dieser Bereich sollte nicht mit dem Verwaltungsnetz vermischt werden, da der Datenverkehr der Gäste andere Anforderungen an Bandbreite und Segmentierung stellt.
In einer Beispielumgebung könnte vmbr0 das Verwaltungsnetz abbilden, vmbr1 das Storage-Netz und vmbr2 das VM-Netz. Die tatsächliche Struktur wird durch vorhandene Switches, VLAN-Designs und externe Router bestimmt. Die Nutzung von VLANs reduziert den physischen Aufwand. Eine Bridge erhält in diesem Fall keinen zusätzlichen physischen Port, sondern arbeitet mit getaggten Interfaces.
Der Aufbau eines Bonds für das Storage-Netz liefert Redundanz und höhere Bandbreite. Ein LACP-Modus (802.3ad) führt zwei physische Leitungen logisch zusammen:
auto bond0
iface bond0 inet manual
bond-slaves enp2s0 enp3s0
bond-miimon 100
bond-mode 802.3ad
Darüber legt eine Bridge die logische Transportebene:
auto vmbr1
iface vmbr1 inet static
address 172.20.50.10/24
bridge-ports bond0
bridge-stp off
bridge-fd 0
Diese Werte stehen beispielhaft und werden individuell ersetzt. Entscheidend ist das Prinzip der getrennten Verkehrswege, nicht die konkrete IP-Struktur.
Eine solche Trennung verbessert die Erfolgsquote von Migrationen. Der Migrationsprozess überträgt Speicherzustände, CPU-Kontexte und Geräteeigenschaften der VM über das Verwaltungsnetz. Eine Überlastung dieses Pfads würde die Migration verzögern oder abbrechen.
Planung der Storage-Topologien
Für den Storage existieren drei fundamentale Modelle, die sich in Praxisumgebungen häufig kombinieren lassen.
Lokales Storage mit Replikation
Lokale ZFS-Pools bieten hohe Flexibilität. Jede VM liegt auf dem eigenen Knoten, Replikationsaufträge halten synchrone Kopien auf anderen Hosts bereit. Eine Live Migration arbeitet auf dieser Basis schneller, da der Zielspeicher bereits aktuelle Daten besitzt. Die Replikation nutzt ZFS-Snapshots und überträgt inkrementelle Blöcke. Die Oberfläche erlaubt Intervalle von wenigen Minuten bis zu mehreren Stunden.
Ein Replikationsauftrag wird Cluster-weit verwaltet, aber pro VM konfiguriert. Die Definition umfasst den Zielknoten sowie ein Schedule-Feld mit Kalenderformat. Das System prüft regelmäßig alle Replikationsaufträge und zeigt den Status im Tab „Tasks“ der Weboberfläche an.
Gemeinsames Storage über NFS oder iSCSI
NFS bietet sich für Templates, Container-Images, Cloud-Init-Dateien, ISO-Medien und Backups an. Die Einrichtung erfolgt über die Oberfläche mit der Auswahl Add -> NFS. NFS-Storage lässt sich anschließend VM-weit nutzen. Für produktive VM-Festplatten ist NFS abhängig von Latenz und Durchsatz. Ein leistungsfähiger Server mit ZFS-SLOG verbessert die Konsistenz synchroner Write-Operationen erheblich.
iSCSI stellt blockbasiertes Storage bereit. Das System behandelt die LUNs wie physische Datenträger. Proxmox kann darauf LVM-Gruppen anlegen. Dieser Ansatz eignet sich für Umgebungen, in denen blockorientierter Zugriff gefordert ist. Multipath-Umgebungen mit redundanten Netzwerkpfaden erhöhen die Ausfallsicherheit.
In einer Beispielumgebung könnte die Anbindung so erfolgen:
pvesm add iscsi beiscsi --portal 172.30.20.50 --target iqn.2024-02.example:cluster.lun1
Darauf entsteht die LVM-Gruppe:
pvesm add lvm lvmscsi --vgname vg_cluster --base beiscsi
Verteiltes Storage mit Ceph
Ceph integriert sich tief in Proxmox. Der Assistent erzeugt Monitore, Manager und OSDs (Object Storage Daemon). Ceph liefert RADOS Block Devices (RDB) als primäres Medium für VMs. Pools können als replizierte oder erasure-coded Pools betrieben werden. Ceph benötigt eigene Netzwege für Client-IO und Replikation zwischen den OSDs.
Der Vorteil von Ceph liegt in der fehlenden Abhängigkeit von externen Storage-Systemen. Jeder Host trägt zur Gesamtleistung bei. Je mehr OSDs im Cluster existieren, desto größer die IOPS-Leistung und Bruttokapazität.
Knotenrollen klar definieren
Ein Proxmox-Cluster profitiert von einer sinnvollen Aufgabenzuweisung. Auch wenn jeder Knoten denselben Funktionsumfang besitzt, verdeutlicht eine Rollenplanung die Architektur und entlastet kritische Bereiche:
- Compute-Knoten: Compute-Knoten tragen den Hauptteil der VMs und Container. Starke CPU-Leistung, hoher RAM-Ausbau und schnelle lokale SSDs sind hier relevant.
- Storage-Knoten: Storage-Knoten können Ceph-OSDs, iSCSI-Targets oder NFS-Server beherbergen. In einer Beispielumgebung wäre ein Host mit vielen NVMe-Geräten dafür geeignet.
- Management-Knoten: Management-Knoten übernehmen API, GUI, pvedaemon, pveproxy, Cluster-Dienste und Zertifikatverwaltung. Es besteht keine zwingende Notwendigkeit, sie exklusiv zu betreiben, aber es ist ratsam, sie nicht zu überlasten.
Eine solche Struktur dient der Orientierung. In der Praxis verschmelzen diese Rollen häufig, dennoch bleibt die klare Abgrenzung in der Planungsphase wichtig.
Hochverfügbarkeit und Knoteninteraktion
HA-Ressourcen lassen sich im Menü der Weboberfläche anlegen. Eine HA-Ressource definiert, wie eine VM im Fehlerfall verlagert oder neu gestartet wird. Eine funktionierende HA-Konfiguration setzt Replikation oder gemeinsames Storage voraus. Proxmox nutzt einen lokalen Ressourcenmanager sowie den Cluster Resource Manager, um Failover-Entscheidungen umzusetzen.
Affinity-Regeln legen fest, ob eine VM bevorzugt auf einem bestimmten Knoten läuft oder von einzelnen Hosts ferngehalten werden soll. Diese Regeln unterstützen gezielte Verteilungen oder Trennungen kritischer Maschinen.
Migration als technisches Planungselement
Eine Live Migration verschiebt eine laufende VM innerhalb des Clusters ohne sichtbare Unterbrechung im Gast. Die Voraussetzungen sind ein gültiges Quorum, kompatible CPU-Features und ein geeigneter Storage-Pfad. Bei lokalem Storage kopiert Proxmox während der Migration die virtuellen Festplatten inkrementell oder vollständig.
Das Shell-Kommando in einer Beispielumgebung lautet:
qm migrate 200 nodeB --online
Der Vorgang überträgt nur Speicherinhalte, wenn die Disk über gemeinsames Storage bereitgestellt wird. Bei Migrationen von lokalem Storage dient die Option --with-local-disks als Ergänzung.
Einsatz von SDN für komplexe Strukturen
Proxmox-SDN ergänzt klassische Bridges um VNets, Zonen, Subnetze und dynamisches Routing. Die Definitionen liegen unter /etc/pve/sdn und werden per Weboberfläche gesteuert.
dnsmasq liefert Adressen für SDN-Subnetze. Proxmox erzeugt für jede Zone eigene Konfigurationsdateien und bindet sie an die Bridge des jeweiligen VNets. Die Aktivierung erfolgt automatisch nach der Definition eines Subnetzes. In einer Beispielumgebung könnte ein Subnetz so aussehen:
Subnet: 10.150.10.0/24
Gateway: 10.150.10.1
DHCP Range: 10.150.10.100 - 10.150.10.200
SNAT: enabled
FRRouting als Routing-Komponente
FRRouting liefert OSPF- und BGP-Funktionalität. In VXLAN- oder EVPN-Zonen wird FRRouting genutzt, um Routinginformationen zwischen den Knoten auszutauschen. Dadurch entsteht ein verteiltes, dynamisches L2-over-L3-Netzwerk.
SDN eignet sich für Mandantentrennung, experimentelle Netze, verschachtelte Laborumgebungen und Segmentierung komplexer Anwendungen.
Integration von Cloud-Init und Terraform
Cloud-Init dient der automatisierten Initialisierung neuer virtueller Maschinen. Templates speichern Cloud-Init-Laufwerke und geben Netzkonfiguration, Benutzer, SSH-Schlüssel sowie Paketinstallationen beim ersten Bootvorgang an den Gast weiter. In Terraform-Umgebungen entstehen reproduzierbare VM-Definitionen auf Basis deklarativer HCL-Dateien. Der Provider interagiert direkt mit der Proxmox-API.
Beispiel für die Bereitstellung einer VM per Terraform:
resource "proxmox_vm_qemu" "web01" {
name = "web01"
target_node = "nodeA"
clone = "template-ubuntu"
memory = 4096
cores = 4
}
Diese Automatisierungswege sind relevant für die Cluster-Planung, wenn viele identische Systeme oder standardisierte Rollenprofile entstehen sollen.
Backup- und Disaster-Recovery-Konzepte
Proxmox Backup Server stellt Datastores für inkrementelle, deduplizierte Sicherungen bereit. Der Host-Backup-Mechanismus über proxmox-backup-client sichert /etc/pve und /etc/network. Damit lassen sich Konfigurationen eines Hosts vollständig rekonstruieren.
Beispiel für einen Host-Backup-Aufruf:
proxmox-backup-client backup hostconfig.pxar:/etc/pve networkconfig.pxar:/etc/network --repository <repo>
Für die Wiederherstellung wird ein Proxmox-Host neu installiert und danach das pxar-Archiv zurückgespielt. Anschließend können VM-Backups aus dem Datastore wieder eingespielt werden. Dadurch bleiben VMIDs, Storage-Zuordnungen und Netzdefinitionen erhalten.
Ein Disaster-Recovery-Konzept beinhaltet daher nicht nur VM-Backups, sondern auch die Sicherung der Host-Konfigurationsdateien.
Hardwareaspekte bei der Cluster-Planung
Ein Cluster benötigt homogene CPU-Befehlssätze für Migrationen. Unterschiedliche Generationen derselben Architektur lassen sich oft kombinieren, dennoch sollte ein einheitlicher CPU-Typ bevorzugt werden.
Schnelle SSDs und NVMe-Laufwerke bilden eine sinnvolle Basis für ZFS-Pools oder Ceph-OSDs. RAM-Größe und CPU-Anzahl richten sich nach den Lastprofilen der Gäste. Verteilte Arbeitslast verlangt genügend physische Netzwerkadapter, um Verwaltungs-, Storage- und VM-Verkehr voneinander zu trennen.
Redundante Netzteile, USV-Unterstützung und Out-of-Band-Management über iDRAC, IPMI oder Redfish erleichtern Wartungen und erhöhen die Betriebssicherheit.
Fazit
Ein präzise geplanter Proxmox-Cluster basiert auf konsistenten Netzwerksegmenten, wohlüberlegten Storage-Strukturen und klaren Knotenrollen. Die Cluster-Mechanismen von pmxcfs, Corosync, HA-Manager und SDN greifen nur dann sauber ineinander, wenn die zugrunde liegenden Bereiche logisch getrennt, technisch belastbar und administrativ nachvollziehbar aufgebaut sind.
Die Beispielwerte in diesem Artikel dienen ausschließlich der Illustration. Jede produktive Umgebung gestaltet Netzbereiche, Storage-Bereiche, Rollenmodelle und Arbeitslastverteilungen individuell. Ein strukturierter Planungsprozess erhöht die Stabilität des Clusters und schafft eine Grundlage für effiziente Migrationen, schnelle Wiederherstellungen, ausfallsichere SDN-Strukturen und klare Erweiterungsoptionen.
