10.2 Exp´erimentations sur une grappe
11.2.4 Architecture g´en´erale d’Entropy
Dans cette th`ese, nous avons consid´er´e uniquement les capacit´es et les besoins en ressources CPU et m´emoire des nœuds et des machines virtuelles. Cette consid´eration n’est pas suffisamment r´ealiste lorsque les applications font une utilisation cons´equente du r´eseau. Il serait en effet utile de pouvoir sp´ecifier des r`egles de placement relatives `a des contraintes li´ees au r´eseau afin de rapprocher des machines virtuelles fortement communicantes par exemple ou de s’assurer que la latence entre deux machines virtuelles est suffisante pour ex´ecuter des applications temps-r´eel. Il se pose alors le probl`eme de la mod´elisation d’un r´eseau et de son utilisation dans Entropy. Nous devons d’abord consid´erer la capacit´e r´eseau de chaque nœud, de chaque lien et de chaque ´equipement d’interconnexion. Il est ensuite n´ecessaire d’identifier et de quantifier le trafic r´eseau entre chaque machine virtuelle. Pass´e cette ´etape, il convient alors de mod´eliser finement l’impact sur le trafic r´eseau de l’affectation d’une machine virtuelle sur un nœud. Cette phase n´ecessite de tenir compte de la topologie du r´eseau et des r`egles de routage. La mod´elisation peut ˆetre simplifi´ee dans le cadre d’un r´eseau uniforme en ´etoile avec des r`egles de routage statiques par exemple. Elle peut ˆetre cependant beaucoup plus d´elicate `a mod´eliser si la topologie est complexe (un r´eseau cubique par exemple) ou si le routage est dynamique (s’il s’adapte `a la charge courante des diff´erents liens r´eseaux par exemple). L’impl´ementation d’un tel mod`ele pourrait ˆetre simplifi´ee par notre approche PPC car elle n’implique pas de modifier les diff´erentes contraintes de la base de connaissances. Il suffirait uniquement de cr´eer de nouvelles variables d´ecrivant les ressources et des contraintes de distances et de graphes, d´edi´ees `a la mise `a jour de ces variables en fonction de l’affectation des machines virtuelles.
L’informatique autonome propose entre autre une s´eparation de certains concepts durant une phase d’auto-adaptation : un module de d´ecision choisit les adaptations `a r´ealiser tandis qu’un module de planification pr´epare l’auto-adaptation. Le d´eveloppement d’Entropy suit cette logique et propose ainsi plusieurs modules de d´ecision et un module de planification. Cependant, en comparant par exemple VMPP et VMRP, on observe que les d´efinitions de chaque probl`eme sont quasiment ´equivalentes. La d´efinition de VMPP est focalis´ee sur la r´eduction du nombre de nœuds utiles. La d´efinition de VMRP se focalise quant `a elle sur la r´eduction du coˆut du plan associ´e `a la configuration r´esultat mais utilisant un nombre de nœuds ´egal `a la solution de VMPP. On peut donc consid´erer que la r´esolution de VMPP ne sert qu’`a pr´eparer le probl`eme VMRP. Cette remarque est ´egalement valable avec le probl`eme RJAP qui ne sert qu’`a indiquer `a VMRP l’´etat des tˆaches pour la configuration finale. Nous avons donc `a r´esoudre deux probl`emes dont l’´ecriture est quasiment ´equivalente pour calculer une nouvelle configuration. En th´eorie, cette approche est coˆuteuse et r´eduit significativement la r´eactivit´e de l’auto-adaptation. Il serait possible de ne r´esoudre qu’un seul probl`eme en consid´erant un probl`eme multi-objectif. R´esoudre un tel probl`eme consiste `a calculer un compromis entre plusieurs variables objectif (par exemple le nombre minimum de
11.2. Perspectives 103 nœuds pour h´eberger les machines virtuelles et le coˆut de reconfiguration) dont la valeur est pond´er´ee. Des ´evaluations de pr´ec´edentes impl´ementations d’Entropy ont cependant montr´e que le temps de r´esolution d’un tel probl`eme ainsi que la qualit´e du r´esultat ´etaient moins satisfaisants que la r´esolution de deux probl`emes ind´ependants. Am´eliorer l’efficacit´e de la r´esolution de probl`emes d’optimisation multi-objectifs serait alors b´en´efique `a Entropy. Cette perspective couvre cependant un champ d’application beaucoup plus large que celui de notre th`ese.
Entropy propose un environnement complet permettant de contrˆoler les machines virtuelles durant la totalit´e de leur cycle de vie. Cependant la contribution de cette th`ese se focalise sur l’aspect d´ecisionnel et la planification de l’auto-adaptation. La n´ecessit´e de maintenir la totalit´e d’un environnement de gestion des machines virtuelles est potentiellement un frein au d´eploiement de nos contributions dans des environnements de productions. Utiliser des machines virtuelles dans une grappe n´ecessite en effet de revoir l’architecture de celle-ci, notamment au niveau du stockage ou des plans d’adressage du r´eseau. R´ecemment, des suites logicielles comme OpenNebula [Mon08] proposent de faciliter la mise en place de tels environnements. Afin de favoriser l’utilisabilit´e d’Entropy, il serait important de choisir apr`es une ´etude des diff´erents environnements disponibles, un environnement de r´ef´erence servant de support `a notre contribution. Cette int´egration dans un environnement ouvert et disposant d’une communaut´e de d´eveloppeurs et d’utilisateurs provenant du monde acad´emique et du monde industriel nous permettrait `
a la fois une meilleure compr´ehension des besoins des utilisateurs mais ´egalement une visibilit´e sup´erieure de notre contribution.
Chapitre 12
Annexe
D
urantplacement des machines virtuelles en cours d’ex´ecution. Ces diff´erentes contraintes sont incluses encette th`ese, nous avons d´evelopp´e diff´erentes contraintes agissant sur l’´etat des tˆaches et le standard dans la base de connaissances d’Entropy et peuvent ˆetre utilis´ees pour d´efinir des probl`emes sp´ecifiques `a une grappe. Cette annexe liste les diff´erentes contraintes d´evelopp´ees ainsi que leur d´efinition `a la fois textuelle et formelle en suivant le mod`ele VMAP et les contraintes globales du solveur Choco.
12.1
Contraintes li´ees `a l’ordonnancement des machines vir-
tuelles
D´esignation D´efinition
mustBeReady(j) Indique qu’une machine virtuelle d’indice j doit ˆetre dans le pseudo- ´etat Pr^et. Le solveur choisira l’´etat concret en fonction de son ´etat courant. Si celle-ci est dans l’´etat Ex´ecution alors son ´etat sera Endormi, sinon son ´etat sera Attente.
Expression : vj= n + 1
mustBeRunning(j) Indique qu’une machine virtuelle d’indice j doit ˆetre dans l’´etat Ex´ecution.
Expression : vj≤ n ou vj6= n + 1 ∧ vj6= n + 2
mustBeStopped(j) Indique qu’une machine virtuelle d’indice j doit ˆetre dans l’´etat Termin´e.
Expression : vj= n + 2