Linux-Prozesse einfrieren und wiederherstellen mit CRIU

Manche Wartungsarbeiten lassen sich nur dann vornehmen, wenn keine Produktiv-Software mehr läuft. Doch Admins können Prozesse nicht nach Gutdünken beenden, sonst droht Datenverlust; zeitaufwendige Berechnungen müssten von vorne beginnen. Abhilfe schafft auf Linux-Systemen das kleine Werkzeug Checkpoint/Restore In Userspace, kurz CRIU genannt.

CRIU friert den aktuellen Zustand eines Prozesses ein und sichert ihn auf der Festplatte. Später lässt sich der Prozess wieder zum Leben erwecken und arbeitet dann an der Stelle weiter, an der CRIU ihn eingefroren hat. Bei virtuellen Maschinen heißt dieses Konzept Snapshots.

Das Konservieren hilft nicht nur bei Wartungsarbeiten. Angehaltene Prozesse lassen sich auch auf andere Rechner verschieben und laufen dort weiter. Diese Live-Migration hilft beispielsweise beim Loadbalancing: Dreht ein Rechner gerade Däumchen, transferiert man einen Prozess per Skript dorthin. Des Weiteren lassen sich verdächtig agierende Prozesse einfrieren und auf einem anderen System in Ruhe analysieren. Bindet man CRIU in die Startskripte des Systems ein, sichert es Prozesse beim Herunterfahren automatisch und bringt sie beim nächsten Systemstart zurück in den Speicher. Auf diese Weise stellt man nicht nur den Zustand vor dem Ausschalten wieder her, sondern verkürzt auch den Boot-Vorgang.

Nümmerchen

Die erste CRIU-Version erschien vor nicht einmal zwei Jahren. Von der aktuellen Version 1.1 lag bei Redaktionsschluss nur der erste Release Candidate vor; bei Erscheinen dieses ADMIN-Magazins sollte CRIU 1.1 jedoch zur Verfügung stehen. Dennoch basieren die folgenden Ausführungen auf dem Release Candidate. Ältere Versionen sammelt das Release-Archiv unter [2].

CRIU arbeitet zwar vollständig im Userspace, stellt aber mehrere Anforderungen ans laufende System. Zunächst funktioniert das Programm nur auf Systemen mit ARM- oder x86_64-Architektur, in letztem Fall muss auch ein 64-Bit-Linux laufen. Des Weiteren verlangt CRIU einen Linux-Kernel ab Version 3.11. Aktuelle Desktop-Distributionen erfüllen diese Bedingung, die auf Servern beliebten Linux-Varianten Debian 7 und CentOS 6.5 jedoch nicht. Der Einsatz von CRIU auf diesen Systemen setzt deshalb ein Kernel-Upgrade voraus.

Der laufende Kernel muss außerdem die von CRIU verlangten Funktionen bereitstellen. Tabelle 1 führt die beim Kernel-Kompilieren zu aktivierenden Einstellungen auf. Liegt ein fertiger Kernel vor, prüft CRIU dessen Kompatibilität mit »criu check« .

Aufgrund der detaillierten Ansprüche an den Betriebssystemkern stellten die CRIU-Entwickler in der Vergangenheit eigens einen passenden Kernel bereit. Da Linux in Version 3.11 jedoch alle notwendigen Funktionen mitbringt, fällt diese Notwendigkeit weg und der Einsatz alter CRIU-Kernel empfiehlt sich nicht mehr.

Erfüllt der Kernel alle Voraussetzungen, muss zudem Googles Protocol-Buffers-Bibliothek her [3, 4], die in den Repositories der meisten Distributionen bereitsteht. Neben der Bibliothek selbst benötigt man die zugehörigen Entwicklungspakete, die C-Bindings und den Protobuf-C-Compiler. Unter Ubuntu und Debian heißen die entsprechenden Pakete »libprotobuf-c0-dev« und »protobuf-c-compiler« , auf anderen Distributionen ähnlich.

CRIU greift außerdem auf Iproute2 zurück, das mindestens in Version 3.5.0 von August 2012 vorliegen muss. Auch dieses Werkzeug haben die meisten aktuellen Distributionen an Bord. Falls nicht, wie im Fall von Debian 7, gibt es den Quellcode unter [5].

Testlauf

Um CRIU zu übersetzen, benötigt man nach dem Download der Quellen [1] nur noch das Make-Werkzeug und einen C-Compiler. Nach dem Entpacken des Archivs und dem Kompilieren mit »make« ist eine systemweite Installation des Werkzeugs weder vorgesehen noch notwendig.

Bevor man die ersten Prozesse schockfrostet, empfiehlt sich ein CRIU-Test. Dazu initiiert man als Benutzer Root auf der Kommandozeile diesen Befehl:

criu check --ms

Am Ende sollte CRIU die Meldung »Looks good« auswerfen (siehe Abbildung 1). Andernfalls verrät das Werkzeug, welche Funktion fehlt. Ältere Versionen des Tools hießen übrigens noch »crtools« , deshalb beziehen sich manche im Internet kursierende Anleitungen noch auf diesen Befehlsnamen.

Abbildung 1: Meldet CRIU Looks good, bietet der Kernel alle vom Werkzeug benötigten Funktionen.

Der nächste Testschritt folgt im CRIU-Unterverzeichnis »test« . Dort ruft man als Root das Skript »zdtm.sh« auf. Diese Test-Suite startet mehrere Prozesse und friert sie probeweise ein. Ein kompletter Durchlauf benötigt einige Minuten, während derer das System immer wieder einfrieren kann. Bei einem Problem bricht die Test-Suite ab und nennt die Quelle. Nach erfolgreichem Durchlauf erscheint nur das Resultat des letzten Tests (Abbildung 2).

Abbildung 2: Die Test-Suite prüft, ob das System alle Voraussetzungen für den Betrieb von CRIU erfüllt.