# Proxmox Networking & Cluster-Design: Die Kunst der Hochverfügbarkeit

TL;DR / Management Summary Ein Proxmox-Cluster ist nur so stabil wie sein langsamstes Paket. Während VM-Traffic hohe Bandbreite benötigt, ist für den Corosync-Cluster-Traffic (Heartbeat) nur eines entscheidend: Ultra-niedrige Latenz. Wir separieren den Traffic konsequent in VLANs oder physische Netze und konfigurieren Redundanz auf allen Ebenen. Wer Corosync über ein überlastetes Backup-Netz schickt, riskiert Fencing-Loops und den GAU im Rechenzentrum.

# 1. Einführung: Die vier Schichten des Netzwerk-Traffics

In einer professionellen Proxmox-Umgebung unterscheiden wir vier funktionale Traffic-Typen. Die Vermischung dieser Typen auf einer einzigen Schnittstelle ist der häufigste Grund für Cluster-Instabilitäten.

1. Management Traffic: GUI-Zugriff, SSH, API. (1 Gbit/s ausreichend).
2. Cluster Traffic (Corosync): Der “Puls”. Extrem zeitkritisch. (1 Gbit/s ausreichend, aber dediziert!).
3. VM/LXC Traffic: Die Nutzdaten der Dienste. (10+ Gbit/s empfohlen).
4. Storage/Migration Traffic: Massendaten (Replikation, Backup, Ceph, iSCSI). (10+ Gbit/s zwingend).

# Cluster Netzwerk-Topologie (Mermaid)

graph TD
    subgraph S[Physical Switches]
        SW1[Core Switch A - Management/VM]
        SW2[Core Switch B - Management/VM]
        SW3[Cluster Switch A - Corosync/Storage]
        SW4[Cluster Switch B - Corosync/Storage]
    end

    subgraph P[Proxmox Node]
        NIC1[NIC 1 - LACP Bond 0]
        NIC2[NIC 2 - LACP Bond 0]
        NIC3[NIC 3 - Corosync Link 0]
        NIC4[NIC 4 - Corosync Link 1]
    end

    NIC1 --- SW1
    NIC2 --- SW2
    NIC3 --- SW3
    NIC4 --- SW4

    subgraph V[Virtual Stack]
        B[vmbr0 - VLAN Aware Bridge]
        V1[VM 101 - Web]
        V2[VM 102 - SQL]
    end

    NIC1 & NIC2 --> B
    B --> V1
    B --> V2

# 2. Virtual Networking: Bridges, Bonds & VLANs

Proxmox nutzt den bewährten Linux-Netzwerkstack (ifupdown2), um virtuelle Switche zu bauen.

# Linux Bridge (vmbr)

Die Bridge ist das zentrale Element. Sie fungiert als Layer-2 Switch innerhalb des Hosts.

• VLAN Aware: Wir empfehlen, Bridges “VLAN Aware” zu schalten. Dadurch können wir den VMs direkt in der GUI VLAN-Tags zuweisen, ohne für jedes VLAN eine eigene Bridge anlegen zu müssen.

# Network Bonding (LACP / Active-Backup)

Für Redundanz bündeln wir physische Schnittstellen.

• LACP (802.3ad): Bietet Lastverteilung und Failover. Erfordert jedoch Unterstützung am physischen Switch (Stacking oder VPC).
• Active-Backup: Die einfachste Form der Redundanz. Wenn Kabel A bricht, übernimmt Kabel B. Funktioniert mit jedem Switch.

# 3. Deep Dive: Corosync – Der Puls des Clusters

Corosync ist der Dienst, der sicherstellt, dass alle Knoten über den Zustand der anderen Bescheid wissen. Wenn Corosync keine Pakete mehr erhält, verliert der Knoten das Quorum (die Mehrheit).

# Das Heartbeat-Problem

Wenn die Latenz im Corosync-Netzwerk über einen Schwellenwert steigt (typischerweise > 50-100ms), denkt der Cluster, der Knoten sei tot.

• Fencing (Self-Fence): Ein Knoten, der das Quorum verliert, startet sich selbst hart neu (Watchdog), um sicherzustellen, dass er keine korrupten Daten auf geteilten Speicher schreibt.

# Corosync Redundanz-Mechanismus (Mermaid)

