Proxmox Cluster-Architektur: Multi-Host-Setups richtig planen

Wenn Sie mehr als einen Proxmox-Host betreiben, stellt sich schnell die Frage: Wie organisiere ich meine Infrastruktur optimal? Dieser Artikel vergleicht die beiden Hauptansätze — den klassischen Proxmox VE Cluster und den neuen Proxmox Datacenter Manager — und gibt konkrete Architekturempfehlungen für verschiedene Szenarien.

Die zwei Welten: Cluster vs. Datacenter Manager

Proxmox bietet zwei fundamentale Ansätze für Multi-Host-Umgebungen:

Proxmox VE Cluster (seit Jahren etabliert)
Ein Verbund von Hosts, die über Corosync kommunizieren und als eine logische Einheit fungieren. Ideal für einen Standort mit niedrigen Latenzen.

Proxmox Datacenter Manager (PDM) (seit Dezember 2024, Alpha)
Eine übergeordnete Management-Schicht, die mehrere unabhängige Cluster oder Einzelhosts zentral verwaltet. Ideal für verteilte Standorte oder Multi-Tenant-Setups.

Proxmox VE Cluster im Detail

Wie funktioniert's?

Der Proxmox VE Cluster basiert auf dem Corosync Cluster Engine. Alle Nodes kommunizieren über UDP (Ports 5405-5412) und synchronisieren ihre Konfiguration in Echtzeit über das Proxmox Cluster File System (pmxcfs).

Kernkomponenten:

• Corosync: Cluster-Kommunikation und Quorum-Management
• pmxcfs: Verteiltes Dateisystem für Konfiguration
• HA Manager: Automatisches Failover bei Node-Ausfall
• Live Migration: VMs zwischen Nodes verschieben ohne Downtime

Vorteile

• Einheitliche Verwaltung: Alle Nodes über eine Web-GUI
• Live Migration: VMs im laufenden Betrieb verschieben
• High Availability: Automatisches Failover bei Hardware-Ausfall
• Shared Storage: Gemeinsamer Zugriff auf Ceph, NFS, iSCSI
• Cluster-weite Features: Firewall-Regeln, Backup-Jobs, Ressourcen-Pools
• Bewährte Technologie: Seit Jahren in Produktion erprobt

Nachteile

• Latenz-sensitiv: Corosync braucht < 2ms Latenz zwischen Nodes
• Kein WAN: Nicht für geografisch verteilte Standorte geeignet
• Quorum-Anforderung: Mindestens 3 Nodes für stabiles HA (oder QDevice)
• Hostname/IP fix: Nach Cluster-Beitritt nicht mehr änderbar
• Blast Radius: Fehlkonfiguration kann den gesamten Cluster betreffen

Anforderungen

Proxmox Datacenter Manager (PDM)

Was ist PDM?

Der Proxmox Datacenter Manager ist eine neue, übergeordnete Management-Schicht. Er verbindet sich via HTTPS mit beliebig vielen Proxmox VE Clustern oder Einzelhosts und bietet eine zentrale Übersicht.

Wichtig: PDM ersetzt nicht die PVE-Oberfläche — es ist eine zusätzliche Schicht darüber.

Vorteile

• Multi-Cluster-Management: Beliebig viele Cluster in einer UI
• Standort-unabhängig: Keine Latenz-Anforderungen (nur HTTPS)
• Inter-Cluster-Migration: VMs zwischen Clustern verschieben
• Skalierbar: Tests mit 5'000+ Clustern und 10'000+ VMs erfolgreich
• Geringer Ressourcenbedarf: 2 vCPU, 4 GB RAM reichen
• Moderne UI: Neue, performante Web-Oberfläche
• CLI & API: Vollständige Automatisierung möglich

Nachteile

• Alpha-Status: Noch nicht produktionsreif (Stand: Februar 2026)
• Kein HA für PDM selbst: Single Point of Failure
• Eingeschränkte Features: Noch nicht alle PVE-Funktionen verfügbar
• Keine Rechteverwaltung: Aktuell nur Admin-Zugang
• Zusätzliche Komponente: Weiterer Server zu betreiben

