7.1. Simulation
L’implémentation de notre solution a consisté à développer deux applications : un programme en java représentant le processus P à 5 états et une application Web pour le déploiement des services IaaS. Afin de montrer les performances de notre solution et sa capacité à tolérer les pannes dans un environnement de cloud privé IaaS, nous l’avons déployée sur un ensemble de trois machines physiques reliées dans un réseau local LAN (Local Area Network). Ces trois machines physiques représentent les hôtes du réseau et ont été configurées pour tourner l’hyperviseur Xen (Annexe A). Le tableau 7.1 présente les configurations matérielles et logicielles des hôtes du réseau. La figure 7.1 montre l’exécution de l’application sur ces trois hôtes.
Tableau 7.1 : Les machines physiques employées pour la simulation.
Figure 7.1: Exécution de l’application distribuée sur trois machines physiques.
Une fois que le programme est démarré sur les différents hôtes, nous avons choisi comme nœud initial le nœud node0 d’adresse IP 10.10.10.22. Cet hôte nous a servi à ajouter les deux autres à l’aide de la commande add node. Ainsi, l’ajout des deux nœuds sous forme de contrôleurs de cluster a été effectué par les commandes add node 10.10.10.23 8082 et add node 10.10.10.24 8082. La figure 7.2 présente le processus d’ajout de ces nœuds et le fonctionnement du programme.
On peut observer que le nœud initial (node0) s’est octroyé le privilège 4 tandis que le premier nœud (node1) ajouté a reçu le privilège 3. Le troisième nœud du réseau (second nœud ajouté, node2) obtient le privilège 2. Il est alors possible d’administrer tout le système par l’interface CLI du nœud node0 qui permet dès lors d’obtenir la liste de tous les hôtes du réseau par la commande node list, la liste des machines virtuelles disponibles sur le réseau et sur chaque hôte par la commande vm list.
Figure 7.2: Ajout des nœuds au système par l’interface CLI.
Le système offre également la possibilité de migrer des machines virtuelles d’un nœud à un autre par la commande vm migrate. Il permet respectivement le démarrage et l’arrêt d’une machine virtuelle sur le réseau par les commandes vm launchet vm stop. Sur la figure 7.3 on peut observer que la machine virtuelle testvm1 (ID =2) est passée de l’état null (éteint) à l’état idle (allumé) suite à la commande vmlaunch 2. De même, son état est passé de l’état idle à null suite à la commande vm stop 2.
Figure 7.3: Gestion des machines virtuelles du système par l’interface CLI.
Pour la mise en oeuvre des services IaaS à l’aide de notre solution, il est possible d’ajouter des utilisateurs au système par la commande add user. L’attribution d’une machine virtuelle à un utilisateur est effectuée par la commande add user vm.
L’utilisateur peut alors accéder à cette machine par l’interface Web proposée (Figure 7.4). Il est également possible d’accéder aux différents hôtes du système par l’interface Web. L’accès à une machine virtuelle ou à un hôte du système nécessite une authentification par mot de passe. Le mot de passe pour l’accès VNC doit préalablement être configuré par l’administrateur du système (Figure 7.5).
Figure 7.4: Accès au portail Web.
Figure 7.5: Accès aux machines virtuelles via le portail Web développé
Figure 7.6: Authentification pour l’accès VNC aux hôtes ou machines virtuelles du système.
Toutes les opérations d’administration du système peuvent également se faire via cette même interface Web. Les figures 7.7 et 7.8 et 7.9 présentent quelques fonctionnalités du système par l’intermédiaire de notre plateforme Web.
Figure 7.7: Configuration du système via l’interface Web.
Figure 7.8: Ajout d’un hôte au système par l’interface Web.
Figure 7.9: Caractéristiques d’un hôte du système.
Pour tester la capacité de la solution à assurer la continuité des services IaaS en cas de panne d’un nœud quelconque du réseau, nous avons exécuté l’application Web dans une machine virtuelle (ns.com) que nous avons déployée sur le nœud node0. Le tableau 7.2 présente les configurations de cette machine virtuelle.
Tableau 7.2 : Configuration de la machine virtuelle « ns.com ».
A la réception des paramètres de cette machine virtuelle par le CLC (node0), renseignés par la commande define ns vm paramsou par l’intermédiaire du portail Web (Figure 7.10), il l’a automatiquement répliquée sur le nœud élu (node1) (Figure 7.11). En arrêtant la machine ns.com sur le nœud node0, elle est automatiquement redémarrée par ce dernier. Lorsque nous avons ensuite retiré l’hôte node0 du réseau en débranchant son câble réseau du commutateur Ethernet (switch) utilisé, le nœud node1, élu, ne pouvant plus joindre le cloud controller (node0), en a déduit que ce dernier est tombé en panne et a procédé respectivement à un changement d’état (en s’attribuant le privilège 4), à l’élection du nœud node2 (en lui envoyant le privilège 3 suivi d’une copie de la machine virtuelle ns.com) et enfin au démarrage de la machine virtuelle ns.com disponible à son niveau. Sur la figure 7.12, on peut observer que la machine virtuelle ns.com est allumée sur le nouveau cloud controller node1 du réseau. Les données du système (nombre de machines disponibles, nombre d’utilisateurs, nombre de machines virtuelles possédées par chaque utilisateur) sont ensuite fournies à l’application Web hébergée par la machine virtuelle ns.com afin de d’assurer la reprise correcte des services. On peut également noter sur la figure 7.12, l’affichage du nœud node0 en panne qui a été automatiquement enregistré par le nouveau CLC avant son passage à l’état P4. Le système comporte ainsi deux nœuds dans le réseau. En retirant le nouveau CLC node1 du réseau, le même scénario s’observe. Le seul nœud restant dans le système devient le cloud controller et le nombre de nœuds en panne dans le réseau passe à deux (Figure 7.13). Le portail Web du système est resté joignable pendant tout le processus du test. La connexion au portail Web est cependant réinitialisée à chaque reprise des services par un nouveau CLC.
Figure 7.10: Renseignement des paramètres de la machine virtuelle ns.com au CLC.
Figure 7.11: Réplication de la machine virtuelle ns.com sur le CC élu.
Figure 7.12: Reprise des services par le CC élu.
Figure 7.13: Reprise des services par le CC restant dans le réseau.
Une autre possibilité pour la disponibilité des services au niveau du système consiste à employer un serveur physique pour l’hébergement de l’application Web. Dans ce cas, seules les informations telles que l’adresse IP et le port d’écoute de ce serveur seront répliquées sur le nouveau CC élu de façon à permettre à ce dernier la possibilité de lui renvoyer les informations du réseau dès sa reprise des services du CLC. La commande define ns host paramspermet de renseigner les paramètres de ce serveur au cloud controller. Nous avons employé ce mode pour tester le fonctionnement complet de notre algorithme en utilisant 07 machines de tests dont 02 physiques et 05 virtuelles (Tableau 7.3). Ces machines ont été enregistrées comme les hôtes du système indépendamment de leur nature physique ou virtuelle. L’hôte node0 est employé comme le CLC du réseau. Nous avons ensuite enregistré les machines node1 et testvm5 comme les deux CCs du réseau. Les nœuds testvm1 et testvm2 sont enregistrés comme les NCs du cluster 0 et les nœuds testvm3 et testvm4 comme les NCs du cluster 1. La figure 7.14 montre ces différentes machines sur la plateforme Web avec leurs valeurs respectives de privilège. Lorsque nous avons arrêté la machine testvm1 élue par le CC0 (node1) (Figure 7.15), l’hôte testvm2 a été élu en recevant le privilège 1 de la part de son CC. En arrêtant le CC1 (testvm5) du second cluster, le nœud testvm3 a procédé à un changement d’état pour celui d’un cluster controller (Figure 7.16).
Tableau 7.3: Liste des hôtes le test de l’algorithme proposé.
Figure 7.14: Affichage des 07 hôtes de test sur la plateforme Web
Figure 7.15: Arrêt de la machine testvm1
Figure 7.16: Changement d’état de testvm3 à l’état de CC.
7.2. Discussion
Le développement de notre système et les tests effectués ont confirmé sa capacité à assurer la continuité des services dans un environnement de cloud privé. En termes de fonctionnalités, la solution permet de gérer un ensemble de machines physiques et virtuelles à travers une interface d’administration CLI mais aussi à travers un portail Web qui offre une utilisation beaucoup plus flexible du système. La solution permet également la création des comptes utilisateurs avec la possibilité de leur affecter des machines virtuelles. Elle est compatible avec la solution de virtualisation Xen et permet le déploiement, le démarrage et l’arrêt des machines virtuelles créées.
Pour assurer la disponibilité des services, notre solution utilise la migration de machine virtuelle qui lui permet de répliquer sur le nouveau CC élu, le serveur hébergeant l’application livrée aux utilisateurs, en employant le protocole de transfert de données SSH par la méthode d’échange de clés publiques RSA. Cette technique de migration de machine est employée dans la solution de cloud privé OpenNebula pour permettre le déploiement de machines virtuelles sur un ensemble d’hôtes distants. L’emploi de la virtualisation pour assurer la disponibilité des services au niveau du cloud controller nécessite cependant que tous les hôtes du réseau soient configurés pour exécuter l’hyperviseur Xen. De plus, il est nécessaire qu’un espace disque minimum pour accueillir cette machine virtuelle soit disponible au niveau de tous les hôtes du réseau.
Une autre possibilité offerte par notre solution pour la disponibilité des services consiste à employer un serveur physique pour l’hébergement de l’application Web. Ce mode offre la possibilité d’isoler le serveur Web du système de supervision du cloud. Cependant, il présente dans le réseau un unique point de défaillance qui pourrait bloquer les services en cas de panne de ce serveur.
La particularité de notre système par rapport aux autres solutions dans le domaine du cloud privé pour l’implémentation des services IaaS, réside dans l’algorithme distribué de supervision utilisé. Cet algorithme permet à notre système de résister à une interruption générale des services en permettant, en cas de panne d’un hôte du réseau, une auto-configuration dynamique du système pour assurer la continuité des services. Une approche similaire a été proposée par Naing (2012) mais dont la solution reste limitée à l’architecture d’Eucalyptus. En effet les différents composants d’Eucalyptus sont originellement conçus pour une architecture centralisée de supervision. Ainsi, la technique d’élection et de reconfiguration du système proposée par Naing (2012) ne gère que les différents CCs du réseau.
Par conséquent, elle n’aborde pas la question de la disponibilité des services au niveau du cloud controller. Ainsi, l’arrêt du cloud controller entraînera toujours une rupture des services dans son système. De même l’arrêt du dernier CC élu CCM bloquera l’évolution de l’algorithme d’élection utilisé.
Notre système représente une solution à part entière dans le domaine du cloud computing privé afin de permettre un rapide déploiement des services. Bien qu’étant très jeune dans le domaine du cloud privé, il intègre originellement le support de la tolérance aux pannes et celui de la disponibilité des services. L’algorithme employé dans notre solution se base sur une représentation en arbre des différents hôtes du réseau et permet la supervision des nœuds critiques par ceux élus en employant le protocole XML RPC pour la communication. Ce protocole permet à chaque nouveau nœud élu d’invoquer périodiquement au niveau des nœuds parents une méthode qui renvoie l’état de ces derniers. Pour optimiser cet algorithme, il est possible d’employer le principe de rendez-vous utilisé dans les systèmes distribués en utilisant une variable commune protégée par des mutex(35) et possédant une valeur initiale qui serait modifiée à chaque intervalle de temps qu’un nœud parent communiquerait avec les nœuds fils du réseau et dont l’ état serait à chaque fois remise à l’initial par le nœud fils. Ainsi, une absence de modification de cette variable pendant une période de temps donnée permettrait d’en déduire l’absence du nœud parent dans le réseau.
Ce principe permettrait de réduire le nombre de messages échangés entre un nœud élu et son parent. Par ailleurs, l’élection d’un nœud dans le système, pendant la phase d’initialisation, est basée sur le principe « FIFE » (First in First Elected) par analogie au principe FIFO (First In First Out) : le cloud controller élit le premier cluster controller reçu tandis que chaque contrôleur de cluster élit le premier node controller reçu. Pour optimiser ce fonctionnement, il est possible d’introduire un système permettant le changement d’élu après réception d’autres CCs, par le cloud controller, ou d’autres NCs, par les différents CCs, en se basant sur les performances des nouveaux nœuds ajoutés.
35 Un mutex est une primitive de synchronisation utilisée en programmation informatique pour éviter que des ressources partagées d’un système ne soient utilisées en même temps.