Kontrolliertes Herunterfahren bei Stromausfall

[jonofe]

Irgendwas sollte den Server wieder hochfahren lassen,

Man könnte das z.B. mit einem RPI Zero machen, auf dem der apcupsd läuft und der dann alle Geräte runter (ssh) und auch wieder hochfährt (WoL).
Wenn bei Stromausfall der USV komplett leer läuft, dann fährt der RPI bei Rückkehr des Stroms hoch und der apcupsd fährt die Server wieder hoch.
Wenn die USV hingegen nicht komplett leer läuft, dann fährt der apcupsd bei Rückkehr der Primärstromversorgung die Server wieder hoch.

[uncelsam]

Das liegt dann auch wieder an der USV, ich hab hier ne Eton bei der ich einstellen kann, dass X min. nach dem Herunterfahren die Ausgänge ausgehen, bei Spannungswiederkehr gehen die dann auch wieder an, und der Server dahinter ist so eingestellt dass er bei Spannungswiederkehr grundsätzlich wieder hochfährt.

Die Ausgänge sind auch so Konfiguierbar dass sie erst wieder anschalten wenn der Akku entsprechend geladen wurde, so dass der Server auf jeden Fall sauber hergefahren werden kann, sollte ein zweiter Stromausfall kommen.

Wobei ich denke dass man mit einer guten gebrauchten USV so eine Edomi "Server" sicher auch mal 30min überbrücken kann.

Grüße

[saegefisch]

Irgendwas sollte den Server wieder hochfahren lassen

Man könnte auch an einem nicht per USV versorgtem RasPi oder ESP8266 (kostet nur 10€) o.ä. einfach dafür sorgen, dass der beim hochfahren alle relevanten Servern ein WoL-Paket sendet. Wenn sie unten waren, fahren sie hoch. Wenn sie noch oben waren, tut's nicht weh.

Frage zu LBS 19000378: Der funktioniert nur mit APCUPSD, richtig?
Ich nutze für meine USV (obwohl von APC) seit viele Jahren NUT, dass erwarten auch meine qnap-NASe (alle als Slave). Edomi steht noch als slave auf meiner todo-Liste. Gibt es bereits ein NUT-Pendant zum 19000378 und ich habe nur falsch gesucht? Oder bin ich da der erste mit Bedarf?

[jonofe]

Frage zu LBS 19000378: Der funktioniert nur mit APCUPSD, richtig?

Ja, das ist korrekt.

Dass es einen für NUT gäbe, wäre mir auch neu, aber nichts ist unmöglich ...

[saegefisch]

...dann muss ich wohl mal selber...wenn mal Zeit ist... bei Gelegenheit...

[saegefisch]

jonofe : Hi André, Ich hätte da mal was für Dich - ich habe den 19000378 um ein paar Kleinigkeiten = ein paar wenige Zeilen angepasst und nun funktioniert er vermutlich universell für APCUPSD und NUT gleichermaßen. Warum? Weil letztlich ruft man NUT ebenso per tcp auf und kann dann gleichfalls aus dem response per E5 gewünschte Werte ausgeben lassen. Nur die Request-Zeile ist anderes inkl. der Aufbereitung des response. Für den Anwender sind die möglichen Werte in E5 natürlich abweichend (siehe unten), die Hilfe wäre entsprechend schon ergänzt.

Abweichende Besonderheit ist nur, dass der NUT-Server mehrere UPS verwalten kann und daher der Name im Aufruf mit gegeben werden muss. Es gäbe daher einen neuen Eingang für den Typ "apcupsd" oder "nut". Und einen für den UPS-Namen (NUT-only). Mit dem command E4 = "list" kann man sich alle am Server verfügbaren UPS ausgeben lassen und den korrekten Namen so ermitteln. Ob man die beiden neuen Eingänge hinten anhängt oder vorne einschiebt ist Geschmackssache.

Dafür kennt NUT nach meiner Kenntnis keine Events.

--> Soll ich den LBS Dir hier mal einstellen und Du schaust Dir überschaubaren Änderungen an? Ohne Dein ok wollte ich hier nichts vorab einstellen...

Alternativ mache ich einen neuen LBS, der fast gänzlich Deinem entspräche mit obigen Änderungen - wenn es Dir lieber ist und Du erlaubst... zweieiige Zwillinge gewissermaßen...
Alle geänderten Zeilen hätte ich bereits für Dein Review markiert und kommentiert.
Unbenannt.JPG

---

Zur allgemeinem Info:

• Vergleich Ausgabe NUT <-> apcupsd des selben Geräts
• TIMELEFT entspricht nach meiner Kenntnis battery.runtime (3424s/60=57,1min)

battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 50 battery.date: 2001/09/25 battery.mfr.date: 2013/12/19 battery.runtime: 3424 battery.runtime.low: 120 battery.type: PbAc battery.voltage: 13.6 battery.voltage.nominal: 12.0 device.mfr: American Power Conversion device.model: Back-UPS XS 650CI device.serial: 3B1351X15089 device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.SERIAL: 3B1351X15089 driver.parameter.synchronous: no driver.version: 2.7.4 driver.version.data: APC HID 0.96 driver.version.internal: 0.41 input.sensitivity: medium input.transfer.high: 300 input.transfer.low: 140 input.voltage: 226.0 input.voltage.nominal: 230 ups.beeper.status: enabled ups.delay.shutdown: 20 ups.firmware: 892.R3 .I ups.firmware.aux: R3 ups.load: 13 ups.mfr: American Power Conversion ups.mfr.date: 2013/12/19 ups.model: Back-UPS XS 650CI ups.productid: 0002 ups.realpower.nominal: 390 ups.serial: 3B1351X15089 ups.status: OL (-> Bedeutung) ups.timer.reboot: 0 ups.timer.shutdown: -1 ups.vendorid: 051d

APC : 001,036,0863 DATE : 2020-12-21 16:27:50 +0000 HOSTNAME : HAL-10 VERSION : 3.14.14 (31 May 2016) debian UPSNAME : APCXS650 CABLE : USB Cable DRIVER : USB UPS Driver UPSMODE : STARTTIME: 2020-12-21 16:27:48 +0000 SHARE : MODEL : Back-UPS XS 650CI STATUS : ONLINE LINEV : 228.0 Volts LOADPCT : 13.0 Percent BCHARGE : 100.0 Percent TIMELEFT : 57.1 Minutes MBATTCHG : 10 Percent MINTIMEL : 5 Minutes MAXTIME : 0 Seconds SENSE : Medium LOTRANS : 140.0 Volts HITRANS : 300.0 Volts ALARMDEL : 30 Seconds BATTV : 13.6 Volts LASTXFER : Unacceptable line voltage changes NUMXFERS : 0 TONBATT : 0 Seconds CUMONBATT: 0 Seconds XOFFBATT : N/A STATFLAG : 0x05000008 SERIALNO : 3B1351X15089 BATTDATE : 2013-12-19 NOMINV : 230 Volts NOMBATTV : 12.0 Volts NOMPOWER : 390 Watts FIRMWARE : 892.R3 .I USB FW:R3 END APC : 2020-12-21 16:27:53 +0000

[jonofe]

Soll ich den LBS Dir hier mal einstellen und Du schaust Dir überschaubaren Änderungen an?

Hi Carsten,
Du kannst ihn mir gerne per E-Mail senden (edomi (at) anrath.net). Ich schau mal drüber, ob ich verstehe was du erweitert hast (damit es bei späteren Anpassungen keine Probleme gibt).

[saegefisch]

Lieben Dank, André, für das übernehmen des Ergänzungen in Deinen LBS, um nun universell APCUPSD und NUT abfragen zu können.

Für NUT kann ich für V0.3 bestätigen: Passt so!

Ein Logik-Beispiel - vielleicht hilft es dem ein oder anderen:
Unbenannt2.JPG Unbenannt.JPG
Bleibt die spannende Frage von Christian nicht nur in Worten, sondern auch in technischen Lösungen zu beantworten: Wie fährt edomi wieder hoch, wenn die Spannung nach dem kontrollierten herunter fahren, aber vor dem finalen Ende der USV-Kapazität die Spannung wieder kehrt? Dann bleibt edomi nämlich tatsächlich erst mal aus; wie allen anderen Server/NAS ebenso - weil der Spannungsausfall aus Sicht des BIOS ja nie geschah. Oben stehen ja schon ein paar Ansätze zur Lösung...

[ThomasCologne]

Also wenn bei uns die Spannung wieder kommt, fährt auch das NAS bzw. Raspberry wieder hoch. Wir haben keine USV. Wenn nun also ein pi oder ein NAS (welche nicht an der USV) angeschlossen sind, ein Signal schickt, sollte man damit doch was anfangen können.

[saegefisch]

ohne USV = nicht relevant!

aber mit... Lies die Frage noch mal Genau(!) durch...

der von dir beschrieben Fall ist der, der bei fast allen gelöst ist und den ich auch schon lange auf dem Schirm hatte.
Aber was passiert, wenn es auf den letzten Minuten gar keinen Ausfall gibt... die Frage ist ein wenig akademisch, aber durchaus real...

[Janncsi]

