Die passende Architektur, nicht automatisch die größte.
Ob ein einzelner Server reicht oder ein Cluster mit mehreren Nodes sinnvoll ist, hängt von Ihren Anforderungen an Verfügbarkeit, Ihrer Datenmenge und Ihrem Budget ab. Diese Seite erklärt die gängigen Architekturmodelle und Storage-Optionen, ohne eines davon als pauschale Lösung darzustellen.
Was bei der Wahl der Architektur zählt
- Verfügbarkeitsanforderungen wie kritisch ist ein Ausfall für Ihren Betrieb, und wie lange wäre er verkraftbar
- Datenmenge und Wachstum wie viel Speicher wird heute und in den nächsten Jahren gebraucht
- Performance-Anforderungen welche Anwendungen stellen hohe Anforderungen an Geschwindigkeit
- Anzahl vorhandener oder geplanter Hosts wie viele Server stehen zur Verfügung oder sind budgetiert
- Vorhandene Hardware lässt sich Bestehendes sinnvoll einbinden
- Netzwerk ist ein ausreichend schnelles Netzwerk für Cluster- oder Storage-Kommunikation vorhanden
- Budget Mehr Hosts und verteilter Storage bedeuten mehr Hardware- und Betriebsaufwand
- Wiederherstellungsziele wie schnell müssen Systeme im Ernstfall wieder verfügbar sein
Was Hochverfügbarkeit (HA) bei Proxmox bedeutet
Hochverfügbarkeit (HA) bedeutet bei Proxmox nicht automatisch einen unterbrechungsfreien Betrieb. Fällt ein Cluster-Node aus, werden die betroffenen virtuellen Maschinen auf einem verfügbaren Node neu gestartet, nicht nahtlos übernommen. Es entsteht also eine kurze Unterbrechung. Wie lange diese dauert, hängt unter anderem ab von der Fehlererkennung im Cluster, der Quorum-Entscheidung, dem verwendeten Storage, der Startzeit der jeweiligen VM, der Anwendung selbst und ihren Abhängigkeiten zu anderen Systemen. Wir vermeiden Formulierungen, die HA mit einem nahtlosen, unterbrechungsfreien Betrieb gleichsetzen.
Einzelhost (Single Node)
Ein einzelner Proxmox-Server für mehrere virtuelle Maschinen oder Container. Die einfachste und wirtschaftlichste Architektur, passend für Umgebungen, in denen ein Ausfall des Hosts über ein gutes Wiederherstellungskonzept statt über automatisiertes Failover abgefangen wird.
2-Node-Cluster
Zwei Proxmox-Server (Nodes) mit Replikation der VMs. Zwei Nodes allein bedeuten noch keine vollwertige Hochverfügbarkeit (HA): Bei einem Ausfall muss eindeutig feststehen, welcher Server weiterläuft, das sogenannte Quorum. Dafür wird häufig ein QDevice ergänzt. Ein QDevice stellt dem Cluster lediglich eine zusätzliche Stimme für die Quorum-Entscheidung bereit, es ersetzt keinen dritten Proxmox-Node und stellt selbst keine Rechen- oder Storage-Ressourcen für virtuelle Maschinen bereit.
Für die Datenreplikation zwischen den beiden Nodes kommt neben periodischer ZFS-Replikation auch DRBD in Frage, eine blockbasierte Spiegelung, die Änderungen laufend statt in Intervallen zwischen den Servern synchronisiert. Das kann den Datenverlust im Fehlerfall weiter reduzieren, bringt aber zusätzliche Komplexität mit. Beide Verfahren sind zeitversetzt beziehungsweise laufend, aber nicht mit synchronem Shared Storage gleichzusetzen, entsprechend vorsichtig sind daraus abgeleitete HA-Erwartungen zu bewerten. Ob sich das für Ihre Umgebung lohnt, prüfen wir im Einzelfall.
Bei produktiven Clustern empfiehlt sich zusätzlich eine redundante Netzwerkanbindung der Nodes.
3-Node-Cluster
Drei Proxmox-Server (Nodes) bilden ein klassisches Cluster mit stabiler Quorum-Situation, ganz ohne Zusatzgerät: Bei Ausfall eines Nodes haben die verbleibenden zwei weiterhin eine eindeutige Mehrheit. VMs können per Replikation oder gemeinsamem Storage (Shared Storage) auf einem anderen Node weiterlaufen.
3-Node-Cluster mit Ceph
Ceph verteilt die Daten über mehrere Nodes und kann dadurch hochverfügbaren Storage bereitstellen, ohne dass ein separates SAN nötig ist. Das erhöht die Ausfallsicherheit des Storages zusätzlich zur Ausfallsicherheit der Nodes. Dafür braucht die Umgebung eine ausreichende Anzahl an Laufwerken, passende Hardware, genügend CPU und RAM, ausreichend schnelle Netzwerkverbindungen zwischen den Servern und eine saubere Planung. Ceph ist nicht automatisch die beste Lösung: Für kleinere Umgebungen können lokales ZFS, ZFS-Replikation oder ein vorhandener Shared Storage sinnvoller sein.
Redundante Netzverbindungen zwischen den Nodes sind für das Storage-Netzwerk von Ceph wichtig.
Cluster mit vorhandenem SAN oder Shared Storage
Eine Migration auf Proxmox bedeutet nicht automatisch, dass bestehende Storage-Systeme ausgetauscht werden. Ist bereits ein Fibre-Channel-SAN, ein iSCSI- oder NFS-System oder ein anderer Shared Storage vorhanden, lässt er sich häufig weiterverwenden, statt einen neuen verteilten Storage aufzubauen. Ob Ihr vorhandenes System dafür geeignet ist, prüfen wir im Einzelfall.
Architektur- und Storage-Varianten im Vergleich
| Variante | Ausfallsicherheit | Aufwand |
|---|---|---|
| Einzelhost, ZFS lokal | Gering, abhängig vom Backup | Niedrig |
| 2-Node-Cluster, ZFS-Replikation oder DRBD, QDevice | Mittel, Quorum über QDevice | Mittel |
| 3-Node-Cluster, Shared Storage | Gut, stabiles Quorum | Mittel bis hoch |
| 3-Node-Cluster mit Ceph | Hoch, verteilter Storage | Hoch |
| Cluster mit vorhandenem SAN | Abhängig vom SAN-System | Abhängig von Anbindung |
Keine dieser Varianten ist pauschal die beste Lösung. Welche Architektur passt, hängt von Ihren Anforderungen, Ihrer Hardware und Ihrem Budget ab.
Netzwerk und Cluster-Kommunikation
Proxmox ist nicht nur ein Server- und Storage-Thema, das Netzwerkdesign gehört zur Gesamtarchitektur.
Cluster-Kommunikation und Corosync
Corosync ist die Kommunikationsschicht, über die Proxmox-Cluster-Nodes Status und Quorum-Entscheidungen austauschen. Sie braucht eine stabile, vorhersehbare Netzwerkverbindung: geringe Latenz und geringe Paketverluste sind wichtig, damit der Cluster Zustandsänderungen zuverlässig erkennt. Die Cluster-Kommunikation sollte nicht unkontrolliert mit stark schwankendem normalen Datenverkehr um Bandbreite konkurrieren, und bei produktiven Clustern sollte Redundanz eingeplant werden, etwa über logisch sauber getrennte oder redundante Netzpfade. Das bedeutet nicht zwingend physisch getrennte Switches, die passende Architektur richtet sich nach Verfügbarkeitsanforderungen und Größe der Umgebung.
Traffic-Trennung, Bandbreite und Switches
Dazu zählen redundante Netzwerkanbindungen der Hosts, wo passend über Bonding oder LACP, eine saubere VLAN-Trennung sowie die bewusste Planung unterschiedlicher Traffic-Arten: Storage-Netzwerk, Management-Netzwerk, VM-Datenverkehr, Backup-Traffic und Migration-Traffic. Nicht jede Umgebung benötigt vollständig getrennte physische Netze, aber die Traffic-Arten sollten bewusst geplant statt zufällig gemischt werden.
Welche Bandbreite sinnvoll ist, hängt von Architektur und Last ab. 1 Gbit/s kann für kleine, einfache Umgebungen ausreichend sein, bei Live-Migration, Backups, Storage-Traffic oder Ceph kann deutlich mehr sinnvoll sein, bei größeren oder storageintensiven Umgebungen etwa 10 Gbit/s oder mehr. Eine starre Mindestbandbreite geben wir nicht pauschal vor, bei Ceph haben Bandbreite und Latenz aber erheblichen Einfluss auf Performance und Stabilität.
Bei professionellen Umgebungen kann eine zentral verwaltbare Switch-Infrastruktur sinnvoll sein: zentrale VLAN-Konfiguration, einsehbarer Portstatus, sichtbare Link-Ausfälle, nachvollziehbare Trunks und LACP-Zustände sowie dokumentierbare Änderungen erleichtern das Troubleshooting. Ein bestimmter Hersteller ist dafür nicht zwingend erforderlich, Transparenz auf der Netzebene ist der wichtige Teil.
Proxmox VE Cluster und Datacenter Manager: zwei unterschiedliche Ebenen
Werden mehrere Cluster, einzelne Nodes oder mehrere Proxmox Backup Server an unterschiedlichen Standorten betrieben, stellt sich zusätzlich die Frage nach einer übergeordneten Verwaltungsebene.
Proxmox VE Cluster
Ein Proxmox-VE-Cluster verbindet Nodes technisch zu einem gemeinsamen Cluster. Dazu gehören Themen wie Quorum, Corosync, Hochverfügbarkeit (HA), eine gemeinsame Cluster-Konfiguration, Storage und die Live-Migration von VMs zwischen Nodes.
Proxmox Datacenter Manager
Der Proxmox Datacenter Manager liegt eine Ebene darüber. Er kann mehrere voneinander unabhängige Cluster, Einzel-Nodes und Proxmox Backup Server in einer zentralen Verwaltungsoberfläche zusammenführen, statt jede Umgebung ausschließlich separat zu administrieren.
Wichtig für die Einordnung: Ein Datacenter Manager macht aus mehreren unabhängigen Clustern nicht automatisch ein einziges großes Proxmox-Cluster. Jede Umgebung bleibt technisch eigenständig, er bietet lediglich eine zusätzliche, zentrale Sicht und Steuerungsebene darüber.
Anwendungsbeispiel: Standorte mit eigenständigen Proxmox-Clustern, weitere Systeme im Rechenzentrum oder in der Cloud und ein eigener Backup-Standort, zentral im Blick über den Proxmox Datacenter Manager.
- Updates zentral im Überblick verfügbare Updates angebundener Proxmox-VE- und PBS-Systeme im Blick, ersetzt aber keine geplante, geprüfte und priorisierte Update-Strategie mit eigenen Wartungsfenstern
- Monitoring und Transparenz zentrale Sicht auf Zustand und Verfügbarkeit der Proxmox-Infrastruktur, kein Ersatz für weitergehende Monitoring- oder Alarmierungssysteme
- Rollen und Berechtigungen zentrale, rollenbasierte Rechteverwaltung für mehrere Administratoren oder Teams, ohne pauschale Compliance-Versprechen
- Ceph-Monitoring zentraler Überblick über Ceph-Cluster mehrerer angebundener Umgebungen, ohne Ceph automatisch aufzubauen oder zu optimieren
Aus der Praxis
Wir haben beides umgesetzt: einen 3-Node-Cluster mit Ceph für einen Logistikstandort mit rund 20 VMs, und einen 2-Node-Cluster mit redundantem Shared Storage für einen weiteren Standort. Welche Architektur passt, hängt von den Anforderungen ab, nicht von einer pauschalen Empfehlung. Beispiele aus unserer Projektarbeit ansehen.
Zur Infrastruktur gehört mehr als Storage
Zur Infrastruktur gehört auch ein passendes Wiederherstellungskonzept. Mehr dazu unter Backup und Recovery. Läuft bei Ihnen bereits eine Proxmox-Umgebung und Sie sind sich bei der Architektur unsicher, prüfen wir das im Rahmen eines Health Checks.
Gut zu wissen
Wie viele Server benötigt ein Proxmox-Cluster?
Ein Cluster ist technisch ab zwei Servern (2-Node-Cluster) möglich, für eine stabile Quorum-Situation ohne Zusatzgerät sind meist drei Server (3-Node-Cluster) üblich. Wie viele Server sinnvoll sind, hängt von Ihren Anforderungen an Verfügbarkeit ab.
Braucht man zwingend drei Hosts?
Nein. Ein einzelner Server (Einzelhost) reicht für viele kleinere Umgebungen aus. Ein 3-Node-Cluster ist eine von mehreren möglichen Architekturen, nicht die einzig richtige.
Kann ein Cluster mit zwei Hosts sinnvoll sein?
Ja, in Kombination mit einem QDevice als zusätzlicher Stimme für das Quorum. Ohne QDevice ist die Quorum-Situation bei einem 2-Node-Cluster technisch heikel und muss sorgfältig geplant werden.
Was ist ein QDevice?
Ein QDevice stellt dem Cluster eine zusätzliche Stimme für die Quorum-Entscheidung bereit. Es ersetzt keinen dritten Proxmox-Node und stellt selbst keine Rechen- oder Storage-Ressourcen für virtuelle Maschinen bereit, sondern dient ausschließlich der zuverlässigen Cluster-Entscheidung bei einem Hostausfall.
Ist Ceph notwendig?
Nein. Ceph ist eine von mehreren Storage-Optionen und sinnvoll, wenn verteilter, hochverfügbarer Storage über mehrere Nodes gebraucht wird. Für kleinere Umgebungen sind lokaler ZFS-Storage oder ZFS-Replikation oft ausreichend.
Kann ein vorhandenes SAN weiterverwendet werden?
In vielen Fällen ja, je nach Anbindung über Fibre Channel, iSCSI oder NFS. Eine Migration auf Proxmox bedeutet nicht automatisch, dass bestehende Storage-Systeme ausgetauscht werden müssen. Das prüfen wir anhand des vorhandenen Systems.
Bedeutet Hochverfügbarkeit einen unterbrechungsfreien Betrieb?
Nein. Bei einem Hostausfall werden betroffene virtuelle Maschinen auf einem verfügbaren Cluster-Node neu gestartet, das bedeutet eine kurze Unterbrechung, keinen nahtlosen Übergang. Wie lange diese Unterbrechung dauert, hängt unter anderem von Fehlererkennung, Quorum, Storage und der Startzeit der jeweiligen Anwendung ab.
Unsicher, welche Architektur passt?
Im Erstgespräch besprechen wir Ihre Anforderungen und geben Ihnen eine erste Einschätzung. Eine genauere Bestandsaufnahme vereinbaren wir bei Bedarf gesondert.