HA und Live-Migration im SAN-Cluster: was der Watchdog wirklich tut

/01Was Hochverfügbarkeit im SAN-Cluster bedeutet — und was nicht

Hochverfügbarkeit in einem Proxmox-Cluster bedeutet: Fällt ein Knoten aus, startet der HA-Manager die VMs und Container, die auf diesem Knoten liefen, automatisch auf einem anderen Knoten neu — ohne dass jemand eingreifen muss. Auf einem SAN-Cluster mit Shared LVM funktioniert das, weil jeder Knoten dasselbe LUN sieht: Es muss nichts kopiert werden, nur die VM-Konfiguration und der Dienst selbst wechseln den Besitzer. Voraussetzung dafür ist laut Proxmox-Dokumentation, dass der Storage-Eintrag als shared markiert ist — nur dann implementiert das LVM-Backend „cluster-wide locking if the storage is marked as shared in the configuration" und verhindert, dass zwei Knoten gleichzeitig dieselben Metadaten verändern.

Was Hochverfügbarkeit nicht bedeutet, wird in diesem Artikel ausdrücklich mitbehandelt: Sie ist kein Schutz vor Datenverlust, kein Ersatz für ein Backup und keine Garantie gegen jede Art von Ausfall. Sie ist eine Automatik, die einen Knotenausfall abfedert — nicht mehr, aber auch nicht weniger. Die Architektur, die diesen Artikel voraussetzt — mindestens drei Quorum-Stimmen (drei Knoten oder zwei Knoten plus QDevice), ein eigenes Netz für Corosync, SAN per Multipath angebunden — ist im Grundlagenartikel zum Managed-Proxmox-Cluster beschrieben; hier geht es ausschließlich um das, was darüber passiert: HA-Manager, Fencing und Live-Migration.

/02Der HA-Manager: CRM, LRM und der Ressourcenzustand

Proxmox trennt die HA-Logik in zwei Rollen. Der Cluster Resource Manager (CRM) läuft als Dienst auf einem der Knoten und trifft die übergeordneten Entscheidungen: welche Dienste wo laufen sollen. Der Local Resource Manager (LRM) läuft auf jedem Knoten und setzt diese Entscheidungen lokal um — er startet, stoppt oder migriert die ihm zugewiesenen Dienste. Verliert der Knoten mit aktivem CRM das Quorum oder stürzt der Prozess ab, übernimmt automatisch ein anderer Knoten diese Rolle; die Proxmox-Dokumentation beschreibt diesen Übergang nüchtern: „the CRM lost its lock, this means a failure happened and quorum was lost."

Entscheidend ist, dass der LRM nicht aus eigenem Ermessen handelt, wenn sein Knoten das Quorum verliert: Die Dokumentation hält fest, „When a cluster member determines that it is no longer in the cluster quorum, the LRM waits for a new quorum to form. Until there is a cluster quorum, the node cannot reset the watchdog." Der Knoten kann also nicht einfach weiterarbeiten, als wäre nichts geschehen — er wartet, und wenn er zu lange wartet, übernimmt der Watchdog, den der nächste Abschnitt behandelt.

Diese Aufteilung in CRM und LRM ist kein Selbstzweck: Sie sorgt dafür, dass die übergeordnete Entscheidung — welcher Dienst soll wo laufen — nur an einer einzigen Stelle im Cluster getroffen wird, während die Ausführung lokal bleibt. Ein Knoten, der kurzzeitig nicht erreichbar ist, kann so nie zwei widersprüchliche Entscheidungen gleichzeitig umsetzen. Wie das Mehrheitsmodell hinter dem Quorum selbst funktioniert — wie viele Stimmen für eine Mehrheit nötig sind und warum zwei bloße Knoten ohne QDevice dafür nicht reichen — ist Grundlage dieses gesamten Mechanismus und im Grundlagenartikel zum Managed-Proxmox-Cluster ausführlich beschrieben.

/03Fencing und Watchdog: die Sicherung gegen Split-Brain

