In einem früheren Artikel habe ich geschrieben, dass mein Homelab einen echten Stromausfall ohne Unterbrechung überstanden hat. Das stimmt. Gemessen habe ich dabei aber nichts. Ich weiß nicht, wie lange die Umschaltung dauert, wie lange die Batterien wirklich reichen, ob das Herunterfahren in der richtigen Reihenfolge klappt und was nach der Rückkehr des Stroms von selbst wieder hochkommt. Dieser Artikel ist deshalb ein Testplan und kein Erfahrungsbericht. Der Test ist noch nicht gelaufen, die Ergebnisse kommen in einem Folgeartikel.

Was ich weiß und was nicht
Zur Erinnerung der Aufbau: Zwei Hybrid-Wechselrichter mit je 4,8 kWh Batterie versorgen über ihre Notstrom-Ausgänge die Server. Wechselrichter 1 trägt den Netzwerkschrank sowie Knoten 1 und Knoten 2 mit rund 55 W, Wechselrichter 2 trägt nur Knoten 3 mit rund 132 W.

Mein Wissensstand:
| Frage | Stand heute |
|---|---|
| Schaltet der Notstrom um? | ja, gezielt ausprobiert und bei einem echten Ausfall beobachtet |
| Wie lange dauert die Umschaltung? | nicht gemessen |
| Wie lange reicht die Batterie? | nur gerechnet: bei 40 % Ladestand rund 30 Stunden (Wechselrichter 1) und rund 13 Stunden (Wechselrichter 2) |
| Fahren die Knoten rechtzeitig herunter? | nein, dafür gibt es noch keine Automatik; bei leerer Batterie gehen sie hart aus |
| Was startet danach von selbst? | Startreihenfolge der Gäste ist eingestellt, im Test nie geprüft |
Die vier Fragen und wie ich sie messe
Umschaltzeit
Ein Messgerät für Millisekunden habe ich nicht im Plan. Ich prüfe deshalb indirekt, ob die Umschaltung für die Geräte unsichtbar bleibt: Ist ein Knoten neu gestartet? Hat ein Switch die Verbindung verloren? Hat das Monitoring eine Lücke? Wenn die Laufzeit der Knoten nach dem Test weiterzählt und kein neuer Boot im Journal steht, war die Umschaltung kurz genug. Eine Zahl in Millisekunden wird daraus nicht, und das schreibe ich dann auch so.
# Vor und nach dem Test auf jedem Knoten
uptime -s
journalctl --list-boots | tail -n 3
# Cluster und Gäste
pvecm status
qm list
Laufzeit
Ich lasse die Batterien im ersten Test nicht leerlaufen. Stattdessen messe ich, wie schnell der Ladestand bei bekannter Last sinkt, und vergleiche das mit der Rechnung. Nach meiner Formel (Kapazität, 90 Prozent Wirkungsgrad, gemessene Last) sollte Wechselrichter 1 etwa 1,3 Prozentpunkte pro Stunde verlieren und Wechselrichter 2 etwa 3 Prozentpunkte. Weil der Ladestand nur in ganzen Prozent kommt und manchmal springt, brauche ich dafür mehrere Stunden und nicht zehn Minuten. Die Last lese ich doppelt ab: am Wechselrichter und an einer Zwischenstecker-Steckdose mit Leistungsmessung.
Den Messwerten traue ich nur begrenzt. Der Ladestand ist schon einmal in unter einer Minute um 29 Prozentpunkte gesprungen, und die Abfrage eines Wechselrichters lief zeitweise ins Leere, ohne dass der Wert als ungültig galt. Ich lese deshalb die Rohwerte und achte auf die Meldung für eingefrorene Werte.
Shutdown-Reihenfolge
Bei einem langen Ausfall fahre ich die Knoten heute von Hand herunter. Im Test spiele ich genau das durch: zuerst Knoten 3, weil seine Batterie am schnellsten leer ist, dann Knoten 1, zuletzt Knoten 2, auf dem Firewall und ein Domänencontroller laufen. Ich messe, wie lange jeder Knoten bis zum Ausschalten braucht und ob ein Gast das Zeitlimit reißt. Der Windows-Dateiserver ist dafür mein Kandidat.
Home Assistant läuft auf Knoten 3. Fahre ich ihn als Ersten herunter, verschwinden auch die Ladestände aus meiner Übersicht. Für den Rest des Tests bleibt voraussichtlich nur die App des Herstellers.
Wiederanlauf
Danach kommt der Strom zurück. Ob die Knoten sich dann von selbst einschalten, steht nirgends in meiner Doku. Genau das will ich sehen. Laufen sie, sollen die Gäste je Knoten in fester Reihenfolge starten:
| Reihenfolge | Gäste | Wartezeit danach |
|---|---|---|
| 1 | Firewall | 60 s |
| 2 | Domänencontroller | 60 s |
| 3 | DNS-Filter | 20 s |
| 4 | Home Assistant, Management-Server | 30 s |
| 5 | Backup-Server, Dateiserver, Verwaltungs-Container | 30 s |
| 6 | Medienserver, KI-Server | 30 s |
| 9 | Client-VM | – |
Die Reihenfolge gilt nur innerhalb eines Knotens. Über Knotengrenzen hinweg wartet kein Gast auf einen anderen. Außerdem startet Proxmox Gäste mit Autostart erst, wenn der Cluster Quorum hat, also mindestens zwei von drei Knoten laufen. Ich messe die Zeit vom Einschalten bis zu dem Punkt, an dem alle Gäste laufen, Namensauflösung und Anmeldung funktionieren und das Monitoring grün ist.
Auch die Steuerung der Batterien reagiert mit. Liefert der Netzzähler während des Ausfalls keine Werte, setzt meine Überwachung die Sollwerte auf 0. Das ist so gewollt, aber ich will es sehen. Nach der Rückkehr des Netzes lädt die Steuerung unter 43 Prozent mit bis zu 1200 W je Batterie nach.
Ablauf in Phasen
Ich teile den Test in fünf Phasen. Jede hat ein Abbruchkriterium, und ich kann nach jeder Phase aufhören.
- Ausgangswerte festhalten: Ladestände, Last, Laufzeiten der Knoten, Zustand im Monitoring, Zähler der unsicheren Abschaltungen an der NVMe von Knoten 3.
- Netz trennen: den Stromkreis, an dem die Wechselrichter am Netz hängen, an der Sicherung abschalten. Vorher eindeutig herausfinden, welche Sicherung das ist.
- Inselbetrieb beobachten: einige Stunden, Ladestand und Last alle 30 Minuten notieren, dazu den Verlauf aus Home Assistant.
- Geordnet herunterfahren: Knoten 3, dann Knoten 1, dann Knoten 2, je mit Zeitstempel.
- Netz zurück: Sicherung einschalten, beobachten, was sich von selbst einschaltet, und die Zeit bis „alles grün“ stoppen.
Risiken
Ein Stromausfall-Test greift in die laufende Infrastruktur ein. Läuft eine Batterie leer, gehen die Knoten ohne Herunterfahren aus. Deshalb teste ich nicht bis zur leeren Batterie, sondern breche weit vorher ab.
Dazu trägt ein Wechselrichter fast alles: Fällt Wechselrichter 1 im Test aus, sind Netzwerk, Internet und zwei Knoten weg, und Knoten 3 allein hat kein Quorum. Bei einem Firmware-Update ist der Notstrom-Ausgang schon einmal ausgefallen. Der Test findet deshalb nie zusammen mit einem Update statt.
Vorbereitung
Vor dem Test erledige ich diese Punkte:
- Das nächtliche Backup aller Gäste ist erfolgreich gelaufen, dazu liegt ein frisches Backup von Home Assistant vor.
- Der Zeitpunkt liegt nicht um 02:15 Uhr, wenn die Backups laufen, und nicht zur vollen Stunde wegen der Replikationen. An dem Tag ändere ich nichts an Home Assistant. Am liebsten nach einem sonnigen Tag mit vollen Batterien.
- Ich bin die ganze Zeit vor Ort. Der Haushalt weiß vorher Bescheid, dass Internet und Anmeldung kurz ausfallen können.
- Die Notfallseite meiner Doku liegt ausgedruckt bereit, denn bei abgeschalteten Knoten ist auch die Doku weg.
- Fällt ein Ladestand unter 30 Prozent, beende ich die Phase und fahre herunter. Fällt etwas Unerwartetes aus, schalte ich die Sicherung sofort wieder ein.
Mein Messprotokoll ist eine einfache Tabelle. So soll sie aussehen, die rechte Spalte ist heute noch leer:
| Messgröße | Quelle | Erwartung | Ergebnis |
|---|---|---|---|
| Neustart eines Knotens beim Umschalten | Laufzeit, Journal | keiner | offen |
| Ladestand-Verlust pro Stunde | Home Assistant, Notizen | etwa 1,3 und 3 Punkte | offen |
| Last im Inselbetrieb | Wechselrichter, Zwischenstecker | rund 55 und 132 W | offen |
| Dauer Herunterfahren je Knoten | Zeitstempel | unbekannt | offen |
| Unsichere Abschaltungen der NVMe | Monitoring | Zähler bleibt gleich | offen |
| Zeit bis „alles grün“ | Monitoring, Gästeliste | unbekannt | offen |
Was danach kommt
Aus den Ergebnissen folgen zwei Bausteine, die heute fehlen: ein Alarm, wenn der Notstrom läuft oder ein Ladestand unter 30 Prozent fällt, und ein automatisches, geordnetes Herunterfahren, bevor die Batterien leer sind. Geplant ist ein Auslöser wie „Ladestand unter 12 Prozent seit fünf Minuten bei Netzausfall“. Die Schwelle setze ich aber erst fest, wenn ich die Dauer des Herunterfahrens gemessen habe. Einen Test mit wirklich leerer Batterie mache ich danach getrennt und nur mit frischem Backup.
Schreibe einen Kommentar