Mesos

Mesos ist ein OpenSource Projekt der Apache Foundation welches als Ziel hat ein Microkernel für Rechenzentren zu sein. Im Gegensatz zu Container Cluster Management Produkten wie Kubernetes, OpenShift oder Cloud Foundry, ist Mesos ein reiner Ressourcen Scheduler. Es besteht aus einer Kollektion von Software welche physikalische Ressourcen wie CPU, Memory und Storage zu einem einzigen Pool zusammenstellt. Die physikalischen Ressourcen werden dann den Frameworks wie z.B. Marathon, Chronos, ElasticSearch, Kafka (uvm) zur Verfügung gestellt.

Durch das Mesos Framework können sich Entwickler auf die Programmierung ihrer API’s oder Webinterfaces konzentrieren um diese on-demand zu provisionieren, verteilen oder ausfallsichere Systeme aufzubauen ohne sich Gedanken über die physikalische Infrastruktur zu machen.

Mesos optimiert die Verteilung auf die physikalische Ressourcen über das zusammenfügen verschiedener Workloads wie z.B. Batch Jobs und Services. Hinzu kommt, dass Mesos die Ressourcen immer effektiv verteilt um diese nicht durch Leerläufe zu verschwenden.

Die Kern-Architektur eines verteilten Systems basiert auf master und worker Nodes verbunden mit einer ebenfalls verteilten key/value Datenbank. Mesos verwendet hierbei Apache Zookeeper welche den Status des Clusters und der Workloads beinhaltet. Die Frameworks sitzen on-top auf den master nodes und schedulen die Workloads der einzelnen Prozesse.

mesos_architecture.png

Die folgenden Vorteile sehen wir im Einsatz eines Mesos Kernels:

  • Kann einen großen Ressourcen Pool unterschiedlicher Quellen erstellen (Hardware, VirtualMaschine, AWS, Azure, usw.)
  • Ist ein OpenSource Projekt, supportet und eingesetzt von den größten Firmen weltweit (Apple, eBay, twitter, Netflix, ChinaMobile, uvm)
  • Unterstützt eine grosse Anzahl von Frameworks: Marathon, ElastiSearch, Kafka, Kubernetes uvm
  • Ist ein Stable Produkt. Die API Versionen sind stabil. Features kommen in weiteren API Versionen hinzu
  • Mesos ist fuer Masse ausgelegt und kann quasi eine unendliche Anzahl an Worker Nodes verwalten
  • Das System ist hochperformant und gerade fuer IoT Backend Systeme sehr zu empfehlen
  • Mesos kann nicht nur Container (Docker, Runc, usw), sonder auch Native Software/Apps (bash, golang, python, java uvm) oder ganze Datenbanken/Engines (Elasticsearch, Cassandra, Kafka uvm.) managen

Aufbau einer möglichen Platform

Die Schlüsselkomponenten sind Mesos als Ressourcen Scheduler und Marathon für die Orchestrierung. Die Marathon API wird dabei zum deployen der Applikationen verwendet.

Die Platform bleibt immer erweiterbar. Zukünftige Container Orchestrierungen wie Kubernetes oder AI Frameworks wie TensorFlow können jederzeit und on-demand als Erweiterung hinzugefügt werden. Mesos unterstützt unterschiedliche Hardware Ressourcen. D.h. in-house Bare-Metal Server können parallel zu den Servern in AWS, Azure oder GoogleCloud verwendet werden. Dies ermöglicht die höchstmögliche Flexibilität einer hybrid Cloud Umgebung.

moegliche_mesos_platform.png

Verwendete Tools

Die Platform ist mit offenheit und größtmöglicher flexibilität designed. Produkte und Tools können jederzeit und relativ einfach ausgetauscht werden. Die Empfehlung ist; Die Tools und Produkte in Hinsicht auf die Pipeline der Entwickler aufzubauen. Für alle von gewählten Produkte existiert kommerzieller Support.

Tool Rolle Lizenz KommerziellerSupport
Marathon Container Orchestrierung Apache 2.0 Mesosphere
HA Proxy Load Balancer GPL Mesosphere / HA Proxy
Jenkins Build Server MIT CloudBees
Prometheus Time Database für das Monitoring Apache 2.0 Robust Perception
Weave net Container Networking (vxlan) Apache 2.0 Weave Works
Weave Scope Container und Netzwerk Monitoring Apache 2.0 Weave Works
Graylog Loggin Server GPL 3.0 Graylog
Grafana Dashboard und Monitoring Apache 2.0 Grafana Labs
Consul Service Discovery und interner DNS Mozilla Public License 2.0 Hashicorp
Sonartype Nexus Docker Image Repository EPL 1.0 Sonartype
Docker engine Application Container Engine Apache 2.0 Docker Inc.

Build-In Features

Der Cluster ist mit Hinblick auf Service Discovery, Load Balancing, Persistierung von Daten, zentralem Logging und einer vielzahl weiterer Komponenten designed worden. Das gesamte Konzept ermöglicht eine schnelle und kosteneffiziente lieferung von Services.

Load Balancer und interner DNS

Eingehender Netzwerktraffic zum Mesos Cluster wird über zwei oder mehr HA Proxies geleitet. Diese HA Proxies leiten ihren Verkehr zu den Marathon Load Balancer welche jeweils permanent den Marathon Event-Bus abhören um zu wissen wohin der Traffic weitergeleitet werden muss.