Wann PDM sinnvoll ist

• Mehrere unabhängige Proxmox-Installationen
• Geografisch verteilte Standorte
• Multi-Tenant-Umgebungen (verschiedene Kunden/Abteilungen)
• Managed Service Provider (MSP)
• Konsolidierte Übersicht über heterogene Umgebungen

Architekturvorschläge

Szenario 1: Kleines KMU (5-20 VMs)

Setup: 3 identische Server am gleichen Standort

┌─────────────────────────────────────────┐
│          Proxmox VE Cluster             │
│                                         │
│   ┌─────┐    ┌─────┐    ┌─────┐        │
│   │Node1│────│Node2│────│Node3│        │
│   └──┬──┘    └──┬──┘    └──┬──┘        │
│      │          │          │            │
│      └──────────┼──────────┘            │
│                 │                       │
│          ┌──────┴──────┐               │
│          │ ZFS Storage  │               │
│          │ + Replikation│               │
│          └─────────────┘               │
└─────────────────────────────────────────┘

Empfehlung:

• 3 Nodes für Quorum (oder 2 + externes QDevice)
• Storage: Bestehendes NAS (NFS/iSCSI) oder lokales ZFS + Replikation
• 1-10 Gbit Netzwerk zwischen Nodes
• Dediziertes VLAN für Cluster-Traffic

Pragmatischer Ansatz:
Wenn bereits ein NAS vorhanden ist (Synology, QNAP, TrueNAS), nutzen Sie es als Shared Storage. Damit funktioniert Live-Migration sofort. Kein NAS? Dann lokales ZFS mit Proxmox Replication — einfach und robust.

Kosten: ~CHF 15'000-30'000 Hardware + CHF 0-700/Jahr Proxmox Support

Szenario 2: Mittelstand (50-200 VMs)

Setup: Zwei Standorte mit je einem Cluster

┌─────────────────────┐     ┌─────────────────────┐
│   Standort Zürich   │     │   Standort Bern     │
│                     │     │                     │
│  ┌─────┬─────┬────┐│     │┌─────┬─────┬─────┐ │
│  │ N1  │ N2  │ N3 ││     ││ N1  │ N2  │ N3  │ │
│  └─────┴─────┴────┘│     │└─────┴─────┴─────┘ │
│         │          │     │         │          │
│    ZFS + Repl.     │     │    ZFS + Repl.     │
└─────────┬──────────┘     └─────────┬──────────┘
          │                          │
          │      Site-to-Site VPN    │
          └──────────┬───────────────┘
                     │
              ┌──────┴──────┐
              │  Proxmox    │
              │ Datacenter  │
              │  Manager    │
              └─────────────┘

Empfehlung:

• 2 unabhängige Cluster (kein Stretched Cluster!)
• PDM für zentrale Übersicht (sobald stabil)
• PBS an jedem Standort für lokale Backups
• Cross-Site Replikation für DR
• Separate Netzwerke für Storage, Cluster, VMs

Warum kein Stretched Cluster?
Corosync über WAN ist fragil. Latenz-Spikes führen zu Split-Brain-Situationen. Zwei unabhängige Cluster mit Replikation sind robuster.

Szenario 3: Enterprise / MSP

Setup: Mehrere Kunden/Abteilungen mit eigenen Clustern

┌────────────────────────────────────────────────────┐
│              Proxmox Datacenter Manager            │
│                  (Zentrale Verwaltung)             │
└───────────┬─────────────┬─────────────┬───────────┘
            │             │             │
    ┌───────┴───┐  ┌──────┴────┐  ┌────┴──────┐
    │ Cluster A │  │ Cluster B │  │ Cluster C │
    │ (Kunde 1) │  │ (Kunde 2) │  │ (Intern)  │
    │           │  │           │  │           │
    │ 5 Nodes   │  │ 3 Nodes   │  │ 8 Nodes   │
    │ 120 VMs   │  │ 45 VMs    │  │ 200 VMs   │
    └───────────┘  └───────────┘  └───────────┘

