Proxmox USV-Shutdown: Warum die Cluster-Reihenfolge zählt

Ein USV-Shutdown für einen einzelnen Proxmox-Host ist denkbar unkompliziert: Niedrigen Akkustand erkennen, Gastsysteme stoppen, Server ausschalten. In einem Cluster gestaltet sich die Situation deutlich anspruchsvoller: HA versucht womöglich, VMs auf Nodes neu zu starten, die sich selbst bereits auf das Herunterfahren vorbereiten; Ceph kann durch den Ausfall zu vieler OSDs blockieren; und ein Backup-Server verlangt nach einem völlig anderen API-Berechtigungsmodell.

Das Open-Source-Projekt PVE-UPS widmet sich genau diesen Herausforderungen in seinen jüngsten Versionen. Bei dem Werkzeug handelt es sich um eine schlanke LXC- oder Docker-Appliance, die eine USV über SNMP oder einen bestehenden Server für Network UPS Tools überwacht und Proxmox-Hosts über die REST-API automatisiert herunterfährt. Es benötigt keinen separaten Agenten auf den einzelnen Nodes und verbleibt standardmäßig im Dry-Run-Modus, bis der Administrator die Ausführung explizit scharfschaltet.

Neuere Releases ergänzen Zielsysteme für Proxmox Backup Server, multiple Webhooks, gründlichere Selbsttests und eine clusterfähige Shutdown-Logik im Betastadium. Diese Cluster-Steuerung ist die entscheidende Neuerung, denn sobald ein Verbund im Spiel ist, wird die Shutdown-Reihenfolge zu einem tragenden Bestandteil Ihrer Storage- und HA-Architektur.

Warum kann HA einen Stromausfall verschlimmern?

Proxmox HA existiert, um Dienste wiederherzustellen, wenn ein Node unerwartet verschwindet. Während eines gezielten, kontrollierten Cluster-Shutdowns ist genau diese automatische Wiederherstellung das Letzte, was man gebrauchen kann.

Stellen Sie sich einen Drei-Node-Cluster im Akkubetrieb vor. Node A erreicht seinen Schwellenwert und schaltet sich planmäßig ab. Ist HA weiterhin aktiv, interpretiert der Cluster diesen Vorgang als ungeplanten Ausfall und beginnt unverzüglich, Dienste auf Node B und Node C umzuziehen oder dort neu zu starten. Diese verbleibenden Nodes hängen jedoch an derselben begrenzten USV-Kapazität und stehen möglicherweise nur Minuten vor dem eigenen Herunterfahren. Der Cluster generiert zusätzliche Last, wo er eigentlich Last abwerfen sollte. Der neue Cluster-Modus von PVE-UPS nutzt daher den disarm-ha-Mechanismus von Proxmox, bevor der erste Node heruntergefahren wird.

Die aktuelle Proxmox-HA-Dokumentation beschreibt diesen entschärften Zustand: Watchdogs werden clusterweit freigegeben, und automatisches Fencing, Failover sowie Wiederherstellungen werden gestoppt. Proxmox warnt ausdrücklich davor, dass Dienste bei entschärftem HA ungeschützt sind; das Zeitfenster sollte daher minimal gehalten werden. Für einen kontrollierten Shutdown ist genau das erwünscht: Die Nodes gehen absichtlich offline, und der Cluster soll nicht versuchen, diesen Zustand panisch zu kompensieren.

PVE-UPS stuft diese Cluster-Vorbereitung als Beta ein und setzt Proxmox VE 9.2 oder neuer für disarm-ha voraus. In älteren 8.x-Umgebungen führt es eine reduzierte Vorbereitung durch, ohne vorzutäuschen, dass dieselben HA-Schutzfunktionen zur Verfügung stünden. Das ist ein durchdachter Ansatz, denn eine USV-Automatisierung darf während eines laufenden Stromausfalls niemals stillschweigend von Funktionen ausgehen, die die Plattform gar nicht bietet.

