Cluster, HA und Wartung

Ein VM-Neustart ist noch keine Dienstverfügbarkeit

Hochverfügbarkeit im Cluster löst genau ein Problem: Eine VM, deren Host ausgefallen ist, läuft danach auf einem anderen Host wieder. Das ist wertvoll und eng begrenzt. Der Cluster startet eine Maschine neu, nicht eine Anwendung. Zwischen beidem liegen Dateisystemprüfung, Dienststart, Abhängigkeiten zu Datenbank und Verzeichnisdienst, Sitzungsverlust und der Umstand, dass Clients die alte Adresse noch im Zwischenspeicher halten.

Hochverfügbarkeit — Der Dienst kehrt nach einem Ausfall innerhalb einer vereinbarten Zeit zurück. Ein Unterbruch ist Teil der Zusage.

Fehlertoleranz — Der Dienst läuft über den Ausfall hinweg ohne Unterbruch weiter. Das verlangt eine zweite, synchron mitlaufende Instanz und kostet entsprechend.

Wer beides verwechselt, verspricht der Fachabteilung Fehlertoleranz und liefert einen Neustart. Die Zusage, die ein HA-Cluster tatsächlich einlösen kann, lautet: ungeplanter Neustart der VM auf einem anderen Host, ohne Konsistenzgarantie für die Anwendung. Alles darüber hinaus — sauberes Herunterfahren, transaktionale Konsistenz, Client-Failover — ist ein eigener Vertrag der Anwendung.

Der Cluster trifft drei Entscheidungen, nicht eine

Im Alltag verschmilzt der Satz „der Cluster hat die VM neu gestartet“ zu einem einzigen Vorgang. Tatsächlich sind es drei aufeinander aufbauende Entscheidungen, die unabhängig voneinander scheitern können. Sie auseinanderzuhalten ist der Unterschied zwischen einer Diagnose und einem Ratespiel.

Die erste Frage ist eine Mehrheitsfrage und hat mit dem Workload nichts zu tun. Die zweite ist eine Messfrage und braucht mehr als einen Beobachtungspfad. Die dritte ist eine Sicherheitsfrage: Ohne Beweis, dass die alte Instanz nicht mehr schreibt, ist ein Neustart anderswo gefährlicher als der Ausfall selbst.

Eine vierte Frage stellt der Cluster nie: ob der Dienst danach funktioniert. Die beantwortet nur ein Test gegen die Anwendung.

Quorum ist die Erlaubnis zu entscheiden, nicht die Fähigkeit zu tragen

Quorum ist die Mindestzahl an Stimmen, die eine Clusterpartition braucht, um Zustandsänderungen vornehmen zu dürfen. Proxmox VE vergibt laut Dokumentation je Knoten standardmäßig eine Stimme und wechselt bei Quorumverlust in den Nur-Lese-Modus. pvecm status zeigt die Rechnung offen an:

Expected votes

Summe aller konfigurierten Stimmen, im Beispiel der Dokumentation 4

Total votes

Stimmen der aktuell sichtbaren Partition

Quorum

Schwelle, ab der die Partition entscheiden darf, im Beispiel 3

Quorate

Ja oder Nein — das Ergebnis dieser Rechnung

Daraus folgt die Empfehlung von drei Knoten aufwärts: Bei zwei Knoten verliert nach einem Ausfall auch der überlebende Knoten die Mehrheit. Für diesen Fall sieht Proxmox VE ein QDevice vor — einen externen Stimmgeber auf einem unabhängigen Server. Er gibt seine Stimme laut Dokumentation immer nur einer Partition und verhindert damit, dass beide Seiten sich für die Mehrheit halten. Anders als corosync selbst verbindet sich das QDevice über TCP/IP und unterliegt nicht denselben Latenzanforderungen.

Microsoft löst dieselbe Frage im Failover Cluster über einen Zeugen: Datenträger-, Dateifreigabe- oder Cloud-Zeuge. Die Microsoft-Dokumentation empfiehlt, ab Windows Server 2012 R2 immer einen Zeugen zu konfigurieren; neuere Versionen verwalten dessen Stimme über Dynamic Quorum selbst.

Tot oder nur unerreichbar — zwei Messwege statt einem

Reißt die Verbindung im Verwaltungsnetz zu einem Host ab, hat der Cluster eine einzige Beobachtung und drei mögliche Ursachen. Ein einzelner Messweg kann sie nicht trennen. vSphere HA nutzt deshalb einen zweiten: Datastore-Heartbeating.

