© Anna Liebiedieva, 123RF

Ein Betriebssystem für die Cloud, das intern auf Docker setzt und außerdem ab Werk den Bau von Rechenclustern unterstützt, das soll Core OS sein. Ob passend zu dem offensichtlich guten Marketing auch technisch viel Frische dominiert, klärt dieser Test.

Die liebe Cloud müsste eigentlich so einfach sein, doch die Realität sieht leider anders aus. Wer virtuelle Systeme auf Basis von Open Stack, Open Nebula oder anderen Umgebungen betreibt, genießt einerseits die typischen Funktionen von Debian, Ubuntu, Red Hat & Co. Andererseits schlägt er sich damit herum, dass diese Distributionen für den Einsatz in Clouds eigentlich gar nicht gemacht sind. Das äußert sich vor allem in der Wartung von virtuellen Maschinen.

So gibt es im Lifecycle eines virtuellen Systems in einer Cloud gleich eine Vielzahl von Eigenschaften und Ereignissen, die mit klassischen Distributionen nicht besonders gut abzudecken sind. Das fängt beim Software-Umfang an: Ein “nacktes” Image für Ubuntu 14.04 kommt zwar insgesamt nicht mal auf 300 MByte, dafür lässt sich damit aber auch nur wenig anfangen, ohne einen Haufen Zusatzpakete zu installieren. Zusatzsoftware braucht Konfiguration, die einer Cloud-VM über Managementtools wie Puppet oder Chef unterzuschieben ist oder alternativ in Form von Skripten beim Systemstart. Dann aber muss jede VM aufs Neue alle Informationen erhalten. Hinzu kommt, dass die Zahl der laufenden VMs in Clouds üblicherweise stark schwankt, Puppet und Chef aber nicht besonders gut an hohe Fluktuation bei Systemen angepasst sind.

Und was passiert, wenn VMs ausfallen? Die Installation von Pacemaker in den Cloud-VMs wäre mühsam und langwierig, viele Clouds kompensieren ausgefallene VMs nur über den Umweg der Orchestrierung. Wenn diese Funktion fehlt, muss der Admin selbst ran, mit allen unangenehmen Nebenerscheinungen.

Core OS als Hilfe

Die aufgezählten Schwierigkeiten reichen für ausgedehnte Katerstimmung in der Cloud eigentlich aus, doch keine Panik: Core OS tritt an, um mit den Einschränkungen klassischer Linux-Distributionen im Cloudkontext aufzuräumen. Die Distribution des Herstellers Core Os Inc. geistert seit Monaten durch den Blätterwald, im Juli stellten die Entwickler die erste stabile Version vor.

Die Basis: Docker im Mittelpunkt

Konzipiert ist Core OS als minimalistischer Ansatz für ein Cloudbetriebssystem. Cloudnutzer sollen nur die grundlegenden Werkzeuge erhalten, um danach sinnvoll mit der Software arbeiten zu können. Wer sich das von den Entwicklern unter [1] bereitgestellte Open-Stack-Image herunterlädt, bekommt ein 160 MByte großes File (als Alpha-, Beta- und Final-Version sowie als VM auch auf der DELUG-DVD), das allerdings noch mittels Bzip2 komprimiert ist (Abbildungen 1 bis 3). Nach dem Entpacken kommt das Image auf 400 MByte, damit übertrifft es Ubuntus Open-Stack-Image für 14.04 bereits um über 100 MByte. Intuitiv hätte man sich Minimalismus jedenfalls anders vorgestellt.

Abbildung 1: Ein fertiger Verbund aus drei VMs auf Basis von Core OS sieht im Open-Stack-Dashboard so aus.

Abbildung 2: Für Open Stack bietet Core OS fertige Images der Alpha-, Beta- und Stable-Kanäle, die sich problemlos in Glance integrieren lassen.

Abbildung 3: Ein Leichtgewicht ist das Core-OS-Image für Open Stack mit seinen knapp 400 MByte nicht gerade, doch ist hier alles enthalten, was für den Betrieb von VMs notwendig ist.

