Hochverfügbarkeit

Was HA leistet

• Node fällt aus → betroffene VM startet automatisch auf einem anderen, gesunden Node neu – auch nachts oder am Wochenende, ohne dass jemand eingreifen muss
• Zwei Dienste teilen sich die Arbeit: der CRM (Cluster Resource Manager, aktiv auf dem aktuellen Master) entscheidet, was passieren soll, der LRM (Local Resource Manager) auf jedem Node setzt es lokal um
• Kein unterbrechungsfreier Betrieb per se – die VM startet neu, laufende Verbindungen wie RDP-Sitzungen oder offene Datenbank-Transaktionen gehen dabei verloren
• HA-Gruppen (/etc/pve/ha/groups.cfg) legen fest, auf welchen Nodes eine Ressource bevorzugt läuft – nützlich, wenn VMs aus Lizenz- oder Performance-Gründen an bestimmte Hardware gebunden bleiben sollen

RTO vs. RPO

• RTO (Recovery Time Objective): wie schnell ist der Betrieb wieder online – bildlich, wie lange das Geschäft geschlossen bleibt
• RPO (Recovery Point Objective): wie viele Daten gehen im schlimmsten Fall verloren – bildlich, wie viele der letzten Buchungen im Brandfall verloren gehen
• Zwei getrennte Ziele, die unterschiedliche Stellschrauben betreffen: RTO hängt an Erkennung, Fencing und VM-Boot, RPO hängt fast ausschließlich am gewählten Storage
• Beide Werte sollten vorab mit dem Kunden konkret beziffert werden, z. B. „RTO unter 2 Minuten", „RPO unter 1 Minute" – ohne Zahl bleibt „hochverfügbar" eine leere Behauptung
• Faustregel: ein kleineres RPO kostet meist mehr Storage-Aufwand (Ceph statt Replikation), ein kleineres RTO eher schnellere Hardware und schlankere VM-Images

Ablauf eines Failovers

• Erkennung: der Cluster stellt über Corosync/Quorum fest, dass ein Node tot ist – nicht beim ersten verpassten Herzschlag, sondern erst nach Ablauf des konfigurierten Token-Timeouts, um Fehlalarme durch kurze Hänger zu vermeiden
• Fencing: der alte Node wird sicher stillgelegt, in der Praxis meist über den Software-Watchdog (siehe Modul 7) – dieser Schritt dauert bei Proxmox typischerweise bis zu rund einer Minute, weil der Watchdog-Timeout bewusst konservativ eingestellt ist
• Erst wenn das Fencing bestätigt ist, gibt der HA-Manager die Ressource für einen Neustart frei – eine bewusste Sicherheitsbremse, lieber kurz warten als riskieren, dass die VM doppelt läuft
• Neustart der VM auf einem gesunden Node, ausgewählt nach den in den HA-Gruppen hinterlegten Präferenzen und der aktuellen Auslastung der verbleibenden Nodes
• Alle drei Schritte laufen automatisch über ha-manager, nachvollziehbar per ha-manager status oder in der Web-GUI unter „HA"

„Sekunden statt Minuten" – ehrlich

• RTO = Erkennung + Fencing + VM-Boot – drei Phasen, die sich addieren, nicht überlappen
• Sekunden-Klasse für Erkennung und Fencing erreichbar, in Summe aber oft schon 30 bis 90 Sekunden allein für diese beiden ersten Schritte, je nach Token- und Watchdog-Timeout
• Der VM-Boot bleibt der bestimmende Faktor für die Gesamtzeit: ein schlankes Linux mit wenig Diensten bootet in 10–20 Sekunden, ein „fettes" Windows-Server-System mit vielen Diensten kann durchaus 1–2 Minuten brauchen
• Konsequenz für die Praxis: schlanke, zweckgebundene VM-Images verbessern die reale HA-Zeit oft mehr als jede Feinjustierung am Cluster selbst
• „Sekunden statt Minuten" bezieht sich ehrlicherweise auf die Cluster-Reaktion, nicht zwangsläufig auf die gesamte gefühlte Ausfallzeit bis zur wieder erreichbaren Anwendung

Voraussetzung: Storage