Ausgefallen

Kein Netz-Heartbeat und kein Datastore-Heartbeat — der Host gilt als tot, seine VMs werden anderswo gestartet

Partitioniert

Kein Netz-Heartbeat zum Primärhost, aber der Datastore-Heartbeat läuft — der Host lebt in einer abgetrennten Gruppe

Isoliert

Kein Netz-Heartbeat, Datastore-Heartbeat läuft, und der Host erreicht seine Isolationsadressen nicht

Die Dokumentation ist an dieser Stelle wörtlich: Hört ein untergeordneter Host auf, über den Datastore zu heartbeaten, gilt er als ausgefallen und seine VMs werden woanders neu gestartet. Läuft der Datastore-Heartbeat dagegen weiter, weiß der Primärhost, dass er nicht neu starten darf.

vCenter Server wählt dafür standardmäßig zwei Heartbeat-Datastores je Host aus, höchstens fünf; die Zahl steuert die erweiterte Option das.heartbeatdsperhost. Im Wurzelverzeichnis jedes solchen Datastores legt vSphere HA ein Verzeichnis .vSphere-HA an.

Isolationsadresse — Die Adresse, die ein Host anpingt, um zu prüfen, ob er selbst vom Netz getrennt ist. Voreingestellt ist das Standardgateway der Verwaltungsschnittstelle; über das.isolationaddress lassen sich weitere Adressen ergänzen.

Ein Host erklärt sich laut Dokumentation erst dann für isoliert, wenn beides zutrifft: Er erreicht die Agenten der anderen Hosts nicht und er kann seine Isolationsadressen nicht anpingen. Wer als Isolationsadresse das Standardgateway belässt, macht genau dieses Gateway zum Schiedsrichter über den Zustand seiner VMs.

Die Isolationsreaktion ist eine Entscheidung über Datenverlust

Stellt ein Host fest, dass er isoliert ist, wendet sein HA-Agent die konfigurierte Isolationsreaktion auf die laufenden VMs an. Die Wahl ist keine Geschmacksfrage, sondern eine Abwägung zwischen zwei Schäden.

Deaktiviert

Die VMs laufen weiter. Kein Datenverlust auf der isolierten Seite, aber der Dienst bleibt unerreichbar, solange die Isolation dauert

Ausschalten und neu starten

Hartes Abschalten ohne Beteiligung des Gasts. Schnell, und genau deshalb mit dem Risiko unvollständig geschriebener Daten

Herunterfahren und neu starten

Geordnetes Herunterfahren über die Gastwerkzeuge. Schonender, braucht aber Zeit und eine funktionierende Gastintegration

Dazu kommt eine Sonderregel, die leicht übersehen wird: Für eine VM, deren Neustartpriorität auf deaktiviert steht, findet laut Dokumentation gar keine Isolationsreaktion statt. Wer Prioritäten nur als Reihenfolge liest, übersieht, dass derselbe Wert zugleich ein Schalter für die Isolationsreaktion ist.

Welche Reaktion angemessen ist, hängt am Speicherpfad. Verliert der isolierte Host mit dem Netz auch seinen Storage, ändert Weiterlaufen nichts mehr zum Guten. Bleibt der Storage erreichbar — der typische Fall bei getrennten Netzen für Verwaltung und Storage —, ist Weiterlaufen oft die schonendere Wahl, weil der Cluster die VMs ohnehin nicht neu startet, solange der Datastore-Heartbeat läuft.

Fencing beweist, dass die alte Instanz nicht mehr schreibt

Fencing ist die Voraussetzung dafür, dass ein Dienst überhaupt woanders anlaufen darf. Die Proxmox-Dokumentation begründet das an einem konkreten Szenario: Fällt jedes Netz außer dem Storagenetz aus, ist die VM aus dem Produktivnetz nicht mehr erreichbar — sie läuft aber weiter und schreibt weiter auf den gemeinsamen Storage. Startet man sie nun auf einem anderen Knoten, schreiben zwei Instanzen auf dieselben Daten.

Klassisch löst man das über externe Geräte, die dem Knoten Strom oder Netz abschneiden. Proxmox VE geht einen Weg ohne Zusatzhardware: Selbst-Fencing über einen Watchdog-Timer. Verfügbar ist wahlweise ein Hardware-Watchdog oder der Software-Watchdog softdog des Linux-Kernels.