Für weiterführende Hintergründe zum Zusammenspiel von HA und Storage empfiehlt sich ein Blick in den Mr.PlanB Proxmox-Hub. Wie sich ein Cluster bei Stromausfall verhält, hängt maßgeblich von seiner ursprünglichen Konzeption ab.

Warum verändert Ceph die Shutdown-Reihenfolge?

In einem hyperkonvergenten Ceph-Cluster kann der Speicher bereits unbenutzbar werden, bevor der letzte Proxmox-Node heruntergefahren ist.

Die offizielle Ceph-Shutdown-Dokumentation von Proxmox beginnt mit einer Grundregel, die einleuchtend klingt, in Automatisierungsskripten jedoch häufig missachtet wird: Beenden Sie ausnahmslos alle Ceph-Clients zuerst. In einer hyperkonvergenten Proxmox-Umgebung sind diese Clients primär die VMs und Container, die auf RBD oder CephFS zugreifen. Erst wenn diese Systeme keinen I/O mehr erzeugen, sollte der Storage-Cluster auf das Abschalten vorbereitet werden. Proxmox empfiehlt anschließend, den Ceph-Zustand zu prüfen, das noout-Flag zu setzen (damit OSDs während des geplanten Shutdowns nicht als dauerhaft verloren gewertet werden) und die Nodes danach in kontrollierter Reihenfolge auszuschalten.

Ein herkömmlicher, unkoordinierter Shutdown pro Node scheitert hier regelmäßig. PVE-UPS bietet daher eine dedizierte Option für hyperkonvergentes Ceph. Der Ablauf folgt der strikten Abhängigkeitskette:

1. HA entschärfen.
2. Alle Gastsysteme im Cluster stoppen.
3. Ceph-Wartungsvorbereitung aktivieren.
4. Nodes in der konfigurierten Reihenfolge herunterfahren.

Schritt 2 markiert die Schwachstelle primitiver Skripte. Wenn Node A lediglich seine eigenen Gäste stoppt und abschaltet, während auf Node B und Node C noch VMs laufen, kann der verbleibende Ceph-Pool unter die Mindestanzahl an Replikaten fallen, die für I/O erforderlich ist. Die verbliebenen VMs blockieren augenblicklich auf Speicherebene. Node B versucht anschließend, Gäste herunterzufahren, deren virtuelle Festplatten nicht mehr reagieren, wodurch der Shutdown-Prozess einfriert, während sich die USV-Batterie unaufhaltsam leert. Ein solches Szenario ist ungleich verheerender als ein einzelner Host, der einen Ausschaltbefehl ignoriert.

Warum nicht einen HA-Node so lange wie möglich betreiben?

In bestimmten Szenarien ist genau das die sinnvollste Strategie. Ein Administrator schilderte ein alternatives Notfallkonzept: Sinkt die USV-Restlaufzeit auf etwa die Hälfte, werden zwei der drei HA-Nodes planmäßig heruntergefahren und sämtliche Gastsysteme auf dem verbleibenden Host konsolidiert. Dieser letzte Server läuft weiter, bis nur noch wenige Minuten Akkukapazität verbleiben, und schaltet sich erst dann ab.

Das ist ein absolut pragmatischer Entwurf, sofern die gesamte Last auf einen Node passt und der Storage auch nach dem Abschalten der übrigen Knoten uneingeschränkt funktioniert. Für einen hyperkonvergenten Ceph-Cluster eignet sich dieser Weg jedoch nicht, da Rechen-HA und verteilter Speicher unterschiedliche Abhängigkeiten besitzen. Wenn der letzte Host auf Ceph-OSDs angewiesen ist, die mit den ersten beiden Nodes abgeschaltet wurden, bringt sein Weiterbetrieb keinerlei Nutzen: Die VMs mögen rein rechnerisch noch laufen, ihr Storage ist jedoch tot.

