Notre solution se base sur une application distribuée dont les instances sur les différents nœuds opèrent par des changements d’état pour assurer la continuité des services. Afin de modéliser le comportement de cette application, nous appelons P le processus de l’application sur chaque nœud. Les processus P exécutés sur les différents nœuds fonctionneront suivant des rôles. Chaque rôle est identifié par une valeur de privilège (un entier) comprise entre 0 et 4. L’attribution d’une valeur de privilège à un processus P le fait passer de son état initial à l’état de la nouvelle valeur attribuée. Nous notons Pi un processus portant le privilège i, i compris entre 0 et 4. Ces différentes valeurs confèrent aux différents processus les rôles suivants :
– Privilège 0 : correspond à l’état du processus P, noté P0, qui lui confère le rôle de supervision du nœud sur lequel il se trouve. Cet état correspond à celui d’un contrôleur de nœud simple (Node controller) dans les autres solutions (Eucalyptus, Opennebula, etc.). Tous les processus sur les différents nœuds du système démarreront à cet état.
– Privilège 1 : correspond à l’état du processus P, noté P1, élu pour assurer la supervision d’un cluster controller et d’être ainsi en état de reprendre ses services en cas de panne à son niveau.
– Privilège 2 : correspond à l’état du processus P, noté P2, lui conférant le rôle de supervision d’un ensemble de nœuds regroupés (cluster). Ce rôle correspond à celui d’un cluster controller dans les autres solutions.
– Privilège 3 : correspond à l’état du processus P, noté P3, élu pour assurer la supervision du cloud controller et d’être ainsi en état de reprendre ses services en cas de panne à son niveau. Un processus P3 correspond également à un cluster controller.
– Privilège 4 : correspond à l’état du processus P, noté P4, élu pour assurer la tâche de supervision de tous les nœuds du système. P4 équivaut au cloud controller des autres solutions. Il collectera les informations sur tous les nœuds du système par l’intermédiaire des cluster controllers (P2 et P3).
Pour modéliser le fonctionnement du système nous emploierons les diagrammes de séquence et d’état-transition du langage de modélisation UML (Unified Modelling Language). Les diagrammes de séquence permettent de montrer les interactions entre objets distants alors que les diagrammes d’état-transition donnent une vue plus détaillée du fonctionnement en local de chaque objet.
L’algorithme de fonctionnement du système se déroule en deux phases : une phase d’initialisation et une phase de supervision. Dans la présentation des deux phases de fonctionnement de notre système, nous montrerons les différents changements d’état du processus P et les différents évènements reçus ou générés. La présentation des changements d’état suit le formalisme observé à la section 4.1.2 des algorithmes distribués :
[ETAT i, EVENEMENT j]→ [ETAT (i+1), EVENEMENT (j+1)]
Ce formalisme nous permet de collecter les différents changements d’état afin de produire la machine à états du processus P. Nous noterons les différentes transitions observées par (tr) lors de la présentation du fonctionnement du système. Pendant les deux phases, nous emploierons 07 nœuds notés A, B, C, D, E, F et G pour illustrer les différents cas de figure.
5.1. Phase d’initialisation
La phase d’initialisation concerne l’enregistrement des différents nœuds du système. Cette phase permet à chaque nœud de prendre connaissance des autres nœuds du réseau. A ce niveau, il est nécessaire de choisir un nœud initial qui assurera le rôle du cloud controller (P4). Cette opération se fera en lui attribuant manuellement la valeur du privilège 4 ou en lui ajoutant un premier nœud de cluster.
Nous notons par Ea l’évènement d’ajout d’un nœud dans le système et M(i) l’évènement d’envoi de privilège i, i compris dans {0, 1, 2, 3, 4}, à un nœud du système.
Ea0 représentera l’ajout du premier nœuds au système. Eai(N) représentera l’ajout du nœud N au système contenant préalablement i+1 nœuds. Dans le cas de l’évènement Ea0, le système comporte initialement 0+1 nœuds qui est le nœud initialement choisi comme cloud controller pour les opérations d’ajout. Ce nœud se connaissant lui-même, on considère que le système comporte 1 nœud à cet instant précis. La notation CiEa représentera le même évènement Ea lorsqu’il est appliqué au contrôleur du cluster i. L’indice i d’un cluster est son ordre de création.
L’ajout d’un nœud doit se faire en précisant le cluster de ce nœud. Si le nœud est ajouté comme contrôleur d’un nouveau cluster, nous notons l’évènement d’ajout de ce nœud N, par Ea(N). Par contre si le nœud ajouté doit appartenir à un cluster existant, nous le notons Ea(N, i), avec i l’indice du cluster indiqué.
Le choix du nœud initial (Ni) se fera alors en lui ajoutant un premier nœud N par l’évènement Ea0(N) ou en lui affectant directement la valeur du privilège 4. Dans les deux cas, le nœud recevant l’évènement passera à l’état P4 et procèdera à l’enregistrement du premier nœud reçu comme le cluster controller élu pour assurer sa supervision :
Ni: [P0, Ea0(N) | M(4)] → [P4, Em + M(3)] (tr1)
N : [P0, Em + M(3)] → [P3, M(1)] (tr2)
L’évènement de mise à jour de l’état du système est noté Em. Em permet à un nœud recevant l’ajout d’un autre nœud de mettre à jour l’état du système à son niveau en local et au niveau de tous les autres nœuds s’il en a le privilège. La génération de l’évènement Em de la part du cloud controller (P4) consistera d’une part à mettre à jour sa liste locale des nœuds du système en y ajoutant le nouveau nœud reçu et d’autre part à mettre à jour la liste des nœuds au niveau de tous les autres hôtes du système par l’intermédiaire des cluster controllers (P2, P3). La génération de l’évènement Em de la part d’un contrôleur de cluster consistera, à en avertir le cloud controller (P4), à mettre à jour sa liste locale des nœuds du système et à procéder à la même opération au niveau des nœuds de son cluster. Dans le cas d’un simple contrôleur de nœud (P1, P0), Em consistera à la mise à jour de l’état local de sa liste.
En (tr1) le processus P, du nœud initial choisi, à l’état P0 reçoit une valeur de privilège 4 (M(4)), ou un premier nœud N dans sa liste (Ea0(N)). Il générera respectivement deux évènements (M(3) + Em) : l’évènement d’élection du premier nœud reçu comme cluster controller élu et l’évènement de mise à jour de l’état du système à son niveau et au niveau du nœud ajouté. S’il s’agit d’une attribution directe de privilège sans ajout du premier nœud, l’évènement M(3) consistera en une recherche périodique du premier nœud dans sa liste afin de l’élire par affectation de la valeur 3 dès qu’il sera ajouté.
En (tr2), le nœud ajouté reçoit le privilège 3 de la part du processus P4 et passe à l’état P3. Il génère l’évènement M(1) d’élection d’un nœud de supervision. Nous précisons qu’un évènement d’élection M(i) est généré de façon périodique jusqu’à la réussite de l’élection du nœud recherché. L’envoi du privilège i n’est effectué que lorsque le nœud recherché est trouvé.
Le diagramme de séquence de la figure 5.1 illustre le schéma des deux transitions (tr1) et (tr2) en considérant A comme le nœud initial choisi et B comme le premier nœud ajouté. La figure 5.2 montre le schéma du système après les opérations en (tr1) et (tr2).
Figure 5.1: Diagramme de séquence de l’ajout d’un premier nœud au système.
Figure 5.2: Schéma de l’architecture après l’ajout du premier nœud.
Une fois que le choix du cloud controller est effectué et que le premier nœud ajouté est élu comme cluster controller, l’ajout d’un nouveau nœud au système nécessitera à partir de ce moment la précision du cluster auquel il appartient. Lorsqu’il s’agit d’un nœud appartenant à un nouveau cluster, ce nœud sera élu comme le contrôleur de ce cluster (P2). Les transitions (tr3) et (tr4) illustrent ces cas de changements d’état et le diagramme de séquence de la figure 5.3 en illustre le fonctionnement avec comme nouveau nœud ajouté, le nœud C.
[P4, Eai≠0(N)] → [P4, Em + M(2)] (tr3)
N : [P0, Em + M(2)] → [P2, M(1)] (tr4)
En (tr3), le cloud controller reçoit un nouveau nœud d’un nouveau cluster (symbolisé par l’ajout du nœud N sans précision d’un indice de cluster), il procèdera à l’élection de ce nœud comme le contrôleur dudit cluster. Le processus à l’état P0 de ce nœud passe donc à l’état P2 (tr4). On obtient le schéma de la figure 5.4 de l’état du système.
Figure 5.3: Diagramme de séquence de l’ajout d’un nouveau nœud dans un nouveau cluster.
Figure 5.4: Schéma du système après l’ajout d’un second contrôleur de cluster.
Par ailleurs, si le nœud ajouté appartenait au même cluster que le nœud initialement ajouté au cloud controller par l’évènement (Ea0) lors de son initialisation, ce nœud sera élu par le contrôleur de ce cluster. Il s’agit dans ce cas de l’ajout d’un premier nœud à un cluster possédant déjà un contrôleur. Ce contrôleur élira le nouveau nœud ajouté pour se charger de sa supervision en lui attribuant le privilège 1. Les évènements et transitions d’état dans ce cas s’observent en (tr5), (tr6), (tr6’) et (tr7).
[P4, Eai(i≠0)(N, j)] → [P4, Em + CjEa0(N)] (tr5)
[P3, CjEa0(N)] → [P3, Em + M(1)] (tr6)
[P2, CjEa0(N)] → [P2, Em + M(1)] (tr6’)
N: [P0, Em + M(1)] → [P1, Em] (tr7)
En (tr5), le cloud controller reçoit l’ajout d’un nœud dans un cluster existant d’indice j (j sera 0 pour le premier cluster créé), Il génère à l’endroit du contrôleur de ce cluster l’évènement CjEa0(N) qui représente l’ajout du premier nœud N (Ea0(N)) au cluster j (Cj) possédant déjà un contrôleur. Ce cas de figure s’observera pour tous les contrôleurs de cluster (P2 et P3) dont la liste des nœuds pour ce cluster est encore vide. A la réception de cet évènement (CjEa0(N)), le contrôleur de ce cluster (P2 ou P3) procèdera à l’élection du nœud reçu (tr6, tr6’). Le nœud élu mettra à jour sa liste locale, passera à l’état P1 et démarrera la supervision du contrôleur de ce cluster (tr7). La figure 5.5 montre ce fonctionnement dans l’encadré rouge, en considérant le nœud D comme le nouveau nœud ajouté au cluster d’indice 0 supervisé par le nœud B. Le schéma illustratif du système à cette étape du processus d’initialisation se présente à la figure 5.6.
A cette étape, les processus d’élection de nœuds pour la supervision d’un contrôleur particulier (P4, P3 ou P2) sont illustrés. Les autres ajouts concernent les nœuds simples d’exécution possédant le privilège 0. Ces nœuds appartiendront à des clusters possédant déjà un nœud de contrôle pour ce cluster et un nœud élu par le privilège 1 pour assurer la supervision du contrôleur du cluster. L’ajout d’un nouveau nœud au système dans ce cas conduira à l’envoi de la configuration actuelle du système à ce nœud par l’évènement Em.
Figure 5.5: Diagramme de séquence de l’ajout d’un premier nœud à un cluster possédant déjà un contrôleur.
Figure 5.6: Schéma du système après l’ajout d’un premier nœud à un cluster possédant déjà un contrôleur.
[P4, Eai(i≠0)(N, j)] → [P4, Em + CjEak(k≠0)(N)] (tr8)
[P3, CjEak(k≠0)(N)] → [P3, Em] (tr9)
[P2, CjEak(k≠0)(N)] → [P3, Em] (tr9’)
[P0, Em] → [P0, Em] (tr10)
Eai(i≠0)(N, j) : Evènement d’ajout du nœud N au système possédant déjà i+1 nœuds. La valeur i différente de 0 indique que le nouveau nœud n’est pas celui ajouté à l’initialisation du système, qui possède déjà à cet instant un cloud controller (P4) et un cluster controller élu (P3). L’indice j représente l’indice du cluster de ce nœud.
CjEak(k≠0)(N): Evènement d’ajout du nœud N au cluster j possédant déjà k+1 nœuds. La valeur k différente de 0 indique que le nœud N n’est pas le premier nœud ajouté au cluster j, qui possède déjà à cet instant un contrôleur de cluster (P2 ou P3) et un nœud (P1) élu.
Le diagramme de séquence de la figure 5.7 illustre le fonctionnement de toute la phase d’initialisation du système. Parmi les nœuds A, B, C, D, E, F et G employés, les nœuds A, B, C, D, E concernent les cas de figure observés depuis le choix du cloud controller (P4, nœud A) et l’élection des nœuds de privilèges respectifs (P3, nœud B), (P2, nœud C). Les nœuds D et E étant les nœuds respectivement élus par les contrôleurs de cluster B et C.
Les nœuds F et G sont concernés par la transition (tr10) générée par les évènements produits aux (tr8) et (tr9). Ces deux derniers nœuds appartiennent respectivement aux clusters 0 et 1 dont les contrôleurs sont respectivement les nœuds B et C. L’encadré rouge sur le schéma de la figure 5.7 illustre le cas des nœuds E, F. Le schéma du système après la phase d’initialisation se présente à la figure 5.8.
Les différentes transitions présentes sur le diagramme de séquence de la figure 5.7 montrent que le cloud controller choisi (nœud A) ne communique qu’avec les cluster controllers (nœud B et C) ; et que les contrôleurs de cluster (B et C) ne communiquent respectivement qu’avec les nœuds D, F et G, E de leurs cluster et le cloud controller.
Figure 5.7: Diagramme de séquence à l’initialisation du système.
Figure 5.8: Schéma du système après la phase d’initialisation.
Les différents changements d’état possibles du processus P sur un nœud quelconque pendant la phase d’initialisation du système se présentent à la figure 5.9. On peut y noter les transitions débutant de l’état P0 à l’état Pi, i compris dans {1, 2, 3, 4} et la transition P2 à P3. La transition P0 à P1 concerne l’élection d’un P0 par un cluster controller P2 tandis que celle de P2 à P3 représente l’élection d’un cluster controller par le cloud controller P4.
Figure 5.9: Diagramme d’état-transition du processus P à l’initialisation.
5.2. Phase de supervision
La phase de supervision du système concerne l’exécution des tâches de supervision affectées à chaque hôte du système. Pendant cette phase, les nœuds respectivement élus par le cloud controller et les différents contrôleurs de cluster effectuent une vérification périodique de ces différents contrôleurs afin de détecter d’éventuelles pannes à leur niveau.
Pour la modélisation de cette partie de notre système, nous notons par Ep un évènement de panne dans le réseau. Ainsi Ep(P1) signifiera qu’un processus P1 est tombé en panne ou est injoignable par les autres processus du réseau. La panne d’un P4 sera perçue comme évènement Ep(P4) par le nœud de processus P3 élu pour sa supervision tandis que la panne d’un P2 ou P3 sera détectée sous forme d’évènement Ep(P2) ou Ep(P3) par un nœud de processus P1. Ces nœuds respectivement élus procèderont à des changements d’état pour la reconstitution du système.
– Panne d’un P0
La panne d’un nœud exécutant le processus P à l’état P0 entraine simplement la suppression de ce nœud de la liste de tous les nœuds du système par le contrôleur P2 ou P3 en charge de ce cluster.
[P3, Ep(P0)] → [P3, Em)] (tr11)
[P2, Ep(P0)] → [P2, Em)] (tr11’)
– Panne d’un P1
La panne d’un nœud exécutant le processus P à l’état P1 entraine l’élection d’un nouveau P1 parmi les nœuds exécutant le processus P à l’état P0 dans ce cluster.
[P3, Ep(P1)] → [P3, Em +M(1)] (tr12)
[P2, Ep(P1)] → [P2, Em + M(1)] (tr12’)
– Panne d’un P2
La panne d’un cluster controller simple (P2) entraine le passage du P1 élu à l’état de P2 et la réélection d’un nouveau P1 par le nouveau cluster controller.
Cette panne sera également détectée par le cloud controller qui procèdera aux processus de mise à jour en cas d’un cluster vide.
[P1, Ep(P2)] → [P2, Em + M(1)] (tr13)
[P4, Ep(P2)] → [P4, Em] (tr14)
– Panne d’un P3
La panne d’un cluster controller élu (P3) par le cloud controller entraine deux événements : l’élection d’un nouveau cluster controller (P2) par le cloud controller et le passage du nœud élu P1 du cluster dont le contrôleur vient de tomber en panne, de l’état P1 à P2 et l’élection d’un nouveau P1 dans le système.
[P4, Ep(P3)] → [P4, Em + M(3)] (tr15)
[P1, Ep(P3)] → [P2, Em + M(1)] (tr16)
– Panne d’un P4
La panne du cloud controller (P4) est automatiquement détectée par le processus P3 en charge de sa supervision. Le nœud P3 élu procède à un changement d’état de P3 au P4 à la réception de l’événement Ep(P4).
[P3, Ep(P4)] → [P4, Em+M(3)] (tr17)
Cependant, en quittant l’état P3 pour l’état P4, le cluster j dont le processus P3 vient de quitter la gestion ne dispose plus de contrôleur et le nœud exécutant le processus P1 ne le saura pas non plus car le changement d’état du P3 à P4 ne le rend pas injoignable. Afin de faire changer d’état au processus P1 élu dans ce cluster pour le faire passer de P1 à P2 et procéder à l’élection d’un nouveau P1, le processus P3 devenu P4 génère un évènement de panne du processus P3, qu’il était, à l’endroit du processus P1 afin de simuler un évènement de panne. Nous notons cet événement Ep*(P3). Le processus P1 recevant cet événement passe donc de l’état P1 à P2 et élit un nouveau P1 dans son cluster (tr18).
[P1, Ep*(P3)] → [P2, Em + M(1)] (tr18)
Les différents changements d’état du processus P pendant la phase de supervision du système se présentent à la figure 5.10.
Figure 5.10: Diagramme d’état-transition du processus P pendant la phase de supervision du système.
Sur la figure 5.10, deux nouvelles transitions (P1 à P2 et P3 à P4) sont ajoutées au diagramme du système comparativement au diagramme de la phase d’initialisation (Figure 5.9). Ces transitions ne sont donc possibles qu’en cas de panne d’un nœud dans le réseau. En fusionnant les deux diagrammes des figures 5.9 et 5.10, on obtient le diagramme d’état transition général du processus P (Figure 5.11).
Sur la figure 5.11, le processus P à l’état P0 peut passer de cet état à tous les autres. La transition à l’état P4 est effectuée à l’initialisation sur le nœud initial du système en lui attribuant le privilège 4 ou en lui ajoutant un premier nœud de cluster. Le passage aux autres états P1, P2 et P3 est effectué respectivement en recevant le privilège 1 de la part d’un cluster controller (P2 ou P3) recherchant un nœud P1 pour le superviser, en recevant le privilège 2 de la part du cloud controller qui l’élit comme cluster controller ou enfin en recevant le privilège 3 de la part du cloud controller pour le superviser.
Figure 5.11: Diagramme d’état-transition global du processus P.
La transition P1 à P2 est effectuée suivant la panne d’un cluster controller (P2 ou P3) dont le nœud exécutant le processus P1 était en charge de supervision. Cette transition est également causée par la génération d’une panne simulée de la part d’un P3 (Ep*(P3)) quittant cet état pour l’état P4. La transition P2 à P3 est effectuée suivant l’élection d’un cluster controller (P2) de la part du cloud controller.
La transition P3 à P4 est effectuée en cas de panne du cloud controller. Le cluster controller en charge de sa supervision passe de l’état P3 à l’état P4
Conclusion partielle
Dans ce chapitre, nous avons modélisé le fonctionnement de l’application distribuée. Ce chapitre nous permet d’avoir une représentation formelle du système à développer. Le chapitre suivant traitera de l’implémentation de notre solution et présentera les différents outils utilisés.