Suche
Das Betriebssystem der Cloud - Teil 4

Eine Einführung in Apache Mesos: Schritt für Schritt in die Cloud

Mario-Leander Reimer, Andreas Zitzelsberger, Michael Hausenblas

©Shutterstock / Lightspring

Apache Mesos ist der Kernel für verteilte Systeme. Es bietet Anwendungen analog zum klassischen Betriebssystemkernel einheitliche Schnittstellen, um Ressourcen im Cluster zu verwalten und an Anwendungen zu vermitteln. Mesos ist der Kernbestandteil von DC/OS, einem Betriebssystem für die Cloud. Im Rahmen dieses Artikels geben wir eine Einführung in Mesos und zeigen, wie man die beispielhafte Spring-Cloud-Anwendung Zwitscher auf DC/OS zum Laufen bringt.

Die Kernaufgabe von Apache Mesos ist das Scheduling von Containern im Cluster. Mesos führt die Container dabei auf den Cloud-Knoten zuverlässig und ressourcenschonend aus. Rescheduling erfolgt bei Bedarf, z. B. beim Ausfall einer Ressource oder wenn alternative, passendere Ressourcen frei werden. Dann wird die Ausführung eines Containers auf eine andere Ressource verlagert.

Apache Mesos abstrahiert dabei die konkrete Infrastruktur hin zu Ressourcen wie Rechenleistung, Netzwerk oder Storage. Der Nutzer von Mesos übergibt lediglich einen Container zur Ausführung. Ob dieser dann in einer lokalen virtuellen Maschine, einer privaten oder öffentlichen IaaS Cloud oder auf klassischen Server Racks ausgeführt wird, verbirgt Mesos. Ebenso vermittelt Mesos je nach Bedarf Netzwerkverbindungen und Storage Mounts. Ziel ist, mehrere Mandanten und Anwendungen im Cluster genauso einfach und effektiv zu betreiben wie auf einem lokalen Rechner, damit die verfügbaren Ressourcen möglichst effektiv genutzt werden können.

Hintergrundinformationen zu Apache Mesos und DC/OS

Mesos wurde vom RAD Lab der University of California entwickelt und das erste Mal 2009 veröffentlicht. 2011 war Mesos bereits deutlich fortgeschritten und wurde von Twitter adaptiert. Mittlerweile setzen auch Airbnb, Apple und viele weitere auf Mesos und betreiben damit Cluster mit zehntausenden Rechnern. Seit 2013 ist Mesos ein Top-Level-Projekt der Apache Software Foundation.

DC/OS steht für Data Center Operating System. DC/OS erweitert Mesos als Kernel um zusätzliche Funktionalität mit dem Ziel, ein vollwertiges, integriertes Betriebssystem für die Cloud zu bieten. Das System wurde im April 2016 von Mesosphere unter der Apache-2.0-Lizenz freigegeben und bietet unter anderem:

  • Einen DNS-Service für Service Naming und Discovery
  • Ein Command Line Interface sowie ein webbasiertes Administrations-UI
  • Ein Package Repository mit diversen vorgefertigten Anwendungs- und Infrastrukturpaketen
  • Frameworkintegrationen von Marathon und Chronos für langlaufende und zeitgesteuerte Services

Zusammenspiel mit einem Cluster-Orchestrierer

Abb. 1: Der Cloud Native Stack: Apache Mesos, Kubernetes, Spring Cloud

Abb. 1: Der Cloud Native Stack: Mesos, Kubernetes, Spring Cloud

Apache Mesos ist ein Cluster-Scheduler. Wie spielt Mesos mit einem Cluster-Orchestrierer zusammen? Das Zusammenspiel (Abb. 1) lässt sich am einfachsten erklären, wenn wir die Analogie zum klassischen Betriebssystem betrachten. Im klassischen Betriebssystem gibt es Ausführungseinheiten wie Prozesse und Threads und darüber Anwendungen. Eine Anwendung kann aus vielen Ausführungseinheiten bestehen, die alle möglichen Abhängigkeiten, Querbeziehungen und Eigenheiten mitbringen.

