Watchdog – eigenständige Überwachung des VM-Zustands in der Cloud: von /dev/watchdog bis zum Reset-Test

WebDisk Blog · Kategorie: Cloud-Computing · Lesezeit: ~9 Minuten

Kurz gefasst:- Das Cloud-Panel kann „Running“ anzeigen, obwohl das System innerhalb der VM seit einer Viertelstunde nicht reagiert – die HA-Mechanismen des Hypervisors sehen die Maschine von außen, nicht ihr Inneres.- Watchdog ist ein Zähler, der außerhalb des Gastsystems abläuft: Hört das System auf, ihn regelmäßig „zurückzustellen“, führt der Hypervisor einen harten Reset der VM durch – selbst wenn der Kernel vollständig eingefroren ist.- Die Reaktion ist ein Reset, keine Reparatur – deshalb ist in WebDisk Cloud das Gerät /dev/watchdog in den Maschinen verfügbar, aber wir aktivieren den Mechanismus nicht für Sie; im Artikel zeigen wir, wie Sie das bewusst tun. >Sie arbeiten nicht mit dem Terminal? Überspringen Sie die Befehlsblöcke – die Beschreibung des Mechanismus, die Vergleichsübersicht und der Abschnitt zu den Grenzen der Lösung lassen sich auch ohne sie lesen.

Es ist 3:00 Uhr nachts. Das Infrastruktur-Monitoring leuchtet grün, das Cloud-Panel zeigt bei Ihrer Maschine den Status „Running“ – und die Kunden können seit zwanzig Minuten die Anwendung nicht öffnen. Das Betriebssystem innerhalb der VM hat sich endgültig aufgehängt: Der Kernel plant keine Prozesse mehr, die Konsole reagiert nicht, von SSH keine Spur. Aus Sicht der Infrastruktur ist nichts passiert, denn der Prozess der virtuellen Maschine auf dem physischen Server läuft einwandfrei. Der Ausfall ist genau dort unsichtbar, wo die Automatismen hinschauen.

Für dieses Szenario gibt es einen Mechanismus, der älter ist als die Cloud: den Watchdog – wörtlich „Wachhund“, ein Zeitzähler, den man regelmäßig zurückstellen muss, weil er sonst zubeißt. In diesem Artikel erklären wir, worin sich ein innerhalb der Maschine laufender Watchdog von der Hochverfügbarkeit (HA) auf Hypervisor-Ebene unterscheidet, zeigen die Funktionsweise des Geräts /dev/watchdog, beschreiben Schritt für Schritt, wie Sie den Watchdog unter Ubuntu aktivieren und testen – und sagen ehrlich, wann Sie ihn besser nicht aktivieren. Der Text ist für alle nützlich, die virtuelle Maschinen in der Cloud betreiben – in WebDisk Cloud und nicht nur dort.

Warum zeigt das Cloud-Panel „Running“, obwohl die VM nicht funktioniert?

Klassische Hochverfügbarkeitsmechanismen in der Cloud arbeiten auf Infrastrukturebene. Der Hypervisor (die Software, die virtuelle Maschinen auf dem physischen Server ausführt) und die Verwaltungsschicht achten auf zwei Dinge: ob der Host lebt und ob der VM-Prozess lebt. Fällt der physische Server aus, starten die Maschinen auf einem anderen; verschwindet der VM-Prozess unerwartet, wird er neu gestartet. Das ist ein wichtiges Sicherheitsnetz, aber es betrachtet die Maschine ausschließlich von außen.

Dabei spielt sich ein erheblicher Teil realer Ausfälle im Inneren des Gastsystems ab: ein Kernel-Lockup, ein hängender init/systemd-Prozess, erschöpfter Speicher, nach dem sich das System zwischen dem Beenden von Prozessen und dem Swapping aufreibt, ein Treiberfehler. Die Maschine „läuft“ – antwortet manchmal sogar auf Ping –, erbringt aber keinen Dienst, und anmelden kann man sich auch nicht mehr. Für die HA-Mechanismen des Hypervisors ist dieser Zustand von einem gesunden nicht zu unterscheiden: Der VM-Prozess existiert, aus ihrer Sicht gibt es also nichts zu retten.

