Usv on zefanjas.de - Open Source & Education

XenServer automatisch herunterfahren mit NUT

Sat, 21 Apr 2018 00:18:23 +0000

Unsere Kerninfrastruktur an der Schule ist mit USVs /UPS abgesichert. Wir haben leider immer wieder Stromausfälle (meist kurze) und mit Hilfe der USVs können wir diese zumindest etwas überbrücken. An unserer USV / UPS hängt [ein Raspberry Pi, der als NUT Server][1] eingerichtet ist. Wenn der Strom ausfällt und die USV / UPS auf Batteriebetrieb umschaltet, sendet der Raspberry Pi ab einem bestimmten Ladestand einen Befehl an alle verbunden Server. Diese fahren sich dann automatisch herunter. Alle unsere Virtuellen Maschinen, Backup-Systeme und Server werden damit heruntergefahren. Ein wesentlicher Server hat aber bisher noch gefehlt: der Virtualisierungshost. Deshalb möchte ich heute kurz beschreiben, wie man einen XenServer automatisch herunterfahren lassen kann, indem man ihn als NUT-Client einrichtet.

NUT-Client installieren

XenServer basiert auf CentOS, aber die Installation von Fremdpaketen ist nicht erlaubt. Man sollte sich auch bewusst sein, dass man evtl. keinen Support mehr erhält (falls man einen Supportvertrag hat), wenn man zusätzliche Pakete installiert.

Um den NUT-Client installieren zu können, mussten wir bei unserem XenServer 7 noch folgende Anpassung in der Datei /etc/yum.repos.d/CentOS-Base.repo vornehmen. Im Abschnitt [extras] haben wir in der Zeile baseurl $releaseserver mit einer 7 ersetzt.

$ nano /ect/yum.repos.d/CentOS-Base.repo
...
[extras]
name=CentOS-$releasever - Extras
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep$
baseurl=http://mirror.centos.org/centos/7/extras/$basearch/
...

Danach können wir das Epel-Repo einrichten und den NUT-Client installieren:

$ yum clean all
$ yum --enablerepo=extras -y install epel-release
```

Nun schauen wir, welches Paket unseren NUT-Client zur Verfügung stellt und installieren es:

```
$ yum provides /usr/sbin/upsmon
Geladene Plugins: fastestmirror
Loading mirror speeds from cached hostfile
* epel: mirrors.bangmodhosting.com
nut-2.7.2-3.el7.x86_64 : Network UPS Tools
Quelle : epel
Übereinstimmung von:
Dateiname : /usr/sbin/upsmon
```

```
$ yum install nut-client-2.7.2-3.el7.x86_64
```

### NUT einrichten

Nachdem der NUT-Client nun installiert ist, müssen wir ihn noch konfigurieren, damit unserer XenServer auch herunterfährt, falls der Strom ausfällt. Zuerst müssen wir noch eine Datei erstellen, um NUT mitzuteilen, dass unser XenServer ein Client ist:

```
$ nano /etc/ups/nut.conf
MODE=netclient

```

In der Datei _**/etc/ups/upsmon.conf**_ findet die Hauptkonfiguration statt. Dort ändern wir zwei Zeilen:

```
$ nano /etc/ups/upsmon.conf
...
MONITOR ups@192.168.1.2 1 upsremote password slave
...
SHUTDOWNCMD "/etc/ups/xen-shutdown.sh"
...
```

Je nach Konfiguration des NUT-Masters muss hier noch der UPS-Name, die IP, sowie Benutzername und Passwort angepasst werden.

Bevor unser XenServer herunterfährt, soll er vorher noch alle Virtuellen Maschinen ausschalten. Dazu habe ich [folgendes Skript][2] gefunden, welches wir nun herunterladen und ausführbar machen.

```
$ cd /etc/ups/
$ wget https://raw.githubusercontent.com/serrc-techops/NUT-Configuration/master/slave/xen/xen-shutdown.sh
$ chmod +x xen-shutdown.sh
```

Damit der NUT-Client auch automatisch startet, müssen wir noch einen Systemd-Service einrichten. Dazu erstellen wir die Datei _**/etc/systemd/system/nut-monitor.service**_ und fügen folgenden Inhalt ein:

```
$ nano /etc/systemd/system/nut-monitor.service

[Unit]
Description=Network UPS Tools - power device monitor and shutdown controller
After=local-fs.target network.target

[Service]
ExecStart=/usr/sbin/upsmon
PIDFile=/run/nut/upsmon.pid
Type=forking

