| Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente |
| technique:limites_du_cluster [2017/06/20 23:46] – antoiner | technique:old:limites_du_cluster [2021/01/08 22:58] (Version actuelle) – qduchemi |
|---|
| ===== Les limites de la première version de l'infrastructure Picasoft ===== | ===== Limites de la première infrastructure Picasoft ===== |
| |
| ==== Rappels sur l'infrastructure ==== | ==== Rappels sur l'infrastructure ==== |
| Dans le cadre de la TX du semestre de A16, une première infrastructure Picasoft a été mise en place. Cette infrastructure, comme expliqué dans les premières étapes de la documentation, est basée sur un cluster Proxmox qui permet de centraliser la gestion de plusieurs serveurs physiques. Chacune des machines virtuelles émulées sur les machines physiques (Alice et Bob) hébergent des services s’exécutant dans des conteneurs Docker. Dans le but de rendre le déploiement des services de Picasoft plus flexibles et plus robustes aux pannes, il a été décidé d'utiliser Docker Swarm. | Dans le cadre de la TX du semestre de A16, une première infrastructure Picasoft a été mise en place. Cette infrastructure, comme expliqué dans les premières étapes de la documentation, est basée sur un cluster Proxmox qui permet de centraliser la gestion de plusieurs serveurs physiques. Chacune des machines virtuelles émulées sur les machines physiques (Alice et Bob) hébergent des services s’exécutant dans des conteneurs Docker. Dans le but de rendre le déploiement des services de Picasoft plus flexibles et plus robustes aux pannes, il a été décidé d'utiliser Docker Swarm. |
| |
| Contrairement au simple "Docker", Docker Swarm permet de déployer des services (et non plus de simples conteneurs). Ces services sont en réalité des "abstractions" de conteneurs, dans le sens où ils peuvent être créée depuis n'importe quelle machine du cluster Swarm. L'utilisateur n'a pas à se soucier de l'instanciation des conteneurs, de la répartition de charge sur le cluster Swarm, ou encore du "service discovery". Tout est géré par Swarm. En résumé, il suffit de déployer un nombre X de services depuis un nœud du cluster Swarm pour que, en interne, Docker créé des conteneurs sur Y nœuds du cluster et s'occupe de faire en sorte que les nœuds exécutent un nombre équivalent de conteneurs pour éviter qu'un nœud se retrouve surchargé (exécute 100 conteneurs) alors que d'autres ne font quasiment rien (exécute 2 conteneurs). | Contrairement au simple "Docker", Docker Swarm permet de déployer des services (et non plus de simples conteneurs). Ces services sont en réalité des "abstractions" de conteneurs, dans le sens où ils peuvent être créés depuis n'importe quelle machine du cluster Swarm. L'utilisateur n'a pas à se soucier de l'instanciation des conteneurs, de la répartition de charge sur le cluster Swarm, ou encore du "service discovery". Tout est géré par Swarm. En résumé, il suffit de déployer un nombre X de services depuis un nœud du cluster Swarm pour que, en interne, Docker créé des conteneurs sur Y nœuds du cluster et s'occupe de faire en sorte que les nœuds exécutent un nombre équivalent de conteneurs pour éviter qu'un nœud se retrouve surchargé (exécute 100 conteneurs) alors que d'autres ne font quasiment rien (exécute 2 conteneurs). |
| |
| ==== Les faiblesses de l'infrastructure face aux pannes ==== | ==== Les faiblesses de l'infrastructure face aux pannes ==== |