Fencing ist der Mechanismus, der verhindert, dass zwei Knoten gleichzeitig glauben, für dieselbe VM zuständig zu sein. Die Proxmox-Dokumentation beschreibt das Risiko ohne Umschweife: Würde man eine VM, deren ursprünglicher Knoten nur kurz nicht erreichbar war, einfach auf einem zweiten Knoten neu starten, entstünde „a dangerous race condition, because we write from both nodes" — ein Zustand, der laut Dokumentation „destroy all VM data" kann. Fencing verhindert genau das, indem es den fraglichen Knoten zwangsweise aus dem Spiel nimmt, bevor der Rest des Clusters dessen Dienste übernimmt.

Technisch übernimmt das ein in jedem Knoten eingebauter Watchdog. Laufen auf einem Knoten HA-verwaltete Dienste und verliert er das Quorum oder reagiert sein CRM/LRM-Prozess nicht mehr, greift laut Dokumentation eine feste Frist: „this will trigger a reboot after the watchdog has timed out (this happens after 60 seconds)." Diese 60 Sekunden sind kein Konfigurationsfehler, wenn sie auftreten — sie sind die eingebaute Garantie, dass ein fraglich gewordener Knoten binnen einer Minute entweder wieder sauber mitspielt oder zuverlässig aus dem Cluster verschwindet.

hostspezial@pve01:~$ ha-manager status
# Gesamtzustand: welche Dienste laufen wo, welcher Knoten haelt den CRM-Lock

hostspezial@pve01:~$ pvecm status
# Quorum-Sicht: wie viele Stimmen aktuell vorhanden sind

hostspezial@pve01:~$ journalctl -u pve-ha-crm -u pve-ha-lrm --since "-1h"
# CRM/LRM-Entscheidungen der letzten Stunde nachvollziehen

Ein durchgespielter Ausfall macht die Fristen aus diesem Abschnitt greifbar. Angenommen, pve02 trägt HA-verwaltete VMs auf gemeinsamem SAN-Storage und verliert unerwartet die Netzverbindung:

T+0s     pve02 wird fuer die anderen Knoten unerreichbar
T+<5s    Corosync erkennt den Verbindungsverlust (Latenzgrenze
         aus Abschnitt /04), das Quorum wird neu berechnet
T+<5s    pve02 selbst erkennt den Quorumverlust, die LRM wartet
         auf ein neues Quorum und kann den Watchdog nicht
         zuruecksetzen
T+60s    Watchdog auf pve02 loest den Reboot aus -- der Knoten
         ist damit zuverlaessig aus dem Cluster entfernt
