Proxmox Cluster-Netzwerk richtig planen: Corosync, Migration, Storage und Management

Ein Proxmox-Cluster, in dem alle Dienste über ein einziges Netzwerk laufen, funktioniert — bis er es nicht mehr tut. Sobald ein Ceph-Rebalancing die Bandbreite sättigt, Live-Migrationen stocken und Corosync den Heartbeat verliert, steht der gesamte Cluster. Professionelles Netzwerk-Design trennt die verschiedenen Traffic-Typen und verhindert genau diese Szenarien.

Die vier Traffic-Typen im Proxmox-Cluster

Jeder Proxmox-Cluster produziert vier grundlegend verschiedene Arten von Netzwerkverkehr:

Traffic-Typ	Charakteristik	Anforderung
Corosync	Kleine Pakete, extrem latenzempfindlich	< 2 ms RTT, dediziertes Netz
Migration	Burst-Traffic, hohe Bandbreite	10 Gbit/s+, darf andere Netze nicht stören
Storage	Konstanter Durchsatz, IOPS-sensitiv	10–25 Gbit/s, Jumbo Frames
Management	Gering, aber kritisch	Erreichbarkeit, Sicherheit

Die goldene Regel: Corosync-Traffic darf niemals mit Storage- oder Migrations-Traffic konkurrieren. Ein verspäteter Heartbeat führt zu einem Fencing-Event — und damit zum ungewollten Neustart von VMs.

Corosync-Ring: Das Nervensystem des Clusters

Corosync ist das Cluster-Kommunikationsprotokoll, das den Zustand aller Knoten überwacht. Es sendet regelmäßig Heartbeat-Pakete und erwartet Antworten innerhalb enger Zeitfenster.

Dediziertes Corosync-Netzwerk

Für Corosync genügt ein einfaches Layer-2-Netz ohne Router oder Firewall:

# /etc/network/interfaces — Corosync-Interface
auto ens18f1
iface ens18f1 inet static
    address 10.10.10.1/24
    mtu 1500

Auf den weiteren Nodes analog mit 10.10.10.2/24 und 10.10.10.3/24. Verwenden Sie ein separates physisches Interface oder ein dediziertes VLAN.

Corosync mit zwei Ringen (Redundanz)

Proxmox unterstützt seit PVE 6 mehrere Corosync-Links. Konfigurieren Sie immer mindestens zwei Links auf getrennten physischen Pfaden:

# Corosync-Links anzeigen
pvecm status | grep -A5 "link"

# Zweiten Link hinzufügen (auf allen Nodes gleichzeitig)
pvecm link update 1 --address 10.10.20.1

Der erste Link (Link 0) nutzt z. B. das 10.10.10.0/24-Netz über Switch A, der zweite Link (Link 1) das 10.10.20.0/24-Netz über Switch B. Fällt ein Switch aus, bleibt der Cluster funktionsfähig.

Corosync-Tuning

Die Standard-Timeouts sind für die meisten Umgebungen passend, können aber bei instabilen Netzen angepasst werden:

# /etc/pve/corosync.conf (Auszug)
totem {
    token: 3000          # Timeout in ms (Standard: 1000)
    token_retransmits_before_loss_const: 6
    join: 60
    consensus: 3600      # muss > 1.2 * token sein
}

Vorsicht: Höhere Timeouts bedeuten langsamere Fehlererkennung. Erhöhen Sie Werte nur, wenn die Netzwerklatenz dies erfordert.

Migration-Network: Bandbreite für Live-Migration

Live-Migration verschiebt den gesamten RAM-Inhalt einer VM über das Netzwerk. Eine VM mit 32 GB RAM erzeugt entsprechend viel Traffic. Ohne dediziertes Migrationsnetz blockiert dieser Transfer andere Dienste.

Migration-Network konfigurieren

In der Proxmox-Weboberfläche: Datacenter > Options > Migration Settings:

Migration Network:  10.10.30.0/24
Migration Type:     secure (verschlüsselt)

Die Netzwerkkonfiguration auf jedem Node:

# /etc/network/interfaces — Migration-Interface
auto ens18f0
iface ens18f0 inet static
    address 10.10.30.1/24
    mtu 9000

Bandbreite begrenzen

Um zu verhindern, dass eine Migration das gesamte Netzwerk sättigt, setzen Sie ein Bandbreitenlimit:

# Migration-Bandbreite auf 5 Gbit/s begrenzen
pvesh set /cluster/options --migration '{"network":"10.10.30.0/24","type":"secure","bandwidth_limit":5120}'

Der Wert 5120 entspricht 5120 MiB/s. Bei einem 10-Gbit/s-Link lässt das genug Headroom für parallele Migrationen.

Storage-Network: Ceph und iSCSI

Das Storage-Network trägt den konsistenten Datenverkehr zwischen Nodes (bei Ceph) oder zum externen Storage (iSCSI, NFS). Hier zählt vor allem Durchsatz und geringe Latenz.

Ceph-Netzwerk konfigurieren

Ceph unterscheidet zwischen Public Network (Client-Zugriff) und Cluster Network (OSD-Replikation). Das Cluster Network trägt den Replikations-Traffic und sollte immer dediziert sein:

# /etc/pve/ceph.conf
[global]
public_network = 10.10.40.0/24
cluster_network = 10.10.50.0/24
ms_bind_ipv4 = true

Die Netzwerk-Interfaces:

# Storage Public Network
auto ens19f0
iface ens19f0 inet static
    address 10.10.40.1/24
    mtu 9000

# Storage Cluster Network (OSD-Replikation)
auto ens19f1
iface ens19f1 inet static
    address 10.10.50.1/24
    mtu 9000

MTU 9000 (Jumbo Frames) für Storage

Jumbo Frames mit MTU 9000 reduzieren den CPU-Overhead pro übertragenem Byte erheblich. Bei Storage-Traffic, der aus vielen großen sequentiellen Blöcken besteht, bringt das 10–20 % mehr Durchsatz.

Wichtig: MTU 9000 muss auf dem gesamten Pfad konfiguriert sein — Interfaces, Switches und ggf. Router. Ein einziges Gerät mit MTU 1500 fragmentiert die Pakete und verschlechtert die Performance.

# MTU auf allen Switches prüfen
for host in switch1 switch2 switch3; do
    ssh admin@$host "show interface mtu"
done

# MTU testen (von Node zu Node)
ping -M do -s 8972 10.10.40.2

Der Wert 8972 ergibt sich aus 9000 (MTU) - 20 (IP-Header) - 8 (ICMP-Header). Funktioniert der Ping, sind Jumbo Frames korrekt konfiguriert.

iSCSI-Anbindung

Für externes Storage über iSCSI (z. B. TrueNAS als Target) nutzen Sie das gleiche Storage-Netzwerk:

# /etc/network/interfaces — iSCSI Multipath
auto ens19f0
iface ens19f0 inet static
    address 10.10.40.1/24
    mtu 9000

auto ens19f1
iface ens19f1 inet static
    address 10.10.41.1/24
    mtu 9000

Mit multipathd und open-iscsi konfigurieren Sie Multipath-I/O für Redundanz und Lastverteilung.

Management-VLAN

Das Management-Netzwerk dient dem Zugriff auf die Proxmox-Weboberfläche, SSH und API. Es sollte in einem eigenen VLAN liegen und durch Firewall-Regeln geschützt sein.

# /etc/network/interfaces — Management Bridge
auto vmbr0
iface vmbr0 inet static
    address 10.10.1.1/24
    gateway 10.10.1.254
    bridge-ports ens18f0
    bridge-stp off
    bridge-fd 0

Zugriffsbeschränkung

Beschränken Sie den Zugriff auf das Management-Interface über die Proxmox-Firewall:

# Nur bestimmte Subnetze dürfen auf die Weboberfläche zugreifen
pvesh create /nodes/pve1/firewall/rules \
  --action ACCEPT --type in --source 10.10.1.0/24 \
  --dest 10.10.1.1 --dport 8006 --proto tcp

Bonding und LACP

Für Redundanz und höhere Bandbreite fassen Sie physische Interfaces zu Bonds zusammen. LACP (802.3ad) verteilt Traffic über mehrere Links:

# /etc/network/interfaces — LACP Bond
auto bond0
iface bond0 inet manual
    bond-slaves ens18f0 ens18f1
    bond-mode 802.3ad
    bond-miimon 100
    bond-xmit-hash-policy layer3+4
    mtu 9000

# Bridge über den Bond
auto vmbr1
iface vmbr1 inet static
    address 10.10.40.1/24
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0
    mtu 9000