Intern werden die Container im Consul DNS Server registriert, so dass die Container ihre benötigten Services (z.B. weitere Container) über den DNS Namen auflösen und erreichen können.

ex-internal_lb.png

Persistente Daten

Während die Container Technology das Packetieren und verteilen von Software drastisch vereinfacht, existiert eine große Lücke bei der Persistierung von Daten. Bei vielen Microservices wird dies sicherlich keine Rolle spielen. Bei einigen um so mehr und ein Verlust der Daten durch das zerstören des Containers könnte kritische folgen haben. In diesem Fall gibt es viele Möglichkeiten Daten zu persistieren. Es ist zu Prüfen, welche Art von Daten gesichert und zur Verfügung gestellt werden muss. Hierbei ist der IO ein Massgeblicher Faktor.

Zentralles Logging

Die Logs der Applikationen und der Container sollten Zentral gesammelt und über einfache Wege ausgelesen werden. Hierbei ist zu beachten, dass auch dem Platform Operator direkt auf dem Server die Möglichkeit des Auslesens der Container Logs ermöglicht wird ohne den Umweg eines WebInterfaces zu gehen.

Monitoring

Jede Docker Engine forwarded seine Metriken zum Prometheus Server. Live Monitoring Dashboards mit Hilfe von Grafana können wichtige Metriken darstellen. Das automatische alarmieren der Überschreitung von Grenzwerten kann ebenfalls nützlich sein. Hierbei ist wichtig die Grenzwerte für jeden Bedarfsfall zu ermitteln. Beispiel; An Feiertagen sehen die Zugriffe auf Systeme anders aus als zu “normalen” Tageszeiten.

Multiple Infrastucture

Der Mesos Cluster kann in einer Cloud Umgebung (z.B. AWS oder Azure) genauso deployd werden wie unter Vagrant auf dem Rechner des Entwicklers. Dies ermöglicht einem lokale Tests durchzuführen die seitens der Infrasturktur nahe zu identisch dem des Produktiven Systems ist.

DevOps Workflow

Ein DevOps Workflow einer auf Docker basierenden Applikation könnte wie folgt aussehen.

devops_workflow.png

Der Entwickler commitet die Sourcen in ein zentrales GIT Repository. Der CI/CD (z.B. Jenkins) Server bekommt ein Webhook oder polled das Repository um den Workflow zu starten.

  1. Jenkins nutzt Mesos als Ressource Pool und startet entsprechende Slaves um das Docker Image zu bauen. Das Docker Artefact wird im Docker Repository gespeichert. Anschliessend deployed Jenkins dieses Image (blue/green) im Cluster.
  2. Der Mesos Master empfängt Jobs von Marathon (z.B. ein Docker Container) und verteilt diese auf seine Slaves.
  3. Alle Persistenten Storages müssen im Marathon JSON spezifiziert werden.
  4. Container Namen werden im Consul registriert.
  5. Der Marathon LoadBalancer erkennt anhand des Marathon Event Bus die neuen Container und richtet ein LoadBalancing zu diesen ein.
  6. Alle Logs (container und host) werden richtung Graylog, Monitoring und Prometheus geschickt.

Workloads

Im Gegensatz zu einer “opinionated platform” as a service, wo die Platform in einigen Fällen vorgibt wie die Applikation auszusehen hat, gibt unsere Lösung einem mehr Flexibilität bezüglich der Arten des Workloads. Zum einen kann die Applikation Daten persistieren und die Container Technology gibt dem Entwickler die Freiheit deren präferierte runtime zu verwenden.

Trotzdem sollte der Entwickler wie auch der Plattformbetreiber sicher gehen, dass die zu Betreibende Applikation zur den 12factors (https://12faactor.net) kompatibel ist. Nur dann ist sichergestellt, dass die Applikation sauber, ohne downtime (blue/green deployment), einfach zu skalieren und hochverfügbar ist.

Platform Operations

Infrastructure as-a-code

Um eine Microservice Platform zu betreiben, müssen viele neue Prozesse eingeführt werden. Der Entwickler wird mehr in die Verantwortung genommen werden. Der Platform Operator wird mehr automatisieren um die Platform überhaupt noch betreiben zu können. Infrastructure as-a-code gibt dem Operator die Möglichkeit seine Platform auf die Art und weise zu deployen wie es der Entwickler mit seinen Docker Containern bereits macht. Basierend auf Pipelines lässt sich so der Cluster erweitern, neue Framework installieren oder im blue/green verfahren eine komplett neue Platform aufbauen und nach dem Umzug der Container die alte Umgebung entfernen.

as-a-code.png

Die gesamte Platform Konfiguration liegt Version Controled im GIT. Als Resultat können wir jederzeit in nur wenigen Minuten eine komplett neue Cloud Platform automatisiert aufbauen. Diese Möglichkeit kann gerade im Falle eines Sicherheitsproblems sehr nützlich sein. So wäre man in der Lage, in Regelmässigen Abständen alle Master und Slave Nodes aus einem Know-State heraus neu aufzubauen.

Schlusswort

Suchen sie sich einen Partner der Ihnen bei der Konzeptionierung, dem Aufbau wie auch dem Betrieb ihrer Umgebung unterstuetzt. Gerne stehen wir ihnen dabei zur Verfuegung und freuen uns ueber eine Kontaktaufnahme.