UNIVERSITE DE YAOUNDE I

Faculté des Sciences Département d’Informatique BP 812 Yaoundé-Cameroun

UNIVERSITY OF YAOUNDE I Faculty of Science

Department of Computer Science P.O.Box 812 Yaoundé-Cameroon

Présenté et soutenu par

KITIO TSAMO Arielle 07U118

Sous la co-direction de :

Dr. Laurent BROTO Pr. Maurice TCHUENTE

Yaoundé, 2013

Déploiement et Configuration Autonomes d’Applications dans un Environnement

Mutualisé : Cas de Tune-Ng

Mémoire soutenu en vue de l’obtention du Diplôme de

Master en Informatique

Déploiement et Con�guration Autonomes

d'Applications Distribuées dans un Environnement

Mutualisé: Cas de Tune-Ng

Résumé

Les environnements d'applications distribuées deviennent de plus en plus complexes parce

que composés d'applications hétérogènes (patrimoniales 1) conçues avec des technologies éparses.

C'est le cas des plateformes mutualisées, notamment celles d'informatique dans le nuage 2,

(désignées par le terme cloud dans la suite) . L'administration de ces systèmes par des adminis-

trateurs humains présentent trois insu�sances majeures : le manque de réactivité , l'accroisse-

ment d'erreurs et le gaspillage en ressources autant matérielles, humaines qu'énergétiques.

Cette triple problématique donne naissance au concept d'Administration Autonome (AA) qui

consiste essentiellement en la délégation des tâches d'administration d'un logiciel à un autre

logiciel. Il existe des Systèmes d'Administration Autonome (en abrégé SAA) développés pour

l'administration des environnements distribués classiques (TUNe, Rainbow). Les essais d'util-

isation de ceux-ci dans le cloud ont montré des limites(gestion des machines virtuelles, ...).

Il existe également des SAA spéci�ques au cloud. Ces derniers utilisent majoritairement les

techniques de paravirtualisation ou de virtualisation complète pour satisfaire les besoins de

mutualisation du cloud. Ces techniques imposent généralement la manipulation de machines

virtuelles lourdes 3. Leur taille pourrait être considérablement réduite dans les environnements

typiquement linux, par l'utilisation de techniques de virtualisation basées sur les conteneurs.

En outre, la majorité de ces SAA sont non seulement spécialisés pour un panel d'applications

spéci�ques, orientés vers l'administration de l'infrastructure matérielle (au détriment des ap-

plications y déployées), mais n'o�rent pas des outils de haut niveau pour la modélisation des

architectures à déployer. Ce mémoire a un objectif double. Il présente une approche de concep-

tion d'un SAA adapté au cloud, couvrant les applications patrimoniales (utilisation d'images

dédiées), o�rant des outils de haut niveau (pro�ls UML) pour la modélisation des architec-

tures et permettant de réduire la taille des machines virtuelles manipulées (via le mécanisme de

DeltaSave). Ce mémoire présente également de présenter une plate-forme, Tune-Ng, en cours

de développement qui rend les services annoncés précédemment et qui permet de reduire de

4 fois en moyenne, la taille initiale des machines virtuelles pour les architectures J2EE par

exemple.

Mots clés : cloud computing, administration autonome, , déploiement d'applications, appli-

cations patrimoniales.

Abstract

The administration by humans of complex systems, including distributed application en-

vironments and cloud computing plaforms (called simple cloud in the rest of the document)

has three main disadvantages : the lack of reactivity, the increase in errors, and the wastage of

resources. Autonomous Administration Systems (AAS) are a solution to this triple problem.

Autonomous Administration refers to the administration of a software by another software.

There exist AAS developed for the administration of classical distributed environments and

which present several limitations when used in the cloud[26]. There equally exist cloud speci�c

1. Une application patrimoniale est une application n'ayant pas été conçue avec des facilités d'adminis-tration.

2. en anglais Cloud Computing3. taille OS + taille des packages des applications installées

1

AAS. These largely use para-virtualization or full-virtualization technics to meet up with cloud

mutualisation needs. These techniques generally impose the manipulation of heavy virtual ma-

chines whose sizes can be considerably reduced in typical linux environments using container

based virtualization technics. Also, the majority of AAS are not only specialised for a speci�c

panel of applications, but are also oriented towards the administration of material infrastruc-

tures, and do not o�er high level tools for modeling architectures to be deployed. This thesis

has a double objective. We propose a design approach of a cloud adapted AAS that covers

legacy applications (using dedicated images), that o�ers high level tools (UML pro�les) for

modeling architectures and that allows to reduce the size of the virtual machines that are

manipulated (via the DeltaSave mechanism). We also present a platform, Tune-Ng, which is

being developed and which o�ers the previously stated services and reduces by averagely 4

times the size of the initial virtual machines for a J2EE architecture (for example).

Key Words : cloud computing, autonomous administration, distributed systems, application

deployment, legacy applications.

1 Introduction

Le monde de l'Informatique actuel fait face à une diversité et une complexité sans cessecroissantes des supports, infrastructures et systèmes informatiques. Cette multiplicationde facteurs associée à l'essor des technologies du cloud, oriente la construction de nouveauxsystèmes informatiques complexes. L'administration continue et permanente de ces systèmescomplexes s'avère fastidieuse, très consommatrice en ressources et sujette à de nombreuseserreurs. Une approche prometteuse et largement adoptée pour résoudre ce problème estl'administration autonome proposée par IBM en 2003[26].

Les membres de l'équipe SEPIA, au sein de laquelle a été e�ectué le présent travail se sontpenchés sur cette problématique d'administration autonome dans les systèmes complexes,les environnements distribués. C'est ainsi que sont nés les projets Jade[9] et TUNe[20]. Jadea permis la validation de l'apport des systèmes d'administration autonome (en abrégé SAA)ainsi que l'apport du développement de SAA à base de composants. TUNe quant à luifournit des outils palliant aux limites de son prédécesseur Jade 4, notamment la complexitéliée à l'utilisation des modèles à composants.

La mission première de TUNe a donc été d'implanter, un système d'administration au-tonome (SAA) dont l'utilisation soit moins contraignante [26] (via la fourniture d'outils demodélisation de haut niveau).

Avec l'arrivée des technologies du cloud, l'équipe SEPIA et bien d'autres travaux ([12][25], ...) dans la littérature se sont interessés à l'administration dans le cloud. Le cloud étantun système complexe tout comme les environnements distribués ; il a été naturel de s'intér-roger sur l'adaptabilité des SAA aux tâches d'administration dans le cloud.

Les principes et avantages des SAA sont des reponses à certains besoins d'administra-tion dans le cloud. Cependant, certaines tâches particulières dont l'isolation, la virtualisa-tion(section 2.1.2) et les spéci�cités y associées ne sont ou pas totalement prises en comptepar les SAA classiques. En outre, les solutions adaptées au cloud existantes se sont ma-joritairement axées autour de la gestion de l'infrastructure matérielle (IaaS). On ne compteaucune solution portant sur l'administration autonome d'applications déployées sur les mid-dlewares tournant sur des IaaS. Ces solutions sont également caractérisées par une dualitéentre l'étendue du domaine métier/technique couvert et le degré de maturité des fonctionnal-

4. SAA o�rant les fonctionnalités d'administration telles que présentées par [18] et supportant l'admin-istration de logiciels patrimoniaux. Jade a permis la validation de l'apport des SAA ainsi que l'apport dudeveloppement de SAA à base de composants

2

ités o�ertes[12]. Ceci, constitue un frein à la mise en oeuvre de l'administration de n'importequelle application patrimoniale.

Le présent mémoire s'interesse donc à l'adaptabilité de ces SAA (TUNe en particulier) aucloud a�n, de pouvoir y administer tout type d'application virtualisable, prendre en compteles besoins spéci�ques du cloud dont la virtualisation et principalement la réduction de lataille des machines virtuelles manipulées.

Ce mémoire est résumé ainsi qu'il suit : , la section 2 de notre mémoire situe le contextede nos travaux en décrivant les tâches d'administration dans le cloud, puis les apports dessystèmes d'administration autonome dans la réalisation de ces tâches, ceux de TUNe enparticulier. Ceci amène, la présentation des approches classiques et leurs limites à la section3. Est énoncée par la suite, l'approche de solution proposée lors de nos travaux à cet e�et,suivie de la description de sa mise en oeuvre et évaluation respectivement dans les sections4 et 5. La section 6 clôture notre mémoire avec la présentation des perspectives de notrecontribution à court et à moyen terme.

2 Cloud et Administration Autonome

Nous présentons dans cette section les deux principales notions abordées dans ce mé-moire : cloud et l'administration autonome.

2.1 Le Cloud

Le terme �cloud � est communément utilisé en lieu et place de l'expression �Cloud�. De-vant le manque de consensus sur la dé�nition de la notion de cloud computing, reprenonscelle de CISCO[4] : Le Cloud Computing est une plate-forme de mutualisation informa-tique fournissant aux entreprises des services à la demande avec l'illusion d'une in�nité desressources. C'est donc un environnement mutualisé dont l'intérêt principal réside dans lefait que les entreprises ne paient que pour les services e�ectivement consommés.

La mutualisation consiste au partage d'un ensemble de ressources parmi des entreprisesclientes, ce qui augmente le taux moyen d'utilisation de ces ressources. La mutualisation ainsique les services à la demande sont donc les deux principes majeurs du cloud computing.

2.1.1 Organisation du cloud

Le cloud connait trois types distincts d'utilisateurs : l'administrateur du cloud (four-nisseur), les entreprises/clients (qui souscrivent des contrats d'utilisation auprès des four-nisseurs), les utilisateurs �naux (utilisateurs des applications d'entreprises).

