Watchdog – samodzielne monitorowanie stanu VM w chmurze: od /dev/watchdog po test resetu

Blog WebDisk · kategoria: Chmura obliczeniowa · czas czytania: ~9 minut

W skrócie:- Panel chmury może pokazywać „Running”, choć system wewnątrz VM od kwadransa nie odpowiada – mechanizmy HA hypervisora widzą maszynę z zewnątrz, nie jej wnętrze.- Watchdog to licznik odliczany poza systemem gościa: jeśli system przestanie go regularnie „zerować”, hypervisor twardo resetuje VM – nawet gdy jądro jest całkowicie zawieszone.- Reakcją jest reset, nie naprawa – dlatego w WebDisk Cloud urządzenie /dev/watchdog jest dostępne w maszynach, ale mechanizmu nie włączamy za Ciebie; w artykule pokazujemy, jak zrobić to świadomie. >Nie pracujesz z terminalem? Pomiń bloki poleceń – opis mechanizmu, zestawienie porównawcze i sekcja o granicach rozwiązania czytają się bez nich.

Jest 3:00 w nocy. Monitoring infrastruktury świeci na zielono, panel chmury pokazuje przy Twojej maszynie status „Running” – a klienci od dwudziestu minut nie mogą otworzyć aplikacji. System operacyjny wewnątrz VM zawiesił się na dobre: jądro przestało planować procesy, konsola nie reaguje, po SSH nie ma śladu. Z perspektywy infrastruktury nic się nie stało, bo proces maszyny wirtualnej na fizycznym serwerze działa bez zarzutu. Awaria jest niewidzialna dokładnie tam, gdzie patrzą automaty.

Na ten scenariusz istnieje mechanizm starszy niż chmura: watchdog – dosłownie „pies stróżujący”, licznik czasu, który trzeba regularnie zerować, bo inaczej gryzie. W tym artykule wyjaśniamy, czym watchdog uruchomiony wewnątrz maszyny różni się od wysokiej dostępności (HA) na poziomie hypervisora, jak działa urządzenie /dev/watchdog, jak krok po kroku włączyć i przetestować watchdoga w Ubuntu – oraz, uczciwie, kiedy lepiej go nie włączać. Tekst przyda się każdemu, kto utrzymuje maszyny wirtualne w chmurze – w WebDisk Cloud i nie tylko.

Dlaczego panel chmury pokazuje „Running”, choć VM nie działa?

Klasyczne mechanizmy wysokiej dostępności w chmurze działają na poziomie infrastruktury. Hypervisor (oprogramowanie, które uruchamia maszyny wirtualne na fizycznym serwerze) i warstwa zarządzająca pilnują dwóch rzeczy: czy żyje host i czy żyje proces VM. Gdy padnie fizyczny serwer – maszyny wstają na innym; gdy proces VM niespodziewanie zniknie – zostaje uruchomiony ponownie. To ważna siatka bezpieczeństwa, ale patrzy na maszynę wyłącznie z zewnątrz.

Tymczasem spora część realnych awarii dzieje się wewnątrz systemu gościa: zakleszczenie jądra (kernel lockup), zawieszony proces init/systemd, wyczerpana pamięć, po której system miota się między zabijaniem procesów a swapem, błąd sterownika. Maszyna „działa” – czasem nawet odpowiada na ping – ale nie świadczy usługi i nie da się do niej zalogować. Dla mechanizmów HA hypervisora taki stan jest nieodróżnialny od zdrowego: proces VM istnieje, więc z ich punktu widzenia nie ma czego ratować.

Właśnie tę lukę domyka watchdog uruchomiony w samej maszynie.

Jak działa watchdog i /dev/watchdog?

Zasada działania jest celowo prymitywna – i w tym tkwi jej siła. Watchdog to licznik odliczający w dół, umieszczony poza kontrolą nadzorowanego systemu. System musi go cyklicznie zerować; jeśli przestanie – licznik dobiega końca i uruchamia z góry ustaloną reakcję. W serwerach fizycznych taką rolę pełni układ na płycie głównej; w maszynie wirtualnej – wirtualne urządzenie watchdog, które hypervisor wystawia gościowi. W Linuksie widać je jako plik urządzenia /dev/watchdog. Po jego otwarciu licznik się uzbraja: od tej chwili ktoś musi regularnie do niego pisać.