Der Mechanismus ist streng: Stellt ein Knoten fest, dass er nicht mehr im Quorum ist, wartet der lokale Resource Manager auf ein neues Quorum. Solange keines zustande kommt, kann der Knoten den Watchdog nicht zurücksetzen. Hat er aktive Dienste, löst das nach Ablauf des Watchdogs einen Neustart aus — laut Dokumentation nach 60 Sekunden. Der Knoten setzt sich also selbst zurück, obwohl seine VMs gesund sind.

Eine Feinheit hebt die Dokumentation eigens hervor: Hat ein Knoten einen aktiven Cluster Resource Manager, aber einen untätigen lokalen Resource Manager, führt Quorumverlust nicht zum Selbst-Reset. Grund ist, dass das Cluster-Dateisystem bei Quorumverlust ohnehin nur noch lesbar ist. Ist 15 Minuten lang kein Dienst konfiguriert, schließt der Cluster Resource Manager den Watchdog vollständig.

Der Watchdog macht das Netzdesign zur HA-Frage

Hier entsteht der Befund, der in der Praxis am häufigsten überrascht. Wenn ein Knoten sich nach 60 Sekunden ohne stabiles Quorum selbst zurücksetzt, dann ist jede Umschaltzeit im Clusternetz, die länger als 60 Sekunden dauert, eine Ausfallursache. Die Proxmox-Dokumentation rechnet das für LACP vor:

• Standardmäßig werden LACPDUs nur alle 30 Sekunden gesendet.
• Drei ausbleibende LACPDUs in Folge gelten als Ausfall — daraus folgt eine Umschaltzeit von 90 Sekunden.
• Knoten mit HA-Ressourcen fencen sich aber bereits nach rund 60 Sekunden.
• Die Empfehlung lautet deshalb, bond-lacp-rate fast auf Knoten und Switch zu setzen — das drückt die Umschaltzeit auf 3 Sekunden.

Ein vollkommen normal konfigurierter LACP-Bond reicht also aus, um bei einem Leitungsfehler Knoten zu verlieren, die selbst völlig gesund sind. Der Fehler steckt nicht im Cluster, sondern in einer Voreinstellung des Netzes.

balance-rr, balance-xor, balance-tlb, balance-alb

Können asymmetrische Erreichbarkeit erzeugen und damit unerwartetes Fencing auslösen

802.3ad (LACP)

Kann sich von Asymmetrie erholen, ist mit der Standardrate aber zu langsam — bond-lacp-rate fast setzen

active-backup

Erzeugt keine Asymmetrie, schaltet aber unter Umständen nicht auf die Ersatzleitung um

Der Preis der empfohlenen Wahl gehört dazu: bond-lacp-rate fast verlangt eine passende Einstellung auf der Switchseite und erzeugt mehr Kontrollverkehr. Wer nur eine Seite umstellt, bittet die Gegenseite lediglich um schnellere LACPDUs und sollte das Ergebnis messen, statt es anzunehmen.

Neustartversuche sind gedeckelt — und der Zähler ist tückisch

Ein HA-Dienst wird nicht endlos neu gestartet. Zwei Grenzen steuern das Verhalten je Ressource, beide stehen laut Dokumentation standardmäßig auf 1:

max_restart — Wie oft der Dienst auf dem aktuellen Knoten neu gestartet wird, bevor ein anderer Knoten in Frage kommt.

max_relocate — Wie oft der Dienst auf einen anderen Knoten verschoben wird. Ein Verschieben findet erst statt, nachdem max_restart auf dem aktuellen Knoten überschritten wurde.

Die Falle steckt im Zurücksetzen: Der Verschiebezähler fällt laut Dokumentation erst dann auf null, wenn der Dienst mindestens einmal erfolgreich gestartet wurde. Wird ein Dienst wieder und wieder gestartet, ohne dass die Ursache behoben ist, wiederholt sich also nur die Neustartregel — der Cluster arbeitet sich nicht schrittweise durch die Knoten.

Endet die Kette erfolglos, landet der Dienst im Zustand error und ist damit stillgelegt. Das ist bewusst so: Ein Dienst, der auf jedem Knoten scheitert, hat ein Problem, das kein weiterer Neustart löst. Aus error führt nur ein Eingriff von Hand heraus.

Für die Diagnose lohnt der Blick auf die Zustandsfolge. Ein Dienst auf einem ausgefallenen Knoten geht zuerst nach fence und wartet dort, bis der Knoten nachweislich abgeschaltet ist. Erst danach folgt recovery, wo der Manager anhand der online und quorierten Knoten einen neuen Zielknoten sucht. Wer eine VM in fence hängen sieht, hat kein Platzierungsproblem, sondern ein Fencing-Problem.