Classi�cation

Il existe divers types de classi�cation de cloud dont les critères de reférence sont lapropriété(privé, public ou hybride), ou le type de service o�ert. C'est ce dernier typequi nous intéresse car il sépare mieux que les autres, la couche qui intéresse nous travaux :l'IaaS.

� Infrastructure as a Service (IaaS) : c'est le niveau le plus bas. Le fournisseurmet à disposition des clients l'infrastructure matérielle requise. L'unité d'allocationest généralement la machine virtuelle (MV) pour une gestion plus �ne des ressources.Dans cette catégorie, on retrouve : Amazon EC2/S3 5 pour les o�res commerciales et

5. http ://awsdocs.s3.amazonaws.com/EC2/latest/ec2-ug.pdf

3

OpenStack 6, OpenNebula 7 dans le domaine du logiciel libre ;

� Platform as a Service (PaaS) : le fournisseur met à disposition des API spéci�quesà son infrastructure matérielle. Il laisse aux entreprises, la maitrise des applicationsqu'elles y déploient, installent et utilisent. Cependant, l'entreprise est tenu d'implé-menter ses applications suivant ces API. Dans cette catégorie, nous pouvons citer :Google App Engine 8, Microsoft Azure 9 ;

� Software as a Service (SaaS) : il s'agit du niveau le plus haut dans lequel le cloudfournit directement les applications �nales à ses clients. Le fournisseur administre lesapplications �nales et le rôle d'administrateur du client est sensiblement nul. Con-trairement à l'IaaS, il est très spécialisé. Ici se retrouvent les fournisseurs de solutionsde réseaux sociaux, de CRM, d'outils de bureautique et de messagerie en ligne parexemple.

2.1.2 Les dé�s actuels

Le cloud computing n'est pas une révolution technologique, mais une orientation vers unmode de gestion des infrastructures informatiques des entreprises[5]. Le cloud comporte donctous les problèmes classiques retrouvés dans les infrastructures usuelles dont : la toléranceaux pannes, la sécurité, l'interopérabilité et la portabilité d'applications entre clouds. Toute-fois, le principe d'hébergement d'applications de di�érents utilisateurs avec des ressourcespartagées amène des dé�s supplémentaires notamment l'administration et l'isolation desmachines virtuelles. Ce sont les deux dé�s auxquels nous nous sommes intéressés dans nostravaux.

L'isolation

La mutualisation dans les clouds publics est une source d'interférences d'accès auxressources partagées. Ceci accroit le besoin d'isolation. L'isolation est un concept qui garan-tit l'intégrité de chaque utilisateur vis-à-vis des autres. Dans le cloud, elle est mise en oeuvrede deux manières :

� l'isolation par la réservation entière de ressources[26] : le cloud public étant basésur le principe de mutualisation, cette approche n'est ni raisonnable, ni béné�que dansla mésure où, à tout instant le fournisseur alloue à chaque entreprise des ressourcesphysiques pour un usage exclusif (équipements réseaux, bande passante entre autres) ;

� l'isolation par la virtualisation : basée sur l'utilisation de machines virtuelles,la virtualisation garantit une isolation et ayant les mêmes performances au niveaudes MV qu'au niveau des machines réelles (appelées noeuds). Dans le domaine dudéploiement, elle permet également d'éviter le problème de con�its de dépendancesqui survient lors de l'installation sur un même noeud de plusieurs applications ayantdes dépendances con�ictuelles (e.g voire [3]). Il existe plusieurs techniques de virtual-isation 10. Le choix de l'une d'elles induit des tâches d'administration particulières etin�ue considérablement sur les performances de l'IaaS.

6. http ://www.openstack.org7. http ://www.opennebula.org/8. http ://code.google.com/appengine/9. http ://www.microsoft.com/windowsazure/10. http ://hal.inria.fr/docs/00/20/40/19/PDF/RR-6409.pdf

4

Administration dans le cloud

Les tâches d'administration dans le cloud sont réparties entre les fournisseurs et lesentreprises. Pour ces deux utilisateurs, on retrouve pratiquement, les mêmes opérations.Ce sont essentiellement[26][12] : la reservation et allocation de ressources, le monitoring, laconstruction d'images (pour les entreprises), la con�guration et le démarrage des machinesvirtuelles, le déploiement et la recon�guration dynamique d'applications et de MV. Nousprésentons ci-dessous, celles de ces tâches que nous avons abordées dans ce mémoire :