Doch der erste Anschein trügt: Das Core-OS-Image enthält im Grunde alles, was zum Betrieb von Diensten in einer Cloud notwendig ist. Um die zuvor beschriebenen Probleme von klassischen Distributionen in Clouds zu umgehen, haben sich die Core-OS-Entwickler dabei eine ganze Menge einfallen lassen. Dreh- und Angelpunkt von Core OS ist der Containermanager Docker (Abbildung 4), eine Software, die im Augenblick einen wahren Hype erlebt. Docker ist eine Implementierung von Linux-Containern (LXC), die die Entwickler als “on steroids” bezeichnen, also mit diversen Zusatzfunktionen, die in den ursprünglichen LXC-Versionen fehlen ([2], [3]).

Abbildung 4: Docker an Bord: Core OS bringt ab Werk Docker 1.0.2 mit, sodass sich alle Dienste direkt in Docker-Containern nutzen lassen.

Da findet sich beispielsweise eine eingebaute Containerverwaltung, mit der Admins Anwendungen sehr einfach zwischen mehreren Hosts verschieben können: Ein vom Benutzer einmal angelegter Container lässt sich als einzelne Datei von einem Host auf einen anderen übertragen oder über den Docker-Image-Store anderen Nutzern zur Verfügung stellen. Ein fertiger Docker-Container ist im Grunde autonom: Solange ihm der Computer, auf dem er laufen soll, eine Docker-Umgebung bietet, ist er völlig zufrieden.

Versionskontrolle inklusive

Den Komfort im Umgang mit Docker-Images haben die Entwickler so weit getrieben, dass sich Container de facto mit einer eigenen Versionsverwaltung im Stil von Git & Co. administrieren lassen. Außerdem ist es problemlos möglich, in einen Docker-Container alle Dateien zu packen, die für den Betrieb einer spezifischen Anwendung nützlich sind.

So entsteht etwa eine “fahrende” Apache-Installation: Jeder Host, der mit Docker-Containern klarkommt, kann auch einen Container mit fertiger Apache-Installation starten. Das System ähnelt der Art und Weise, wie Programme auf Mac OS X den Weg zum Nutzer finden; hier erhält der Anwender eine Programm-App, die alle benötigten Laufzeitkomponenten enthält. Im Docker-Beispiel ist das sehr ähnlich, hier bekommt der Nutzer einen sofort lauffähigen Docker-Container.

Für Core OS spielt Docker eine große Rolle, denn das Cloudsystem geht davon aus, dass alle Programm-spezifischen Dateien einer Installation in jenem Container liegen, der zur Applikation gehört. Daraus leitet sich auch der Name her: Das eigentliche Betriebssystem ist tatsächlich nur der Kernel mit einigen wenigen Beigaben, gerade genug, um Docker-Container laufen zu lassen. Alle zum Endkunden exponierten Dienste passieren anschließend einzig in Docker, das Hauptsystem bleibt davon praktisch unberührt.

Unterbau: Chrome OS

Dass Core OS rigoros auf Docker für Applikationen setzt, sorgt im Alltag mit der Distribution für so einige unerwartete Effekte. Unterbau des Systems ist nicht etwa eine der hergebrachten Distributionen, stattdessen haben sich die Core-OS-Entwickler rund um Alex Polvi für Chrome OS als Basis ihres Systems entschieden. Chrome OS ist bekanntlich die extrem zurückgestutzte Linux-Version, die Google den eigenen Chrome-Geräten spendiert und die im Grunde nichts außer einem Webbrowser enthält. Chrome OS bietet beispielsweise auch keinen eigenen Paketmanager nach dem Vorbild von Rpm oder Debians Dpkg, was sich darauf auswirkt, wie Admins Updates für Core OS installieren.

Weil Core OS sowieso nur ein Rahmenwerk ist, um Docker-Container zu nutzen, haben die eigentlichen Core-OS-Systeme nur sehr wenige Parameter, die für sie spezifisch sind. Solange Kernwerte wie Hostname und IP-Adresse den Reboot eines Core-OS-Systems überleben, sind Updates deshalb denkbar leicht: Es genügt, das alte System runterzufahren und ein neues System mit einer anderen und erneuerten Rootdisk zu starten – fertig ist das Update. Wer das mit den Update-Orgien der großen Distributionen vergleicht, mag zunächst skeptisch sein, doch gleicht diese Art der Update-Verwaltung auch der Art, die sich generell für Updates von Cloud-VMs empfiehlt.

