© maroti 123RF

Darum, dass die wichtigen Dienste im Rechenzentrum immer am Laufen sind, will sich das Apache-Projekt Aurora kümmern. Das Verteilen von Diensten hat Aurora von Twitter gelernt.

Der Erfolg des Aurora-Projekts [1] hat viele Väter: Zum Beispiel stand ursprünglich Twitter hinter der Entwicklung, die Software ist Teil von Mesos [2] das mit seinem Framework ein Betriebssystem für Rechenzentren [3] sein will. Des Weiteren hat Aurora im März dieses Jahres den Apache-Inkubator verlassen und firmiert nun als ein vollwertiges Apache-Projekt. Und nicht zuletzt stand auch Google zumindest indirekt Pate bei diesem Projekt.

Die Anfänge von Aurora reichen in das Jahr 2010 zurück. Bill Farner, ein Mitglied des Forschungsteams bei Twitter, startete damals ein Projekt, um den Betrieb der Zwitscher-Infrastruktur zu erleichtern. Die IT-Landschaft des Kurznachrichtendienstes war zu jenem Zeitpunkt beträchtlich gewachsen. Die Betriebsteams sahen sich mit Tausenden von Rechnern und Hunderten von Applikationen konfrontiert. Hinzu kam das ständige Ausrollen neuer Softwareversionen.

Jener Bill Farner hatte zuvor bei Google gearbeitet und dort Einblick in deren Clustermanager Borg [4] erhalten. So stand der Internetgigant quasi indirekt Pate für Aurora.

In den ersten Jahren fand die Entwicklung nur innerhalb von Twitter und hinter verschlossenen Türen statt. Mehr und mehr Angestellte trugen zur Weiterentwicklung bei. Aurora wurde für die verschiedenen Twitter-Dienste immer wichtiger. Schließlich war die Öffnung des Projekts in Richtung der Open-Source-Community ein natürlicher Schritt, um ein so stark gewachsenes Softwareprojekt pflegen zu können. Seit 2013 gehört Aurora zur Apache-Familie.

Stein auf Stein

Eine zentrale Aufgabe von Aurora bildet das Starten und Überwachen von Diensten in einer IT-Landschaft. Man könnte es mit einem Rechenzentrums-weiten Init-Daemon vergleichen. Fällt ein Server oder eine Anwendung aus, startet Aurora sie auf einem anderen Rechner neu und prüft, ob alles erwartungsgemäß funktioniert. Kenner der Materie sehen hier auch eine Verwandtschaft mit den bekannten Mesos-Diensten Marathon [5] und eventuell auch Chronos [6]. Der Kasten “Anschieber” enthält dazu weitere Details. Die zweite Verantwortlichkeit von Aurora ist das Ausrollen neuer Versionen der überwachten Dienste.

Außerdem registriert Aurora die Dienste und ermöglicht es so anderen Programmen, sie zu nutzen. Dafür greift Aurora auf Zookeeper [7] zurück. Für das Starten und Überwachen von Diensten nutzt das Projekt Mesos. Diesem Apache-Projekt hat das Linux-Magazins bereits einen Artikel gewidmet [8]. Dort ist auch beschrieben, wie Mesos gewissermaßen als Rechenzentrums-Scheduler arbeitet. Der Artikel erwähnt die Rollen Master und Slave. Der Master nimmt Aufgaben entgegen und gibt sie zur eigentlichen Abarbeitung an Slaves weiter.

Aurora fungiert nun als Abstraktionsschicht zur Aufgabenverteilung durch Mesos. Man kann es als Meta-Scheduler bezeichnen. Das Zusammenspiel der einzelnen Komponenten ist in Abbildung 2 dargestellt.

Abbildung 2: Aurora, Zookeeper, Mesos und Thermos im Zusammenspiel.

Jobs, Aufgaben, Prozesse

Ein Blick hinter die Kulissen zeigt, dass das Ganze noch etwas komplizierter ist. Aurora benutzt Mesos zwar als Unterbau, kopiert aber zusätzlich eigene Komponenten auf die Slaves, um die Tasks abzuarbeiten. Diese speziellen Bestandteile hören auf den Namen Thermos. Sie erfüllen zwei Aufgaben: Zum einen gibt es die so genannten Exekutoren, die Prozesse auf Betriebssystem-Ebene starten. Zum anderen existieren Observer. Sie sind eine Art Meldestelle für die Exekutoren. Sie erhalten die Statusmeldungen über die gestarteten Prozesse und reichen diese dann an Mesos zurück.

