Les concepts ´evoqu´es dans la section pr´ec´edente ne sont pas sp´ecifiques `a l’environnement logiciel. Les actions manipulant les machines virtuelles durant leur cycle de vie sont disponibles avec la plupart des hyperviseurs, tandis que la notion de configuration s’abstrait de toute consid´eration sur le syst`eme de supervision de la grappe. Il existe plusieurs syst`emes de supervision, plusieurs hyperviseurs et chacun d’entre eux disposent de leur sp´ecificit´es. Il est donc n´ecessaire de pouvoir interfacer Entropy avec des syst`emes de supervision sp´ecifiques, mais ´egalement avec des hyperviseurs sp´ecifiques.
Nous d´ecrivons dans cette section un exemple d’interfa¸cage avec le syst`eme de supervision Ganglia puis nous discutons de la m´ethode retenue pour interfacer Entropy avec un hyperviseur particulier.
6.2.1
Le module de supervision : exemple d’interfa¸cage avec Ganglia
Ganglia [MCC04] est un syst`eme de supervision de ressources distribu´e. Chaque nœud `a superviser ex´ecute une sonde gmond qui interroge le syst`eme d’exploitation afin d’extraire les diff´erentes informations d´ecrivant l’´etat des ressources de la machine, telle que la quantit´e de m´emoire disponible et utilis´ee ou la distribution du temps processeur. Ces informations sont transmises `a d’autres sondes appartenant `a la mˆeme grappe en utilisant une adresse multicast ou `a une sonde parente afin d’agr´eger les informations.
6.2. Int´egration avec l’environnement logiciel 49
Figure6.4 – Architecture du module de supervision Ganglia interfac´e avec Entropy
Un deuxi`eme composant, le gmetad, sert de collecteur de donn´ees. Celui-ci interroge une sonde gmond par grappe et stocke les informations dans une base de donn´ees au format RRD. Ce composant met `a disposition une connexion TCP exportant l’´etat courant des ressources de toutes les grappes supervis´ees. Les donn´ees sont format´ees au travers d’un flux XML qu’il est possible d’analyser afin d’extraire les informations n´ecessaires `a l’´etablissement de la configuration courante.
La Figure 6.4 repr´esente une architecture logicielle bas´ee sur l’utilisation de Ganglia comme syst`eme de supervision. En plus des sondes sur les nœuds de calcul, il est n´ecessaire de d´eployer une sonde sur chaque machine virtuelle afin de remonter les informations relatives `a leur consommation CPU. Nous avons choisi de consid´erer que les machines virtuelles et les nœuds de calcul appartenaient `a deux grappes diff´erentes. Les besoins en ressources CPU des machines virtuelles sont calcul´es d’apr`es le pourcentage de temps CPU consomm´e par les machines virtuelles et la capacit´e CPU de leur nœud d’accueil.
Par d´efaut, les informations fournies par Ganglia ne permettent pas de d´eterminer la position des machines virtuelles. De plus, en fonction de l’hyperviseur, certaines informations additionnelles sont `a fournir afin de combler les manques : dans le cas d’une grappe utilisant l’hyperviseur Xen [BDF+03] par exemple, la sonde s’ex´ecute dans le « Domaine-0 » (machine virtuelle d´edi´ee `a la gestion de l’hyperviseur) et Ganglia ne peut d´eterminer le nombre de CPU physiques disponibles sur la machine ni la quantit´e de m´emoire utilisable. Pour ces raisons, des m´etriques suppl´ementaires doivent ˆetre ins´er´ees dans la sonde
gmond au travers d’un script shell ex´ecut´e sur chaque nœud de calcul.
6.2.2
Le module d’ex´ecution
Le module d’ex´ecution est charg´e de la supervision et de l’ex´ecution d’une reconfiguration par l’application d’un plan de reconfiguration fourni par le module de planification. Ce plan d´ecrit les actions `a ex´ecuter sur les machines virtuelles. Il s’agit des transitions dans le cycle de vie des machines virtuelles. Ces actions sont consid´er´ees `a ce moment comme abstraites car elles ne sont li´ees `a aucun hyperviseur pr´ecis. Le module d’ex´ecution ´etant en contact direct avec l’environnement logiciel de la grappe il doit donc transformer chaque action abstraite en une action concr`ete ´equivalente, compatible avec l’environnement. La transformation des actions abstraites en actions concr`etes est r´ealis´ee par le biais de pilotes (dri-
vers). Pour chaque type d’action, l’administrateur assigne un pilote permettant de la r´ealiser. L’adminis-
trateur peut impl´ementer ses propres pilotes ou utiliser les pilotes disponibles dans la base de connais- sances. Dans Entropy, des pilotes permettent d’ex´ecuter des actions pour l’hyperviseur Xen 3.2 par le biais du serveur HTTP embarqu´e dans l’hyperviseur ou par l’interface XML-RPC [MSS08]. Il est ´egale- ment possible d’ex´ecuter les actions par le biais de commandes shell ex´ecut´ees dans une session SSH sur le nœud d’accueil de la machine virtuelle `a manipuler.
Il est possible aussi de d´efinir des actions concr`etes plus g´en´eriques. Des efforts r´ecents de la part des acteurs de la virtualisation tendent vers l’´etablissement de standards concernant la sp´ecification des machines virtuelles et leur manipulation. Le standard OVF [OVF09] par exemple, d´efinit un format
g´en´erique pour des machines virtuelles d´eployables sur tous les hyperviseurs compatibles. Libvirt [LVT] est un gestionnaire d’hyperviseur, il s’intercale au dessus de l’hyperviseur et permet de manipuler les machines virtuelles par le biais d’une interface commune quelque soit le type de l’hyperviseur sous-jacent (Xen, KVM/Qemu [Hab08], VirtualBox [VBO], OpenVZ [OVZ], LxC [LxC]). En d´eployant Libvirt au dessus des hyperviseurs de chaque nœud de calcul et en utilisant des pilotes compatibles, il est possible d’obtenir un environnement g´en´erique pour la manipulation des machines virtuelles dans les grappes, ind´ependamment de l’hyperviseur d´eploy´e sur les nœuds. Ce type d’impl´ementation n’a cependant pas pu ˆetre r´ealis´e dans le cadre de cette th`ese de par l’absence d’une interface g´en´erique permettant de communiquer avec Libvirt. Celui-ci est enti`erement ´ecrit dans le langage C et bien qu’un portage pour le langage JAVA existe, il repose sur l’utilisation d’un pont JNI n’assurant aucune portabilit´e directe de l’application. Une solution consisterait alors `a d´evelopper un serveur XML-RPC pour Libvirt.