Alternativlos

Eine Alternative bietet Core OS so oder so nicht, denn das Hauptdateisystem (»/« ) ist stets im Nur-Lesen-Modus eingehängt, sodass Veränderungen unmöglich sind. Admins, die auf Core OS setzen, müssen sich mit diesem auf den Namen Fastpatch getauften System also so oder so anfreunden. Letztlich fällt das aber auch nicht so schwer, denn die Core-OS-Entwickler bauen sinnvolle Hintertüren ein: Beim typischen Update wird die alte Rootpartition nicht überschrieben, sondern es wird eine zweite angelegt, die das aktualisierte System enthält. Geht beim Update etwas schief, steht dem Admin der Weg zurück also jederzeit offen.

Von Vorteil ist hier auch der kleine Footprint, der Core OS auszeichnet: Ein paar GByte für diverse alte und neue Core-OS-Partitionen dürften sich auf jedem Server freischaufeln lassen, passen doch auf handelsübliche SD-Karten bereits mehrere Installationen.

Wer eine funktionierende Rootpartition für Core OS hat, muss sich für ein Update nicht ein komplettes zweites Image herunterladen, wenn er in einen Supportvertrag investiert und dadurch das Produkt Coreupdate erhält. Dabei handelt es sich um eine Lösung zur Verwaltung von Updates, die auf Googles Omaha-Projekt fußt. Coreupdate ermöglicht de facto die Verwaltung von Updates über alle Knoten des Clusters – kostet aber auch Geld (siehe unten).

Für die Cloudkonfiguration: Etcd und Fleet

Ein minimales Grundsystem und der verstärkte Einsatz von Docker – wirklich bahnbrechend sind diese Features noch nicht. Mini-Distributionen gibt es bekanntlich auch von anderen Herstellern und das Einrichten von Docker-Unterstützung bedeutet heute auch keine unüberwindbare Hürde auf einschlägigen Systemen.

Core OS ist aber deutlich mehr als eine Mini-Distribution, der beste Beweis dafür sind die beiden Komponenten Etcd ([4], Abbildung 5) und Fleet [5]. Bei beiden Programmen handelt es sich um Eigenentwicklungen der Core-OS-Developer, beide Tools lösen spezifische Probleme von Cloud-basierten Systemen.

Abbildung 5: Mittels einer separaten Konfigurationsdatei rufen Core-OS-VMs nach dem Boot den Etcd-Discovery-Dienst an und starten auch Fleet.

Etcd verwaltet /etc

Etcd beispielsweise kümmert sich – nomen est omen – um die Verwaltung der Konfigurationsdateien in »/etc« . Aber der Begriff “Dateien” ist eigentlich in diesem Kontext eher irreführend, speichert Core OS seine Konfigurationen eben nicht mehr in Dateien (Abbildung 6), sondern nutzt Etcd als handlichen Key-Value-Store, aus dem sich kompatible Dienste die jeweiligen Konfigurationswerte einfach selbst heraussuchen.

Abbildung 6: Core OS präsentiert sich dank Etcd in »/etc« erstaunlich aufgeräumt, besonders deshalb, weil in dieser Liste bereits alle benötigten Dateien vorhanden sind.

Die Etcd-Instanzen in verschiedenen VMs, die zueinander gehören, tauschen den gesamten Inhalt des Key-Value-Store von Etcd untereinander aus, sodass alle Instanzen stets die aktuelle Konfiguration haben. Das ganze Schema funktioniert im Wesentlichen wie ein Paxos-Cluster [6], der Vergleich mit dem Gespann aus Corosync und Pacemaker [7] liegt nahe, auch wenn die Programme absolut nichts miteinander zu tun haben.

