SUSEs Server-Zukunft ALP: Enterprise Linux radikal neu gedacht

Inhaltsverzeichnis

Unter dem Projektnamen Les Droites – Die Rechten als Bezug zum kleinsten Viertausender der Alpen – hat SUSE den ersten Prototypen seiner Adaptable Linux Platform (ALP) veröffentlicht. Der Projektverantwortliche German M. Ybenes geht im SUSE-Blog auf einige technische Details des Rumpf-Linux ein und erklärt, wie die unmittelbare Zukunft von ALP aussieht.

Für SUSE geht es bei ALP um einiges – denn das Produkt soll der künftige Kern von SUSE Linux Enterprise werden, also jener Distribution, mit der SUSE bis heute einen großen Teil seines Geldes verdient. Einige technische Details stechen aus der ALP-Vorstellung deshalb heraus: Erstmals wird zu einem SLE-Grundsystem etwa eine Automatisierungssoftware gehören, die ab Werk installiert wird. SUSE hat sich für Salt entschieden, auf Wunsch steht aber auch Ansible als Alternative zur Verfügung. Das klare Ziel von ALP ist es dabei, eine Zero-Touch-Distribution zu sein. Das Einloggen auf den Systemen und das Ausführen händischer Befehle möchte SUSE also überflüssig machen; stattdessen sollen sämtliche Änderungen aus CI/CD-Pipelines sowie eben der konfigurierten Automation kommen. Hierfür definiert SUSE verschiedene Self-Management-Level, aus denen der Administrator später wählen können soll. So wird es möglich sein, automatische Updates von einzelnen Systemkomponenten zu aktivieren oder zu deaktivieren, im Voraus nur herunterzuladen oder nach Kategorien zu erlauben oder zu verbieten.

Verschlanktes System

Wer ALP ausprobieren möchte, benötigt dazu mindestens einen Server, der den Anforderungen der Architekturdefinition x86_64-v2 entspricht. Die meisten aktuellen Server dürften dafür infrage kommen. Bereits während der ALP-Installation fallen erhebliche Unterschiede zum etablierten SLE auf: Auf Wunsch verschlüsselt ALP beispielsweise sämtliche Datenträger des Systems (Full Disk Encryption – FDE). SUSE weist aber ausdrücklich darauf hin, dass FDE aktuell noch aktiv weiterentwickelt wird und sich noch stark verändern kann.

Ferner übt die Adaptable Linux Platform sich vor allem in Reduktion und Verschlankung. Im Kern besteht das System ausschließlich aus einem Linux-Kernel, den absolut notwendigsten Systemwerkzeugen sowie einer Laufzeitumgebung für Container. Dem Administrator obliegt dabei die Entscheidung, ob er Podman oder K3s nutzen möchte. Komplementär soll es im fertigen ALP auch möglich sein, KVM mit Qemu für die Voll- oder Paravirtualisierung virtueller Instanzen zu nutzen. Das Gros der anderen Software, die Administratoren von SUSE gewohnt sind und mögen, ist hingegen nicht mehr Bestandteil von ALP. Das erfasst sogar das altehrwürdige YaST, das in ALP streng genommen nicht mehr zum Systemkern gehört. Beiliegen wird es der Distribution dennoch, allerdings in Form eines Containers. Aus Anbietersicht bietet das immense Vorteile, etwa jenen, dass YaST sich jederzeit unabhängig von allen anderen Bestandteilen des Systems aktualisieren oder reparieren lässt.

Late to the Party

Die Idee, die eigene Enterprise-Distribution zu einem Linux-Kernel mit Container-Laufzeit zu degradieren, ist dabei keineswegs neu – ganz im Gegenteil: Red Hat hat einen ähnlichen Wandel in RHEL 9 zumindest bereits begonnen und bei Canonical erzwingt man seit Jahren die sukzessive Migration hin zu Snap, im Kern ebenfalls ein Container-Format. Für die Distributoren ergibt das Vorgehen auf mehreren Ebenen Sinn: Einerseits ist es leichter, ein leichtfüßiges Rumpfsystem zu entwickeln und zu warten und benötigte Zusatzsoftware in Form von separaten Containern auszuliefern. Das gilt umso mehr, weil diese innerhalb des Unternehmens auch von eigenständigen Teams und unabhängig vom Release-Zyklus der Kerndistribution entwickelt werden können. Ein neues ALP-Release muss künftig etwa nicht mehr automatisch mit einem neuen YaST-Release einhergehen.

Darüber hinaus bietet das Vorgehen eine bequeme Methode für Distributoren, sich eine ganze Menge an Aufwand bei der Wartung ihrer Systeme vom Hals zu schaffen. Bei klassischen Enterprise-Distributionen ist es bekanntlich so, dass Administratoren vom Anbieter erwarten, sämtliche relevante Software samt und sonders in Paketform beizulegen. Seit Dekaden pflegen SUSE, Red Hat & Co. deshalb Apache, MySQL/MariaDB, PostgreSQL und Tausende andere Anwendungen in unterschiedlichen Versionen und Varianten für ihre (noch) unterstützten Enterprise-Systeme. Der Container-Ansatz macht diesem Treiben den Garaus, weil derselbe Container etwa für MariaDB oder MySQL sich auf sämtlichen Systemen betreiben lässt, die eine passende Laufzeitumgebung für Container im Gepäck haben. Absehbar ist bereits, dass die Linux-Distributoren von den jeweiligen Herstellern der Programme fordern werden, entsprechende Container in aktuellster Version bereitzuhalten, sodass ihnen selbst überhaupt keine Aufwände mehr entstehen. Genau darin besteht eine der Hauptmotivationen, Distributionen wie ALP zu entwickeln.

Self-Healing und Lifecycle Management

Auch für Administratoren soll sich das Konzept den Versprechen der Anbieter nach aber freilich auszahlen. Erstmals stellt SUSE im Prototypen der Adaptable Linux Platform deshalb auch Self-Healing-Features vor. Geht beim Update eines Containers etwas schief, revidiert ein ALP-System demnach die durchgeführten Änderungen und springt zum letzten bekannten Zustand zurück, der zuverlässig funktioniert hat. Der Zero-Touch-Ansatz, der Administratoren beinahe schon zur Automation nötigt, erlaubt außerdem implizit schnelle Restore-Operationen: Geht mal etwas fundamental schief, lässt ein ALP-System sich direkt per Lifecycle-Management schnell wiederherstellen – das gilt umso mehr, wenn es Network-Attached Storage (NAS) oder Software-Defined Storage in Form virtuellen Blockspeichers nutzt.

Wer ALP ausprobieren möchte, findet Qcow2-Abbilder für den Betrieb in Qemu mit KVM unter. Allerdings handelt es sich bei diesem ersten Release ausschließlich um eine Testversion, die nicht für den produktiven Einsatz gedacht ist. SUSE hatte die Arbeit an ALP im April 2022 angekündigt.

(fo)