Beste Grundlage für die Bereitstellung von Mesos

Wir sind derzeit dabei, die Architektur unseres neuen Apache Mesos Cloud-Setups zu entwerfen. Ziel ist es, unsere Systeme zu vereinheitlichen, indem verschiedene Stapel auf dieselbe Architektur verschoben werden. Die Hauptarbeitslasten sind Big-Data-Analysen mit Apache Spark und unserer Unternehmensinfrastruktur, einschließlich Webservern, Mailservern usw.

Die Idee ist, unsere Webdienste in Docker-Containern auszuführen, die auf einem der verfügbaren Planer für Mesos (Marathon / Chronos, Aurora oder Singularity) ausgeführt werden. Dies wäre somit die erste Mesos-Rahmengruppe. Daneben hätten wir das Apache Spark-Framework und mehrere Datenbank-Frameworks für die Datenspeicherung. Dies wäre die zweite Gruppe von Mesos-Frameworks. Wir werden die Details auswählen, nachdem wir sie alle parallel zum Testen ausgeführt haben.

Wir haben jedoch Schwierigkeiten zu entscheiden, auf welcher Grundlage Mesos selbst betrieben werden soll. Idealerweise möchten wir es so nah wie möglich am Metall laufen lassen. Wir möchten auch eine Orchestrierungslösung verwenden, um sicherzustellen, dass die Mesos & Framework-Daemons bei einem Fehler immer ausgeführt / neu gestartet werden. Folgende Optionen werden in Betracht gezogen:

1) Ausführen von Mesos und den Frameworks als Docker-Container in einem minimalen Betriebssystem. In dieser Hinsicht neigen wir derzeit zu CoreOS und Fleet.

2) Ausführen von Mesos und den Frameworks direkt auf Ubuntu / Debian-Servern. Für diese Option neigen wir zu Foreman und Puppet.

In Bezug auf die Frage suchen wir nach einer Lösung, die in der Reihenfolge ihrer Wichtigkeit:

• ist am wenigsten komplex zu konfigurieren
• ist am einfachsten zu warten und auf dem neuesten Stand zu halten
• hat den geringsten Overhead

Wir haben noch nie mit CoreOS gearbeitet, aber es ist die Option, auf die wir zuzugehen scheinen. Ein großes (subjektives) Problem, das ich dabei habe, ist, dass wir Mesos auf Docker-Containern und dann Docker-Container auf Mesos ausführen. Das scheint mir "unrein" und falsch zu sein. Ist diese Überlegung unbegründet?

Ein ähnlicher Gedanke betrifft die Redundanz zwischen Schichten. Um zu erklären, woher ich komme, würde ich es vorziehen, wenn Mesos ein tatsächliches Betriebssystem wäre, das direkt auf dem Metall läuft. Unabhängig davon, auf welcher Grundlage Sie arbeiten, erhalten Sie auf mehr als einer Ebene der Architektur (dh CoreOS & Fleet & SystemD == Mesos & Marathon & Chronos) dieselbe beabsichtigte Funktionalität. Ist das unvermeidlich?

Gibt es andere gute Optionen, um die Ebene unter Mesos auszuführen, die wir unter Berücksichtigung unserer Kriterien nicht berücksichtigt haben?

Das Konfigurieren und Ausführen von Diensten unter Mesos kann ein komplexer oder einfacher Vorgang sein. Sie sollten zunächst ein Schema von Diensten definieren, die Sie unter Mesos ausführen möchten, abhängig von Ihren Anforderungen und Zielen, um die gewünschte Lösung zu erhalten.

Ich verwende unter HAProxy ein Setup von> 70 Computern und eine Vielzahl verschiedener Dienste für den dynamischen Lastausgleich mit Mesos-DNS und Marathon, API-Gateway, Chronos, Jenkins, Docker, Collectd und Graphite, ...

Um nun Ihre direkten Fragen zu beantworten:

• Die Konfiguration von Mesos ist am wenigsten komplex mit Ihrer "bevorzugten" Linux-Distribution , mit der Sie am besten vertraut sind.
• Am einfachsten zu warten ist wieder die Distribution, mit der Sie am besten vertraut sind.
• In Bezug auf den Overhead ist Mesos ein Softwaresystem, das neben seinen eigenen zugrunde liegenden Betriebssystembibliotheken und anderen Softwarefunktionen auch Mesos als Betriebssystem verwendet (sowohl mit Hardware als auch mit Software ...). Dies ist ein völlig falsches Bild.

Meine beste Antwort für Sie ist also, Ihre Lieblings-Linux-Distribution zu verwenden und Mesos einzuschalten. Wenn Sie etwas Neues und möglicherweise schnelles und müheloses lernen möchten, verwenden Sie (Open-Source-) DCOS und CoreOS .