In Paxos-basierten Clustern gibt es stets einen Koordinator, also einen dynamisch gewählten Knoten, der zuständig für Konfigurationsänderungen ist und diese an alle anderen Knoten verteilt, falls der Admin an den Rädchen des Clusters dreht. Core OS stößt an dieser Stelle auf ein Hindernis: Startet ein Admin viele Core-OS-VMs innerhalb einer Cloud gleichzeitig, dann wissen die darin laufenden Etcd-Instanzen nicht, wie sie miteinander reden können (Abbildung 7).

Abbildung 7: Die Etcd-Tokens des Discovery-Dienstes verraten neuen Clusterknoten lediglich, wie sie mit den schon vorhandenen Maschinen reden können, mehr nicht.

Etcd-Discovery

Abhilfe schafft das Etcd-Projekt durch die Discovery-Funktion: Admins melden ihre Knoten beim Starten entweder unter dem offiziell von Core OS zur Verfügung gestellten Dienst an. Oder sie setzen auf eine eigene Instanz des Etcd-Discovery-Dienstes, der sich problemlos auch lokal betreiben lässt. Direkt nach dem Starten verbindet sich Etcd mit der angegebenen Adresse und findet so heraus, welche anderen Etcd-Instanzen vorhanden sind. Der gesamte Rest der Kommunikation erfolgt dann ausschließlich zwischen den einzelnen Instanzen von Etcd, der Discovery-Dienst schneidet also nicht den gesamten Datenverkehr mit.

Für den Makrokosmos von Core OS ist Etcd also genau die richtige Lösung. Admins von Clustern wissen ohnehin, dass es mühsame Kleinarbeit ist, den Inhalt von »/etc« über mehrere Clusterknoten hinweg synchron zu halten; in noch viel größerem Maße wird ein Problem daraus, wenn Clusterknoten ständig kommen und gehen – wie es bei Core-OS-Clustern aus vielen Instanzen regelmäßig der Fall sein wird. Wer sich Hoffnungen darauf macht, Etcd außerhalb von Core OS zu nutzen, wird jedoch enttäuscht. Viel Unterstützung bei anderen Projekten hat das Werkzeug noch nicht erhalten.

Fleet

Pacemaker kommt in Setups häufig zum Einsatz, um Spezialaufgaben über alle Knoten des Clusters abzuwickeln. Oft genug hat der Dienst nur die Aufgabe, Programme auf einzelnen Nodes zu starten oder zu stoppen. Für eine relativ simple Aufgabe holen sich Admins also mit Pacemaker viel Komplexität ins Setup. Als Gegenpol dazu schrieben die Core-OS-Entwickler eine Erweiterung für Systemd: Fleet.

Fleet soll Systemd um das Bewusstsein für Clusteraufgaben erweitern: Die Fleet-Instanzen auf allen Knoten reden miteinander und führen dann über die lokalen Systemd-Instanzen spezifische Befehle aus. Das ist besonders deshalb praktisch, weil auf diese Weise Pacemaker außen vor bleibt. Fleet soll in Kombination mit Etcd letztlich die zentrale Steuerung eines vollständigen Clusters ermöglichen, zusammen mit Systemd und auf Basis der Informationen aus Etcd konfiguriert Fleet einen aus Core OS bestehenden Cluster so, dass er dem Wunsch des Admin entspricht.

Wie die Core-OS-Entwickler ihre Releases planen, wirkt auf den ersten Blick etwas wirr, doch lassen sich bei genauerem Hinsehen drei Release-Zweige erkennen: Der »alpha« -Zweig, in dem alle aktuellen Entwicklungen erfolgen, der »beta« -Zweig, in dem getestet und auch die nächste Release vorbereitet wird, sowie der »stable« -Zweig, der die gerade stabile Version enthält.

Release-Plan

Der Plan für Releases ähnelt frappierend dem Releasezyklus von Debian, auch die genutzten Methoden sind ähnlich. So wandern Updates nach einer gewissen Zeit vom Alpha- in den Beta-Zweig, und wenn dieser keine Bugs mehr enthält, wird er der neue »stable« -Tree, wobei die Core-OS-Entwickler insgesamt etwas schneller zu Werke gehen, als es bei Debian der Fall ist.