Geplante Wartung läuft über einen anderen Pfad als ein Ausfall

Ein Ausfall wird erkannt; Wartung wird angekündigt. Dafür gibt es den Wartungsmodus. Er markiert den Knoten als für den HA-Betrieb nicht verfügbar und lässt alle verwalteten Dienste auf andere Knoten wandern. Der ursprüngliche Knoten wird dabei im Managerzustand vermerkt, sodass die Dienste nach dem Ende der Wartung automatisch zurückkehren.

Gesetzt wird der Modus über die Kommandozeile, und zwar von jedem Knoten aus — der Befehl wird als Managerkommando eingereiht:

• ha-manager crm-command node-maintenance enable NODENAME aktiviert den Wartungsmodus.
• ha-manager crm-command node-maintenance disable NODENAME hebt ihn wieder auf.

Wichtig für das Sicherheitsverständnis: Der Selbst-Fencing-Watchdog bleibt während des Verschiebens aktiv. Der Wartungsmodus schaltet die Schutzfunktion nicht ab, er ändert nur die Platzierung.

Für Arbeiten am Clusternetz selbst — corosync umkonfigurieren, Switches tauschen — reicht das nicht. Solche Eingriffe erzeugen genau den Quorumverlust, den HA als Knotenausfall deutet. Dafür existiert ein eigener Mechanismus, der die Watchdogs clusterweit freigibt. Sein Preis steht in derselben Dokumentation: Währenddessen schützt HA die Dienste nicht, Ausfälle werden nicht automatisch behoben. Das Fenster gehört deshalb so kurz wie möglich gehalten.

Herunterfahren und Neustarten sind im HA-Cluster nicht dasselbe

Der letzte und praktischste Stolperstein: Wie ein Knoten beendet wird, entscheidet über das Schicksal seiner VMs. Proxmox VE steuert das über ha: shutdown_policy in datacenter.cfg. Voreingestellt ist laut Dokumentation Conditional — aus Gründen der Abwärtskompatibilität, mit dem ausdrücklichen Hinweis, dass manche Anwender Migrate für das erwartungsgemäßere Verhalten halten.

Conditional beim Herunterfahren

Der lokale Resource Manager stoppt alle verwalteten Dienste; andere Knoten übernehmen sie anschließend — ein Kaltstart, keine Livemigration

Conditional beim Neustart

Die Dienste werden eingefroren und bleiben auf dem Knoten; nach dem Neustart laufen sie dort wieder an

Migrate

Der Knoten markiert sich als nicht verfügbar und verschiebt alle Dienste, bevor er herunterfährt

Failover

Alle Dienste werden gestoppt, aber anderswo wiederhergestellt, wenn der Knoten nicht bald zurückkehrt

Freeze

Alle Dienste werden gestoppt und eingefroren und erst wiederhergestellt, wenn der Knoten zurück ist

Der Unterschied zwischen den ersten beiden Zeilen ist die eigentliche Lehre: Derselbe Knoten, zwei Befehle, zwei völlig verschiedene Ergebnisse. Die Dokumentation nennt auch den Grund für das Stoppen beim Herunterfahren — moderne Hosts tragen so viel Arbeitsspeicher, dass eine Livemigration aller VMs unverhältnismäßig lange dauerte. Wer migrieren will, muss das vorher von Hand anstoßen.

Zwei Punkte gehören zur Vollständigkeit. Bei der Richtlinie Migrate bleibt der Watchdog während der Migration aktiv: Verliert der Knoten dabei das Quorum, wird er gefenct und die Dienste werden wiederhergestellt. Und lokal gebundene Dienste — Hardware-Passthrough, strikte Knotenregeln — lassen sich nicht verschieben; sind alle zulässigen Ziele weg, hängt das Herunterfahren, bis jemand eingreift.

Arbeitsbeispiel: Nach dem Switch-Wartungsfenster fehlen drei Knoten

Das Muster ist übertragbar: Wo eine Schutzfunktion an eine Frist gebunden ist, wird jede Umschaltzeit in den darunterliegenden Schichten zum Teil des HA-Entwurfs. Die Frage lautet nicht, ob der Bond redundant ist, sondern ob er schneller umschaltet, als der Watchdog zuschlägt.