Zum Verständnis ist es hilfreich, sich an die Terminologie des Projekts zu halten. Auf der Aurora-Ebene gibt es Jobs. Die zerfallen in Tasks der Mesos-Schicht. Ein Job entspricht daher normalerweise mehreren Tasks. Auf der Thermos-Ebene schließlich zerfallen die Tasks in Prozesse, die der Admin mit Kommandos wie »ps« oder »top« betrachten kann. Die Beschreibung eines Aurora-Jobs enthält Instruktionen für den Meta-Scheduler selber, für Mesos und Thermos. Angaben über Jobs, Tasks und Prozesse definieren am Ende die Anwendung, die der Meta-Scheduler überwacht.

Die Entwickler verwenden dafür eine Python-basierte Domain Specific Language (DSL). Die Beschreibungsdatei besitzt typischerweise die Endung ».aurora« und hat mehrere Bestandteile. Einer ist eine Art Jobschablone, die dazu dient, Gemeinsamkeiten einfach zusammenzufassen, wenn die Aufgaben auf Aurora-Ebene identisch sind und sich nur die Tasks oder Prozesse unterscheiden. Das vermeidet Redundanzen in der Beschreibung. Nach dieser Vorlage definiert man die Prozesse (Thermos), Tasks (Mesos) und Jobs (Aurora).

Das Ganze kann etwas verwirrend wirken. Ein typisches Hallo-Welt-Beispiel zeigt Listing 1. Ein Prozess-Objekt in der Aurora-DSL erfordert zwei Angaben: einen Namen und das auszuführende Kommando. Letzteres ist im vorliegenden Fall ein einfaches Echo-Kommando, das Python über das OS-Modul ausführt. Ein Task-Objekt benötigt einen Namen und die zugehörigen Prozesse. Für Mesos selbst kommen natürlich noch die notwendigen Ressourcen dazu. Anhand dieser Angaben sucht sich das System die passenden Sklaven heraus. In Listing 1 lauten die Anforderung 10 Prozent CPU, 20 MByte RAM und ebenso viel Plattenplatz. Es lassen sich auch mehrere Prozesse einer Task zuordnen.

01 $ cat hallo.welt.aurora
02 import os
03 hallo_welt_process = Process(
04   name = 'hallo_welt',
05   cmdline = 'echo hallo welt')
06
07 hallo_welt_task = Task(
08   resources = Resources(cpu = 0.1, ram = 20*MB, disk = 20*MB),
09   processes = [hallo_welt_process])
10
11 hallo_welt_job = Job(
12   cluster = 'test',
13   role = os.getenv('USER'),
14   task = hallo_welt_task)
15
16 jobs = [hallo_welt_job]

Des Weiteren benötigt die Konfiguration Angaben über die zugeordneten Tasks, eine Rolle und die Ausführungsumgebung. Die Rolle entspricht oft dem Benutzerkontext, unter dem die zugehörigen Prozesse am Ende laufen. Die Ausführungsumgebung wiederum definiert, welche Aurora-Instanzen sich um den Job kümmern. Das dargestellte Beispiel demonstriert nur einen Teil der Möglichkeiten. Wer tiefer einsteigen will, der findet ausreichend Lesestoff in der Projekt-Dokumentation ([9] bis [12]).

Wer erste Schritte mit Aurora wagen möchte, hat mehrere Möglichkeiten. Empfehlenswert ist die Installation von Vagrant [13]. Die Projekt-Dokumentation und auch andere Anleitungen im Internet benutzen dieses Werkzeug zur Installation. Der Weg zu Fuß ist deutlich schwieriger und erfordert zunächst die Installation eines Mesos-Clusters [14] mit der zugehörigen Zookeeper-Infrastruktur.

Schwierige Installation

Die Installation der verschiedenen Aurora-Komponenten ist zwar prinzipiell dokumentiert, aber sehr unübersichtlich. Es geht nicht klar aus ihr hervor, welche Schritte in welcher Reihenfolge zu absolvieren sind. Das hat dem Team des Linux-Magazins einiges Kopfzerbrechen bereitet. Die nächste Hausaufgabe besteht im Erlernen der Beschreibungssprache. Hier empfiehlt es sich wiederum, mit den einfachen Beispielen aus der Dokumentation zu beginnen und sie dann Schritt für Schritt systematisch zu erweitern.

Die Einstiegshürden für den erfolgreichen Einsatz von Aurora sind nicht gerade niedrig. Für kleinere IT-Umgebungen sollte der Admin daher zunächst sehr sorgfältig Aufwand und Nutzen abschätzen. In großen Umgebungen mit vielen Servern, vielen Diensten und ständigen Software-Updates, lohnt sich dagegen das Evaluieren des Meta-Schedulers umso mehr.