Mehr zum Thema: Einführung in den SMACK-Stack: Spark, Mesos, Akka, Cassandra, Kafka

Der Kernel des Betriebssystems kennt nur Threads und Prozesse und weiß nichts von Anwendungen. Anwendungen werden von zusätzlichen Komponenten wie einem init-System für Services (sytemd oder initd) oder einem Applikationsserver gesteuert. Im Cluster erfüllt Mesos die Rolle des Kernels und bietet Ressourcenmanagement und -Scheduling. Mesos kennt als Ausführungseinheit Tasks, weiß aber nichts von Anwendungen. Ein Task ist die Ausführung eines Docker-Containers oder eines Shell-Kommandos. Anwendungen werden vom Orchestrierer gesteuert.

Wie funktioniert Apache Mesos?

Mesos setzt eine Master-Slave-Architektur um (Abb. 2). Es gibt einen Master, der Agenten verwaltet, die auf jedem Knoten (Worker-Node) im Cluster laufen. Mesos-Frameworks führen Tasks auf diesen Agenten aus. In Abbildung 2 sind zwei Frameworks in weiß dargestellt: Eines für Hadoop und eines für MPI. Ein Framework besteht aus zwei Komponenten: einem Scheduler, der sich am Master anmeldet, um Ressourcenangebote zu erhalten, und einem Executor, der die tatsächliche Ausführung der Tasks übernimmt. Die Frameworkschnittstelle ist auch die Schnittstelle zum Cluster-Orchestrierer. Marathon oder auch Kubernetes laufen als Frameworks im Mesos-Cluster. Mesos implementiert außerdem zweistufiges Scheduling (Two-Level-Scheduling, Abb. 3).

Abb. 3: Zweistufiges Scheduling in Apache Mesos

Abb. 3: Zweistufiges Scheduling in Mesos

Stufe 1: Der Ressourcen-Scheduler kennt alle verfügbaren Ressourcen und darf diese allokieren. Er nimmt Ressourcenanfragen (Specifications) entgegen und unterbreitet entsprechend einer Scheduling Policy Ressourcenangebote (Offers). Dabei nutzt Mesos standardmäßig DRF (Dominant Resource Fairness) als Algorithmus. Dieser Algorithmus ist auf Fairness ausgelegt und verhindert, dass sich Tasks mehr als die ihnen fairerweise zustehenden Ressourcen erschleichen. Somit können auf einem Mesos-Cluster viele unterschiedliche Anwendungen und Mandanten in friedlicher Gemeinschaft betrieben werden. In Mesos hat der Master die Rolle des Ressourcen-Schedulers inne.

Stufe 2: Der App-Scheduler nimmt Tasks entgegen, übersetzt diese in Ressourcenanfragen und nimmt passende Ressourcenangebote an. Der App-Scheduler ist nicht Bestandteil von Mesos und wird als Teil eines Frameworks anwendungsspezifisch ergänzt. Auf einem Mesos-Cluster können mehrere Frameworks gleichzeitig betrieben werden.

Im Kasten „Mesos-Frameworks kurz vorgestellt“ finden Sie eine Übersicht herausragender Frameworks für Mesos. Eine längere Liste von Frameworks findet sich in Mesos‘ Dokumentation.

Mehr zum Thema: JAX TV: Wie Sie mit Mesos eine produktionsreife PaaS entwickeln

