Les m´ etriques

Les exp´eriences r´ealis´ees durant cette th`ese ont pour but de valider l’utilisation du SAA TUNeEngine pour l’administration de la plateforme de cloud CloudEngine et des applications qu’elle h´eberge. Au niveau de l’IaaS, les principales m´etriques qui nous int´eressent sont : la charge CPU et le nombre de VM par machine physique. La charge CPU comprend la consommation CPU de chaque VM, la consommation CPU du dom0 (syst`eme hˆote avant l’installation de l’hyperviseur) et la charge CPU de la machine physique qui est la somme de toutes les charges CPU des VM qu’elle h´eberge.

Au niveau des applications entreprises, nous nous int´eressons au d´ebit et au temps de r´eponse des requˆetes de l’application RUBIS, observ´es au niveau du serveur web Apache.

10.2

Evaluations´

10.2.1

R´eparation de VM

Dans cette exp´erimentation, nous ´evaluons les deux types de r´eparation que nous avons d´ecrites dans la section 9.3.1 du chapitre pr´ec´edent. Il s’agit de la r´eparation collaborative et non collaborative dont nous rappellerons bri`evement les principes dans les sections suivantes.

De fa¸con g´en´erale, dans les exp´eriences que nous r´ealisons pour l’´evaluation de la r´eparation, les pannes sont d´etect´ees par l’instance TUNeEngine de niveau IaaS. Nous d´emarrons l’IaaS de telle sorte que les serveurs du MonitoringController, instal- l´es sur chaque machine de l’IaaS, scrutent l’´etat des VM toutes les 2 secondes. Nous consid´erons qu’une VM est en panne lorsqu’elle ne r´epond plus `a une requˆete IP (la commande ”ping” `a partir d’une autre machine) ou encore lorsque son hyperviseur Xen indique un ´etat d’erreur.

Pour chacune des ´evaluations des deux m´ethodes de r´eparation, nous ex´ecutons un benchmark RUBIS pyramidal (mont´ee de charge, charge constante et baisse de charge). Nous simulons une panne sur une VM h´ebergeant un serveur MySQL de l’application RUBIS ex´ecut´ee. En outre, nous associons `a ces exp´erimentations une exp´erience particuli`ere jouant le rˆole de rep`ere. En effet, cette exp´erience sera utilis´ee pour la comparaison des deux m´ethodes de r´eparation. Elle consiste en l’ex´ecution d’un benchmack RUBIS dans lequel aucune panne n’est simul´ee. La comparaison Syst`eme d’administration autonome adaptable : application au Cloud

10.2. ´EVALUATIONS 127 des deux m´ethodes de r´eparation est effectu´ee sur la base du d´ebit en requˆetes et du nombre d’erreurs observ´ees durant chaque exp´erience.

Pour finir, l’application RUBIS ex´ecut´ee dans cette exp´erience est compos´ee de : 1 serveur Apache, 1 serveur Tomcat, 1 serveur MySQL-Proxy et 1 serveur MySQL. Les VM h´ebergeant ces serveurs sont configur´ees de telle sorte qu’elles s’ex´ecute- rons chacune sur des machines distinctes. Cette configuration n’a aucune influence particuli`ere sur les r´esultats de l’exp´erimentation.

10.2.1.1 R´eparation non collaborative

Nous d´efinissons la r´eparation non collaborative comme celle dans laquelle l’ins- tance TUNeEngine de l’IaaS est l’unique responsable du d´epannage des VM. Dans notre exp´erimentation, TUNeEngine d´emarre sur chaque machine de l’IaaS un ser- veur dont le rˆole est de sauvegarder toutes les 7 secondes l’´etat de chaque VM. Le choix de la fr´equence de sauvegarde ne doit pas ˆetre ni trop petite, au risque de p´enaliser l’ex´ecution de la VM (comme nous le verrons), ni grande au risque d’avoir un grand ´ecart entre la VM d´epann´ee et son ´etat avant la panne. Nous avons choisi une dur´ee de 7 secondes en rapport avec la dur´ee minimale d’attente entre chaque ´emission de requˆete de client RUBIS. Les ´etats de VM sauvegard´es sont stock´es, non pas sur le serveur NFS, mais sur la machine h´ebergeant la VM. Ces sauvegardes seront transf´er´ees avec la VM lors des op´erations de consolidation.

La figure 10.2 montre la comparaison entre l’exp´erimentation rep`ere (courbe rouge) et l’exp´erimentation avec r´eparation par checkpointing (courbe verte) dans laquelle aucune panne n’a ´et´e simul´ee. Cette figure nous permet uniquement d’obser- ver l’impact du checkpointing de VM sur les performances de l’application RUBIS s’ex´ecutant dans le cloud. Nous observons une baisse de d´ebit de requˆetes trait´ees dans ce type de r´eparation : courbe rouge au dessus de la courbe verte. Nous ´eva- luons cette baisse de d´ebit `a 46% environ. Elle est due `a l’arrˆet r´egulier des VM lors du checkpointing dans l’IaaS. En effet, le checkpointing implant´e par Xen provoque l’indisponibilit´e de la VM pendant sa sauvegarde. Ainsi, toutes les requˆetes en di- rection ou `a l’int´erieur de cette VM s’ex´ecuteront apr`es la sauvegarde. Ceci explique ´egalement de grandes fluctuations du d´ebit sur la courbe verte.

La figure 10.3 pr´esente le r´esultat de l’application de la m´ethode de r´eparation de VM par checkpointing dans le cloud, avec simulation de pannes sur la VM du serveur MySQL. L’instant Tp repr´esente l’instant auquel la panne a ´et´e provoqu´ee

tandis que l’instant Tr marque la fin de la r´eparation. La dur´ee de r´eparation dans

cette exp´erience est d’environ 22 secondes. Cette dur´ee comprend le temps ´ecoul´e avant la d´etection de la panne et ´egalement la dur´ee de red´emarrage de la VM `a partir de son dernier ´etat sauvegard´e.

Nous constatons ´egalement dans cette exp´erimentation qu’aucune requˆete n’est perdue `a la fois pendant les sauvegardes de VM que pendant la r´eparation. En effet, pour ce qui est de la sauvegarde, le protocole TCP/IP sur lequel repose notre r´eseau se charge de r´e´emettre une requˆete lorsque celle-ci n’a pas abouti. Ainsi, durant

10.2. ´EVALUATIONS 128

Figure 10.2 – Coˆut du checkpointing dans la r´eparation de VM dans l’IaaS la sauvegarde, l’indisponibilit´e n´egligeable de la VM n’entraˆıne pas la rupture des communications TCP/IP et celles-ci sont reprises `a la fin de la sauvegarde. Quant `

a la non perte de requˆetes durant la r´eparation, elle s’explique par le comportement du client RUBIS. En effet, il r´e´emet en cas d’erreur la mˆeme requˆete 6 fois toutes les secondes, ce qui laisse le temps `a la r´eparation (d´emarrage de la VM avec son ancien ´etat) de se r´ealiser. Notons que pour certaines applications comme MPI, l’indisponibilit´e de la VM (mˆeme n´egligeable), suivit du changement d’´etat de la VM ne saurait ˆetre tol´er´ee.

10.2.1.2 R´eparation collaborative

La seconde m´ethode de r´eparation est dite collaborative dans la mesure o`u les op´erations de r´epartition sont r´ealis´ees `a la fois par l’instance TUNeEngine de niveau IaaS et l’instance TUNeEngine de niveau application entreprise. En effet, l’instance TUNeEngine de niveau IaaS d´etecte la panne de VM, red´emarre la VM `a partir de son image initiale et fait appel `a l’instance TUNeEngine propri´etaire de la VM pour finaliser la r´eparation. L’instance TUNeEngine de niveau application est quant `a elle charg´ee de : d´eployer sur la VM red´emarr´ee les logiciels qui y s’ex´ecutaient avant la panne ; configurer et d´emarrer ces logiciels. La taille des logiciels `a d´eployer ainsi que la dur´ee d’ex´ecution des programmes de configuration et de d´emarrage des logiciels sur la VM influencent la dur´ee de la r´eparation.

10.2. ´EVALUATIONS 129

Figure 10.3 – R´eparation de VM de l’IaaS par checkpointing

La figure 10.4 pr´esente deux courbes : la courbe rouge repr´esente l’exp´erimen- tation rep`ere tandis que la courbe verte repr´esente le r´esultat de l’exp´erimentation avec panne et r´eparation collaborative. Nous constatons que cette m´ethode de r´e- paration, contrairement `a la pr´ec´edente, n’a aucun impact sur les performances de l’application RUBIS lorsqu’aucune panne n’intervient. Cette constatation est visible sur la figure 10.4 dans les zones (1) et (3). La zone (2) repr´esente la dur´ee de la r´eparation. Elle inclut : le temps de d´etection de la panne, la dur´ee de d´eploiement et de red´emarrage de la VM, la dur´ee de la copie des binaires du serveur MySQL s’ex´ecutant sur la VM et enfin la dur´ee de red´emarrage du serveur MySQL. Pour ces raisons, nous constatons dans cette exp´erience, une r´eparation en 5 minutes 30 secondes. Cette dur´ee importante de la r´eparation entraˆıne une perte de requˆetes au niveau des clients RUBIS. Cette perte est de deux ordres :

– Des pertes li´ees aux requˆetes effectivement ´emises par le client RUBIS, mais heurt´ees `a l’indisponibilit´e du serveur MySQL. Nous ´evaluons cette perte `a environ 0.12% des requˆetes ex´ecut´ees. La valeur n´egligeable de cette perte vient d’une part du fait que chaque client RUBIS ´emet 6 fois la mˆeme requˆete en cas d’erreurs, avec une pause d’une seconde entre chaque tentative. D’autre part, les timeout des serveurs J2EE impliqu´es dans ces requˆetes sont sup´erieurs `

a la minute.

– En comparaison avec l’exp´erimentation rep`ere, nous observons la r´eduction du nombre globale de requˆetes ex´ecut´ees durant cette exp´erience. Nous estimons cette r´eduction `a environ 23% de requˆetes trait´ees dans l’exp´erimentation re- p`ere. Cette valeur s’explique par la perte de temps des clients RUBIS dans leurs tentatives de r´e´emission de requˆetes pendant la dur´ee de la r´eparation.

10.2. ´EVALUATIONS 130 Notons que l’utilisation d’un serveur miroir, g´en´eralement pratiqu´ee dans les appli- cations, permettra de palier cette latence importante. Dans certains cas, ce miroir est mis en place par l’IaaS. C’est le cas de la plateforme de cloud Windows Azure que nous avons pr´esent´e dans la section 7.2.4 du chapitre etatDeLart.

Figure 10.4 – R´eparation collaborative de VM