Bei externem NFS, iSCSI, lokaler ZFS-Replikation oder Architekturen ohne Ceph ergibt eine solche Lastkonsolidierung dagegen viel Sinn. Das koordinierte Herunterfahren des gesamten Clusters als geschlossene Einheit sollte eine bewusste Richtlinie sein, die Sie passend zu Ihrem Setup wählen. PVE-UPS macht dies konfigurierbar, was die einzig richtige Entscheidung ist.

Was ändert sich für Proxmox Backup Server?

PVE-UPS kann Proxmox Backup Server nun als vollwertiges, eigenständiges Shutdown-Ziel verwalten, statt PBS fälschlicherweise wie einen normalen PVE-Node zu behandeln.

Die APIs ähneln sich zwar optisch, die Berechtigungsmodelle weichen jedoch voneinander ab. PVE nutzt Sys.PowerMgmt für das Herunterfahren des Hosts. PBS verwendet stattdessen Sys.PowerManagement, wobei sich auch die API-Pfade und die Token-Autorisierung unterscheiden. Wer früher ein PBS-System wie einen PVE-Host eintrug, scheiterte regelmäßig mit der Fehlermeldung eines vermeintlich ungültigen API-Tokens. Jeder Host-Eintrag besitzt nun ein Typfeld, sodass gemischte Umgebungen aus PVE und PBS präzise abgebildet werden können.

Hierbei existiert auch ein Sicherheitsaspekt. Die Dokumentation von PVE-UPS weist darauf hin, dass PBS keine eng gefasste Berechtigung ausschließlich für das Herunterfahren anbietet, wie es bei PVE der Fall ist. Die dokumentierte PBS-Konfiguration vergibt eine Admin-Rolle beschränkt auf /system/status. Das Projekt mahnt Produktivanwender ausdrücklich zur Vorsicht, bevor sie einer einzelnen Appliance Zugriff auf Virtualisierungs-Hosts und Backup-Server gleichzeitig gewähren.

Dieser Rat ist fundiert, schließlich betreibt man einen Backup-Server gerade deshalb, um im Ernstfall über eine unabhängige Wiederherstellungsmöglichkeit zu verfügen. Wenn dieselbe Management-Appliance über dasselbe Netzwerk Produktiv-Hosts und Backups steuern kann, reicht eine Fehlkonfiguration oder Kompromittierung deutlich weiter. In Produktivumgebungen ist ein separater Abschaltpfad oder ein eigenes Netzwerksegment für PBS oft die sicherere Wahl.

Warum verwirrte die Privilege Separation bei API-Tokens?

Eine funktionierende API-Verbindung ist noch kein Beweis dafür, dass das Token den Host tatsächlich herunterfahren darf.

Ein Anwender richtete die dedizierte Power-Management-Rolle vorschriftsmäßig ein und erhielt dennoch die Warnung, dass Sys.PowerMgmt nicht bestätigt werden konnte. Die Ursache lag in der Privilege Separation für Proxmox-API-Tokens. Ist diese aktiv, benötigt ein Token eigene ACL-Einträge und erbt nicht automatisch sämtliche Rechte seines übergeordneten Benutzers. Die PVE-UPS-Anleitung weist dem dedizierten Benutzer die Power-Rolle zu und generiert das Shutdown-Token mit deaktivierter Privilege Separation, wodurch das Token die Berechtigungen des Benutzers übernimmt.

Der entsprechende Befehl nutzt den Parameter --privsep 0, was der Entwickler als beabsichtigten Schritt für das dokumentierte Setup bestätigte. Solche Berechtigungsprobleme sollten zwingend bei der Ersteinrichtung auffallen und nicht erst, wenn die USV bereits auf Batterie läuft. Die verbesserten Selbsttests in der neuen Version fangen genau diese Fehlerbilder frühzeitig ab.

Was deckt der neue Selbsttest tatsächlich auf?

