Genauer Blick aufs Update: Was Ubuntu 20.04 für Server bringt
Seite 2: Subiquity als neuer Installer
Viele Admins sehen heutzutage über Jahre hinweg keinen Installer einer Linux-Distribution mehr. Für den Betrieb von Systemen in der Cloud stehen fertige Abbilder bereit, auf echtem Blech ist die Installation des Betriebssystems oft komplett automatisiert. In Ubuntu 20.04 entgeht einem dann aber der neue Installer Subiquity: Er löst den schon etwas betagten Debian-Installer ab und bietet eine Reihe nützlicher Zusatzfunktionen. Eine besteht darin, sich in eine laufende Installation per SSH einzuloggen. Dass das extrem hilfreich sein kann, weiß jeder, der schon einmal ohne Maus versucht hat, einen Fehler während des Setups zu debuggen.
Wer ZFS ausprobieren möchte, kann die Server-Abbilder von Ubuntu 20.04 für die Installation eines Systems gar nicht benutzen. Denn die Option, ZFS als Dateisystem für das Hauptsystem zu nutzen, fehlt im Subiquity-Installer komplett. Das ist zwar lästig, aber kein Beinbruch, denn letztlich führen sowohl der grafische Ubiquity-Installer als auch Subiquity zu denselben Ubuntu-Systemen. Ein Nachteil entsteht dem Server-Admin durch den grafischen Desktop also nicht.
Der Linux-HA-Stack aus Pacemaker und Corosync gehört nicht gerade zu jenen Komponenten, mit denen sich Admins bevorzugt auseinandersetzen. Das hat zum Teil historische Gründe: Seit Heartbeat 2 mit seiner XML-basierten Ressourcenkonfiguration vor über einem Jahrzehnt den alten Heartbeat 1 ablöste, folgt der HA-Suite der Ruf der Unbenutzbarkeit. Schon die bloße Installation von Pacemaker und die Konfiguration von Corosync als dessen Kommunikationsmechanismus brachten manchen Systemverwalter zur Weißglut. Vor diesem Hintergrund lässt Ubuntu 20.04 aufhorchen: Hier gehört Corosync 3.0 ebenso zum Lieferumfang wie Pacemaker 2.0 – und zusammen liefern die Komponenten einige neue Funktionen.
In Corosync hat Knet – Abkürzung von Kronosnet – den vorherigen Ring-Mechanismus abgelöst, was die Kommunikation der Cluster-Knoten untereinander verbessert. Geringere Latenzen und ein erhöhter Durchsatz bei der Cluster-Kommunikation sind die Resultate. Darüber hinaus haben die Entwickler den Corosync-Code aufgeräumt und viele wenig genutzte Features wie den RDMA-Support entfernt.
Auch Pacemaker 2.0 versteht sich vorrangig als Aufräum-Release, das alte Zöpfe abschneidet. Die zuvor noch unterstützte Kommunikationsschicht von Heartbeat 1 gehört in Version 2.0 endgültig der Vergangenheit an. Dasselbe gilt für Red Hats alten Cluster-Manager CMAN. Und selbst bei der Arbeit mit Ressourcen in der Cluster Information Base (CIB), also der oft verhassten XML-Datei, sorgen die Entwickler für mehr Ordnung: Master-Slave-Ressourcen waren bisher nötig, um solche Ressourcen in Pacemaker abzubilden, die auf vielen Cluster-Knoten laufen konnten, dort aber unterschiedliche Zustände haben. Der Klassiker ist die redundante Speicherlösung DRBD, bei der ein Laufwerk auf einem Host stets den Primary-Status hat und beschreibbar ist, während dieselbe Ressource auf anderen Systemen im Secondary-Modus läuft. An die Stelle der Master-Slave-Ressourcen treten nun die bereits vorhandenen Klon-Ressourcen, die jedoch mit einem promotable-Flag versehen werden.
Die wohl wichtigste Neuerung aus Sicht des Admins betrifft aber die Art, wie Pacemaker und Corosync in Ubuntu 20.04 aufzusetzen sind. Hier übernimmt die Pacemaker Control Shell (pcs) das Kommando. Auf jedem späteren Cluster-Host läuft deren Daemon pcsd, der die Konfiguration aus der Ferne ermöglicht. Mit wenigen Befehlen von einem zentralen Host aus lässt sich in Ubuntu 20.04 dadurch ein Pacemaker-Cluster aus dem Boden stampfen. Das Hantieren mit Konfigurationsdateien ist nicht länger nötig, denn diese legt pcsd automatisch an.
Software per Snap? Nicht so sehr auf Servern…
Auf Desktop-Systemen rührt Canonical kräftig die Werbetrommel für sein neues Paketformat Snap. Das fußt auf Container-Technik und soll es sowohl Canonical als auch Drittanbietern erlauben, Software für Ubuntu 20.04 leicht zu verteilen. Denn jedes Programm bringt alle Abhängigkeiten im fertigen Container mit, lediglich eine funktionale Runtime für letztere ist auf dem jeweiligen System nötig.
Zwar lässt sich das Snap-Paketformat freilich auch ohne grafische Oberfläche nutzen, so recht will darüber aber keine große Freude aufkommen. Während der Installation fragt das System, welche Snaps aus einer Liste vermeintlich beliebter Snaps man installieren möchte – darunter Docker, PostgreSQL oder Prometheus. Von der Umstellung des Haupt-Werkzeugs zur Paketinstallation merkt man in der Server-Variante ohne grafische Oberfläche aber gar nichts. Entscheidet man sich nicht explizit für die Snap-Nutzung, bleiben diese praktisch außen vor und den größten Teil seiner Programme bezieht man weiterhin in Form von .deb-Paketen.
Dies ist vielen Admins aber vermutlich ohnehin lieber. Vielen Nutzern stößt es außerdem durchaus sauer auf, dass Canonical ein eigenes Paketformat erfinden musste, statt sich dem bereits bestehenden Flatpak-Format anzuschließen – das sich auf Ubuntu 20.04 freilich ebenfalls nutzen lässt.