Steige gerade erst mit dem Lesen ein, aber zumindestens saegefisch hat doch Mikrotik am Laufen.

Der fährt nach Stromausfall auf jeden Fall automatisch hoch. An meinem ist die USV angeschlossen per USB und kann die Informationen auch verarbeiten. N MagicPacket mit dem Mikrotik loszusenden ist sowieso n leichtes.

Wäre das auch ein Weg?

LG

[jonofe]

Wäre das auch ein Weg?

Ja, alles war nach Stromausfall wieder hochfährt und gleichzeitig die USV monitored ist eine Lösung. Ob MikroTik oder RPI ist eigentlich egal.

Wichtig ist aus meiner Sicht, dass die folgenden zwei Fälle abgedeckt sind:

1. Wenn USV leer läuft muss das Gerät nach Stromrückkehr automatisch booten und die Server wieder hochfahren, sobald die USV wieder eine ausreichende Kapazität (z.B. 30%) meldet (via apcupsd oder nut oder sonstwie)
2. Wenn die USV nicht komplett leer läuft bevor der Strom primärseitig wieder da ist, muss das Gerät die primärseitige Stromversorgung feststellen und die Server bei Erreichen der Mindestkapazität (z.B. 30%) wieder hochfahren.

[saegefisch]

hat doch Mikrotik am Laufen.

Der fährt nach Stromausfall auf jeden Fall automatisch hoch. An meinem ist die USV angeschlossen per USB und kann die Informationen auch verarbeiten. N MagicPacket mit dem Mikrotik loszusenden ist sowieso n leichtes.

In dem 2. Fall...
Der FritzBox, Mikrotik, Switche fahren nicht kontrolliert herunter. Da es letztlich nicht zum Stromausfall kam, laufen sie einfach durch.
Alle Server, NAS,... wurden kontrolliert herunter gefahren. Mangels tatsächlichem Eintritt des Stromausfall fehlt der Trigger, um sie bei Stromrückkehr wieder hoch zu fahren. Er war ja nie weg.
Und Achtung: Wohl möglich ist der NUT/APCUPSD-Server/Primary ebenfalls herunter gefahren... damit kann kein Client mehr erkennen, dass da noch ein Rest war, als die Spannung gar nicht ausfiel. Das wäre bei mir so, weil der NUT-Server auf dem Proxmox läuft.

Aus meiner Sicht scheint mir Janns von meiner Ursprungsidee weiter gedachter Vorschlag (Weil der spart sich sogar den ESP und hat auch kein Problem mit VLAN) perfekt: Einfach per Script vom MikroTik regelmäßig ein WoL-Paket an alle Server. 24/7 alle 5 Minuten. Oder Minütlich. Wenn die Server laufen, tut's nicht weh. Wenn aber der besondere obige Fall auftritt, fahren sie nach spätestens dieser Zeit alle wieder hoch. Da muss man mMn auch nichts noch prüfen auf Mindest-Kapa, weil Netz ja wieder da ist. Woher sollte der MT das auch wissen - außer er wäre selber NUT/APSCUPSD-Server.

[jonofe]

Da muss man mMn auch nichts noch prüfen auf Mindest-Kapa, weil Netz ja wieder da ist.

Annahme: Die USV geht bis 1% runter und dann kommt die Primärspannung zurück. Dann fährt der Mikrotik bei 1% USV Reserve alle Server wieder hoch. Wenn dann wieder die Primärspannung weg ist, dann kann's knapp werden.

Woher sollte der MT das auch wissen - außer er wäre selber NUT/APSCUPSD-Server.

Ja genau das kann der Mikrotik ja, mit dem UPS Package. Damit kann er auch die Kapazität auslesen. Das ganze dann in ein Skript und es sollte funktionieren.

[saegefisch]

Ja, das Szenario, dass die Spannung ganz rasch wieder wegfällt war schon im letzten Post nachvollziehbar - aber für meine Abwägung hätte ich den Fall als "Restrisiko" gesehen...

Dass der MT auch UPS-Server kann, wusste ich gar nicht. Danke für den Tipp! Das wäre in der Tat sehr charmant. Allerdings wohl nur apcupsd, nicht nut, richtig?

Und wenn ich meine qnap-NAS richtig verstanden habe, dann können die nur NUT-Server anfragen, nicht apcupsd. Damit habe ich leider keine Schnittmenge zwischen UPS-Option im MT und den Erfordernissen meiner qnap-NASe Und daher kam ich zu meiner Abschätzung "Restrisko"...

Wenn ich nicht durch qnap auf NUT beschränkt wäre, würde ich die UPS-Lösung im MT sofort vorziehen - das ist klasse. Den der MT ist der erste der kommt und der letzte der geht...