Er überprüft Detailkonfigurationen, die sich sonst erst während eines echten Stromausfalls als fehlerhaft erweisen würden, wie etwa den exakten Proxmox-Node-Namen. Weist die Konfiguration eine falsche Groß-/Kleinschreibung oder ein überflüssiges Domain-Suffix auf, verläuft ein simpler Verbindungstest oft noch positiv, bis der eigentliche Shutdown-Aufruf einen Node-Namen anspricht, den die API nicht kennt. Der neue Selbsttest gleicht den konfigurierten Namen direkt mit der API ab.

Zudem wird der Cluster-Status einmal pro Verbund validiert, automatisch nach dem erneuten Scharfschalten der Appliance ausgeführt und durch eine manuelle Schaltfläche zur sofortigen Ausführung ergänzt.

Neben der Ablaufsteuerung für Cluster-Shutdowns mögen dies wie untergeordnete Details wirken, in der Praxis wiegen sie oft schwerer. Administratoren hoffen darauf, dass eine USV-Automatisierung so gut wie nie zum Einsatz kommt. Konfigurationsfehler bleiben dadurch monate- oder jahrelang unbemerkt. Je länger der zeitliche Abstand zwischen realen Notfällen ist, desto unverzichtbarer werden automatisierte Selbsttests.

Ein Anwender berichtete, dass das Tool seine Server während des ersten Stromausfalls seit Jahren fehlerfrei heruntergefahren habe. Das ist zwar nur ein einzelner Erfahrungsbericht, veranschaulicht das Grundproblem jedoch perfekt: Ein Notfall-Workflow bleibt extrem lange ungenutzt und ist im entscheidenden Moment plötzlich das Einzige, worauf es ankommt.

Warum sind mehrere Webhooks bei einem Stromausfall wichtig?

Die Information "Der Shutdown wurde eingeleitet" ist nur eines von vielen Ereignissen, über die Administratoren benachrichtigt werden möchten. PVE-UPS unterstützt mittlerweile mehrere Webhook-Ziele anstelle eines einzelnen Endpunkts. Jedes Ziel erhält ein eigenes Format, individuelle Schweregradfilter, Testfunktionen und optionale Authentifizierungs-Header. Vordefinierte Vorlagen existieren für Slack, Discord, ntfy, Microsoft Teams, JSON und Klartext, ergänzt durch benutzerdefinierte Templates für eigene Endpunkte.

Ein fehlgeschlagener Webhook wird im Ereignisprotokoll, auf der Zielkarte und im Dashboard unübersehbar hervorgehoben. Genau so muss Infrastruktur-Automatisierung arbeiten: Ein Benachrichtigungssystem, das Meldungen lautlos verschluckt, ist gefährlicher als gar keines, da es falsche Sicherheit vortäuscht.

Bei einem Stromereignis sollten unterschiedliche Dringlichkeiten an verschiedene Kanäle geleitet werden. Ein Status "USV auf Batterie" genügt in einem Chat-Kanal, während "Cluster-Shutdown initiiert" oder "Host-Shutdown fehlgeschlagen" sofortige Eskalationswege erfordern. Die Benachrichtigungseinstellungen bieten hierfür inzwischen ausreichend granulare Optionen.

Sollte PVE-UPS innerhalb des Clusters laufen, den es herunterfährt?

Das ist durchaus möglich, doch der genaue Standort erfordert Bedacht. Das Projekt wird üblicherweise als unprivilegierter LXC-Container auf einem der geschützten Proxmox-Nodes betrieben, wobei die Shutdown-Reihenfolge den Host der Appliance stets an letzter Stelle ausschaltet.