[Install]
WantedBy=multi-user.target
```

Nun aktivieren wir diesen Service und starten ihn:

```
$ systemctl enable nut-monitor.service
$ systemctl daemon-reload
$ systemctl start nut-monitor
```

Mit `systemctl status nut-monitor` können wir uns anzeigen lassen, ob alles läuft:

```
nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller
Loaded: loaded (/etc/systemd/system/nut-monitor.service; enabled; vendor preset: disabled)
Active: active (running) since Mi 2018-04-18 17:13:42 ICT; 1 day 12h ago
Process: 997 ExecStart=/usr/sbin/upsmon (code=exited, status=0/SUCCESS)
Main PID: 1001 (upsmon)
CGroup: /system.slice/nut-monitor.service
├─1000 /usr/sbin/upsmon
└─1001 /usr/sbin/upsmon
```

### Automatisches Herunterfahren testen

Zuerst können wir das Skript zum Herunterfahren des XenServers testen und schauen, ob auch alle gestarteten VMs heruntergefahren werden. Dazu führen wir das Skript einfach aus:

```
$ sh /etc/ups/xen-shutdown.sh
```

Um einen Stromausfall zu simulieren und können wir auf dem _NUT Master_ folgenden Befehl absetzen:

```
$ sudo upsmon -c fsd
```

Danach muss man allerdings alle Geräte wieder von Hand einschalten oder per Wake-on-Lan wecken.

### Fazit

[NUT][3] ist ein tolles Projekt und es erlaubt uns sehr flexible Einsatzszenarien. Zur Zeit haben wir nur eine große UPS am NUT Master angeschlossen, aber es ist auch durchaus denkbar, mehrere UPS an den NUT Master anzuschließen. In Kombination mit Check_MK können wir somit den Status der USV / UPS ständig überwachen und bekommen ganz nebenbei auch eine Statistik, wie oft der Strom bei uns ausgefallen ist.

 [1]: https://zefanjas.de/server-bei-stromausfall-herunterfahren-ups-nut-co/
 [2]: https://github.com/serrc-techops/NUT-Configuration/blob/master/slave/xen/xen-shutdown.sh
 [3]: http://networkupstools.org/

Server bei Stromausfall herunterfahren – UPS, NUT & Co

Mon, 27 Nov 2017 22:29:51 +0000

An unserer Schule gibt es immer wieder Stromausfälle. Manchmal dauern sie nur wenige Sekunden, manchmal aber auch mehrere Stunden. Damit unsere IT-Infrakstruktur nicht darunter leidet, haben wir für unsere Server und Netzwerkgeräte eine [UPS/USV][1] installiert. Diese helfen kürzere Stromausfälle (bis zu 1 Stunde) oder Stromschwankungen zu überbrücken. Für alle längeren Ausfälle fahren wir unsere Server automatisch herunter, wenn die UPS ein kritisches Batterielevel erreicht. Dafür nutzen wir NUT ([Network UPS Tools][2]).

Unser Setup besteht aus folgenden Komponenten:

Raspberry Pi als UPS-Server bzw. Master
Liebert GXT4 UPS
Server als Clients bzw. Slaves

UPS / USV in NUT auf dem Raspberry Pi einrichten

Für den Raspberry Pi verwenden wir das Standard [Raspian Stretch Lite Image][3]. Zu beachten ist, dass SSH seit 2016 standardmäßig nicht mehr aktiviert ist. Die verschiedenen Möglichkeiten, wie man SSH wieder aktiveren kann, sind [hier dokumentiert][4]. Nachdem SSH nun wieder aktiviert ist, kann man sich nun auf dem Raspberry Pi einloggen (die IP des Raspberry Pi kann man z.B. mit avahi-browse -ar von einem Rechner im gleichen Netzwerk herausfinden oder man schließt einen Monitor und Tastatur an). Die IP brauchen wir später noch, deshalb ist es sinnvoll dem Raspberry Pi [eine statische IP][5] zu geben.

Als nächstes installieren wir den NUT-Server mit

sudo apt-get install nut-client nut-server usbutils
```

Falls die UPS / USV per USB angeschlossen ist (wie in unserem Fall), kann man mit lsusb überprüfen, ob sie auch erkannt wurde. So sieht die Ausgabe auf dem Raspberry Pi aus:

$ lsusb
Bus 001 Device 004: ID 10af:0000 Liebert Corp. UPS
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
```

In der ersten Zeile sieht man, dass unsere Liebert UPS erkannt wurde.

Nun müssen wir unsere UPS / USV in der Datei _**/etc/nut/ups.conf**_ konfigurieren. Für unsere UPS sieht der Eintrag folgendermaßen aus:

[gxt4]
     driver = usbhid-ups
     port = auto
     productid = 0000
     desc = "Emerson Liebert GXT 4"
```

Auf der [Website der Network UPS Tools][6] findet man eine Liste mit allen unterstützen UPS /USV und mit welcher Treiber am besten funktioniert.

Als nächstes wollen wir testen, ob die Einstellungen korrekt sind der UPS Daemon mit der UPS kommunizieren kann. Dazu starten wir **upsd** mit sudo upsdrvctl start . Eine erfolgreiche Ausgabe sollte ungefähr so aussehen:

Network UPS Tools - UPS driver controller 2.7.2
Network UPS Tools - Generic HID driver 0.38 (2.7.2)
USB communication driver 0.32
Using subdriver: Belkin HID 0.16
```

NUT enthält einen kleines Programm, mit dem man die Kommunikation mit der UPS /USV testen kann. Es heißt **upsc** und gibt alle lesbaren Parameter der UPS / USV aus.

$ upsc gxt4
Init SSL without certificate database
battery.charge: 100
battery.charge.low: 20
battery.charge.warning: 0
battery.type: PbAc
battery.voltage: 0.0
battery.voltage.nominal: 0.0
device.mfr: Emerson Network Power
device.model: Liebert GXT4
device.serial: 1607000060AFC23
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.productid: 0000
driver.version: 2.7.2
driver.version.data: Belkin HID 0.16
driver.version.internal: 0.38
ups.mfr: Emerson Network Power
ups.model: Liebert GXT4
ups.productid: 0000
ups.serial: 1607000060AFC23
ups.status: OL CHRG
ups.vendorid: 10af
```

Nun ist unsere UPS /USV erfolgreich eingerichtet. Als nächsten richten wir den NUT Server, den UPS Monitor **upsmon** und noch zwei Benutzer für den Master und die Slaves ein.

### NUT Server konfigurieren

In der _**/etc/nut/nut.conf**_ legen wir fest, dass der Raspberry Pi unser Master ist:

MODE=netserver
```

Auf dem NUT-Server läuft der UPS Daemon (**upsd**). Er ist für die (physikalische) Verbindung zur UPS verantwortlich. Die einzelnen Clients/Slaves greifen mit Hilfe des **upsmon** auf den Status der UPS zu. So können mehrere Clients immer über den Zustand der UPS informiert sein und gegebenenfalls das Herunterfahren auslösen, wenn die UPS den Status „On Low Battery“ liefert.

Damit unser NUT Server aus dem Netz erreichbar ist, müssen noch folgende Zeilen in der _**/etc/nut/upsd.conf**_ hinzugefügt werden (IP bitte anpassen):

LISTEN 127.0.0.1
LISTEN 192.168.1.2 #IP des Raspberry Pis
```

Als nächstes legen wir die Benutzer fest mit der sich ein Client beim Master anmelden kann (in der Datei _**/etc/nut/upsd.user**_):

```
[upsmaster]
    password = geheim
    upsmon master

[upsremote]
        password  = geheim
        upsmon slave
```

Damit **upsmon** die UPS auch überwacht, müssen wir nun noch eine letzten Eintrag in der Datei **/etc/nut/upsmon.conf** hinzufügen:

```
MONITOR gxt4@localhost 1 upsmaster geheim master
```

Damit man weiß, ob alle Dienste richtig laufen, kann man den Status des Servers als auch den lokalen Clients auf dem Raspberry Pi (denn der soll ja auch heruntergefahren werden, wenn kein Strom mehr da ist) mit folgendem Befehlen überprüfen:

```
$ sudo systemctl status nut-server
$ sudo systemctl status nut-client
```

Nun ist unser Master fertig eingerichtet und die Clients bzw. Slaves können jetzt konfiguriert werden.

### Clients / Slaves einrichten (z.B. Server, andere Computer)

Zuerst müssen auf einem Client die notwendigen Pakete installiert werden:

```
sudo apt-get install nut-client
```

Diesmal müssen wir nur zwei Dateien editieren. In der _**/etc/nut/nut.conf**_ legen wir den Modus fest:

```
MODE=netclient
```

Danach müssen wir wieder **upsmon** sagen, welche UPS er überwachen soll (in _**/etc/nut/upsmon.conf**_):

```
MONITOR gxt4@192.168.1.2 upsremote geheim slave
```