W praktyce robi to demon watchdog: otwiera urządzenie i „melduje się” co kilka–kilkanaście sekund. Dopóki system działa, meldunki płyną. Gdy jądro się zawiesi, demon nie dostanie czasu procesora, licznik dobiegnie zera, a hypervisor wykona skonfigurowaną akcję – twardy reset maszyny. Kluczowe jest to, że egzekucja odbywa się poza systemem gościa: zawieszone jądro nie może jej powstrzymać, bo licznik nie tyka w tym jądrze, tylko piętro niżej.

Demon potrafi przy tym więcej niż meldować „żyję”. W pliku konfiguracyjnym można dodać testy kondycji: maksymalne obciążenie systemu, obecność procesu o wskazanym pliku PID, świeżość pliku (czy log wciąż przyrasta), odpowiedź wskazanego hosta na ping, wreszcie własne skrypty testowe. Jeśli któryś test trwale zawodzi, demon celowo przestaje zerować licznik i doprowadza do resetu – mimo że jądro formalnie działa. Dzięki temu reaguje także na „miękkie” zwisy, nie tylko na śmierć kliniczną systemu.

Czym watchdog różni się od HA hypervisora?

Co obserwuje – HA na poziomie hypervisora: fizyczny host i proces VM · Watchdog wewnątrz VM: wnętrze systemu gościa
Wykrywa – HA na poziomie hypervisora: awarię hosta, zniknięcie procesu VM · Watchdog wewnątrz VM: zawieszenie jądra, brak odpowiedzi systemu, niezdane testy kondycji
Nie wykrywa – HA na poziomie hypervisora: zwisu wewnątrz działającego procesu VM · Watchdog wewnątrz VM: awarii hosta (to nie jego rola)
Reakcja – HA na poziomie hypervisora: ponowne uruchomienie VM, np. na innym hoście · Watchdog wewnątrz VM: twardy reset VM
Kto włącza i konfiguruje – HA na poziomie hypervisora: dostawca chmury · Watchdog wewnątrz VM: użytkownik, wewnątrz własnej maszyny

Te dwa mechanizmy nie konkurują ze sobą – patrzą na tę samą maszynę z dwóch przeciwnych stron i dopiero razem domykają obraz awarii: od padu fizycznego serwera po zawieszone jądro. Co ważne w środowisku współdzielonym: watchdog konfiguruje się w całości wewnątrz VM, bez zmian po stronie hypervisora – użytkownik chmury może więc podnieść odporność swojego systemu samodzielnie, nie naruszając separacji odpowiedzialności między nim a dostawcą.

Jak włączyć watchdoga w Ubuntu krok po kroku?

Przykład dotyczy Ubuntu Server (np. 22.04 lub 24.04); w innych dystrybucjach Linuksa różnią się co najwyżej nazwy pakietów.

1. Sprawdź, czy maszyna widzi urządzenie:

ls -l /dev/watchdog*
# crw------- 1 root root 10, 130 ... /dev/watchdog

Jeśli pliku nie ma, hypervisor nie wystawił maszynie wirtualnego urządzenia watchdog (co robić w takiej sytuacji – patrz FAQ; w WebDisk Cloud urządzenie jest dostępne).

2. Zainstaluj demona:

sudo apt update
sudo apt install watchdog

3. Skonfiguruj plik /etc/watchdog.conf:

sudo nano /etc/watchdog.conf

Minimalna, rozsądna konfiguracja startowa:

# urządzenie i rytm meldunków
watchdog-device = /dev/watchdog
interval = 10 # demon melduje się co 10 s; musi to być
# wyraźnie mniej niż limit czasu urządzenia

# opcjonalne testy kondycji – odkomentuj świadomie:
#max-load-1 = 24 # reset przy 1-min. load > 24
#pidfile = /run/mysqld/mysqld.pid # pilnuj konkretnego procesu
#file = /var/log/syslog # wskazany plik musi się zmieniać…
#change = 1800 # …przynajmniej co 1800 s

4. Włącz usługę i obserwuj:

sudo systemctl enable --now watchdog
systemctl status watchdog
journalctl -u watchdog -f # meldunki i wyniki testów na żywo

Od tej chwili maszyna jest pod nadzorem. Dwie uwagi porządkowe: planowe zatrzymanie usługi (systemctl stop watchdog) zamyka urządzenie „czysto” i rozbraja licznik, więc w domyślnej konfiguracji nie kończy się resetem; testy kondycji dopisuj pojedynczo i obserwuj logi po każdej zmianie – o tym, dlaczego to ważne, za chwilę w bilansie.

Przetestuj, zanim zaufasz

Ostrzeżenie. Poniższy test twardo resetuje maszynę – dokładnie tak, jak zrobiłby to watchdog przy prawdziwej awarii. Wykonuj go wyłącznie na maszynie testowej albo w uzgodnionym oknie serwisowym; wszystkie niezapisane dane przepadną.

