Cluster-Architektur prüfen: Proxmox-Beratung ordnet Netz, Storage und Ausfalldomänen ein. Für providerbezogenen Aufbau: Hetzner, OVHcloud und IONOS. Erstgespräch.
Dieser Leitfaden behandelt die providerneutrale Netzplanung. Die bestehenden Provider-Anleitungen ergänzen die jeweilige Produkt- und Routingkonfiguration. Beispielkonfigurationen und Prüfbefehle sind enthalten. Stand: Oktober 2026.
Inhalt
- Verkehr und Ausfalldomänen erfassen
- Corosync vom Lastverkehr trennen
- Storage und Migration dimensionieren
- VLANs, Bonds und MTU festlegen
- Netz vor der Freigabe prüfen
- Provider-Anleitungen und Beratung
- Quellen
Verkehr und Ausfalldomänen erfassen
Beginnen Sie mit einer Verkehrsmatrix. Pro Netz sind Teilnehmer, erlaubte Verbindungen, Kapazität, MTU und physischer Pfad zu dokumentieren. Die PVE-Netzdokumentation unterscheidet Bridges, Routing, VLANs und Bonds; diese Werkzeuge erfüllen unterschiedliche Aufgaben.
| Verkehr | Teilnehmer | Planungsentscheidung |
|---|---|---|
| Management | Administratoren, PVE und Infrastruktur | Kontrollierter Zugang, Routing und unabhängige Konsole |
| Corosync | Cluster-Nodes untereinander | Latenzarmer Hauptpfad und physisch unabhängiger zusätzlicher Link |
| Storage | Nodes und Storage-Dienste | Kapazität für Gast-I/O, Recovery und Replikation |
| Migration und Backup | Quelle, Ziel und PBS | Geplanter Pfad, Lastgrenzen und Erreichbarkeit |
| Gäste | VMs, Container und externe Dienste | VLAN-/Bridge-Zuordnung und Firewall-Regeln |
Ein Netzname beweist keine unabhängige Ausfalldomäne. Zeichnen Sie Kabel, NICs, Switches, Uplinks und gegebenenfalls die Standortverbindung dazu. Zwei VLANs auf derselben NIC teilen weiterhin deren Ausfall und Kapazität. Auch ein zweiter Switch hilft nur, wenn der verbleibende Pfad tatsächlich nutzbar bleibt.
Corosync vom Lastverkehr trennen
Der Cluster Manager verlangt für stabilen Betrieb ein zuverlässiges Netz mit Latenzen unter 5 ms zwischen allen Nodes. Das ist eine Herstelleranforderung. Corosync benötigt vergleichsweise wenig Bandbreite, reagiert aber empfindlich auf Latenzschwankungen. Proxmox empfiehlt eine dedizierte physische NIC und rät von einem gemeinsamen Hauptnetz mit Storage ab.
Planen Sie einen weiteren Corosync-Link über einen anderen physischen Pfad. Corosync kann über Kronosnet selbst zwischen Links wechseln. Ein zusätzliches VLAN auf demselben Uplink bietet diese physische Unabhängigkeit nicht. Storage darf allenfalls einen niedrig priorisierten Fallback in einer redundanten Konfiguration liefern; es ersetzt nicht den getrennten Hauptpfad.
Erfassen Sie statische Linkadressen und die erlaubten Verbindungen. Die Herstellerdokumentation nennt UDP 5405-5412 zwischen Nodes für Corosync und weitere Anforderungen wie SSH und synchronisierte Zeit. Erreichbarkeit ist gezielt zwischen den Cluster-Nodes freizugeben, nicht als öffentliche Freigabe. Für zwei Nodes wird das QDevice-Konzept zusätzlich geplant; es liefert weder Storage noch Netzkapazität.
Beispiel für den Aufbau eines Clusters mit zwei Corosync-Links über getrennte Netze (Adressen sind Platzhalter):
# auf dem ersten Node
pvecm create prod-cluster --link0 10.10.10.11 --link1 10.10.30.11
# auf jedem weiteren Node, mit dessen eigenen Link-Adressen
pvecm add 10.10.10.11 --link0 10.10.10.12 --link1 10.10.30.12
pvecm status
link0 liegt auf der dedizierten Corosync-NIC, link1 auf einem physisch anderen Pfad. Ein Beispiel-Adressplan:
| Netz | Subnetz | Verwendung | Physischer Pfad |
|---|---|---|---|
| Management | 192.0.2.0/24 | Web-GUI, SSH, Gäste-Bridge | Bond über zwei Switches, VLAN-aware Bridge |
| Corosync link0 | 10.10.10.0/24 | Cluster-Kommunikation | Dedizierte NIC, eigener Switch |
| Corosync link1 | 10.10.30.0/24 | Zusätzlicher Cluster-Link | Anderer Switch oder anderes Kabel |
| Storage und Migration | 10.10.20.0/24 | Ceph, Replikation, Migration | Eigene 10-25-Gbit-Ports |
Storage und Migration dimensionieren
Für hyperkonvergentes Ceph empfiehlt Proxmox mindestens 10 Gbit/s für Ceph-Traffic. Der Bedarf umfasst neben Gast-I/O auch Recovery und Replikation. Public Network und optionales Cluster Network haben unterschiedliche Rollen; die Trennung muss zur tatsächlichen Hardware und Last passen. Die Ceph-Anleitung behandelt den Storage-Aufbau.
Auch ohne Ceph erzeugen Backups, ZFS-Replikation und VM-Migration konkurrierende Datenströme. Die Migrationsnetze lassen sich gezielt auswählen. Planen Sie Kapazität und Lastbegrenzungen aus dem Bestand; ein schneller Uplink allein beweist keine stabile Clusterkommunikation.
VLANs, Bonds und MTU festlegen
VLANs ordnen logische Netze; Bonds bündeln oder sichern Links abhängig vom Modus. Für LACP müssen Switch- und Hostkonfiguration zusammenpassen. Für Corosync empfiehlt Proxmox mehrere Netze statt eines alleinigen Bonds, weil einzelne Bond-Fehlerbilder die Clusterkommunikation beeinträchtigen können (Bonding und VLANs).
Legen Sie die MTU durchgehend fest: Host, VLAN, Bond, Bridge, Switch und Providerpfad müssen zusammenpassen. Größere Frames sind eine bewusste Entscheidung, keine Voraussetzung für einen Cluster. Ein kleiner Ping bestätigt noch keine Übertragung mit der geplanten Paketgröße; prüfen Sie den vollständigen Pfad und vermeiden Sie ungeprüfte MTU-Übernahmen aus anderen Providernetzen.
Bei einem bestehenden Cluster Netzänderungen schrittweise planen. Proxmox beschreibt Änderungen an einer Kopie der corosync.conf, die Erhöhung von config_version und die anschließende Statusprüfung. Nicht gleichzeitig alle funktionierenden Linkpfade ersetzen (Cluster-Konfiguration).
Beispiel für /etc/network/interfaces mit LACP-Bond, VLAN-aware Bridge und einer dedizierten Corosync-NIC (Namen und Adressen anpassen):
auto bond0
iface bond0 inet manual
bond-slaves enp1s0f0 enp1s0f1
bond-miimon 100
bond-mode 802.3ad
bond-xmit-hash-policy layer2+3
auto vmbr0
iface vmbr0 inet static
address 192.0.2.11/24
gateway 192.0.2.1
bridge-ports bond0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094
auto enp2s0
iface enp2s0 inet static
address 10.10.10.11/24
Die Gäste hängen an vmbr0 und erhalten ihre VLAN-ID an der virtuellen Netzwerkkarte. enp2s0 ist die eigene Corosync-NIC ohne Bond und ohne Gäste. Mit Jumbo Frames auf dem Storage-Netz gilt dort die MTU durchgehend, zum Beispiel mtu 9000 an Schnittstelle und Switch. Den Pfad prüfen Sie mit einem Ping ohne Fragmentierung in voller Paketgröße (9000 minus 28 Byte Header):
ping -c 3 -M do -s 8972 10.10.20.12
Netz vor der Freigabe prüfen
Die folgenden lesenden Befehle erfassen Adressen, Routen und Clusterzustand. corosync-cfgtool -s zeigt den Status der Corosync-Links:
ip -br address
ip route
pvecm status
corosync-cfgtool -s
Bewerten Sie Erreichbarkeit und Latenz zwischen allen Nodes auch bei repräsentativer Storage-, Backup- und Migrationslast. Paketgrößen und MTU separat prüfen. Für Failover-Tests je einen geplanten Pfad ausfallen lassen, verbleibende Links und Quorum beobachten und Abbruchkriterien vorab vereinbaren. Produktive Ausfälle werden nicht ungeplant zu Testzwecken ausgelöst.
Dokumentieren Sie erwarteten und beobachteten Pfad, Quorum, Linkstatus, Last und offene Befunde. Der HA-Aufbau benötigt zusätzlich Fencing, zugänglichen Gast-Storage und ausreichende Restkapazität. Netzwerkredundanz allein erfüllt diese Bedingungen nicht. Für entfernte Standorte ist die Abgrenzung zum Multi-Site-DR relevant.
Provider-Anleitungen und Beratung
- Hetzner: vSwitch und Cluster-Netz für den dortigen Providerpfad.
- OVHcloud: vRack und Verkehrstrennung für die OVH-Topologie.
- IONOS: privates Cluster-Netz für die passende IONOS-Produktlinie.
Diese Spokes konkretisieren den jeweiligen Aufbau; sie ersetzen keine providerneutrale Kapazitäts- und Ausfallplanung.
Proxmox-Beratung klärt Architektur und Netzplan. Den providerbezogenen Aufbau ordnen Hetzner, OVHcloud und IONOS ein. Es werden keine ungeprüften Netzwerte oder Ausfallzeiten zugesagt.