� A1 : Déploiement : il consiste en la copie et sauvegarde des systèmes de �chiers desMV (appelés images) sur les noeuds distants sous forme de MV. Le déploiement deMV peut être explicite (initié par l'entreprise) ou implicite lors de l'installation d'unlogiciel ;

� A2 : Con�guration et démarrage de MV : la con�guration des machines virtuellesprécède le démarrage de celles-ci. Elle utilise les caractéristiques renseignées par l'en-treprise lors de la réservation des MV. L'une des complexités majeures ici réside dansle nombre de paramètres à renseigner, leur variété ainsi que le moment où ils peu-vent/doivent être renseignés pour chaque MV.Le démarrage quant à lui , dépend de la nature des logiciels déployés sur les machinesvirtuelles et de la politique d'allocation du fournisseur. Il est courant que le démarraged'un logiciel obéisse à un ordre précis ;

� A3 : Construction et déploiement d'images et MV : c'est une tâche dévolue àl'entreprise. La construction d'images utilisées pour la création des machines virtuellesconstitue une véritable problèmatique pour l'entreprise. En e�et, en plus de résoudre leproblème de dépendances entre les applications à déployer sur les MV et les librairiesdont elles ont besoin, la technique de construction d'images choisie doit garantir quela taille de ces images est plus ou moins petite a�n d'assurer de bonnes performanceslors de leur manipulation ;

� A3 : Recon�guration dynamique : elle englobe deux tâches principales : la con-solidation et la réparation de pannes. La consolidation (redimensionement[26]) a pourobjectif premier, d'optimiser les gains lors de l'allocation et réduire le gaspillage demachines pendant l'exécution. Étant donné la propriété de non-intrusivité de l'IaaS, lesoptions de réparation de pannes o�ertes couramment par les IaaS sont le redémarrageinitial de la MV ou le redémarrage à partir du dernier point de sauvegarde.

2.1.3 Synthèse

Les tâches d'administration dans le cloud tournent toutes autour de la gestion e�cacedes machines virtuelles. Compte tenu de la taille 11 du cloud , il s'avère coûteux et très risquéde con�er ces tâches en continu à des administrateurs humains.

En ce sens, les SAA pourraient améliorer considérablement l'administration dans le cloudau niveau des deux principaux utilisateurs (fournisseur, entreprise).

Nous présentons donc dans la section suivante le concept de SAA en général et les apportsdu système d'administration autonome TUNe en particulier.

2.2 Administration Autonome

L'administration autonome est l'administration d'un logiciel (patrimonial ou non) parun autre logiciel. Un tel logiciel est alors utilisé pour installer, déployer et con�gurer les

11. Taille du cloud : ensemble constitué de la multitudes d'utilisateurs, clients, applications et ressourcesmatérielles

5

logiciels administrés. Ce logiciel peut également observer l'environnement d'exécution et leslogiciels qu'il administre, et réagir à des événements comme des pannes ou des montées de lacharge, a�n de recon�gurer les logiciels de façon autonome (sans intervention humaine). Lessystèmes d'administration autonome(SAA) permettent de façon e�cace, à grande échelle :

� d'assurer une réactivité spontanée face aux pannes ou besoins de recon�guration etdonc la disponibilité continue des services ;

� de garantir la �exibilité du système avec comme avantage, la facilité dans le passageà l'échelle ;

� de limiter les erreurs : l'administration des systèmes complexes passe par la création etmise à jour de pléthore de �chiers de con�guration. Parce que fastidieuse et requérantde la minutie, leur mise à jour continue et permanente par des administrateurs humainsest source d'erreurs ;

� de réduire le gaspillage en ressources (matérielles, énergétiques, logicielles). En e�et,pour garantir la continuité de services, les administrateurs humains sont amenés àsurévaluer les ressources.

À titre d'exemple, nous avons les SAA suivants : Rainbow 12[7], Accord[15], TUNe[20],Unity[6], Pragma[21] et Cascada[19].

2.2.1 Les tâches d'administration

On entend par administration autonome d'applications, deux concepts[5] notamment ledéploiement et la recon�guration :

� le déploiement. Il comprend le déploiement proprement dit (copie des �chiers etbinaires du logiciel sur les di�érents noeuds distants) et sa con�guration. La con�g-uration consiste en la dé�nition des paramètres 13 requis pour le bon fonctionnementdu logiciel. Elle peut varier d'un noeud à un autre suivant les spéci�cités de ceux-ci(système de �chiers répartis ou non, architecture, ...) ;

� la recon�guration regroupe toutes les opérations qui modi�ent l'architecture logi-cielle. Les principales sont la réparation et l'optimisation. La réparation vise à remettreen marche un logiciel défaillant tandis que l'optimisation permet à une application des'adapter à l'environnement (qui peut varier au cours du temps) dans lequel elle estdéployée.

2.2.2 Approches de developpement de Système d'Administration Autonome

Dans cette section, nous présentons de façon sommaire les concepts communément util-isés pour l'implantation des SAA. Nous présentons par la suite, TUNe en particulier pourdeux raisons principales. En comparaison aux autres SAA[26], TUNe est l'un des seuls sys-tèmes qui gère les applications patrimoniales et qui fournit des outils de haut niveau pourla modélisation d'architectures. En outre, TUNe est le système développé par l'équipe danslaquelle se sont déroulés ces travaux. Comme la majorité des SAA, il est basé sur un modèleà composants [12].

Système d'Administration Autonome basé sur les composants : Généralités

Le principe général repose sur l'encapsulation des éléments administrés dans des com-posants et l'administration de l'environnement logiciel comme une architecture à composants

12. Ne fournit pas les fonctions déploiements de logiciels : Conçu pour l'administration d'applications déjàinstallées et en cours d'exécution13. (modi�cation de ces �chiers, positionnement de variables)

6

(Fractal[11], JMX, OpenCOM, ...).En pratique, l'utilisation des SAA basés sur les composants requiert de l'administrateur,

une maitrise parfaite de la programmation à base de composants ainsi que des frameworkset API associés. Ceci constitue un frein à leur utilisation[26].

Utilisation des langages

Pour la description et le déploiement de l'environnement (logiciel et matériel) à ad-ministrer, les SAA utilisent généralement des langages et scripts de déploiement. Ces lan-gages sont encore appelés ADL(Architecture Description Language). C'est le cas du langageAcme 14[8] utilisé par Rainbow et du langage SIDL utilisé par Accord[26].

Pour ce qui est de la recon�guration dynamique, les SAA se fondent sur les règles ECA(Event Condition Action) pour implanter leurs politiques de recon�guration. Des langagessont également utilisés à cet e�et, à l'instar du langage Stich utilisé par Rainbow. TUNequant à lui o�re un langage proche des diagrammes d'état-transition d'UML : baptisé Recon-�guration Description Language (RDL) [20]. En e�et, la manipulation directe des langagesest fastidieuse.

Il existe cependant un formalisme pour la description d'application distribuée dans lecloud, par exemple OVF (Open Virtualization Format)[13] qui présente encore des insu�-sances relatives à la description d'architectures réparties [14]. Des acteurs tels que VMware,Citrix, proposent déjà des plates-formes capables de déployer des paquetages au formatOVF. Il manque cependant à OVF un support pour la description d'architectures réparties,toutefois des évolutions d'OVF permettent la con�guration dynamique des liaisons réparties[14].

Cas de TUNe

TUNe[20] acronyme de Toulouse University Network est un SAA qui porte le nom duprojet qui lui a donné naissance en 2008. C'est l'un des seuls SAA en dehors de Rainbow[7]adaptable à tout type d'application. TUNe est une évolution de Jade[9] et fournit un formal-isme de haut niveau pour les principales tâches d'administration. En e�et, la manipulationdirecte des langages est verbeuse et fastidieuse pour des architectures à grande échelle (casde Diet 15[10]). TUNe implante donc des langages d'administration basés sur les pro�ls UML,donc plus accessibles aux utilisateurs non initiés aux modèles à composants. Il dé�nit troislangages couvrant les caractéristiques décrites par [2] :

1. Architecture Description Language (ADL) : il s'appuie sur le diagramme declasses dé�ni par UML. TUNe permet de décrire l'architecture de l'application admin-istrée ainsi que la plate-forme matérielle sur laquelle elle sera déployée. Pour ce faireil o�re deux diagrammes de classes :� un diagramme qui représente au moyen d'une classe, chaque type de logiciel quicompose l'application. Chaque classe possède un ensemble d'attributs spéci�quesau type de logiciel ou non ;

� un autre diagramme qui modélise l'environnement matériel d'exécution. Ici uneclasse est vue comme un regroupement de machines (cluster) présentant des pro-priétés identiques ;

Cet ADL permet également de dé�nir des interconnexions entre les classes, selon lasémantique proposée par le formalisme UML[17] ;

14. Acme associé au modèle de composants Acme15. Diet est une application large échelle de calcul scienti�que sur grilles de calcul, dont la structure

hiérarchique et modulaire lui permet de supporter un grand nombre de noeuds de calcul

7

2. Wrapping Description Language (WDL) : utilisé pour dé�nir l'ensemble desopérations supportées par chaque type de logiciel. Une opération est dé�nie par sonnom, une méthode java qui l'implémente et un ensemble de paramètres ;

3. Recon�guration Description Language (RDL) : c'est un formalisme de dé�nitiondes politiques d'administration (recon�guration), basé sur le principe des diagrammesd'états-transitions dé�nis par UML. Chaque état correspond soit à la modi�cationd'attributs des entités dé�nies via l'ADL ou à l'exécution d'une opération décrite dansle WDL.

3 Approches classiques et leurs limites

Comme dit en section introductive de ce mémoire, nos travaux sont basés sur le systèmed'administration autonome TUNe. Dans cette section, nous commençons par présenter leslimites de TUNe vis-à-vis des essais d'apatation au cloud, puis les insu�sances des IaaS exis-tants pour gérer de manière e�ciente les machines virtuelles et un large panel d'applicationsarbitraires.

3.1 Adaptation de TUNe

Au travers d'expérimentations consistant à déployer à l'aide de TUNe des applicationsgrande échelle comme Diet, les applications virtualisées (J2EE) et déploiement dans le cloud,il ressort maintes insu�sances :

1. P1 : le paquettage des applicationsPour chaque type de logiciel, l'administrateur via TUNe fournit une archive (format.tgz ) contenant l'application à déployer ainsi qu'un wrapper(�chier xml) contenantles paramètres de con�guration de ladite application. L'archive et le wrapper sont àdéployer sur les noeuds de la plate-forme matérielle.� dépendances des librairies : ces noeuds ont des systèmes d'exploitation hétérogènesdont l'état(version de l'OS, librairies installées) est méconnu lors du paquettagedes applications. Cette méconnaissance peut conduire à l'échec du déploiement del'archive et pour cause, la non résolution de certaines dépendances aux librairiesrequises ;

� écriture du wrapper : l'écriture du wrapper (via le WDL) pour la con�gurationd'application, s'avère fastidieuse pour les architectures de grande échelle ;

2. P2 : gestion des machines (regroupement en cluster)Les opérations de maintenance (dans le cloud, Diet) peuvent entrainer le retrait (ex-tinction) ou l'ajout de machines. La gestion de charge est un exemple qui peut causerl'ajout de machine(s) en cas de surcharge ou le retrait en cas de baisse d'activité.Comme dit plus haut les machines dans TUNe ne sont pas traitées de façon individu-elle car regroupées en cluster. TUNe ne permet donc pas la dé�nition de la politiquepermettant l'arrêt ou le démarrage d'une seule machine ;

La gestion des politiques de recon�guration est sujette aux mêmes limites que cellesdes machines.

3. P3 : insu�sances de l'ADL pour les machinesUne machine virtuelle (dans le cas de Diet et du cloud) est à la fois une machine etun logiciel. TUNe ne permet pas l'expression de cette double identité car ses langagesdi�érencient les machines des logiciels.

8

3.2 Gestion d'applications patrimoniales

Les solutions actuelles dédiées à l'administration autonome d'applications dans le cloudsont caractérisées par une dualité importante entre, le degré de maturité des fonctionnalitésd'administration o�ertes et l'étendue du domaine métier ou technique couvert. En e�et,certaines solutions privilégient l'étendue du domaine technique/métier couvert, au détri-ment des fonctionnalités proposées (cas de Microsoft Azure qui se focalise sur l'automa-tisation d'un ensemble restreint d'opérations d'administration d'applications basées sur latechnologie Microsoft). D'autres par contre, se focalisent sur un nombre important de fonc-tionnalités appliquées à un domaine métier ou technologique réduit (cas des services deSalesforce.com 16 qui sont dédiés à la gestion de la relation cliente : CRM). Cette dualité estcausée par l'utilisation de scripts de con�guration spéci�ques, qui pourraient être remplacéspar une abstraction de plus haut niveau, basée sur un modèle de l'application administrée. Ilexiste cependant des approches intermédiaires qui essaient de concilier ces deux contraintes(Amazon Elastic 17, Google App Engine, Cloud Foundry 18). Cependant elles ne rompentpas cette dualité en permettant l'administration autonome de n'importe quelle applicationpatrimoniale virtualisable.

Lors du développement de la plate-forme VAMP[27], [12] a démontré en 2012 le caractèrearti�ciel de cette dualité en se concentrant sur les aspects relatifs à la gestion du déploiementinitial des applications (�gure 5).

Il existe en outre, des solutions ayant acquises une notoriété dans le domaine de l'ad-ministration autonome des machines IaaS ; VDirector 19 en est l'outil phare. Cependant, iln'existe pas actuellement de solutions s'intéressant à l'administration des applications dé-ployées sur des middlewares tournant au dessus de ces IaaS (à l'exemple des applicationsdéployées sur des serveurs Apache ou servlets Tomcat). On parle de la non-intrusivité [26]de l'IaaS dans la couche Entreprise. Cette propriété rend impossible la gestion des pannesliées aux logiciels exécutés sur les MV sans la collaboration de l'entreprise.

Nous nous intéressons donc à la problématique du déploiement autonome et �able demiddlewares ou d'applications réparties s'exécutant sur les MV dans plateforme de cloud.Ceci, indépendamment des domaines métiers qu'elles adressent ou des choix de conception,de réalisation à elles associés. Ceci constitue notre problème P4.

3.3 Synthèse

Les problèmes décrits dans cette section se résument en trois points :� l'intégration de la gestion de machines virtuelles (vis-à-vis de TUNe) ;� l'administration intercouche middleware-application ;� la prise en charge d'applications patrimoniales et utilisation d'outils haut niveau demodélisation d'architectures.