Watchdog, którego nigdy nie zweryfikowano, to tylko wpis w konfiguracji. Najbardziej wiarygodny test symuluje właśnie ten scenariusz, przed którym mechanizm ma chronić – natychmiastowe zawieszenie jądra:

# wymusza crash jądra – system natychmiast przestaje odpowiadać
echo c | sudo tee /proc/sysrq-trigger

Maszyna zamiera: sesja SSH pada, konsola nie reaguje. Demon przestaje meldować się urządzeniu, licznik dobiega zera i hypervisor resetuje VM. Po powrocie systemu sprawdź przebieg zdarzenia:

uptime # świeży czas działania = reset zadziałał
journalctl -b -1 -e # ostatnie wpisy z poprzedniego uruchomienia

Jeśli maszyna zamiast zresetować się po upływie limitu wisi w nieskończoność – wróć do poprzedniej sekcji: najczęściej okazuje się, że demon nie działał albo nie otwierał właściwego urządzenia.

Kiedy nie włączać watchdoga i jakie ma ograniczenia?

Nazwijmy rzeczy po imieniu: watchdog niczego nie diagnozuje i nie naprawia. Jego jedyną reakcją jest twardy reset – odpowiednik wyciągnięcia wtyczki z gniazdka:

Reset przerywa wszystko, także operacje w toku. Systemy plików z księgowaniem (ext4, XFS) i bazy danych z mechanizmami odtwarzania po awarii są projektowane tak, by taki restart przetrwać, ale dane niezapisane na dysk przepadają. Watchdog w żadnym razie nie zastępuje kopii zapasowych – pisaliśmy o nich w artykule Backup w chmurze – fundament bezpieczeństwa IT.
Reset maskuje przyczynę. Maszyna, która „sama” restartuje się co kilka dni, w statystykach dostępności wygląda na zdrową, choć choruje. Watchdog powinien iść w parze z monitoringiem i analizą logów – reset to plaster, nie leczenie.
Tracisz materiał dowodowy. Zawieszona maszyna to także stop-klatka awarii; reset ją kasuje. Gdy próbujesz zdiagnozować trudny do odtworzenia zwis, watchdog bywa wrogiem śledztwa.
Testy kondycji bywają fałszywie dodatnie. Reguła w rodzaju max-load-1 na maszynie, która zgodnie z planem liczy coś ciężkiego, potrafi zresetować system w środku poprawnie wykonywanej pracy. Dlatego progi dobiera się do charakteru obciążenia, a nowe testy włącza pojedynczo, z okresem obserwacji.

Kiedy watchdoga nie włączać? Gdy maszyna wykonuje długie zadania wsadowe bez punktów kontrolnych; gdy analizujesz powtarzający się zwis i potrzebujesz „żywej” maszyny do diagnozy; gdy usługa i tak stoi za load balancerem, który sam wyłącza chore instancje. Najwięcej watchdog daje na samodzielnych maszynach, których nikt nie dubluje: pojedynczy serwer aplikacji, brama VPN, panel administracyjny, serwer pocztowy.

Watchdog w WebDisk Cloud

Nasza chmura działa na platformie Apache CloudStack, a kondycją fizycznych serwerów i warstwy wirtualizacji zajmujemy się my – awarie po stronie infrastruktury to nasza odpowiedzialność. Pozostaje jednak dokładnie ta luka, od której zaczęliśmy: maszyna zawieszona wewnętrznie może z zewnątrz wyglądać na poprawnie działającą – a żaden mechanizm po stronie dostawcy nie powinien wtedy zgadywać za Ciebie, czy twardy reset akurat teraz jest bezpieczny.

Dlatego podział ról jest prosty:

Maszyny w WebDisk Cloud uruchamiają się z dostępnym urządzeniem /dev/watchdog – nie musisz niczego zgłaszać ani zmieniać w konfiguracji usługi.
Mechanizm nie jest włączony domyślnie w naszych wzorcach systemów. Skoro reakcją jest reset, decyzja o uzbrojeniu – i dobór testów kondycji do Twojej aplikacji – należą do Ciebie.
Włączenie odbywa się w całości wewnątrz maszyny, dokładnie tak, jak w instrukcji powyżej – bez ingerencji w hypervisor i bez udziału naszego zespołu.

Jeśli przenosisz się do nas ze środowiska VMware, gdzie pokrewną rolę pełni monitorowanie maszyn oparte na sygnale narzędzi gościa, koncepcja będzie znajoma – a o samej przeprowadzce piszemy w artykule o migracji z VMware do WebDisk Cloud.