In einem Ceph-Cluster existiert eine weitere Bedingung: Der PVE-UPS-Gast darf niemals von dem Ceph-Storage abhängen, den er herunterfahren soll. Laut Dokumentation verweigert der Installer die Installation auf einem Ceph-Root-Dateisystem, es sei denn, der Administrator erzwingt dies ausdrücklich. Diese Prüfung ist absolut sinnvoll: Liegt das Image der Appliance auf Ceph und der Storage fällt mitten im Shutdown unter min_size, friert der steuernde Container ein, bevor die restlichen Befehle abgesetzt werden können. Platzieren Sie den PVE-UPS-Gast in einer Ceph-HCI-Umgebung daher immer auf lokalem Speicher.

Was sollten Sie testen, bevor Sie einer USV-Automation vertrauen?

Warten Sie keinesfalls auf den ersten echten Stromausfall. Beginnen Sie im Dry-Run-Modus und validieren Sie jeden einzelnen Integrationspfad:

• Überprüfen Sie, ob die ausgelesenen USV-Werte plausibel sind.
• Stellen Sie sicher, dass Akkustand und Restlaufzeit-Schwellenwerte unter realer Systemlast realistisch kalkuliert sind.
• Testen Sie jedes einzelne PVE-API-Token.
• Prüfen Sie den PBS-Pfad separat, sofern Sie Proxmox Backup Server einsetzen.
• Testen Sie sämtliche Webhook-Ziele.
• Führen Sie den integrierten Selbsttest aus.
• Verifizieren Sie, dass die hinterlegten Node-Namen exakt den API-Namen entsprechen.
• Prüfen Sie bei aktivem HA, ob der Cluster den erwarteten entschärften Zustand zuverlässig erreicht.
• Testen Sie bei Ceph das Herunterfahren der Gäste und die Wartungsvorbereitung im Testlabor oder während eines Wartungsfensters.

Führen Sie anschließend einen kontrollierten Stromausfalltest durch. Trennen Sie die USV bei laufenden Servern von der Steckdose und beobachten Sie den gesamten Ablauf. Der erste abgesetzte Shutdown-Befehl sagt noch wenig aus. Kontrollieren Sie, ob alle Gastsysteme sauber stoppen, Ceph bis zum Beenden des letzten Clients ansprechbar bleibt, HA keine Workloads neu startet, die Hosts in der gewünschten Reihenfolge herunterfahren und die USV selbst für den langsamsten Host genügend Restkapazität bereithält.

Ein Proxmox Health Check deckt etliche Schwachstellen im Cluster bereits im Vorfeld auf, die praktische Verifikation des Shutdown-Pfads ersetzt er jedoch nicht.

Batteriewerte auslesen ist der einfache Teil der USV-Automation

Verglichen mit der präzisen Koordination eines Cluster-Shutdowns ist die reine USV-Überwachung simpel. SNMP liefert Laufzeiten und NUT visualisiert Akkuzustände. Die anspruchsvolle Aufgabe besteht darin, die Folgeaktionen zu steuern, wenn die Infrastruktur aus HA, verteiltem Speicher, Backup-Servern und mehreren Hosts mit voneinander abhängigen Diensten besteht.

PVE-UPS gewinnt an Relevanz, weil seine neueren Versionen diese Orchestrierung systematisch adressieren. Der PBS-Support beseitigt Inkompatibilitäten bei den API-Rechten, multiple Webhooks sorgen für Transparenz und verbesserte Selbsttests decken Konfigurationsmängel rechtzeitig auf. Die clusterfähige Beta-Funktion markiert den bisher ehrgeizigsten Schritt.

Ein Proxmox-Cluster ist weit mehr als drei eigenständige Server, die sich lediglich eine Weboberfläche teilen. Bei einem Stromausfall beeinflussen sich HA-Status, VM-Zustände, Ceph-Gesundheit, Storage-Verfügbarkeit und Shutdown-Reihenfolge gegenseitig. Stimmt die Abfolge nicht, arbeitet der Cluster gegen das eigene Herunterfahren. Stimmt sie, erfüllt die USV ihren Zweck und verschafft allen Systemen ausreichend Zeit für einen geordneten Stillstand.