Proxmox durch USV herunterfahren

[GregorS]

Hallo Zusammen,
ich habe mir einen Promox VE auf einem NUC installiert, indem 3 VM laufen (ioBroker / Debmatic / flightradar).
Nun möchte ich Promox herunterfahren, wenn die USV nur noch 50% Restkapazität hat.
Es handelt sich bei der USV um eine APC mit Netzwerkkarte.
Wie stelle ich das am geschicktesten an?
Welche Software muss ich wo installieren (Promox oder in jder VM)?
Bin noch absoluter Neuling mit Promox.

Danke für Eure Hilfe.

Gregor

 

[shanreich]

Apcupsd [1] sollte das sein wonach du suchst. Das ganze am Proxmox Node installieren, wenn der gesamte Node heruntergefahren werden soll. Wie die Konfigurationsdatei aussehen sollte kannst du hier [2] nachlesen.

[1] https://wiki.ubuntuusers.de/USV/Apcupsd/
[2] https://linux.die.net/man/5/apcupsd.conf

 

[Dunuin]

NUT wäre auch noch eine Option, sofern eine USV auf der Support-Liste steht: https://networkupstools.org/stable-hcl.html

 

[GregorS]

Ich wollte mir apcups installieren.
Jetzt habe ich eine Frage zur Konfiguration.
Auf meinem NUC läuft Promox VE (IP: 192.xxx.xxx.100)
Die USV hat die IP: 192.xxx.xxx.109
Muss ich auf dem Promox VE (.100) apcups als Server installiern und auf jeder VM als Client?
Habe bis jetzt leider nur Anleitungen für USB-Kabel gefunden und keine für Netzwerk.
Als Device hätte ich snmp oder PC zur Auswahl.

 

[Dunuin]

In den Gästen braucht du eigentlich nichts installieren, sondern nur auf dem PVE Host. Sobald der PVE Host runterfahren soll wird er automatisch vorher alle Gäste herunterfahren und erst dann sich selbst.

 

[GregorS]

Ok.
Muss ich unter Promox VE noch was einstellen?

 

[GregorS]

Habe gerade mal einen Test gemacht.
Die Server sind sauber heruntergfahren.
Unter

BATTERYLEVEL 5

Durch die USV gemeldete Restkapazität in Prozent, ab der der Rechner heruntergefahren wird

habe ich 80% eingestellt, aber der Server ist schon bei 90% (Batteriestatus) heruntergefahren.

Meine Einstellungen in der apcupsd.conf:
ONBATTERYDELAY 6
BATTERYLEVEL 80
MINUTES 3
TIMEOUT 0
ANNOY 300
ANNOYDELAY 60

Irgendwas habe ich wohl falsch eingestellt.

 

[Detlef Paschke]

habe ich 80% eingestellt, aber der Server ist schon bei 90% (Batteriestatus) heruntergefahren.

Meine Einstellungen in der apcupsd.conf:
ONBATTERYDELAY 6
BATTERYLEVEL 80
MINUTES 3
TIMEOUT 0
ANNOY 300
ANNOYDELAY 60

Irgendwas habe ich wohl falsch eingestellt.

Du hast "BATTERYLEVEL 80" und "MINUTES 3" angegeben. Das ist eine ODER-Verknüpfung, der Shutdown wird bei dem Ereignis ausgelöst, welches zuerst eintritt. Wenn die geschätzte Restlaufzeit bereits bei 90% Batteriekapazität erreicht ist, fährt der Server da schon runter.

Den Batterielevel auf 80% halte ich im übrigen für sehr hoch und das die USV bei 90% bereits bei 3 Minuten Restlaufzeit ist, für sehr wenig.
Entweder ist die USV für deinen Server viel zu schwach, die Batterie ist am Ende oder die USV sollte dringend mal Kalibriert werden.

Ich habe bei mir einen Batterielevel von 5% und eine Restlaufzeit von 4 Minuten konfiguriert. Meine USV (APC Back-UPS RS 1500G) hält meinen stromhungrigen Server ca. eine halbe Stunde in Betrieb.

Viele Grüße
Detlef

 

[GregorS]

Hallo Detlef,

die 80% waren nur zum Test.
Wollte schauen ob PVE heruntergefahren wird.
Habe jetzt die Werte angepasst.
Bei 10% Ladung wird der Shutdown durchgeführt, bei Restlaufzeit von 3 Minuten werden die Ausgänge abgeschaltet.
Meine USV hält das System 125 Minuten am Leben.
Wenn mein Laptop nicht läuft, ist nur der NUC und ein Telefon online.

Habe nur noch keine Lösung, was ich machen soll, wenn zwischen Shutdown des PVE und der Ausgangsabschaltung der Strom wieder kommt.
Dann merkt der NUC nichts davon und bleibt down.

Gruß
Gregor

 

[Detlef Paschke]

Wenn mein Laptop nicht läuft, ist nur der NUC und ein Telefon online.