Empfehlung:

• Separate Cluster pro Mandant (Isolation, Compliance)
• PDM für Operations-Team
• Standardisierte Hardware (einfachere Wartung)
• Automatisierung via Terraform/Ansible
• Monitoring mit Prometheus + Grafana

Best Practices

Netzwerk-Design

Mindestens 3 separate Netzwerke:

1. Management-Netz: Web-GUI, SSH, API (1 Gbit)
2. Cluster-Netz: Corosync-Traffic (10 Gbit, dediziert)
3. Storage-Netz: Replikation/iSCSI/NFS (1-10 Gbit)
4. VM-Netz(e): Gast-Traffic (je nach Bedarf)

Redundanz:
Corosync unterstützt bis zu 8 Links. Nutzen Sie mindestens 2 auf unterschiedlichen physischen Pfaden.

Storage-Strategie

Die pragmatische Lösung für kleine Installationen:
Viele Unternehmen haben bereits ein NAS (Synology, QNAP, TrueNAS). Dieses kann via NFS oder iSCSI als Shared Storage für Proxmox dienen — fertig. Live-Migration funktioniert, Backups sind oft schon integriert. Kein Grund, komplexere Lösungen zu bauen.

Warum wir Ceph für KMU nicht empfehlen:
Ceph ist mächtig, aber komplex. Es braucht mindestens 3 Nodes, dediziertes 10 Gbit Netzwerk, und Tuning-Know-how. Bei falscher Konfiguration ist es langsamer als lokales Storage oder ein gutes NAS.

Quorum und HA

• 3 Nodes: Toleriert 1 Ausfall
• 5 Nodes: Toleriert 2 Ausfälle
• 2 Nodes + QDevice: Toleriert 1 Ausfall (QDevice auf separatem Host)

QDevice-Tipp:
Der QDevice kann auf einem Raspberry Pi oder einer kleinen VM an einem dritten Standort laufen. Er braucht nur minimale Ressourcen.

Backup-Strategie

┌─────────────────┐
│  Proxmox VE     │
│  Cluster        │
└────────┬────────┘
         │ Backup (nächtlich)
         ▼
┌─────────────────┐
│  Proxmox        │
│  Backup Server  │──────► Offsite (S3/NFS)
│  (lokal)        │
└─────────────────┘

3-2-1 Regel:

• 3 Kopien Ihrer Daten
• 2 verschiedene Medien/Systeme
• 1 Kopie offsite

Migration: Von Einzelhosts zum Cluster

Schritt-für-Schritt

1. Vorbereitung
2. Alle Hosts auf gleiche Proxmox-Version
3. Hostnames und IPs finalisieren (nicht mehr änderbar!)
4. NTP konfigurieren

5. Netzwerk-Konnektivität testen

6. Cluster erstellen
   bash # Auf Node 1 pvecm create mein-cluster

7. Nodes hinzufügen
   bash # Auf Node 2, 3, ... pvecm add <IP-von-Node-1>

8. Storage konfigurieren

9. Shared Storage einrichten (Ceph, NFS, etc.)

10. Oder: Lokalen Storage mit Replikation

11. HA aktivieren

12. HA-Gruppen definieren

13. VMs für HA markieren

14. Testen

15. Node kontrolliert herunterfahren
16. Failover verifizieren

Fazit: Welche Architektur für Sie?

Unser Rat: Starten Sie mit einem soliden 3-Node-Cluster am Hauptstandort. Erweitern Sie bei Bedarf um weitere Nodes oder Standorte. Der Proxmox Datacenter Manager wird interessant, sobald er aus dem Alpha-Stadium heraus ist — bis dahin funktionieren separate Cluster mit manueller Verwaltung oder Terraform/Ansible hervorragend.

Benötigen Sie Unterstützung bei der Planung Ihrer Proxmox-Architektur? Wir helfen Ihnen gerne — von der Konzeption bis zur Umsetzung.

→ Kostenloses Beratungsgespräch vereinbaren