Die IP und das Passwort müssen natürlich noch angepasst werden. Bitte auch das **slave** am Ende beachten! Zuletzt noch den entsprechenden Service neu starten und überprüfen, ob alles läuft:

$ sudo systemctl restart nut-client
$ sudo systemctl status nut-client
```

Glückwunsch! Nun sollte alles eingerichtet sein, aber wie kann man testen, dass es wirklich funktioniert?

### Herunterfahren testen

Der folgende Befehl löst das Signal zum Herunterfahren aus (wie es auch im Falle eines Stromausfalls sein würde):

```
$ sudo upsmon -c fsd
```

### UPS mit Check_MK überwachen [Update]

#### Check_MK Agent einrichten

Nachdem die UPS jetzt fertig eingerichtet ist, wäre es natürlich toll, wenn wir sie auch im Monitoring überwachen können. Wir nutzen dafür Check\_MK. Clients können in Check\_MK mit dem Check_MK Agenten oder per SNMP überwacht werden. Der Agent ist in den Standard-Paketquellen von Debian und Ubuntu enthalten, weshalb wir ihn einfach mit diesem Befehl auf dem Raspberry Pi installieren können:

```
$ sudo apt-get install check-mk-agent xinetd
```

Standardmäßig ist der Check_MK Agent nicht aktiviert, sodass wir ihn noch in der Datei _**/etc/xinetd.d/check_mk**_ noch aktivieren müssen. Am Ende der Datei muss disable = yes  in disable = no  geändert werden. Wenn man möchte, kann man auch noch den Zugriff einschränken, indem man mit only_from = IP-des-Check-MK-Severs  die Server-IPs einträgt, die die Erlaubnis haben die Daten des Check_MK Agenten abzufragen.

Als nächstes muss xinetd neu gestartet werden. Mit dem zweiten Befehl überprüfen wir, ob der Check_MK Agent richtig konfiguriert ist und läuft (IP anpassen!).

```
$ sudo service xinetd restart
$ telnet 192.168.1.2 6556
```

#### NUT Plugins

Bisher weiß der Check_MK Agent noch nichts von unserer UPS und liest die entsprechenden Daten auch nicht aus. Mit folgendem kleinen Skript können wir die Ausgabe von upsc dem Agenten mitteilen:

```
#!/bin/sh

if which upsc > /dev/null 2>&1 ; then
    echo '<<<nut>>>'
    for ups in $(upsc -l)
    do
        upsc $ups| sed "s,^,$ups ,"
    done
fi
```

Diese kleine Plugin speichern wir unter _**/usr/lib/check\_mk\_agent/plugins/nut**_. Auf dem Raspberry Pi sind wird nun fertig. Es fehlen jetzt noch die Anpassungen auf dem Check_MK Server.

Auf dem Server brauchen wir ein weiteres Skript, welches die Daten des Check_MK Agenten ausliest. Dieses Skript ist umfangreicher, deshalb [verlinke ich es hier][7]. Es muss unter _**/opt/omd/versions/default/share/check_mk/checks/nut**_ gespeichert werden. Das Original-Plugin kann man hier finden: . Ich habe es minimal angepasst für unsere UPS angepasst.

Wenn man nun den Raspberry Pi als neuen Host in Check_MK hizufügt, werden die Services für die UPS / USV mit angezeigt.

 NUT Services 

### Fazit

NUT ist ein [weiteres tolles Open Source Projekt][8], mit dem sehr flexible Anpassungen möglich sind. In [dieser PDF][9] sind noch viele weitere (komplexe) Anwendungsszenarien enthalten. Während ich diesen Artikel schreibe, haben wir wieder einen Stromausfall und alle unsere Server sind zuverlässig heruntergefahren worden!

 

 [1]: https://de.wikipedia.org/wiki/Unterbrechungsfreie_Stromversorgung
 [2]: http://networkupstools.org/
 [3]: https://www.raspberrypi.org/downloads/raspbian/
 [4]: https://www.raspberrypi.org/documentation/remote-access/ssh/
 [5]: http://www.imakeyouintelligent.com/raspberry-raspbian-stretch-static-ip/
 [6]: http://networkupstools.org/stable-hcl.html
 [7]: https://gist.github.com/zefanja/585a96988656f24c507e573042564d8e#file-nut-plugin-server
 [8]: https://zefanjas.de/2017/11/18/5-grossartige-open-source-programme-die-wir-in-unserer-schule-einsetzen/
 [9]: http://rogerprice.org/NUT/ConfigExamples.A5.pdf