Reboots nach Kernel-Absturz? Kmorph hat da schon mal was vorbereitet

1. Reboots nach Kernel-Absturz? Kmorph hat da schon mal was vorbereitet
   • Ein laufender Kernel als Reserve
   • Ohne Neustart heißt nicht ohne Dienstunterbrechung
   • Kernelupdates über denselben Mechanismus
   • Fedora-bootc-Prototyp: Absturz und Update

Unter dem Namen Kmorph hat Linux-Entwickler Cong Wang ein praktisches, aber noch experimentelles Werkzeug vorgestellt: Ein bereits gestarteter zweiter Kernel soll nach einem Absturz das System übernehmen, ohne den Rechner neu zu starten. Über denselben Mechanismus lassen sich auch geplante Kernelupdates einspielen.

In seiner Ankündigung gibt Wang rund eine Sekunde von der Fehlererkennung bis zum laufenden Nachfolger an. Ein vorbereiteter Nginx-Dienst habe in Tests binnen zwei Sekunden nach dem Kernelabsturz wieder Anfragen beantwortet. Laut der Projektbeschreibung auf GitHub benötigt Kmorph einen Kernel mit Multikernel-Erweiterungen. Unterstützt werden derzeit x86-64 und ARM64.

Ein laufender Kernel als Reserve

Grundlage sind die Multikernel-Erweiterungen für Linux. Mit ihnen laufen mehrere Linux-Kernel parallel auf derselben Maschine, jeweils mit eigenen CPUs, Speicherbereichen und Geräten. Ein Hypervisor ist dafür nicht nötig. Kmorph startet den Reservekernel vorab auf wenigen, frei konfigurierbaren CPUs und einem Teil des Arbeitsspeichers. Dort überwacht der Daemon kmorphd den bisherigen Kernel über vsock.

Bleiben die Antworten wiederholt aus, beginnt die Übernahme. Zunächst stoppt der Nachfolger die CPUs des bisherigen Kernels und lässt sich bestätigen, dass sie tatsächlich angehalten haben. Dieses Fencing verhindert, dass beide Kernel auf dieselben Ressourcen zugreifen. Kann der Nachfolger eine CPU nicht sicher stoppen, setzt er die Übernahme nicht fort. Anschließend übernimmt er die Geräte, setzt sie soweit möglich zurück und stellt die Netzwerkkonfiguration wieder her. Die übrigen CPUs und den verfügbaren Speicher bindet er per Hotplug ein.

Auf Wunsch sichert Kmorph außerdem einen kdump-kompatiblen vmcore mit dem Speicherinhalt, CPU-Registern und VMCOREINFO des abgestürzten Kernels. Erst nach dem Schreiben des Dumps gibt es den dafür zurückgehaltenen Speicher zur Nutzung frei. Anders als beim üblichen kdump-Ablauf muss dafür weder ein Capture-Kernel nach dem Absturz starten noch anschließend die Maschine erneut ins Produktionssystem booten.

Ohne Neustart heißt nicht ohne Dienstunterbrechung

Die laufenden Prozesse des alten Kernels setzt Kmorph nicht fort. Im Normalfall startet der Userspace nach der Übernahme neu. Um diese Wartezeit für ausgewählte Dienste zu vermeiden, kann Kmorph sie schon im Reservekernel starten. Die Dokumentation zu Standby-Diensten zeigt dafür beispielsweise die Konfiguration standby = nginx.service.

Der Dienst läuft dann bereits, bevor der bisherige Kernel ausfällt. Seine Ports kann er an die vorgesehenen IP-Adressen binden, obwohl der Nachfolger noch keine Netzwerkkarte besitzt. Bei der Übernahme bekommt der Reservekernel die Netzwerkkarte und stellt unter anderem MAC-Adresse, IP-Adressen und Routen wieder her. Danach wechselt er mit pivot_root auf das reguläre Root-Dateisystem. systemd startet die übrigen Dienste; der vorbereitete Nginx-Prozess muss dafür nicht anhalten. Ein vollständig unterbrechungsfreier Betrieb ist laut Wang ein Entwicklungsziel.

Jedoch hat das Verfahren Grenzen: Standby-Dienste müssen zunächst ohne Datenträger und Netzwerkzugriff auskommen. Sie dürfen in dieser Phase keinen Zustand schreiben, der dauerhaft erhalten bleiben muss. Dienste mit eigenen Mount-Namespaces, etwa durch PrivateTmp= oder ProtectSystem=, muss Kmorph nach dem Wechsel neu starten, sofern kein Drop-in ihre Sandbox lockert. Für sie entfällt damit der Vorteil des vorgezogenen Starts.

Kernelupdates über denselben Mechanismus

Mit kmorph upgrade lässt sich die Übernahme auch gezielt auslösen, solange der bisherige Kernel noch funktioniert. Kmorph übermittelt dafür nochmals die aktuelle Netzwerkkonfiguration, synchronisiert die Dateisysteme und friert beschreibbare Dateisysteme auf Blockgeräten ein. Anschließend fordert es den Nachfolger zur Übernahme auf. Dieser kann bereits eine neuere Kernelversion ausführen. Bei einem geplanten Wechsel entsteht kein Crash-Dump.

Der neue Kernel kann anschließend selbst einen weiteren Nachfolger bereitstellen. Die Distributionsintegration nutzt dafür unter anderem dracut oder initramfs-tools, Kernel-Installations-Hooks und einen systemd-Dienst. Der Dienst übernimmt auch das erneute Bereitstellen des Reservekernels nach einem Wechsel.

Kmorph selbst koordiniert diese Abläufe mit zwei C-Programmen. Die Mechanismen für Fencing, Geräte- und IOMMU-Übernahme sowie Ressourcen-Hotplug stecken in den Multikernel-Erweiterungen.

Fedora-bootc-Prototyp: Absturz und Update

Einen zusätzlichen Praxistest hat Clement Verna im Fedora-Projektforum vorgestellt. Seine Integration baut ein Fedora-45-bootc-Image mit Multikernel-Kernel und Kmorph. Das Hilfsprogramm kmorph-bootc bereitet den Nachfolger aus einem bootc-Deployment vor. Terminalaufzeichnungen dokumentieren sowohl die Übernahme nach einem per SysRq ausgelösten Kernel-Absturz als auch den Wechsel auf ein neues Image mit neuer Kernelversion.

Die Testumgebung und Reproduktionsschritte sind ebenfalls frei verfügbar. Verna testete in einer KVM-VM mit zwei vCPUs und 16 GByte RAM auf einer Graviton3-Maschine. SELinux war deaktiviert. In dieser Integration kann der Nachfolger nach der Übernahme bislang keinen weiteren Reservekernel starten, sie erlaubt deshalb nur einen Wechsel pro Boot. Verna bezeichnet den Aufbau ausdrücklich als Proof of Concept und warnt vor einem Einsatz im Produktivbetrieb.

(fo)