Proxmox-HA-Fehler: 10 Failover-Probleme, die Sie vermeiden sollten

Proxmox HA versagt am schmerzhaftesten, wenn der Cluster technisch für Hochverfügbarkeit konfiguriert ist, das umgebende Design das erwartete Failover aber nicht tragen kann. Die häufigen Probleme sind Quorum, Storage-Zugriff, Fencing, Placement-Regeln, Kapazität und ungetestete Anwendungs-Recovery.

Mit Stand August 2026 empfiehlt Proxmox mindestens drei Cluster-Nodes für ein zuverlässiges Quorum, und der HA-Manager nutzt Watchdog-basiertes Fencing, um zu verhindern, dass ein ausgefallener oder isolierter Node weiterhin denselben Workload ausführt. Diese beiden Details erklären, warum ein Cluster, der auf einem Diagramm redundant aussieht, in der Praxis trotzdem schwer versagen kann.

Was schützt Proxmox HA eigentlich?

Proxmox High Availability verwaltet ausgewählte virtuelle Maschinen und Container automatisch, sodass sie nach einem Host-Ausfall auf einem anderen gesunden Node neu gestartet werden können. Es macht das Gast-Betriebssystem oder die Anwendung innerhalb dieses Gasts nicht sofort verfügbar.

Diese Unterscheidung zählt.

Wenn eine Datenbank-VM vier Minuten zum Booten braucht und weitere drei Minuten, bis die Datenbank die Health Checks besteht, ist der Anwendungsausfall länger als die Ausfallerkennungszeit des Clusters für den Host. Die Proxmox-Dokumentation beschreibt typische HA-Fehlererkennung und Failover mit rund zwei Minuten. Das ist nur ein Teil des Recovery-Pfads.

Wenn Sie noch entscheiden, wie klein ein HA-Design vernünftigerweise sein kann, lesen Sie Ceph, HA und der Minimum Viable Cluster für KMU.

1. Warum ist ein Proxmox-HA-Cluster mit zwei Nodes riskant?

Ein Zwei-Node-Cluster verliert die einfache Mehrheit, sobald ein Node verschwindet. Proxmox empfiehlt mindestens drei Nodes für ein zuverlässiges Quorum, weil die verbleibenden Nodes genug Stimmen brauchen, um zu bestimmen, welche Seite einer Partition handeln darf.

Ein QDevice kann einem Zwei-Node-Cluster eine externe Stimme hinzufügen. Das kann ein nützliches Design für kleine Umgebungen sein, verwandelt aber nicht auf magische Weise zwei Server in drei Server. Sie haben weiterhin nur zwei Compute-Nodes, und ein Ausfall kann alle Workloads auf einer einzigen Maschine konzentrieren.

Der praktische Fehler besteht darin, nur für Quorum zu planen und die Kapazität zu vergessen.

Wenn Node A und Node B jeweils mit 70 Prozent Arbeitsspeicherauslastung laufen, gibt es beim Ausfall eines der beiden keinen sicheren Ort, um alles neu zu starten. Das Quorum kann gesund sein, während die Kapazität es nicht ist.

Der Leitfaden zum Proxmox-Zwei-Node-Quorum geht tiefer auf diesen Fehlermodus ein.

2. Was passiert, wenn der Ziel-Node den VM-Storage nicht sehen kann?

HA kann eine VM nicht erfolgreich auf einem Node neu starten, der keinen Zugriff auf ihre Disks hat. Das klingt offensichtlich, aber asymmetrischer Storage-Zugriff ist einer der einfachsten Wege, einen Cluster zu bauen, der im Normalbetrieb funktioniert und im Notfall versagt.

Stellen Sie sich vier Nodes vor. Drei können ein iSCSI-LUN sehen. Der vierte ist reiner Compute-Node und nutzt ein anderes Storage-System. Wenn ein HA-Workload auf diesem LUN auf dem vierten Node landen darf, kann die Placement-Entscheidung für diese VM ungültig werden.

Die Lösung ist architektonisch. Jeder infrage kommende Failover-Node muss Zugriff auf den Storage haben, den dieser Workload braucht, oder Ihre HA-Placement-Policy muss den Workload von Nodes fernhalten, die ihn nicht ausführen können.

Warten Sie nicht auf einen Stromausfall, um zu entdecken, dass sich die Storage-Sichtbarkeit zwischen Nodes unterscheidet.

3. Warum ist Fencing wichtiger als schnelles Failover?

Fencing schützt Daten, indem es sicherstellt, dass der ausgefallene oder isolierte Node keine HA-Ressourcen mehr ausführen darf, bevor ein anderer Node sie neu startet. Proxmox nutzt Watchdog-basiertes Fencing als Teil seiner HA-Architektur.

