Que fait réellement Apache Mesos?
J'essaie de faire le tour de ma tête Apache Mesos et j'ai besoin d'éclaircissements sur quelques éléments.
Ma compréhension de Mesos est qu'il s'agit d'un exécutable qui est installé sur chaque serveur physique/VM (" node ") dans un cluster, puis fournit une Java API (en quelque sorte) qui traite chaque nœud individuel comme un pool collectif de ressources informatiques (CPU/RAM/etc) Par conséquent, pour les programmes codant par rapport à l'API Java, ils ne voient qu'un seul ensemble de ressources et n'ont pas à se soucier de savoir comment/où le code est déployé.
Donc, pour commencer, je peux me tromper fondamentalement dans ma compréhension ici (auquel cas, veuillez me corriger!). Mais si je suis sur la cible, comment l’API Java (fournie par Mesos) permet-elle aux clients Java de puiser dans ces ressources?!? donner un exemple concret de Mesos en action?
Mise à jour
Jetez un œil à mon horrible dessin ci-dessous. Si je comprends bien l'architecture Mesos, nous avons un cluster de 3 serveurs physiques (phys01, phys02 et phys03). Chacun de ces éléments physiques exécute un hôte Ubuntu (ou autre). Grâce à un hyperviseur, disons, Xen, nous pouvons exécuter 1+ machines virtuelles.
Je suis intéressé par Docker et CoreOS, donc je vais les utiliser dans cet exemple, mais je suppose que la même chose pourrait s'appliquer à d'autres configurations sans conteneur.
Donc, sur chaque VM nous avons CoreOS. L'exécution sur chaque instance CoreOS est un exécutable/serveur Mesos. Tous les nœuds Mesos d'un cluster voient tout en dessous comme un seul pool de ressources, et les artefacts peuvent être déployées arbitrairement sur le cluster Mesos et Mesos déterminera sur quelle instance CoreOS les déployer réellement.
Courir sur Mesos est un "framework Mesos" tel que Marathon ou Kubernetes. Différents conteneurs Docker sont exécutés dans Kubernetes (C1 - C4).
Cette compréhension de Mesos est-elle plus ou moins correcte?
Votre résumé est presque exact, mais il ne reflète pas l'essence de ce que représente mesos. La vision de la mésosphère, la société derrière le projet, est de créer un "système d'exploitation de centre de données" et le mésos en est le noyau par analogie avec le noyau d'un système d'exploitation normal. L'API n'est pas limitée à Java, vous pouvez utiliser C, C++, Java/Scala ou Python. Si vous avez configuré votre cluster mesos, comme vous le décrivez dans votre question et que vous souhaitez utiliser vos ressources, vous le faites généralement via un framework au lieu d'exécuter votre charge de travail directement dessus. Cela ne veut pas dire que c'est compliqué voici un tout petit exemple en Scala qui le démontre. Des cadres existent pour plusieurs systèmes de traitement de données distribués populaires tels que Apache Spark , Apache Cassandra . Il existe d'autres frameworks tels que Chronos un cron au niveau du centre de données ou Marathon qui vous permet d'exécuter des applications basées sur Docker.
Mise à jour:
Oui, mesos prendra soin du placement dans le cluster car c'est ce que fait un noyau - planification et gestion de ressources limitées. La configuration que vous avez esquissée soulève cependant plusieurs questions évidentes.
Couches sous mesos: Installer mesos sur CoreOS est possible mais lourd comme je pense. Ce n'est pas un scénario typique pour exécuter mesos - il est généralement déplacé vers la couche la plus basse possible (au-dessus d'Ubuntu dans votre cas). J'espère donc que vous avez de bonnes raisons d'exécuter CoreOS et un hyperviseur.
Couches au-dessus des mésos: Kubernetes est disponible comme cadre et la mésosphère semble y mettre beaucoup d'efforts. Il ne fait cependant aucun doute qu'il existe en partie des chevauchements en termes de fonctionnalités - en particulier en ce qui concerne la planification. Si vous souhaitez planifier des charges de travail de base basées sur des conteneurs, vous pourriez être mieux avec Marathon ou à l'avenir peut-être Aurora . Donc, ici aussi, j'espère que vous avez de bonnes raisons pour cet arrangement. Sidenote: Kubernetes est similaire à Marathon avec une approche plus large et assez opiniâtre.