Tout au long de cette th`ese, nous avons discut´e de certaines limitations et de perspectives concernant l’architecture g´en´erale et les diff´erents composants d’Entropy. Nous reprenons dans cette section les perspectives que nous jugeons les plus pertinentes en les envisageant de mani`ere plus globale et `a plus long terme.
11.2.1 Consolidation dynamique
Notre module de consolidation dynamique assure une concentration optimale des machines virtuelles sur un nombre minimum de nœuds. Si cette approche r´epond `a un besoin r´eel, on remarque cependant que son int´egration dans des centres d’h´ebergement d’applications ou mˆeme sur des grappes de production est limit´ee. Dans le cadre de l’h´ebergement de services web par exemple, les applications distribu´ees h´eberg´ees ont g´en´eralement des contraintes relatives `a la tol´erance aux pannes. Traditionnellement, la solution consiste `a introduire de la redondance dans le service, en h´ebergeant plusieurs instances d’un mˆeme service sur des nœuds diff´erents. En amont, un ou plusieurs r´epartiteurs de charge distribuent les requˆetes HTTP sur les diff´erentes instances. De cette mani`ere, si un nœud h´ebergeant une instance tombe en panne, alors le service reste fonctionnel car plusieurs instances sont encore disponibles. Dans le cadre de l’utilisation de la consolidation dynamique, l’algorithme de placement peut ˆetre amen´e `a h´eberger toutes les instances d’un service sur un mˆeme nœud. Si ce nœud venait `a tomber en panne alors le service entier serait interrompu. Nous pensons que la consolidation dynamique telle qu’elle est appliqu´ee dans Entropy mais ´egalement dans la litt´erature actuelle r´eduit la tol´erance aux pannes en ne consid´erant pas le besoin de s´eparer certains composants. Ces contraintes sont cependant primordiales dans les services `a haute disponibilit´e actuels. L’approche flexible retenue pour le d´eveloppement d’Entropy permet de consid´erer facilement ces contraintes li´ees `a la tol´erance aux pannes. Notre base de connaissances dispose d´ej`a de la contrainteassignOnDif f erentN ode. Celle-ci assure que chaque machine virtuelle d’un ensemble donn´e sera h´eberg´ee sur un nœud diff´erent (sa d´efinition compl`ete est disponible en annexe). Ainsi, lorsqu’un
11.2. Perspectives 101 utilisateur soumet une tˆache contenant des services redondants, il d´eclare en compl´ement des besoins initiaux en ressources, les diff´erents ensembles de machines virtuelles concern´ees. Il est alors possible de sp´ecialiser VMPP pour ajouter une contrainte assignOnDif f erentN ode sur chacun des ensembles de machines virtuelles. Ce module de consolidation modifi´e assurera alors l’utilisation d’un nombre minimal de nœuds tout en maintenant les contraintes li´ees `a la tol´erance aux pannes.
11.2.2 Ordonnancement flexible
Si le d´eveloppement de strat´egies d’ordonnancement est simple et rapide pour une personne connaissant l’API d’Entropy, elle n´ecessite tout de mˆeme des comp´etences dans le langage de programmation JAVA et une connaissance du fonctionnement d’Entropy. Ces points peuvent freiner les administrateurs dans le d´eveloppement d’ordonnanceurs et mener `a des erreurs de conceptions li´ees au manque d’expertise dans l’API d’Entropy et `a l’absence de v´erifications des algorithmes d’ordonnancement. Ce probl`eme est d’autant plus contraignant que certaines erreurs ne seront d´etectables par le d´eveloppeur qu’apr`es l’obser-vation du comportement d’Entropy lors de son ex´ecution. Une approche pour l’´ecriture d’ordonnanceur pour Entropy dans un langage d´edi´e (DSL) pourrait ˆetre une solution `a ces probl`emes. Un DSL est un langage cr´e´ee pour r´esoudre des probl`emes sp´ecifiques `a un domaine. Le langage SQL [MS01] par exemple est un langage d´edi´e `a la manipulation de bases de donn´ees relationnelles. Les langages d´edi´es s’opposent
`
a des langages g´en´eralistes comme JAVA ou C couvrant un large spectre de domaines. L’utilisation d’un DSL d´edi´e `a l’´ecriture de strat´egies d’ordonnancement pour Entropy permettrait de r´eduire le niveau d’expertise n´ecessaire `a leur ´ecriture tout en permettant la v´erification de certaines propri´et´es de correc-tions avant l’ex´ecution de la strat´egie. Le d´eveloppeur manipule en effet uniquement des concepts li´es `a l’ordonnancement des tˆaches et `a la g´en´eration d’une configuration avec un langage restreint. Le code de cette strat´egie est ensuite compil´e pour ˆetre incorpor´e dans Entropy uniquement si celui-ci respecte des propri´et´es telles que l’impossibilit´e de d´etruire involontairement des tˆaches par exemple.
Par ailleurs, l’approche actuelle d’ordonnancement se limite `a la d´eclaration de la liste des tˆaches `a ex´ecuter. Il serait pertinent de pouvoir sp´ecifier ´egalement des r`egles de placement entre les diff´erentes ma-chines virtuelles des tˆaches. On retrouve alors un cas d’utilisation similaire `a la consolidation dynamique o`u l’utilisateur peut souhaiter ex´ecuter chacune de ses machines virtuelles sur des nœuds diff´erents. Mais il importe ´egalement de pouvoir ex´ecuter plusieurs machines virtuelles sur un mˆeme nœud, lorsque celles-ci sont fortement inter-communicantes par exemple ou interdire d’ex´ecuter certaines machines virtuelles sur une liste de nœuds. La base de connaissances d’Entropy dispose d´ej`a d’un ensemble de contraintes pr´e-impl´ement´ees r´epondant `a ces besoins (l’annexe regroupe et d´efinit ces diff´erentes contraintes). Notre DSL pour l’ordonnancement pourrait alors int´egrer la possibilit´e d’exprimer ces contraintes de placement pour affiner l’ordonnancement et le placement des machines virtuelles.
11.2.3 Reconfiguration
Dans cette th`ese, nous avons identifi´e diff´erentes perspectives propres au module de planification de la reconfiguration, mais ´egalement li´ees aux besoins, non-consid´er´es `a l’origine, des modules de d´ecisions.
Notre algorithme de cr´eation de plans de reconfiguration n´ecessite qu’un nœud de la grappe dispose d’un espace libre suffisamment grand pour servir de pivot en cas de d´ependances cyclique. Si cette situation est envisageable dans la majorit´e des cas, il est int´eressant de proposer une alternative `a base de suspension et de reprise de machine virtuelle. Lorsqu’un cycle de d´ependances n’est pas r´esolvable, nous r´ealisons une suspension d’un machine virtuelle puis sa reprise lorsque les d´ependances ont ´et´e r´esolues. Cette solution assure la faisabilit´e d’une reconfiguration dans toutes les situations, sans avoir recours `a la pr´eemption d’une machine virtuelle pour r´esoudre tous les probl`emes de cycle de d´ependances [GIYC06], solution `a la fois plus coˆuteuse en temps et en performances.
Par ailleurs, notre ´etude des contextes des actions a mis en avant l’int´erˆet de consid´erer le temps d’ex´ecution des actions, ainsi que leur impact sur les performances des nœuds impliqu´es. Nous avons impl´ement´e une premi`ere fonction de coˆut minimisant le temps d’ex´ecution d’un plan, mais il serait pertinent de r´ealiser ´egalement une fonction de coˆut d´edi´ee `a la r´eduction de l’impact d’une reconfiguration sur les performances de la grappe. La confrontation de ces deux approches pour l’optimisation de la reconfiguration permettrait de choisir l’approche la plus adapt´ee en fonction de diff´erents param`etres tels que le type de tˆaches (du calcul scientifique par exemple) et la fr´equence de variation des besoins en
ressources. Cette confrontation pourrait ´egalement mettre en avant un int´erˆet pour une fonction de coˆut r´ealisant par pond´eration un compromis entre la r´eduction du temps d’ex´ecution d’un plan et son impact sur les performances.
Finalement, nous avons d´emontr´e dans cette th`ese que la PPC ´etait une solution efficace pour la r´esolution de probl`emes d’ordonnancement vari´es. La planification des actions est assimilable `a un pro-bl`eme d’ordonnancement, o`u nous ordonnons les actions `a ex´ecuter pour assurer leur faisabilit´e tout en proposant un coˆut global minimum. L’approche que nous avons choisi dans cette th`ese est une approche mixte o`u le calcul d’un plan de reconfiguration depuis une configuration source vers une configuration finale est r´ealis´e de mani`ere heuristique tandis que l’algorithme d’optimisation VMRP repose sur la PPC.
Le probl`eme VMRP maintient l’´etat de toutes les machines virtuelles ainsi que la viabilit´e de la confi-guration finale tandis que l’heuristique de cr´eation de plan assure la viabilit´e de la conficonfi-guration durant tout le processus de reconfiguration. Nous avons expliqu´e dans les perspectives li´ees `a la consolidation dynamique et `a l’ordonnancement des tˆaches que la prise en compte des contraintes de placement dans le module de d´ecision est une contribution pertinente. Seulement, notre approche actuelle pour la reconfi-guration n’assure pas le maintien de ces contraintes de placement durant le processus de reconfireconfi-guration.
L’approche PPC pour la d´efinition du probl`eme VMRP permet de consid´erer ces contraintes facilement, cependant notre heuristique ne peut assurer que ces contraintes seront maintenues durant tout le proces-sus de reconfiguration. Une solution consisterait alors `a utiliser une approche bas´ee uniquement sur de la PPC pour la planification et l’optimisation du processus de reconfiguration.
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
urant cette th`ese, nous avons d´evelopp´e diff´erentes contraintes agissant sur l’´etat des tˆaches et le placement des machines virtuelles en cours d’ex´ecution. Ces diff´erentes contraintes sont incluses en 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.