Ex´ecution d’applications variables

Cette seconde situation concerne les clients avertis. En effet, nous supposons ici que les clients pratiquent du sizing dans leurs applications. Contrairement `a la situation pr´ec´edente, ici le nombre de VM du mˆeme client est variable. L’IaaS profite de ces arrˆets de VM, donc lib´eration de ressources, pour r´eorganiser les VM par consolidation. Pour illustrer cela, prenons quelques exemples pr´ecis :

– Si le cloud ex´ecute une seule application et que celle-ci pratique du sizing ordonn´e, alors aucune op´eration de consolidation n’est n´ecessaire. Nous parlons de sizing ordonn´e lorsque les VM retir´ees sont les derni`eres `a ˆetre ajout´ees.

– Si le cloud ex´ecute une seule application pratiquant un sizing non ordonn´e, alors la consolidation est n´ecessaire. Cette situation est identique `a celle dans laquelle le cloud ex´ecute plusieurs applications appartenant `a un ou plusieurs clients. En effet, la fin d’une application (qui entraˆıne la fin de ses VM), pendant l’ex´ecution d’autres, laissera des trous sur les machines h´ebergeant les VM de cette application. Cette lib´eration de ressources correspond celle que nous observons dans une application pratiquant un sizing non ordonn´e.

– Une situation plus fine est celle dans laquelle le cloud donne la possibilit´e au client de faire varier la taille d’une VM pendant son ex´ecution. Ainsi, avant d’ajouter une nouvelle VM pour absorber une charge, le client pourra tout d’abord augmenter progressivement les ressources de la VM jusqu’`a atteindre Syst`eme d’administration autonome adaptable : application au Cloud

9.4. SYNTH `ESE 119 la ressource maximale (celle de la machine qui l’h´eberge). Et, c’est `a l’issu de ces augmentations qu’il ajoutera concr`etement une nouvelle VM. Le mˆeme raisonnement est valable pour le retrait. Dans ce sc´enario, la consolidation au niveau de l’IaaS prend v´eritablement tout son sens. Les variations de tailles des VM, lib´ereront des ressources (avec apparition des ”trous”) et n´ecessiteront ainsi des consolidations/´eclatements de VM dans l’IaaS. Notons ´egalement qu’ici, le client est dans l’obligation d’adapter ´egalement les distributeurs de charges de ses applications.

Nous ´evaluons dans le chapitre suivant toutes ces sc´enarios de reconfiguration `a la fois dans le cloud et dans les applications clientes.

9.4 Synth` ese

Dans ce chapitre, nous avons pr´esent´e une adaptation de TUNeEngine pour l’ad-ministration de la plateforme de cloud simplifi´ee CloudEngine ainsi que des appli-cations qu’elle h´eberge. La figure 9.3 pr´esente une vue globale de ces adaptations de TUNeEngine : `a gauche de la figure, nous avons l’utilisation de TUNeEngine pour l’administration d’une application entreprise J2EE s’ex´ecutant dans le cloud ;

`a droite nous avons d’une part l’utilisation de TUNeEngine pour l’administration de CloudEngine et d’autre part le contenu des machines de l’IaaS. Par soucis de lisibilit´e, toutes les liaisons Fractal entre les composants ne sont pas pr´esent´ees dans cette figure.

Le syst`eme de repr´esentation de l’instance TUNeEngine du cloud est organis´e en quatre composants :

– Un composant (”IaaS” sur la figure) contenant les wrappers des serveurs de l’IaaS ainsi que ceux des futures images et VM qu’h´ebergera le cloud. Remar-quons que dans cet exemple, le cloud propose une image de VM par d´efaut (DefaultImage) dont la description est montr´ee dans la figure 9.4(a). Plusieurs configurations de VLAN peuvent ˆetre utilis´ees dans l’IaaS. La figure 9.4(b) pr´esente un exemple de configuration d’un VLAN. Cette description contient par exemple l’adresse IP r´eseau qu’utiliseront les VM de ce VLAN.

– Un composant (”Ressources” sur la figure) contenant leswrappers des machines de l’IaaS. Ces machines peuvent ˆetre regroup´ees en cluster.

– Un composant (”IaaS AutonomicManager” sur le figure) contenant les pro-grammes d’administration et de reconfiguration des serveurs de l’IaaS. Ce com-posant est reli´e au comcom-posant ”IaaS” de la figure. On retrouve par exemple le VMController que nous avons pr´esent´e dans les sections pr´ec´edentes comme un programme d’administration.

– Un composant (”Ressources AutonomicManager” sur le figure) contenant les programmes de d´emarrage des logiciels de monitoring (sonde) des machines de l’IaaS. Ce composant est reli´e au composant ”Ressources” de la figure. Nous associons une sonde par machine (voir le logiciel ”Sonde” sur la partie droite basse de la figure9.4)

9.4. SYNTH `ESE 120 Quant au syst`eme de repr´esentation de l’instance TUNeEngine d’administration de l’application entreprise J2EE, il est organis´e en deux composants :

– Un composant contenant les wrappers des serveurs J2EE et un wrapper d´e-crivant les informations d’initiation de la collaboration avec le cloud. Chaque wrapper de serveur J2EE contient d’une part les informations de configuration du serveur proprement dit et d’autre part les informations d´ecrivant la quantit´e de ressources VM de ce serveur. La figure9.4(c) montre la description du wrap-per d’un serveur Apache de l’application entreprise J2EE. Dans sa premi`ere partie, nous retrouvons les informations de configuration d’Apache comme le

