Apache Mesos
Présentation
Sujet : Apache Mesos
Enseignants : D. Donsez, GP. Bonneau
Auteur : Alan DAMOTTE
Résumé
Abstract
Synthèse
Qu'est-ce que Apache Mesos ?
Mesos est ce qu'on appelle un système de gestion de cluster. C'est plus précisément une solution pensée pour mettre en place et optimiser des systèmes distribués. Mesos va permettre de gérer et partager de manière fine, souple et dynamique des ressources entre différents clusters, pour diverses applications. La solution est relativement récente mais est déjà en production dans des nombreuses entreprises. Parmi celles-ci on peut citer Twitter, Airbnb, ou encore eBay.
Mesos fournit une solution aux problématiques de :
- détection des erreurs,
- distribution et du monitoring de tâches,
- gestion des ressources.
En terme de performance, Mesos peut gérer des miliers de nœuds.
Mesos : A quoi ça sert ?
En permettant d'isoler et partager des ressources, Apache Mesos convient particulièrement bien pour exécuter des applications et des systèmes distribués. Apache Mesos est donc notamment utilisé pour faire tourner Hadoop, Spark, Storm, Kafka, ou Elastic Search. Concrètement, Mesos permet d'exécuter plusieurs systèmes distribués sur le même cluster : par exemple plutôt que de faire tourner un cluster pour Hadoop, et un autre pour Storm, un même cluster pourrait faire tourner les deux grâce au mécanisme de gestion de ressources de Mesos.
Les concurrents
Mesos ouvre globalement la voie à une meilleure optimisation de la gestion des ressources. Ce qui ne laisse évidemment pas indifférents les responsables informatiques, surtout ceux qui se sont lancés dans les systèmes distribués. Parmi les principaux concurrents d'Apache Mesos, on retrouve Omega/Borg, CoreOS et Kubernetes.
Mesos vs CoreOS
Apache Mesos et CoreOS remplissent des fonctionnalités équivalentes : ils permettent de manager un pool de ressources (serveurs) pour exécuter des tâches dessus de manière à voir ce pool comme si il s’agissait d’un serveur unique. On peut voir Mesos ou CoreOS comme des OS distribués.
On trouve donc des équivalences avec les OS (Linux) classiques :
- Le init system (distribué)
- Marathon pour Mesos
- Fleet (basé sur systemd & etcd) pour CoreOS
- Le scheduler/cron (distribué)
- Chronos pour Mesos
- La fonctionnalité Timer units de systemd pour CoreOS
Mesos vs Kubernetes
Avec Kubernetes seul, vous aurez quelque chose qui est simple , facile à déployer, portable et extensible. Vous pouvez alors exécuter une application sur un cluster, et cesser de vous préoccuper d'une machine individuelle. Dans ce cas , le cluster est une ressource flexible comme une VM.
Maintenant que les ressources sont à disposition, il faut exécuter les tâches ou plus précisément mettre à disposition les services. On peut dire que Kubernetes prend en charge « une couche au dessus » de CoreOS et de Mesos. Ces services vont s’exécuter dans des containers Docker.
A noter une différence entre CoreOS et Mesos : CoreOS est (à l’heure actuelle) concentré sur l’exécution de containers Docker, alors que Mesos permet à plusieurs frameworks (voire plusieurs « copies » du même framework), comme Hadoop, Spark, … et depuis peu Kubernetes, de s’exécuter dans un même cluster « côte à côte ». Mesos est donc plus modulaire.
Comment ça marche ?
Mesos est parfois comparé à la virtualisation, mais en plus efficace... Car, un peu comme la virtualisation, Mesos facilite "l'abstraction du CPU, de la mémoire, du stockage et autres ressources de calcul des machines, qu'elles soient physiques ou virtuelles". Il permet ainsi de bâtir "facilement et efficacement des systèmes distribués et élastiques", comme l'explique le site officiel du projet.
Dans ce contexte, Mesos peut permettre de mettre en place des planificateurs ("schedulers") de ressources personnalisées, offrant une gestion fine de la planification multi-ressources (mémoire et CPU). Les containers Docker sont aussi supportés. Une interface web permet de voir l'état du cluster. Testée en production, la capacité de dimensionnement de Mesos pourrait prendre en charge des milliers 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).
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)
Exécuter 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.
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.
Exemple d'implémentation - Comment déployer un cluster Mesos avec Docker
Prérequis
- Docker installé sur sa machine / son serveur : http://docs.docker.com/linux/started/
Manipulation
- Récupérer l'adresse IP du serveur. Pour obtenir cette adresse, faire un ifconfig et récupérer l'adresse IP de l'interface eth0.
Si elle n'existe pas, lui attribuer une adresse avec la commande : ifconfig eth0 192.168.1.12
Ensuite root@docker-server:/# HOST_IP=192.168.1.12
- Démarrer le conteneur Zookeeper
docker run -d \
-p 2181:2181 \
-p 2888:2888 \
-p 3888:3888 \
garland/zookeeper
- Démarrer le Mesos Master
docker run --net="host" \
-p 5050:5050 \
-e "MESOS_HOSTNAME=${HOST_IP}" \
-e "MESOS_IP=${HOST_IP}" \
-e "MESOS_ZK=zk://${HOST_IP}:2181/mesos" \
-e "MESOS_PORT=5050" \
-e "MESOS_LOG_DIR=/var/log/mesos" \
-e "MESOS_QUORUM=1" \
-e "MESOS_REGISTRY=in_memory" \
-e "MESOS_WORK_DIR=/var/lib/mesos" \
-d \
garland/mesosphere-docker-mesos-master
- Démarrer Marathon
docker run \
-d \
-p 8080:8080 \
garland/mesosphere-docker-marathon --master zk://${HOST_IP}:2181/mesos --zk zk://${HOST_IP}:2181/marathon
- Démarrer le Mesos Slave
docker run -d \
--name mesos_slave_1 \
--entrypoint="mesos-slave" \
-e "MESOS_MASTER=zk://${HOST_IP}:2181/mesos" \
-e "MESOS_LOG_DIR=/var/log/mesos" \
-e "MESOS_LOGGING_LEVEL=INFO" \
garland/mesosphere-docker-mesos-master:latest
- Vérifier que les conteneurs sont bien lancés avec la commande docker ps
- Aller sur la page de Mesos
Vous pouvez voir les différentes tâches exécutées et/ou actives. Pour le moment, vous ne devriez en avoir aucune, c'est normal.
- Aller sur la page de Marathon
Cliquer sur le bouton "New App" et créer une nouvelle tâche comme ceci :
- Retourner sur la page de Mesos et vérifier que la tâche est bien en exécution. Vous pouvez également taper cette commande sur le serveur :
docker exec -it mesos_slave_1 /bin/bash
root@ca83bf0ea76a:/# tail -f /tmp/output.txt
La première vous permettra de rentrer à l'intérieur du conteneur, la seconde vérifiera que le fichier output.txt est bien rempli.
Conclusion
Références
http://mesos.apache.org/ Apache Mesos abstracts CPU, memory, storage, and other compute resources away from machines (physical or virtual), enabling fault-tolerant and elastic distributed systems to easily be built and run effectively.