Genau diese Lücke schließt ein Watchdog, der in der Maschine selbst läuft.

Wie funktionieren der Watchdog und /dev/watchdog?

Das Funktionsprinzip ist bewusst primitiv – und genau darin liegt seine Stärke. Ein Watchdog ist ein abwärts zählender Zähler, der außerhalb der Kontrolle des überwachten Systems platziert ist. Das System muss ihn zyklisch zurückstellen; hört es damit auf, läuft der Zähler ab und löst eine vorab festgelegte Reaktion aus. In physischen Servern übernimmt diese Rolle ein Baustein auf dem Mainboard; in einer virtuellen Maschine – das virtuelle Watchdog-Gerät, das der Hypervisor dem Gast bereitstellt. Unter Linux erscheint es als Gerätedatei /dev/watchdog. Nach dem Öffnen wird der Zähler scharfgestellt: Von diesem Moment an muss jemand regelmäßig hineinschreiben.

In der Praxis erledigt das der Daemon watchdog: Er öffnet das Gerät und „meldet sich“ alle paar bis etwa fünfzehn Sekunden. Solange das System läuft, fließen die Meldungen. Friert der Kernel ein, bekommt der Daemon keine Prozessorzeit, der Zähler läuft auf null, und der Hypervisor führt die konfigurierte Aktion aus – einen harten Reset der Maschine. Entscheidend ist: Die Vollstreckung erfolgt außerhalb des Gastsystems – der eingefrorene Kernel kann sie nicht aufhalten, denn der Zähler tickt nicht in diesem Kernel, sondern eine Etage tiefer.

Der Daemon kann dabei mehr, als nur „ich lebe“ zu melden. Die Konfigurationsdatei erlaubt zusätzliche Zustandstests: die maximale Systemlast, das Vorhandensein eines Prozesses mit der angegebenen PID-Datei, die Frische einer Datei (wächst das Log noch?), die Ping-Antwort eines angegebenen Hosts und schließlich eigene Testskripte. Schlägt einer der Tests dauerhaft fehl, hört der Daemon absichtlich auf, den Zähler zurückzustellen, und führt den Reset herbei – obwohl der Kernel formal läuft. Dadurch reagiert er auch auf „weiche“ Hänger, nicht nur auf den klinischen Tod des Systems.

Worin unterscheidet sich der Watchdog von der HA des Hypervisors?

Was beobachtet wird – HA auf Hypervisor-Ebene: physischer Host und VM-Prozess · Watchdog innerhalb der VM: das Innere des Gastsystems
Erkennt – HA auf Hypervisor-Ebene: Ausfall des Hosts, Verschwinden des VM-Prozesses · Watchdog innerhalb der VM: eingefrorenen Kernel, ausbleibende Systemantwort, nicht bestandene Zustandstests
Erkennt nicht – HA auf Hypervisor-Ebene: Hänger innerhalb eines laufenden VM-Prozesses · Watchdog innerhalb der VM: Ausfall des Hosts (das ist nicht seine Rolle)
Reaktion – HA auf Hypervisor-Ebene: Neustart der VM, z. B. auf einem anderen Host · Watchdog innerhalb der VM: harter Reset der VM
Wer aktiviert und konfiguriert – HA auf Hypervisor-Ebene: der Cloud-Anbieter · Watchdog innerhalb der VM: der Nutzer, innerhalb der eigenen Maschine

Diese beiden Mechanismen konkurrieren nicht miteinander – sie betrachten dieselbe Maschine von zwei entgegengesetzten Seiten und vervollständigen erst gemeinsam das Bild eines Ausfalls: vom Absturz des physischen Servers bis zum eingefrorenen Kernel. Wichtig in einer geteilten Umgebung: Die Konfiguration des Watchdogs erfolgt vollständig innerhalb der VM, ohne Änderungen auf Hypervisor-Seite – der Cloud-Nutzer kann die Widerstandsfähigkeit seines Systems also selbst erhöhen, ohne die Trennung der Verantwortlichkeiten zwischen ihm und dem Anbieter anzutasten.

Wie aktivieren Sie den Watchdog unter Ubuntu Schritt für Schritt?

Das Beispiel bezieht sich auf Ubuntu Server (z. B. 22.04 oder 24.04); in anderen Linux-Distributionen unterscheiden sich höchstens die Paketnamen.

