© dotshock, 123RF

Neben möglichst schlanken Betriebssystemen für die Cloud wecken auch umfassendere Ansätze das Interesse der Admins. So etwa das freie Cluster-Framework Mesos, das Rechenzentren antreibt.

Es gibt Bewegung auf dem Feld der Betriebssysteme. Kürzlich stellte das Linux Magazin schlanke quelloffene Varianten für die Cloud vor [1]. Doch auch für traditionelle Rechenzentren warten neue Ideen. Eine prominente heißt DCOS (Datacenter Operating System) und kommt von Mesosphere [2]. Wesentliche Komponente ist hier das Cluster-Framework Mesos von Apache [3], das seit etwa 2009 existiert und mittlerweile einige Fans zählt. Dazu gehören Schwergewichte wie Ebay [4], Netflix [5], Paypal [6] oder Twitter [7].

Grob betrachtet ist Mesos ein Gerüst, um alle Ressourcen eines Rechenzentrums möglichst effizient zu nutzen. Es entwickelt gewissermaßen die klassischen Berechnungscluster aus dem HPC-Umfeld weiter und fasst CPU, Speicher, Plattenplatz oder andere Ressourcen zu einem einzigen – verteilten – Konstrukt zusammen. Das sind genau die Aufgaben, die auf einem Einzelcomputer der Betriebssystemkern übernimmt. Der Anschaulichkeit halber bezeichnet das Projekt Mesos daher auch gern als verteilten Kernel für das Rechenzentrum.

Was bisher geschah

Wie viele Open-Source-Projekte entstand auch Mesos im universitären Umfeld. Konkret wirkten die Doktoranden Benjamin Hindman, Andy Konwinski, Matei Zaharia und ihr Professor Ion Stoica von der renommierten University of California, Berkeley, daran mit. Im Jahr 2009 erfolgte die öffentliche Vorstellung [8], zu jenem Zeitpunkt lautete der Codename des Projektes Nexus ([9], [10]). Damit die Anwender das Projekt nicht mit einem gleichnamigen anderen verwechseln, benannte es sich in Mesos um.

Mesos ist in C++ geschrieben, steht unter der Apache-Lizenz, aktuell ist Version 0.21. Das Projekt will es Admins ermöglichen, alle im Rechenzentrum verfügbaren Ressourcen einfach zu nutzen. Mesos ist ein Toplevel-Projekt der Apache-Foundation in der Kategorie Cloud.

Zwei Jahre nach der Erstveröffentlichung zeigten die Entwickler auf der Usenix-Konferenz 2011 [11] eine viel fortgeschrittenere Variante [12]. Zu diesem Zeitpunkt betrieben die Ingenieure von Twitter Mesos bereits seit einem Jahr in ihrer eigenen IT-Infrastruktur [13]. Manche von ihnen hatten zuvor bei Google gearbeitet und kannten dessen Pendant, das heute auf den Namen Omega ([14], [15]) hört. Inzwischen nutzen viele prominente Firmen Mesos, Ebay und Netflix sind nur die bekanntesten.

Mesos stellt ein Gerüst bereit, über das Admins die Ressourcen der IT-Landschaft nutzen. Damit dies effizient geschieht, müssen entsprechende Schnittstellen (APIs) vorhanden und hinreichend dokumentiert sein. Wer sich Mesos von dieser Seite nähert, findet unter [16] einen guten Einstieg. Dabei spielt es keine Rolle, ob der Entwickler eher C, C++, Java, Go oder Python bevorzugt.

Als Scheduler dient Mesos einer Reihe anderer Softwareprojekte im Rechenzentrum als Unterbau, Tabelle 1 listet einige auf, unter [17] gibt es auch eine sehr schöne Darstellung. In der Mesos-Sprache heißen diese “Nutznießer” verwirrenderweise Frameworks. Eine alternative Bezeichnung ist Mesos-Anwendung. Sie ergibt mehr Sinn, betrachtet man den anfänglichen Vergleich mit einem verteilten Betriebssystemkern (Abbildung 1). Der Artikel verwendet beide Begriffe synonym und geht auch auf Marathon und Chronos ein.

Tabelle 1 auflistet.” width=”300″ height=”104″ /> Abbildung 1: Apache Mesos dient gewissermaßen als ein über das Rechenzentrum verteilter Betriebssystemkern für eine Reihe verschiedener Frameworks, die Tabelle 1 auflistet.

Meister und Sklaven

Die Architektur hinter Mesos [18] ist gleichermaßen einfach und komplex. Ganz grob formuliert gibt es zwei Rollen: Master und Slaves. Master heißt der Hauptprozess. Er nimmt die Anfragen der Frameworks entgegen und gibt sie an andere Mitglieder im Mesos-Verbund weiter. Das sind die Slaves oder Worker, sie verrichten die eigentliche Arbeit. Was genau sie tun, hängt vom verwendeten Framework beziehungsweise der Mesos-Anwendung ab.

