Proxmox Fachwissen · Cluster & HA
Proxmox Cluster und Hochverfügbarkeit richtig planen.
Ein Proxmox-Cluster wird nicht allein dadurch hochverfügbar, dass mehrere Server verbunden sind. Erst das abgestimmte Zusammenspiel aus Quorum, Fehlerdomänen, Ressourcenreserven, Netzwerk, Storage, Backup und Betriebsprozessen schafft eine Plattform, die definierte Ausfälle kontrolliert verkraftet.
Architektur vor Installation
Hochverfügbarkeit beginnt mit einem messbaren Verfügbarkeitsziel.
Vor der Hardwareauswahl muss geklärt werden, welche Systeme nach einem Hostausfall automatisch neu starten sollen, welche Unterbrechung fachlich tolerierbar ist und wie viel Leistung im Fehlerfall noch benötigt wird. Ein Cluster kann einen defekten Node erkennen und ausgewählte virtuelle Maschinen auf verbleibenden Nodes starten. Er ersetzt jedoch weder eine anwendungsspezifische Hochverfügbarkeit noch ein Backup und verhindert nicht jede Betriebsunterbrechung.
AOIT ordnet Workloads deshalb nach Kritikalität, Abhängigkeiten und Wiederanlaufreihenfolge. Domain Controller, Datenbanken, Lizenzdienste, Dateiablagen und Fachanwendungen werden nicht isoliert betrachtet. Aus dieser Bewertung entstehen HA-Gruppen, Startreihenfolgen, Wartungsregeln und ein realistischer Ressourcenpuffer für den Ausfall eines Nodes.
RTO
Wie schnell muss ein Dienst nach einem Infrastrukturfehler wieder verfügbar sein?
RPO
Welcher Datenstand darf bei Replikation oder Wiederherstellung maximal fehlen?
Fehlerdomäne
Welche Komponenten teilen Strom, Netzwerk, Storage, Rack oder Standort?
Restkapazität
Können die verbleibenden Nodes die priorisierten Systeme zuverlässig übernehmen?
Clusterentscheidungen
Quorum verhindert widersprüchliche Zustände und unkontrollierte Doppelstarts.
Proxmox nutzt Corosync für Clusterkommunikation und Mehrheitsentscheidungen. Verliert ein Teil des Clusters den Kontakt zur Mehrheit, darf er kritische Änderungen und HA-Aktionen nicht einfach fortsetzen. Diese Schutzfunktion reduziert das Risiko eines Split-Brain-Szenarios, in dem getrennte Clusterteile denselben Dienst gleichzeitig kontrollieren wollen.
Drei stimmberechtigte Nodes sind für viele mittelständische HA-Umgebungen ein gut verständliches Grunddesign. Zwei Nodes allein besitzen bei einer Trennung keine eindeutige Mehrheit. Ein QDevice kann in passenden Zwei-Node-Szenarien eine zusätzliche Stimme bereitstellen, muss aber unabhängig und zuverlässig erreichbar sein. Die Entscheidung ist keine Abkürzung zur Hochverfügbarkeit, sondern Teil einer bewusst dokumentierten Quorum-Architektur.
Redundante Datenwege
Management, Corosync, Storage, VM-Verkehr und Backup sauber trennen.
Clusterkommunikation benötigt niedrige, stabile Latenz und darf nicht durch große Backups, Storage-Rebalancing oder produktive Lastspitzen verdrängt werden. AOIT plant daher logische und – wo erforderlich – physische Trennungen für Management, Corosync, Storage, virtuelle Maschinen und Sicherungsverkehr. Bonding, redundante Switches und getrennte Strompfade reduzieren gemeinsame Ausfallursachen.
Entscheidend ist nicht die Anzahl der VLANs, sondern die Ende-zu-Ende-Betrachtung. Zwei Netzwerkkarten am Server helfen wenig, wenn beide am selben Switch, an derselben Stromversorgung oder an einer einzelnen Uplink-Strecke enden. Monitoring muss Paketverlust, Latenz, Interfacefehler und den Zustand der redundanten Pfade sichtbar machen, bevor Corosync oder Storage instabil werden.
Corosync
Latenzarme, priorisierte Clusterkommunikation mit redundanten Pfaden.
Storage
Planbare Bandbreite für Ceph, NFS, iSCSI oder Replikation.
VM-Netze
Segmentierte Produktionszonen mit kontrollierten Übergängen.
Management
Geschützte Administration, API, Monitoring und Jump-Host-Zugriff.
HA im Alltag
Automatischer Neustart braucht Reserven, Regeln und regelmäßige Tests.
HA-Ressourcen werden nur dann zuverlässig auf einem anderen Node gestartet, wenn dort CPU, Arbeitsspeicher, Netzwerk und Storage verfügbar sind. Eine Plattform, die im Normalbetrieb dauerhaft nahezu vollständig ausgelastet ist, besitzt im Fehlerfall keine belastbare Reserve. Kapazitätsplanung berücksichtigt deshalb den größten angenommenen Einzelausfall und priorisiert geschäftskritische Systeme gegenüber weniger wichtigen Workloads.
Wartungsfenster, Node-Neustarts, Firmware-Updates und Storage-Arbeiten werden mit HA-Regeln koordiniert. Vor produktiven Tests werden aktuelle Backups, Konsistenz der Anwendungen und ein klarer Abbruchweg geprüft. Geplante Failover-Übungen zeigen, ob Gäste tatsächlich am richtigen Ort starten, Netzwerkpfade funktionieren und abhängige Dienste in der vorgesehenen Reihenfolge verfügbar werden.
AOIT verbindet technische Alarmierung mit dokumentierten Zuständigkeiten. Clusterzustand, Quorum, Replikation, Storage-Gesundheit, SMART-Werte, Kapazität und fehlgeschlagene Tasks werden überwacht. Ereignisse erhalten eine Bewertung und einen geregelten Bearbeitungsweg, statt lediglich E-Mails ohne Verantwortlichen zu erzeugen.
AOIT Vorgehensweise
Vom Bestandsbild zum betreibbaren Proxmox-Cluster.
Der Einstieg beginnt mit Workload- und Abhängigkeitsanalyse, Leistungswerten, vorhandenen Wartungsfenstern und den Erwartungen an Wiederanlauf. Danach entstehen Zielarchitektur, Stückliste, Netzwerk- und Storage-Design, Namens- und Rollenmodell sowie ein Test- und Migrationsplan. Erst nach technischer Abnahme werden produktive Workloads in kontrollierten Wellen überführt.
Zum Projektabschluss gehören Betriebsdokumentation, Notfallzugänge, Monitoring, Updateverfahren, Backup, Restore-Tests und eine eindeutige Aufgabenverteilung. AOIT kann die Plattform anschließend vollständig betreiben oder gemeinsam mit der internen IT als Co-Managed-Modell weiterführen.
Häufige Fragen
Antworten zur Planung und zum Betrieb.
Braucht ein Proxmox-HA-Cluster immer drei Nodes?
Drei stimmberechtigte Nodes sind ein verbreitetes, gut verständliches Design. Andere Topologien sind möglich, benötigen aber eine bewusste Quorum-, Ausfall- und Ressourcenplanung. Ein QDevice kann in ausgewählten Zwei-Node-Szenarien helfen, ersetzt jedoch keinen dritten Compute-Node.
Ist Live Migration dasselbe wie Hochverfügbarkeit?
Nein. Live Migration verschiebt eine laufende VM geplant zwischen Nodes. HA reagiert auf definierte Ausfälle und startet eine Ressource gegebenenfalls auf einem anderen Node neu. Beide Funktionen haben unterschiedliche Voraussetzungen und Risiken.
Kann Proxmox HA ein Backup ersetzen?
Nein. HA schützt vor bestimmten Infrastrukturfehlern, nicht vor versehentlichem Löschen, logischen Fehlern, Ransomware oder einem kompletten Standortausfall. Dafür sind unabhängige Backups und geprüfte Restore-Verfahren notwendig.
Wie wird ein Cluster sicher gewartet?
Wartung erfolgt nodeweise mit geprüften Backups, ausreichender Restkapazität, kontrollierter Migration oder Abschaltung, klaren Abbruchkriterien und einer anschließenden Funktionskontrolle von Cluster, Storage, Netzwerk und Gästen.
Technische Quellen
Die konkrete Architektur wird anhand Ihrer Workloads, Schutzanforderungen und vorhandenen Infrastruktur geplant. Diese Primärquellen dienen als technische Orientierung.
Nächster Schritt
Proxmox-Architektur mit klaren Betriebszielen planen.
Wir ordnen Ausgangslage, Risiken, Zielarchitektur und Migrationsweg ein – nachvollziehbar und passend zu Ihrem Unternehmen.