1. Prüfen Sie, ob die Maschine das Gerät sieht:

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

Fehlt die Datei, hat der Hypervisor der Maschine kein virtuelles Watchdog-Gerät bereitgestellt (was in dieser Situation zu tun ist – siehe FAQ; in WebDisk Cloud ist das Gerät verfügbar).

2. Installieren Sie den Daemon:

sudo apt update
sudo apt install watchdog

3. Konfigurieren Sie die Datei /etc/watchdog.conf:

sudo nano /etc/watchdog.conf

Eine minimale, vernünftige Startkonfiguration:

# Gerät und Meldetakt
watchdog-device = /dev/watchdog
interval = 10 # der Daemon meldet sich alle 10 s; das muss
# deutlich unter dem Zeitlimit des Geräts liegen

# optionale Zustandstests – bewusst einkommentieren:
#max-load-1 = 24 # Reset bei 1-Min.-Load > 24
#pidfile = /run/mysqld/mysqld.pid # einen konkreten Prozess überwachen
#file = /var/log/syslog # die angegebene Datei muss sich ändern…
#change = 1800 # …mindestens alle 1800 s

4. Aktivieren Sie den Dienst und beobachten Sie:

sudo systemctl enable --now watchdog
systemctl status watchdog
journalctl -u watchdog -f # Meldungen und Testergebnisse live

Von diesem Moment an steht die Maschine unter Aufsicht. Zwei organisatorische Hinweise: Ein geplantes Stoppen des Dienstes (systemctl stop watchdog) schließt das Gerät „sauber“ und entschärft den Zähler, endet in der Standardkonfiguration also nicht mit einem Reset; Zustandstests fügen Sie einzeln hinzu und beobachten die Logs nach jeder Änderung – warum das wichtig ist, dazu gleich mehr in der Bilanz.

Testen Sie, bevor Sie vertrauen

Warnung. Der folgende Test setzt die Maschine hart zurück – genau so, wie es der Watchdog bei einem echten Ausfall täte. Führen Sie ihn ausschließlich auf einer Testmaschine oder in einem abgestimmten Wartungsfenster aus; alle ungespeicherten Daten gehen verloren.

Ein Watchdog, der nie überprüft wurde, ist nur ein Eintrag in der Konfiguration. Der glaubwürdigste Test simuliert genau das Szenario, vor dem der Mechanismus schützen soll – das sofortige Einfrieren des Kernels:

# erzwingt einen Kernel-Crash – das System reagiert sofort nicht mehr
echo c | sudo tee /proc/sysrq-trigger

Die Maschine erstarrt: Die SSH-Sitzung bricht ab, die Konsole reagiert nicht. Der Daemon meldet sich nicht mehr beim Gerät, der Zähler läuft auf null, und der Hypervisor setzt die VM zurück. Prüfen Sie nach der Rückkehr des Systems den Ablauf des Ereignisses:

uptime # frische Laufzeit = der Reset hat funktioniert
journalctl -b -1 -e # letzte Einträge aus dem vorherigen Systemstart

Hängt die Maschine endlos, statt sich nach Ablauf des Limits zurückzusetzen – kehren Sie zum vorherigen Abschnitt zurück: Meist stellt sich heraus, dass der Daemon nicht lief oder nicht das richtige Gerät geöffnet hat.

Wann sollten Sie den Watchdog nicht aktivieren, und welche Grenzen hat er?

Nennen wir die Dinge beim Namen: Der Watchdog diagnostiziert nichts und repariert nichts. Seine einzige Reaktion ist ein harter Reset – das Äquivalent zum Ziehen des Steckers aus der Steckdose:

Ein Reset unterbricht alles, auch laufende Operationen. Dateisysteme mit Journaling (ext4, XFS) und Datenbanken mit Crash-Recovery-Mechanismen sind so konzipiert, dass sie einen solchen Neustart überstehen; Daten, die es nicht mehr auf die Festplatte geschafft haben, gehen jedoch verloren. Der Watchdog ersetzt in keinem Fall Backups – mehr dazu im Artikel Backup in der Cloud – das Fundament der IT-Sicherheit.
Ein Reset maskiert die Ursache. Eine Maschine, die alle paar Tage „von selbst“ neu startet, sieht in den Verfügbarkeitsstatistiken gesund aus, obwohl sie krank ist. Der Watchdog sollte Hand in Hand mit Monitoring und Log-Analyse gehen – ein Reset ist ein Pflaster, keine Heilung.
Sie verlieren Beweismaterial. Eine eingefrorene Maschine ist auch ein Standbild des Ausfalls; ein Reset löscht es. Wenn Sie einen schwer reproduzierbaren Hänger diagnostizieren wollen, kann der Watchdog zum Feind der Ermittlung werden.
Zustandstests können falsch positiv ausschlagen. Eine Regel wie max-load-1 kann auf einer Maschine, die planmäßig etwas Schweres berechnet, das System mitten in korrekt ausgeführter Arbeit zurücksetzen. Deshalb wählt man die Schwellenwerte passend zum Charakter der Last und aktiviert neue Tests einzeln, mit einer Beobachtungsphase.

Wann den Watchdog nicht aktivieren? Wenn die Maschine lange Batch-Aufgaben ohne Checkpoints ausführt; wenn Sie einen wiederkehrenden Hänger analysieren und eine „lebende“ Maschine für die Diagnose brauchen; wenn der Dienst ohnehin hinter einem Load Balancer steht, der kranke Instanzen selbst abschaltet. Am meisten bringt der Watchdog auf eigenständigen Maschinen, die niemand dupliziert: ein einzelner Applikationsserver, ein VPN-Gateway, ein Admin-Panel, ein Mailserver.

Der Watchdog in WebDisk Cloud

Unsere Cloud läuft auf der Plattform Apache CloudStack, und um den Zustand der physischen Server und der Virtualisierungsschicht kümmern wir uns – Ausfälle auf Infrastrukturseite sind unsere Verantwortung. Es bleibt jedoch genau die Lücke, mit der wir begonnen haben: Eine intern eingefrorene Maschine kann von außen wie eine korrekt funktionierende aussehen – und kein Mechanismus auf Anbieterseite sollte dann für Sie raten, ob ein harter Reset gerade jetzt sicher ist.

Deshalb ist die Rollenverteilung einfach:

Maschinen in WebDisk Cloud starten mit verfügbarem Gerät /dev/watchdog – Sie müssen nichts melden und nichts an der Konfiguration des Dienstes ändern.
Der Mechanismus ist standardmäßig nicht aktiviert in unseren System-Templates. Da die Reaktion ein Reset ist, liegen die Entscheidung über das Scharfstellen – und die Wahl der Zustandstests für Ihre Anwendung – bei Ihnen.
Die Aktivierung erfolgt vollständig innerhalb der Maschine, genau wie in der Anleitung oben – ohne Eingriff in den Hypervisor und ohne Beteiligung unseres Teams.

Wenn Sie aus einer VMware-Umgebung zu uns wechseln, in der eine verwandte Rolle das auf dem Signal der Gast-Tools basierende Maschinen-Monitoring übernimmt, wird Ihnen das Konzept vertraut sein – über den Umzug selbst schreiben wir im Artikel über die Migration von VMware zu WebDisk Cloud.

Häufige Fragen

Worin unterscheidet sich der Watchdog innerhalb der VM von der HA des Hypervisors? Die HA des Hypervisors betrachtet die Maschine von außen: Sie überwacht den physischen Host und den VM-Prozess und sieht daher keinen Hänger innerhalb eines laufenden Systems. Der Watchdog arbeitet umgekehrt – er überwacht das Innere des Gastsystems und führt beim Ausbleiben der Meldungen zu einem harten Reset der Maschine durch den Hypervisor. Das sind komplementäre Mechanismen: Erst gemeinsam decken sie Ausfälle vom Absturz des physischen Servers bis zum eingefrorenen Kernel ab.

Ersetzt der Watchdog das Monitoring – Diagramme, Alerts, Benachrichtigungen? Nein, er ergänzt es. Das Monitoring sagt, was und warum passiert, und weckt einen Menschen; der Watchdog erweckt die Maschine lediglich wieder zum Leben, wenn niemand hinschaut. Eine reife Konfiguration hat beides: Der Watchdog verkürzt die Ausfallzeit, das Monitoring ermöglicht es, die Ursache zu beseitigen.