• Shared Storage (Ceph) → RPO 0: die Daten liegen durch die verteilte Speicherung ohnehin auf mehreren Nodes gleichzeitig, ein Node-Ausfall ändert daran nichts
• Lokale Replikation → RPO größer 0, abhängig vom Intervall – Proxmox repliziert per pvesr standardmäßig alle 15 Minuten, das Intervall lässt sich aber bis auf 1 Minute verkürzen
• Rechenbeispiel: bei 1-Minuten-Intervall gehen im ungünstigsten Fall die Änderungen der letzten bis zu 60 Sekunden vor dem Ausfall verloren – bei 15 Minuten entsprechend bis zu 15 Minuten
• Kürzere Replikationsintervalle kosten mehr I/O- und Netzwerk-Last auf dem Ziel-Node – das Intervall ist ein Kompromiss zwischen RPO und Systemlast, nicht beliebig auf null drehbar
• Der Storage entscheidet über den maximalen Datenverlust – RTO und RPO hängen an komplett unterschiedlichen Bauteilen der Architektur
• „Shared Storage" heißt in der Proxmox-Praxis meist HCI mit Ceph: die Nodes bilden über ihre lokalen Platten gemeinsam einen verteilten Storage-Cluster, es ist kein separates externes SAN nötig – der eigentliche vSAN-Ersatz für HA. Details dazu in Modul 3 („HCI: vSAN-Ersatz mit Ceph")

Voraussetzungen für Live-Migration

• Live-Migration ist der geplante, manuelle Umzug einer laufenden VM auf einen anderen Node – zu unterscheiden vom automatischen HA-Failover nach einem Ausfall, hat aber ähnliche technische Voraussetzungen
• CPU-Typ muss zwischen den Nodes kompatibel sein: host erlaubt Live-Migration nur zwischen identischer Hardware, x86-64-v2/x86-64-v3 auch zwischen unterschiedlichen CPU-Generationen (siehe Modul 2, „CPU-Typ in der VM")
• Shared Storage (z. B. Ceph) oder zumindest replizierter Storage (ZFS-Replikation per pvesr) nötig, damit die VM-Disk auf dem Ziel-Node bereits vorliegt bzw. innerhalb des Replikationsintervalls schnell verfügbar gemacht werden kann
• Fehlt eine dieser Voraussetzungen – inkompatibler CPU-Typ oder Storage nur lokal ohne Replikation – ist lediglich eine Offline-Migration möglich: die VM wird gestoppt, die Disk kopiert und die VM auf dem Ziel-Node neu gestartet, mit spürbarer Downtime

Ausfall-Zeitvergleich (Node-Ausfall)

Auffällig: fast alle etablierten Lösungen lösen HA nach demselben Muster (Erkennung → Fencing/Isolation → Neustart). Der große Zeitunterschied entsteht erst bei VMware Fault Tolerance, das als einzige Technik kein Neustart-, sondern ein Live-Spiegel-Modell fährt.

Die 0-Sekunden-Wahrheit

• Echte 0 Sekunden nur mit VMware Fault Tolerance – mit harten Limits: begrenzte vCPU-Anzahl je geschützter VM, zusätzlicher Ressourcenbedarf durch die permanent mitlaufende Schatten-VM und spürbarer Lizenzaufpreis
• Alle „HA-Restart"-Lösungen (auch Proxmox, VMware vSphere HA, Hyper-V Failover Cluster) brauchen einen VM-Boot – der Unterschied zwischen den Anbietern liegt eher in Details als im Grundprinzip
• Für echte Unterbrechungsfreiheit: App-HA innerhalb der VM bzw. auf Anwendungsebene einplanen, z. B. ein Datenbank-Cluster mit mehreren aktiven Knoten (etwa Galera oder Patroni) oder zwei Webserver hinter einem Loadbalancer

Empfehlung für KMU

• 2 Nodes + QDevice + Replikation: Sekunden-Klasse-RTO, kleines und kalkulierbares RPO (abhängig vom Replikationsintervall) – für die meisten kleinen Firmen der pragmatische Einstieg
• 3+ Nodes + Ceph: ebenfalls Sekunden-Klasse-RTO, dazu RPO 0, weil die Daten ohnehin verteilt liegen – mehr Hardware- und Netzaufwand, dafür echte Nullverlust-Sicherheit
• Leitfrage für die Beratung: „Was passiert, wenn die letzte Minute an Daten fehlt?" – beim Handwerksbetrieb meist ein Schulterzucken, bei einer Arztpraxis mit laufender Abrechnung oder einem Online-Shop mit Bestellungen ein echtes Problem
• Sizing richtet sich nach dem tatsächlichen Schutzbedarf, nicht nach Technik-Vorliebe: Ceph beim Handwerksbetrieb ist teure Über-Ausstattung, Replikation bei der Arztpraxis ein vermeidbares Risiko
• Die Entscheidung sollte vor dem Hardware-Kauf fallen, nicht danach – Node-Anzahl und Storage-Netz für Ceph sind deutlich aufwendiger nachzurüsten als von Anfang an einzuplanen
• Für das KMU-Referenz-Szenario dieses Lernbereichs (1–2 Nodes, 4–6 VMs, siehe Modul 0) heißt das konkret: 2 Nodes + QDevice + Replikation deckt die Redundanz-Anforderungen der allermeisten Betriebe dieser Größe zuverlässig ab, ohne den Aufwand eines Ceph-Aufbaus