Consolidation

Apr`es l’´evaluation de l’utilisation de TUNeEngine pour l’allocation dynamique de ressources au niveau des applications entreprises dans le cloud (ce qui correspond `

a ce que faisait le syst`eme TUNe, son inspirateur), montrons `a pr´esent comment TU- NeEngine permet de g´erer par consolidation de VM les ressources de l’IaaS. Nous montons pour cette exp´erimentation un sc´enario montrant l’utilit´e de la consolida- tion dans l’IaaS. Comme nous l’avons ´enonc´e dans la section 9.3.2.1 du chapitre pr´ec´edent, nous consid´erons un sc´enario ex´ecutant au niveau applicatif une seule ap- plication. La version TUNeEngine d’administration de cette application n’implante aucune politique d’allocation dynamique de ressources. Quant au niveau IaaS, nous utilisons une politique de placement de VM consistant `a maximiser le nombre de VM par machine. Le but de cette exp´erience est de valider l’existence et l’efficacit´e Syst`eme d’administration autonome adaptable : application au Cloud

10.2. ´EVALUATIONS 133 du Scheduler de CloudEngine, dont le rˆole est de g´erer la consolidation des VM dans l’IaaS.

Pour cette exp´erimentation, l’application RUBIS ex´ecut´ee dans le cloud ainsi que le Scheduler de l’IaaS sont configur´es de la fa¸con suivante :

– 1 serveur Apache, 2 serveurs Tomcat, 1 serveur MySQL-Proxy et 2 serveurs MySQL.

– Toute VM h´ebergent un serveur RUBIS se voit allouer 512Mo de m´emoire. Cette configuration fera tenir initialement toutes les VM sur la mˆeme machine physique (512Mo * 6 serveurs + 512Mo du dom0 = 3Go512Mo < 4Go, taille d’une machine physique).

– Le Scheduler est configur´e pour retirer une VM d’une machine physique lorsque la charge CPU de cette machine d´epasse 60%. Dans ce cas, la VM la moins charg´ee est d´eplac´ee vers la machine de l’IaaS la moins charg´ee pouvant l’ac- cueillir. A l’inverse, le Scheduler regroupe des VM sur des machines selon la politique suivante. Soit Ma et Md les machines les moins charg´ees de l’IaaS

contenant des VM telles que Ma est plus charg´ee que Md. Soit V Md, la VM la

moins charg´ee de la machine Md. Si la charge de Ma additionn´ee `a la charge

de V Md est inf´erieure `a 60% et que la taille m´emoire de Ma additionn´ee `a la

taille m´emoire de V Md est inf´erieure `a 4Go, alors le Scheduler d´eplace V Md

vers la machine Ma. Cette politique est une parmi tant d’autres. Notons que

le but de cette exp´erience n’est pas de produire et d’´evaluer diff´erentes poli- tiques de consolidation. Les travaux r´ealis´es par le syst`eme Entropy [59] sont enti`erement consacr´es `a cette probl´ematique.

La figure10.7montre les r´esultats de notre exp´erience : la figure10.7(a) pr´esente la variation des charges CPU sur les machines de l’IaaS tandis que la figure 10.7(b) pr´esente le contenu de chaque machine de l’IaaS en terme de nombre de VM par machine. Sachant que la taille et le nombre de logiciels d´eploy´es dans cette exp´erience sont fixes, les variations de nombre de VM par machine d´emontre la r´ealisation de la consolidation dans l’IaaS coordonn´ee par le Scheduler de CloudEngine. Ces deux figures sont interpr´et´ees de la fa¸con suivante :

– La premi`ere partie des courbes correspond au d´eploiement des VM dans l’IaaS. Compte tenu de la politique de placement et de la taille des VM, toutes les VM sont d´eploy´ees initialement sur la machine Node1. Ceci explique l’obser- vation d’une charge CPU fluctuante sur la courbe CPU de la machine Node1 et l’absence de charge sur les autres machines de la figure10.7(a). La premi`ere partie de la figure 10.7(b) montre ´egalement ce regroupement de VM sur la machine Node1.

– Pendant l’ex´ecution du benchmark RUBIS, nous observons un premier ´eclate- ment d’une VM de la machine Node1 vers la machine Node4 lorsque la charge CPU de la machine Node1 d´epasse le seuil de 60%. Ceci explique la pr´esence d’une charge CPU sur la machine Node4 sur la figure10.7(a)(1) et la pr´esence d’une VM sur cette machine `a la figure 10.7(b)(1). Il en est de mˆeme pour le (2) des figures 10.7(a) et 10.7(b).

– Durant l’ex´ecution de ce benchmark, le Scheduler peut ˆetre amen´e `a regrouper les VM lorsque la charge d’une machine le permet. C’est notamment le cas

10.2. ´EVALUATIONS 134 de la VM de la machine Node4 qui sera d´eplac´ee vers la machine Node5 en mesure de supporter cette VM `a l’instant repr´esent´e sur la figure 10.7(a)(3). – Pour finir, les VM sont regroup´ees `a la fin de l’ex´ecution du benchmark sur un

nombre restreint de machines. On peut remarquer que toutes les VM ne sont pas regroup´ees sur une unique machine physique comme initialement. Ceci s’explique par le fait que la migration pratiqu´ee par Xen (le syst`eme de vir- tualisation utilis´e par l’IaaS) d’une VM n´ecessite 2 conditions : (1) la machine de destination dispose d’assez de m´emoire pour ex´ecuter la VM `a migrer ; (2) la machine de destination dispose ´egalement d’un surplus de m´emoire desti- n´ee `a la r´ealisation de l’op´eration de VM, consommatrice de m´emoire. Cette consommation de m´emoire est moins importante pendant la phase de d´emar- rage d’une VM que pendant l’ex´ecution. Ainsi, la machine Node5 h´ebergeant d´ej`a toutes les autres VM, ne dispose pas assez de m´emoire pour accueillir la derni`ere VM se trouvant sur la machine Node4.