Habe nur noch keine Lösung, was ich machen soll, wenn zwischen Shutdown des PVE und der Ausgangsabschaltung der Strom wieder kommt.
Dann merkt der NUC nichts davon und bleibt down.

Das Telefon, auch wenn es kaum Strom braucht, macht heute keinen Sinn mehr.
Telefon und Internet laufen heute meist über das DSLAM, das bei dir in der Straße steht und die hängen am ganz normalen Ortsnetz ohne USV. Ist im Ort der Strom weg, geht Internet und Telefon ohnehin nicht. Bringt also nur was, wenn Hausintern ein Problem mit dem Strom währe oder dein Telefon an irgend was ganz anderem hängt.

Ist der Shutdown erst einmal ausgelöst, läuft er bis zum Ende durch und kann soweit ich weiß, nicht mehr gestoppt werden.
Es ist ein ganz normaler Shutdown, den kann man doch nicht stoppen, oder? Dann müssten all die Sachen, die schon gestoppt wurden, wieder gestartet werden.

Falls bei deiner USV das Killpower, also das Abschalten der USV nach Stromausfall -> Shutdown nicht funktioniert, hatte ich hier mal was dazu geschrieben.

http://helpdesk.schabau.eu/archiv/proxmox008.html

Sonst kann die Batterie deiner USV bis zum bitteren Ende leer gesaugt werden, wenn mal ein längerer Stromausfall ist.

Viele Grüße
Detlef

 

[GregorS]

Deine Anleitung hätte ich vorher finden müssen. Sehr gute Anleitung.

Das mit dem Killpower verstehe ich nicht

Dort steht bereits alles, ist aber Auskommentiert. Es geht darum, /usr und /var beim Shutdown noch einmal zu mounten.
Es muss im Grunde nur das jeweilige Auskommentieren, also die Raute "#" entfernt werden.

#!/bin/sh
mount -n -o ro /usr
mount -n -o ro /var
mount | awk '/ext4/ { print $3 }' | while read line; do
mount -n -o ro,remount $line
done
exit 0

Bei mir wird bei 10% Batterieladung der Befehl zum Beenden von Promox gegeben.
Dann werden die einzelnen VM´s nacheinander beendet.

Was passiert dann in der apcusp/killpower?
Werden dann die Ausgänge sofort abgeschaltet, oder greift da eine Verzögerungszeit?
Das sind meine Einstellungen.

Gruß
Gregor

 

[Detlef Paschke]

Was passiert dann in der apcusp/killpower?
Werden dann die Ausgänge sofort abgeschaltet, oder greift da eine Verzögerungszeit?
Das sind meine Einstellungen.

Es geht darum, dass die USV nach dem Abschluss des Shutdown komplett abgeschaltet wird. Nicht alle USV machen das selbst sondern saugen für ihre Eigenversorgung an der Batterie, bis nichts mehr geht, was sehr schlecht für die Batterie ist (Stichwort Tiefentladung).
Und, hat man in seinem Bios die Einstellung so gewählt, dass der Server bei Netzstrom sofort gestartet wird (Recovery from AC Power Loss) kann das nach einem längeren Stromausfall auch zu Problemen führen.
Der Server ist bereits komplett heruntergefahren die USV liefert aber noch Strom über die Batterie -> Netzstrom liegt wieder an -> die USV schaltet wieder auf Netzstrom. Für den heruntergefahrenen Server ändert sich am Status nichts, da das Netzteil die ganze Zeit mit Strom versorgt wurde. Damit kann "Recovery from AC Power Loss" gar nicht greifen und der Server bleibt aus, bis er manuell gestartet wird.

Viele Grüße
Detlef

 

[GregorS]

Ok.
Das mit der Tiefentladungt ist richtig.
Aber der Server braucht doch eine gewisse Zeit bis er heruntergefahren ist.
Wenn die USV nach dem Befehl "Shutown Server" die Ausgänge abschaltet, würde der Server doch trotzdem unkontrolliert abgeschaltet.
Woher weiss die USV dass sie die Ausgänge nun abschalten kann?

 

[Detlef Paschke]

Ok.
Das mit der Tiefentladungt ist richtig.
Aber der Server braucht doch eine gewisse Zeit bis er heruntergefahren ist.
Wenn die USV nach dem Befehl "Shutown Server" die Ausgänge abschaltet, würde der Server doch trotzdem unkontrolliert abgeschaltet.
Woher weiss die USV dass sie die Ausgänge nun abschalten kann?

Der Killpower-Befehl wird als letztes gegeben und die USV wartet auch noch (bei mir so ca. 2, 3, 4 sec.) bis sie abschaltet.

Viele Grüße
Detlef Paschke

 

[Detlef Paschke]

Mit ShowStatus=yes in in /etc/systemd/system.conf bekommt man beim Start und Shutdown auch wieder ein paar mehr Informationen, so wie es früher mal war. Proxmox oder Debian im allgemeinen, ist ja nahezu stumm geworden. So sieht man, wann was ausgeführt wird.

Viele Grüße
Detlef Paschke

 

[GregorS]

