ZFS-Boot-Umgebungen mit beadm verwalten und ein fehlgeschlagenes Update zurückrollen

Ziel

ZFS-Boot-Umgebungen (Boot Environments, BEs) unter Oracle Solaris 11.4 auflisten, erstellen, aktivieren und löschen und damit einen Host wiederherstellen, nachdem ein pkg update schiefgegangen ist.

Voraussetzungen

Die Rolle root oder ein zugewiesenes Profil mit Rechten zur Verwaltung von Boot-Umgebungen; ausserdem ein ZFS-Root-Pool. BEs setzen ihn voraus, und unter 11.4 ist er das Standard-Layout und das einzige unterstützte Root-Layout.

Schritte

1. Vorhandene BEs auflisten: beadm list zeigt alle Boot-Umgebungen, die aktuell aktive, die beim nächsten Boot aktive sowie den jeweiligen Speicherverbrauch.
2. Vor einer riskanten manuellen Änderung eine BE von Hand erstellen: beadm create <new-be-name> klont die aktuell laufende BE, ohne das laufende System zu verändern. Dabei sind zwei Snapshot-Formen zu unterscheiden: beadm create <be-name>@<snapshot> legt nur einen Snapshot einer bestehenden BE an, während beadm create -e <be-name>@<snapshot> <new-be-name> aus einem solchen Snapshot eine neue BE erzeugt.
3. pkg eine BE automatisch erstellen lassen: Wie im IPS-Artikel dieser Reihe beschrieben, erstellt und aktiviert pkg update eine neue BE, wenn das Update Pakete betrifft, die einen Neustart erfordern (das gilt für jedes SRU-Update). Gesteuert wird dies über die Eigenschaft be-policy des Images. Operationen ohne Neustart ändern die laufende BE, höchstens mit einer Backup-BE.
4. Eine BE aktivieren, damit sie beim nächsten Mal bootet: beadm activate <be-name>. Dadurch wird der Host nicht neu gestartet; die aktuell laufende BE läuft bis zum nächsten Neustart weiter.
5. Neu starten, um tatsächlich in die neu aktivierte BE zu wechseln, und mit beadm list prüfen, dass sie nun die aktuell aktive ist.
6. Wenn die neue BE defekt ist, aber noch bootet: beadm activate <previous-be-name> ausführen und erneut neu starten. Bootet sie gar nicht mehr, lässt sich beadm darin nicht ausführen. Stattdessen beim Booten die vorherige BE auswählen, auf x86 im GRUB-Menü, auf SPARC mit boot -L am ok-Prompt. Nach dem Start dann beadm activate <previous-be-name> ausführen, damit spätere Neustarts nicht wieder in der defekten BE landen.
7. Aufräumen, sobald das Ergebnis als zuverlässig gilt: beadm destroy <be-name> entfernt eine nicht mehr benötigte Boot-Umgebung samt allen ihren Snapshots. Es fragt zur Bestätigung nach (-F überspringt die Abfrage) und kann die laufende BE nicht entfernen.

Erwartetes Ergebnis

Nach beadm activate und einem Neustart zeigt beadm list die Ziel-BE als aktiv, und der Host läuft mit der Software, die diese BE enthält. Eine gelöschte BE erscheint nicht mehr in der Liste, und ihr Speicherplatz wird freigegeben.

Grenzen und Prüfbasis

Das Aktivieren einer früheren BE mit anschliessendem Neustart ist der unterstützte Rollback für ein fehlgeschlagenes pkg update; Pakete müssen nicht manuell neu installiert werden. Mindestens die vorherige BE sollte aufbewahrt werden, bis die neue im Produktivbetrieb verifiziert ist; beadm destroy lässt sich nicht rückgängig machen, ausser durch Wiederherstellung aus einem Backup des Pools. Da sich die BEs den Root-Pool teilen, lässt sich durch das Löschen alter BEs auch Platz schaffen, wenn pkg update wegen Platzmangel abgelehnt wird. Ein Rollback setzt nur die eigenen Datasets der BE zurück (Root-Dateisystem und /var); gemeinsam genutzte Datasets wie /export/home oder /var/share werden nicht zurückgerollt, sodass dort nach dem Update geschriebene Daten erhalten bleiben. Dies gilt für Oracle Solaris 11.4; illumos-basierte Systeme mit ZFS-Boot-Umgebungen folgen demselben Muster aus Aktivieren, Neustart und Rollback, wobei sich Tool-Namen und Optionen unterscheiden können.