Wir sind derzeit dabei, die Architektur unseres neuen Apache Mesos-Cloud-Setups zu entwerfen. Ziel ist es, unsere Systeme zu vereinheitlichen, indem wir verschiedene Stacks auf dieselbe Architektur verschieben. Die Hauptarbeitslasten sind Big Data-Analysen mit Apache Spark und unsere Unternehmensinfrastruktur, einschließlich Webservern, Mailservern usw.
Die Idee ist, unsere Webdienste in Docker-Containern auszuführen, die auf einem der verfügbaren Scheduler für Mesos (Marathon/Chronos, Aurora oder Singularity) laufen. Dies wäre somit die erste Mesos-Framework-Gruppe. Daneben hätten wir das Apache Spark-Framework und mehrere Datenbank-Frameworks zur Datenspeicherung. Dies wäre die zweite Gruppe von Mesos-Frameworks. Wir werden die Einzelheiten auswählen, nachdem wir sie alle parallel zum Testen ausgeführt haben.
Wir haben jedoch Schwierigkeiten zu entscheiden, auf welcher Basis wir Mesos selbst ausführen sollen. Idealerweise möchten wir es so nah wie möglich am Metal ausführen. Wir möchten auch eine Orchestrierungslösung verwenden, um sicherzustellen, dass die Mesos- und Framework-Daemons immer ausgeführt bzw. bei einem Fehler neu gestartet werden. Die Optionen, die wir in Betracht ziehen, sind folgende:
1) Mesos und die Frameworks als Docker-Container in einem minimalen Betriebssystem ausführen. In dieser Hinsicht tendieren wir derzeit zu CoreOS und Fleet.
2) Mesos und die Frameworks direkt auf Ubuntu/Debian-Servern ausführen. Für diese Option tendieren wir zu Foreman und Puppet.
Was die Frage betrifft, versuchen wir, die Lösung zu finden, die (in der Reihenfolge ihrer Wichtigkeit):
- ist am einfachsten zu konfigurieren
- ist am einfachsten zu warten und auf dem neuesten Stand zu halten
- hat den geringsten Overhead
Wir haben bisher noch nicht mit CoreOS gearbeitet, aber es ist die Option, auf die wir uns anscheinend zubewegen. Ein großes (subjektives) Problem, das ich damit habe, ist, dass wir Mesos auf Docker-Containern ausführen und dann Docker-Container auf Mesos. Das erscheint mir „unsauber“ und falsch. Ist diese Überlegung unbegründet?
Ein ähnlicher Gedanke betrifft die Redundanz zwischen den Schichten. Um zu erklären, was ich meine: Mir wäre es am liebsten, wenn Mesos ein echtes Betriebssystem wäre, das direkt auf dem Metall läuft. Es scheint, dass man, egal welche Basis man verwendet, am Ende die gleiche beabsichtigte Funktionalität auf mehr als einer Schicht der Architektur hat (d. h. CoreOS&Fleet&SystemD == Mesos&Marathon&Chronos). Ist das unvermeidlich?
Gibt es andere gute Optionen zum Ausführen der Schicht unter Mesos, die wir unter Berücksichtigung unserer Kriterien nicht in Betracht gezogen haben?
Antwort1
Das Konfigurieren und Ausführen von Diensten unter Mesos kann ein komplexer oder einfacher Vorgang sein. Um die gewünschte Lösung zu erhalten, sollten Sie zunächst je nach Ihren Anforderungen und Zielen ein Schema der Dienste definieren, die Sie darunter ausführen möchten.
Ich betreibe ein Setup mit >70 Maschinen und einer Vielzahl verschiedener Dienste unter HAProxy für dynamischen Lastausgleich mit Mesos-DNS und Marathon, API-Gateway, Chronos, Jenkins, Docker, Collectd und Graphite, …
Nun zur Beantwortung Ihrer direkten Fragen:
- Mesos ist am einfachsten zu konfigurieren mit Ihrem"Lieblings"-Linux-Distributionmit denen Sie am besten vertraut sind.
- Am einfachsten zu warten ist wiederum die Distribution, mit der Sie am besten vertraut sind.
- In Bezug auf den Overhead ist Mesos ein Softwaresystem, das neben seinen eigenen auch zugrunde liegende Betriebssystembibliotheken und andere Softwarefunktionen nutzt. Und Mesos als Betriebssystem zu betrachten (das sowohl mit Hardware als auch mit Software funktioniert ...) ist ein völlig falsches Bild.
Meine beste Antwort für Sie ist also, Ihre bevorzugte Linux-Distribution zu verwenden und Mesos darauf zu installieren, oder wenn Sie etwas Neues lernen möchten und zwar möglichst schnell und mühelos, verwenden Sie(Open-Source) DCOSUndCoreOS.