Hash-Policy: layer3+4 verteilt Traffic anhand von IP-Adressen und Ports. Das funktioniert gut für VM-Traffic, da jede VM eigene IPs hat. Für Ceph-Traffic (wenige IPs, viele Verbindungen) kann layer2+3 besser sein.

LACP auf dem Switch konfigurieren

Der Switch muss die Gegenseite des LACP-Bonds bereitstellen. Beispiel für einen managed Switch:

# Cisco-Syntax (Beispiel)
interface range GigabitEthernet0/1-2
  channel-group 1 mode active
  
interface Port-channel1
  switchport mode trunk
  mtu 9000

Beispiel-Topologie: 3-Node-Cluster

Eine bewährte Topologie für einen produktiven 3-Node-Cluster mit Ceph:

Node 1 (pve1):
  ens18f0 → Management VLAN 10    (10.10.1.1/24)
  ens18f1 → Corosync Link 0       (10.10.10.1/24)
  ens19f0 → Ceph Public            (10.10.40.1/24, MTU 9000)
  ens19f1 → Ceph Cluster           (10.10.50.1/24, MTU 9000)
  ens20f0 → Migration              (10.10.30.1/24, MTU 9000)
  ens20f1 → Corosync Link 1       (10.10.20.1/24)

Switch A: Management, Corosync L0, Migration
Switch B: Corosync L1, Ceph Public, Ceph Cluster

Durch die Verteilung auf zwei Switches überlebt der Cluster den Ausfall eines einzelnen Switches.

Beispiel-Topologie: 2-Node-Cluster (Budget)

Nicht jedes Unternehmen hat sechs NICs pro Node. Eine minimale, aber funktionale Konfiguration mit vier NICs:

Node 1 (pve1):
  ens18f0 → VLAN 10: Management    (10.10.1.1/24)
             VLAN 11: Corosync L0   (10.10.10.1/24)
  ens18f1 → VLAN 12: Corosync L1   (10.10.20.1/24)
  bond0 (ens19f0 + ens19f1) → Storage + Migration (10.10.40.1/24, MTU 9000)

Hier teilen sich Management und Corosync L0 ein physisches Interface über VLANs. Das funktioniert, solange das Management-Netz wenig Traffic hat.

Häufige Fehler und deren Vermeidung

1. Corosync über das Storage-Netz: Ein Ceph-Recovery sättigt das Netz, Corosync verliert den Heartbeat, Nodes werden gefenced. Immer trennen.

2. MTU-Mismatch: Ein Switch mit MTU 1500 im Storage-Pfad fragmentiert Jumbo Frames. Performance bricht ein, aber es gibt keine offensichtliche Fehlermeldung — nur unerklärlich langsamen Storage.

3. Kein zweiter Corosync-Link: Ein einzelner Link ist ein Single Point of Failure. Ein kurzer Kabelwackler führt zu einem Split-Brain-Szenario.

4. Spanning Tree auf Bridge-Ports: Proxmox-Bridges brauchen kein STP (bridge-stp off). Aktiviertes STP verursacht 30–50 Sekunden Verzögerung beim Link-Up.

5. Bond ohne LACP-Gegenstelle: Ein Bond im Mode 802.3ad ohne konfigurierte LACP-Gruppe auf dem Switch führt dazu, dass nur ein Link aktiv ist.

Netzwerk-Monitoring

Überwachen Sie die Netzwerk-Performance kontinuierlich:

# Bandbreite pro Interface prüfen
iftop -i ens19f0

# Corosync-Status und Latenz
corosync-cfgtool -s

# Bond-Status überprüfen
cat /proc/net/bonding/bond0

Integrieren Sie diese Checks in Ihr Monitoring-System (z. B. Checkmk, Zabbix oder DATAZONE Control), um Probleme frühzeitig zu erkennen.

Fazit

Ein durchdachtes Netzwerk-Design ist die Grundlage für einen stabilen Proxmox-Cluster. Die Investition in dedizierte Netze für Corosync, Storage und Migration zahlt sich beim ersten Ceph-Recovery oder bei der ersten gleichzeitigen Migration mehrerer VMs aus. Planen Sie das Netzwerk vor der Cluster-Installation — nachträgliche Änderungen erfordern Wartungsfenster und bergen Risiken.