Inhalt (7 Abschnitte)
Auf dem Papier ist die Hochverfügbarkeit von Proxmox ein Häkchen: Man fügt eine Ressource zu HA hinzu, und wenn ein Knoten ausfällt, startet sie anderswo neu. Wir betreiben einen Cluster mit drei Knoten und 31 HA-Ressourcen (alles, was sich dafür eignet), und der Weg vom gesetzten Häkchen zu einem Cluster, der sich tatsächlich wie geplant verhält, ist mit Entdeckungen gepflastert. Hier sind sie, damit Sie sie nicht selbst machen müssen.
Zuerst: was HA tut (und was nicht) #
Proxmox HA startet Ihre Maschinen auf einem anderen Knoten neu, wenn ihr Knoten nicht mehr erreichbar ist. Neustart heißt: Es gibt eine Unterbrechung, und auf repliziertem lokalem ZFS-Speicher (unser Fall, kein gemeinsames SAN) startet die Maschine vom letzten Replikat. Bei einer Replikation alle 15 Minuten beträgt Ihr tatsächlicher RPO 15 Minuten: die erste Zahl, die Sie kennen und neben die Anforderungen Ihres Notfall-Wiederherstellungsplans stellen sollten. HA schützt vor dem Hardwareausfall eines Knotens, nicht vor Ransomware oder menschlichen Fehlern, die gewissenhaft in weniger als 15 Minuten auf den anderen Knoten repliziert werden.
Strukturelle Folge auf lokalem ZFS: Eine Maschine ohne Replikat hat in HA nichts verloren: Das Failover würde sie auf einem Knoten starten, der ihren Datenträger nicht hat. Bei uns ist die Regel mechanisch: Die zulässigen Knoten einer HA-Ressource ergeben sich aus ihrer Replikation, nie aus einer Wahl nach Gefühl. Und eine Voraussetzung, noch bevor man irgendetwas aktiviert: ein redundantes Cluster-Netzwerk (doppelter Corosync-Ring), sonst wird aus einem einfachen Netzwerkverlust ein Fencing: Der Cluster „tötet“ aus übertriebener Vorsicht einen gesunden Knoten.
Der Mythos: Nein, Container migrieren nicht live #
Das steht im Code von Proxmox, nicht in den Prospekten: Ein LXC-Container kann nicht live migrieren. Bei Wartung wie bei Failover wird ein CT angehalten, synchronisiert, neu gestartet: Rechnen Sie mit 10 bis 30 Sekunden Unterbrechung, zuzüglich des Anwendungsstarts. VMs dagegen migrieren live, auch mit lokalen Datenträgern. Dieses Detail verändert die Dimensionierung: Ein Dienst, der keinen Aussetzer verträgt, braucht eine VM (oder Redundanz auf Anwendungsebene), keinen CT „in HA“. Wir haben das in beide Richtungen geprüft: Unsere CTs brauchen ihre 10 bis 30 s für den Relocate, und eine notorisch launische VM ist live migriert, ohne eine Sekunde Uptime zu verlieren.
Die drei Fallstricke, die uns Stunden gekostet haben #
1. Ohne Failback kommen die Maschinen nie zurück #
Die Richtlinie shutdown_policy=migrate evakuiert die Ressourcen sauber, wenn ein Knoten neu gestartet wird. Was wir auf die harte Tour gelernt haben: Die Rückkehr hängt vom Flag failback jeder Ressource ab. Mit failback 0 (dem historischen Standard unserer Konfiguration) endete ein Neustart eines Knotens mit neun Maschinen, die nie zurückkamen: der Knoten leer, sein Nachbar überlastet und eine HA-Übersicht, die seelenruhig überall started anzeigte. Die Drift ist still und summiert sich: Jede Wartung bringt den Cluster ein bisschen mehr aus dem Gleichgewicht. Seitdem gilt überall failback 1: Jede Rückkehr eines Knotens kostet ein paar Relocates von 10 bis 30 s, ein bewusst gezahlter Preis gegen die unsichtbare Drift.
2. Die HÖHERE Priorität gewinnt #
In einer Platzierungsregel (node-affinity) bedeutet nodeA:1, nodeB:2, dass nodeB der bevorzugte Knoten ist: Die höhere Zahl gewinnt. Liest man das intuitiv verkehrt herum, legt man genau das Gegenteil der eigenen Absicht fest, und HA verschiebt die Maschine innerhalb der nächsten Minute… was bei einem Container ein sofortiges Anhalten und Neustarten bedeutet. Wir sind zweimal in einem Monat in diese Falle getappt, daher diese Zeile in unseren Verfahren: Vor dem Bestätigen einer Regel prüfen, welche Zahl die höhere ist, immer.
3. qm stop stoppt keine HA-Ressource #
Eine Ressource unter HA gehört dem HA-Manager: Halten Sie sie von Hand an, betrachtet er sie als ausgefallen… und startet sie wieder. An dem Tag, an dem eine VM während eines Backups einfriert (erlebt, dank der Wechselwirkungen zwischen dem Einfrieren des Dateisystems und der Sicherheitssoftware im Gast), reicht der Reflex qm stop nicht mehr: ha-manager crm-command stop hält sauber an und informiert dabei den Manager. Das sollten Sie vor dem Vorfall wissen, nicht währenddessen.
Was wir mitnehmen #
- HA wird von der Replikation her konzipiert: RPO 15 min, zulässige Knoten = replizierte Knoten, Kapazität des verbleibenden Knotens geprüft (der Verlust eines Knotens bündelt seine Last auf seinem Replikationsnachbarn; den Ausweichplan erstellt man in Ruhe).
- CT = Neustart, VM = Live-Migration: pro Dienst das richtige Vehikel wählen.
failback, Prioritäten, Anhalten einer HA-Ressource: drei kontraintuitive Verhaltensweisen, die man auf einer unkritischen Maschine testet und nie erst im Produktivbetrieb entdeckt.- Und ehrlicherweise, wie es sich für einen Erfahrungsbericht gehört: Das Failover bei einem harten Ausfall eines Knotens (Stecker ziehen, nicht neu starten) ist noch eine Übung, die eingeplant werden muss. Ein ungetesteter HA-Cluster ist eine Hypothese, keine Garantie.
Diese Infrastruktur trägt unser souveränes Hosting: automatisches Failover, Replikation, unveränderliche Backups und Überwachung. Wenn Ihr Hoster Ihnen sagt „das läuft in HA“, aber zu RPO oder Failback keine Antwort hat, wissen Sie jetzt, welche Fragen Sie stellen sollten, und wir auch.
