Dans le but d’assurer la disponibilité des services dans un environnement de cloud computing privé, nous avons proposé une solution basée sur un algorithme de supervision distribué des différents nœuds du réseau. Avant de présenter la solution dans le contexte du cloud computing, nous jugeons nécessaire de présenter le principe de fonctionnement des algorithmes de supervision distribués et la notion de système distribué.
4.1 Algorithme de supervision distribué
4.1.1. Notion de système distribué
Un système distribué est un ensemble d’entités autonomes pouvant échanger des informations à travers un réseau de communication (Chalopin et al, 2011). Selon Lavault (1993), Le modèle standard d’un système distribué S est une structure logicielle ou matérielle distribuée en un réseau point à point asynchrone(29) de processus séquentiels communicants. Les constituants du réseau sont les sites et le système de communication établi entre eux. Chaque site ou nœud du système possède une mémoire locale non partagée et au moins un processeur. L’échange d’information entre sites s’effectue uniquement par messages. Les autres caractères distinctifs d’un tel système distribué sont l’absence de toute mémoire partagée et d’horloge globale et l’absence de toute variable et état global. Les seules classes d’évènements perçues par un processus quelconque s’exécutant sur les différents sites sont les évènements produits soit par le processus lui-même de façon spontanée (par exemple l’envoi d’un message), soit des évènements causés par d’autres processus. Dans un tel système, tous les nœuds ou sites exécutent au moins un processus de S. Un des principes de l’informatique distribuée est de briser la symétrie de ces processus en octroyant à l’un d’entre eux le privilège de supervision des autres. C’est le rôle des algorithmes distribués de supervision.
4.1.2. Algorithme distribué
Selon Lavault (1993), un algorithme distribué A sur un système distribué S est la caractérisation des transitions locales à réaliser de façon séquentielle par chaque processus de S à la réception d’un message. Ce processus étant dans un état déterminé. A peut être vu comme une collection de processus qui, par échange d’information, participent à la réalisation d’un but commun tout en conservant leur autonomie. Chaque processus peut être alors défini comme une suite d’évènements, un ensemble fini d’états et un ensemble fini de transitions entre évènements ainsi schématisés :
[ETAT i, EVENEMENT j]→ [ETAT (i+1), EVENEMENT (j+1)]
Un évènement interne produit seulement un changement d’état, un évènement d’envoi de message provoque l’envoi d’un message asynchrone et un évènement de réception donne lieu à la fois à la réception de messages et la mise à jour de l’état local selon les valeurs des messages.
4.1.3. Principe d’élection dans un système distribué
Le processus d’élection dans un système distribué est caractérisé par une transformation de la configuration du système distribué S. Dans une configuration initiale du système, tous les processus actifs sont dans le même état (candidat), dans une configuration finale, un seul processus est dans un état prédéterminé (élu). Et tous les autres dans un état prédéterminé différents du précèdent (battu).
4.1.4. Caractérisation des systèmes distribués
Une première caractéristique importante d’un système distribué est le maillage du réseau de communication, c’est-à-dire l’ensemble des liaisons directes entre sites. Il s’agit en fait de maillage logique. Dans ce contexte, il est évidemment nécessaire que le réseau physique soit complètement connexe. Selon Charon (2007) les principaux maillages utilisés sont :
– Le maillage complet : tout processus peut communiquer avec les autres.
– Le maillage en anneau : tout processus possède deux voisins et il ne peut communiquer qu’avec ceux-ci.
– Le maillage en étoile : un processus en particulier peut communiquer avec tous les autres qui, réciproquement ne communiquent qu’avec le processus particulier. Ce maillage présente l’inconvénient de particulariser un site et de rendre ainsi fâcheuse une panne de ce dernier.
– Le maillage en arbre : la panne de tout processus non terminal déconnecte le système.
Les autres caractéristiques d’un système distribué sont entre autres la distribution des données et la distribution du contrôle :
– La distribution des données : afin d’assurer la reprise des services de supervision en cas de panne d’un nœud ou site, une donnée x du système doit être recopiée sur les autres sites. C’est le principe de duplication des données. L’autre principe en termes de distribution des données est le partitionnement, qui consiste à recopier sur chaque site une partie de l’information.
– La distribution du contrôle : dans un système de supervision distribué, le principe de privilège tournant permet de pallier aux problèmes de panne générale. Un site particulier possède le privilège de superviser les autres. En cas de panne de ce dernier, un autre site est immédiatement élu pour continuer les tâches de supervision des autres. Le privilège passe ainsi de site en site pour assurer la continuité des services de supervision dans le réseau.
4.2 Présentation de notre solution
Nous avons étudié les solutions de cloud privé dans la première partie et noté qu’elles sont pour la plupart constituées d’un nœud central de supervision appelé cloud controller (CLC). Le problème lié à ces solutions est l’arrêt des services livrés aux utilisateurs lors d’une panne au niveau du cloud controller. En reprenant l’architecture d’Eucalyptus qui adopte une représentation modulaire sous forme d’arbre des différents hôtes du réseau, on obtient à la figure 4.1 le schéma de l’architecture en cas de panne du nœud central du système.
Figure 4.1: Schéma de l’architecture du cloud privé : Cas de panne du nœud central de supervision.
La panne du nœud central de supervision coupe ainsi les services d’administration et de supervision disponibles au niveau du cloud controller.
Bien que les différents nœuds du réseau soient toujours fonctionnels, il est impossible d’accéder à ces derniers via les différents portails et interfaces d’administration présents au niveau du CLC. Aussi, la tâche de supervision assurée par le cloud controller est ainsi arrêtée. Le même problème s’observe partiellement en cas de panne d’un cluster controller qui priverait le cloud controller de l’accès aux informations et services disponibles au niveau des différents nœuds de ce cluster (Figure 4.2).
Figure 4.2: Schéma de l’architecture du cloud privé : cas de panne d’un cluster controller.
La solution à proposer devra introduire un fonctionnement distribué permettant à la fois la reprise des tâches et fonctions assurées par le cloud controller en cas de l’arrêt de ce dernier et aussi la possibilité de réélire un nouveau cluster controller, parmi les nœuds qu’il supervise, lorsque ce dernier tomberait en panne. Une approche de solution que nous avons trouvée à ce problème consiste à considérer le maillage en arbre des différents composants du système afin de déléguer des nœuds « fils » dont la charge consisterait à superviser les nœuds « parents » critiques du réseau que sont le cloud controller et les différents cluster controllers.
Figure 4.3: Schéma de la solution proposée.
Sur la figure 4.3 de la solution proposée, un lien logique de supervision est créé respectivement entre chaque cluster controller et un contrôleur de nœud de ce cluster, et entre un cluster controller et le cloud controller. De cette manière, une panne localisée au niveau d’un cluster controller ferait automatiquement changer d’état au node controller en charge de sa supervision pour l’état de cluster controller. De même, lorsque le cloud controller tomberait en panne, le cluster controller en charge de sa supervision prendrait automatiquement sa place par changement d’état. Ce processus enclencherait immédiatement l’élection d’un nouveau cluster controller pour la supervision du nouveau cloud controller et l’élection d’un nouveau node controller pour la supervision du nouveau cluster controller.
Au niveau du cloud controller, il est donc question de s’assurer qu’un cluster controller (CC) au moins soit élu et soit capable de reprendre les services du CLC en cas de panne de ce dernier (Figure 4.4).
Figure 4.4: Schéma d’un scénario de reprise des services par la solution proposée.
Sur la figure 4.4, le nœud A assure les fonctions de cloud controller. Il a élu parmi les différents contrôleurs de cluster du système le nœud B pour assurer sa supervision. Le cluster controller élu (nœud B) devra alors vérifier régulièrement la présence du cloud controller (nœud A) afin de s’assurer de son bon fonctionnement. En cas d’une inaccessibilité à ce dernier, le Cluster controller élu devra en conclure qu’une panne est survenue à son niveau et devra reprendre immédiatement les fonctions assurées par ce dernier et en même temps établir un nouveau lien de supervision avec un autre cluster controller (ici le nœud C).
De même si le cluster controller élu venait à s’arrêter, le cloud controller devra en élire un autre immédiatement. Sur la figure 4.5, le cloud controller (nœud A) a réélu un nouveau cluster controller (le nœud C) suite à une panne observée au niveau du cluster controller B.
Figure 4.5: Schéma d’un scénario de réélection d’un nouveau cluster controller en cas de panne d’un cluster controller prédestiné à reprendre les services du cloud controller.
Les mêmes scénarios s’observeront également au niveau des différents CCs et les différents nœuds qu’ils supervisent. La panne de tout cluster controller, y compris celui élu pour la supervision du cloud controller entraînerait la reprise des services de ce cluster controller par le node controller en charge de sa supervision et la réélection d’un nouveau CC par le CLC (en cas de panne d’un CC élu) (Figure 4.6).
Figure 4.6: Schéma d’un scénario de reprise des services d’un cluster controller par un node controller et réélection de nouveaux cluster controller et node controller.
Sur la figure 4.6, le cloud controller CLC a élu le cluster controller B pour assurer sa supervision. De même le cluster controller B a élu un contrôleur de nœud (Nœud C) pour assurer sa supervision. Une panne localisée au niveau du nœud B devra enclencher automatiquement deux évènements :
– Le passage du nœud C à l’état de cluster controller
– L’élection d’un cluster controller pour la supervision du cloud controller.
Sur le schéma de la figure 4.6, le nœud E a été élu car représentant à cet instant le seul cluster controller existant. Au cas où ce cluster controller n’existerait pas, le nœud C qui passerait nécessairement à l’état de cluster controller, suite à la panne du nœud B, sera élu par le cloud controller (Figure 4.7).
Figure 4.7: Processus d’élection d’un node controller passé à l’état de cluster controller.
Sur la figure 4.7, la panne du nœud B entraine premièrement le passage du nœud C à l’état de cluster controller et l’élection d’un nœud de supervision de sa part. A l’étape 2, le cloud controller retrouve dans le réseau un nouveau cluster controller et l’élit en tant que superviseur du cloud controller.
Par ailleurs, la panne d’un NC élu dans un cluster entraînerait l’élection d’un nouveau NC dans ce même cluster s’il en existe encore.
4.3 La réplication des données
La solution proposée et présentée à la section 4.2 vise à assurer la disponibilité des services du cloud. Dans cette solution, deux types de rôles sont passés de nœud en nœud dans le réseau. Le rôle de supervision de toute l’architecture et le rôle de supervision d’un ensemble de nœuds regroupés. La distribution de ces différents rôles nécessite la capacité des nouveaux nœuds élus à assurer convenablement les tâches et fonctions définis par ces rôles. Ainsi, un cluster controller qui passe à l’état de cloud controller devra être en mesure de livrer les services du cloud aux utilisateurs; et un node controller devenu cluster controller devra être en mesure de communiquer avec les différents nœuds de son cluster afin de renvoyer les informations au cloud controller.
Pour assurer les différents changements d’état des nœuds du système, tous les nœuds du réseau devront exécuter une même application distribuée. Cette application fonctionnera de manière à assurer la connaissance « globale » de l’état du système au niveau de chaque nœud. Les informations nécessaires et locales à chaque nœud, telles que son adresse IP et port d’écoute devront être connues de tous les autres nœuds du réseau.
De plus, chaque nœud du système devra connaître son état et connaître également celui des nœuds critiques du système que sont les contrôleurs de cluster et le contrôleur actuel du cloud.
Pour assurer la continuité des services du cloud controller par un nouveau nœud (cluster controller) élu, il est possible d’employer la migration de machines virtuelles. En effet, le cloud controller délivre les services aux utilisateurs à la fois par une interface CLI (command line interface) mais aussi à travers un portail Web. Pour la redondance de ce portail, il est possible de l’installer dans une machine virtuelle afin de rendre cette dernière mobile sur le réseau par migration. Cette machine virtuelle sera disponible au niveau du cloud controller et une copie sera exécutée par ce dernier. L’élection d’un nouveau cluster controller nécessitera donc, de la part du cloud controller, le transfert des fichiers de la machine virtuelle disponible à son niveau vers le nouveau nœud élu. De plus, le cloud controller devra au fur et à mesure de l’utilisation des services, répliquer tout changement d’informations de l’application sur le cluster controller élu. Ainsi, la reprise des services par le cluster controller consistera au lancement de la machine virtuelle et à la mise à jour des informations de l’application exécutée à son niveau.
Conclusion partielle
Dans ce chapitre, nous avons présenté la solution proposée pour le cloud privé. Nous avons montré par des figures les différents scénarios possibles de reprise de services en cas de panne d’un nœud du système.
Nous avons également noté que le système doit employer une application distribuée identique sur tous les nœuds (hôtes) du réseau. Le chapitre suivant abordera la modélisation de cette application distribuée.
29 Modèle de système distribué dans lequel il n’y a pas de synchronisation des processus s’exécutant sur le réseau. La communication entre les processus n’est liée à aucune synchronisation temporelle. Les processus repartis ignorent toute information par rapport aux dates d’arrivée des messages qu’ils reçoivent.