Częste pytania

Czym różni się watchdog wewnątrz VM od HA hypervisora? HA hypervisora patrzy na maszynę z zewnątrz: pilnuje fizycznego hosta i procesu VM, więc nie widzi zwisu wewnątrz działającego systemu. Watchdog działa odwrotnie – nadzoruje wnętrze systemu gościa i przy braku meldunków doprowadza do twardego resetu maszyny wykonanego przez hypervisor. To mechanizmy komplementarne: dopiero razem obejmują awarie od padu fizycznego serwera po zawieszone jądro.

Czy watchdog zastępuje monitoring – wykresy, alerty, powiadomienia? Nie, uzupełnia go. Monitoring mówi, co i dlaczego się dzieje, oraz budzi człowieka; watchdog jedynie przywraca maszynę do życia, gdy nikt nie patrzy. Dojrzała konfiguracja ma jedno i drugie: watchdog skraca przestój, monitoring pozwala usunąć przyczynę.

Aplikacja się zawiesiła, ale system działa. Czy watchdog to wykryje? Sam z siebie nie – bez testów kondycji reaguje dopiero na brak odpowiedzi systemu. Pierwszą linią obrony dla pojedynczej usługi jest restart samego procesu (np. Restart=on-failure w systemd). Test z plikiem PID albo własnym skryptem może być drugą linią, ale pamiętaj: jego skutkiem jest reset całej maszyny – to najgrubsze dostępne narzędzie i tak należy je traktować.

Czy twardy reset może uszkodzić dane? Współczesne systemy plików z księgowaniem i bazy danych z odtwarzaniem po awarii znoszą go z reguły bez szkody – kosztem utraty danych, które nie zdążyły trafić na dysk. Ryzyko jest realne dla aplikacji piszących bez zabezpieczeń transakcyjnych. Wniosek jest zawsze ten sam: reset nie zwalnia z posiadania przetestowanych kopii zapasowych.

W mojej maszynie nie ma /dev/watchdog. Co teraz? Poza WebDisk Cloud – zapytaj dostawcę, czy wystawia wirtualne urządzenie watchdog. Alternatywą jest softdog, moduł jądra emulujący watchdoga czysto programowo (sudo modprobe softdog). Uczciwie: softdog działa w tym samym jądrze, które ma nadzorować, więc przy pełnym zakleszczeniu jądra może zawieść razem z nim – urządzenie wystawione przez hypervisor daje mocniejszą gwarancję.

Jak przetestować, czy watchdog naprawdę działa? Na maszynie testowej albo w uzgodnionym oknie serwisowym wymuś crash jądra poleceniem echo c | sudo tee /proc/sysrq-trigger – system natychmiast przestaje odpowiadać. Jeśli watchdog jest sprawny, po upływie limitu hypervisor twardo zresetuje VM; po powrocie systemu potwierdzisz to świeżym uptime i wpisami z poprzedniego uruchomienia w journalctl -b -1. Maszyna wisząca w nieskończoność oznacza najczęściej, że demon nie działał albo nie otwierał właściwego urządzenia.

Czy to działa tylko w Linuksie? Przykłady w tym artykule dotyczą Linuksa – to najlepiej udokumentowana i najprostsza droga. W innych systemach potrzebny jest sterownik wirtualnego urządzenia watchdog i odpowiednik demona; przed wdrożeniem sprawdź w dokumentacji, czy Twój system obsługuje takie urządzenie.

Podsumowanie

Watchdog należy do mechanizmów z gatunku „prosty, więc skuteczny”: licznik odliczany poza systemem gościa zamienia najgorszy rodzaj awarii – cichą, niewidzialną z zewnątrz – w zwykły, krótki restart. Trzy rzeczy warto zapamiętać: HA hypervisora i watchdog patrzą na maszynę z dwóch różnych stron i dopiero razem domykają obraz; reakcją watchdoga jest twardy reset, więc uzbraja się go świadomie i po teście; w WebDisk Cloud urządzenie /dev/watchdog czeka w Twojej maszynie – uzbrojenie go to Twoja decyzja i kwadrans pracy. A jeśli dopiero rozglądasz się za środowiskiem dla swoich maszyn, sprawdź, czym jest chmura publiczna w rozsądnej cenie.

Nie masz pewności, czy watchdog pasuje do Twojego obciążenia? Napisz do nas – zespół wsparcia WebDisk pomoże ocenić, czy to rozwiązanie pasuje do Twojego scenariusza.