”ApacheUser” tandis que dans sa deuxi`eme partie, nous retrouvons les infor-mations de configuration de la VM qui h´ebergera cet Apache (par exemple

”cpu” : la quantit´e de processeur `a garantir `a cette VM).

– Un composant contenant les programmes de configuration, d´emarrage, recon-figuration et r´eparation des serveurs J2EE.

Le composant ResourceController (rempla¸cant le NodeAllocator) de l’ins-tance TUNeEngine de niveau entreprise obtient du serveur RMI de collaboration, la r´ef´erence RMI du composantCollaborator du Cloud. A partir de cette r´ef´erence, leResourceController pourra allouer ou lib´erer des VM pour l’ex´ecution des ser-veurs de l’application entreprise. Dans cette collaboration, la plus part des ordres

´emis par leResourceController `a destination du cloud seront r´esolus par le VM-Controller. En r´eponse `a la r´eservation d’une VM pour l’ex´ecution d’un serveur Apache par exemple, le VMController construit et ins`ere dans le syst`eme de re-pr´esentation de CloudEngine unwrapper de VM dont une description est pr´esent´ee dans la figure9.4(d). Les informations de configuration de cette VM sont transmises par leResourceController du niveau entreprise dans l’ordre de r´eservation.

Dans la mˆeme logique, l’implantation du composant ProbreMySQL utilise la r´e-f´erence RMI du Collaborator afin d’avoir les informations de monitoring des VM h´ebergeant les serveurs MySQL dont il observe. Ainsi, il pourra (`a partir de ces in-formations) d´ecider de la scalabilit´e ou non des serveurs MySQL en cas de n´ecessit´e.

Pour finir, nous pouvons observer un empilement de serveurs sur les machines de VMCluster. Ainsi, s’ex´ecutent au dessus de l’hyperviseur les repr´esentants Re-moteLauncher et RemoteWrapper d´eploy´es par l’instance TUNeEngine du cloud.

Chaque RemoteWrapper est associ´e `a l’ex´ecution d’une VM, qui est consid´er´ee par l’instance TUNeEngine du cloud comme un ´el´ement administrable. Ensuite, chaque VM contient les repr´esentants RemoteLauncher et RemoteWrapper d´eploy´es par l’instance TUNeEngine de niveau entreprise. Chaque RemoteWrapper de chaque VM est associ´e `a l’ex´ecution d’un serveur J2EE. Les diff´erents repr´esentants des instances TUNeEngine des deux niveaux (entreprise et cloud) sont enti`erement in-d´ependantes et ne disposent d’aucun lien entre eux.

Syst`eme d’administration autonome adaptable : application au Cloud

9.4. SYNTH `ESE 121

Figure 9.3 – Vue globale d’administration et d’utilisation de CloudEngine via TU-NeEngine

9.4. SYNTH `ESE 122

Figure 9.4 – (a) Description d’une image de VM dans le SR de CloudEngine, (b) Description d’une VM dans le SR de CloudEngine, (c) Description du logiciel Apache dans le SR de l’instance TUNeEngine de niveau application Entreprise, et (d) Description d’une VM dans l’IaaS g´en´er´ee par le VMController de CloudEngine.

Syst`eme d’administration autonome adaptable : application au Cloud

Chapitre 10

Exp´ erimentations

Contents

10.1 Environnements d’exp´erimentation . . . 124 10.1.1 L’IaaS . . . 124 10.1.2 Les applications entreprises : RUBIS . . . 125 10.1.3 Les m´etriques . . . 126 10.2 ´Evaluations . . . 126 10.2.1 R´eparation de VM . . . 126 10.2.1.1 R´eparation non collaborative . . . 127 10.2.1.2 R´eparation collaborative . . . 128 10.2.2 Scalabilit´e et Consolidation . . . 130 10.2.2.1 Scalabilit´e . . . 130 10.2.2.2 Consolidation . . . 132 10.2.2.3 Scalabilit´e et Consolidation simultan´ees . . . 134 10.3 Synth`ese . . . 143

Dans ce chapitre, nous pr´esentons une ´evaluation de notre SAA TUNeEngine appliqu´e `a la plateforme de cloud CloudEngine et aux applications qu’elle administre.

Compte tenu de la difficult´e d’´evaluation de certains aspects de l’administration (configuration, d´eploiement et reconfiguration par exemple), nous nous limitons dans ce chapitre aux aspects suivants : construction d’images de VM et leur enregistrement dans le cloud ; utilisation de TUNeEngine pour la r´eparation de VM dans le cloud ; et utilisation de TUNeEngine pour la gestion de ressources de l’IaaS et des applications entreprises.

Ce chapitre est organis´e de la fa¸con suivante : dans un premier temps, nous d´ecrivons les environnements mat´eriels et logiciels sur lesquels nous nous appuyons pour la r´ealisation de nos exp´erimentations. Ensuite, nous pr´esentons les r´esultats d’´evaluation de TUNeEngine pour la r´eparation de VM dans CloudEngine. Pour finir, nous pr´esentons l’´evaluation de l’utilisation de TUNeEngine pour la gestion de ressources de l’IaaS ainsi que celle des applications entreprises.

10.1. ENVIRONNEMENTS D’EXP ´ERIMENTATION 124

10.1 Environnements d’exp´ erimentation