Institut numerique

Chapitre 6 : Choix techniques

Notre solution représente un nouveau système pour le cloud privé. Elle vise à intégrer le support de la tolérance aux pannes afin d’assurer la continuité des services en cas d’arrêt d’un nœud quelconque du réseau. Pour la réalisation de cette solution, nos choix ont porté sur la méthode de communication entre les différents nœuds du système, la solution de virtualisation employée, le langage de programmation de l’application distribuée.

6.1. Méthode de communication

Pour assurer la communication entre les différents composants de notre système, nous avons choisi d’employer le protocole XML-RPC. C’est un standard de communication entre applications distribuées qui offre une abstraction de l’hétérogénéité des composants du système. Une implémentation open source de ce protocole est proposée en java par Apache software Fondation (2010) sous le paquetage du nom org.apache.xmlrpc. Ce paquetage fournit plusieurs classes pour l’implémentation d’un système distribué. Les classes indispensables sont XmlrpcServer et XmlrpcClient.

La classe Xmlrpcserver représente un serveur XML-RPC qui peut être utilisé avec un serveur Web existant tel que Tomcat ou Jetty ou avec un serveur Web minimal du nom de WebServer fourni sous forme d’une classe en java et faisant partir du même paquetage org.apache.xmlrpc. Elle permet de publier les méthodes à mettre à la disposition des nœuds distants par l’intermédiaire d’une classe nommée PropertyHandlerMapping. Nous avons employé la classe WebServer pour implémenter le côté serveur de notre application (voir Annexe D).

La classe XmlrpcClient du paquetage org.apache.xmlrpc permet de faire des appels de méthodes disponibles sur le serveur distant et de récupérer les valeurs de retour. Pour l’emploi de cette classe dans notre application, nous avons développé une classe nommée HostNode qui possède parmi ses attributs une instance de la classe xmlrpcClient, représentant chaque hôte distant du système (voir annexe D). La classe HostNode comporte toutes les méthodes nécessaires pour la communication avec un nœud distant. Elle permet de tester la connectivité à un nœud afin de détecter sa présence. Elle permet aussi l’échange d’informations entre les différents nœuds du réseau.

6.2. La solution de virtualisation employée

Le choix d’une solution de virtualisation est nécessaire afin de rendre compatible notre solution avec le système de virtualisation choisi. Cette compatibilité permettra de mettre en pratique les services IaaS du cloud computing à base de notre solution. Nous avons étudié les solutions de virtualisation et constaté que Xen est une solution à la fois plus complète et plus performante dans ce domaine. Nous retenons donc Xen comme solution de virtualisation.

Xen permet la gestion de ses machines virtuelles à l’aide d’un outil nommé xen-tools. Cet outil fournit les commandes nécessaires pour la création, le démarrage et l’arrêt des machines virtuelles. Le lancement des commandes offertes par xen-tools pour la gestion des machines sera effectué au sein de notre application en employant l’API shell pour java, implémenté et fourni sous le paquetage com.developpez.adiguba.shell(30).

Par ailleurs, le déploiement de machines virtuelles sur des hôtes distants sera assuré par l’emploi du protocole SSH via les commandes scp (secure copy). Cette commande permet une copie sécurisée des fichiers d’un hôte à un autre. Elle est utilisée dans la solution de cloud privé OpenNebula pour le déploiement de machines virtuelles sur un ensemble d’hôtes. Pour la gestion des machines virtuelles et tous les processus impliqués dans leur déploiement, nous avons développé respectivement deux classes : la classe VmManager et la classe TransfertDriver. Le diagramme de classe de tout le système est présenté à la figure 6.1. Les autres classes telles que ClusterManager, Cluster, VM, Monitoring, Cli et les classes User et UserManager permettent de gérer de façon modulaire tout le système.

ClusterManager permet de sauvegarder et de gérer tous les nœuds du réseau en se servant des classes Cluster et HostNode. Une instance de la classe Cluster représente un cluster réel du système avec son leader et le nombre d’hôtes qu’il comporte. La classe VM représente l’instance d’une machine sur le réseau et possède tous les attributs de cette machine. La supervision locale effectuée par chaque hôte du système est assurée par la classe Monitoring. Elle possède la valeur du privilège du nœud considéré et fonctionne en se basant sur cette valeur. Les classes User et UserManager permettent de gérer les différents utilisateurs du système. Les données du système et celles des utilisateurs sont stockées dans une base de données (HSQLDB(31)) interne à notre application. Enfin, la classe Cli permet d’administrer le système en offrant une interface de lignes de commandes (CLI).

Figure 6.1: Diagramme de classe du système.

6.3. Le portail Web des services IaaS

Les solutions de cloud privé permettent l’accès aux ressources du système par l’intermédiaire d’un portail Web. Ce portail permet de mettre à la disposition des utilisateurs du système les machines virtuelles disponibles. Il permet d’administrer tout le système de façon homogène. Pour offrir cette fonctionnalité, nous avons développé en java une interface Web en y intégrant un client VNC du nom de noVNC(32) pour l’accès aux machines virtuelles et aux différents hôtes du réseau. Il s’agit d’une implémentation opensource du client VNC. Il est écrit en HTML5 et emploie les technologies du Web telles que les websockets(33), pour une connexion full-duplex asynchrone au serveur VNC et le canva(34) pour l’affichage des données. Pour la communication avec le système de supervision développé, l’application Web utilise également la classe XmlRpcClient du même paquetage org.apache.xmlrpc. De plus, pour offrir la possibilité de configurer ce portail au niveau du système de supervision, nous avons développé une classe PortalNodeInstance qui représente l’instance du portail Web au niveau du système. De cette manière, un nouveau cloud controller élu pourra envoyer ses paramètres (adresses IP et port d’écoute) au portail afin que ce dernier puisse invoquer les méthodes disponibles à son niveau. La figure 6.1 cidessus montre cette classe sur le diagramme présenté.

6.4. Synthèse des outils utilisés

Tableau 6.1 Synthèse des outils utilisés pour l’implémentation.

30 Paquetage écrit en java pour le lancement des commandes Shell directement à partir d’un programme java. < http://blog.developpez.com/adiguba/p3035/java > consulté le 03/10/2012
31 HSQLDB (Hyper Structured Query Language Database) est un système de gestion de base de données relationnelle écrit en Java et qui peut être embarqué dans une application. http://sourceforge.net/projects/hsqldb/ consulté le 06/10/2012.
32 Client VNC en html5.<http://kanaka.github.com/noVNC/noVNC/vnc.html> consulté le 12/09/2012
33 Les websockets constituent une nouvelle technologie du Web permettant d’établir une connexion asynchrone full-duplex avec un serveur Web. <http://grenache.tools.ietf.org/html/rfc6455> consulté le 12/09/2012.
34 Composant du HTML5 qui permet d’éffectuer des rendus dynamiques d’images.

Page suivante : Troisième partie : Résultats et discussion

Retour au menu : CONCEPTION D’UNE SOLUTION DE CLOUD COMPUTING PRIVE BASEE SUR UN ALGORITHME DE SUPERVISION DISTRIBUE : APPLICATION AUX SERVICES IAAS