Lors de cette session, Sam Bessalah nous a présenté Apache Mesos. Ce projet est né du besoin de gérer plus efficacement les nœuds d’un cluster. Imaginons un cluster Hadoop, un autre pour Elasticsearch, etc. Sans outil approprié cela devient compliqué et cela augmente lorsque le nombre de machines à gérer devient important. En effet comment reprendre efficacement les nœuds en cas de problèmes ?
L’initiative est née chez Google avec le projet Omega, Apache Mesos est issu de cette étude.
Qu’est ce que Mesos ?
Mesos fournit une solution aux problématiques de :
- détection des erreurs,
- distribution et du monitoring de tâches,
- gestion des ressources.
Pour simplifier, il faut voir Mesos comme un datacenter avec une seule machine. Ce dernier va agir comme une couche et interagir avec des machines physiques et virtuelles. Ces machines vont contenir des batchs, des applications Web, des systèmes de storage ou de distribution.
En terme de performance, Mesos peut gérer des miliers de nœuds.
Architecture
Voici une image représentant les différents composants :
Zookeeper permet de faire la découverte et l’élection de nœuds. Nous avons également un master et des slaves :
- Le master contient les frameworks.
- Les slaves exécutent les tâches.
Les frameworks sont des applications possédant deux composants :
- un scheduler : pour attribuer les ressources,
- un executor : pour lancer l’exécution des tâches.
Afin de faire fonctionner des outils dessus, une API (Java, Scala, Go et autres) permet de faire l’implémentation adéquate. Certains de ces outils proposent déjà des implémentations (Elasticsearch, Hadoop, etc).
Les tâches sont des conteneurs linux. Initialement basé sur les cgroups, Mesos a le support natif avec Docker depuis la version 0.20.
Reprise sur erreurs
Que se passe-t-il lorsque le master ou un slave tombe ?
Concernant le master, ce dernier possède un Registrar qui loggue toutes les informations des tâches exécutées sur les slaves. Cela permet de garder la cohérence du système lors de la reprise sur erreurs. En parallèle Zookeeper va se charger de faire une réélection des nœuds masters et reprendre les tâches en cours.
Pour la reprise sur erreur des slaves, les tâches exécutées sont continuellement sauvegardées sur les disques locaux par le biais de checkpoints. Plus précisément ce sont les informations concernant les tâches (status, mises à jour, etc)
Executer des applications
A la base Mesos était prévu pour faire tourner des jobs Hadoop ou Spark, mais le besoin d’exécuter des applications plus classiques est arrivé. De cela sont nés des outils comme Marathon ou Aurora.
Sam nous conseille Marathon car les features sont actuellement plus avancées. Le principe est d’avoir un framework générique Mesos afin de faire tourner les applications. Ce dernier permet d’utiliser un init.d distribué pour les clusters. Cela a l’avantage d’exécuter des binaires linux (Tomcat par exemple) et de superviser les clusters.
Marathon est en réalité un PAAS privé offrant les services suivants :
- La découverte de services,
- Une API Rest pour les déploiements d’applications (une interface graphique est disponible),
- Un système d’authentification et du SSL,
- Du load balancing basé sur HAProxy.
Sam a terminé sa présentation en nous présentant Mesosphere qui fournit l’infrastructure nécessaire à la mise en place de Mesos avec un ensemble d’outils pré-configurés. Il a également évoqué le projet Kubernetes qui permet lui aussi d’organiser et de gérer des conteneurs Docker dans un cluster.