Linux-Magazin Clean Linux (Vorschau)

Titelthema
www.linux-magazin.de Kernelupdates 09/2013
42
Techniken für reibungslose Kernel-Updates und -Upgrades
Kern-Kompetenz
Kernelupdates: Fluch oder Segen, Notwendigkeit oder einfach nur ein Ärgernis? Welche Fallstricke gibt es und
wie kann der Systemadministrator Aufwand und Risiko minimieren? Das Linux-Magazin weiß Rat. Udo Seidel
© serezniy, 123RF.com
Der Austausch des Linux-Kernels ist wie
ein Motorwechsel beim Auto. Er lässt sich
nicht zwischen Tür und Angel erledigen
und erfordert Vorbereitung. Dem Eingriff
folgt häufig ein kompletter Reboot des
Servers. Linux-Installationen mit Systemen
von drei-, vier- oder gar fünfstelliger
Anzahl sind keine Seltenheit mehr. Der
operative Aufwand, ein Kernelupgrade
in dieser Größenordnung durchzuführen,
ist entsprechend groß und erfordert
erheblichen Zusatzaufwand für das Gelingen.
Aber sogar im kleinen Rahmen
stellt sich die Frage, welche ungewollten
oder unerwarteten Änderungen der neue
Betriebssystemkern mitbringt.
Touch a running System
Gründe für einen Wechsel des Kernels
gibt es gleich mehrere: Typische Szenarien
sind Bugfixes oder das Stopfen
von Sicherheitslöchern (Update), daneben
aber auch externe Anforderungen,
etwa durch Software, die nicht zum Lieferumfang
der Linux-Distribution zählt
und neuere Kernelfeatures verlangt (Upgrade).
Die manchmal rasante Entwicklung
der Hardware erfordert nicht selten
ebenfalls einen neueren Betriebssystemkern.
Nur in den seltensten Fällen kann
ein Admin das Kernelupgrade aus seinem
Aufgabenkatalog streichen, also sollte er
es richtig machen. Der folgende grobe
Vorgehensplan betrachtet drei Aspekte:
Wie, Wann und Wo.
Kernelupdates lassen sich in zwei Arten
unterteilen: offline und online. Zur
letzteren zählt der Austausch einzelner
Kernelmodule oder sogar ganzer Funktionen,
was das Tool Ksplice ermöglicht.
Einfacher ist aber zunächst die Offline-
Variante zu erklären. Hier wandert der
neue Kernel auf das System und ein Reboot
aktiviert ihn.
Die Fragestellungen lauten dabei: Wie
den neuen Kernel erzeugen? Wie wandert
er auf den Server und wann? Wann
findet der Reboot zur Aktivierung statt
und auf welchen Systemen (wo)? Das
Offline-Verfahren ist technisch die beste
Variante, weil sich das System danach in
einem sauberen und definierten Zustand
befindet. Allerdings bedeutet der Reboot
einen Ausfall der Dienste des neu zu
startenden Servers.
Lassen Dienstleistungsverträge und
Wartungsfenster dies nicht zu, müssen
Alternativen her. Ist ein Dienst wichtig,
sichert man ihn meist ohnehin durch
Hochverfügbarkeits-Setups. Im Fall des
Kernelupdate kann der Admin auf diesen
Mechanismus zurückgreifen. Bis zum
fertigen Kernel-Rollout befindet sich der
HA-Verbund dabei in einem Mischbetrieb:
Systeme, die identische Aufgaben
wahrnehmen, unterscheiden sich in der
Schlüsselkomponente Kernel. Aus mehreren
Gründen empfiehlt es sich, diesen
Zustand möglichst kurz zu halten.
Rückfahrkarte
Das Testen eines neuen Kernels vor dem
Rollout gehört für Sysadmins zum guten
Ton. Neben dem eigentlichen Funktionstest
gehört das Ausprobieren des
Upgrade-Prozesses selbst dazu, ebenso
ein Fallback. Sind Kernelmodule von
Drittherstellern im Spiel, lohnt es sich,
deren Kompatibilitätsmatrix zu prüfen.
Die Theorie kann aber den Praxistest
nicht ersetzen.
Die Eleganz von Linux besteht darin,
dass das System problemlos mehrere Betriebssystemkerne
vorhält (Abbildung 1).
So kann der Admin den Rechner bequem
in den vorherigen Zustand zurückversetzen,
falls nötig. Es empfiehlt sich, Kernelupdates
vom Patchen der sonstigen Systemkomponenten
so weit wie möglich zu
trennen. Zum einen lässt sich der Userspace
online patchen, was den Betrieb
deutlich geringer stört als der Austausch