T+~0-120s parallel: CRM auf einem verbleibenden Knoten erkennt
         den verlorenen Lock und startet die betroffenen Dienste
         auf anderen Knoten neu (laut Dokumentation "typical
         error detection and failover times of about 2 minutes")

Zwei Fristen laufen hier nebeneinander, nicht nacheinander: Die 60 Sekunden sind die Obergrenze, bis sich pve02 selbst aus dem Spiel nimmt; die rund zwei Minuten sind die vom Hersteller genannte typische Gesamtzeit, bis die verschobenen Dienste auf den verbleibenden Knoten wieder laufen. Beide Werte sind keine Garantie, sondern Herstellerangaben aus der Proxmox-Dokumentation — wie lange ein konkreter Vorfall tatsächlich dauert, hängt zusätzlich an der Zahl der betroffenen VMs, deren Arbeitsspeicherbedarf beim Neustart und der aktuellen Auslastung der verbleibenden Knoten.

/04Das Corosync-Netz als Voraussetzung, nicht als Detail

Watchdog und Fencing aus Abschnitt /03 reagieren auf Quorum-Verlust — und Quorum hängt direkt an der Qualität des Corosync-Netzes. Die Proxmox-Dokumentation nennt dafür eine enge Vorgabe: „The Proxmox VE cluster stack requires a reliable network with latencies under 5 milliseconds (LAN performance) between all nodes to operate stably." Teilt sich dieses Netz mit SAN- oder Backup-Verkehr, reicht eine Lastspitze, um genau die Kette aus Abschnitt /03 auszulösen — nicht weil ein Knoten wirklich ausgefallen ist, sondern weil Corosync-Pakete zu spät ankamen.

Redundanz für dieses Netz baut Proxmox nicht über Hoffnung, sondern über einen zweiten, unabhängigen Link in corosync.conf:

# /etc/pve/corosync.conf — Ausschnitt, zwei Links je Knoten
nodelist {
  node {
    name: pve01
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 10.10.10.1
    ring1_addr: 10.20.20.1
  }
  node {
    name: pve02
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 10.10.10.2
    ring1_addr: 10.20.20.2
  }
}
totem {
  interface { linknumber: 0 }
  interface { linknumber: 1 }
}

Laut Proxmox-Dokumentation genügt das Eintragen im laufenden Betrieb: „The new link will be enabled as soon as you follow the last steps to edit the corosync.conf file. A restart should not be necessary." Ob der zweite Link die Prüfung übersteht, lässt sich laut Dokumentation gezielt testen, indem man den ursprünglichen Link kurz trennt und beobachtet, ob der Cluster-Status über pvecm status weiterhin gesund bleibt — eine Übung, die vor jedem produktiven HA-Einsatz stehen sollte, nicht erst nach dem ersten echten Ausfall.

Für ein HA-Setup, das SAN-Storage trägt, ist ein dediziertes, redundantes Corosync-Netz deshalb keine Optimierung, sondern Grundvoraussetzung. Wie dieses Netz aufgebaut wird, welche Fehler in der Praxis zu nächtlichen Fencing-Vorfällen führen und wie man sie diagnostiziert, zeigt der eigene Artikel zu Corosync und Fencing im Detail — inklusive des Zwei-Knoten-Sonderfalls mit QDevice.

/05Live-Migration mit Shared Storage auf dem SAN

Neben der ungeplanten HA-Übernahme steht die geplante Live-Migration: ein Dienst wechselt den Knoten, während er läuft, ohne dass der Cluster den alten Knoten je als ausgefallen betrachtet. Die Proxmox-Dokumentation unterscheidet grundsätzlich zwei Wege: „Online Migration (aka Live Migration)" und „Offline Migration" — Letztere schaltet die VM kurz ab, kopiert ihren Zustand und startet sie auf dem Zielknoten neu, was für geplante Wartung ohne Zeitdruck ausreicht, aber eben mit spürbarer Downtime. Für den Normalfall im SAN-Cluster zählt die Online-Variante:

hostspezial@pve01:~$ qm migrate 140 pve02 --online
# Online-Migration der VM 140 auf Knoten pve02, laut PVE-GUI
# Standardverhalten, sobald die VM laeuft

Laut Proxmox-Dokumentation startet der Zielknoten dafür zunächst einen neuen QEMU-Prozess, der auf den Speicher- und Gerätezustand der laufenden VM wartet, während deren vCPUs weiter pausiert bleiben. Dann beginnt der Quellknoten, den Arbeitsspeicher asynchron zu übertragen; ändert sich Speicher auf der Quelle währenddessen, wird er erneut markiert und in einem weiteren Durchlauf nachgesendet. Dieser Zyklus wiederholt sich, bis der verbleibende Unterschied klein genug ist, um in wenigen Millisekunden übertragen zu werden — „the source VM can be paused completely, without a user or program noticing the pause", bevor der Zielknoten „the new running VM in well under a second" übernimmt.

Entscheidend für die Geschwindigkeit ist, dass die Festplatte dabei nicht mitwandert: Auf Shared Storage sehen Quell- und Zielknoten dieselbe Disk, es muss ausschließlich der Arbeitsspeicher übertragen werden. Die Dokumentation nennt explizit die Voraussetzungen, unter denen das funktioniert: beide Knoten im selben Cluster, eine verlässliche Netzverbindung zwischen ihnen, der Zielknoten mit gleicher oder höherer Proxmox-VE-Paketversion, und CPUs desselben Herstellers mit vergleichbaren Fähigkeiten. Nicht migrierbar sind laut Dokumentation lokal gebundene Ressourcen wie durchgereichte PCI- oder USB-Geräte; lokale Festplatten dagegen „can be migrated by sending them to the target just fine" — das funktioniert technisch auch ohne SAN, dauert aber so lange wie das Kopieren der gesamten Disk, statt in Sekunden zu laufen.

/06Wartung ohne Downtime: das geplante Patch-Fenster

Der praktische Nutzen von Abschnitt /05 zeigt sich beim Patchen: Ein Knoten, der für ein Kernel-Update neu gestartet werden muss, muss seine Dienste vorher nicht verlieren, sondern kann sie geordnet abgeben. Proxmox bietet dafür einen eigenen Wartungsmodus, der HA-verwaltete Dienste per Live-Migration auf andere Knoten verschiebt, bevor der Reboot beginnt — der Knoten verlässt den Cluster dann angekündigt, nicht kommentarlos, und löst damit kein Fencing aus.

hostspezial@pve01:~$ ha-manager crm-command node-maintenance enable pve01
# HA-Dienste auf pve01 wandern per Live-Migration zu anderen Knoten

# jetzt Wartung fahren: Patchen, Reboot, Hardware-Wechsel

hostspezial@pve01:~$ ha-manager crm-command node-maintenance disable pve01
# Dienste wandern zurueck, Wartungsmodus wird beendet

Ein Detail aus der Dokumentation wird in der Praxis regelmäßig übersehen: „The manual maintenance mode is not automatically deleted on node reboot, but only if it is either manually deactivated using the ha-manager CLI or if the manager-status is manually cleared." Wer den letzten Befehl vergisst, hat einen Knoten, der zwar wieder online ist, aber dauerhaft keine HA-Dienste mehr übernimmt — kein Fencing-Problem mehr, aber ein Betriebsproblem, das sich still einschleicht, bis es jemand bemerkt.

Bei HostSpezial laufen solche Kernel- und Sicherheitsupdates in festen Patch-Fenstern von Montag bis Freitag — planbar für den Kunden, mit dem Wartungsmodus als festem, als Runbook dokumentiertem Bestandteil des Ablaufs, nicht als optionalem Zusatzschritt.

/07Wo es hakt: HA ist kein Backup, Split-Brain bleibt ein Risiko

Zwei Einschränkungen gehören ungeschönt in jede HA-Planung.

• HA schützt nicht vor Datenverlust: Ein HA-Cluster startet eine VM nach einem Knotenausfall neu — mit demselben Datenstand, den sie zuletzt auf dem SAN hatte. Wird die VM selbst durch Ransomware, einen fehlerhaften Patch oder einen Bedienfehler beschädigt, übernimmt die HA-Automatik diesen Schaden unverändert auf den neuen Knoten. Ein Disaster-Recovery-Konzept mit eigenem RPO und RTO ist deshalb kein optionales Extra zu HA, sondern eine eigene, zusätzliche Aufgabe.
• Split-Brain ist kein theoretisches Risiko, sondern der Grund für Fencing: Die in Abschnitt /03 zitierte „dangerous race condition" tritt genau dann ein, wenn Fencing fehlschlägt oder abgeschaltet ist — etwa weil ein Administrator es im Störfall manuell umgangen hat, um Zeit zu sparen. Jede Abkürzung an dieser Stelle hebt exakt den Schutz auf, den HA eigentlich bieten soll.
• Live-Migration und Snapshots vertragen sich noch nicht überall: Laut Proxmox-Roadmap ist es weiterhin offen, „the remaining restriction that prevents migrating VMs with snapshots on local volume-chain-enabled storages" aufzuheben. Vor jeder geplanten Migration auf Shared LVM mit Volume-Chain-Snapshots lohnt sich deshalb ein Blick, ob ein laufender Snapshot die Migration blockiert — ein weiterer Grund, Snapshots auf dem SAN als kurzes Testfenster zu behandeln, nicht als Dauerzustand.

Die rechnerische Grenze aus dem Kernaussagen-Kasten gehört in dieselbe ehrliche Rechnung: Mit typischen Fehlererkennungs- und Übernahmezeiten von rund zwei Minuten liegt die maximale Uptime laut Proxmox-Dokumentation bei etwa 99,999 Prozent — selbst bei fehlerfrei funktionierendem Fencing und sauberem Cluster-Netz. Wer mehr erwartet, erwartet etwas, das die Technik so nicht zusagt — und sollte die Erwartung an eine konkrete, vertraglich hinterlegte Zahl knüpfen, nicht an ein Gefühl.

/08Was der Betrieb durch HostSpezial abnimmt

HA-Konfiguration ist kein Zustand, den man einmal einrichtet und dann vergisst — Quorum, Fencing-Historie und Wartungsmodus-Reste wie in Abschnitt /06 beschrieben brauchen laufende Beobachtung. HostSpezial übernimmt dafür im Betrieb konkret: Monitoring von Quorum, Ring-Status und offenen Wartungsmodi, Patch-Fenster von Montag bis Freitag mit Live-Migration als Standardablauf, Rufbereitschaft außerhalb dieser Fenster für echte Störfälle, und den Betrieb aus dem Rechenzentrum Coburg mit Ausweichstandort Neustadt. Die Informationssicherheit dahinter ist nach ISO/IEC 27001:2024 zertifiziert (Zertifikat 202787) — ein geprüfter, kein selbst behaupteter Stand. Der durchgespielte Knotenausfall aus Abschnitt /03 und der Linktest aus Abschnitt /04 sind dabei keine einmaligen Abnahme-Schritte, sondern wiederkehrender Bestandteil unserer Wartungsroutine, damit sich an der Architektur nichts unbemerkt verschlechtert.

/09Wann Hochverfügbarkeit die richtige Wahl ist — und wann nicht

Hochverfügbarkeit auf dem SAN-Cluster lohnt sich, wenn die Grundarchitektur bereits stimmt: mindestens drei Quorum-Stimmen (drei Knoten oder zwei Knoten plus QDevice), ein dediziertes und redundantes Corosync-Netz, Multipath sauber konfiguriert, und ein Team oder Dienstleister, der Testausfälle tatsächlich fährt, statt nur zu hoffen, dass der Ernstfall ausbleibt.

Dagegen spricht

• Fehlendes drittes Standbein: Nur zwei Knoten ohne QDevice erreichen das Quorum-Modell aus Abschnitt /01 gar nicht erst verlässlich — HA bliebe Theorie.
• Kein geübter Wartungsablauf: Wer den Wartungsmodus aus Abschnitt /06 nicht kennt oder routinemäßig vergisst zu deaktivieren, produziert selbst die Störungen, die HA eigentlich verhindern soll.
• Fehlendes Backup-Konzept: HA ohne eigenständige Sicherung verschiebt im Ernstfall nur das Problem auf einen anderen Knoten, statt es zu lösen.

In der Praxis ist ein getestetes, dokumentiertes Wiederanlaufverfahren für viele Mittelständler mit überschaubarer Knotenzahl die robustere erste Investition — HA kommt dazu, sobald die Architektur aus dem Grundlagenartikel zum Managed-Proxmox-Cluster und ein geübtes Team stehen. Der Unterschied zwischen beiden ist am Ende weniger eine Frage der Lizenz oder der Proxmox-Version als eine Frage der Betriebsreife: Ein Cluster, dessen Quorum, Corosync-Netz und Wartungsablauf noch nicht verlässlich laufen, gewinnt durch HA zunächst nur zusätzliche Komplexität, keine zusätzliche Sicherheit. Unser Vorgehen bei neuen Kunden folgt deshalb immer derselben Reihenfolge: erst den durchgespielten Knotenausfall aus Abschnitt /03 und den Linktest aus Abschnitt /04 im Testbetrieb erfolgreich durchführen, dann HA für produktive Dienste scharf schalten — nie umgekehrt. Ein Cluster, der diesen Test im Testbetrieb nicht besteht, besteht ihn im Ernstfall erst recht nicht.

/10Häufige Fragen