Ein Homelab mit drei Proxmox-Knoten, zwei Domänencontrollern und einer Firewall als virtueller Maschine hat ein Problem, über das man ungern nachdenkt: Was passiert, wenn der Strom weg ist? Üblich ist eine USV, die ein paar Minuten überbrückt und dann per Signal die Server herunterfährt. Bei mir hängen die Server stattdessen an den Notstrom-Ausgängen von zwei Hybrid-Wechselrichtern mit Batteriespeicher, die ohnehin für die Photovoltaik im Haus stehen. Dieser Artikel beschreibt den Aufbau, die Reihenfolge, in der ich die Knoten herunterfahre, die Steuerung der Batterien mit Home Assistant und die Fehler, die ich dabei gemacht habe. Einige waren unangenehm.
Der Aufbau: zwei Wechselrichter statt einer USV
Im Hausanschlussraum stehen zwei Hybrid-Wechselrichter vom Typ APsystems EZHI. Jeder hat eine Batterie der 5-kWh-Klasse; Home Assistant meldet 4,8 kWh Kapazität. Jede Batterie besteht aus zwei Modulen von Pylontech mit je 2,4 kWh. An den Notstrom-Ausgang jedes Wechselrichters habe ich eine Dreifachsteckdose angeschlossen. Fällt das Netz aus, schaltet der Wechselrichter auf Batteriebetrieb um, und die Geräte an diesem Ausgang laufen weiter.
Die Verbraucher sind so aufgeteilt:
| Wechselrichter 1 | Wechselrichter 2 | |
|---|---|---|
| Verbraucher | gesamter Netzwerkschrank (Switches, Glasfasermodem, Zähler-Auslesung), Knoten 1 und Knoten 2 | nur Knoten 3 |
| Gemessene Last | rund 55 W | rund 132 W |
| Batterie | 4,8 kWh | 4,8 kWh |
Knoten 3 ist der dicke Knoten mit Grafikkarte, Fileserver und Backup-Server, deshalb hat er einen Wechselrichter für sich allein. Die Lastwerte habe ich doppelt geprüft: einmal mit dem Wert, den der Wechselrichter selbst meldet, und einmal über eine schaltbare Zwischenstecker-Steckdose mit Leistungsmessung. Beide Messwege stimmen überein, die Laufzeitrechnung steht also auf echten Zahlen.
Wie lange reicht das?
Es bleibt immer eine Reserve von etwa 40 Prozent für den Notstrom. Tagsüber darf die Photovoltaik die Batterien bis 100 Prozent laden. Die Laufzeit rechne ich so: Kapazität mal Ladestand mal Wirkungsgrad (ich nehme 90 Prozent an), geteilt durch die Last.
| Ladestand | Wechselrichter 1 (55 W) | Wechselrichter 2 (132 W) |
|---|---|---|
| 40 % (Reserve) | rund 30 Stunden | rund 13 Stunden |
| 100 % (nach einem sonnigen Tag) | rund 80 Stunden | rund 33 Stunden |
Das sind gerechnete Werte, keine gemessenen. Sobald auf Knoten 3 ein KI-Modell auf der Grafikkarte rechnet oder ein Backup läuft, steigt die Last deutlich und die Zeit schrumpft. Selbst mit Reserve überbrückt das Setup aber Stunden statt Minuten.
Die Umschaltung habe ich gezielt getestet, und es lief alles weiter. Dazu kam ein echter Stromausfall, den die Infrastruktur ohne Unterbrechung überstanden hat. Eine zusätzliche klassische USV für Ausfälle von einigen Stunden bis zu einem Tag halte ich deshalb für unnötig. Nicht getestet habe ich das Verhalten bei leerer Batterie.
Firmware-Update: der Notstrom ist nicht garantiert
Ein Firmware-Update des Wechselrichters hat mir unerwartete Ausfälle der angeschlossenen Geräte beschert. Während des Updates liefert der Notstrom-Ausgang offenbar nicht durchgehend Spannung. Seitdem fahre ich vor einem Update die Proxmox-Knoten am betroffenen Wechselrichter geordnet herunter und aktualisiere immer nur einen Wechselrichter auf einmal. Den zweiten nehme ich erst dran, wenn alles wieder läuft und der Cluster wieder drei Stimmen hat.
Ob frühere, unerklärte Abstürze eines Knotens mit einem Update zusammenhängen, kann ich nicht sagen: Home Assistant zeichnet weder Firmware-Versionen noch Update-Zeitpunkte auf. Das will ich künftig festhalten.
Shutdown-Reihenfolge der Knoten
Die Reihenfolge hängt davon ab, welcher Wechselrichter betroffen ist. Wer anderen Diensten das Netz liefert, geht zuletzt aus und kommt zuerst wieder.
Bei einem Update an Wechselrichter 2 fällt nur Knoten 3 aus, aber auf dem laufen Fileserver, Home Assistant, Medienserver, der zweite DNS-Filter und der Backup-Server. Wenn ich den Host mit shutdown -h now herunterfahre, beendet Proxmox die Gäste von allein in umgekehrter Startreihenfolge. Dabei zählt das Timeout je Gast: Ein Windows-Fileserver braucht zum Herunterfahren länger als der Standard. Backups und Replikationen dürfen in dieser Zeit nicht laufen.
Bei einem Update an Wechselrichter 1 fallen das Netzwerk, das Glasfasermodem und zwei von drei Knoten weg. Auf diesen beiden Knoten laufen die Firewall, beide Domänencontroller, der Management-Server mit dem Monitoring und die Zertifizierungsstelle. Ohne sie gibt es kein Internet, keine Anmeldung, kein DNS und kein DHCP. Ich fahre zuerst Knoten 1 herunter, dann Knoten 2, weil dort die Firewall und ein Domänencontroller laufen, die bis zuletzt stehen sollen. Beim Hochfahren geht es umgekehrt: Knoten 2 zuerst, damit Firewall und DNS da sind, bevor der Rest startet. Vorher sage ich im Haushalt Bescheid, dass das Internet weg ist, und wähle ein Zeitfenster mit wenig Nutzung.
Nach dem Update prüfe ich jedes Mal dieselben Punkte:
# Hat der Cluster wieder alle Stimmen?
pvecm status
# Laufen die VMs auf diesem Knoten?
qm listDazu kommen ein Blick ins Monitoring und auf die Ladestände der Batterien in Home Assistant. Diesen Ablauf habe ich noch nicht vollständig durchgespielt; er ist aus den Abhängigkeiten abgeleitet.
Ein gemeinsamer Ausfallpunkt
Beim Aufschreiben der Reihenfolge ist mir etwas aufgefallen, das ich unterschätzt hatte: Wechselrichter 1 trägt Switches, Modem und zwei der drei Proxmox-Knoten. Fällt genau dieses Gerät aus, ist nicht nur das Netz weg. Knoten 3 bleibt allein übrig und hat keine Mehrheit im Cluster. Ohne Quorum startet oder verschiebt er keine Gäste mehr, solange niemand eingreift.
Steuerung über Home Assistant
Die Batterien sollen nicht nur Notstrom liefern, sondern auch den Eigenverbrauch erhöhen. Dafür misst ein Shelly Pro 3EM am Netzanschluss, wie viel Strom gerade bezogen wird. Eine Automation in Home Assistant rechnet daraus eine Zielleistung je Wechselrichter und schreibt sie per lokaler Integration ins Gerät: negativ heißt laden, positiv heißt entladen. Unter der Reserve lädt die Steuerung aus dem Netz nach, Überschuss aus der Photovoltaik geht in die Batterie.
Als ich die Konfiguration genauer durchgesehen habe, kam einiges zusammen:
- Der Ladestand eines Wechselrichters fiel einmal in 57 Sekunden von 39 auf 10 Prozent. Physikalisch ist das unmöglich. Vermutlich kalibriert die Batterie von Zeit zu Zeit, und dabei springt die Anzeige. Bestätigt ist das nicht.
- Eine Automation sollte bei hoher Temperatur oder sehr niedrigem Ladestand alles stoppen. Der Sprung auf 10 Prozent löste sie aus, und sie schaltete sämtliche Automationen ab, obwohl die Batterie einfach weitergeladen hätte. Damit fehlte auch der Temperaturschutz.
- Alle Helfer hatten feste Startwerte. Nach jedem Neustart von Home Assistant sprangen bewusst geänderte Einstellungen auf den Standard zurück.
- Die Automation lief rund 32.700 Mal am Tag, schrieb jedes Mal einen Logbuch-Eintrag und schickte über 2.000 Befehle pro Tag an jeden Wechselrichter. Die Datenbank war auf 3,3 GB gewachsen.
- Die Netzladung startete unter 40 Prozent und stoppte bei 40 Prozent. Weil der Notstrom-Ausgang ständig Last zieht, entstand ein Sägezahn knapp unter der Reserve, mit Tagestiefstwerten zwischen 34 und 39 Prozent.
Der Umbau in Stufen und ein Fehler, den ich selbst eingebaut habe
Ich habe die Konfiguration zuerst in ein Git-Repository gelegt, ein vollständiges Backup von Home Assistant gezogen und dann in Stufen umgebaut, jeweils mit Messwerten vorher und nachher. Die erste Stufe sollte absichern: ein Filter für den Ladestand, ein Wartungsschalter und Helfer ohne feste Startwerte.
Genau dieser Filter war ein Fehler. Ich hatte einen gleitenden Mittelwert über zwei Minuten gewählt, um Sprünge zu dämpfen. Dieser Filter rechnet aber nur, wenn ein neuer Messwert kommt. In der Nacht sprang der Ladestand eines Wechselrichters von 42 auf 30 Prozent und blieb dann konstant. Der gefilterte Wert blieb 79 Minuten lang bei 40,9 Prozent stehen. Die Netzladung startete deshalb nicht, und die Batterie sank bis auf 10 Prozent. Am Wechselrichter hing Knoten 3. Die Reserve war verletzt, und zwar durch die Änderung, die sie schützen sollte.
Jetzt arbeitet die Steuerung wieder mit dem echten Messwert, der nur als nicht verfügbar gilt, wenn keine Zahl kommt. Sprünge fängt eine Wartezeit ab: Ein Ladestand unter 10 Prozent zählt erst, wenn er zehn Minuten anhält, und löst dann nur eine Meldung aus, keine Abschaltung.
Die weiteren Stufen haben aufgeräumt:
- Der Sicherheits-Stopp greift nur noch bei einer Batterietemperatur über 45 °C. Er setzt die Sollwerte auf null, pausiert die Steuerung und gibt sie nach fünf Minuten unter 40 °C selbst wieder frei. Eine höhere Grenze ergibt keinen Sinn, weil laut Handelsangaben bei 50 °C die Grenze der Batterie liegt.
- Die Netzladung hat eine Hysterese: Start unter 43 Prozent, Stopp ab 48 Prozent. Damit wird die Reserve von 40 Prozent gehalten, zum Preis von etwas mehr Netzstrom.
- Die Steuerung läuft nur noch alle 10 Sekunden statt bei jeder Änderung, Befehle gehen erst ab 80 W Abweichung und mit mindestens 15 Sekunden Abstand hinaus, es gibt keinen Logbuch-Eintrag je Lauf, und Zwischenwerte sind aus der Aufzeichnung ausgeschlossen.
- Eine Meldung kommt, wenn ein Messwert länger als zehn Minuten nicht aktualisiert wird. Die Abfragen an einen Wechselrichter liefen zeitweise ins Leere, ohne dass der Wert als nicht verfügbar galt. Er war einfach eingefroren.
- Eine Entlade-Untergrenze nach Sonnenprognose sorgt dafür, dass nur so tief entladen wird, wie der erwartete Überschuss des nächsten Sonnentages noch in die Batterien passt. Im Herbst und Winter liegt die Grenze damit meist bei 60 Prozent.
Der Wartungsschalter ist der wichtigste Baustein. Er setzt beide Sollwerte auf null und stoppt die Steuerung. Ich schalte ihn vor jedem Firmware-Update und vor jedem Neustart von Home Assistant ein. Bleibt die Steuerung nämlich stehen, behält der Wechselrichter den zuletzt gesetzten Sollwert, und wie er sich ohne weitere Befehle verhält, ist nicht dokumentiert.
Was noch offen ist
Fällt das Netz sehr lange aus und beide Batterien laufen leer, gehen die Server heute hart aus. Ein geordnetes Herunterfahren bei niedrigem Ladestand gibt es noch nicht: Ein Wächter pro Knoten, der zunächst nur beobachten soll, ist als Skript vorbereitet, aber nicht eingerichtet. Ebenso fehlen ein Alarm im Monitoring bei niedrigem Ladestand, der kurze Sprünge ausblenden muss, sonst meldet er jede Kalibrierung, und ein Skript für den Ablauf bei Firmware-Updates. Das Verhalten bei leerer Batterie habe ich nie getestet; das will ich nur nach Absprache und mit frischem Backup tun.
Schreibe einen Kommentar