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 Apache Mesos 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.

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 und denen Ressourcen wie IP, RAM, CPU und Storage zuweisen. Diese tragen nicht mehr die Last eines Images mit sich herum sind aber genauso gut isoliert vom Hostsystem wie ein Container.

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.

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.

Selbstverständlich können auch wir zu all den Komponenten Support anbieten.

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.

Alle MesosTasks welche eine WeaveIP zugewiesen bekommen, werden im Weave DNS registriert, so dass dies ihre benötigten Services (z.B. weitere Container/MesosTasks) über den DNS Namen auflösen und erreichen können. Sollten MesosTasks/Container keine eigene IP zugewiesen werden da diese im Host Mode betrieben werden, werden diese im Mesos DNS registriert. Durch den Einsatz von DNSMasq ist die Namensauflösung Transparent.

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.

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 die Application zu bauen. Anschliessend deployed Jenkins dieses im blue/green im Mesos Cluster.
2. Der Mesos Master empfängt Jobs von Marathon und verteilt diese auf seine Slaves.
3. Alle Persistenten Storages müssen im Marathon JSON spezifiziert werden.
4. Der Container/MesosTask Name werden im WeaveDNS und MesosDNS registriert.
5. Der Marathon LoadBalancer erkennt anhand des Marathon Event Bus die neue Application und richtet ein LoadBalancing zu diesen ein.
6. Alle Logs 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. Gleichzeitig gibt einem Mesos die Möglichkeit die Application Containerless zu entwickeln um diese noch schneller und effizienter zu betreiben.

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.

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.