Mesos-Frameworks kurz vorgestellt

  • Marathon eignet sich speziell zur Steuerung langlaufender Prozesse. Marathon ist einfach zu benutzen und in DC/OS fertig integriert. Es ist als Metaframework konzipiert, kann also andere Frameworks wie Chronos steuern.
  • Kubernetes ist der Cluster-Orchestrierer, obwohl es noch neu ist. Kubernetes wurde im letzten Java Magazin vorgestellt [1]. Leider gibt es zum Zeitpunkt der Erstellung dieses Artikels kein fertiges Paket des Kubernetes-Frameworks für Apache Mesos.
  • Chronos ist ein Scheduler zur Steuerung zeitgetriebener Tasks und damit das Cluster-Äquivalent zu cron in Unix.
  • Apache Aurora ist ein Framework, das sowohl langlaufende als auch zeitgesteuerte Tasks unterstützt und damit eine vollwertige Alternative zu Marathon und Chronos ist. Aurora kommt von Twitter und zielt auf sehr große Installationen ab, ist aber auch deutlich komplexer zu benutzen als Marathon und Chronos.
  • Jenkins verdient eine spezielle Erwähnung. Jenkins wird meist als Continuous-Integration-Server bezeichnet, ist aber tatsächlich ein sehr leistungsfähiger Orchestrierer für Batch-Jobs. Mit dem Mesos-Jenkins-Plug-in ist Jenkins in der Lage, beliebige Batches und natürlich auch CI-Builds im Cluster zu verteilen und zu steuern.

Erste Schritte: Hands-On Mesos

Für unsere ersten Schritte mit Mesos wollen wir DC/OS Vagrant einsetzen. Dies erlaubt uns, einen vorkonfigurierten kompletten DC/OS-Cluster auf einer Maschine hochzufahren (Abb. 4). Alternativ ist es z. B. auch möglich, den Showcase mit DC/OS auf Amazon AWS oder einem anderen Provider auszuführen. Das Set-up und die Systemvoraussetzungen findet man in der DC/OS-Vagrant-Deployment-Anleitung. Für den Showcase sollte das Zielsystem mindestens 16 GB Speicher besitzen. Wir verwenden die Communityversion 1.7.0 von DC/OS. Zusätzlich benötigen wir für die Beispiele das DC/OS CLI. Nach der Installation von DC/OS Vagrant erzeugen und starten wir einen Cluster mit einem Management-Node, drei Worker-Nodes und einem Bootstrap-Node:

$ vagrant up m1 a1 a2 a3 boot

Nachdem die Nodes laufen, lässt sich unter http://m1.dcos/ die DC/OS-Management-Oberfläche aufrufen. Die DC/OS-Community-Edition verwendet per Default externe OAuth-Quellen wie Google, GitHub oder Microsoft. Der erste angemeldete Nutzer wird zum Superuser und kann weitere Nutzer hinzufügen.

Abb. 4: Laufendes DC/OS

Abb. 4: Laufendes DC/OS

Zwitscher auf Apache Mesos und Marathon ausführen

Als nächsten Schritt packen wir unseren Zwitscher-Showcase auf Mesos. Wir setzen als Framework Marathon ein. Netterweise bringt unser fertiger Cluster schon ein vorkonfiguriertes und integriertes Marathon mit. Wir tun dies exemplarisch am Beispiel des Zwitscher-Eureka-Service. Als Erstes benötigen wir eine Marathon-Konfiguration für den Service. Die Konfiguration ist ein JSON, das über das DC/OS CLI oder das Marathon-REST-API an Marathon geschickt wird. Für die Marathon-Konfiguration gibt es auf der Mesosphere Github-Seite eine ausführliche Dokumentation.

{
  "id": "zwitscher-eureka",

  "instances": 1,
  "cpus": 0.1,
  "mem": 512,

  "container": {
    "type": "DOCKER",
    "docker": {
      "image": "qaware-oss-docker-registry.bintray.io/zwitscher/zwitscher-eureka:1.0.1",
      "network": "BRIDGE",
      "portMappings": [
        { "hostPort": 8761, "containerPort": 8761, "protocol": "tcp", "servicePort":8761}
      ]
    }
  },

  "healthChecks": [
    {
      "protocol": "HTTP",
      "path": "/admin/health",
      "intervalSeconds": 10,
      "portIndex": 0,
      "timeoutSeconds": 10,
      "maxConsecutiveFailures": 3
    }
  ]

}

