Eine USV kauft Zeit. Ob der USV-Shutdown gelingt, entscheidet die Reihenfolge, in der du abschaltest und wieder hochfährst.
- Eine USV kauft nur Zeit, ob zehn Minuten oder drei Stunden. Ohne geordneten USV-Shutdown stehen Datenbanken, Cluster und Hochverfügbarkeit nach dem Stromausfall im Zweifel schlechter da als vorher.
- Testen ist Pflicht: Die gefährlichsten Fehler stecken in Wegen, die nur im Ernstfall benutzt werden. Und bei NUT lohnt es sich, genau hinzuschauen, denn auch die Clients entscheiden selbst, ob sie herunterfahren.
- Nach dem ersten Lauf kommt die Nacharbeit: Oft klärt erst der Wiederanlauf, was noch fehlt. Wer alles gleichzeitig startet, überlastet den eigenen Cluster.
- Reihenfolge schlägt Tempo: erst Dienste mit Abhängigkeiten, dann der Rest, und bei jedem Schritt prüfen, ob der Vorgänger wirklich oben ist.
- So viel automatisch wie möglich: Erkennen, Melden, Herunterfahren, Wecken und Hochfahren laufen ohne Eingriff. Beim Menschen bleiben bewusst der Notschalter, die Einordnung der Server und jede Installation.
Die USV löst nur das halbe Problem
Ich arbeite seit 2008 in der IT, und eine USV stand fast überall im Serverraum. Dass Server eine brauchen, muss man niemandem mehr erklären. Was ich dagegen selten gesehen habe: einen durchdachten Plan dafür, was in den Minuten oder Stunden passiert, die sie dir verschafft. Und wer sich darum kümmert, wenn um drei Uhr nachts niemand im Büro ist. Genau hier setzt ein durchdachter USV-Shutdown an.
Unsere Umgebung ist eine typische Linux-Landschaft: ein Proxmox-Cluster mit Hochverfügbarkeit, darauf Datenbankcluster, ein OpenSearch-Cluster und eine Reihe von Anwendungen, die alle voneinander abhängen. Die USVs sind ans Netzwerk angebunden, ein eigener NUT-Server übernimmt die Rolle des Dirigenten. Wer hier einfach den Stecker zieht oder alle Server gleichzeitig herunterfährt, riskiert beschädigte Indizes, einen Split-Brain im Datenbankcluster und einen Wiederanlauf, der länger dauert als der Stromausfall selbst.
Wir haben deshalb ein geordnetes Herunterfahren gebaut, das auf NUT (Network UPS Tools) aufsetzt. NUT war die einzige aktiv gepflegte und herstellerunabhängige Option im Vergleich mit den Herstellerlösungen. Warum ich bei solchen Bausteinen auf Open Source setze, habe ich in Open Source ist keine Blackbox beschrieben. Gebaut heißt hier: gedacht, getestet, verworfen, neu gedacht. Drei Dinge habe ich dabei gelernt: testen, bei NUT genau hinschauen und nacharbeiten.
Testen: Ohne echten Lauf ist es nur ein Plan
Meine Erfahrung: Ein Shutdown-Skript, das nie unter echten Bedingungen gelaufen ist, ist eine Annahme, keine Absicherung. Trockentests und Simulationen sind wichtig, sie zeigen aber nur, ob die Logik stimmt. Ob jeder Zugang, jeder Benutzer und jede Berechtigung im Ernstfall passt, zeigt erst der echte Lauf.
Ein typisches Beispiel: Die Automatik meldet sich per SSH an den Hosts an, um die Gäste herunterzufahren. In der SSH-Konfiguration ihres Dienstnutzers steht aber ein falscher Benutzer, etwa einer, der von außen gesperrt ist. Im Alltag fällt das nie auf, denn dieser Weg wird nur im Ernstfall benutzt. Getestet wurde vorher vielleicht mit einem anderen Benutzer, und der funktionierte. Verwandt damit ist das zu optimistische Log, das „erfolgreich“ schreibt, sobald etwas versucht wurde, und nicht erst, wenn es geklappt hat.
Deshalb gilt: Getestet wird genau der Pfad, den die Automatik später nimmt, mit demselben Benutzer und derselben Konfiguration. Erst im Dry-Run, der alles durchspielt und nichts anfasst, dann im geplanten Test mit echtem Abschalten.
Hinschauen: NUT hat seine Eigenheiten
NUT ist mächtig und herstellerunabhängig. Es hat aber Eigenheiten, die du kennen solltest, bevor du dich darauf verlässt. Die wichtigste: Die Clients entscheiden selbst, ob sie herunterfahren, nicht nur der Server.
Ein Beispiel: Nach dem regelmäßigen Selbsttest der USV kann das Statusflag CAL stehen bleiben (NUT-Issue #2168). Wird dann der NUT-Dienst neu gestartet, verlieren die Clients kurz die Verbindung, und upsmon hält die USV für tot. Die Server fahren herunter, obwohl Strom da ist (Issue #2794). Ein Fix existiert, ist aber noch nicht in allen Distributionen angekommen.
Links ein Beispiel dafür, wie es nicht laufen soll: Strom ist da, trotzdem fahren die Server herunter, denn bei NUT entscheiden auch die Clients selbst. Rechts zwei der Regeln aus dem Text, die diese Kette unterbrechen.
Daraus folgen ein paar einfache Regeln. Den NUT-Dienst nie neu starten, solange Clients verbunden sind. Auf den Clients alle USVs überwachen statt nur einer, dann bleibt immer eine gesunde Versorgung stehen. Selbsttest und Kalibrierung als eigene Zustände erkennen und nur melden. Und die NUT-Version und ihre offenen Fehler im Blick behalten.
Nacharbeiten: Nach dem ersten Lauf geht die Arbeit erst los
Was viele unterschätzen: Das Herunterfahren ist der leichtere Teil. Ein Shutdown kann sauber durchlaufen, und trotzdem kommt die Umgebung nicht sauber wieder hoch. Proxmox wartet beim Start zwar einmal kurz, staffelt danach aber nichts, solange du keine Startreihenfolge festlegst. Und selbst die Startreihenfolge von Proxmox gilt nur pro Host und nicht für Gäste, die von der Hochverfügbarkeit verwaltet werden. Starten alle Gäste gleichzeitig, sind die Anwendungen schneller oben als die Datenbank, hängen in Fehlerzuständen, und die Hochverfügbarkeit beginnt, Dienste zu verschieben.
Das ist kein Scheitern. Genau so werden Abläufe besser: Nach jedem Test und jedem echten Lauf werden die Logs ausgewertet, Ursachen geklärt und der Ablauf angepasst. Unser Shutdown-Skript ist inzwischen viele Versionen weiter, und jede davon hat etwas aus einem Test oder einer Beobachtung übernommen. Wichtig ist nur, die Dokumentation gleich mit nachzuziehen. Sonst wird sie zu genau der Schrankware, über die ich in Prozesse gestalten: Lieferware statt Schrankware geschrieben habe.
Was wir daraus gebaut haben: USV-Shutdown mit NUT und Proxmox
Aus diesen Überlegungen ist unser Konzept entstanden, das auf drei Bausteinen steht: früh genug starten, in der richtigen Reihenfolge stoppen und beim Hochfahren aktiv prüfen statt zu hoffen.
Früh genug starten, aber nur bei echtem Ausfall. Wie viel Zeit bleibt, hängt von der USV ab. Deshalb arbeiten wir nicht mit einer festen Prozentzahl, sondern mit mehreren Kriterien, die sich an die eigene Hardware anpassen lassen. Ein echter Ausfall liegt nur vor, wenn keine USV mehr am Netz ist. Dann startet der Shutdown beim ersten erfüllten Kriterium. Typische Kriterien sind: Der Ausfall dauert länger als eine festgelegte Zeit, Restlaufzeit oder Ladung fallen unter einen Schwellwert oder die USV meldet „Batterie schwach“. Hat deine USV drei Stunden Laufzeit, kannst du die Dauer deutlich länger ansetzen und kurze Ausfälle überbrücken, ohne überhaupt etwas herunterzufahren. Solange eine USV am Netz ist, etwa bei einem Selbsttest, einer Kalibrierung oder einer Wartung, gibt es nur eine Meldung und nie einen Shutdown.
Ein echter Ausfall liegt nur vor, wenn keine USV mehr am Netz ist. Selbsttest, Wartung oder ein Kommunikationsfehler lösen nur eine Meldung aus. Den Shutdown startet dann das erste erfüllte Kriterium, die Schwellwerte lassen sich an die eigene USV anpassen.
In der richtigen Reihenfolge stoppen. Der Ablauf folgt den Abhängigkeiten, nicht dem Alphabet:
- Karenzzeit und Notschalter: Bis zuletzt lässt sich der ganze Ablauf von Hand stoppen. Kommt der Strom in dieser Zeit zurück, bricht der Lauf ebenfalls ab.
- Datenbankrolle prüfen und bei Bedarf einen Switchover durchführen.
- Updates anhalten und die Hochverfügbarkeit für die betroffenen Gäste ruhigstellen, damit HA nicht gegen den Shutdown arbeitet. Updates sind wichtig, wie ich in Never change a running system geschrieben habe, aber nicht mitten im Stromausfall.
- Anwendungen parallel herunterfahren, mit begrenzter Wartezeit.
- Erst wenn die Anwendungen unten sind, folgt OpenSearch und danach die Datenbanken. Wer Daten liefert, geht erst, wenn niemand mehr darauf zugreift.
- Zum Schluss die Hosts. Was der Datenbankcluster zum Arbeiten braucht, bleibt bis zuletzt an.
Beim Hochfahren aktiv prüfen. Die Hosts werden erst geweckt, wenn wieder mindestens eine USV am Netz ist, und zwar nacheinander. Danach trägt jeder Gast eine Stufe, vom Kern bis zu den weniger kritischen Anwendungen. Der Kern (Koordination, Datenbanken, OpenSearch) startet zuerst, und zwar nacheinander mit Bereitschaftsprüfung. Erst wenn diese Dienste wirklich bereit sind, geht es mit den Anwendungen weiter. Diese Prüfung ersetzt die feste Wartezeit. Die Stufen pflegen wir in einer kleinen Weboberfläche per Drag and Drop, inklusive Wartungsmodus: Ein Gast oder Host in Wartung wird beim Hochfahren nicht gestartet.
Erst werden die Hosts geweckt, also die Server, auf denen die Gäste laufen. Dann starten die Gäste: zuerst der Kern, Dienst für Dienst mit Bereitschaftsprüfung, danach die Anwendungen Stufe für Stufe, von kritisch bis weniger kritisch. Die Prüfung ersetzt die feste Wartezeit.
Selbsttests ernst nehmen. Selbsttest und Kalibrierung der USV werden jetzt aktiv erkannt und nur gemeldet. Die Nodes überwachen alle USVs statt nur einer, damit ein hängendes Flag allein keinen Shutdown auslöst. Neue Skriptstände laufen zuerst im Dry-Run, der alles durchspielt und nichts anfasst, danach erst im Livebetrieb.
Automatisch, wo es geht, von Hand, wo es zählt
Das Ziel ist klar: Im Ernstfall soll niemand eingreifen müssen, auch nicht nachts oder am Wochenende. Stromausfälle halten sich nicht an Bürozeiten. Deshalb läuft die ganze Kette vom Erkennen bis zum letzten gestarteten Gast automatisch. Wo eine Entscheidung Wissen über die eigene Umgebung braucht, bleibt sie bewusst beim Menschen.
Im Ernstfall läuft die ganze Kette automatisch, auch nachts oder am Wochenende. Wer will, schaut bei Warnungen hin oder bricht von Hand ab. Wo eine Entscheidung Wissen über die eigene Umgebung braucht, bleibt sie beim Menschen, und manches automatisiert bewusst niemand.
Mindestens genauso wichtig finde ich, was wir bewusst nicht automatisieren. Die Reihenfolge beim Herunterfahren steht fest im Skript. Die Oberfläche zeigt sie an, ändert sie aber nicht, denn Stabilität geht hier vor Komfort. Die Stufen der Server schlägt Proxmox über Tags vor, übernommen werden sie aber nur per Klick und nie von selbst. Neue Versionen installiert ein Admin von Hand, ohne Root-Login und immer mit einem Weg zurück. Skripte und Konfiguration liegen versioniert im Git, und Änderungen unter /etc/ lassen sich nachvollziehen, so wie ich es in /etc/ voll im Griff – mit etckeeper beschrieben habe. Und den NUT-Dienst startet keine Automatik neu, solange Nodes verbunden sind. Ein Neustart zur falschen Zeit kann sonst mehr anrichten als der Stromausfall selbst.
Dahinter steckt eine Haltung, die ich jedem empfehle: Im Zweifel meldet die Automatik lieber, als dass sie handelt. Sind alle USVs gleichzeitig nicht lesbar, fährt nichts herunter, denn ein Kommunikationsfehler ist kein Stromausfall. Erst wenn die Batterie wirklich knapp wird, hat Handeln Vorrang vor Abwarten.
Fazit: Teste deinen USV-Shutdown, bevor der Ernstfall es tut
Am Ende läuft es auf drei Dinge hinaus: testen, bei NUT genau hinschauen und nach jedem Lauf nacharbeiten. Die Gefahr liegt selten im Stromausfall selbst, sondern in den Abhängigkeiten drumherum. Ein Notfallprozess, der nie unter echten Bedingungen gelaufen ist, ist Schrankware. Und ein Log, das Erfolg meldet, ohne ihn zu prüfen, ist schlimmer als gar keins.
Das ist übrigens derselbe Gedanke wie bei jedem guten Prozess: Er muss gelebt und ausprobiert werden, am besten von denen, die ihn im Ernstfall brauchen. Bei uns heißt das: Dry-Run, Notschalter und Stufen statt Hauruck.
Genau diese Erfahrung bringen wir bei Honicon mit. Wir schauen gemeinsam mit dir auf die Abhängigkeiten in deiner Umgebung, kennen die Stolperfallen rund um USV, NUT und Proxmox und sorgen dafür, dass dein Notfallablauf im Ernstfall wirklich trägt. Wenn du dir dafür die extra Portion Know-how ins Haus holen willst, melde dich gern bei uns.
