technique:old:limites_du_cluster

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

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] antoinertechnique:old:limites_du_cluster [2021/01/08 22:58] (Version actuelle) qduchemi
Ligne 1: Ligne 1:
-===== 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 ====
Ligne 5: Ligne 5:
 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 ====
Ligne 20: Ligne 20:
 Pour fonctionner, Corosync utilise le protocole "totem". Ce dernier consiste à passer un token de nœud en nœud du cluster. Chaque nœud fait la même séquence d'instructions (envoyer des messages, approbation des anciens messages etc), avant de passer le token au nœud suivant. Ce token (ou jeton) est propagé de proche en proche, de nœud en nœud, et cela de façon continue. Si un nœud venait à ne pas envoyer son token, alors, ce dernier serait déclaré comme étant perdu, et un nouveau token serait émis et re-propagé sur le cluster. En revanche, si un nœud perd son token plusieurs fois de suite, alors le nœud est déclaré "mort" au restant du cluster. Pour fonctionner, Corosync utilise le protocole "totem". Ce dernier consiste à passer un token de nœud en nœud du cluster. Chaque nœud fait la même séquence d'instructions (envoyer des messages, approbation des anciens messages etc), avant de passer le token au nœud suivant. Ce token (ou jeton) est propagé de proche en proche, de nœud en nœud, et cela de façon continue. Si un nœud venait à ne pas envoyer son token, alors, ce dernier serait déclaré comme étant perdu, et un nouveau token serait émis et re-propagé sur le cluster. En revanche, si un nœud perd son token plusieurs fois de suite, alors le nœud est déclaré "mort" au restant du cluster.
  
-Si un nœud est déclaré mort, alors le restant des nœuds du cluster forment un nouveau cluster à N-1 nœuds (ils "excluent" le nœud mort du cluster). Toutefois, pour assurer le bon fonctionnement du nouveau cluster, il est nécessaire de savoir si ce nouvel ensemble de nœuds peut satisfaire la même tâche 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 répartie ?". Afin de répondre à cette question, le cluster nouvellement formé va calculer un "quorum" qui permet, en fonction du pouvoir de vote de chaque nœud, de savoir si suffisamment de voie sont présentes dans le cluster pour continuer l’exécution (NB: Des nœuds du cluster peuvent être dotés de plus de voix que d'autres. Ils ont donc un pouvoir de décision plus important que le restant des nœuds du cluster). Ainsi, si le nouveau cluster rassemble suffisamment de voix (quorum suffisamment élevé), un token est de nouveau propagé sur le cluster et l’exécution peut reprendre.+Si un nœud est déclaré mort, alors le restant des nœuds du cluster forment un nouveau cluster à N-1 nœuds (ils "excluent" le nœud mort du cluster). Toutefois, pour assurer le bon fonctionnement du nouveau cluster, il est nécessaire de savoir si ce nouvel ensemble de nœuds peut satisfaire la même tâche 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 répartie ?". Afin de répondre à cette question, le cluster nouvellement formé va calculer un "quorum" qui permet, en fonction du pouvoir de vote de chaque nœud, de savoir si suffisamment de voix sont présentes dans le cluster pour continuer l’exécution (NB: Des nœuds du cluster peuvent être dotés de plus de voix que d'autres. Ils ont donc un pouvoir de décision plus important que le restant des nœuds du cluster). Ainsi, si le nouveau cluster rassemble suffisamment de voix (quorum suffisamment élevé), un token est de nouveau propagé sur le cluster et l’exécution 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. 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.
  • technique/old/limites_du_cluster.1497995174.txt.gz
  • (modification externe)