In der Konfiguration (Listing 1) ist der Ressourcenbedarf, hier nur CPUs und Speicher, der Programmtyp („container“ mit „type“ : „DOCKER„) und die Settings für den Health Check definiert. Im Zwitscher GitHub finden sich Konfigurationen für sämtliche Services. Diese Konfiguration enthält eine Besonderheit: Da wir für die Discovery des Eureka-Service Mesos-DNS über die DNS-Schnittstelle einsetzen wollen, können wir keine dynamischen Ports verwenden. Mesos-DNS ist in unserem DC/OS-Vagrant-Cluster schon vorkonfiguriert.

Die Zeile „portMappings“ legt daher fest, dass der Marathon-Port 1:1 nach außen durchgereicht wird. Mesos kümmert sich selbstständig darum, dass die Container nur auf Nodes ausgeführt werden, die passende freie Ports haben. Damit können wir den Eureka-Service einfach über den Hostnamen referenzieren:

"dependencies" : [ "zwitscher-eureka" ],
  "env": { "eureka.host": "zwitscher-eureka.marathon.mesos"}

Lassen Sie uns nun den Config-Service über die Marathon CLI starten:

$ dcos marathon app add zwitscher-config/marathon-zwitscher-config.json

Der Status kann entweder über die CLI oder die Marathon-Weboberfläche beobachtet werden:

$ dcos marathon app list
ID                  MEM  CPUS  TASKS  HEALTH  DEPLOYMENT  CONTAINER  CMD
/zwitscher-config   512  0.1    0/1    0/0      scale       DOCKER   None

Nun ist es Zeit für einen Kaffee, da Mesos/Marathon/Docker den Container erst herunterladen, instanziieren und den Microservice starten muss. Das Ganze geht wesentlich schneller, wenn der Container bereits im Cluster verfügbar ist. Nach einiger Zeit springt die Anzeige auf den Status Running, und der Health Bar wird grün (Abb. 5).

Abb. 5: Marathon mit laufendem Config-Service

Abb. 5: Marathon mit laufendem Config-Service

Die anderen Services können analog deployt werden, alternativ findet sich im Zwischter GitHub ein kleines Skript namens marathon-deploy-all.sh, das sämtliche Services auf einen Rutsch deployt. Marathon unterstützt auch das Anlegen von Applikationen über das Web-UI. Nach ein paar Minuten schaut die Applikationsübersicht in Marathon dann aus wie in Abbildung 6.

Abb. 6: Marathon mit allen Zwitscher-Services

Abb. 6: Marathon mit allen Zwitscher-Services

Der Zwitscher-Cluster läuft nun. Als Test können wir das Zwitscher-Board über den Edge-Service aufrufen. Dazu öffnen wir den Edge-Service im Marathon-UI (Abb. 7). Unter den Nodes wird jeweils die IP:PORT-Kombination des Node angezeigt. Diese können wir einfach im Browser aufrufen. In Produktion würden wir einen Load Balancer vorschalten, der die Nodes der Edge-Services anspricht.

Abb. 7: Details des Zwitscher-Edge-Service in Marathon

Abb. 7: Details des Zwitscher-Edge-Service in Marathon

Zwitscher-Service skalieren

Wir wollen nun unseren Zwitscher-Service skalieren. Über das DC/OS CLI geht das schnell:

$ dcos marathon app update zwitscher-service instances=2
Created deployment ca7e50f0-ad1b-4172-91e0-50061cf78242

Ressourcennutzung in DC/OS und die Auslastung des Nodes, den Mesos für die Instanz auswählt, steigen. Dank Eureka war es das dann auch. Die Aufrufe der anderen Komponenten werden automatisch per Round-Robin an die Serviceinstanzen verteilt. In der Eureka-Weboberfläche tauchen beide Instanzen des Zwitscher-Service auf. Bei den anderen Services funktioniert das ganze analog, nur die Discovery von Eureka selbst läuft über Mesos-DNS. Auch über das Marathon-REST-API kann skaliert werden. Prinzipiell ist es möglich, beliebige automatische Skalierungs-Use-Cases zu bauen, diese müssen aber individuell programmiert werden. Mögliche Beispiele:

  • Automatisch in Abhängigkeit von den Requests/Sekunde skalieren
  • Niedrig priorisierte Batch-Jobs starten, wenn der Cluster wenig ausgelastet ist
  • Dynamische AWS-Instanzen bestellen, provisonieren und Anwendungen mit niedrigen Datenschutzbedarf erlauben, diese über Mesos zu nutzen

