Open Source im professionellen Einsatz
Linux-Magazin 08/2015
© maroti 123RF

© maroti 123RF

Mesos-Framework Aurora

Dispatcherdienste

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.

1084

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.

Anschieber

Auf den ersten Blick scheinen Aurora und Marathon den gleichen Zweck zu erfüllen, und beide setzen auf Mesos auf. Beide dienen dazu, lange laufende Anwendungen zu starten und zu überwachen. Im Detail gibt es dann doch Unterscheidungsmerkmale: Die Installation und erste Tests gehen bei Marathon deutlich schneller und leichter von der Hand. Für Aurora sind einige Klimmzüge nötig. Für die ersten Jobs gilt es, die entsprechende Beschreibungssprache zu lernen. Bei Marathon reichen an dieser Stelle fast rudimentäre Json-Kenntnisse.

Aurora ist ebenso wie Mesos ein natürliches Mitglied der Apache-Familie. Marathon hingegen ist ein Projekt, das die Firma Mesosphere vorantreibt. Ein weiterer Unterschied betrifft die Unterstützung der allerneusten Features und Technologien. Aurora ist hier etwas konservativer, um die Stabilität von Twitter-Diensten nicht unnötig zu gefährden. Die Integration von Docker beispielsweise fand bei Marathon früher statt.

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.

Listing 1

Hallo-Welt-Version eines Aurora-Jobs

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.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 3 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Apache Mesos

    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.

  • Firefox schließt Release-Channel Aurora

    Mozilla hatte den Aurora-Channel im Jahr 2011 als Bindeglied zwischen Nightly-Builds und Betaversionen im Release-Prozess gestartet. Wie Mozilla nun bekannt gibt, passt der Aurora-Channel nun nicht mehr in die Release-Strategie des Projekts.

  • Container-Management

    Diverse Lösungen treten an, um Admins perfektes Container-Management zu liefern. Das Linux-Magazin fühlt Kubernetes, Docker Swarm, Mesos und Diego auf den Zahn.

  • Datacenter Operating System wird Open Source

    Führende Technologieunternehmen arbeiten zusammen, um das erste Open Source Betriebssystem für den Produktionsbetrieb von Containern und verteilten Anwendungen zu liefern

  • Mesos in Version 1.0 mit HTTP-API

    Die Apache Software Foundation hat die Verfügbarkeit von Mesos 1.0 angekündigt.

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.