technique:old:limites_du_cluster

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

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.

Le quorum

Le quorum est un synonyme de “majorité”. Lorsque le cluster démarre, chaque noeud du cluster se voit affecter un nombre de voies (un pouvoir de vote) qui peut differer d’une machine à une autre (dans le cas de noeud “master” et “esclave” par exemple). Pour pouvoir continuer a fonctionner, le cluster reçoit le nombre limite de votes a avoir. Si un noeud est déclaré “mort” (un problème est survenu sur cette machine, ou elle a été déconnectée), alors le cluster se divise en une ou plusieurs partitions qui se reforment en nouveaux clusters sans le/les noeuds “mort(s)”. Avant de continuer a s’executer chaque noeud va calculer le quorum, en ajoutant son pouvoir de vote a ces des noeuds voisins. Si le quorum est suffisamment élevé, le cluster peut continuer à assurer les services du cluster. Si le quorum n’est pas suffisant, alors les noeuds s’excluront mutuellement en le cluster ne fonctionnera plus.

Le split brain

Le split brain est un risque particulièrement présent dans les clusters a 2 noeuds. En effet, comme son nom l’indique, le split-brain va mener a une division en 2 du cluster. Cela se produit lorsque 2 noeuds perdent contact l’un l’autre et essayent de prendre le contrôle du cluster et des ressources partagées de façon simultanée. Chaque noeud pensera avoir le quorum et ne parviendra pas a exclure l’autre noeud. De ce fait, les deux noeuds se mettent à fonctionner indépendamment l’un l’autre, ce qui peut mener a un corruption des systèmes de stockages distribués !

Le problème de l'infrastructure

Maintenant que nous avons vu Corosync, et les notions de Quorum et de Split brain, il apparait évident que le cluster de machines formé de Alice et Bob présente clairement des risques de split brain en cas de panne. De ce fait, les avantages du clustering (haute disponibilité, flexibilité, robustesse face aux pannes etc) ne sont pas réellement perceptibles, ET, chaque noeud du cluster (ie: Alice et Bob dans le cas du cluster Proxmox) représentent un peu de faille. De ce fait, on multiplie l’apparition de problèmes par 2 sans pouvoir dégagé d’avantages clairs de notre cluster.

De plus, l’infrastructure comporte 2 clusters:

  • Proxmox
  • Docker swarm

Ce qui signifie que les erreurs liées au clustering ont 2 fois plus de chance de se produire.

Conclusion

Ainsi, utilisé un système de clustering est certainement le meilleur moyen d’assurer la robustesse d’une infrastructure. Toutefois, ceci s’applique surtout a des clusters d’au moins 3 noeuds. Les clusters de 2 noeuds (dans le cas de Picasoft en tout cas) sont trop propices aux bugs en cas de panne et cela complexifie grandement la mise en place et le déploiement des services, tout en rallongeant les temps de maintenance.

  • technique/old/limites_du_cluster.1494584862.txt.gz
  • (modification externe)