Wer Core OS ausprobieren möchte, sollte mindestens auf den Zweig der Betaversion setzen. Besser ist es, mit der aktuellen stabilen Version zu experimentieren. Kurz nach einer Release sind die beiden ohnehin weitgehend identisch.

Die Core-OS-Website [8] bietet verschiedene Informationen, wie sich Core OS auf bestimmten Systemen installieren lässt. Tests mit Qemu, Libvirt oder VMware sind ausdrücklich erwünscht und technisch leicht in die Tat umzusetzen.

Online-Ressourcen helfen beim Testen

Für den Test bietet sich die Variante auf Basis einer Open-Stack-Installation an – das entsprechende Open-Stack-Image stellt das Projekt auf seiner Website selbst zur Verfügung.

Über ein entsprechendes Skript ist es möglich, der Etcd-Instanz innerhalb der gestarteten VMs ihre Discovery-ID mit auf den Weg zu geben. Im Anschluss präsentiert sich ein Mehrknoten-Cluster aus Core-OS-VMs, die über Etcd und Fleet orchestriert sind. Danach könnte es im Grunde bereits mit Docker-Containern losgehen, in denen dann die Applikationen als Containerdienste laufen. Im Test funktionierte Core OS stets genau so, wie die Entwickler es versprechen, und zeigte keine Schwächen – Hut ab.

Support-Modelle

Core OS selbst ist zunächst als Image natürlich kostenlos, auch die Benutzung ist kostenfrei. Es besteht ausschließlich aus Komponenten, die unter Open-Source-Lizenzen vertrieben werden. Das Unternehmen hinter Core OS bietet aber auch ein Supportmodell mit Bezahlung an, das auf den namen “Core OS Managed Linux” hört.

Die Preise unterscheiden sich im Wesentlichen hinsichtlich der gebotenen Leistung und der Anzahl der Server, die ein Vertrag abdeckt. “Managed Linux” für bis zu zehn Server schlägt mit 100 US-Dollar pro Monat zu Buche, enthalten ist neben Zugriff auf Coreupdate auch Hilfe bei der Installation und Nutzung von Core OS per E-Mail.

Wer stattdessen noch einen draufsetzt und in den “Premium Support” investiert, bekommt Priority-Support per Telefon, muss aber auch deutlich tiefer in die Tasche greifen: Für bis zu 25 Server werden 1200 Dollar pro Monat fällig. Wer zwischen 51 und 250 Server im Premium-Vertrag abdecken möchte, zahlt dafür jedoch bereits 11000 Dollar pro Monat – alles andere als ein Pappenstiel. Eine europäische Dependance gibt es noch nicht, wer Support will, muss ihn in den USA einkaufen.

Fazit

Core OS gilt derzeit vollkommen zu Recht als Shootingstar der Cloudszene, denn anders als hergebrachte Distributionen ist es eigens für den Einsatz in den Wolken entwickelt. Das merkt der Nutzer vor allem daran, dass es in vielerlei Hinsicht anders denkt, als konventionelle Systeme es tun – und so Probleme nicht zu umgehen hat, an denen Debian, Red Hat & Co. knabbern.

Etcd und Fleet sind zwei sehr hilfreiche Werkzeuge, die eine deutlich stärkere Präsenz auch außerhalb von Core OS verdient hätten. Und der eingebaute Update-Mechanismus ist so pfiffig, dass sich glatt die Frage stellt, wieso diese Idee vorher noch niemand hatte.

Wer also auf der Suche nach einem ordentlichen Betriebssystem für seine Cloud ist, sollte sich Core OS auf jeden Fall genauer ansehen. Gerade dann, wenn Docker als Alternative zur Vollvirtualisierung ebenfalls zur Diskussion steht. Doch Admins seien gewarnt: Berührungsängste mit Neuerungen stehen bei Core OS eher im Weg – wer die Distribution ausprobieren will, muss auch dazu bereit sein, lange gehegte Konventionen über Bord zu werden.

Der Autor

Martin Gerhard Loschwitz arbeitet als Principal Consultant bei Hastexo. Er beschäftigt sich dort intensiv mit den Themen HA, Distributed Storage und Open Stack. In seiner Freizeit pflegt er Pacemaker für Debian.