Die Anwendung hat sich aufgehängt, aber das System läuft. Erkennt der Watchdog das? Von sich aus nicht – ohne Zustandstests reagiert er erst auf das Ausbleiben der Systemantwort. Die erste Verteidigungslinie für einen einzelnen Dienst ist der Neustart des Prozesses selbst (z. B. Restart=on-failure in systemd). Ein Test mit PID-Datei oder eigenem Skript kann die zweite Linie sein, aber denken Sie daran: Seine Folge ist der Reset der gesamten Maschine – das ist das gröbste verfügbare Werkzeug, und so sollte man es auch behandeln.

Kann ein harter Reset Daten beschädigen? Moderne Dateisysteme mit Journaling und Datenbanken mit Crash-Recovery überstehen ihn in der Regel ohne Schaden – um den Preis des Verlusts der Daten, die es nicht mehr auf die Festplatte geschafft haben. Das Risiko ist real für Anwendungen, die ohne transaktionale Absicherung schreiben. Die Schlussfolgerung ist immer dieselbe: Ein Reset entbindet nicht von der Pflicht, getestete Backups zu besitzen.

In meiner Maschine gibt es kein /dev/watchdog. Was nun? Außerhalb von WebDisk Cloud – fragen Sie Ihren Anbieter, ob er ein virtuelles Watchdog-Gerät bereitstellt. Eine Alternative ist softdog, ein Kernel-Modul, das den Watchdog rein softwareseitig emuliert (sudo modprobe softdog). Ehrlicherweise: softdog läuft in demselben Kernel, den er überwachen soll, und kann bei einem vollständigen Kernel-Lockup also zusammen mit ihm versagen – ein vom Hypervisor bereitgestelltes Gerät bietet die stärkere Garantie.

Wie testet man, ob der Watchdog wirklich funktioniert? Erzwingen Sie auf einer Testmaschine oder in einem abgestimmten Wartungsfenster einen Kernel-Crash mit dem Befehl echo c | sudo tee /proc/sysrq-trigger – das System reagiert sofort nicht mehr. Ist der Watchdog funktionsfähig, setzt der Hypervisor die VM nach Ablauf des Limits hart zurück; nach der Rückkehr des Systems bestätigen Sie das mit einem frischen uptime und den Einträgen aus dem vorherigen Systemstart in journalctl -b -1. Eine endlos hängende Maschine bedeutet meist, dass der Daemon nicht lief oder nicht das richtige Gerät geöffnet hat.

Funktioniert das nur unter Linux? Die Beispiele in diesem Artikel beziehen sich auf Linux – das ist der am besten dokumentierte und einfachste Weg. In anderen Systemen sind ein Treiber für das virtuelle Watchdog-Gerät und ein Gegenstück zum Daemon nötig; prüfen Sie vor der Einführung in der Dokumentation, ob Ihr System ein solches Gerät unterstützt.

Zusammenfassung

Der Watchdog gehört zu den Mechanismen der Gattung „einfach, also wirksam“: Ein außerhalb des Gastsystems ablaufender Zähler verwandelt die schlimmste Art von Ausfall – den stillen, von außen unsichtbaren – in einen gewöhnlichen, kurzen Neustart. Drei Dinge sollten Sie sich merken: Die HA des Hypervisors und der Watchdog betrachten die Maschine von zwei verschiedenen Seiten und vervollständigen erst gemeinsam das Bild; die Reaktion des Watchdogs ist ein harter Reset, also stellt man ihn bewusst und nach einem Test scharf; in WebDisk Cloud wartet das Gerät /dev/watchdog in Ihrer Maschine – es scharfzustellen ist Ihre Entscheidung und eine Viertelstunde Arbeit. Und wenn Sie sich gerade erst nach einer Umgebung für Ihre Maschinen umsehen, werfen Sie einen Blick auf die Public Cloud zu einem vernünftigen Preis.

Sie sind nicht sicher, ob der Watchdog zu Ihrer Last passt? Schreiben Sie uns – das WebDisk-Support-Team hilft Ihnen einzuschätzen, ob diese Lösung zu Ihrem Szenario passt.