Notre problématique est donc la fourniture d'un SAA spécialisé pour la gestion de l'in-tercouche middleware-application (sans restriction sur la nature d'applications), béné�ciantdes avantages de TUNe à savoir les modèles et celles des machines virtuelles pour l'isolation ;tout en assurant la légèreté de celles-ci pour garantir de meilleures performances au système.

16. http ://www.salesforce.com/17. http ://aws.amazon.com/ec2/18. http ://www.cloudfoundry.com/19. http ://www.vmware.com/products/vcloud-director/

9

4 Notre Approche

Le système que nous proposons est composé de trois couches, lesquelles couches satisfontles insu�sances relevées :

� couche 1 (Editor) ou environnement d'édition : constituée du support langage pourla description des architectures ;

� couche 2 (Deployer) ou environnement d'exécution : constituée des outils de création,con�guration et déploiement des images et de machines virtuelles ;

� couche 3 (Dashbord) ou de contrôle : permet le suivi des applications déployées.Ceci facilite les tâches d'optimisation liées à celles-ci. La couche Dashbord renseignenotamment sur l'état desdites applications : démarrée ou non, charge CPU utilisée, lenombre de fois qu'elle a été redémarrée...

L'approche générale se décline ainsi qu'il suit :� l'intégration de la gestion de machines virtuelles via le dévelopement de la couche 2.A�n d'assurer la gestion e�cace des machines virtuelles au niveau cette couche, nousinstaurons l'utilisation d'images dédiées présentées en section 4.1. Elles permettenten outre l'encapsulation d'applications patrimoniales. Nous optons en raison desperformances o�ertes (développées en section 4.1.1), pour les solutions de virtualisa-tion basées sur l'utilisation des conteneurs. Sur la base de ce type de virtualisation,nous developpons un système d'images réduites (appelé DeltaSave) pour améliorerdavantage les performances du SAA. Ce aspect est décrit à la section 4.1.2.Nous comptons par la suite, prendre en compte les principaux hyperviseurs commerci-aux actuels (n'utilisant pas les conteneurs). Pour ce faire, nous utilisons des techniquespermettant la portabilité des machines virtuelles entre hyperviseurs ;

� la simpli�cation du procédé de con�guration d'applications et d'architectures avecTUNe par rapport à l'utilisation des wrappers. Ceci est fait en reécrivant son systèmede con�guration basée cette fois sur l'utilisation de clés de con�guration appeléesjockeys (voire sections 4.2 et 5.2.2) ;

� le dévelopement et l'intégration de la couche DashBoard pour le suivi des applicationsdéployées (sur des middleware) basée sur l'usage de sonde intégrée aux applicationsdéployées. Une sonde ici désigne un jockey spécial qui fait référence à un script per-mettant de véri�er l'état d'une application donnée ;

� la modi�cation des modèles de TUNe notamment pour la dé�nition de la doubleidentité des MV et leur intégration à la couche d'édition pour la modélisation desarchitectures.

Nous nous concentrons dans la suite de cette section sur les problèmatiques P1, P2 et P4.

4.1 Intégration de la gestion des machines virtuelles

L'utilisation des machines virtuelles dans le cloud est déjà en soi une solution au problèmeP1 de dépendances de librairies soulevé par TUNe. En e�et nous proposons la constructiond'images dédiées. Le principe de l'image dédiée est d'encapsuler une application avec leslibrairies requises à son bon fonctionnement dans une machine virtuelle.

L'application (archive .tgz) qui était directement déployée par TUNe sur les systèmes d'-exploitation des noeuds (�gure 1-(a)), est dorénavant déployée et con�gurée dans l'OS d'unemachine virtuelle. C'est cette dernière (�gure 1-(c)) qui sera déployée sur le noeud. Ainsi,aucune modi�cation sur la machine réelle ne peut atteindre, ni altérer le fonctionnement (lesdépendances satisfaites) de ladite application sur sa machine virtuelle. Chaque image crééeest sauvegardée puis publiée dans l'IaaS individuellement (résolution du problème P2). Unecopie modi�ée est alors utilisable pour la création de plusieurs machines virtuelles.

10

L'utilisation d'images dédiées présente l'inconvénient d'être coûteuse. En e�et, parce quelourdes 20 (e.g : 1Go dans le cas de la plate-forme VAMP[27]), le temps utilisé pour leur ma-nipulation est élevé. Nous proposons une approche basée sur la virtualisation niveau noyauet le mécanisme DeltaSave (section 4.1.2).

Figure 1 � Résolution de dépendances

4.1.1 Choix de la technique de virtualisation

Les administrateurs ont tendance à utiliser les hyperviseurs 21. Cette tendance est jus-ti�ée au vu des avantages qu'o�re la paravirtualisation 22. La virtualisation niveau noyau,basée sur l'usage de conteneurs s'avère être une approche très légère par rapport aux tech-niques de virtualisation utilisées communément. C'est celle choisie pour notre SAA.

Les conteneurs et les machines virtuelles ont en commun de permettre d'avoir sur unemachine physique plusieurs partitions isolées. La di�érence entre ces deux concepts et lesavantages indéniables de l'isolation niveau noyau sont inhérents à la technique de partion-nement. Nous désignons cette technique dans la suite du document avec le sigle VPC pour :Virtualisation Par Conteneurs. Nous présentons ci-dessous les critères ayant orientés notrechoix :

1. Le concept de noyau unique : la paravirtualisation, la full-virtualisation et lavirtualisation assistée par le matériel o�rent la possibilité d'exécuter di�érents OS surun même serveur. À l'inverse de ceux-ci, dans les systèmes basés sur la VPC, on disposed'une seule instance noyau au dessus de laquelle s'exécutent plusieurs instances isoléesde blocs de programmes utilisateur. Cette approche est plus légère que l'usage desmachines virtuelles proprement dit. En e�et, la pile logicielle liant les applications aumatériel pour l'exploitation des ressources est réduite d'où de meilleures performances.

2. Systèmes de �chiers : le système de �chiers root d'un conteneur est tout simplementun répertoire situé dans le système hôte 23. Aucun frais supplémentaire n'est doncinduit par les opérations d'entrée/sortie. Le backup et la restauration des conteneurssont triviaux et se résument au simple archivage des images. On retrouve dans cerépertoire root, les répertoires usuels notamment etc, lib, bin, etc. L'administrateur adonc une vue globale sur tous les �chiers et le déploiement en masse est facilité ;

3. Réseau : des études de performances réseaux [22][24] comparant la vitesse et consom-mation de ressources pendant les opérations de migration des machines virtuelles enutilisant la paravirtualisation et la VPC met en évidence les meilleures performancesde cette dernière ;

20. taille de l'OS + taille de l'application21. Un hyperviseur est une plate-forme de virtualisation qui permet à plusieurs systèmes d'exploitation

de travailler sur une même noeud en même temps22. http ://hal.inria.fr/docs/00/20/40/19/PDF/RR-6409.pdf23. Il n'a donc pas besoin de partition particulière, ni de disque supplémentaire pour un conteneur

11

4. Gestion de la mémoire : comme pour le réseau, l'OS de chaque machine virtuellepense qu'il gère du matériel, la mémoire RAM y compris. Par contre pour les con-teneurs, seul le noyau a la charge de ces opérations. Ainsi, pas besoin de pré-allouerde la mémoire à un conteneur à son démarrage : l'allocation est faite à la demande.L'échange est aussi rapide que sur un système non virtualisé [24] ;

5. Performances généralesL'usage des conteneurs est d'autant plus rapide qu'il ne nécessite par le démarragede système d'exploitation ; le noyau hôte est déjà en marche. Des études et tests ontété consacrés à cette comparaison des performances entre les autres techniques devirtualisation (principalement la para-virtualisation) et la VPC. Les critères ont étéentre autres la consommation des ressources (CPU, mémoire, ...)[23][24], le tempsde migration[16], la gestion du réseau[22]. Ces études permettent toutes, grâce à desrésultats de référence, de mettre en évidence les meilleures performances des systèmesde VPC comparément aux hyperviseurs.

Partant de l'hypothèse de l'usage d'un seul type de système de �chiers, la virtualisationbasée sur l'usage des conteneurs o�re des meilleurs performances que les hyperviseurs. Cettehypothèse est la principale limite de la VPC.

C'est de cette étude, que nous portons notre choix en première approche, sur le conceptde virtualisation par les conteneurs pour notre SAA. Ce choix nous garantit d'ors-et-déjàde meilleures performances que les hyperviseurs et des images de tailles réduites dans notrecontexte (environnement typiquement Linux).

4.1.2 Gestion des images

Généralement, sauvegarder l'ensemble des images dédiées s'avère inutile. Les imagessont essentiellement les mêmes, avec un nombre relativement restreint de �chiers ajoutés oumodi�és.

Modèle de stockage

Notre approche : DeltaSave , est donc de ne garder que la di�érence entre un conteneurde base (ContainerBase dans la �gure2) contenant la majorité des librairies utilisées par laplupart des programmes et les librairies ainsi que les exécutables requis pour cette image enparticulier. Ce principe est illustré ci-dessous à la �gure 2.

Figure 2 � Approche DeltaSave pour le stockage d'images

Soient :� O le contenu de l'OS de base (�gure2-a) et o sa taille, C le contenu du Container_Base et c sa taille ;

� n, le nombre d'applications à déployer. On aura n images dédiées ;

� Ai les �chiers spéci�ques de l'application i, et ai la taille de l'application proprement dite :

12

� Li, l'ensemble des librairies dont a besoin Ai ;

� Lio et Lic les ensembles de librairies à ajouter à O, C respectivement, lors de l'installation de Ai ;

On a :

Lio = Lic ∪ θi avec ∃i, j/ i 6= j, θi ∩ θj 6= ∅

La relation entre le ContainerBase (C) et les OS invités (O) des MV (appelés 'OS de base' dans la

�gure2-a) est la suivante :

C = O ∪n⋃

i=1

θi ∪ ε

Où ε est l'ensemble des librairies ajoutées à C et non utilisées par les Ai

Avec le stockage classique (�gure 2-(a)), l'expression de l'espace disque Eo consommé est donnée par la

formule :

Eo = (n ∗ o) +

n∑i=1

ai + lio ;

avec l'approche DeltaSave (�gure 2-(b)), nous avons l'expression de l'espace consommé Ec :

Ec = c+

n∑i=1

ai + lic ;

Dans le pire des cas, les applications sont très disparates (du point de librairies). En d'autres termes, C ne

contient aucune des librairies requises par les Ai : ∀i, 1 ≤ i ≤ n, Lio = Lic. On alors :

Eo = (n ∗ o) +

n∑i=1

∆i et Ec = c+

n∑i=1

∆i avec ∆i = ai + lic = ai + lio;

Pour observer le gain engrangé par l'utilisation du DeltaSave, il convient de trouver en pratique, la valeur

seuil de n (appelée s) à partir de laquelle le containerBase pèse moins que n OS de base :

∃s ≤ n, / ∀x ≥ s , c ≤ (x ∗ o) (1)

Principe de manipulation : 'As a CD Live'

Pour manipuler l'image entière, nous utilisons un principe proche de celui utilisé pour lesCD Live, tels que Knopsis, Ubuntu. En e�et : Un CD Live contient un système d'exploitationamorçable (containerBase) généralement protégé en écriture. Au moment du boot à partirdu CD Live (sollicitation du containerBase), le système crée un espace de travail temporaire(delta) dans la mémoire RAM, puis monte en union son système de �chier sur le systèmede �chiers du CD (containerBase en l'occurence). Après un chroot dans l'espace monté(delta + containerBase), l'utilisateur a l'illusion de travailler sur un OS complet (celui decontainerBase). Il peut alors modi�er les �chiers système à sa guise, les modi�cations sontécrites sur le système de �chiers RAM (delta + containerBase).

4.2 Con�guration de machines virtuelles et applications patrimo-niales

Chaque machine virtuelle comprend des paramètres de con�guration. Certains concer-nent des aspects de con�guration locale , d'autres participent à la dé�nition d'interconnexionentre éléments distants (adresse IP et port d'accès à un serveur, ...). Selon leur nature, cesparamètres peuvent être renseignés pendant la création de l'image (paramètres statiques),

13

Figure 3 � Manipulation des im-ages et MV avec le principe 'As aCD Live'

auquel cas ils sont gérés par le gestionnaire de déploiement (voire �gure 4), ou après l'instan-ciation des machines virtuelles (paramètres dynamiques) renseignés par un con�gurateur aumoment de l'auto-con�guration.

C'est également le cas pour les applications déployées sur ces machines. En e�et, desparamètres (jockeys) sont ajoutés aux images pour lesquelles elles sont dédiées. Pour l'essen-tiel, ils permettent la con�guration et le contrôle d'activité des applications. Leur gestionest détaillée à la section 5.2.2.

4.3 Tune-Ng

Nous proposons le développement d'un portail web (Tune-Ng) qui automatise le dé-ploiement et la con�guration automatiques, d'applications patrimoniales virtualisables ausein d'un IaaS. Ladite plate-forme implante également les concepts de légèreté présentés ensection 4.1.

Nous utilisons donc les images dédiées également introduites à la section 4.1. Elles sontinstanciées sous forme de machines virtuelles. Chaque image se compose de briques tech-niques (système d'exploitation, intergiciels), et de briques fonctionnelles (données et logicielsapplicatifs). Une fois instanciées, les MV font l'objet d'une phase de con�guration dynamiqueindividuelle qui, �nalise le paramétrage de l'application répartie.

4.3.1 Architecture générale de Tune-Ng

Conformément à la section précédente, l'architecture générale de Tune-Ng est la suiv-ante :

� couche1 : Editor. C'est cette couche qui permettra la modélisation des architecturesà déployer. Elle o�rira des pro�ls UML comme ceux de TUNe pour décrire les entitéslogicielles consituant ladite architecture via des diagrammes de classes, ainsi que lespolitiques de recon�guration à l'aide de diagramme d'états-transition. Elle commu-nique avec la couche sous-jacente (couche d'exécution) par l'interpréteur ;

� couche2 : Deployer. Cette couche permet le déploiement et la con�guration des ar-chitectures décrites à la couche 1 sur la plate-forme matérielle représentée . La couched'exécution est constituée de quatre unités applicatives :� l'interpréteur : établit la liaison entre la couche d'édition et le service de déploiement.Il communique les informations extraites des diagrammes de la couche d'éditionà l'unité de déploiement pour la création et déploiement des machines virtuelles

14

Figure 4 � Architecture globale de Tune-Ng

correspondantes ;� l'unité de création d'images : permet la construction des images dédiées utiliséespour la création des machines virtuelles ;

� le con�gurateur : con�gure les machines virtuelles avec les paramètres générés lorsde leur création ou renseignés pendant la création de l'image associée ( collaborationavec l'unité de déploiement) ;

� l'unité de déploiement : permet de déployer et démarrer sur les noeuds des MVcorrespondantes aux spéci�cations envoyées par l'interpréteur.

� couche 3 : Dashbord pour le suivi de l'état des applications déployées sur les machinesvirtuelles.

5 Mise en oeuvre de la couche Deployer de Tune-Ng

Pour mettre en oeuvre notre approche sus-présentée, nous prévoyons deux étapes. Lapremière consiste au développement de la couche d'exécution et la seconde consiste en l'in-tégration de la couche d'édition, ainsi que la couche de contrôle.

Lors de la mise en oeuvre de la couche 2, nous nous interessons particulièrement audéploiement autonome d'applications réparties. La �gure 5 reprend le cycle de vie du dé-ploiement d'applications et les transitions associées, proposée par le canevas de [1]. Lesétapes en bleu, désignent celles relatives au déploiement initial, étudiées.

Notre contribution ici, est l'écriture d'un système de création d'images, d'un système deréduction de taille d'images, d'un système de con�guration d'images (machines virtuelles)et d'un système de déploiement de MV dans un environnement mutualisé.

Compte tenu du temps imparti à notre période de travail, nous n'avons pu terminer ledeveloppement des couches 1, 3. Leur intégration complèteentre dans les perspectives de nostravaux.

15

Figure 5 � Cycle de vie d'une application lors de la phase de déploiement

5.1 Conception de Tune-Ng

On distingue trois rôles utilisateurs : �nalUser, imageManager et administrator quipeuvent e�ectuer les tâches suivantes respectivement :

� �nalUser peut créer, con�gurer et déployer une machine virtuelle ou une architecture ;� imageManager : gestionnaire d'images. Il peut créer, con�gurer, sauvegarder, publierles images dédiées qu'utilisent les �nalUser pour créer leurs machines virtuelles ;

� administrator, c'est l'administrateur de Tune-Ng. C'est le seul à manipuler directementles machines réelles (noeuds). Il peut donc ajouter, con�gurer et véri�er la con�gura-tion interne d'un noeud.

L'administrator peut e�ectuer toutes les opérations de l'imageManager et ce dernier peute�ectuer celles du �nalUser. Les opérations o�ertes à ces utilisateurs sont regroupées enquatre services (couche Deployer de la �gure 4) à savoir l'interpréteur, le service de créationd'images, le service de con�guration (con�gurateur) et le service de déploiement. La mod-élisation suivante décrit les composants de notre système ainsi que la communication entreeux suivant le formalisme ci-dessous :Dé�nition d'un paramètre

Parametres = nomParametre −→m

valeur

Dé�nition d'une valeur de retour ;

Retour = nomRetour −→m

valeur

Dé�nition de l'Interface d'un service ;

I = (Nom,Parametres, Service, g)

g : Parametres → Service

v 7→ g(v)

De�nition d'un service o�ert ou requis par une interface d'un composant. Il prend des paramètres (Parametres) et renvoie unRetour correspondant au service demandé.

Service = (Parametres,Retour, f)

Parametres → Retour

s 7→ f(s)

Dé�nition de composant : Un composant dispose d'un ensemble d'interfaces requises, et d'un ensemble d'interfaces o�ertes

Composant −→m

I;

Composant = (NomComposant,< I >,< I >)

16

Dé�nition de la communication entre composants C1 et C2 : le composant C1 envoie les paramètres VarEns pour obtenir

le service S de C2

C1 ∗ V arEns → C2 ∗ S selon la signature suivante :

Composant ∗ Parametres → Composant ∗ Service

Le système entier SI est fait de trois composants principaux :

SI = < Editor, Deployer, DashBoard >

Le composant Deploy quant à lui est également fait de quatre composants :

Deployer = < Interpretor, Configurator, DeployUnit, ImageUnit >

Editor = (Editor,< modeliserArchitecture >,< recuperer_ProfilUml_Architecture >)

DeployUnit = (DeployUnit,< recuperer_ProfilUml_Architecture, obtenirImage >,

< creerArchitecture, creer_MachineV irtuelle >)

Configurator = (Configurator,< recuperer_Architecture, recuperer_MachineV irtuelle >,

< configurer_MachineV irtuelle, configurer_Architecture >)

ImageUnit = (ImageUnit,<>,< envoyerImage, creerImage >)

De�nition des interfaces de communication

Interpretor → Editor ∗ recuperer_ProfilUml_Architecture

DeployUnit → Interpretor ∗ interpreter_ProfilUML

DeployUnit ∗ IdentifiantImage → ImageUnit ∗ recuperer_Image

DeployUnit ∗ Image ∗Architecture_Description → DeployUnit ∗ creer_MachineV irtuelle

DeployUnit ∗Architecture_Description → Configurator ∗ configurer_Architecture

DashBoard ∗ Identifiant_Application → Deployer ∗ controler_Application

Dé�nition des concepts : SI (Système)

ProfilUMLDescription = < IdentifiantImage, Caracteristique− ens, Identifiant_ProfilUML >

ProfilUMLArchitecture = profilUML− ens

Image = < Application− ens, IdentifiantImage >

ImageDeploy = < Image, nombre_d_Instances >

ArchitectureDescription = ImageDeploy − ens

Architecture = < ArchitectureDescription, MachineV irtuelle− ens >

Énumération des principaux services

configurerArchitecture = (Architecture_Description, Architecture, configurer)

creerMachineV irtuelle = (Image, MachineV irtuelle, creer)

recupererImage = (identifiantImage, Image, chercher)

interpreterProfilUML = (profilUML, Architecture_Description, extraire_DescriptionArchitecture)

recupererP rofilUmlArchitecture = (profilUML, profilUML_Description, recuperer)

D'un point de vue architectural, Tune-Ng est composé d'une entité centrale : TuneNg_Master,chargée d'appliquer la logique d'administration et d'un ensemble d'agents répartis sur laplateforme matérielle. Ce sont les TuneNg_Agent. Ainsi, sur chaque noeud, sont instanciésdeux types d'agent :

17

� TuneNg_Agent : qui gère les opérations générales non spéci�ques aux entités applica-tives locales à la machine ;

� RemoteWrapper : assure la gestion et le suivi des opérations spéci�ques (con�gura-tion,...) à une instance de logicielle donnée (voire section 5.2.2). C'est essentiellement lesystème de jockeys et la (les) sonde(s) dé�nis pour chaque image lors de leur création.

5.2 Les services

Comme dit plus haut (section 5.1), la couche d'exécution compte quatre principauxservices dont trois sont pour l'instant implémentés dans Tune-Ng. Ce sont le service decréation d'images, service de con�guration et le service de déploiement présentés dans lessous-sections suivantes.

5.2.1 Le service de création d'images

Ce service permet d'utiliser et de valider le système de réduction d'images developpé(section 5.3). Il est basé sur le principe de montage/démontage de système de �chiers.Chaque image dédiée a des propriétés appelées jockey, dé�nies lors de la création de laditeimage. La séquence suivante décrit en détail la création d'une image dédiée.

1. l'imageManager demande via une interface de Tune-Ng la création d'une nouvelleimage en précisant le nom et la nature du système de base (debian squeeze, debianwheezy, ubuntu). Il peut également spéci�er le �chier de con�guration d'extension(.conf) à utiliser. Ce �chier contient les contraintes sur la gestion des ressources (limitemémoire, CPU) utilisables par les machines virtuelles créées sur la base de ladite image.Elles sont écrites suivant la syntaxe des �chiers de con�guration des cgroup 24. À cetteétape l'image ne pèse que 4 Ko sur le disque ;

2. l'imageManager peut alors associer à l'image créée des paramètres ( qui seront ren-seignés lors du démarrage ou de la con�guration de MV créées sur la base de cetteimage) . Un paramètre est un triplet : identi�ant, le chemin du �chier où est créée lejockey dans l'image et le jockey ;

3. à la demande de l'imageManager, Tune-Ng démarre et monte une machine virtuelletemporaire correspondant à l'image. Elle n'est en fait qu'une pile vide AuFS d'unsystème de �chiers accessible en lecture/écriture au dessus du containerBase montéen lecture seule. Le terminal de la MV temporaire créée est mappé sur le navigateur(interface de Tune-Ng) et est directement accessible par l'imageManager(confère �gure3). La MV est également accessible par ssh via le terminal standard ;

Figure 6 � Installation d'apache sur une image via l'interface Tune-Ng

4. c'est ici que commence la phase de con�guration. L'imageManager connecté à la MVinstalle les dépendances comme il le ferait sur sa propre machine. Il peut ajouter desjockeys dans les �chiers de cette image. Ce sont ces jockeys qui sont utilisés par leservice de con�guration pour paramétrer les MV ;

24. http ://profy.fr/wiki.php/cgroup

18

5. la sauvegarde de l'image dédiée (click sur le bouton save �gure 11) entraine l'arrêt dela machine virtuelle temporaire, démontage et la suppression de la pile de �chiers crééepour elle. L'image peut alors être publiée, auquel cas elle est copiée dans le repositorydes images préfabriquées accessibles par les �nalUser ;

6. il est possible de télécharger le �chier de con�guration de chaque image dédiée. Il peutêtre complété par la valeur des jockeys et utilisé pour con�gurer les MV créées aveccette image.

Nous utilisons un repository contenant des images standards préfabriquées et éventuellementpubliées par les imageManager.

5.2.2 Le service de con�guration

L'utilisation des jockeys permet de simpli�er le procédé de con�guration d'applicationsutilisé dans TUNe (utilisation de Wrapper [20]). Telles qu'introduites plus haut (section4.2), les valeurs des jockeys peuvent être renseignées à di�érents stades du processus dedéploiement grâce à l'outil sed. Ces jockeys sont soit, des paramètres statiques dont lavaleur ne dépend pas de l'environnement d'exécution. Le cas échéant, elle est renseignéepar l'unité de déploiement lors de la construction des images. Le service de con�gurationintervient donc partiellement dans le service de création des images décrit ci-dessus, lors duparamétrage initial de celles-ci. Soit il s'agit de paramètres dynamiques dont la valeur n'estconnue qu'après l'instanciation des machines virtuelles. Dans ce cas, la valeur du jockey serarenseignée par le con�gurateur au moment de l'auto-con�guration. C'est le cas des adressesIP par exemple. Ce sont ces jockeys spéci�és lors de la création des images qui sont utiliséspour les machines virtuelles.

L'auto-con�guration est assurée par des scripts spéci�ques à chaque application en-capsulée dans une image. On distingue deux jockeys spéciaux qui dé�nissent la procédured'installation d'une application quelconque dans une image. Ces deux jockeys sont utiles au�nalUser qui utilise ladite image :

� appPath : c'est le chemin d'accès au script d'installation et/ou de con�guration del'application à installer dans l'image ;

� appFiles : c'est le chemin d'accès aux ressources (�chiers) nécessaires à la réussitede l'exécution du script renseigné par appPath. Cela peut-être le chemin d'accès auxservlets (.war) pour une image dédiée tomcat ;

5.2.3 Le service de déploiement

Le service de déploiement assure essentiellement le déploiement de machines virtuelleset d'architectures sur des noeuds distants. En e�et, TuneNg-Master e�ectue (synchronise)une copie de l'image dédiée originale sur le noeud distant. Les paramètres de connexion(identi�ant ssh, clé publique) utilisés pour la copie sont ceux spéci�és lors de la créationdu noeud. Toujours dans un soucis d'é�cacité, nous utilisons des outils permettant de necopier/actualiser que les �chiers modi�és. Nous faisons donc usage de l'outil rsync 25 pour letransfert des octets de l'image modi�ée. Il utilise de façon sous-jacente, ssh pour la connexionsécurisée au noeud distant. Ainsi, la commande suivante permet la synchronisation rapided'une image dédiée pour apache et une MV apache localisée sur le noeud d'adresse IP192.168.1.2

sudo /usr/bin/rsync -az -e /usr/bin/ssh -i /home/tuneng/.ssh/id_rsa

/home/tuneng/tuneng/images/jb-apache

25. rsync (Remote SYNChronisation) http ://doc.ubuntu-fr.org/rsync

19

tuneng@192.168.1.2:/home/tuneng/tmp/R-dynvps.tmp-jecf

Gestion des noeuds

Les noeuds sont les machines physiques sur lesquelles peuvent être déployées des ma-chines virtuelles. Le service de déploiement permet d'ajouter de nouveaux noeuds utilisables.Un noeud est dit utilisable lorsque sa con�guration a été véri�ée et validée. Tune-Ng, fournità cet e�et une page d'aide à la con�guration des noeuds (installation des paquets requis,droits utilisateurs, réseau ).

Ci-après la description du cycle de vie d'ajout d'un nouveau noeud :

1. l' administrator ajoute au réseau un nouveau noeud sur lequel il déploie un TuneNg_Agent,

2. l' administrator via l'interface de la plateforme Tune-Ng, commande la véri�cation dela con�guration du noeud. Cette opération est assurée par TuneNg_Agent qui se sertdes informations renseignées lors de la création dudit noeud. Il s'assure entre autresque lxc y est correctement installé et qu'il dispose des droits pour les opérations debase comme le montage/démontage, connexion en super-utilisateur.

3. TuneNg_Agent retourne le rapport de véri�cation à TuneNg_Master

4. TuneNg_Master journalise le rapport envoyé.

La sécurité des données transportées est assurée par l'encryptage SSL. SSL sigle de SecureSocket Layer est un procédé standard de sécurisation des transactions e�ectuées via Internet.

Déploiement d'architectures

Une architecture est considérée ici comme un ensemble d'images dédiées reliées entreelles par des jockeys. Le déploiement d'une architecture se traduit par le démarrage des MVcorrespondantes aux images constituant l'architecture ; suivi de l'envoi des informations deconnexion au �nalUser initiant l'opération de déploiement. La �n du contrat est marquéepar l'arrêt complet des MV ainsi que la libération des ressources à elle allouées.

Nous expérimentons tout particulièrement la création et déploiement d'architecture J2EEstandard. Dans notre contexte, une architecture J2EE standard est constituée de serveursd'applications Tomcat, serveurs web Apache 2 aux quels est intégré le module mod_jk 26

pour la communication avec les serveurs Tomcat et serveurs de base de données Mysql.L'image Apache contient des jockeys qui la caractérise (numéro d'ordre), ainsi que des jock-eys qui permettent de lui associer des workers, servlets Tomcat et dé�nir le loadBalancer.Via l'interface de Tune-Ng, le �nalUser précise le nombre de serveurs Apache, Tomcat etMysql qu'il souhaite intégrer à son architecture. C'est l'interface de Tune-Ng qui permet delier des serveurs Apache aux serveurs Tomcat et lier les servlets de ces derniers à des basede données Mysql. Ces architectures peuvent être con�gurées à l'aide de �chier de jockeys.

5.3 Réduction de la taille des images

La mise en oeuvre du système de réduction de taille d'images basée sur la VPC, se fait parle choix d'un outil de virtualisation adéquat (de la catégorie VPC), ainsi que l'implantationde l'approche de sauvegarde d'images DeltaSave et l'utilisation de ces images suivant leprincipe utilisé pour les CD Live. Pour ce faire, nous utilisons le couple LXC et AuFsrespectivement comme système de virtualisation et outil de manipulation des images.

L'utilisation de ces deux outils (LXC et AuFS) a permis de réduire d'environ 4 fois lataille des images dédiées créées pour les architectures J2EE standard.26. http ://tomcat.apache.org/connectors-doc/

20

5.3.1 LXC comme système de virtualisation

LXC 27 (sigle de LinuX Container) est un système de virtualisation niveau noyau léger.Nous avions trois principales options dont : VServer 28, OpenVZ 29 et LXC. L'argumentmajeur du choix de LXC est le fait qu'il soit intégré au noyau linux (depuis le noyau 2.6.29)et n'a pas besoin de packages supplémentaires. Technologie de chroot évolué, LXC repose surles fonctionnalités du noyau linux notamment les Cgroups et les espaces de nommagerespectivement pour la mutualisation des ressources et pour l'isolation. Cgroup 30 (acronymede Control groups) est une fonctionnalité du noyau linux qui permet de limiter, compter etisoler l'utilisation des ressources : disque, processeur, mémoire, utilisation disque.

LibVirt pour la portabilité des machines virtuelles

Pour permettre la portabilité des machines virtuelles d'un hyperviseur à un autre, nousutilisons libvirt 31. Libvirt est une bibliothèque permettant d'interagir avec di�érentes solu-tions de virtualisation. Pour l'instant, l'hyperviseur pris en compte est LXC. Il a été utilisépour mettre sur pied notre système d'images de taille réduite détaillé précédemment à lasection 4.1.2.

5.3.2 AuFS pour le partage de �chiers

Plusieurs outils pour l'union de système de �chiers existent, notre choix s'est porté surAuFS (Another Union File System). AuFS est un service du système de �chiers de Linuxqui permet de fusionner plusieurs points de montage. Il permet d'utiliser une image unique :ContainerBase. C'est grâce à cet outil qu'à la demande, nous montons en union le delta desimages avec le conteneur de base (containerBase), et ne sauvegardons que les modi�cationsapportées virtuellement au containerBase.La commande suivante permet de monter dynamiquement un répertoire Tmp_Union_Dircorrespondant à une machine virtuelle Apache. Apache_Image_Dir représente le deltasauvegardé lors de la création de l'image dédiée Apache ; c'est elle qui est montée en unionà containerBase pour obtenir le point de montage de la machine virtuelle.

# mount -t aufs aufs $Tmp_Union_Dir

-o dirs=$Apache_Image_Dir=rw:$Container_Base_Dir$=ro

5.4 Synthèse des choix technologiques

Tune-Ng est developpé avec les technologies J2EE avec le framework Spring, et utilise unebase de données PostgreSql 9.1. Le système d'exploitation considéré lors du developpementde la plateforme Tune-Ng est Debian Wheezy.

5.4.1 Récapitulatif

La �gure ci-dessous résume les outils agencés pour assurer la gestion e�cace des machinesvirtuelles au niveau de la couche d'exécution :

5.5 Couche d'édition

La couche d'édition calquera les concepts de base des pro�ls UML présentés à la section2.2.2 pour la modélisation des architectures. [5] présente le détail de ces concepts.27. http ://lxc.sourceforge.net/28. http ://linux-vserver.org/Welcome_to_LinuxVServer.org29. http ://openvz.org/Main_Page30. http ://profy.fr/wiki.php/cgroup31. http ://libvirt.org/index.html

21

Figure 7 � Outils

� (a), (b) rmi : pour le déploiement de TuneNg-Agent sur

le noeud distant et le retour des résultats des opérations

e�ectuées par TuneNg-Agent : sauvegarde, rapport de

véri�cation de con�guration, ...

� (c) et (c') : sed a (stream editor) pour la con�guration

et auto-con�guration des MV (mises-à-jour des jockeys)

sur le noeud ;

� (d) rsync : pour la copie et synchronisation des MV ;

� (e) ssh (secure shell) : pour la connexion sécurisée ;

� (f) ssl (secure socket layer) : pour les échanges sécurisés ;

� (g) lxc et aufs pour la virtualisation et la réduction de

la taille des MV ;

� (h) libvirt pour la gestion de plusieurs hyperviseurs.

a. http ://www.gnu.org/software/sed/manual/sed.html

5.6 Couche Dashboard

Elle se basera essentiellement sur le retour des sondes embarquées dans les applicationsdéployées via les RemoteWrapper.

5.7 Évaluation

L'objectif de cette évaluation est d'estimer la viabilité du processus de déploiementd'une application à l'aide de Tune-Ng. Elle se focalise sur la vitesse de déploiement etl'espace consommé par les architectures déployées. Nous considérons une architecture J2EEstandard constituée de serveurs Apache 2, Tomcat7 et Mysql 5.5 à déployer sur des noeudsayant Debian Wheezy comme système d'exploitation.

5.7.1 Évaluation 1 : espace consommé

Le tableau ci-dessous présente l'espace disque utilisé pour une image Apache, Tomcatet Mysql respectivement. Cet espace a été mésuré en créant des images à partir LXC sans,puis à l'aide de Tune-Ng.CB dans le tableau ci-dessous, désigne le conteneur de base qui aune taille de 319M. Pour la colonne Sans Tune-Ng, nous considérons des containers créésmanuellement (lxc-create -n nom) sur la base d'un template Debian Wheezy qui pèse 230M.

Sans Tune-Ng Tune-Ng Tune-Ng et CB

Apache2 et mod_jk 272 M 63 M 382 M

Jdk1.7 et Tomcat 7 487 M 145 M 464 M

Mysql5.5 client et serveur 486M 110 M 499 M

À partir de combien de conteneurs gagne t-on en espace avec l'utilisation de Tune-Ng ?Répondre à la question posée à cette question revient à trouver la valeur minimale de nsuivant l'équation (1) présentée à la section 4.1.2. En moyenne à partir de n = 2, pourune architecture J2EE standard, on gagne en espace en déployant ladite architecture viaTune-Ng.

En comparaison à la plateforme Vamp (section 3.2) où les machines virtuelles ont unetaille minimale de 1Go, nous observons un gain signi�catif de facteur 3 en ne considérantqu'une seule machine virtuelle. Ce gain serait plus considérable en considérant plusieurs MV

22

(partant du principe de DeltaSave). Ceci n'a cependant pu être expérimenté faute d'accèsau code de l'application Vamp.

5.7.2 Évaluation 2 : temps utilisé

Notre approche pour l'évaluation en temps est la suivante. Nous nous proposons de créerdiverses con�gurations d'architectures J2EE en faisant varier le nombre d'instances (de 1à 10 par image) de serveurs Apache, de Tomcat, et Mysql. Nous souhaitions comparer lestemps de déploiement (et démarrage) desdites architectures, et l'espace disque consommé enutlisant Tune-Ng, OpenStack, Puppet, et manuellement 32. Nous considérons dans ce derniercas, le déploiement comme le clonage suivi du démarrage des conteneurs. Seulement, dansnotre démarche d'évaluation, nous nous sommes malheureusement heurtés à la complexité dedéploiement et de con�guration de l'environnement nécessaire pour l'utilisation des plate-formes OpenStack et Puppet. Fort de celà, les évaluations y a�érentes rentrent dans lesperspectives directes de nos travaux.

5.7.3 Illustration

Le graphe suivant illustre les variations observées entre le déploiement d'architecturesavec et sans Tune-Ng : Cette �gure met clairement en évidence les gains engrangés par

Figure 8 � Évaluation

l'utilisation de Tune-Ng (autant en espace disque, qu'en temps de déploiement).

6 Conclusion et perspectives

6.1 Conclusion

Nos travaux se situent dans le cadre de l'administration autonome d'applications dansle cloud. Dans la première section de notre mémoire, nous avons présenté d'une part lesproblématiques d'administration d'applications dans le cloud et d'autre part les apportséventuels des systèmes d'administration autonome (SAA) par rapport à celles-ci. Nous noussommes principalement intéressés au SAA TUNe. En e�et, en plus d'o�rir des outils de hautniveau pour la modélisation des architectures, TUNe est l'un des seuls SAA à prendre encompte les applications patrimoniales. Nous avons rencontré les problèmes de dépendancesde librairies, et de gestion de machines virtuelles.

32. Manuellement : nous crééons au préalable des conteneurs standards pour Apache, Tomcat et Mysql

23

Notre approche pour la résolution du problème de dépendances de librairies a été l'util-isation des images dédiées. L'utilisation d'images dédiées constitue également une solutionau problème de gestion de machines virtuelles posé par TUNe. Seulement cette approcheprésente un autre problème sous-jacent commun à la plupart des IaaS : la taille des-ditesimages dédiées. En e�et, elles doivent être plus ou moins légères pour que leur manipulation(déploiement, con�guration, migration) soit rapide.

À cet e�et, nous avons mis au point un système de �chiers pour des images de tailleréduite basé sur la virtualisation niveau noyau (utilisation des conteneurs), associé au mé-canisme DeltaSave développé à la section 4.1.2, ainsi qu'un choix conséquent d'outils (voire�gure 5.4.1) pour la manipulation des MV. Ceci nous a permis de réduire de 4 fois enmoyenne, la taille des images manipulées en comparaison à l'utilisation commune de LXC. Cette approche a été e�ectivement implémentée dans la plateforme Tune-Ng. Nous avonsutilisé une librairie de virtualisation linux (libvirt) pour permettre dans la suite la prise encompte de n'importe quel hyperviseur. LXC est l'outil de virtualisation utilisé actuellementdans Tune-Ng.

Nous avons par la suite, e�ectué une évaluation des gains au niveau de l'espace disqueconsommé par les images et MV ainsi qu'au niveau du temps nécessaire pour le déploiementd' architecture (J2EE) construite sur la base desdites images. Cette évaluation s'est baséeessentiellement de l'utilisation manuelle de LXC, avec OpenStack , VAMP[27] et Puppet 33.Nous nous sommes heurtés à la di�culté d'installation et de con�guration de l'environ-nement nécessaire à l'utilisation d'OpenStack, Puppet. La �gure 8, montre bien l'avantagedu déploiement d'architecture J2EE standard avec Tune-Ng.

La plateforme Tune-Ng en son état actuel permet le déploiement et la con�gurationautonomes d'applications dans une plateforme de cloud. La con�guration est basée sur l'u-tilisation de jockeys. Ce sont des clés modi�ables de façon dynamique, intégrées dans les�chiers des images dédiées lors de le création par l'imageManager. Il existe deux clés spécialesqui permettent de dé�nir le script d'installation (appPath) ainsi que la location des �chiersnécessaires (appFiles). Tune-Ng o�re par défaut le mécanisme complet pour le déploiementet con�guration autonomes d'architecture J2EE standard.

6.2 Perspectives

Les perspectives à nos travaux sont nombreuses. En e�et, le système de �chiers implantédans Tune-Ng pour l'instant fonctionne avec LXC. Il serait souhaitable de l'étendre auxautres hyperviseurs commerciaux : Xen, VMWare entre autres. Ceci pourra être fait en sebasant sur les avantages de libvirt présenté à la section 5.3.Compte tenu du temps imparti à notre stage, les couches d'édition et de contrôle n'ont paspu être complètement développées et intégrées à Tune-Ng. Il se dégage donc trois autresperspectives à ces travaux :

� le développement et l'intégration à Tune-Ng des modèles UML adaptés au cloud ;� l'intégration aux couches Deployer et DashBoard, les opérations d'auto-réparation etde rédimensionnement pour faire de Tune-Ng un système d'administration autonomed'applications patrimoniales complet ;

� et l'évaluation complète des temps de déploiement (et migration de MV), et espaceconsommé avec les plate-formes OpenStack, Puppet, Vamp entre autres (voire section5.7.2).

� paralléliser les procédures de déploiement en prenant en compte les caractéristiquesdes noeuds de la plateforme matérielle

33. http ://puppetlabs.com/

24

RemerciementsJe tiens à remercier le laboratoire IRIT, la structure qui nous a accueilli tout le long de notrestage et le projet BioDataCloud qui a �nancé nos travaux. Je remercie particulièrement mesencadrants Dr. Laurent Broto, Pr. Maurice Tchuente pour le suivi et les conseils dont nousavons béné�ciés.

Je remercie mes très chers enseignants principalement : les docteurs Melatagia, Chedom,Tsopze, Kouokam, Tindo, M. Hamza, M. Tapamo, M. Monthé ... pour l'enseignement dequalité et l'aide qu'ils ont su m'apporter. Je remercie les membres du jury dont : Pr. Atsa,Pr. Ndoundam pour le temps consacré à l'évaluation de mon travail.

Je remercie également ma famille (mes parents M. Kitio Galbert et Mme Alachio Char-lotte) , mes soeurs et tante (Rose, Winnie, Élodie, Excelle, Divine et Charleine) pour lacon�ance et le soutien moral dont elles ont toujours fait preuve. Je n'oublie pas mes amis :Robert, Thomas, Coriane, Vanel, Emmanuel, Samuel, Melanie, Sedrique..., tous les mem-bres de l'équipe SEPIA (principalement Pr. D. Hagimont, Larissa, Brice) pour leur soutienet encouragement permanents ; ainsi que tous ceux qui de près ou de loin ont contribué laréalisation de mes travaux.

Références

[1] David S. Rosenblum A. Carzaniga and Alexander L. Wolf. Design of a scalable event noti�cationservice : Interface and architecture. Technical Report CU-CS-863-98, Department of Computer Science,University of Colorado, August 1998.

[2] Er L. Wolf Antonio Carzaniga, David S. Rosenblum. Design of a scalable event noti�cation service :Interface and architecture. University of Colorado, Department of Computer Science, Technical ReportCU-CS-863-98, August 1998.

[3] V. Bala T. Frauenhofer T. Mummert M. Pigott B. Alpern, J. Auerbach. Pds : A virtual executionenvironment for software deployment. VEE'05, June 2005.

[4] K Bakshi. Cisco cloud computing - data center strategy, architecture, and solutions. 2009.

[5] Laurent Broto. Support langage et système pour l'administration autonome. PhD thesis, September2008.

[6] I Whalley S R White D M Chess, A Segal. Unity : Experiences with a prototype autonomic computingsystem. In Proceedings of the First International. Conference on Autonomic Computing (ICAC), 2004.

[7] A.Huang B.Schmerl D.Garlan, S.Cheng and P.Steenkiste. Rainbow : Architecture-based self adaptationwith reusableinfrastructure. IEEE Computer Society, October 2004.

[8] D. Wile D.Garlan, R. Monroe. Acme : Architectural description of component-based systems. Foun-dations of Component-Based Systems, pages 47�68, 2000.

[9] Noël De Palma D.Hagimont, S.Bouchenak and C.Taton. Autonomic management of clustered applica-tions. IEEE International Conference on Cluster Computing, 2006.

[10] F. Desprez E. Carron. Diet : A scalable toolbox to build network enabled servers on the grid. IJHPCA,2005.

[11] Matthieu Leclercq Vivien Quéma Eric Bruneton, Thierry Coupaye and Jean-Bernard Stefani. The fractal component model and its support in java. Spe software-practice and experience, 36 :1257�1284,2006.

[12] Xavier ETCHEVERS. Déploiement d'applications patrimoniales en environnements de type informa-tique dans le nuage. PhD thesis, Université de Grenoble, december 2012.

[13] DMTF Distributed Management Task Force. Open virtualization format speci�cation. DSP0243,February 2009.

[14] Blasco I. Galant F., Gomez M. Autocon�guration of enterprise-class application deployment in vir-tualized infrastructure using ovf activation mechanisms. 2012 8th international conference and 2012workshop on systems virtualiztion management (svm), pages 414�421, October 2012.

[15] Parashar M. Hua Liu. Accord : A programming framework for autonomic applications. IEEE Transac-tions on Systems, Man and Cybernetics, Special Issue on Engineering Autonomic Systems,, pages 341� 352, May 2006.

[16] A. Bejleri O. Shurdi I. Tafa, E. Kajo and A. Xhuvani. The performance between xen-hvm, xen-pv andopen-vz during live-migration. 2011.

[17] and Cook Jézéuel, Huÿmann. The uni�ed modeling language. 5th International Conference, Dresden,Germany, 2460, October 20002.

25

[18] Je�rey O. Kephart and David M. Chess. The vision of autonomic computing. IEEE Computer Maga-zine, 2003.

[19] A. Manzalini L. Baresi A. D. Ferdinando A. Manzalini F. Zambonelli L. Baresi, A. Di Ferdin. Thecascadas framework for autonomic communications. Autonomic Communication (Springer, Heidelberg),2009.

[20] P. Stolf N. Depalma S. Temate L. Broto, D. Hagimont. Autonomic management policy speci�cation intune. Proceedings of the 2008 ACM symposium on Applied computing, pages 1658�1663, March 2008.

[21] Salim Hariri M. Parashar. Pragma : an infrastructure for runtime management of grid applications.Proceedings of the 16th International Parallel and Distributed Processing Symposium, IPDPS, April2001.

[22] Jean-Christophe Ducom Nathan Regola. Recommendations for virtualization technologies in highperformance computing. 2nd IEEE International Conference on Cloud Computing Technology andScience, 2010.

[23] openVZ. Performance. http ://openvz.org/Performance.

[24] Zhikui Wang Sharad Singhal Kang G. Shin Pradeep Padala, Xiaoyun Zhu. Performance evaluation ofvirtualization technologies for server consolidation. 2008.

[25] Amazon Web Services. Amazon elastic compute cloud (amazon ec2). http://aws.amazon.com/ec2/.

[26] Alain Tchana. Système d'Administration Autonome Adaptable : application au Cloud. PhD thesis,2011.

[27] F. Boyer N. D. Palma X. Etchevers, T. Coupaye. Auto-con�guration d'applications réparties dans lenuage. RenPar'20 / SympA'14 / CFSE 8, mai 2011.

26