Dans le cadre de la TX du semestre de A16, une première infrastructure Picasoft à été mise en place. Cette infrastructure, comme expliqué dans les première étapes de la documentation est basée sur un cluster Proxmox qui permet de centraliser la gestion de plusieurs serveurs physique. Chacune des machines virtuelles émulées sur les machines physique Alice et Bob hébergent des services s’executant dans des docker containers. Dans le but de rendre le déploiement des services de Picasoft plus flexible et, robuste aux pannes; il a été décidé, d’utiliser Docker Swarm. Contrairement au simple “docker”, docker swarm permet de deployer des services (et non plus des containers). Ces services sont en réalité des “abstractions” de containers, dans le sens ou ils permettent etre créée depuis n’importe quelle machine du cluster swarm. L’utilisateur n’a pas a se soucier de l’instanciation des containers, de la repartition de charge sur le cluster swarm, ou encore du “service discovery”. Tout est géré par swarm. En gros, il suffit de deployer un nombre X de services depuis un noeud du cluster swarm pour qu’en interne, docker créé des containers sur Y noeuds du cluster et s’occupe de faire en sorte que les noeuds exécutent un nombre a peut près egale de containers pour éviter qu’un noeud se retrouve surchargé (execute 100 containers) alors que d’autres ne fassent quasiment rien (execute 2 containers).

Oui, mais voila, alors que Swarm et proxmox semblent être des solutions idéales aux problèmes de robustesse, flexibilité, high availability etc que Picasoft peut rencontrer; il existe en réalité un problème majeur dans l’infrastructure actuelle: Le cluster ne contient que 2 noeuds ! En fait, un cluster de 2 noeuds est certainement la pire configuration imaginable pour faire du clustering, puisque que des situations de split-brain peuvent se produire et le quorum peut devenir difficilement atteignable.

Avant de regarder de plus près ces deux phénomènes qui menacent pus qu’ils n’aident l’infrastructure, parlons de Corosync.

Corosync représente la couche de communication au sein du cluster. Il est très utilisé de nos jour pour assurer la communication au sein des clusters open-source. Pour fonctionner, Corosync utilise le protocol “totem”. Ce dernier consiste a passer un token de noeud en noeud du cluster. Chaque noeud fait la même chose sequence d’instructions (envoyer des messages, approbation des anciens messages etc), avant de passer le token au noeud suivant. Ce token est propagé de proche en proche, de noeud en noeud, et cela de façon continue. Si un noeud venait ne pas envoyer son token, alors, ce dernier serait déclaré comme étant perdu, et un nouveau token serait émis et repropagé sur le cluster. En revanche, si un noeud perd son token plusieurs fois de suite, alors le noeud est déclaré “mort” au restant du cluster. Si un noeud est déclaré mort, alors le restant des noeuds du cluster forment un nouveau cluster a N-1 noeud (ils “excluent” le noeud mort du cluster). Toutefois, pour assurer le bon fonctionnement du nouveau cluster, il est nécessaire de savoir si ce nouvel ensemble de noeuds peut satisfaire la meme tache que le cluster initial. Une question se pose alors, “le nouveau cluster a-t-il une capacité calculatoire suffisante pour assurer le bon fonctionnement de l’application repartie ?”. Afin de répondre à cette question, le cluster nouvellement formé va calculé un “quorum” qui permet, en fonction du pouvoir de vote de chaque noeud, de savoir si suffisamment de voie sont présentent dans le noeud pour continuer l’execution (NB: Des noeuds du cluster peuvent être dotés de plus de voies que d’autres. Ils ont donc un pouvoir de decision plus important que le restant des noeuds du cluster). Ainsi, si le nouveau rassemble suffisamment de voies (quorum suffisamment élevé), un token est de nouveau propagé sur le cluster et l’execution peut reprendre.

Ainsi, Corosync représente la couche de communication au sein du cluster de machines. Ces machines s’échangent un token de façon perpétuelle pour s’assurer que “tout va bien”. En cas de perte répétée du token par une machine, elle est déclarée “morte” et est exclue du cluster. Le nouveau cluster calcule ce que l’on appelle un quorum pour savoir s’il possède un “pouvoir” suffisant, lui permettant d’assurer le bon fonctionnement de l’application repartie.

• Cluster a 2 noeuds
• Fonctionnement de Corosync
• Plusieurs points de failure –

  > Swarm, Proxmox --> 2 fois plus de problème tan donné qu'on a un cluster a 2 noeud

  • Galere pour garder le quorum et éviter le split brain en cas de problèmes