Fehlertoleranz messen

Wir simulieren nun einen Ausfall eines unserer Service. Dazu verbinden wir uns per vagrant ssh mit dem Node, auf dem eine der Eureka-Instanzen läuft. Das Passwort ist vagrant. Dann finden wir mit docker ps heraus, welcher Docker-Container den Eureka-Service enthält, und anschließend benutzen wir docker kill, um den Container zu stoppen. Nach einem kurzen Augenblick können wir in der Marathon-UI sehen, dass die Instanz als down erkannt wird und eine neue Instanz gestartet wird, um das Soll wieder zu erreichen. Danach stoppen wir den Node a2 oder a3. Dazu nutzen wir vagrant halt a3. Der Node wird in dem DC/OS-UI zunächst als N/A markiert. DC/OS wartet darauf, dass der Node wieder erreichbar wird. Nach Ablauf einer Grace Period wird der Node entfernt, und die Tasks auf dem Node werden auf die anderen Nodes verteilt. Wird der Node anschließend wieder hochgefahren, wird er nach kurzer Zeit von Mesos erkannt und wieder in den Cluster mit aufgenommen.

Fazit

Mit Apache Mesos und DC/OS steht ein leistungsfähiges Betriebssystem für die Cloud frei zur Verfügung. Der Stand der Dinge ist vergleichbar mit den ersten Linux-Versionen: Noch nicht perfekt und manches wird noch vermisst, aber ein deutlicher Schritt vorwärts. Zum Beispiel wären ausgereifte Cluster-Diagnosefunktionen hilfreich. Dafür stehen aber völlig neue Möglichkeiten bereit, auch sehr große und verteilte Anwendungslandschaften beherrschbar zu machen. Anhand des Zwitscher-Showcase konnten Sie sehen, wie eine Microservice-Anwendung auf Mesos deployt werden kann. Dabei spielt Mesos elegant mit dem bestehenden Stack aus Docker und Spring Cloud zusammen. Die Anwendung kann unverändert bleiben, sie muss nichts davon wissen, dass sie auf Mesos läuft, und Mesos selbst verrichtet geräuschlos und effektiv seinen Dienst, so wie man es von einem Kernel erwartet.

Mehr zum Thema:

Apache-Mesos-Interview: Neues in Mesos 1.0, Unterschiede zu Kubernetes und Docker Swarm, Pläne für DC/OS

Geschrieben von
Mario-Leander Reimer
Mario-Leander Reimer
Mario-Leander Reimer ist Cheftechnologe bei der QAware. Er ist Spezialist für den Entwurf und die Umsetzung von komplexen System- und Softwarearchitekturen auf Basis von Open-Source-Technologien.
Andreas Zitzelsberger
Andreas Zitzelsberger
Andreas Zitzelsberger ist Cheftechnologe bei der QAware GmbH, einem IT-Projekthaus mit Schwerpunkt auf Cloud-nativen Anwendungen und Softwaresanierung. Er konzentriert sich auf moderne Big-Data-Architekturen, leichtgewichtige Enterprise-Integration und Diagnose und Stabilisierung von komplexen Systemen.
Michael Hausenblas
Michael Hausenblas
Michael Hausenblas ist Entwickler und Cloud Advocate bei Mesosphere. Er hilft AppOps dabei, verteilte Cloud-native Applikationen zu entwickeln und zu betreiben. Mesosphere ist ein weltweit tätiges Softwareunternehmen, welches DC/OS entwickelt und maßgeblichen Anteil an der Entwicklung von Apache Mesos hat.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.