Alles klar.
Danke für die Erklärung.
Werde es nach dem Urlaub mal einrichten.
1 Tag vorher ist mir das Risiko zu groß.
Deine Seite ist übrigends sehr informativ. Super erklärt die einzelnen Rubriken.

Gruß
Gregor

 

[Detlef Paschke]

Deine Seite ist übrigends sehr informativ. Super erklärt die einzelnen Rubriken.

Das hört man gern, doch nicht nur Zeitverschwendung.

Viele Grüße
Detlef

 

[Dunuin]

Außerdem musst du gucken, dass da die USV noch lange genug Strom liefern kann, dass da der Server auch komplett runtergefahren werden kann. Das kann bei 10% je nach Last und Kapazität kritisch sein. Nicht vergessen, dass da der Server beim runterfahren nochmal mehr Strom verbrauchen kann als sonst im Idle, da du plötzlich alle Gäste auch runterfahren willst, was dann natürlich zuätzliche Ressourcen vom Server erzeugt. Und dann kann es vorkommen, dass da ein Gast beim runterfahren hängt. Da gibt es dann zwar ein Timeout (glaube 5 Minuten war das), wo dann PVE the Gäste einfach hart stoppt, aber so 7-10 Minuten sollte man da glaube ich schon fürs Runterfahren des PVE Servers einplanen.

 

[Detlef Paschke]

Und dann kann es vorkommen, dass da ein Gast beim runterfahren hängt. Da gibt es dann zwar ein Timeout (glaube 5 Minuten war das), wo dann PVE the Gäste einfach hart stoppt, aber so 7-10 Minuten sollte man da glaube ich schon fürs Runterfahren des PVE Servers einplanen.

Da wäre ich für ein privates Projekt doch nicht soo Paranoid.
Ein typischer Test ist alle VM laufen haben und mit einer Uhr nebenstehend dem Proxmox einen Shutdown-Befehl geben. Auf der Uhr schauen, wie lange es dauert, bis der Server sich komplett abgeschaltet hat und gern zwei Minuten zugeben. Die Zeit kann man dann recht ruhigen Gewissens unter "MINUTES" angeben.
Bei 7 bis 10 Minuten für einen evtl. auftretenden zusätzlichen Timeout? Was soll man sich denn da noch hinstellen? Firmen Okay, aber privat ist es doch sehr übertrieben. Genau so übertrieben wie die ewige SSD-macherei für einen kleinen privaten Server. (Das Schaft auch noch eine drehende SAS-Platte und die kündigt sich vor allem an, bevor sie versagt.) Okay, SSD braucht weniger Strom, darf man aktuell nicht vergessen.

Viele Grüße
Detlef

 

[Dunuin]

Da wäre ich für ein privates Projekt doch nicht soo Paranoid.
Ein typischer Test ist alle VM laufen haben und mit einer Uhr nebenstehend dem Proxmox einen Shutdown-Befehl geben. Auf der Uhr schauen, wie lange es dauert, bis der Server sich komplett abgeschaltet hat und gern zwei Minuten zugeben. Die Zeit kann man dann recht ruhigen Gewissens unter "MINUTES" angeben.
Bei 7 bis 10 Minuten für einen evtl. auftretenden zusätzlichen Timeout? Was soll man sich denn da noch hinstellen? Firmen Okay, aber privat ist es doch sehr übertrieben.

Das VMs nicht runterfahren wollen ist bei mir keine Seltenheit. Macht z.B. keine einzige Win VM die seit dem letzten Reboot ein Update gemacht hat und diese nun beim Runterfahren installieren will. Die hängen dann einfach für 5 Minuten oder so, bis PVE die letztendlich killt. Bei meinen OPNsense VMs hatte ich das auch schon öfters mal. Manchmal hat auch der Storage das runterfahren verhindert. Ich hatte z.B. mal eine USB-Disk dran, die Probleme machte, und per Disk-Passthrough in die VM gebracht. Da wollte die Linux-VM auch nicht mehr runterfahren. Oder man hat seine Startreihenfolge nicht richtig eingestellt und die NAS VM fährt vor den anderen VMs runter, welche die SMB/NFS Shares eingebunden haben. Da wollen dann die VMs beim Runterfahren erst den Write Cache auf die NFS/SMB Share flushen, was natürlich nicht geht, weil der NFS/SMB Server nicht mehr online ist, also warten die VMs beim Runterfahren einfach so lange, bis der NFS/SMB Share wieder erreichbar ist oder sie halt von PVE nach dem Timeout gekillt werden. Alles schon hier daheim gehabt, daher ja der Hinweis von mir

Genau so übertrieben wie die ewige SSD-macherei für einen kleinen privaten Server. (Das Schaft auch noch eine drehende SAS-Platte und die kündigt sich vor allem an, bevor sie versagt.) Okay, SSD braucht weniger Strom, darf man aktuell nicht vergessen.

Das hängt immer ganz vom Workload ab. Ich hab hier daheim VMs die mit DBs arbeiten, die lasten schon alleine eine HDD zu 100% aus. DA wären HDDs z.B. völlig undenkbar.