Das gefährliche Szenario ist Split-Brain. Eine Seite einer Netzwerkpartition glaubt, die andere Seite sei tot, aber der isolierte Host führt die VM weiterhin aus und schreibt weiterhin auf den Storage. Eine zweite Kopie anderswo zu starten, kann Daten beschädigen.

Deshalb ist es eine schlechte Idee, Ausfall-Timer aggressiv zu verkürzen, ohne Fencing zu verstehen. Ein schnellerer Neustart bringt nichts, wenn er die Chance auf zwei aktive Writer erhöht.

Testen Sie das Watchdog-Verhalten auf der tatsächlichen Hardware. Eine Konfigurationsdatei, die besagt, dass Fencing existiert, ist ein schwächerer Beweis als ein kontrollierter Ausfalltest.

4. Warum sollten Sie die Cluster-Kommunikation von lautem Traffic trennen?

Corosync-Traffic ist klein, aber latenzempfindlich. Ein Cluster-Netzwerk, das sich überlastete Pfade mit Backup-Jobs, Storage-Replikation, großen Migrationen oder instabilem Switching teilt, kann Symptome erzeugen, die wie ein Node-Ausfall aussehen.

Proxmox' Cluster-Design-Richtlinien betonen zuverlässiges Networking, weil das Quorum davon abhängt, dass Nodes konsistent kommunizieren können.

Der Fehler besteht darin, anzunehmen, Bandbreite sei die einzige Metrik, die zählt. Eine 10-GbE-Verbindung mit Paketverlust und unvorhersehbarer Latenz kann für die Cluster-Kommunikation schlechter sein als ein ruhigerer 1-GbE-Pfad.

Überwachen Sie Paketverlust, Latenz und Switch-Verhalten. Wenn der Cluster jedes Mal instabil wird, wenn Backups starten, liegt das Problem nicht bei der HA-Policy.

5. Warum bedeutet Shared Storage nicht automatisch HA?

Shared Storage löst die Disk-Zugänglichkeit. Es löst nicht Compute-Kapazität, fehlgeschlagene Gast-Boots, schlechte Placement-Regeln, Netzwerkabhängigkeiten oder Anwendungszustand.

NFS, iSCSI, Fibre Channel und Ceph können je nach Architektur alle Storage bereitstellen, auf den mehrere Nodes zugreifen können. Das Storage-System selbst wird dann Teil des Availability-Designs.

Ein einzelnes NAS mit einem Controller und einem Netzwerkpfad kann jedem Proxmox-Node gemeinsamen Zugriff geben und trotzdem ein Single Point of Failure bleiben.

Dieselbe Logik gilt für Ceph. Ceph entfernt einige zentrale Storage-Abhängigkeiten, aber nur, wenn Sie genug Failure Domains, gesunde OSDs und geeignetes Networking haben.

Die Kompromisse werden in Proxmox-HA-Storage: Ceph vs. ZFS-Replikation vs. NAS behandelt.

6. Kann ZFS-Replikation Shared Storage für HA ersetzen?

ZFS-Replikation kann die Abhängigkeit von Shared Storage verringern, ändert aber das Recovery-Modell. Die Proxmox-Storage-Replikation kopiert Gast-Volumes nach einem Zeitplan zwischen Nodes, mit einem dokumentierten Mindestintervall von einer Minute.

Das bedeutet, die sekundäre Kopie kann der aktiven VM hinterherhinken.

Wenn ein Node plötzlich ausfällt, existieren die jüngsten Schreibvorgänge nach der letzten abgeschlossenen Replikation möglicherweise nicht auf dem Ziel. Für manche Workloads ist das akzeptabel. Für eine transaktionale Datenbank vielleicht nicht.

Beschreiben Sie ZFS-Replikation nicht als HA ohne Datenverlust, es sei denn, die Anwendung hat einen weiteren Mechanismus, der diese Schreibvorgänge schützt.

Die richtige Frage ist Ihr Recovery Point Objective. Wie viele aktuelle Daten können Sie sich leisten zu verlieren?

7. Was stimmt nicht mit den alten HA-Gruppen in Proxmox VE 9?

Proxmox VE 9 hat sich von HA-Gruppen weg und hin zu HA-Node-Affinitätsregeln bewegt. Bestehende HA-Gruppen sind veraltet und werden auf das neuere Node-Affinitätsmodell migriert.

Das ist bei Upgrades wichtig, weil alte Annahmen über bevorzugte Nodes und Failback-Verhalten in einer Form überleben können, die Sie nicht überprüft haben.

Prüfen Sie nach dem Umstieg auf Proxmox VE 9 jede HA-Regel. Bestätigen Sie, welche Nodes infrage kommen, welche bevorzugt sind und ob Failback tatsächlich gewünscht ist.