Der Master übernimmt den ersten Schritt einer zweistufigen Aufgabenplanung. Tritt ein Slave oder Worker dem Mesos-Verbund bei, teilt er dem Mesos-Chef mit, welche Ressourcen er in welcher Menge mitbringt. Der Master protokolliert diese und bietet sie den Frameworks an.

Im zweiten Schritt der Aufgabenplanung entscheidet die Mesos-Anwendung, welche konkreten Jobs sie den angebotenen Ressourcen zuordnet. Der Master nimmt diese Anforderung entgegen und verteilt sie auf die Slaves. Es gibt also zwei Scheduler: den Master und die Mesos-Anwendung (Abbildung 2).

Abbildung 2: Das Zusammenspiel zwischen Mesos-Anwendung (Framework) und Mesos (Master und Slave) beim Abarbeiten von Aufgaben.

So genannte Exekutoren führen den Job anschließend aus. Etwas abstrakt gesprochen handelt es sich dabei um Framework-verwandte Prozesse, die auf den Slaves ihre Arbeit verrichten. Im einfachsten Fall handelt es sich um schlichte (Shell-)Kommandos. Für die in Tabelle 1 gelisteten Frameworks dienen die jeweiligen Laufzeitumgebungen beziehungsweise abgespeckte Versionen des Framework selbst als Exekutoren.

Der Master bestimmt, wann ein Job beginnt und endet. Allerdings kümmert sich der Slave oder Worker wiederum um die Details. Er verwaltet die Ressourcen für den Prozess und überwachte das Ganze. In der Mesos-Sprache entspricht ein Framework-Job einer Slave- oder Executor-Task (Abbildung 2). In dem Analogon eines Betriebssystems wäre es ein Thread.

Wie erwähnt protokolliert der Mesos-Master, welche Ressourcen jeder Slave in den Verbund einbringt beziehungsweise zur Laufzeit noch zur Verfügung hat. Im Auslieferungszustand sind die Anzahl der Prozessoren, der Hauptspeicher sowie der Plattenplatz und die freien Netzwerkports vordefiniert. Ohne Zusatzkonfiguration gibt der Slave also einfach weiter, was er zum gegenwärtigen Zeitpunkt parat hat. Typischerweise legt der Admin fest, welche Ressourcen er dem Mesos-Verbund in welchem Umfang spendiert [19].

Die Anzahl der Prozessoren und der freie Hauptspeicher nehmen dabei eine gewisse Sonderposition ein. Mangelt es einem Slave an einem von beiden, kann er keine anderen Ressourcen in den Mesos-Cluster einbringen [20]. Beide sind jedoch notwendig, um auch nur ein einfaches Kommando auszuführen – unabhängig vom benötigten Plattenplatz oder den notwendigen Netzwerkports. Selbstverständlich lassen sich weitere – selbst erfundene – Ressourcen definieren, weitere Details dazu finden Interessierte unter [20].

Verfügbar sein

Doch es bleiben mindestens zwei Fragen offen. Erstens: Wie sieht es mit der Ausfallsicherheit beziehungsweise Verfügbarkeit aus? Zweitens: Wie funktioniert die Authentisierung?

(Hoch-)Verfügbarkeit ist bei Mesos natürlich nicht in Vergessenheit geraten. Für die Slaves ist das Konzept ganz einfach. Sie sind als Farm organisiert [21]. Um also den Ausfall von X Workern zu verkraften, muss der Mesos-Verbund mindestens N+X Slaves umfassen. Dabei ist N die Anzahl der Rechner, die das geforderte Mindestmaß an Ressourcen bereitstellen.

Beim Master sieht es etwas anders aus. Hier greift Mesos auf die Infrastruktur von Zookeeper ([22], [23]) zurück. Die Auswahl dieses Systems ist nicht wirklich überraschend – ist es doch ebenfalls ein Apache-Projekt. Zookeeper dient hier gleichermaßen als Leim zwischen den multiplen Mesos-Mastern und als Anlaufstelle für die Frameworks. Für Erstere erlaubt die HA-Infrastruktur die Wahl des eigentlichen Chefs im Verbund.

Die Information, wie Zookeeper zu erreichen ist, gibt der Mesos-Admin beim Start der Master-Instanzen an. Alternativ lässt sie sich auch in Shellvariablen hinterlegen (Tabelle 2).