sequenceDiagram
    participant N1 as Node 1
    participant N2 as Node 2
    participant N3 as Node 3

    Note over N1,N3: Link 0: Primärer Pfad (Latenz: 0.5ms)
    N1->>N2: Heartbeat OK
    N2->>N3: Heartbeat OK
    
    Note over N1,N3: Link 1: Sekundärer Pfad (Latenz: 0.8ms)
    N1->>N2: Heartbeat OK
    
    Note right of N2: Kabelbruch an Link 0!
    N1--xN2: Timeout Link 0
    N1->>N2: Heartbeat via Link 1 (Failover)
    Note over N1,N2: Cluster bleibt 'Quorate'

# Best Practice: Multi-Link Corosync

Konfigurieren Sie immer mindestens zwei unabhängige Links für Corosync in der /etc/pve/corosync.conf:

logging {
  debug: off
  to_syslog: yes
}

nodelist {
  node {
    name: pve01
    nodeid: 1
    ring0_addr: 10.10.10.1  # Dediziertes Netz 1
    ring1_addr: 10.20.20.1  # Dediziertes Netz 2
  }
  ...
}

totem {
  cluster_name: PVE-CLUSTER
  config_version: 2
  interface {
    linknumber: 0
  }
  interface {
    linknumber: 1
  }
  ip_version: ipv4
  link_mode: passive
  secauth: on
  version: 2
}

# 4. Day-2 Operations: Netzwerk-Management im laufenden Betrieb

# ifupdown2 nutzen

Dank ifupdown2 können Netzwerkänderungen in Proxmox ohne Reboot übernommen werden.

• Aktion: Nach Änderung in der GUI auf “Apply Configuration” klicken.
• Check: Prüfen Sie danach immer mit ip a und bridge vlan show, ob die Konfiguration wie gewünscht aktiv ist.

# MTU 9000 (Jumbo Frames)

Für Storage-Traffic (iSCSI, Ceph) und Live-Migration ist die Erhöhung der MTU auf 9000 sinnvoll, um den CPU-Overhead zu reduzieren.

• Warnung: Jumbo Frames müssen End-to-End (NIC -> Switch -> Storage) konfiguriert sein. Ein einziger Switch mit MTU 1500 in der Kette führt zu Paketverlust und massiven Problemen.

# 5. Troubleshooting & “War Stories”

# Der “Broadcast-Sturm” GAU

Szenario: In einem Rechenzentrum wurde versehentlich ein Loop im Management-Netzwerk gesteckt. Symptom: Alle 12 Proxmox-Knoten starteten innerhalb von 2 Minuten gleichzeitig neu. Ursache: Das Management-Netzwerk wurde auch für Corosync genutzt. Der Broadcast-Sturm trieb die CPU-Last des Netzwerkstacks hoch und blockierte die Corosync-Pakete. Die Knoten verloren das Quorum und lösten den Hardware-Watchdog aus. Lösung: Physische Trennung des Corosync-Traffics auf dedizierte, ungetaggte Ports.

# Die “Multicast”-Falle

Szenario: Ein neuer Proxmox-Cluster wurde in einem bestehenden Switch-Stack installiert. Corosync verlor ständig die Verbindung. Ursache: Frühere Corosync-Versionen (vor PVE 6.x) nutzten Multicast. Der Switch hatte IGMP-Snooping aktiv, aber keinen IGMP-Querier im VLAN. Pakete wurden nach wenigen Minuten gefiltert. Lösung: Umstellung auf Unicast (Standard in modernen PVE-Versionen) oder Konfiguration eines IGMP-Queriers.

# 6. Experten-Checkliste für das Cluster-Netzwerk

• [ ] Corosync auf mindestens zwei physisch getrennten Links konfiguriert?
• [ ] VLAN Awareness auf der Haupt-Bridge aktiviert?
• [ ] MTU 9000 für Storage/Migration (falls unterstützt) aktiv?
• [ ] Statische IPs für alle Host-Schnittstellen (Management/Cluster)?
• [ ] No-Subscription Repos für ifupdown2 Updates gepflegt?

# Anhang: Referenzen & Links

• Proxmox VE: Cluster Manager (Official)
• Proxmox Wiki: Network Configuration
• Corosync High Level Architecture