Ein Dienst, der nach der Wartung ständig zu einem bevorzugten Node zurückmigriert, kann unnötige Bewegung erzeugen. Ein Dienst mit zu strikter Platzierung kann unmöglich zu starten sein, wenn ein Node ausgefallen ist.

Die Placement-Policy sollte eine echte operative Anforderung beschreiben, nicht einfach das aktuelle Layout für immer festschreiben.

8. Warum versagen HA-Cluster bei geplanter Wartung?

Geplante Wartung ist der Moment, in dem Sie herausfinden, ob der Cluster genug Reservekapazität hat. Wenn das Evakuieren eines Nodes die verbleibenden Hosts über sichere Arbeitsspeicher- oder Storage-Grenzen drückt, hatte das Design keine echte N-plus-1-Kapazität.

Proxmox bietet HA-Wartungsverhalten und Shutdown-Policies, einschließlich einer Migrate-Policy, die versucht, laufende HA-Dienste wegzumigrieren, bevor der Shutdown fortfährt.

Nutzen Sie diese Features bewusst.

Prüfen Sie vor dem Patchen eines Nodes freien Arbeitsspeicher, CPU-Spielraum, Storage-Pfade und alle Passthrough-Geräte, die eine Migration verhindern. Eine VM mit durchgereichter GPU oder HBA lässt sich vielleicht nicht wie eine gewöhnliche VM verschieben.

Wartung ist eine kontrollierte Version eines Ausfalls. Behandeln Sie sie als wiederkehrenden HA-Test.

9. Warum kann eine gesunde VM trotzdem einen ausgefallenen Dienst bedeuten?

Der Hypervisor weiß, ob die virtuelle Maschine läuft. Er weiß möglicherweise nicht, ob die Anwendung darin Nutzer korrekt bedient.

Eine Windows-VM kann booten, während die Active-Directory-Replikation kaputt ist. Eine Linux-VM kann laufen, während PostgreSQL in der Recovery hängt. Ein Webserver kann lokal antworten, während der Load Balancer ihn nicht erreichen kann.

Hier endet Infrastruktur-HA.

Überwachen Sie den Dienst, nicht nur den VM-Zustand. Fügen Sie Anwendungs-Health-Checks, Abhängigkeitsprüfungen und externe synthetische Tests hinzu, wo der Workload sie rechtfertigt.

Wenn Ihr Verfügbarkeitsziel auf Ebene des Business-Service definiert ist, muss Ihr Test auch auf dieser Ebene definiert sein.

10. Warum ist ein ungetesteter HA-Cluster keine echte HA?

Der teuerste HA-Fehler ist die Annahme, das Design funktioniere, weil alle Nodes grün anzeigen.

Ziehen Sie in einem Wartungsfenster ein Kabel. Schalten Sie einen Node aus. Unterbrechen Sie einen Storage-Pfad. Stoppen Sie einen Switch-Port. Starten Sie einen Quorum-Teilnehmer neu. Zeichnen Sie auf, was passiert und wie lange die Recovery dauert.

Testen Sie nicht alles auf einmal.

Beginnen Sie mit einem kontrollierten Ausfall und messen Sie vier Werte: Erkennung, Gast-Neustart, Betriebssystem-Bereitschaft und Anwendungs-Bereitschaft. Diese Zahlen werden zu Ihrer echten Recovery-Baseline.

Testen Sie dann auch den Backup-Pfad. HA schützt die Uptime vor manchen Infrastruktur-Ausfällen. Es ersetzt keine Backups gegen Löschung, Beschädigung oder Ransomware.

Was würde ich zuerst an einem fragilen Proxmox-HA-Cluster ändern?

Ich würde zuerst die Failure Domain explizit machen. Listen Sie jede HA-VM auf, die Nodes, auf denen sie laufen darf, den Storage, den sie braucht, ihre Netzwerkabhängigkeiten und die Reservekapazität, die nach dem Ausfall eines Nodes nötig ist.

Dann würde ich einen Host-Ausfall testen.

Wenn der Cluster nur zwei Nodes hat, würde ich das Quorum-Design reparieren, bevor ich weitere HA-Workloads hinzufüge. Wenn sich der Storage-Zugriff je nach Node unterscheidet, würde ich Placement-Regeln oder Storage-Architektur reparieren, bevor ich automatischem Neustart vertraue. Wenn der Cluster nicht einen Host verlieren kann, ohne den RAM zu erschöpfen, würde ich die Last reduzieren oder Kapazität hinzufügen.

Ein kleinerer Cluster mit vorhersehbarem Ausfallverhalten ist nützlicher als ein kompliziertes HA-Design, das nie zum Versagen gezwungen wurde.