Für die Mesos-Anwendungen wiederum dient Zookeeper als erste Anlaufstelle, wenn sie den Master herausfinden wollen. Auch hier gilt, dass der Admin die Informationen beim Start des Framework bereitstellen muss. Wer Mesos professionell betreiben möchte, kommt um ein Zookeeper-Setup nicht herum. Ein paar wichtige Details liefert der Kasten “Zoowächter”.

Die zweite Frage betrifft die Authentisierung, sie umfasst gleich mehrere Aspekte. Da ist einmal das Vertrauensverhältnis innerhalb des Mesos-Verbunds, also zwischen Master und Slave. Zum anderen berührt das Thema natürlich die Zusammenarbeit zwischen einer Mesos-Anwendung und Mesos.

Im Auslieferungszustand kommen hier SASL (Simple Authentication and Security Layer, [25]) mit Crammd5 [26] zum Zuge. Für die Authentisierung von Frameworks gibt es seit Version 0.20 neben der Authentisierung auch eine Autorisierung [27].

Dabei unterscheidet Mesos drei Kategorien: Rollen, Benutzer und Anweiser. Diese erhalten bei unterschiedlichen Aktionen Gewicht. Eine Rolle ist eine Eigenschaft, unter der sich ein Framework bei Mesos registriert. Intern hilft eine Zugriffskontrollliste (Access Control List, ACL) bei dieser Aufgabe. Ist die Mesos-Anwendung dort entsprechend vermerkt, erhält sie Zugriff auf Ressourcen zum Ausführen von Jobs.

Führt sie dann die Tasks auf den Slaves aus, kommt die zweite Kategorie zum Tragen. Die Benutzer entsprechen dem gleichnamigen Konstrukt auf Betriebssystemebene. Auch hier verwendet Mesos intern die erwähnten ACLs.

Die dritte Kategorie – Anweiser – regelt das Abschalten eines Framework. Die Definition der entsprechenden Berechtigung erfolgt im Json-Format [28], Details liefern [19] und [27].

War das schon alles?

Ende 2014 kündigte Mesosphere ein Datacenter Operating System (DCOS) an [29]. Es ist nicht überraschend, dass Mesos hier die Rolle des Betriebssystemkerns übernehmen wird. Dazu gesellen sich die Frameworks Marathon [30] und Chronos [31]. Ersteres verwaltet Jobs mit langer Ausführungszeit. Im Vergleich mit einem klassischen Unix-ähnlichen Betriebssystem entspricht Marathon dem Init-Prozess [32]. Man kann es auch als Meta-Scheduler betrachten, der auf Mesos aufsetzt. Marathon startet die anderen Frameworks und überwacht sie. Dabei prüft es, ob die gewünschte Anzahl von Jobinstanzen läuft. Fällt beispielsweise ein Slave aus, startet Marathon auf den verbliebenen Mesos-Knoten die ausgefallenen Prozesse.

Chronos führt Jobs nach einem vorgegebenen Plan aus. Es entspricht damit Cron [33]. Bei DCOS ist Chronos das erste von Marathon gestartete Framework. Beide besitzen eine REST-Schnittstelle zum Interagieren ([34], [35], [16]).

Abbildung 3 zeigt eine stark vereinfachte Selbstbau-Version von DCOS. Nur Marathon (Abbildung 4) und Chronos sind als Mesos-Anwendungen registriert. Die jeweiligen Jobs sind einfache »sleep« -Kommandos. Zookeeper zu verwenden ist für DCOS verpflichtend. Sowohl Marathon als auch Chronos setzen diese Infrastruktur voraus.

Abbildung 3: Das Data Centre Operating System in der Schmalspurvariante: Mesos mit Marathon und Chronos.

Abbildung 4: Marathon beweist einen langen Atem und verwaltet lange andauernde Jobs.

Zu Redaktionsschluss gab es das Datacenter OS von Mesosphere noch nicht als fertiges Produkt. Interessenten können sich aber für eine Vorabversion anmelden. Genauere Informationen liefert die Webpräsenz von Mesosphere [2].

Eine Art Zwischenfazit

Dass Mesos ein spannendes Projekt ist, zeigt eigentlich schon die Liste der Unternehmen, die es inzwischen seit Jahren einsetzen. Die Anzahl der darauf aufsetzenden Frameworks kann sich ebenfalls sehen lassen. Sein Stärke spielt Mesos vor allem in großen und heterogenen IT-Landschaften aus. Auf einfache Weise fasst es die vorhandenen Rechenkapazitäten zusammen und stellt sie wahlweise als Gesamtpaket oder häppchenweise zur Verfügung. Diese Form der Abstraktion ist aber auch für kleinere IT-Umgebungen schick. Das angekündigte DCOS ist letztlich nur die logische Weiterentwicklung der existierenden Projekte und hebt den Rechenzentrumsbetrieb auf eine neue Ebene.