Konfiguracja UPS-a pod Debianem
Podłączenie serwera do UPS-a nie zapewnia automatycznie bezpieczeństwa danych zgromadzonych na dyskach twardych w przypadku awarii zasilania, gdyż każdy UPS ma ograniczony czas pracy na baterii. Po jej rozładowaniu następuje zanik napięcia zasilania i dyski w nieskonfigurowanym serwerze narażone są na uszkodzenie na skutek gwałtownego zatrzymania, nie mówiąc o integralności danych w przypadku trwającej operacji zapisu.
Jedną z usług, dbającą o monitorowanie stanu UPS-a i wywołująca zamykanie systemu w przypadku krytycznie niskiego poziomu energii w UPS-ie, jest NUT (Network UPS Tools). Możliwości NUT-a są całkiem spore — zasadniczo jest to serwer wraz z klientami, umożliwiający zbudowanie całej sieci maszyn, które podłączając się do serwera, monitorują stan UPS-ów i podejmują decyzję np. o wyłączeniu poszczególnych serwerów.
Poniżej przedstawię konfigurację w najprostszej sytuacji, gdy posiadamy tylko jedną maszynę, która monitoruje bezpośrednio podłączony do niej UPS, czyli pełni rolę serwera, i jednocześnie jest jedynym klientem, który po otrzymaniu informacji o krytycznie niskim poziomie baterii zamyka system operacyjny i wyłącza się. Konfiguracja została przetestowana na Debianie 5.0.
Konfiguracja NUT-a
Konfiguracja NUT-a umieszczona jest w katalogu /etc/nut/. Plik ups.conf zawiera opis naszych UPS-ów wraz ze sterownikami. Korzystam z UPS-a ORVALDI 1500 RT i sterownika megatec_usb. UPS podłączony jest do serwera kablem USB.
[orvaldi] driver = megatec_usb port = auto
Jak wskazuje definicja, dalej będziemy się odwoływali do tego UPS-a przez nazwę orvaldi.
W następnym kroku konfigurujemy serwer, zapisując w pliku upsd.conf:
ACL localhost 127.0.0.1/32 ACL all 0.0.0.0/0 ACL mojasiec 192.168.2.0/24 ACL mojvpn 10.1.0.0/24 ACL mojserwer 192.168.2.1/32 LISTEN localhost LISTEN mojserwer ACCEPT localhost ACCEPT mojasiec ACCEPT mojvpn REJECT all
Tak skonfigurowany serwer NUT-a będzie nasłuchiwał w sieci lokalnej mojasiec i VPN-ie mojvpn. Udostępniając serwer przez VPN-a, zyskujemy możliwość prostego i bezpiecznego zdalnego monitorowania UPS-a, co opiszę dalej.
Tymczasem w pliku upsd.users dodamy użytkownika, który będzie mógł monitorować zasilanie:
[monuser] password = bezpiecznehaslo allowfrom = localhost upsmon master
Konfiguracja upsmona
Serwer został skonfigurowany, czas dodać daemona upsmon, który odpowiada za wyłączanie maszyny i powiadamianie administratora o awarii. Najpierw tworzymy plik upsmon.conf z ustawieniami:
MONITOR orvaldi@localhost 1 monuser bezpiecznehaslo master SHUTDOWNCMD "/usr/bin/beep -f 4000 -l 100 -r 10 -d 10 ; shutdown -h now" MINSUPPLIES 1 POLLFREQ 5 POLLFREQALERT 5 HOSTSYNC 15 DEADTIME 15 POWERDOWNFLAG /etc/killpower NOTIFYCMD /sbin/upssched NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC NOTIFYFLAG REPLBATT SYSLOG+WALL+EXEC FINALDELAY 5
Pozycja MONITOR podłącza nas do monitora wskazanego UPS-a. SHUTDOWNCMD określa, jakie polecenie zamyka system. Tu standardowe shutdown -h now poprzedziłem kilkoma piknięciami głośniczka systemowego. Kolejne opcje to standardowe wartości, określające zależności czasowe między UPS-em, serwerem i klientami. NOTIFYCMD mówi, że powiadomienia nadzorowane są przez program upssched, który daje nieco większe możliwości niż prosty skrypt, wysyłający maile. Pozycje NOTIFYFLAG mowią o akcjach podejmowanych przy zdarzeniach takich jak przejście na zasilanie sieciowe, przejście na zasilanie bateryjne, niski poziom baterii czy konieczność jej wymiany — tu powiadomienia są zapisywane w logu, wypisywane na konsoli i przekazywane do programu upssched.
Program upssched umożliwia budowanie regułek, reagujących w określony sposób na zdarzenia. Konfigurujemy go w pliku upssched.conf:
CMDSCRIPT /etc/nut/upssched-cmd PIPEFN /var/lib/nut/upssched.pipe LOCKFN /var/lib/nut/upssched.lock AT ONBATT * START-TIMER onbatt 30 AT ONLINE * CANCEL-TIMER onbatt AT LOWBATT * EXECUTE lowbatt AT SHUTDOWN * EXECUTE shutdown AT REPLBATT * EXECUTE replbatt AT NOCOMM * EXECUTE nocomm
W przypadku prostych systemów najważniejszą możliwością, jaką otrzymujemy, są timery. Tutaj użyłem timera, który po przejściu na zasilanie bateryjne odczekuje 30 sekund i dopiero wtedy wysyła komunikat onbatt do skryptu upssched-cmd. Jeżeli zasilanie sieciowe zniknie na mniej niż 30 sekund, powiadomienie nie zostanie wysłane.
Skrypt upssched-cmd zawiera tylko prostą instrukcję case, odpowiedzialną za wysyłanie odpowiednich maili:
#!/bin/bash EMAIL="twojemail@example.com" case $1 in "onbatt") msg="Zanik napięcia sieciowego. System zasilany z baterii." ;; "online") msg="Przywrócenie napięcia sieciowego." ;; "lowbatt") msg="Krytycznie niski poziom baterii." ;; "shutdown") msg="Zamknięcie systemu." ;; "replbatt") msg="Bateria wymaga wymiany!" ;; "nocomm") msg="Brak komunikacji z UPS-em!" ;; *) msg="Nieznana komenda: $1." ;; esac echo $msg | mail -s "UPS monitor" $EMAIL
Uruchomienie usług
Aby NUT uruchamiał się wraz z upsmonem, musimy jeszcze zmodyfikować /etc/default/nut:
# start upsd START_UPSD=yes # set upsd specific options. use "man upsd" for more info UPSD_OPTIONS="" # start upsmon START_UPSMON=yes # set upsmon specific options. use "man upsmon" for more info UPSMON_OPTIONS=""
Na koniec zmieniamy uprawnienia plików konfiguracyjnych, aby nie mieli do nich dostępu niepowołani użytkownicy:
# chown root:nut /etc/nut/* # chmod o-rwx /etc/nut/*
Teraz możemy zrestartować NUT-a, który załaduje sobie sterownik i podłączy się do UPS-a:
# /etc/init.d/nut restart
W /var/log/daemon.log powinniśmy znaleźć mniej więcej taki log:
Jul 18 22:06:52 mojserwer upsmon[18890]: Signal 15: exiting Jul 18 22:06:52 mojserwer upsd[18886]: Client monuser@127.0.0.1 logged out Jul 18 22:06:52 mojserwer upsmon[18888]: upsmon parent: read Jul 18 22:06:52 mojserwer upsd[18886]: Signal 15: exiting Jul 18 22:07:02 mojserwer upsd[26794]: listening on localhost port 3493 Jul 18 22:07:02 mojserwer upsd[26794]: listening on mojserwer port 3493 Jul 18 22:07:02 mojserwer upsd[26794]: Connected to UPS [orvaldi]: megatec_usb-orvaldi Jul 18 22:07:02 mojserwer upsd[26795]: Startup successful Jul 18 22:07:02 mojserwer upsmon[26797]: Startup successful Jul 18 22:07:02 mojserwer upsd[26795]: Connection from 127.0.0.1 Jul 18 22:07:02 mojserwer upsd[26795]: Client monuser@127.0.0.1 logged into UPS [orvaldi]
Testy
Aby przetestować rozkaz SHUTDOWNCMD z pliku upsmon.conf, wydajemy komendę:
# /usr/local/ups/bin/upsdrvctl -t shutdown
Symuluje ona awarię zasilania i wyświetla sekwencję zamykania systemu. Jeżeli wszystko przedstawia się poprawnie, możemy wykonać test, pozwalający w praktyce sprawdzić, czy system się zamknie:
# /usr/local/ups/sbin/upsmon -c fsd
Uwaga! Symuluje to awarię zasilania i w przypadku poprawnej konfiguracji owocuje wyłączeniem komputera!
Monitorowanie statusu zasilania
Poza automatycznym monitoringiem upsmona możemy skorzystać też z opcji monitoringu na żądanie, np. za pomocą polecenia upsc:
# upsc orvaldi@localhost battery.charge: 95.0 battery.voltage: 27.00 battery.voltage.nominal: 24.0 driver.name: megatec_usb driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.2.2 driver.version.internal: 1.5.14 input.frequency: 50.0 input.frequency.nominal: 50.0 input.voltage: 236.5 input.voltage.fault: 140.0 input.voltage.maximum: 240.5 input.voltage.minimum: 228.5 input.voltage.nominal: 230.0 output.voltage: 236.5 ups.beeper.status: disabled ups.delay.shutdown: 0 ups.delay.start: 2 ups.load: 22.0 ups.mfr: ups.model: JP0508C5 ups.serial: unknown ups.status: OL ups.temperature: 25.0 ups.type: standby
Wcześniej wspominałem, że możliwa jest także zdalna obserwacja UPS-a, np. z wykorzystaniem VPN-a, jeśli nie chcemy udostępniać portu NUT-a w Internecie. Znakomicie sprawdza się tu klient KNutClient, który czuwa w zasobniku systemowym i wyświetla bieżące obciążenie UPS-a oraz powiadomienia o zdarzeniach takich jak przejście na zasilanie akumulatorowe. W jego konfiguracji wystarczy podać adres serwera i nazwę UPS-a (nie ma potrzeby podawania nazwy użytkownika i hasła, jeśli zależy nam tylko na monitoringu).
Dla dociekliwych
Zainteresowani bardziej skomplikowaną konfiguracją NUT-a, znajdą stosowne informacje w dokumentacji. Na początek polecam rozdział Shutdown design, tłumaczący krok po kroku, jak system obsługuje zdarzenia związane z awarią zasilania.
