Tchana

Institut National Polytechnique de Toulouse (INP Toulouse)
Sret de logiciel et calcul de haute performance (SLCHP)
Alain-B. TCHANA
mardi 29 novembre 2011
Systme d'Administration Autonome Adaptable: application au Cloud
Mathmatiques Informatique Tlcommunications (MITT) Institut de Recherche en Informatique de Toulouse (IRIT) Mr. Daniel HAGIMONT
Mr. Nol DE PALMA Mr. Jean-Marc MENAUD M : Mr. Nol DE PALMA, Universit Joseph Fourier, Rapporteur Mr. Jean-Marc MENAUD, Ecole des Mines de Nantes, Rapporteur Mr. Michel DAYDE, Institut National Polytechnique de Toulouse, Examinateur Mr. Maurice TCHUENTE, Universit de Yaound I, Examinateur Mr. Daniel HAGIMONT, Institut National Polytechnique de Toulouse, Directeur de Thse Mr. Laurent BROTO, Institut National Polytechnique de Toulouse, Examinateur
` THESE
soutenue en vue de lobtention du titre de DOCTEUR DE LUNIVERSITE DE TOULOUSE Spcialit : INFORMATIQUE e e dlivre par e e lINSTITUT NATIONAL POLYTECHNIQUE DE TOULOUSE
Syst`me dadministration autonome adaptable : e application au Cloud

Prsente et soutenue publiquement par e e
Alain-B. TCHANA
le 29/11/2011, devant le jury compos de : e
Mr. Mr. Mr. Mr. Mr. Mr.
Jean-Marc MENAUD Ecole des Mines de Nantes Rapporteur Noel DE PALMA Universit Joseph Fourier e Rapporteur Maurice TCHUENTE Universit de Yaound I e e Examinateur Michel DAYDE Institut National Polytechnique de Toulouse Examinateur Laurent BROTO Institut National Polytechnique de Toulouse Co-Directeur de th`s e Daniel HAGIMONT Institut National Polytechnique de Toulouse Directeur de th`se e
Ecole doctorale MITT : Mathmatique, Informatique, Tlcommunication de Toulouse e ee Directeur de th`se : Daniel HAGIMONT(IRIT, ENSEEIHT) e Laboratoire : Institut de Recherche en Informatique de Toulouse - UMR 5505-IRIT/ENSEEIHT CNRS - INP - UPS - UT1 - UTM 118 Route de Narbonne, 31062 Toulouse Cedex 09. Tel : 05.61.55.67.65
ii
A Hl`ne Marchau. Je ne trouverai jamais assez de ee e mots, ni despace, ni de temps pour te dire ` quel point a ton aide ma t capitale Hl`ne. Jai toujours imagin ee ee e plus jeune (au secondaire) que toute th`se aboutissait e sur une dcouverte ou une invention. Ta rencontre sera e ma plus grande trouvaille de ces derni`res annes et e e jesp`re quelle le restera. e
Hommage au syst`me ducatif e e Franais pour mavoir accueilli et c nanc ma th`se. e e Alain TCHANA.
Remerciements
Je tiens initialement a remercier tous les membres du jury pour le temps que ` vous avez consacr a lvaluation de mon travail. Merci a mes rapporteurs Nol De e` e ` e PALMA et Jean-Marc MENAUD a qui a t cone la responsabilit de critiquer la ` ee e e forme et le fond de mon travail. Merci a Michel DAYDE qui a accept de prsider le ` e e jury et dexaminer mon travail. Merci a Maurice TCHUENTE qui ma fait lhonneur ` du dplacement du Cameroun, lieu o` jai acquis les bases des connaissances mises e u a prot dans cette th`se. ` e Merci ` mon directeur de th`se Daniel HAGIMONT et co-Directeur Laurent a e BROTO. Vous mavez mis dans les conditions idales pour raliser cette th`se, tant e e e sur le plan professionnel que personnel. Je dois ` Daniel (le lieutenant Dan) mes moa destes qualits rdactionnelles, desprit critique et de recul dans la ralisation dun e e e travail de recherche. Laurent, tu as t une des premi`res personnes qui ma impresee e sionn techniquement dans les domaines de linformatique et de la mcanique. Tu e e as russi a me transmettre ta srnit face a tout probl`me et syst`me informatique. e ` ee e ` e e En dehors du laboratoire, vous avez t tous les deux ma seconde famille. Je vous ee ai souvent prsent ` la fois comme encadreurs, tuteurs et potes. Ce fut un bonheur e ea de travailler avec vous et jesp`re continuer. e Un grand merci a nos admirables secrtaires Sylvie ARMENGAUD et Sylvie ` e EICHEN. Vous tes exceptionnelles dans votre travail et vous avez contribu a facie e` liter le mien. Je remercie la grande quipe ASTRE, multi-culturelle et tr`s anime dans le e e e travail. Merci au professeur TOURE Mohamed qui ma accueilli et trait comme e un fr`re durant son sjour dans cette quipe. Merci a Suzy TEMATE qui apportait e e e ` toujours la lumi`re et la fra e cheur dans le bureau. Un merci a Aeman GADAFI avec ` qui jai pass de longues nuits de travail au laboratoire amenant son pouse a se e e demander qui est ce Alain. Merci ` Raymond ESSOMBA, Larissa MAYAP et Tran a SON avec qui jai termin dans une bonne ambiance mon sjour au sein de lquipe. e e e Je remercie les membres du grain : le moussokologue Amadou BAGAYOKO qui a toujours laiss sa porte ouverte a toute heure ; le jeune Bang SAMBOU et Mee ` kossou BAKAYOKO pour votre amiti et disponibilit ; ` Cheik OUMAR AIDARA, e e a Aboubakar DIALLO et Cheik TALL pour vos dbats houleux et enrichissants les e soirs de foot. Tchez toujours de faire respecter les fondamentaux. a Je ne saurai oublier ma tr`s grande famille qui ma toujours soutenu dans tous e mes choix. Vous constituez une grande partie de mes motivations et jesp`re toujours e vous faire honneur. Un merci particulier a mon p`re et ma m`re qui ont toujours mis ` e e lcole au centre de tout. Merci a la 1759 qui reprsente un membre permanent de e ` e la famille auquel je peux faire appel a tout moment :). ` v
Rsum e e Ces derni`res annes ont vu le dveloppement du cloud computing. Le principe e e e fondateur est de dporter la gestion des services informatiques des entreprises dans e des centres dhbergement grs par des entreprises tiers. Ce dport a pour principal e ee e avantage une rduction des cots pour lentreprise cliente, les moyens ncessaires ` la e u e a gestion de ces services tant mutualiss entre clients et grs par lentreprise hbere e ee e geant ces services. Cette volution implique la gestion de structures dhbergement e e a grande chelle, que la dimension et la complexit rendent diciles a administrer. ` e e ` Avec le dveloppement des infrastructures de calcul de type cluster ou grilles ont e merg des syst`mes fournissant un support pour ladministration automatise de ces e e e e environnements. Ces syst`mes sont dsigns sous le terme Syst`mes dAdministration e e e e Autonome (SAA). Ils visent a fournir des services permettant dautomatiser les ` tches dadministration comme le dploiement des logiciels, la rparation en cas a e e de panne ou leur dimensionnement dynamique en fonction de la charge. Ainsi, il est naturel denvisager lutilisation des SAA pour ladministration dune infrastructure dhbergement de type cloud. Cependant, nous remarquons que les e SAA disponibles ` lheure actuelle ont t pour la plupart conus pour rpondre aux a ee c e besoins dun domaine applicatif particulier. Un SAA doit pouvoir tre adapt en e e fonction du domaine considr, en particulier celui de ladministration dun cloud. ee De plus, dans le domaine du cloud, dirents besoins doivent tre pris en compte : e e ceux de ladministrateur du centre dhbergement et ceux de lutilisateur du centre e dhbergement qui dploie ses applications dans le cloud. Ceci implique quun SAA e e doit pouvoir tre adapt pour rpondre a ces besoins divers. e e e ` Dans cette th`se, nous tudions la conception et limplantation dun SAA adape e table. Un tel SAA doit permettre dadapter les services quil ore aux besoins des domaines dans lesquels il est utilis. Nous montrons ensuite comment ce SAA adape table peut tre utilis pour ladministration autonome dun environnement de cloud. e e
vii
Abstract Last years have seen the development of cloud computing. The main underlying principle of to externalize the management of companies IT services in hosting centers which are managed by third party companies. This externalization allows saving costs for the client company, since the resources required to manage these services are mutualized between clients and managed by the hosting company. This orientation implies the management of large scale hosting centers, whose dimension and complexity make them dicult to manage. With the developement of computing infrastructures such as clusters or grids, researchers investigated the design of systems which provides support of an automatized management of these environments. We refer to these system as Autonomic Management Systems (AMS). They aim at providing services which automate administration tasks such as software deployment, fault repair or dynamic dimensioning according to a load. Therefore, in this context, it is natural to consider the use of AMS for the administration of a cloud infrastructure. However, we observe that currently available AMS have been designed to address the requirements of a particular application domain. It should be possible to adapt an AMS according to the considered domain, in particular that of the cloud. Moreover, in the cloud computing area, dierent requirements have to be accounted : those of the administrator of the hosting center and those of the user of the hosting center (who deploys his application in the cloud). Therefore, an AMS should be adaptable to fulll such various needs. In this thesis, we investigate the design and implementation of an adaptable AMS. Such an AMS must allow adaptation of all the services it provides, according to the domains where it is used. We next describe the application of this adaptable AMS for the autonomic management of a cloud environment.
viii
Table des mati`res e

1 Introduction 2 Le cloud 2.1 Le Cloud Computing . . . . . . . . . . . . . . 2.1.1 Gnralits et Dnition . . . . . . . . e e e e 2.1.2 Cloud vs Grilles . . . . . . . . . . . . . 2.1.3 Principes . . . . . . . . . . . . . . . . 2.1.4 Bnces . . . . . . . . . . . . . . . . . e e 2.1.5 Classication . . . . . . . . . . . . . . 2.1.5.1 Par raison de dveloppement e 2.1.5.2 Par niveau de service . . . . . 2.1.6 Challenges . . . . . . . . . . . . . . . . 2.1.6.1 Isolation . . . . . . . . . . . . 2.1.6.2 Administration . . . . . . . . 2.1.6.3 Interoprabilit et Portabilit e e e 2.2 Isolation par la virtualisation . . . . . . . . . 2.2.1 Dnition et Principes . . . . . . . . . e 2.2.2 Objectifs . . . . . . . . . . . . . . . . . 2.2.3 Bnces pour les entreprises . . . . . e e 2.2.4 Classication . . . . . . . . . . . . . . 2.2.5 Synth`se . . . . . . . . . . . . . . . . . e 3 Administration dans le Cloud 3.1 Administration niveau IaaS . . . . . . . . . 3.1.1 Allocation de ressources . . . . . . . 3.1.2 Dploiement . . . . . . . . . . . . . . e 3.1.3 Conguration et Dmarrage . . . . . e 3.1.4 Reconguration . . . . . . . . . . . . 3.1.5 Monitoring . . . . . . . . . . . . . . 3.2 Administration niveau Entreprise . . . . . . 3.2.1 Construction de VM et Dploiement e 3.2.2 Allocation de ressources . . . . . . . 3.2.3 Conguration et Dmarrage . . . . . e 3.2.4 Reconguration . . . . . . . . . . . . 1 4 5 5 6 7 8 10 10 11 12 13 14 14 16 16 17 18 19 20 22 23 24 24 25 25 26 27 28 29 29 30
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
3.3
3.2.5 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Synth`se : syst`me dadministration autonome pour le cloud . . . . . 31 e e 32 32 33 34 35 36 37 38 39 39 41 42 43 46 46 47 48 50 52 54 55 56 57 57 58 59 60 60 60 61 64 64 65 66 67 69 71
4 Administration Autonome 4.1 Dnition . . . . . . . . . . . e 4.2 Objectifs . . . . . . . . . . . . 4.3 Bnces pour les entreprises e e 4.4 Classication . . . . . . . . . 4.5 Synth`se . . . . . . . . . . . . e
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
5 TUNe 5.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Principes . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Architecture Description Language (ADL) . . 5.2.2 Wrapping Description Language (WDL) . . . 5.2.3 Reconguration Description Language (RDL) 5.3 Choix dimplantation . . . . . . . . . . . . . . . . . . 5.4 Exprimentations et Problmatiques . . . . . . . . . e e 5.4.1 Applications cluster . . . . . . . . . . . . . . . 5.4.2 Applications large chelle : cas de DIET . . . e 5.4.3 Applications virtualises . . . . . . . . . . . . e 5.4.4 Cloud . . . . . . . . . . . . . . . . . . . . . . 5.5 Synth`se et nouvelle orientation . . . . . . . . . . . . e 6 Orientation gnrale e e 6.1 Caractristiques . . . . . . . . . . . . . . . . . . e 6.1.1 Uniforme . . . . . . . . . . . . . . . . . 6.1.2 Adaptable . . . . . . . . . . . . . . . . . 6.1.2.1 Adaptation des comportements 6.1.2.2 Extensibilit . . . . . . . . . . e 6.1.3 Interoprable et Collaboratif . . . . . . . e 6.1.4 Synth`se . . . . . . . . . . . . . . . . . . e 6.2 Approche gnrale et Mod`le Architectural . . . e e e 6.2.1 Approche Gnrale . . . . . . . . . . . . e e 6.2.2 Mod`le Architectural . . . . . . . . . . . e 6.2.3 Prise en compte des caractristiques . . . e 6.3 Synth`se . . . . . . . . . . . . . . . . . . . . . . e 7 Etat de lart 7.1 SAA . . . . . . 7.1.1 Rainbow 7.1.2 Accord . 7.1.3 Unity .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
7.2
7.3
7.1.4 Synth`se . . . . . . . . . . . e SAA pour le cloud . . . . . . . . . 7.2.1 OpenNebula . . . . . . . . . 7.2.2 Eucalyptus . . . . . . . . . 7.2.3 OpenStack . . . . . . . . . . 7.2.4 Microsoft Azure . . . . . . . 7.2.5 Autres plateformes de cloud Synth`se . . . . . . . . . . . . . . . e
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
73 73 74 77 78 80 83 83 85 86 87 87 89 90 91 92 94 94 95 96 98 100 102
8 Contributions : TUNeEngine 8.1 Mod`le dtaill de TUNeEngine . . . . . . . . . . . e e e 8.1.1 Soumission de commandes et Collaboration 8.1.2 Construction du SR . . . . . . . . . . . . . . 8.1.3 Dploiement . . . . . . . . . . . . . . . . . . e 8.1.4 Conguration, Dmarrage . . . . . . . . . . e 8.1.5 Rconguration . . . . . . . . . . . . . . . . e 8.2 Le formalisme a composants Fractal . . . . . . . . . ` 8.3 Implantation de TUNeEngine . . . . . . . . . . . . 8.3.1 Le composant TUNeEngine . . . . . . . . . 8.3.2 Soumission de commandes et Collaboration 8.3.3 Construction du SR . . . . . . . . . . . . . . 8.3.4 Dploiement . . . . . . . . . . . . . . . . . . e 8.3.5 Excution de programmes dadministration . e 8.4 Synth`se . . . . . . . . . . . . . . . . . . . . . . . . e
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
9 Contributions : application au Cloud 104 9.1 Un IaaS simpli : CloudEngine . . . . . . . . . . . . . . . . . . . . . 105 e 9.1.1 Vision globale : CloudEngine-TUNeEngine, Application-TUNeEngineCloudEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 9.1.2 RepositoryController . . . . . . . . . . . . . . . . . . . . . . . 108 9.1.3 VMController . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 9.1.4 VLANController . . . . . . . . . . . . . . . . . . . . . . . . . 112 9.1.5 ResourceController . . . . . . . . . . . . . . . . . . . . . . . . 112 9.1.6 MonitoringController . . . . . . . . . . . . . . . . . . . . . . . 113 9.1.7 Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 9.2 Utilisation de CloudEngine . . . . . . . . . . . . . . . . . . . . . . . . 114 9.2.1 Construction et enregistrement de VM . . . . . . . . . . . . . 115 9.2.2 Administration dapplications . . . . . . . . . . . . . . . . . . 115 9.3 Reconguration dapplications et de CloudEngine . . . . . . . . . . . 116 9.3.1 Rparation de VM . . . . . . . . . . . . . . . . . . . . . . . . 116 e 9.3.2 Consolidation de VM et Scalabilit de serveurs . . . . . . . . . 117 e 9.3.2.1 Excution dapplications statique . . . . . . . . . . . 118 e
xi
9.4
9.3.2.2 Excution dapplications variables . . . . . . . . . . 118 e Synth`se . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 e 123 . 124 . 124 . 125 . 126 . 126 . 126 . 127 . 128 . 130 . 130 . 132 . 134 . 143 144 . 144 . 146 . 146 . 148
10 Exprimentations e 10.1 Environnements dexprimentation . . . . . . . . . . . . e 10.1.1 LIaaS . . . . . . . . . . . . . . . . . . . . . . . . 10.1.2 Les applications entreprises : RUBIS . . . . . . . 10.1.3 Les mtriques . . . . . . . . . . . . . . . . . . . . e 10.2 Evaluations . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.1 Rparation de VM . . . . . . . . . . . . . . . . . e 10.2.1.1 Rparation non collaborative . . . . . . e 10.2.1.2 Rparation collaborative . . . . . . . . . e 10.2.2 Scalabilit et Consolidation . . . . . . . . . . . . e 10.2.2.1 Scalabilit . . . . . . . . . . . . . . . . . e 10.2.2.2 Consolidation . . . . . . . . . . . . . . . 10.2.2.3 Scalabilit et Consolidation simultanes e e 10.3 Synth`se . . . . . . . . . . . . . . . . . . . . . . . . . . . e 11 Conclusion et perspectives 11.1 Conclusion . . . . . . . . . . . . . 11.2 Perspectives . . . . . . . . . . . . 11.2.1 Perspectives a court terme ` 11.2.2 Perspectives a long terme `
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
xii
Chapitre 1 Introduction
Face ` laugmentation continuelle des cots de mise en place et de maintenance a u des syst`mes informatiques, les entreprises externalisent de plus en plus leurs services e informatiques en les conant ` des entreprises spcialises comme les fournisseurs de a e e clouds. Lintrt principal de cette stratgie pour les entreprises rside dans le fait ee e e quelles ne paient que pour les services eectivement consomms. Quant au foure nisseur du cloud, son but est de rpondre aux besoins des clients en dpensant le e e minimum de ressources possibles. Une des approches quutilise le fournisseur consiste a mutualiser les ressources dont il dispose an de les partager entre plusieurs entre` prises. Dans ce contexte, plusieurs ds, parmi lesquels lisolation (des ressources, e dfaillances, performances, espaces utilisateur) et ladministration optimale des rese sources, se posent pour permettre un rel dveloppement du cloud. e e Actuellement, la plupart des dveloppements de plateformes de cloud utilisent e la virtualisation [58] comme support technologique pour assurer lisolation. Ainsi, lunit dallocation de ressources dans le cloud est la machine virtuelle, autrement e dit une portion de machine physique. Quant a ladministration dans le cloud, nous ` constatons que les services fournis restent limits et sont plus ou moins semblables e dune plateforme a lautre. Il sagit essentiellement des services de rservation, de ` e dmarrage et darrt des machines virtuelles. Les tches dadministration des mae e a chines virtuelles et des applications des entreprises sont laisses a la charge des e ` dirents administrateurs. A titre dexemple, les oprations de consolidation de mae e chines virtuelles ou encore de passage ` lchelle des applications clientes doivent a e tre implantes par les administrateurs a travers des API de bas niveau. Lobjectif e e ` principal de cette th`se est la conception dun logiciel permettant ladministration e du cloud dans son ensemble. Depuis plusieurs annes, des chercheurs se sont intresss a la conception de e e e ` syst`mes dadministration autonome (SAA). Ces syst`mes visent a fournir des sere e ` vices permettant dautomatiser les tches dadministration comme le dploiement a e des logiciels, la rparation en cas de panne ou leur dimensionnement dynamique en e fonction de la charge. Nous observons un parfait parall`le entre les apports de ces e syst`mes dadministration autonome et les besoins dadministration dans le cloud. e
CHAPITRE 1. INTRODUCTION
Figure 1.1 Plan en U de ce document de th`se e En eet, dans les deux niveaux dadministration dans le cloud (cloud et applications quil excute), les administrateurs sont confronts aux oprations dinstallation (de e e e machines virtuelles et des logiciels), de conguration, de dpannage, dallocation de e ressources et autres tches de reconguration. La principale dirence entre ces deux a e niveaux est la nature des entits administres : les machines virtuelles au niveau du e e cloud (lhbergeur) et les logiciels applicatifs au niveau du client. e Dans le cadre de nos travaux dans le domaine de ladministration, nous avons conu et dvelopp un syst`me dadministration autonome baptis TUNe [29]. En c e e e e plus de valider une approche de dveloppement des syst`mes dadministration aue e tonome, TUNe a t utilis pour ladministration de plusieurs types dapplications. ee e Cependant, il sest relativement inadapt pour ladministration des syst`mes large e e chelle ou virtualiss. Ainsi, sur les bases de TUNe, nous proposons dans cette th`se e e e la conception dun SAA hautement exible et adaptable, pouvant tre notame ment spcialis pour une utilisation dans le cloud. Cette dmarche de construction e e e dun SAA adaptable au cloud (et non spcique au cloud) sexplique par le fait que e notre activit de recherche ne sinscrit pas (et ne sinscrira pas dans le futur) uniquee ment dans la technologie du cloud, mais toujours dans ladministration autonome. Compte tenu de la double problmatique que nous adressons (construction dun e SAA adaptable et application pour ladministration dans le cloud), lorganisation de ce document de th`se suit globalement une trajectoire en U rsume par la gure 1.1 : e e e Partie I : Contexte du cloud Cette partie est compose des chapitres 2 et 3. Le chapitre 2 prsente le cloud et e e ses apports dans les entreprises (tout en clariant quelques dnitions) tandis e que le chapitre 3 prsente en quoi consiste les tches dadministration dans le e a cloud. Partie II : Contexte SAA Cette partie regroupe les chapitres 4 et 5. Le chapitre 4 prsente le contexte e Syst`me dadministration autonome adaptable : application au Cloud e
CHAPITRE 1. INTRODUCTION
scientique quest ladministration autonome en parcourant quelques approches de conception de SAA. Quant au chapitre 5, il prsente le prototype de SAA e TUNe (dvelopp au sein de notre quipe) ainsi que ses dicults a rpondre e e e e ` e aux besoins dadministration du cloud. Partie III : Positionnement Cette partie regroupe les chapitres 6 et 7. Dans le chapitre 6, nous proposons un canevas de conception dun SAA adaptable et gnrique. Quant au chapitre 7, e e il prsente une tude des travaux de recherche eectus autour des SAA et des e e e plateformes dadministration dans le cloud. Partie IV : Contribution SAA Cette partie se rsume au chapitre 8 dans lequel nous prsentons limplantation e e dun SAA adaptable suivant le canevas que nous avons prcdemment propos. e e e Partie V : Contribution Cloud Cette partie contient les chapitres 9 et 10. Le chapitre 9 prsente la persone nalisation du SAA adaptable que nous avons implant, pour ladministration e dans le cloud. Quant au chapitre 10, il montre les valuations de cette persone nalisation dans la ralisation des tches dadministration dans le cloud. e a
Syst`me dadministration autonome adaptable : application au Cloud e
Chapitre 2 Le cloud
Contents
Le Cloud Computing . . . . . . . . . . . . . . 2.1.1 Gnralits et Dnition . . . . . . . . . . . . e e e e 2.1.2 Cloud vs Grilles . . . . . . . . . . . . . . . . 2.1.3 Principes . . . . . . . . . . . . . . . . . . . . 2.1.4 Bnces . . . . . . . . . . . . . . . . . . . . e e 2.1.5 Classication . . . . . . . . . . . . . . . . . . 2.1.5.1 Par raison de dveloppement . . . . e 2.1.5.2 Par niveau de service . . . . . . . . 2.1.6 Challenges . . . . . . . . . . . . . . . . . . . 2.1.6.1 Isolation . . . . . . . . . . . . . . . 2.1.6.2 Administration . . . . . . . . . . . . 2.1.6.3 Interoprabilit et Portabilit . . . . e e e 2.2 Isolation par la virtualisation . . . . . . . . . 2.2.1 Dnition et Principes . . . . . . . . . . . . . e 2.2.2 Objectifs . . . . . . . . . . . . . . . . . . . . 2.2.3 Bnces pour les entreprises . . . . . . . . . e e 2.2.4 Classication . . . . . . . . . . . . . . . . . . 2.2.5 Synth`se . . . . . . . . . . . . . . . . . . . . . e 2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 . 5 . 6 . 7 . 8 . 10 . 10 . 11 . 12 . 13 . 14 . 14 . 16 . 16 . 17 . 18 . 19 . 20
2.1. LE CLOUD COMPUTING
2.1
2.1.1
Le Cloud Computing
Gnralits et Dnition e e e e
Face ` laugmentation continuelle des cots de mise en place et de maintenance a u des syst`mes informatiques, les entreprises externalisent de plus en plus leurs sere vices informatiques. Elles conent leur gestion (des services informatiques) ` des ena treprises spcialises (que nous appelons fournisseurs). Lintrt principal de cette e e ee stratgie rside dans le fait que lentreprise ne paie que pour les services eectivee e ment consomms. En eet, une gestion interne de ces services par lentreprise ne e serait pas compl`tement amortie, en particulier lorsque les besoins dutilisation vae rient. Le dveloppement de ce mode de fonctionnement a t favoris par plusieurs e ee e facteurs tels que lvolution et la gnralisation des acc`s internet, laugmentation e e e e de la puissance des ordinateurs et des rseaux informatiques. Le Cloud Computing e se situe dans cette orientation rcente. e Devant le manque de consensus sur la dnition de la notion de Cloud Compue ting, nous reprenons la dnition propose par CISCO [21] : le Cloud Computing e e est une plateforme de mutualisation informatique fournissant aux entreprises des services ` la demande avec lillusion dune innit des a e ressources. Dans cette dnition, nous retrouvons quelques similitudes avec les e plateformes connues comme les grilles de calcul ou encore les centres dhbergee ment. Il est prsent dans la littrature comme une volution de ces infrastructures e e e e dhbergement mutualises. En guise dexemple, prenons lvolution propose par e e e e [49] (gure 2.1) qui est largement cite dans la littrature. Dapr`s [49], le cloud e e e computing est le fruit dune volution pouvant tre prsente en 5 phases : e e e e Elle dbute avec les Fournisseurs dAcc`s Internet (FAI 1.0). Ils ont pour but e e de mettre en place des moyens de tlcommunication an dassurer le raccoree dement des personnes ou entreprises au rseau internet. e La seconde phase est lorientation des FAI vers lhbergement de pages web e (FAI 2.0). Cette phase marque un grand bond dans le dveloppement dintere net. La troisi`me phase (FAI 3.0) est la possibilit quorent les FAI ` hberger des e e a e applications mtiers des entreprises. e Une connaissance des besoins applicatifs des entreprises permettent aux FAI de faire voluer leur domaine dintervention. Ils mettent en place des platee formes de gnration dapplications a la demande. Il sagit des ASP (Applie e ` cation Service Provider) dont les Software as a Service (section 2.1.5.2) sont des drivs : cest le FAI 4.0. e e La gnralisation des pratiques prcdentes, la prise en compte de nouvelles e e e e pratiques et lintgration des principes que nous prsentons dans les sections e e suivantes donnent naissance au cloud computing. Suivant cette volution, nous prsentons dans la section suivante notre point de e e vue concernant la position du cloud computing par rapport aux plateformes dhe Syst`me dadministration autonome adaptable : application au Cloud e
bergement mutualises comme les grilles [65] (grid5000 [25], Globus [96]). e N.B : Dans ce document, nous utilisons lacronyme CC pour dsigner la teche nologie Cloud Computing et le terme cloud pour parler dune plateforme de Cloud Computing.
Figure 2.1 Evolution vers le Cloud
2.1.2
Cloud vs Grilles
Introduites pour la premi`re fois dans les annes 90, les grilles de calcul situent e e la mutualisation au cur de leur technologie. De mme, la mutualisation est au e cur de la technologie du CC. La question que nous nous posons : A quel niveau se situe la dirence entre le cloud et les grilles (si elle existe) ?. Autrement dit, le e terme Cloud Computing nest-il pas une autre appellation de Grid Computing? Apr`s consultation de la littrature, nous ne trouvons quune tude srieuse consacre e e e e e enti`rement a cette comparaison ([51]). Le constat global de [51] est proche du ntre. e ` o Dun point de vue technologique nous nidentions pas de relle dirence entre e e les plateformes de grille et de cloud. Cependant, louverture du cloud aux utilisateurs de dirents niveaux (pas toujours des informaticiens comme dans les grilles) et e ventuellement son caract`re commercial sont les potentielles dirences que nous e e e identions. De plus, dans les environnements de grilles, les applications (appeles e le plus souvent job) sexcutent gnralement sur une dure limite (mme si cellee e e e e e ci peut tre illimite comme dans le cloud). Comme nous le prsentons dans la e e e section 3, ces dirences rendent la gestion et lutilisation des plateformes de cloud e plus complexes que dans les grilles. Somme toute, nous considrons que la technologie de cloud computing utilise la e technologie de grille a laquelle elle associe les principes douverture au public, de ` Syst`me dadministration autonome adaptable : application au Cloud e
facturation, et dhbergement durable. Dans la section suivante, nous dtaillons ces e e dirents principes. e
2.1.3
Principes
Nous avons nonc dans la section prcdente quelques principes fondamentaux e e e e du cloud. Ces principes lui permettent de se dmarquer des plateformes dhbere e gement classiques (grille, data center, centre dhbergements). Les plus importants e dentre eux sont la mutualisation et la facturation des ressources a lusage : ` La mutualisation. Cest la pratique qui consiste ` partager lutilisation dun a ensemble de ressources par des entreprises (ou entits quelconques) nayant aucun e lien entre elles. Les ressources peuvent tre de diverses natures : logicielles ou mate e rielles (machines, quipements rseau, nergie lectrique). Cette pratique dpend du e e e e e dsir des entreprises de dlocaliser leurs services informatiques vers des infrastruce e tures de cloud. Reposant sur les technologies de grilles, le cloud doit cependant faire face aux probl`mes lis a son exploitation et utilisation. Il sagit des probl`mes classiques tels e e ` e que la scurit, la disponibilit, lintgrit, la abilit et luniformit dacc`s aux e e e e e e e e donnes. e Lallocation et facturation ` la demande. Contrairement aux centres dha e bergement web classiques dans lesquels le paiement se fait ` lavance sous forme de a forfait, le cloud propose une facturation ` lusage. Cette derni`re peut tre implmena e e e te de deux faons. La premi`re consiste a facturer ` lentreprise la dure dutilisation e c e ` a e dun ensemble de ressources quelque soit lutilisation eective. Par exemple, soit r lensemble des ressources rserves par lentreprise. Soient t1 et t2 respectivement e e linstant de dbut et de n dutilisation des ressources. Soit Cu le cot dutilisation e u dune ressource durant une unit de temps. Ainsi, le cot total dutilisation de lene u semble des ressources r est : Cr =(t2 -t1 )*Cu *r . Quant a la deuxi`me faon, elle est ` e c beaucoup plus ne que la premi`re. Elle consiste a facturer les vritables instants e ` e pendant lesquels les ressources ont t utilises. En partant des mmes param`tres ee e e e que prcdemment, soit T={tu1 ,tu2 ,. . . ,tun } avec tui [t1 ;t2 ], 1in, lensemble des e e units de temps pendant lesquelles les ressources ont t rellement utilises. Dans ce e ee e e cas, le cot total dutilisation de lensemble des ressources r est : Cr =Cu *r* n tui . u i=1 A la lumi`re de ces pratiques, nous montrons dans quelle mesure les consquences e e de lutilisation du cloud peuvent tre bnques ` la fois pour le fournisseur et pour e e e a les entreprises qui y ont recours.
2.1.4
Bnces e e
Les retombes des principes du cloud sont bnques a la fois pour son fournise e e ` seur, les entreprises dlocalisant leurs infrastructures et plus largement pour la nae ture (au sens cologique). Globalement, ils assurent aux deux premiers une meilleure e rentabilit. De plus ils permettent ` lentreprise de se concentrer sur les tches de e a a production autres que la maintenance de syst`mes informatiques. e
Pour le fournisseur Les bnces du fournisseur sont uniquement ds au fait de la mutualisation e e u des ressources. En eet, apr`s son investissement dans la mise en place des infrae structures pour le cloud, il fait payer aux entreprises la marge ncessaire pour sa e rentabilisation. Comme pour une entreprise disposant dune plateforme interne, il paie pour les frais dadministration de lensemble. Cette dpense peut tre amortie e e par facturation aux entreprises. En plus de cette marge, il bncie des cots de e e u rutilisation des ressources. En eet, compte tenu de la non appartenance des rese sources aux entreprises, elles (les ressources) leurs sont factures a chaque usage. La e ` mme ressource peut ainsi faire lobjet de plusieurs facturations. e
Pour lenvironnement A l`re de lcologie et des politiques de rduction de la consommation nerge e e e e tique, linvestissement dans les plateformes de cloud reprsente un geste envers la e nature. La mutualisation de ressources (telle que pratique dans le cloud) accompae gne par la dlocalisation des infrastructures dentreprise vers les clouds permettent e e de rduire les consommations nergtiques. Pour illustrer cette armation, reprenons e e e ltude [45] ralise par le groupe WSP Environment & Energy (WSP E&E) 1 pour e e e le compte de Microsoft ` propos de la plateforme de cloud Azure [76]. Cette tude a e est rsume dans sa conclusion : Moving business applications to the cloud can save e e 30 percent or more in carbon emissions per user.. Elle montre que la dlocalisation e des applications Microsoft Exchange Server 2007 [75] des entreprises vers le cloud Microsoft Azure permet de rduire dau moins 30% les missions CO2 par utilisateur e e de chaque entreprise. Cette rduction sexplique par deux facteurs. Dune part, la e dlocalisation permet de rduire le nombre et la taille des infrastructures informae e tiques en service. Ceci implique donc une rduction de la consommation nergtique e e e (donc moins de rejet de CO2 ). Dautre part, le fournisseur Microsoft implante dans son cloud des techniques dutilisation ecace de ressources.
1. Groupe de Consulting en mati`re denvironnement, dnergie et de climat : e e www.wspenvironmental.com
2.1. LE CLOUD COMPUTING Pour lentreprise
Cest elle la premi`re gagnante de cette technologie. Elle ralise des bnces en e e e e argent et en exibilit dans sa capacit ` sagrandir. e ea La rduction des co ts. Le recours au cloud permet a lentreprise dtre factue u ` e re ` lusage, en fonction de ses besoins. Pour avoir une ide du gain ralis, reprenons e a e e e cette observation de Michael Crandell du groupe RightScale [RIGHSCALE] a propos ` du cloud dAmazon [61] : Le cot ` pleine charge dun serveur sur Amazon se situe u a entre 70$ et 150$ par mois alors quil sl`ve ` 400$ en moyenne par mois sil tait ee a e hberg par lentreprise en interne. Plusieurs raisons expliquent cette dirence de e e e cot. En eet, une gestion interne de linfrastructure implique lachat des matriels, u e laectation du personnel (et donc du cot salarial quil induit) pour la gestion de u linfrastructure et divers moyens de production mis en place pour le fonctionnement de lensemble (lectricit, locaux, etc). Le partage de ressources tel que pratiqu dans e e e le cloud permet au fournisseur de rpartir ces cots entre plusieurs entreprises. e u La rduction des gaspillages. Les infrastructures gres en interne sont soue ee vent sous-utilises, alors que linfrastructure dun cloud mutualise lensemble de rese sources pour un grand nombre dentreprises. La mutualisation consiste a mettre ` ` a la disposition de plusieurs utilisateurs une base commune de ressources. Elle permet ainsi daugmenter le taux dutilisation de ces ressources. En eet, les ressources ntant pas ddies ` un seul utilisateur, elles pourront servir a dautres en cas de e e e a ` besoin. La exibilit et acc`s aux ressources large chelle. Lentreprise peut auge e e menter la capacit de son infrastructure sans investissement majeur. En eet, grce e a a lallocation dynamique (` la demande) des ressources quore le cloud, il sut de ` a souscrire ` de nouvelles ressources et celles-ci sont directement alloues. De plus, a e lentreprise est libre de ses alles et venues car les contrats dutilisation sont limits e e dans le temps (autour de lheure). Ainsi, lentreprise peut augmenter ou rduire son e infrastructure ` sa guise a moindre cot et dans un dlai rduit. Rappelons que le a ` u e e cloud ore ainsi ` lentreprise une possibilit daccder ` une quantit de ressources a e e a e dont elle ne pourrait se lorir en interne. Elle peut dornavant envisager des ape plications large chelle sans se soucier de lobtention des quipements. A ce sujet, e e on observe quelques drives avec des groupes qui acqui`rent un grand nombre de e e ressources dans les clouds a des ns criminelles (dcryptage de cl de scurit ou ` e e e e 2 dnis de service en sont des exemples) . e Notons que cette exibilit dpend du type de cloud considr (section suivante). e e ee Par exemple, laugmentation de ressources dans un cloud de type entreprise ne sera pas aussi rapide que dans un cloud de type fournisseur de services. Dans le premier cas, la dcision est prise de faon collgiale (entre toutes les entreprises intervee c e
2. Attaque pour dcryptage de la cl de scurit des Network PlayStation de Sony en e e e e mai 2011
10
nantes) et peut donc prendre un temps considrable. A loppos, dans le second cas, e e lopration se ralise dans limmdiat. e e e
2.1.5
Classication
Avant de prsenter les dirents types de cloud pouvant tre dvelopps, nous e e e e e tablissons dans un premier temps quelques crit`res de classication : e e La raison de dveloppement (business model ). Cest la raison qui justie la e mise en place de la plateforme. Elle peut tre commerciale, scientique ou e communautaire. Le niveau de services. Cest lambition du cloud a fournir aux entreprises une ` plateforme proche ou pas de leurs attentes. Laccessibilit. Le cloud peut tre accessible par tous (cloud public) ou rese e treint a un public particulier (cloud priv). Contrairement aux deux premiers, ` e nous ne dveloppons pas celui-ci tant donn sa simplicit de comprhension. e e e e e
2.1.5.1
Par raison de dveloppement e
Lutilisation du CC ne se limite pas uniquement aux entreprises ` caract`re a e commercial. En fonction des raisons de sa mise en place, nous distinguons quatre catgories de plateformes de CC a savoir : e ` Cloud dEntreprises. Dans cette catgorie, nous retrouvons des entreprises de e petites et de moyennes tailles disposant chacune de peu de ressources et de moyens de maintenance de leurs infrastructures. Elles se regroupent donc autour dun projet de cloud an de mutualiser leurs capacits. La plateforme qui en dcoule est prive, e e e cest-`-dire accessible uniquement par les entits des direntes entreprises. Cette a e e plateforme a lavantage dtre de petite taille et dacc`s restreint ` des utilisateurs ` e e a connus. Ainsi, les probl`mes de scurit sont rduits et ladministration peut tre e e e e e spcialise. Les groupes Amazon EC2 [61] (via le Virtual Private Cloud ), VMe e ware [VMware.org] ou encore VeePee [VeePee] orent par exemple des solutions de clouds privs. e En comparaison avec les technologies existantes, cette catgorie est identique aux e clusters privs. e Cloud Gouvernemental et Recherche Scientique. Pour des raisons de recherche et de dveloppement, des instituts de recherche mettent sur pied des ene vironnements de cloud. Leur dveloppement est encourag et nanc par des goue e e vernements. Lacc`s est exclusivement rserv aux personnes exerant dans le mme e e e c e domaine de recherche, ou appartenant aux instituts de recherche associs, ou ayant e une drogation prcise. Ces plateformes sont pour la plupart orientes projets. Seules e e e les avances scientiques obtenues par les groupes de recherche qui lutilisent pere mettent de valoriser la plateforme. Syst`me dadministration autonome adaptable : application au Cloud e
11
Dun point de vue technologique, dobjectif et dutilisation, aucune dirence e nest notable avec les grilles scientiques comme grid5000 [25]. Cloud pour Rseaux Sociaux et Jeux. Le dveloppement des rseaux soe e e ciaux et des jeux en ligne ncessite de plus en plus de grandes quantits de ressources. e e Cette ncessit est due a la croissance presque exponentielle dutilisateurs. De plus, e e ` lessence de ces environnements est la mise en commun dun certains nombre de donnes et de connaissances (donc de ressources). Dans ce contexte, le dveloppement e e dune plateforme similaire au cloud devient une vidence pour optimiser lutilisae tion des ressources et faciliter le partage de donnes. En eet, elles sont considres e ee comme plateforme de cloud a cause de leur recours aux principes de dveloppement ` e de celui-ci. Louverture de ces plateformes a tous et le nombre important dutilisateurs pour` raient constituer un handicap pour leur gestion. Or nhbergeant quune seule ape plication (celle du fournisseur), leur gestion est spcialise et moins complexe. Elles e e sont comparables aux clusters/griles privs. Les plateformes comme celles du rseau e e social facebook [facebook] ou des jeux en ligne zynga [Zynga] font partie de cette catgorie. e Cloud pour Fournisseurs de Services. Cest le mod`le le plus rpandu. Une e e entreprise, appele fournisseur, met a la disposition dautres (appeles clients) une e ` e plateforme dexcution dapplications et assure le service informatique inhrent. Il e e sagit dun mod`le ouvert a tout public et ` caract`re commercial. La plateforme e ` a e hberge tous types dapplications et lacc`s ` ces applications est ouvert aux utilie e a sateurs externes. Les ds de scurit et dadministration (que nous dtaillons dans e e e e la section 2.1.6) sont importants dans ce mod`le. La plateforme de CC Amazon e Elastic Compute Cloud (EC2) fait partie de ce cette catgorie. Sachant que cette e catgorie peut regrouper les autres, les contributions que nous apportons dans cette e th`se sadressent a cette catgorie de cloud. Notons que quelque soit le mod`le de e ` e e dveloppement considr, la plateforme qui en dcoule peut galement tre classe e ee e e e e selon son niveau dutilisation (section suivante). Notons quil existe des communauts de dveloppement logiciels autour de ces e e catgories de cloud. Elles fournissent des briques logicielles permettant de construie re/enrichir une plateforme de cloud. Tr`s souvent, il sagit dentreprises dont le but e est de dliser ses clients (futurs propritaires de plateformes de cloud). Les logie e ciels sont prsents a ces derniers comme une valeur ajoute de lvolution dun e e ` e e produit existant (comme un syst`me dexploitation). Ce dveloppement est le plus e e souvent pratiqu par des communauts de logiciels libres (plateforme Ubuntu Ene e terprise Cloud [Ubuntu] ou Eucalyptus [80]) ou encore par des grands groupes de dveloppement de logiciels spcialiss (Oracle Cloud Computing [ora]). e e e
2.1. LE CLOUD COMPUTING 2.1.5.2 Par niveau de service
12
En fonction du niveau dabstraction quore le cloud aux entreprises, nous identions dans la littrature trois catgories de plateformes de CC (gure 2.2(a)) : e e Infrastructure as a Service (IaaS). Cest le niveau de service le plus bas. Le cloud fournit des ressources matrielles aux entreprises (capacit de traitement, e e de stockage, etc.). Lacc`s a ces ressources peut tre direct ou virtuel (section 2.2). e ` e On retrouve dans cette catgorie les plateformes comme Amazon Elastic Compute e Cloud (EC2) [61] et IELO Cloud [Cloud]. Platform as a Service (PaaS). Il sagit dun niveau dabstraction au-dessus de lIaaS dans lequel le cloud fournit une plateforme applicative de programmation. Elle permet ` lentreprise de programmer des applications facilement administrables a dans le cloud. Elle oblige lentreprise dune part a ma ` triser lAPI du PaaS et dautre part ` r-implmenter ses applications suivant cet API. Google App Engine [46] et a e e Windows Azure [76] sont des exemples de PaaS. Software as a Service (SaaS). Ici, le cloud fournit directement les applications correspondants aux attentes des entreprises. Les tches dadministration sont a assures par le cloud ; lentreprise na pas grand chose a eectuer. Tr`s spcialis (par e ` e e e lapplication quil fournit), ce type de cloud est le moins rpandu. Les clouds pour e rseaux sociaux et jeux (prsents prcdemment) font partie de cette catgorie. e e e e e e Comme exemple de plateforme SaaS, nous pouvons citer Rightscale [RIGHSCALE] ou encore CORDYS [CORDYS]. Cette classication est la plus rpandue dans la littrature. Dans le but dviter e e e tout malentendu, nous proposons dans le paragraphe suivant, une vision simplie du e cloud. Cette prsentation est proche des clusters/grilles qui sont technologiquement e identiques au cloud. Notre vision. Sans entrer en contradiction avec la prsentation prcdente, e e e nous considrons toute plateforme de cloud comme une plateforme ` deux niveaux e a (gure 2.2(b)) : Abstraction et mutualisation des ressources. Ce niveau correspond exactement a lIaaS dans la vision classique. Nous y retrouvons donc a la fois les ressources ` ` et les applications permettant leur abstraction et mutualisation. Les applications des entreprises et celles utiles ` lexploitation du cloud. Il sagit a aussi bien des applications du SaaS, des applications dveloppes ` partir dun e e a PaaS, que de celles issues ni du PaaS ni du SaaS. Pour aller plus loin, nous considrons le PaaS comme une application sexcutant sur lIaaS. De ce fait, e e il a le mme statut que les autres applications. Lun des ds du cloud est e e lisolation de ces direntes applications. e
13
Figure 2.2 (a)Vision classique. (b) Notre vision.
2.1.6
Challenges
Le CC nest pas une rvolution technologique en soit mais constitue une oriene tation vers un mode de gestion des infrastructures informatiques des entreprises. Cependant, lide dhberger plusieurs applications dutilisateurs dirents pose quelques e e e ds que doit surmonter le cloud. Il sagit de lisolation, ladministration, linterope e rabilit et la portabilit des applications entre plusieurs plateformes. e e
2.1.6.1
Isolation
La mutualisation de ressources dans le cloud (comme dans toutes les infrastructures) implique la mise en place de divers mcanismes (scurit, comptage de rese e e sources, conit dacc`s, etc). Le plus important de ces derniers est la gestion des e conits/interfrences dacc`s entres les utilisateurs. Une rponse idale pour la mise e e e e en place de la mutualisation est lisolation. Nous regroupons sous ce terme plusieurs types disolation a savoir : lisolation des ressources, lisolation despaces utilisateurs, ` lisolation des performances et lisolation des dfaillances. e Lisolation des ressources (ou encore partitionnement) garantit au client lexclusivit dacc`s ` un ensemble de fractions (morceaux) de ressources due e a rant toute sa prsence dans le cloud (malgr la mutualisation). Le client a e e lillusion dtre le propritaire et consid`re lensemble comme des machines ene e e ti`res. Cette isolation permet dviter les situations de famine aux applications e e du client (situation dans laquelle une application attend indniment une rese source dtenue par une autre). De plus, elle permet au fournisseur du cloud e didentier et de compter les utilisations de ressources pour chaque utilisateur. Ce dcompte servira par la suite ` la facturation. e a Lisolation despaces utilisateurs donne a chaque client du cloud lillusion ` dtre le seul utilisateur. Rien ne doit le laisser prsager la prsence dautres e e e utilisateurs ou applications. Illustrons cela a travers lexemple dun cloud four`
14
nissant des environnements Linux. Dans cet environnement, chaque client peut accder en mode super utilisateur (root sous Linux) aux machines lui appare tenant. Cependant, lexcution de la commande ps -aux (achage de la liste e des processus) par exemple ne doit prsenter que les processus dmarrs par e e e lutilisateur en question. Lisolation des performances permet au cloud dassurer le non monopole des ressources globales du cloud par un seul client. Prenons lexemple des ressources rseaux pour illustrer cela. Une utilisation intensive de la bande e passante sur le cloud par une application cliente peut aecter lensemble du rseau et ainsi avoir un impact sur les autres utilisateurs. e Lisolation des dfaillances permet dassurer la non violation des espaces e utilisateurs dans le cloud. Il comprend galement le d de scurit. En tant e e e e que centre dhbergement dapplications multi-utilisateurs, le cloud doit garane tir lintgrit de chaque espace utilisateur vis-`-vis des autres. Ainsi, aucune e e a action malveillante ralise par un client ne doit altrer ni le fonctionnement e e e du cloud ni celui des applications appartenant a dautres clients. Cet objectif ` est dautant plus important que la plupart des utilisateurs du cloud sont non identiables. Il sagit des utilisateurs des services hbergs par les entreprises e e dans le cloud. La prise en compte de ce d a t eectue grce ` lintroduction des techniques e ee e a a de virtualisation (section 2.2) dans limplmentation du cloud. e
2.1.6.2
Administration
Comme nous lavons prsente prcdemment, lexploitation des plateformes de e e e e cloud implique lintervention de trois types dutilisateurs : ladministrateur du cloud, les entreprises et les utilisateurs des applications des entreprises. Les deux premiers (administrateur et entreprises) sont confronts quotidiennement ` plusieurs tches e a a dadministration (pour la plupart rptitives). Lall`gement de ces tches conditionne e e e a lexpansion du cloud dans les entreprises. En eet, an dviter le mme constat e e observ de lutilisation des grilles de calculs (rservs aux scientiques, donc aux e e e utilisateurs avertis), les plateformes de cloud doivent prendre en compte et faciliter les tches dadministration de ces deux utilisateurs. Comme nous le prsentons dans a e la section 3, les oprations dadministration eectues par ces deux utilisateurs sont e e semblables. Notons que lobjet de cette th`se porte essentiellement sur ce challenge. e
2.1.6.3
Interoprabilit et Portabilit e e e
Face a la multiplication des plateformes de cloud, les clients pourront tre confron` e ts plus tard ` deux choix : (1) la migration dune application dun cloud vers un e a autre et (2) lutilisation de plusieurs clouds pour lhbergement de la mme applie e cation. Le choix (1) se pose par exemple lorsque la concurrence entra un client ` ne a partir du cloud qui hberge son application vers un autre plus attrayant. Elle peut e Syst`me dadministration autonome adaptable : application au Cloud e
15
galement survenir lorsque la plateforme initiale dcide de rompre ses services, ce e e qui oblige le client a trouver une autre plateforme pouvant accueillir ses applications. ` Dans ces deux situations, il se pose le probl`me de portabilit de lapplication du e e cloud initial vers le cloud de destination. Quant au choix (2), il survient lorsque le cloud hbergeant lapplication se retrouve a cour de ressources. Dans ce cas, le client e ` ou le fournisseur peut dcider dassocier au cloud initial des ressources venant dune e autre plateforme. Ainsi, la mme application sexcute dans deux environnements de e e cloud dirents appartenant a des fournisseurs distincts. Lensemble form par les e ` e deux plateformes constitue un cloud hybride. Cette situation soul`ve le probl`me e e dinteroprabilit entre les plateformes de CC. Dans ces deux situations ((1) et (2)), e e la mise en place dune API harmonise (par standardisation) pour le dveloppement e e des plateformes de CC est la bienvenue.
2.2. ISOLATION PAR LA VIRTUALISATION
16
2.2
Isolation par la virtualisation
Comme nous lavons prsente dans la section 2.1.6.1, lisolation (au sens de la e e prsentation de la section 2.1.6.1) reprsente lun des ds majeurs dans limplmene e e e tation des plateformes de cloud. Il existe plusieurs faons de la mettre en uvre : c La premi`re mthode consiste ` allouer la ressource matrielle enti`re a une e e a e e ` entreprise mme si celle-ci ne souscrit que pour une fraction de cette ressource. e Cette mthode ne permet quune rsolution partielle des probl`mes disolation. e e e En eet, certaines ressources comme le rseau et sa bande passante restent e partages entre les entreprises dans le cloud. A moins que le fournisseur ale loue exclusivement a chaque entreprise des quipements et la bande passante ` e rseaux (ce qui nest pas raisonnable), il est impossible avec cette mthode e e dviter des situations de monopole de ces ressources par entreprise. Elle doit e tre complte avec une solution logicielle. e ee La seconde mthode consiste ` laisser la responsabilit aux entreprises dime a e planter les mcanismes disolation. Cette mthode nest pas envisageable dans e e la mesure o` le cloud ne dispose daucun moyen dintrospection des applicau tions dentreprise an de sassurer de limplantation de ces mcanismes. e La derni`re mthode est intermdiaire (matrielle et logicielle) aux deux pree e e e mi`res. Tout en implmentant les mcanismes disolation, elle donne lillusion ` e e e a lentreprise davoir un acc`s direct et exclusif a la ressource matrielle. Parallè ` e e lement, elle garantie au cloud le non acc`s direct des entreprises aux ressources e matrielles. Cest de lisolation par virtualisation. e
2.2.1
Dnition et Principes e
La virtualisation [58] se dnit comme lensemble des techniques matrielles et/ou e e logicielles qui permettent de faire fonctionner sur une seule machine, plusieurs syst`mes dexploitation (appels machines virtuelles (VM), ou encore OS invit). Elle e e e garantie lindpendance et lisolation des VM (lisolation telle que prsente dans la e e e section 2.1.6.1). En bref, elle permet dobtenir au niveau des VM la mme isolation e quore les machines relles. e Limplmentation dun syst`me de virtualisation repose sur une application sexe e e cutant entre le matriel et les machines virtuelles : cest la Virtual Machine Monitor e (VMM). Cest elle qui implante les mcanismes disolation et de partage des rese sources matrielles. La gure 2.3 montre larchitecture globale dun syst`me dune e e machine virtualise (c-`-d excutant un syst`me de virtualisation). La VMM est cae a e e pable de dmarrer simultanment plusieurs machines virtuelles de dirents types e e e (Linux, Mac ou encore Windows) sur le mme matriel. Comme dans un syst`me e e e dexploitation normal, chaque VM conserve son fonctionnement habituel. Autrement dit, elle a lillusion de grer les acc`s mmoire, disque, rseaux, processeur et e e e e autres priphriques de ses processus. Vu de lextrieur, lutilisateur peroit lene e e c Syst`me dadministration autonome adaptable : application au Cloud e
17
semble comme un environnement constitu de plusieurs machines relles. e e Quoique les VM g`rent les acc`s aux ressources, aucun acc`s aux ressources nest e e e possible sans laval et le concours de la VMM. Elle dcide notamment des attribue tions de temps processeurs aux machines virtuelles. Quant a la communication avec ` lextrieur, la VMM peut fournir plusieurs techniques pour rendre accessible ou non e les VM. Elle peut la raliser par assignation dadresses IP et par implantation des e mcanismes dacc`s rseaux aux VM (par routage, ltrage de communication, etc). e e e
En plus de fournir un syst`me disolation de syst`me dexploitation, lun des e e premiers objectifs de la virtualisation est dorir des performances proches de celles des machines relles. La section suivante prsente ces objectifs. e e
Figure 2.3 Vue des syst`mes virtualiss e e
2.2.2
Objectifs
De faon gnrale, limplmentation dun syst`me de virtualisation doit remplir c e e e e les trois objectifs suivants [84] : Lquivalence : toute excution dapplication dans un syst`me virtualis doit e e e e tre identique a une excution sur une machine relle ; ` lexception du temps dexe ` e e a e cution li ` la disponibilit des ressources (plusieurs tudes [23] montrent leur rapea e e prochement). Lecacit : la majorit des instructions de la VM doit directement tre exe e e e cute par le processeur sans intervention du logiciel de virtualisation. e Le contrle de ressources : lensemble des ressources est gr de faon excluo ee c sive (voir la section prcdente) par le logiciel de virtualisation. Ceci permet dassurer e e lisolation de performance et de scurit. e e
18
2.2.3
Bnces pour les entreprises e e
Malgr le surcot dexcution induit (3%[27]) par les syst`mes de virtualisation e u e e actuels, la virtualisation ore plusieurs avantages aux entreprises qui en font lusage. Nous remarquons dans la littrature, quil existe un amalgame entre les apports teche nologiques de la virtualisation et les consquences de ces apports dans une entreprise. e Dans cette section, nous vitons de faire cet amalgame. e Le tour est vite fait lorsquil sagit de trouver les apports techniques de la virtualisation dans le domaine des syst`mes (en tant que domaine de recherche) : il sagit e essentiellement de lisolation. Prsent de cette faon, daucuns compareront cette e e c isolation a celle dj` propose par les syst`mes dexploitation pour les processus. En ` ea e e ralit, le vritable apport est la capacit a isoler lexcution de plusieurs syst`mes e e e e` e e dexploitation (et non processus) dans le mme syst`me dexploitation. En raison du e e rapprochement avec certains objectifs du CC, lisolation propose par la virtualisae tion se dcline galement sous plusieurs formes identiques au CC (voir la section 4.1 e e pour leurs descriptions). Les atouts de la virtualisation peuvent se traduire sous plusieurs formes en entreprise. Les bnces possibles sont les suivants : e e Rduction des co ts. Au lieu dacqurir plusieurs serveurs matriels pour lexe u e e e cution de logiciels incapables de cohabiter, lentreprise utilise des machines virtuelles an disoler chaque logiciel. Pour les mmes raisons que le CC, cette excution ree e groupe permet galement de rduire les cots en consommation lectrique, ou encore e e e u e en supercie des locaux qui abritent les serveurs. Un atout concerne les dveloppeurs e de syst`mes dexploitation. Au lieu de ddier une machine pour la ralisation des e e e tests, les dveloppeurs peuvent se servir des machines virtuelles. e Unit de facturation. Dans un centre dhbergement, au lieu dutiliser une e e machine enti`re comme unit dallocation, la virtualisation permet dallouer une e e fraction de machine aux clients. Cet atout est notamment exploit dans certaines e plateformes de cloud. Sauvegarde de services. Dans certaines applications, la robustesse fait partie des premiers crit`res dvaluation. Elle se caractrise par la capacit du syst`me ` e e e e e a reprendre son activit dans un tat proche de la normale (c-`-d avant la panne) en e e a cas de panne dun des serveurs. La virtualisation permet de sauvegarder priodiquee ment ltat dexcution dune VM et de la redmarrer en cas de ncessit a partir e e e e e` dun point de sauvegarde. Cette opration est appele checkpointing dans le jargon e e de la virtualisation. Transfert de services. Nous entendons par transfert de services la possibilit e de dplacer lexcution dun service dune machine relle a une autre sans intere e e ` ruption. Cette caractristique est permise dans la virtualisation via des oprations e e de migration a chaud. Elle permet dexploiter les ressources dune machine relle ` e sous-utilise par un service en cours dexcution sur une machine relle sur-utilise. e e e e Inversement, elle permet de consolider sur un nombre rduit de machines, des sere vices en cours dexcution sur plusieurs machines sous utilises. Notons que tous e e
19
les syst`mes de virtualisation ne fournissent pas ce service. De plus leur ecacit e e dpend de la technique dimplmentation utilise. e e e
2.2.4
Classication
Face ` la dicult de mise en uvre du mod`le de virtualisation propos inia e e e tialement (virtualisation compl`te du matriel), a cause de la non compatibilit des e e ` e drivers matriels, plusieurs techniques de virtualisation se sont dveloppes. Amlioe e e e res au l des annes, les techniques dimplmentation de syst`mes virtuels peuvent e e e e tre regroupes en direntes catgories selon le rapprochement/loignement entre la e e e e e VM et le matriel. La gure 2.4 recense les catgories majeures que nous prsentons e e e bri`vement dans cette section. Le sens des `ches dans cette gure reprsente cette e e e volution chronologique. La prsentation que nous donnons dans cette section suit e e galement cet ordre. Ainsi le dveloppement des syst`mes les plus rcents se justie e e e e par les inconvnients des prdcesseurs. Notons que certains termes employs ici e e e e peuvent se retrouver dans la littrature avec des descriptions direntes. e e Virtualisation du syst`me de chiers (gure 2.4(a)). Cest une mthode e e qui repose sur un syst`me dexploitation pr-install (syst`me hte). Ce dernier e e e e o permet de construire des espaces utilisateurs (dsignation de la VM ici) dont les syse t`mes de chiers sont compl`tement isols. Chaque VM dispose dune arborescence e e e de syst`me de chiers a exclusif qui lui est propre. Les autres ressources telles que la e ` mmoire, les cartes rseaux, le processeur sont directement accessibles par les VM. e e Il nexiste aucune isolation pour ces ressources. On retrouve dans cette catgorie des e outils chroot ou UML (User Mode Linux) [uml]. Lmulation (gure 2.4(b)). La catgorie prcdente ne permettant pas linse e e e tallation dOS, il sest dvelopp une technologie base sur lmulation. Cette teche e e e nique propose une application (le virtualisateur) qui sexcute au-dessus du syst`me e e hte, dans lespace utilisateur. Cette application (qui correspond ` la VMM) a pour o a mission dmuler le matriel et permet ainsi de dmarrer plusieurs syst`mes dexe e e e ploitation rels dans lespace utilisateur. Cette technique de virtualisation induit un e surcot considrable dans lexcution des machines virtuelles. En eet, chaque opu e e e ration eectue dans la VM est intercepte et interprte par la VMM. Le syst`me e e ee e de virtualisation VirtualBox [VirtualBox.org] est bas sur cette technique. e Paravirtualisation (gure 2.4(c)). La paravirtualisation a t dveloppe ee e e pour rsoudre les probl`mes de la catgorie prcdente. Elle consiste ` modier les e e e e e a OS des VM an quils soient au courant de leur statut (de VM). Ainsi, le matriel e est mapp dans la VM et donc accessible directement sous le contrle de la VMM e o (hyperviseur sur la gure 2.4(c)). Cette derni`re sexcute directement au-dessus du e e matriel. Elle remplace lOS hte, qui est considr comme une VM. La contrainte de e o ee modication dOS des VM est une limite ` cette technique. En eet, elle ne permet a pas lexcution de VM munies dOS propritaires (comme Windows). La plateforme e e
20
Xen [23] est le syst`me de paravirtualisation le plus rpandu grce au niveau de e e a performance quil ore [27]. Les travaux de cette th`se sont notamment bass sur ce e e syst`me. e Virtualisation assiste par le matriel (gure 2.4(d)). Lvolution actuelle e e e des drivers matriels et des processeurs (technologie Intel VT [Corporation]) vers la e prise en compte de la virtualisation permet de dvelopper une nouvelle technique de e virtualisation. Ainsi, lintervention de la VMM sur les actions des VM est limite et e celles-ci nont plus besoin dtre modies. Les nouvelles implmentations de Xen e e e ou VMware [VMware.org] permettent dutiliser cette technique lorsque le matriel e le supporte.
Figure 2.4 Techniques de virtualisation
2.2.5
Synth`se e
Apr`s cette prsentation de la virtualisation, nous constatons quelle rpond pare e e faitement au challenge disolation auquel est confront le cloud. De plus, nous constae tons que les bnces de la virtualisation vis a vis des entreprises rejoignent ceux du e e ` Syst`me dadministration autonome adaptable : application au Cloud e
21
cloud. Elle amplie notamment la pratique de la mutualisation des ressources, qui est au cur du cloud. Quant aux techniques disolation par rservation enti`re de e e ressources, nous montrons quelles sont moins bnques. En outre, elle ne couvrent e e pas tous les besoins disolation que requiert le cloud. Pour ces raisons, la majorit des e plateformes de cloud ([61], [76], [Cloud], [OpenNebula], [80], etc.) adopte la virtualisation comme technique disolation. Cest cette catgorie de cloud qui nous intresse e e dans cette th`se. e Son introduction dans le cloud implique la modication du mode de gestion des ressources et plus globalement des tches dadministration. En ce qui concerne la a gestion des ressources, lunit dallocation dans le cloud passe de la machine relle e e a la machine virtuelle. Quant ` ladministration, elle contraint les administrateurs ` a du cloud dacqurir des comptences en mati`re de virtualisation. Dans la section e e e suivante, nous dcrivons a quoi correspond ladministration dans une plateforme de e ` CC base sur la virtualisation. e
Chapitre 3 Administration dans le Cloud

Contents
3.1 Administration niveau IaaS . . . . . . . . . . . 3.1.1 Allocation de ressources . . . . . . . . . . . . . 3.1.2 Dploiement . . . . . . . . . . . . . . . . . . . e 3.1.3 Conguration et Dmarrage . . . . . . . . . . . e 3.1.4 Reconguration . . . . . . . . . . . . . . . . . . 3.1.5 Monitoring . . . . . . . . . . . . . . . . . . . . 3.2 Administration niveau Entreprise . . . . . . . . 3.2.1 Construction de VM et Dploiement . . . . . . e 3.2.2 Allocation de ressources . . . . . . . . . . . . . 3.2.3 Conguration et Dmarrage . . . . . . . . . . . e 3.2.4 Reconguration . . . . . . . . . . . . . . . . . . 3.2.5 Monitoring . . . . . . . . . . . . . . . . . . . . 3.3 Synth`se : syst`me dadministration autonome e e cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pour le . . . . . . 23 . 24 . 24 . 25 . 25 . 26 . 27 . 28 . 29 . 29 . 30 . 30 . 31
Conues comme une volution des plateformes partages, les clouds ncessitent c e e e des tches dadministration rencontres dans les grilles et les environnements disa e tribus en gnral. A celles-ci sajoutent celles relatives a lintroduction de la vire e e ` tualisation. Elles concernent les dirents protagonistes dans le cloud. Comme nous e lavons prsent dans la section 2.1.5.2, nous distinguons trois types dutilisateurs e e dans le cloud (gure 3.1) : le fournisseur (administre le cloud), les entreprises clientes (utilisent les ressources du cloud et administrent ses applications) et les utilisateurs naux (ceux qui utilisent les services fournis par les applications entreprises). Contrairement aux deux premiers utilisateurs, le dernier nest confront a aucune e ` tche dadministration. Lanalyse de cette derni`re laisse para une symtrie entre a e tre e les oprations dadministration ralises par le fournisseur du cloud (niveau IaaS) e e e et celles ralises par les administrateurs des entreprises clientes du cloud (niveau e e entreprise) (observable sur la gure 3.2). Globalement, les gestionnaires des deux niveaux dadministration assurent des tches de : a
3.1. ADMINISTRATION NIVEAU IAAS
23
Dploiement : dploiement de VM au niveau IaaS et dploiement de logiciels e e e pour lentreprise cliente ; Monitoring : monitoring des ressources matrielles et VM au niveau IaaS (ase sur par llment MonitoringController dans la gure 3.2) et monitoring des e ee logiciels au niveau entreprise cliente (assur par llment AppMonitoringCone ee trolle dans la gure 3.2) ; Gestion des ressources : allocation ecace des ressources matrielles au nie veau IaaS (assure par llment ResourceController dans la gure 3.2) et e ee rservation ecace de VM au niveau entreprise cliente (assure par llment e e ee AppResourceController dans la gure 3.2) ; Reconguration : reconguration des VM au niveau de lIaaS (assure par e llment AppMonitoringControlle dans la gure 3.2) et reconguration des ee logiciels, pour le passage ` lchelle par exemple, au niveau entreprise cliente a e (assure par llment AppScheduler dans la gure 3.2). e ee Dans cette section, nous prsentons en dtail et sparment dune part ladminise e e e tration telle queectue dans lIaaS et dautre part les oprations dadministration e e ralises par lentreprise. e e
Figure 3.1 Architecture simplie du Cloud e
3.1
Administration niveau IaaS
Directement rattache a lenvironnement matriel, ladministration au niveau de e ` e lIaaS se rsume a la gestion des machines virtuelles (pour une utilisation ecace e ` des ressources) et de ses serveurs de gestion (scheduler, serveurs de stockage, etc.). Ne pouvant tre ralises en avance, certaines tches dadministration de lIaaS sont e e e a provoques par celles des entreprises (elles seront interprtes comme des oprations e ee e de reconguration). Parmi les oprations dadministration au niveau IaaS, les plus e courantes sont : lallocation de ressources, le dploiement de ses serveurs et des VM, e la conguration et le dmarrage (des VM et ses serveurs). Quant aux autres, elles sont e
24
provoques par des vnements externes pour certaines (consolidation, rparation) e e e e et rguli`res pour dautres (monitoring). e e
3.1.1
Allocation de ressources
Cest la premi`re opration ralise dans le cloud. Elle attribue ` lentreprise e e e e a cliente sa portion de ressources exploitables. Par ressources, nous regroupons ` la fois a la mmoire, le processeur, lespace de stockage, la bande passante et les quipements e e informatiques. Mutualises entre tous les utilisateurs, les ressources reprsentent le e e point de rentabilit pour le fournisseur. Ainsi, la conception et limplmentation e e des politiques dallocation dans le cloud dpendent de la stratgie commerciale du e e fournisseur. Notons que lallocation est provoque entre autres par une rservation e e de lentreprise. Le fournisseur peut dont proposer plusieurs mani`res de rservation : e e 1. Rservation pour une dure indtermine : dans ce mode, un contrat est tabli e e e e e avec lentreprise pour une dure innie et continue (on peut galement parler e e de forfait). 2. Rservation pour une utilisation ` venir et pour une dure limite : dans ce e a e e mode, la dicult se situe dans la gestion des plages de rservation. On retrouve e e le probl`me tr`s connu et complexe qui est celui de la planication. e e 3. Rservation pour une utilisation immdiate et limite dans le temps : dans ce e e e cas, les ressources requises doivent tre disponibles dans limmdiat. e e La prise en compte de ces modes de rservation peut complexier lallocation dans le e cloud. Notamment, il peut tre amen ` mettre en place des les dattente, avec des e ea notions de priorit. Ainsi, en guise dexemple, les ressources obtenues par le dernier e mode de rservation peuvent tre considres comme moins prioritaires que celles e e ee obtenues via les deux premiers. Dans ce cas, le cloud doit tre capable didentier e les ressources ` librer en cas de besoin dune application plus prioritaire. a e
3.1.2
Dploiement e
Le dploiement dans lIaaS concerne essentiellement les syst`mes de chiers des e e machines virtuelles. Il est ralis ` deux occasions. Premi`rement (`che (2) de la e ea e e gure 3.2) lors de lenregistrement dans le cloud des syst`mes de chiers dOS (gae e lement appels images) et des donnes de lentreprise. Pour cela, le cloud utilise un e e serveur de stockage (que nous appelons RepositoryController dans la gure 3.2) distinct des lieux dexcution des VM. Le second dploiement (`che (4) de la gure 3.2) e e e intervient a lexcution de celles-ci. En eet, limage utilise pour lexcution dune ` e e e VM dans le cloud est une copie de limage initiale. Ceci sexplique par deux raisons. La premi`re est la possible inaccessibilit des machines htes (hbergeant les VM) e e o e au serveur de stockage. Tr`s souvent, pour des raisons decacit, le format de stoe e ckage des donnes (y compris les syst`mes de chiers) par le serveur de stockage e e peut tre dirent de celui attendu par le syst`me de virtualisation qui excutera la e e e e Syst`me dadministration autonome adaptable : application au Cloud e
25
VM. Cest le cas dans le cloud Amazon EC2 [61]. La deuxi`me raison est la possible e utilisation de la mme image pour lexcution de plusieurs VM. De plus, lentreprise e e peut souhaiter retrouver limage originale apr`s lexcution de la VM (sauf demande e e contraire).
3.1.3
Conguration et Dmarrage e
Lopration de dmarrage des machines virtuelles ncessite pralablement leur e e e e conguration. Cette derni`re dpend dune part des demandes de lentreprise et e e dautre part de la politique dallocation de ressources dans le cloud. Pendant la phase de rservation, une entreprise souscrit pour des VM dont elle fournit les cae ractristiques au cloud. Ces caractristiques concernent : la quantit de mmoires, e e e e le nombre de processeurs, le lieu gomtrique dexcution de la VM et le syst`me de e e e e chiers reprsentant lOS de la VM. Quant aux contraintes de conguration venant e de lIaaS, il sagit des congurations rseaux. En eet, lIaaS peut implmenter plue e sieurs congurations dacc`s rseaux : lattribution dun rseau virtuel (VLAN) aux e e e VM appartenant a la mme entreprise ou encore lutilisation dun VLAN commun ` e pour toutes les VM (il ne sagit que dexemples). Il doit galement congurer les e contrles rseaux (pare feu ou encore les quotas dutilisation rseau) en fonction des o e e souscriptions de lentreprise.
3.1.4
Reconguration
Comme nous lavons voqu dans le prambule de cette section, la plupart des e e e tches dadministration au niveau de lIaaS peuvent tre interprtes comme des a e ee oprations de reconguration (ralises par le VMController sur la gure 3.2). En e e e eet, elles interviennent pendant lexcution de lIaaS et modient sa composition. e Dans cette section, nous prsentons quelques tches de recongurations particuli`res, e a e lies essentiellement a la gestion des VM : la consolidation et la rparation. e ` e Consolidation de VM Nous nous rappelons des plateformes dhbergement dans lesquelles des machines e enti`res taient ddies ` un client. Dans ces plateformes, aucune tche dadminise e e e a a tration de la part du fournisseur ntait envisageable une fois la machine alloue e e au client (au risque de violer lexclusivit dutilisation de la machine par le client). e A linverse, les clouds bass sur la virtualisation orent une marge a ladministrae ` teur de lIaaS pour une intervention sur les machines physiques. Cette possibilit e est oerte par le caract`re isolant de la virtualisation. Elle permet entre autres au e fournisseur dimplmenter direntes politiques dallocation ou redistribution de rese e sources, dans le but deectuer des conomies ou de respecter un contrat client. e La premi`re intervention dans la gestion de ressources survient pendant la phase e
26
dallocation de VM (elle est galement dite phase de placement). Durant cette phase, e lIaaS doit tre capable didentier lensemble des machines physiques correspondant e a la politique dallocation implante par le fournisseur. Pour illustrer cela, prenons ` e une politique qui consiste ` choisir les machines de telle sorte que le risque de gasa pillage soit le plus faible possible. Cette contrainte peut entra ner le dplacement des e VM en cours dexcution an de librer de la place pour la VM alloue. On parle e e e de consolidation de VM. Par exemple prenons le cas dun IaaS constitu de trois e machines physiques M P1 , M P2 et M P3 de puissance identique note p. Supposons e que M P1 et M P2 utilises respectivement ` moiti de leur puissance. Soit un client e a e ayant besoin dune machine virtuelle dont la puissance requise est 3 p. Dans cette 4 situation, au lieu de faire recours a la troisi`me machine virtuelle, lIaaS doit tre ` e e capable de regrouper les deux machines virtuelles des deux machines M P1 et M P2 sur la machine M P1 ou M P2 et dallouer par la suite lune des machines libres ` ee a la nouvelle machine virtuelle. Notons que la consolidation peut galement seectuer en dehors des oprations e e dallocation. En eet, lIaaS scrute rguli`rement son environnement et rorganise e e e la disposition des VM sur les machines an de librer certaines. Cette libration de e e machines permet de rduire les taux de consommation nergtique de lIaaS. e e e Rparation de pannes e Compte tenu de la taille du cloud et de la multitude dutilisateurs et du nombre de clients quil accueille, le risque dapparition de pannes est important. Lapparition dun dysfonctionnement doit tre rapidement identie et traite par ladministrae e e teur an de ne pas pnaliser les entreprises. Lune des pannes les plus critiques dans e lIaaS est le dysfonctionnement dune machine physique ou virtuelle. En eet, elle aecte les applications des entreprises. A cause de sa non intrusivit, lIaaS nest pas e au courant des logiciels en cours dexcution dans les VM quil hberge. De ce fait, e e lIaaS ne saurait rsoudre ecacement une panne sans la collaboration de lentreprise e concerne. Malgr cette limitation, lIaaS peut proter des atouts de la virtualisation e e et proposer ainsi plusieurs politiques de rparation. Celles-ci peuvent aller des plus e simples (redmarrage de la VM concerne) aux plus sophistiques (redmarrage sur e e e e le dernier point de sauvegarde). Lapplication de ces politiques peut dpendre des e termes du contrat souscrit par lentreprise. Dans tous les cas, la mise en place de ces politiques dpend du syst`me de surveillance implant dans lIaaS. e e e
3.1.5
Monitoring
Les sections prcdentes ont introduit la notion de monitoring. En eet, toutes e e les tches dadministration dans le cloud dpendent des informations obtenues par a e monitoring des environnements matriels, virtuels et logiciels (ralis par Monitoe e e ringController sur la gure 3.2). Parmi les informations de monitoring qui nous intressent, nous pouvons citer le taux dutilisation des processeurs, des disques, du e rseau, de la mmoire, etc. Cependant, larchitecture particuli`re du cloud et des ape e e
3.2. ADMINISTRATION NIVEAU ENTREPRISE
27
plications qui y sont excutes constitue un facteur limitant pour le monitoring. En e e eet, rput comme une tche complexe dans les environnements distribus constie e a e tus de machines relles, le monitoring dans le cloud est un vritable challenge. e e e Les ressources tant virtualises dans le cloud, il nest pas vident de fournir une e e e image retant ltat rel des machines. En eet, nous distinguons deux niveaux e e e dobservation et danalyse de ressources : la machine virtuelle et la machine physique. Dune part, lIaaS doit tre capable de sparer les ressources consommes par e e e chaque niveau an de fournir aux clients des informations relatives uniquement a ` leur consommation. Dautre part, lIaaS doit fournir ` son administrateur les infora mations concernant a la fois les VM et les machines les hbergeant. Dans les deux ` e cas, les informations doivent tre comprhensibles et exploitables. e e Jusqu` prsent, nous nvoquons que des informations locales ` chaque machine a e e a physique ou virtuelle. Or le cloud est un syst`me rparti et htrog`ne. Dans la e e ee e plupart des cas, ladministrateur sintresse aux informations agrges et obtenues e e e par calculs groups des observations locales. Par exemple, ce calcul peut se faire par e combinaison des informations provenant dun ensemble de machines appartenant ` a la mme zone gographique ou a la mme entreprise. e e ` e
Figure 3.2 Administration dans le cloud
3.2
Administration niveau Entreprise
Malgr les avantages quil ore, le cloud peine a sduire les entreprises depuis sa e ` e vulgarisation. Cette hsitation est dordre idologique : lide de coner ses donnes e e e e (essentielles pour la concurrence) a une entreprise externe nest pas encore compl`` e tement accepte dans les entreprises. Face cette ide, le cloud rpond avec plus de e e e
28
dveloppement de la scurit et la condentialit. Comme en interne, ladministrae e e e tion dapplications sur le cloud est une tche fastidieuse pour lentreprise. De plus, a dans le cadre des clouds virtualiss, la gestion des VM reprsente une opration e e e supplmentaire. En somme, ladministration dapplications dans un cloud virtualis e e comprend les tches suivantes : a Construction de syst`mes dexploitation (ou VM) ; e Rservation/Allocation de ressources sur le cloud ; e Installation et dmarrage des logiciels ; e Suivi de lexcution des logiciels et des VM ; e Reconguration/Optimisation (scalabilit, mise ` jour des logiciels, rparation, e a e etc.).
3.2.1
Construction de VM et Dploiement e
Lexcution de toute application par une entreprise dans le cloud a lieu dans e une VM. Lexcution de cette derni`re requiert la prsence de son image dans le e e e serveur de stockage du cloud. Pour lentreprise, le dploiement peut donc seectuer e a deux occasions : pendant le tlchargement du syst`me de chiers des VM (`che ` ee e e (2) sur la gure 3.2) et pendant la copie (de lentreprise vers les VM) des binaires des logiciels constituant son application (`che (5) sur la gure 3.2). Comme nous le e prsentons dans cette section, le second dploiement peut sappuyer sur le premier. e e La premi`re tape avant toute rservation sur le cloud est la construction des e e e syst`mes de chiers. Elle comprend les phases suivantes : (1) installation du syst`me e e dexploitation, (2) conguration du syst`me dexploitation et (3) ventuellement e e linstallation des packages ou binaires des futurs logiciels. Dans certains cas, les phases (1) et (2) ne sont pas ncessaires lorsque le cloud fournit un syst`me de e e chiers rpondant aux attentes de lentreprise. Dans tous les cas, lentreprise eectue e la derni`re tape qui est linstallation de ses logiciels. Cette tche peut seectuer de e e a direntes faons. e c Mthode 1 : Elle construit un OS contenant tous les binaires et packages de tous e ses logiciels (`ches (1), (1) et (1) sur la gure 3.2). La construction seectue chez e elle et le rsultat (un OS de grande taille) est ensuite transfr sur le cloud grce aux e ee a protocoles de sauvegarde quil fournit. Cest par exemple le cas avec Simple Storage Service (S3) du cloud Amazon EC2. Le bnce de cette mthode est la rduction e e e e du nombre de syst`mes de chiers sauvegards dans le cloud (donc des cots de e e u stockage). Par contre a lexcution, lentreprise paye le prix fort. En eet, lexcution ` e e de toute VM a partir de cet OS augmente lespace de stockage de lentreprise et donc ` le cot dexcution. u e Mthode 2 : Construction dun syst`me de chiers ddi pour chaque type de e e e e logiciels (`ches (1) et [(1) ou (1)] sur la gure 3.2). Les avantages de cette mthode e e sont les inconvnients de la prcdente et inversement. Autrement dit, elle est moins e e e Syst`me dadministration autonome adaptable : application au Cloud e
29
coteuse lorsque les VM sont a lexcution qu` larrt. En eet, soient ts la taille u ` e a e dun syst`me dexploitation, n le nombre de logiciels constituant lapplication, tli la e taille du i`me logiciel avec i [1 ; n] . Lespace de stockage dans cette mthode est e e n n n*ts + i=1 tli (avec n le nombre de logiciels) tandis quil est de ts + i=1 tli dans la premi`re mthode. e e Mthode 3 : La derni`re est une solution intermdiaire aux deux premi`res e e e e (`ches (5) sur la gure 3.2). Le syst`me de chier ne contient que lOS minimal ` e e a excuter. Ainsi a lexcution, ladministrateur eectue les oprations de dploiement e ` e e e et dinstallation des logiciels sur ses instances de VM. Elle prsente les avantages e de la premi`re et de la seconde approche. Par contre, elle est plus technique, fase tidieuse et ncessite plusieurs connexions ` distance sur les VM. Ainsi, pour une e a excution multiple du mme logiciel, ladministrateur ralise plusieurs installations e e e de ce logiciel.
3.2.2
Allocation de ressources
Lallocation de ressources pour lentreprise peut consister en la rservation des e lieux de stockage ou encore des machines. La premi`re permet de stocker les images e dOS construites ou des donnes utilisables par la suite par les VM. Rappelons e que ces derni`res ne sont pas vues par lentreprise comme des VM. Pour elle, il e sagit de machines physiques mises a sa disposition par le cloud et dont elle est ` propritaire. Cette opration est faite sous forme de contrats passs avec le cloud. e e e Lentreprise souscrit pour plusieurs ressources de capacits identiques ou non (en e terme de processeur, mmoire, bande passante, etc). Cette rservation se traduit au e e niveau de lIaaS par le dmarrage des VM correspondantes et par la transmission e a lentreprise des informations de connexion (`che (3) sur la gure 3.2). La n ` e du contrat entra larrt des VM et la libration des ressources qui leur taient ne e e e alloues. e
3.2.3
Conguration et Dmarrage e
Une fois les VM dmarres et les binaires des logiciels dploys, ladministrateur e e e e de lentreprise planie la conguration et le dmarrage des logiciels. Ces oprations e e ncessitent des acc`s multiples aux VM via les adresses IP ou nom DNS des VM. e e Elles dpendent des logiciels administrs. Dans certains cas, le dmarrage peut ne e e e cessiter la conguration des liens de communication entre logiciels situs sur des VM e direntes. A cause de la multitude des logiciels, ces oprations sont souvent sources e e derreurs. De plus, certaines applications imposent un ordre de dmarrage entre les e logiciels. Cest le cas par exemple des serveurs Tomcat qui doivent tre dmarrs e e e avant les serveurs web Apache dans une application J2EE.
30
3.2.4
Reconguration
Comme pour lIaaS, les oprations de reconguration ralisables par lentreprise e e peuvent tre dnombres a linni (ralises par Scheduler dapplications sur la e e e ` e e gure 3.2). Dans cette section, nous prsentons deux oprations particuli`res, tr`s e e e e courantes dans ladministration des applications distribues : e Scalabilit e Une fois lapplication dmarre, lentreprise doit tre capable de suivre ltat des e e e e dirents logiciels (voir la section suivante sur le monitoring) an dintervenir en e cas de ncessit. Par exemple, lobservation dune monte en charge au niveau dun e e e tiers J2EE incitera ladministrateur ` rserver une nouvelle VM et eectuer tout le a e processus de dmarrage dune nouvelle instance du logiciel concern an dabsorber e e le surplus de charge. Inversement, il pourra retirer des instances de serveurs lorsque celles-ci sont sous utilises. Lensemble de ces deux oprations permettra de raliser e e e des conomies (par diminution du nombre de VM en utilisation dans le cloud). Cette e pratique est communment appele scalabilit ou principe de la croissance ` e e e a la demande. Rparation e Comme en interne, deux types de pannes peuvent survenir durant lexcution e de lapplication : (1) une panne machine (VM ici) ou (2) une panne logicielle. Ne disposant daucune action rparatrice sur ses VM, lentreprise peut souscrire (aupr`s e e du cloud) pour un contrat de rparation en cas de (1). Dans ce cas, lentreprise peut e tre amene a redployer et dmarrer les logiciels qui sexcutaient sur la VM avant e e ` e e e la panne. Si lIaaS implante la sauvegarde rguli`re des VM, lentreprise na aucune e e rparation ` eectuer. Quant aux pannes de type (2), leurs rparations dpendent e a e e de lapplication. Elles sont de ce fait hors de la porte du cloud. Dans certaines e applications, une panne de type (1) ou (2) peut entra ner la reconguration enti`re e de lapplication. Cest le cas de lapplication J2EE dans laquelle une panne du logiciel Tomcat ncessite le redmarrage du logiciel Apache. e e
3.2.5
Monitoring
La plupart des informations de monitoring recueillies a ce niveau proviennent ` directement des API de lIaaS (liaison entre Monitoring dapplications et Monitoring de lIaaS sur la gure 3.2). Cependant, dans certains cas, ces informations sont insusantes. Par exemple, la dtermination de ltat de surcharge dun serveur e e de base de donnes est plus signicatif lorsquon observe son temps de rponse au e e lieu de la charge CPU de la machine qui lhberge. Pour ces cas particuliers, lade ministrateur introduit dans son application, des logiciels particuliers jouant le rle o de sonde (liaisons entre Monitoring dapplications et les VM sur la gure 3.2). Les informations rcupres par ces sondes sont analyses de faon individuelle ou e ee e c groupe et servent a la prise de dcision (pour des recongurations). e ` e Syst`me dadministration autonome adaptable : application au Cloud e
` ` 3.3. SYNTHESE : SYSTEME DADMINISTRATION AUTONOME POUR LE CLOUD 31
3.3
Synth`se : syst`me dadministration autonome e e pour le cloud
En rsum, ladministration dans le cloud est essentiellement lie a son exploie e e ` tation niveau IaaS et niveau entreprise. Dans les deux niveaux, nous retrouvons des oprations dadministration du mme type. Elles sont proches de celles rencontres e e e dans les grilles de calcul et les environnements distribus. Au niveau IaaS, ladminise tration consiste en la gestion des ressources. De plus lutilisation de la virtualisation implique des tches dadministration supplmentaires qui lui sont propres. Quant a e a lentreprise, ses tches dadministration sont ` lorigine des recongurations au ` a a niveau de lIaaS. Elles sont pour la plupart propres aux applications hberges. e e Devant la multitude de ces tches, fournir une solution ge serait limite et a e e inapproprie dans certaines situations. De plus, ni le cloud, ni lentreprise ne peut e sorir les services dadministrateurs humains qui assureront de faon permanente c et continue (` longueur de journe) toutes ces tches. Ainsi, comme nous lavons a e a eectu dans ladministration des syst`mes distribus (grilles et cluster), nous proe e e posons dans cette th`se lutilisation dun syst`me dadministration autonome pour e e amliorer ladministration dans le cloud. Ce syst`me doit tre utilisable par les deux e e e types dintervenants. Pour cela, il doit globalement remplir les crit`res suivants : e Interoprable : capacit a dialoguer avec dautres syst`mes de gestion de e e ` e cloud et galement des syst`mes dadministration des applications quil he e e berge. Auto-rparable : capacit ` prendre en compte les pannes dans lenvironnee ea ment quil administre (machines, VM et logiciels). Extensible : capacit ` prendre en compte de nouveaux lments dans lenea ee vironnement (nouvelles machines relles et virtuelles, nouveaux logiciels). e Programmable : capacit a prendre en compte de nouvelles politiques dade` ministration (nouvelle mthode de consolidation, de scalabilit, etc.). e e Adaptable : capacit a prendre en compte le remplacement ou la modication e` dun de ses modules an de sappliquer a dautres plateformes de cloud. ` Langages ddis : propose des facilits dutilisation par le biais des langages e e e dadministration proches des comptences des intervenants. e Dans le chapitre suivant, nous montrons en quoi consiste ladministration autonome et dans quelle mesure ladministration autonome peut tre utilise dans cette proe e blmatique. e
Chapitre 4 Administration Autonome

Contents
4.1 4.2 4.3 4.4 4.5 Dnition . . . . . . . . . . . . e Objectifs . . . . . . . . . . . . . Bnces pour les entreprises e e Classication . . . . . . . . . . Synth`se . . . . . . . . . . . . . e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 33 34 35 36
Nous constatons depuis plusieurs annes la complexit croissante des infrastruce e tures et syst`mes informatiques. Cette complexit est due ` plusieurs facteurs tels e e a que la diversication des supports informatiques, la mobilit des utilisateurs, la mule tiplication des besoins et des logiciels, et laugmentation du nombre dutilisateurs doutils informatique, etc. La multiplication de ces facteurs oriente la construction des nouveaux syst`mes informatiques par combinaison de plusieurs autres syst`mes e e de natures direntes. De ce fait, leurs administration peut devenir un vritable obse e tacle a leur prennit. Elle peut devenir source derreurs et tre tr`s consommatrice ` e e e e en ressources humaines. Dans cette section, nous prsentons une solution consistant e a coner cette tche a un autre syst`me informatique (on parle dadministration ` a ` e autonome).
4.1
Dnition e
Un Syst`me dAdministration Autonome est un syst`me informatique conu pour e e c ladministration dautres syst`mes informatiques (matriels et logiciels). Dans la e e suite de ce document, nous utilisons lacronyme SAA pour dsigner un Syst`me e e dAdministration Autonome. Le fonctionnement dun tel syst`me repose sur quatre e modules essentiels (gure 4.1) : Le syst`me de reprsentation : Il maintient une image de lexcution relle e e e e de lapplication administre. e
4.2. OBJECTIFS
33
Les sondes : Elles reprsentent en quelque sorte lil du SAA sur les machines e hbergeant les logiciels quil administre. e Un module dcisionnel : En fonction des observations faites par les sondes e et de ltat courant de lapplication, le SAA peut prendre des dcisions confore e mment aux prvisions de ladministrateur humain. e e Les eecteurs/actionneurs : Contrairement aux sondes, ils permettent au SAA de raliser eectivement les oprations dadministration. Ils interviennent e e a la demande du SAA et doivent laisser le syst`me dans un tat conforme au ` e e syst`me de reprsentation. Leur intervention peut modier le comportement e e de lapplication administre. e
Figure 4.1 Organisation dun SAA
4.2
Objectifs
Ralise par des humains, ladministration de syst`mes complexes comporte des e e e limites. Par syst`mes complexes, nous entendons ceux faisant intervenir plusieurs e types de logiciels et sexcutant dans des environnements htrog`nes et distribus e ee e e (cas dun environnement de cloud). Parmi ces limites, nous pouvons citer : Le manque de ractivit dans la ralisation des tches : par exemple en rponse e e e a e a une panne ou conguration dun syst`me constitu de plusieurs logiciels. ` e e Le gaspillage de ressources. Cest une consquence du manque de ractivit. e e e Dans le but de prvenir des fortes demandes en ressources, ladministrateur e a tendance a sur-valuer celles-ci. Cette sur-valuation lui permet davoir une ` ` e e marge de temps avant lintervention.
4.3. BENEFICES POUR LES ENTREPRISES
34
En rponses a ces limites, le dveloppement de syst`mes informatiques jouant e ` e e le rle dadministrateur est une solution prouve ` travers plusieurs travaux de o e e a recherche. Pour cela, le SAA prend gnralement en compte tout le cycle de vie de e e lapplication administre a savoir [60] [78] [63] : e ` Le dploiement. Il consiste en lallocation de ressources matrielles suivie de e e leur initialisation. Nous entendons par ressources toutes les ressources mmoire, e CPU, disques, rseau et machines ncessaires au fonctionnement de lapplication. e e Linitialisation de la machine consiste au ravitaillement de celle-ci en chiers ou binaires constituant lapplication. La conguration. Elle consiste ` dnir les param`tres requis par lapplication a e e pour son fonctionnement. Elle se fait gnralement par la modication des chiers e e ou encore le positionnement de certaines variables. Le dmarrage et larrt. Il sagit de lexcution des direntes commandes e e e e mettant en marche ou non lapplication. Comme nous lavons voqu dans la sece e tion 3.2.3, le dmarrage peut savrer quelques fois ordonn. e e e La reconguration dynamique. Il sagit des oprations survenant durant e lexcution de lapplication. Elle peut tre cause par plusieurs facteurs : lapparition e e e dune panne, lessouement dun logiciel faisant partie de lapplication, lapparition dune mise ` jour, le dsir doptimisation, etc. Dans la littrature, les oprations de a e e e conguration, de dmarrage et darrt peuvent tre prsentes comme des tches de e e e e e a reconguration. La prise en compte de ces tches par les syst`mes dadministration autonome a e justie son adoption dans des entreprises comme solution dadministration. Dans la section suivante, nous prsentons les bnces dune telle pratique dans une entree e e prise.
4.3
Bnces pour les entreprises e e
Les bnces de ladministration autonome en entreprise sont aussi vidents que e e e ceux de linformatique dans une entreprise qui nen dispose pas. En eet, conu pour c remplir les fonctions dun administrateur humain, un SAA permet ` lentreprise de a raliser des conomies : e e Gain de temps. Ladministration assure par lhumain implique des intervene tions values en minutes, heures et voie jours. Or lutilisation dun SAA fait passer e e les temps dintervention ` la seconde ou milliseconde dans certains cas. Cette dia e rence peut tre facilement observe dans les tches de dploiement des applications e e a e grande chelle (centaines de logiciels). e
4.4. CLASSIFICATION
35
Rduction des ressources. Le remplacement des administrateurs humains par e un syst`me informatique permet dans un premier temps a lentreprise de rduire e ` e son eectif. Cette rduction implique moins de dpenses salariales. De plus, comme e e nous lavons voqu dans la section prcdente, lintroduction dune administration e e e e autonome implique moins de gaspillage en ressources matrielles. En eet, lentree prise ntant plus limite par la lenteur de lhumain et donc de sa surestimation, e e les ressources sont alloues et utilises par ncessit. Cette rduction de ressources e e e e e implique galement une conomie en nergie lectrique. e e e e Adaptabilit des logiciels. Ladministration autonome permet de rendre adape table les logiciels nayant pas t conus a cet eet. Cest le cas des logiciels tels que ee c ` Apache [52] ou Tomcat [53]. On dit dun syst`me quil est adaptable lorsquil est e capable de prendre en compte des modications de son environnement ou encore de son fonctionnement. Ladoption dun SAA permettra de prendre en compte ces modications. Il peut sagir dune adaptation ` une surcharge de travail dun logiciel. a Nous pouvons galement citer le cas de la rparation dune panne logicielle. e e
4.4
Classication
Depuis la pose des prmisses de cette technologie par IBM en 2003, plusieurs e projets de construction de SAA ont vu le jour. Ces dveloppements seectuent e suivant direntes orientations. Dans cette section, nous proposons quelques crit`res e e permettant de les regrouper par familles. Centralis ou distribu. Lecacit (en terme de temps dexcution) dun e e e e SAA est fortement lie a son mode de fonctionnement : centralis ou distribu. e ` e e Un SAA en fonctionnement centralis implique une gestion en un unique point. e Ce fonctionnement correspond ` ladministration des syst`mes de taille rduite (` a e e a cause du risque dun goulot dtranglement). Quant au fonctionnement distribu, e e ladministration peut tre eectue ` nimporte quel lieu de lenvironnement. Dans e e a le cadre des syst`mes ` large chelle (des milliers de logiciels et de machines), un e a e SAA centralis atteint ses limites et laisse la place aux SAA distribus. Ces derniers e e incluent ` la fois les SAA hirarchiss et non hirarchiss. Dans le premier cas, chaque a e e e e point dadministration ` la responsabilit dun morceau de lapplication administre. a e e En cas dimpossibilit dadministration, la tche est transmise au point suprieur qui e a e poss`de une vision plus tendue [91]. Dans le second cas par contre, les SAA sont e e quivalents et doivent collaborer an davoir des tats identiques. e e Adaptable ou non. Les SAA apportent de ladaptabilit aux infrastructures e quils administrent. Cela ne les empche pas de possder galement les mmes facule e e e ts. Un SAA adaptable donne la possibilit ` lutilisateur de remplacer des modules e ea ou des fonctions de base de ladministration. Par exemple, les mthodes de dploiee e ment ou dacc`s a distance sur les machines administres peuvent tre remplaces e ` e e e par dautres fonctions propres a lutilisation courante. ` Syst`me dadministration autonome adaptable : application au Cloud e
` 4.5. SYNTHESE
36
Gnrique ou spcique. La plupart des SAA existants sont conus pour des e e e c applications particuli`res (exemple de Proactive [35] pour les applications MPI). e Ceci implique que le moindre changement de lapplication administre ncessite la e e rimplantation du SAA. e
4.5
Synth`se e
A la lumi`re de cette prsentation, nous constatons dans un premier temps que le e e cloud fait partie des infrastructures dites complexes : plusieurs utilisateurs, plusieurs types dapplications, plusieurs technologies mises en commun, environnements distribus et large chelle. Dans un second temps, nous constatons que les tches dade e a ministration dans le cloud (section 3) correspondent parfaitement a celles auxquelles ` rpond ladministration autonome. A cause de sa nouveaut, les solutions dadminise e tration autonome nont pas fait lobjet de plusieurs exprimentations dans le cadre e du cloud. Dans la suite de ce document, nous explorons lutilisation de SAA pour ladministration dans le cloud. Notre tude sappuie sur le SAA TUNe [28] dvelopp e e e au sein de notre quipe. Le chapitre suivant prsente les principes fondateurs de ce e e syst`me. e
Chapitre 5 TUNe
Contents
5.1 5.2 Historique . . . . . . . . . . . . . . . . . . . . . Principes . . . . . . . . . . . . . . . . . . . . . 5.2.1 Architecture Description Language (ADL) . . 5.2.2 Wrapping Description Language (WDL) . . . 5.2.3 Reconguration Description Language (RDL) 5.3 Choix dimplantation . . . . . . . . . . . . . . 5.4 Exprimentations et Problmatiques . . . . . e e 5.4.1 Applications cluster . . . . . . . . . . . . . . 5.4.2 Applications large chelle : cas de DIET . . . e 5.4.3 Applications virtualises . . . . . . . . . . . . e 5.4.4 Cloud . . . . . . . . . . . . . . . . . . . . . . 5.5 Synth`se et nouvelle orientation . . . . . . . e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 39 39 41 42 43 46 46 47 48 50 52
Exerant dans le domaine de ladministration autonome depuis plusieurs annes c e maintenant, lquipe dans laquelle ces travaux ont t raliss a dvelopp autour du e ee e e e e projet TUNe [29], un SAA baptis du mme nom. Avant de prsenter ses principes e e e fondamentaux, nous revenons sur son historique. La n de ce chapitre prsente les e direntes expriences ralises avec ce syst`me, ses limitations ainsi que sa nouvelle e e e e e orientation. Pour des ns dillustration, tout exemple dans ce chapitre se base sur ladministration dune application J2EE. Il sagit dune application web dynamique organise e suivant une architecture n-tiers (gure 5.1) compose des logiciels suivants : e Apache [52] : le serveur web qui a pour but de servir des documents statiques. Dans certains cas, un loadbalancer (HA-Proxy [hap] par exemple) peut tre e associ a plusieurs serveurs Apache an dabsorber une quantit importante e` e dutilisateurs ; Tomcat [53] : le serveur dapplications qui, a la demande de Apache (via ` son connecteur ModJK [54] par exemple), eectue des traitements pour la construction dune page web ;
5.1. HISTORIQUE
38
Figure 5.1 Exemple dune architecture J2EE MySQL [98] et MySQL-Proxy [66] : ce dernier permet de relier le serveur dapplications a plusieurs sources de donnes MySQL. En cas de besoin, le ` e serveur dapplications fait appel au serveur de donnes MySQL pour le retrait e ou la sauvegarde de donnes venant des clients web. e
5.1
Historique
Le projet TUNe voit le jour en 2008 au sein de lquipe Astre du laboratoire e IRIT (Institut de Recherche en Informatique de Toulouse). Il sinscrit dans la continuit des projets SELFWARE 1 et SCOrWare 2 . Lobjectif principal du projet SELFe WARE est le dveloppement dune plateforme logicielle pour la construction de e syst`mes informatiques rpartis sous administration autonome, et son application e e a deux domaines particuliers : ladministration de serveurs dapplications J2EE et ` ladministration dun bus dinformation dentreprise. Quant au projet SCOrWare, il a pour ambition de fournir une implantation en logiciel libre des rcentes spe e cications Service Component Architecture (SCA) dnies par lOpen SOA Cole laboration. Lobjectif de TUNe dans ces projets est la proposition dune nouvelle plateforme dadministration palliant aux limites de son prdcesseur Jade [26]. Ce e e dernier a t dvelopp au sein de lINRIA dans le projet SARDES 3 a Grenoble. ee e e ` Jade est lun des premiers SAA orant les fonctionnalits dadministration telles que e dcrites par [64] (dploiement, conguration et reconguration). Sa grande particue e larit est ladministration de logiciels patrimoniaux, cest-`-dire ceux nayant pas e a t conus avec des facilits dadministration. En plus de fournir un support pour ee c e ladministration des logiciels dans un environnement rparti, il prend galement en e e compte la supervision de lenvironnement matriel administr. Il permet entre autre e e de dnir des encha e nements dactions excutables (de faon autonome) en rponse e c e a un vnement particulier dans lenvironnement administr (comme des pannes ou ` e e e des surcharges). Alors quil a permis de valider lapport des SAA et lapproche de dveloppement de SAA ` base de composants, Jade sadresse cependant ` des utie a a
1. Le projet SELFWARE : http ://sardes.inrialpes.fr/ boyer/selfware/index.php 2. Le projet SCOrWare : http ://www.scorware.org/ 3. Le projet SARDES : http ://sardes.inrialpes.fr/
5.2. PRINCIPES
39
lisateurs avertis du domaine a composants. En eet, il suppose que les utilisateurs ` ma trisent les techniques de programmation ` base de composants, notamment Fraca tal [31]. Dans ce contexte, le projet TUNe a donc pour mission dimplanter sous les bases de Jade, un SAA dont lutilisation est moins contraignante. Ainsi, TUNe implante des langages dadministration de haut niveau, bass sur les prols UML [81], e donc plus accessibles aux utilisateurs non initis ` Fractal. Dans la section suivante, e a nous prsentons ces langages et leur utilisation dans TUNe. e
5.2
Principes
La conception et limplantation du syst`me TUNe repose sur une approche base e e composants. Approche tr`s prometteuse, cette derni`re est galement au cur de la e e e conception dautres SAA tels que Rainbow [55]. Le principe gnral est dencapsue e ler les lments administrs dans des composants et dadministrer lenvironnement ee e logiciel comme une architecture a composants. Ainsi, le SAA bncie des atouts ` e e du mod`le ` composants utilis tels que lencapsulation, les outils de dploiement et e a e e les interfaces de reconguration pour limplantation des procdures dadministration e autonome. Grce ` cette approche, le SAA ore une vision uniforme de lenvirona a nement logiciel et matriel ` administrer. Pour ce qui est du projet TUNe (comme e a Jade), nous utilisons le mod`le a composants Fractal [31]. e ` Contrairement a Jade, TUNe masque la complexit lie a la ma ` e e ` trise des API de programmation du mod`le ` composants et fournit des langages de haut niveau. Ces e a derniers permettent notamment la description de ladministration de syst`mes large e chelle tout en minimisant les dicults rencontres avec Jade. Bas sur les prols e e e e UML [81] (largement utiliss) et un langage de navigation architectural, TUNe foure nit trois langages dadministration. Ces langages permettent a la fois la description ` des applications, de lenvironnement matriel et des politiques de reconguration e dynamique. Les sections suivantes nont pas vocation a prsenter en dtails le sys` e e t`me TUNe et son implantation. Pour plus dinformations, le lecteur peu se reporter e vous ` la th`se [28]. a e
5.2.1
Architecture Description Language (ADL)
Le processus dadministration avec TUNe dbute par la description de lapplicae tion ` administrer. Comme son anctre Jade, TUNe prend en compte ladministraa e tion dapplications distribues sexcutant dans un environnement rparti. LADL e e e fournit dans TUNe permet de dcrire a la fois lapplication et lenvironnement mae ` triel dans lequel lapplication sexcute. Bas sur le diagramme de classe UML [81], e e e
5.2. PRINCIPES
40
TUNe permet lutilisation des outils de modlisation graphique de lIDM 4 pour la e dnition des lments administrs. e ee e Concernant la description de lapplication, chaque type de logiciel de lapplication est reprsent par une classe UML. Lassignation dattributs a la classe permet e e ` dindiquer les proprits du type de logiciel quelle reprsente. En plus des proprits ee e ee propres au type de logiciel dcrit, TUNe impose des attributs particuliers pour son e utilisation interne (les attributs en rouge sur la gure 5.2). Dans la gure 5.2(a), nous dcrivons 4 types de logiciels constituant une application J2EE ` administrer. Late a tribut legacyFile prsent dans toutes les classes indique a TUNe larchive contenant e ` les binaires du logiciel concern. Par contre, lattribut port du type Apache par e exemple reprsente une proprit propre aux serveurs web Apache. e ee En plus de la description des logiciels, TUNe permet la description des interconnexions entre les types de logiciels. Le nommage de ces interconnexions leur permet dtre utilises dans les autres langages de TUNe pour dsigner des logiciels dun e e e bout de lapplication a un autre (exemple de la liaison workers entre Apache et ` Tomcat). Les sections suivantes prsentent en dtail cette utilisation. De faon ge e c e nrale, cette premi`re tape de description par ADL permet de poser les bases pour e e e les autres langages. De faon analogue, TUNe permet lutilisation des diagrammes de classes UML c pour la description de lenvironnement matriel dans lequel sexcute lapplication e e administre. TUNe consid`re lenvironnement matriel comme un ensemble constie e e tu de groupes de machines (clusters). Chaque cluster reprsente un ensemble de e e machines homog`nes (OS, syst`mes de chiers et toutes autres caractristiques idene e e tiques). Ainsi, dans la description de lenvironnement matriel, chaque classe repre e sente un cluster. Contrairement aux logiciels, tous les attributs dun cluster sont imposs par TUNe. En guise dexemple, lattribut nodele de la classe Cluster (e gure 5.2(b)) indique un nom de chier contenant la liste des machines constituant le cluster. Quant ` lattribut allocator-policy, il dnit la politique dallocation de a e machines (aux logiciels) dans ce cluster. Les interconnexions dcrites ici entre les e clusters sont des relations dhritage dattributs. Contrairement a lutilit quont les e ` e liaisons entre les lments logiciels, les liaisons dhritage servent uniquement ` facee e a toriser la description des attributs entre les clusters. Rappelons que tous les attributs dnis par les clusters sont imposs par TUNe. Ladministrateur ne peut introduire e e de nouveaux attributs. Description intuitive La premi`re particularit de lADL propose par TUNe est la description des e e e types de logiciels. Contrairement aux SAA (comme [26], [68], [57], [43] par exemple) dans lesquels ladministrateur doit dnir la totalit des instances logicielles, TUNe e e permet la description des types de logiciels. Un type logiciel peut tre par la suite inse tanci en plusieurs logiciels a la demande de ladministrateur (via lattribut initial , e ` qui reprsente le nombre dinstances au dmarrage, et des oprations de recongue e e ration). Cette particularit permettra par exemple de dcrire linstanciation de dix e e
4. Ingenierie Dirige par les Mod`les : exemple de Topcased [top] e e
5.2. PRINCIPES
41
Figure 5.2 Exemple dADL : cas dune application J2EE Tomcat dans une application J2EE via la description dun seul type de logiciel Tomcat et la position de son attribut initial ` dix. a Cependant, cette facilit inuence la dnition des interconnexions entre les types e e de logiciels. Il revient ` TUNe la charge de raliser les connexions entre les instances a e logicielles. En eet, TUNe les interpr`te comme un pattern rgissant les liaisons e e entre les instances de logiciels. Il utilise la smantique UML dnissant les assoe e ciations entre classes. Les liaisons entre types de logiciels sont ainsi accompagnes e de cardinalits. Ces derniers permettent a TUNe de construire et de maintenir un e ` mod`le a composants conforme au pattern architectural dcrit par ladministrateur. e ` e Dans la section 5.3, nous revenons sur linterprtation de cette description dans e TUNe. Pour nir, le rapport entre la description des types de logiciels et la description de lenvironnement matriel est le dploiement. Cette relation est indique dans la e e e description des types de logiciels via lattribut host-familly (qui dsigne un cluster) e impos par TUNe pour chaque type de logiciel (trait en pointill sur la gure 5.2). e e Ainsi, toutes les instances appartenant au mme type logiciel sont dployes et exe e e e cutes sur des machines appartenant au mme cluster. e e
5.2.2
Wrapping Description Language (WDL)
LADL fournit par TUNe ne permet quune description structurelle de lenvironnement dadministration. En ce qui concerne la description des oprations dadminise tration, TUNe propose un langage bas sur le formalisme XML nomm : Wrapping e e Description Language (WDL). Dans le reste de ce document, nous utilisons le verbe wrapper pour dcrire laction de raliser cette opration. Pour chaque type de loe e e giciel dcrit dans lADL, ladministrateur dnit (attribut wrapper de chaque type e e logiciel dans la gure 5.2(a)) dans un chier XML lensemble des fonctions pouvant tre excutes (exemple de la gure 5.3) par les instances logicielles de ce type. e e e Syst`me dadministration autonome adaptable : application au Cloud e
5.2. PRINCIPES
42
Figure 5.3 Exemple de wrapping : cas du logiciel Apache Chaque fonction correspond ` une mthode java (exemple de mthode apacheMaa e e nager de la classe java J2EEWrapping sur la gure 5.3) et est spcique au type e logiciel qui lui est associ. e Le langage de wrapping de TUNe permet une description de mthodes avec pase sage de param`tres. Compte tenu de la non connaissance des valeurs exactes des e proprits des logiciels pendant la phase de wrapping, les param`tres dnis dans le ee e e WDL peuvent tre de deux types : constante ou variable. Les param`tres de type e e constante sont ceux dont la valeur reste la mme tout au long de lexcution de e e lapplication et du SAA. Ils ont une smantique comparable a celle des constantes e ` dans les langages de programmation comme java. Cest le cas du premier param`tre e de la fonction start des instances logicielles de type Apache de la gure 5.3(a). Quant aux param`tres de type variable, TUNe ore un langage de dsignation de e e logiciels ainsi que de ses attributs. Il sagit dun langage de navigation architecturale. Autrement dit, il permet de parcourir, a laide dune notation pointe, toute larchi` e tecture suivant les liaisons entre les lments administrs. Ainsi, la valeur relle du ee e e param`tre ne sera value (par rsolution de nom) qu` lexcution de la mthode. e e e e a e e Les deuxi`me et troisi`me param`tres de la gure 5.3 (5.3(b) et 5.3(c)) sont des e e e exemples. Le premier (5.3(b)) fait rfrence a lattribut port de linstance dApache ee ` courant tandis que le second (5.3(c)) fait rfrence aux numros de port des connecee e teurs AJP [24] des serveurs Tomcat lis a linstance Apache courant (via la connexion e ` nomme workers). e Lexcution des fonctions de wrapping dpend de leur prsence ou non dans les e e e politiques de reconguration. Dans la section suivante, nous prsentons le langage e permettant de mettre en application les fonctions de wrapping : le langage de reconguration.
5.2.3
Reconguration Description Language (RDL)
Lexploitation des dnitions faites par ADL et WDL est la dnition de poe e litiques dadministration. TUNe fournit un langage proche des diagrammes dtate transition dUML : baptis Reconguration Description Language (RDL) dans TUNe. e Le terme automate est galement utilis pour dsigner ces diagrammes ou polie e e tiques dadministration. Les automates dcrits ` laide de ce langage sexcutent a e a e ` Syst`me dadministration autonome adaptable : application au Cloud e
5.3. CHOIX DIMPLANTATION
43
Figure 5.4 Principes de TUNe chaque apparition dun vnement dans lenvironnement administr. Chaque tat e e e e de lautomate dnit une action a excuter. Deux types dactions sont possibles : la e ` e modication de param`tres et lappel de fonctions dcrites lors du wrapping. En plus e e des fonctions de wrapping, TUNe met ` la disposition de ladministrateur deux fonca tions particuli`res pour lajout et le retrait dinstances logicielles de larchitecture. e Apr`s lexcution de ces fonctions, il assure la cohrence entre : (1) les patterns are e e chitecturaux dnis auparavant par ADL, (2) la reprsentation interne quil dispose e e (de lenvironnement) et (3) lenvironnement dexcution relle (sur les machines). e e En eet, lajout et le retrait dinstances modient larchitecture courante de lapplication. Comme son prdcesseur Jade, la description des programmes (cas de Jade) ou e e automates (cas de TUNe) de (re)conguration dpend des logiciels administrs et e e des vnements attendus par ladministrateur. Ainsi, le nombre de ces politiques e e dpend des besoins de lapplication administre. Par contre, deux automates partie e culiers sont requis par TUNe pour ladministration de toute application : lautomate de dmarrage et lautomate darrt des logiciels administrs. La gure 5.4 montre un e e e exemple dautomate dcrivant ` la fois la conguration et le dmarrage des serveurs e a e de lapplication J2EE. On constate par exemple que les serveurs J2EE peuvent tre e congurs parall`lement alors que le dmarrage par contre doit respecter un ordre e e e (MySQL, MySQL-Proxy, Tomcat et enn Apache). De la mme faon quavec le WDL, la navigation ` travers larchitecture (par e c a notation pointe) est utilisable dans la dnition des actions. e e
5.3
Choix dimplantation
Ladministration base composants fournit une couche dabstraction pour un ene semble dlments matriels ou logiciels. Sappuyant sur le mod`le ` composants ee e e a Fractal, TUNe construit une architecture ` composants interne reprsentant lena e Syst`me dadministration autonome adaptable : application au Cloud e
44
vironnement administr. Cette architecture est conforme a la description par ADL e ` faite de lapplication par ladministrateur. Cette structure interne se nomme Syst`me e de Reprsentation (SR) dans TUNe. Elle contient ` la fois les lments logiciels et e a ee 5 matriels. Chaque instance logicielle est encapsule dans un composant Fractal. Ce e e dernier implmente les fonctions de base de ladministration ` savoir : le dploiee a e ment, le wrapping et lexcution a distance de fonctions. Les interconnexions entre e ` les instances sont reprsentes par des liaisons (binding) bidirectionnelles entre les e e composants Fractal correspondants. Cette bidirectionnalit facilite la navigation par e notation pointe (navigation dans deux sens entre deux instances lies). Dans la e e gure 5.5 les `ches bleues en pointill (de lenvironnement ddition vers le syst`me e e e e de reprsentation) reprsentent la relation dencapsulation entre les types de logiciels e e et les composants Fractal. Notons que conformment ` la valeur de lattribut inie a tial , llment Tomcat gn`re deux composants Fractal (deux instances du logiciel ee e e Tomcat). Contrairement aux composants logiciels, les machines de chaque cluster ne sont pas reprsentes par un seul composant Fractal. TUNe reprsente le cluster par un e e e composant Fractal. Ce composant implmente les fonctions dallocation et de libe e ration de machines. Les liaisons dhritage ne sont pas maintenues dans le SR. Le e dploiement dun logiciel dans le cluster entra une liaison Fractal entre le compoe ne sant logiciel reprsentant ce logiciel et le composant Fractal reprsentant le cluster. e e Cette liaison (composant logiciel-composant cluster ; `ches rouges sur la gure 5.5) e permet de rcuprer les proprits des machines hbergeant un logiciel. e e ee e An daccomplir les tches dadministration qui lui sont cones, TUNe excute a e e sur les machines distantes deux types de serveurs. Le premier serveur (RemoteLauncher ) permet deectuer des actions gnrales non lies ` un logiciel particulier e e e a de lapplication administre. Cest notamment lui qui initialise la machine distante e avant le dploiement des logiciels. Il dmarre galement, ` la demande de TUNe, les e e e a serveurs de second type. Cest (RemoteLauncher ) le reprsentant de TUNe sur la e machine distante. Contrairement au premier (qui est unique sur la machine), TUNe associe a chaque instance logicielle un reprsentant (serveurs de second type) sur la ` e machine distante. Ce serveur de second type (RemoteWrapper ) est charg de lexe e cution des oprations dadministration lies ` linstance logicielle a laquelle il est e e a ` associ. Il entre en action suite ` linvocation dune fonction de wrapping issue de e a lexcution dun automate de reconguration. Cest a lui que revient par exemple e ` la charge dexcuter la fonction Apache.start (de lautomate de dmarrage de la e e gure 5.4) sur une instance du serveur Apache. Dautre part, ce serveur joue le rle o de communicant dvnements. Cest par son biais que les vnements reprs par e e e e ee des logiciels de monitoring sont communiqus a TUNe (matrialiss par les `ches e ` e e e vertes de la gure 5.5). Depuis sa mise en uvre, cette conception de TUNe a fait lobjet de plusieurs
5. Contrairement ` sa signication habituelle dans la littrature (implantation compl`te a e e du comportement dun logiciel), lexpression encapsuler un logiciel dans ce document signie : implanter les contrleurs permettant de manipuler un logiciel existant (considr o ee comme une bo noire). An dviter lambigu e avec le terme contrleur dj` prsent te e t o ea e dans les mod`les ` composants, nous utilisons le terme encapsuler. e a
45
Figure 5.5 Vue globale de TUNe
5.4. EXPERIMENTATIONS ET PROBLEMATIQUES
46
exprimentations dans divers domaines applicatifs. Comme nous le prsentons dans e e la section suivante, certaines de ces exprimentations ont rvl les limites de cette e e ee conception de TUNe.
5.4
Exprimentations et Problmatiques e e
Les exprimentations ralises avec le syst`me TUNe (par nos partenaires et e e e e nous) durant ces derni`res annes couvrent plusieurs domaines applicatifs. Sans tre e e e exhaustif dans la liste de ces expriences, nous dcrivons dans cette section quelques e e unes dentre elles qui ont motiv la nouvelle orientation du projet TUNe. Il sagit de e lutilisation de TUNe pour ladministration des applications clusters de type ma treesclave(exemple de J2EE), des applications large chelle et des applications virtualie ses. Ces prsentations mettent en exergue dune part lecacit du syst`me TUNe e e e e et dautre part ses limites. En plus de ces exprimentations, nous achevons cette e section par la prsentation des limites lies a la tentative dutilisation de TUNe e e ` pour ladministration du cloud dans son ensemble. La complexit de ce dernier nous e permet de complter lanalyse faite des limitations de TUNe. e
5.4.1
Applications cluster
Le syst`me TUNe a t conu pour ladministration des applications rparties. e ee c e Pour des besoins de dveloppement, il utilise des applications de type J2EE (e gure 5.1) comme support de test. De ce fait, ses langages dadministration rpondent e parfaitement avec les besoins dadministration attendus par ce type dapplications. Parcourons a prsent ces besoins an de montrer lecacit de TUNe. ` e e Concernant linstallation des serveurs J2EE sur les machines distantes, TUNe propose une mthode de dploiement consistant ` copier des binaires de la machine e e a dadministration vers les machines distantes. Ces binaires doivent tre soumis a e ` TUNe sous forme darchives. Lattribut legacyFile, impos par TUNe pour chaque e type de logiciel, permet a ladministrateur dindiquer larchive dinstallation du lo` giciel. Les binaires sont par la suite dsarchivs par TUNe (par lintermdiaire de e e e son RemoteLauncher ) sur les machines distantes. Cette mthode de dploiement e e rpond parfaitement a linstallation des serveurs J2EE qui sont livrs par leur dvee ` e e loppeur sous forme darchives. Apr`s linstallation, les oprations de conguration et de dmarrage des serveurs e e e J2EE sont galement exprimables grce au WDL et RDL de TUNe. En eet, la cone a guration de ces serveurs consiste essentiellement en la modication des chiers de type cl-valeur. La dnition dune fonction permettant de raliser ces modications e e e est facilement ralisable par WDL. Comme nous lavons indiqu dans la section 5.2.2, e e le WDL permet de dnir des fonctions dadministration via des mthodes de classes e e java. Ces derni`res peuvent donc implantes la modication des chiers. Quant au e e dmarrage des serveurs, il seectue par excution de commandes shell. De la mme e e e Syst`me dadministration autonome adaptable : application au Cloud e
47
faon quil proc`de pour la conguration, ladministrateur naura qu` implanter les c e a oprations de dmarrage via des mthodes de classes java. La seule dnition des e e e e fonctions de dmarrage nest pas susante. En eet, contrairement aux oprations e e de conguration qui peuvent sexcuter en parall`le (sur les serveurs), le dmarrage e e e des serveurs J2EE requiert un ordre. En guise dexemple, le serveur dapplication Tomcat doit tre dmarr avant le serveur web Apache qui lui est connect. Le RDL e e e e de TUNe, bas sur les diagrammes dtat-transition dUML, permet dexprimer ces e e contraintes. Ses tats particuliers, que sont le fork et le join, permettent respece tivement de parallliser des oprations et dattendre lexcution dun ux parall`le e e e e doprations. Une fois le dmarrage eectu, lun des besoins les plus importants e e e dans ladministration dune application de ce type est la gestion des variations de charge au niveau des dirents tiers. e Ladministrateur souhaite ajouter des serveurs a un tiers an dabsorber la sur` charge lorsque celui-ci est surcharg. Inversement, il souhaite galement rduire le e e e nombre de serveurs dun tiers lorsquil est sous utilis. Cette derni`re opration lui e e e permet de raliser des conomies dutilisation de machines (tr`s bnque lorsque e e e e e celles-ci sont payantes). Lensemble de ces deux oprations est appel sizing ou pase e sage ` lchelle ou scalabilit de serveurs. Pour raliser cela dans TUNe, ladministraa e e e teur associe aux serveurs J2EE des logiciels particuliers jouant le rle de sondes. Ces o derni`res dclencheront (en cas de sous/sur charge dun tiers) dans TUNe des autoe e mates de reconguration permettant dajouter ou retirer des serveurs. Les deux ope rateurs dajout (suivis dun dploiement) et de retrait (suivis dun un-dploiement) e e dinstances logicielles proposes par TUNe permettent de raliser ce besoin. e e La gnralisation de ces besoins permettent ` TUNe dadresser dautres applie e a cations cluster de type ma tre-esclave comme Ganglia [73]. Cependant, lorsque la taille de lapplication devient importante, nous observons des limites dutilisation de TUNe. Cest le cas avec les applications large chelle comme le serveur de calculs e DIET [33] dans lenvironnement de grille grid5000 [25].
5.4.2
Applications large chelle : cas de DIET e
Lapplication DIET [33] permet de dployer des serveurs (nomms agents dans e e DIET) de calculs dans un environnement de grille. Ces serveurs sont organiss sous e forme arborescente et sont de trois types. Les serveurs de premier type se trouvent a la racine de larbre : ils sont nomms Master Agent (MA). Ces derniers reoivent ` e c les demandes de calculs venant des clients et les orientent vers les serveurs de calculs (serveur de troisi`me type) les mieux adapts. Ces derniers sont dtermins par e e e e les serveurs MA en fonction des informations de monitoring quils obtiennent des serveurs de second type : nomms Local Agent (LA). Enn, les serveurs de troisi`me e e type sont situs aux feuilles de larbre. Ils sont les vritables serveurs de calculs : e e nomms Server Daemon (SeD). Ils reoivent des requtes des clients et restituent e c e les rsultats une fois le calcul eectu. Notons quun MA pourrait directement tre e e e reli aux SeD si ceux-ci ne sont pas de grand nombre. Lintroduction des LA permet e dviter la saturation des MA lorsque lapplication DIET utilise un grand nombre de e
48
serveurs de calculs. Plusieurs niveaux de LA sont introduits entre le MA et les SeD en fonction de la taille de lapplication. La gure 5.6 rsume larchitecture de cette e application. Elle peut tre constitue de milliers de serveurs lorsque lenvironnement e e matriel le permet (cas de grid5000). Lutilisation de TUNe pour ladministration e (dploiement, conguration et dmarrage) de cette application dans un contexte e e large chelle a montr des limites. e e Probl`me 1.1 e La premi`re limite concerne la description par ADL de lapplication DIET. Cette e description devient fastidieuse (rptition dans la description) lorsque lapplication e e contient des centaines de serveurs (cas sur grid5000). Dans sa version initiale, le syst`me TUNe ne permettait pas la description par intension, c-`-d la description e a dun dploiement multiple dinstances de mme type via lattribut initial . En eet, e e lattribut initial (section 5.2.1) qui indique a TUNe le nombre dinstances ` d` a e ployer initialement pour un type de logiciel a t introduit pour prendre en compte ee le dploiement des serveurs DIET sur grid5000. Comme nous lavons dcrit dans la e e section 5.2.1, cet attribut simplie la description de larchitecture dune application contenant plusieurs instances du mme logiciel. Notons que cette modication du e langage ADL de TUNe na ncessit aucune modication du cur de TUNe. e e Probl`me 1.2 e La deuxi`me limite concerne le dploiement des serveurs de calculs SeD. La pere e formance de ces derniers tant lie aux caractristiques matrielles des machines sur e e e e lesquelles ils sexcutent, ladministrateur dispose de direntes versions dinstallae e tion pour chaque cluster de la grille. Or le processus de dploiement fourni par TUNe e ne prvoit quune seule archive (qui correspond ` une version) pour chaque type de e a logiciel. De plus, le choix de la version ntant possible que pendant le dploiement e e (c-`-d une fois le cluster connu), ladministrateur souhaite associer ` chaque cluster a a une version prcise de SeD. e Probl`me 1.3 e La derni`re dicult (que nous dcrivons dans ce document) concernant lade e e ministration de cette application est lie au caract`re centralis de TUNe. En eet, e e e ladministration dune application constitue de milliers de logiciels par une unique e instance de TUNe devient impossible a cause des limites de la machine qui lhberge. ` e Par exemple, louverture dune connexion rseau entre la machine dadministration e et tous les serveurs administrs est limite par les capacits mmoire de la machine e e e e dadministration.
5.4.3
Applications virtualises e
Notre derni`re tentative dadministration avec TUNe concerne lutilisation des e machines virtuelles (section 2.2) pour une gestion optimale des ressources dans un cluster J2EE [90]. En bref, il sagit dutiliser une instance de TUNe pour ladmi-
49
Figure 5.6 Architecture de DIET nistration a la fois des serveurs J2EE et des VM sur lesquelles ils sexcuteront. ` e Ainsi, grce aux atouts des VM, nous implantons plusieurs politiques de gestions a de ressources. Malgr lobtention de rsultats prometteurs concernant la gestion de e e ressources, le syst`me TUNe sest montr inadapt pour ladministration des VM. e e e Probl`me 2.1 e Premi`rement, lexpression de la double identit des VM (` la fois machine et e e a logiciel, section 2.2) est irralisable dans TUNe. En eet, les langages et le cur de e TUNe direncient les machines et les logiciels. Il impose dune part une descripe tion sous forme de cluster pour les machines et les reprsente en son sein a laide e ` dun seul composant. Ceci empche la manipulation individuelle des VM qui est un e besoin important dans cette exprimentation. Dautre part, les logiciels sont dcrits e e et reprsents de faon individuelle dans le SR. Quelle reprsentation utilisera donc e e c e ladministrateur pour dcrire les VM qui jouent les deux rles ? e o Probl`me 2.2 e Apr`s les probl`mes de description par ADL et de reprsentation, linstallation e e e dune VM ne se limite pas (comme dans TUNe) ` la copie de binaires sur la machine a distante. En eet, installer une VM revient ` installer un syst`me dexploitation. a e Ce qui implique une succession doprations de natures direntes parmi lesquelles : e e linitialisation du syst`me de chiers, linstallation des pacquages, etc. Prendre en e compte cette particularit dinstallation revient ` personnaliser la mthode de de a e e ploiement propose par TUNe. e Probl`me 2.3 e Pour nir, la prise en compte de lopration de migration de VM (voir la sece tion 2.2), essentielle dans notre exprimentation [90] est impossible dans TUNe. Il e
50
sagit du dplacement de lexcution dune VM dune machine physique vers une e e autre. Elle ncessite entre autre lexcution atomique du couple doprations [unde e e e ploiement de la VM ; dploiement de la VM sur la machine de destination]. Autree ment dit, elle ncessite une opration du genre move. Ce que ne permettent ni les e e langages, ni limplantation de TUNe.
5.4.4
Cloud
Les exprimentations ralises avec TUNe dans les domaines prcdents nous ont e e e e e conduit vers un domaine beaucoup plus complet et complexe quest le cloud. Comme nous lavons prsent dans la section 3, le cloud dans son ensemble (IaaS et applie e cations entreprise) reprsente un cas dadministration dans lequel lutilisation dun e SAA appara vidente. Ainsi, nous prsentons dans cette section une tentative dutit e e lisation du syst`me TUNe pour ladministration du cloud dans son ensemble. Sans e reprendre la prsentation de ladministration dans le cloud ralise dans la section 3, e e e nous nous appuyons sur cette derni`re pour eectuer notre tude. Plus prcisment, e e e e cette tude prsente les limitations du syst`me TUNe pour ladministration dans le e e e cloud.
Probl`me 3.1 e Administrer le cloud dans son ensemble avec TUNe revient ` excuter plusieurs a e instances de TUNe par niveau dutilisation : une instance pour ladministration de lIaaS et plusieurs instances (` raison dune instance par entreprise) pour ladmia nistration des applications entreprise. Reposant sur la collaboration entre les deux niveaux, ladministration du cloud implique galement la collaboration/interope e rabilit entre les instances de TUNe de niveau entreprise et linstance de TUNe de e niveau IaaS. Probl`me 3.2 e Comme les environnements de grille, lIaaS peut tre constitu dun grand nombre e e de ressources. Ces derni`res peuvent tre rparties dans plusieurs localits (cas e e e e dAmazon EC2 avec X localits). Dans ce contexte, lutilisation de TUNe est proe blmatique et rejoint la situation dcrite dans le Probl`me 1.3 de la section 5.4.2. e e e Probl`me 3.3 e Linstance TUNe de niveau IaaS administre des lments de diverses natures : ee des serveurs assurant les services de base de lIaaS (facturation, stockage de donnes, rseaux, etc.), des VM qui servent de support dexcution pour les applications e e e entreprise, et des quipements matriels. Dans le processus dadministration, le de e e ploiement des serveurs et celui des VM nest pas ralisable de la mme mani`re. On e e e retrouve le mme probl`me que nous avons voqu dans la section 5.4.2 (Probl`me e e e e e 1.2).
51
Probl`me 3.4 e Comme toute plateforme informatique, les oprations de maintenance font partie e du cycle de vie du cloud. Ces oprations peuvent entra e ner la mise en indisponibilit e partielle ou totale dun ensemble de machines. La prise en compte de cette activit e par TUNe se traduit par le retrait des machines concernes du SR. Cependant, e cette opration nest pas possible dans TUNe. Si le retrait concerne un cluster tout e entier, uniquement la modication des langages de TUNe permettra de prendre en compte cette opration. Dans le cas o` le retrait concerne des ressources individuelles, e u la modication des langages et du coeur de TUNe sont ncessaires. Ceci sexplique e par le fait que le syst`me TUNe ne reprsente pas de faon individuelle les ressources e e c matrielles dans le SR. Il est donc impossible de les manipuler individuellement. De e faon analogue, lextension du cloud par ajout de nouvelles machines ne peut c tre pris en compte par TUNe. Ces deux situations sobservent galement au niveau e e entreprise. Pour illustrer cela, prenons lexcution dans le cloud dune application de e type ma tre-esclave par une entreprise. La scalabilit telle que nous lavons prsente e e e dans la section 5.4.1) entra nera des ajout/retrait de VM (vues comme des ressources matrielles par les entreprises). e Probl`me 3.5 e Comme nous lavons prsent dans la section 3, la plupart des oprations dade e e ministration dans le cloud sont dclenches par celles du niveau entreprise. Cest e e ainsi que lajout/retrait de VM au niveau de lIaaS survient apr`s lextension/rduce e tion des ressources au niveau entreprise (les oprations dcrites dans le paragraphe e e prcdent). Cette opration nest pas possible dans le syst`me TUNe. En eet, il e e e e le permet uniquement pour des logiciels dont la description est connue avant son (TUNe) dmarrage. De plus, les entreprises ou le fournisseur de lIaaS peuvent soue haiter intgrer de nouveaux types de logiciels dans lenvironnement apr`s le dmare e e rage de TUNe (ce quil ne permet pas). En guise dexemple, prenons une entreprise excutant dans le cloud une application J2EE constitue des serveurs Apache, Tome e cat, MySQL-Proxy et MySQL. Initialement, lapplication est constitue dune seule e instance dApache et aucun distributeur de charges devant Apache nexiste. Apr`s e saturation du serveur Apache, lentreprise peut souhaiter de joindre un distributeur de charges (HA-Proxy) tout en gardant lexcution de lensemble de lapplication et e du SAA. Probl`me 3.6 e Le changement ou la dnition dune stratgie commerciale (dnition dun noue e e veau type de contrat, dune nouvelle mthode de tolrance aux pannes des VM, etc.) e e par le fournisseur du cloud se traduit par lajout ou le retrait de politiques de reconguration dans linstance TUNe de niveau IaaS. Cette situation est similaire aux deux prcdentes. Elle peut galement concerner le niveau entreprise. De e e e la mme faon que ladministrateur de lIaaS ajoute/retire des logiciels/matriels, il e c e peut eectuer la mme opration pour les politiques de reconguration. e e Probl`me 3.7 e Dans la section 5.4.3, nous avons prsent une politique de gestion de ressources e e
` 5.5. SYNTHESE ET NOUVELLE ORIENTATION
52
base sur la migration des VM. Reposant galement sur la virtualisation, le cloud e e peut mettre en place ces politiques au niveau de linstance TUNe de lIaaS. Comme nous lavons fait remarqu, cette opration nest pas ralisable dans TUNe : ni au e e e niveau langage, ni au niveau interne.
5.5
Synth`se et nouvelle orientation e
Les exprimentations ralises avec TUNe font ressortir deux types de limites : e e e Les limites dues uniquement ` linsusance de ses langages dadministration ; a Les limites dues a linadaptation de son architecture et de sa conception. ` Lanalyse [40] de leurs causes souligne la variation des besoins dadministration en fonction des domaines dapplications. Nous montrons a travers ces expriences que ` e limplantation actuelle de TUNe ne le prdispose pas ` sadapter ` ces variations. e a a Ces derni`res ncessitent un syst`me tr`s exible et tr`s gnrique (voir le chapitre e e e e e e e suivant). Or la conception et limplantation de TUNe sont ralises autour de ses e e langages dadministration (on parle galement de machine langages pour dsigner ce e e type de syst`me). En outre, la conception de ces langages a t dirige par ladmie ee e nistration des applications cluster de type ma tre-esclave. Ainsi, cette dpendance e entre le cur de TUNe et ses langages le rend moins exible et moins adaptable pour adresser dautres domaines applicatifs. Face a ce constat, nous proposons la construction dun SAA ne reposant sur au` cun langage ou domaine dadministration. Lobjectif de ce SAA sera la fourniture dun ensemble dAPI permettant de le rendre le plus exible et gnrique possible. e e Il sera sans doute complexe et donc dicile a utiliser. Pour surpasser cette dicult ` e dutilisation, nous fournissons au dessus de ce SAA une pile de logiciels (couche (2) sur la gure 5.7) facilitant son utilisation. Cette pile contient des logiciels permettant aux administrateurs de dnir deux mme les langages dadministration correspone e dant a leurs besoins applicatifs. Il sagit doutils dIDM (Ingenierie Dirige par les ` e Mod`les) pour la ralisation de langages spciques (Domain Specic Language ou e e e DSL dans le jargon IDM) a ladministration autonome (ce qui rsout les probl`mes ` e e dinadaptation des langages). Ces langages masqueront la complexit du SAA. e Dans cette orientation, le but de cette th`se est de fournir sur la base de TUNe e et de Jade, un SAA exible et gnrique pouvant supporter plusieurs domaines e e dapplications (couche (1) sur la gure 5.7). Quant a la couche suprieure (couche ` e (2) sur la gure 5.7), elle fait lobjet dautres travaux de th`se. La dmonstration de e e lecacit du SAA que nous proposons sera son application ` ladministration dun e a environnement complexe comme le cloud. Avant la prsentation de ce SAA, nous e dcrivons dans le chapitre suivant les crit`res et lapproche quun tel syst`me doit e e e respecter.
` 5.5. SYNTHESE ET NOUVELLE ORIENTATION
53
Figure 5.7 Nouvelle orientation du projet TUNe
Chapitre 6 Orientation gnrale e e

Contents
6.1 Caractristiques . . . . . . . . . . . . . . . . . e 6.1.1 Uniforme . . . . . . . . . . . . . . . . . . . . 6.1.2 Adaptable . . . . . . . . . . . . . . . . . . . . 6.1.2.1 Adaptation des comportements . . . 6.1.2.2 Extensibilit . . . . . . . . . . . . . e 6.1.3 Interoprable et Collaboratif . . . . . . . . . e 6.1.4 Synth`se . . . . . . . . . . . . . . . . . . . . . e 6.2 Approche gnrale et Mod`le Architectural e e e 6.2.1 Approche Gnrale . . . . . . . . . . . . . . . e e 6.2.2 Mod`le Architectural . . . . . . . . . . . . . . e 6.2.3 Prise en compte des caractristiques . . . . . e 6.3 Synth`se . . . . . . . . . . . . . . . . . . . . . . e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 . 56 . 57 . 57 . 58 . 59 . 60 . 60 . 60 . 61 . 64 . 64
Les expriences ralises avec le syst`me TUNe ont permis de valider dune part e e e e les principes de ladministration autonome et dautre part lapproche dadministration ` base de composants. En particulier, ces expriences ont montr son adquation a e e e pour ladministration des applications cluster de type ma tre-esclave (application J2EE par exemple). Cependant, contrairement ` son aspiration initiale (administraa tion gnrique), il est dicile de lutiliser dans plusieurs domaines applicatifs (voir la e e n du chapitre prcdent pour les raisons). Ainsi, la principale recommandation que e e nous avons tir de ces exprimentations est : La conception dun SAA ` voe e a cation gnrique et exible doit suivre une architecture ` deux niveaux e e a (gure 5.7 du chapitre prcdent). Le premier niveau (1) est un supe e port pour ladministration ` lexcution (cest la machine dexcution a e e ou encore le SAA gnrique). Le second niveau (2) fournit un support e e langage pour lexpression des politiques dadministration.. La conception et le dveloppement du premier niveau fait lobjet de cette th`se. Il sagit en quelque e e sorte du dveloppement dun exo-SAA que nous baptisons TUNeEngine. e Lobjectif de ce chapitre est double. Dans un premier temps, nous identions les
6.1. CARACTERISTIQUES
55
caractristiques idales quun tel SAA doit remplir an dtre en mesure de rpondre e e e e a divers besoins dadministration. Dans la prsentation de ces caractristiques, nous ` e e montrons a chaque fois dans quelles mesures elles rpondent aux probl`mes identi` e e s dans le syst`me TUNe. Dans un second temps, nous proposons une approche de e e conception ainsi quun mod`le architectural de ce SAA. e
6.1
Caractristiques e
Fort de nos direntes exprimentations dans le domaine de ladministration e e autonome, nous proposons les caractristiques (considres comme crit`res ou direce ee e tives) suivantes pour la construction dun SAA hautement gnrique : e e Uniforme : Nous dnissons un SAA uniforme comme un SAA dans lequel les e dirences de rles entre lments administrs ne sont pas cbles. Autrement e o ee e a e dit, il sagit dun SAA dans lequel les lments administrs utilisent la mme ee e e reprsentation interne quelque soit leur nature. Ce crit`re se traduit dans le e e syst`me TUNe par la non direnciation entre la description et la reprsentae e e tion (dans le SR) des machines et des logiciels (probl`me 2.1 de la section 5.4.3 e du chapitre prcdent). e e Adaptable : Nous dnissons un SAA adaptable comme un SAA capable e dvoluer en fonction des besoins dadministration. Ladaptabilit du SAA ree e vt dirents aspects. (1) Ladaptation de limplantation du SAA : cest la moe e dication des portements de base du SAA par modication/remplacement/ajout de services sans connaissance enti`re de son implantation. (2) La capacit e e du SAA ` faire voluer dynamiquement les lments quil administre. En eet, a e ee un SAA peut se borner ` administrer un ensemble dlments xes ou faire a ee voluer ces lments par ajout de logiciels, de machines voir de programmes e ee de reconguration. De nos caractristiques, ladaptabilit est la plus importante du SAA que nous e e envisageons. Cette caractristique permettra par exemple dadapter le dploiee e ment du syst`me TUNe pour ladministration des syst`mes virtualiss (proe e e bl`me 2.2 de la section 5.4.3 du chapitre prcdent). e e e Interoprable ou Collaboratif : Comme nous lavons montre dans le cadre e e des applications large chelle (probl`me 1.2 de la section 5.4.2 du chapitre e e prcdent) par exemple, ladministration dune infrastructure peut ncessiter e e e le concours de plusieurs SAA. Ce dernier est dit interoprable/collaboratif e lorsquil est capable dchanger des informations ou des ordres dadministration e avec dautres SAA distincts. Apr`s ces br`ves dnitions des caractristiques du SAA que nous envisageons, e e e e le reste de ce chapitre est consacr dans sa deuxi`me partie ` leur prsentation e e a e dtaille. Pour illustrer ces prsentations, nous nous appuyons sur les expriences e e e e ralises avec le syst`me TUNe (chapitre prcdent) et plus particuli`rement sur le e e e e e e cas de ladministration dans le domaine du cloud.
56
6.1.1
Uniforme
Lexcution dun logiciel est une relation entre deux entits : le support dexcue e e tion (SE) et le logiciel. Le support dexcution (SE) hberge et excute le logiciel. e e e Il implmente tous les mcanismes ncessaires pour lexcution du logiciel. Il est e e e e comparable a une machine munie de son syst`me dexploitation. Dailleurs, dans un ` e environnement dadministration, les lments matriels jouent toujours le rle de SE. ee e o Par contre, les logiciels peuvent galement se comporter comme des SE. Considrons e e lexemple des machines virtuelles que nous avons prsentes dans la section 2.2. Dans e e la relation [machines physique ; VM], la VM est considre comme logiciel a lgard ee ` e de la machine physique qui lhberge. Par contre, dans la relation [VM ; logiciel], la e VM joue le rle de SE vis a vis du logiciel quelle hberge. o ` e Un autre exemple qui illustre ce double rle que peut jouer un logiciel concerne o les serveurs dapplications (dans les applications J2EE) comme JBoss [jbo] ou Tomcat [53]. Pour les mmes raisons que les VM, ces serveurs sont par dnition des e e logiciels. Cependant, leurs fonctionnalits dans une application J2EE est lexcution e e des servlets : ils sont notamment appels conteneurs de servlets. Ils implantent tous e les mcanismes permettant lexcution et lacc`s aux servlets. Ces mcanismes sont e e e e comparables ` ceux que lon retrouve dans les syst`mes dexploitation ` savoir : la a e a gestion des acc`s (scurit), la gestion de la mmoire, le scheduling, la gestion des e e e e entres/sorties, etc. Pour ces raisons, ils peuvent tre considrs comme SE vis ` vis e e ee a des servlets. Pour nir, nous retrouvons le probl`me duniformit dans certains SAA comme e e Accord [70] (conf`re chapitre 7 sur ltat de lart). En eet, Accord ge (par ime e plantation) la dirence entre les logiciels jouant le rle de sondes et les logiciels e o fournissant les services fonctionnels de lapplication administre. En consquence, il e e est dicile dintgrer dans Accord des sondes comme boites noires et de les dnir e e comme lments administrables. ee En sommes, il rsulte des deux premiers exemples que dans ladministration dune e application, les lments administrs peuvent tre soit des SE, soit des logiciels, soit ee e e les deux a la fois. Il sagit de la situation que nous avons identie par le probl`mes ` e e 2.1 de la section 5.4.3 du chapitre prcdent. Quant au troisi`me exemple, il pose e e e le probl`me de la direnciation des rles des lments administrs dans le SAA. e e o ee e De faon gnrale, la recommandation que nous proposons est la suivante : le SAA c e e ne doit pas ger dans sa conception les dirences de rles des lments e o ee quil administre. Cette recommandation se traduit dans le SAA par lutilisation dune reprsentation uniforme pour tous les lments administrs quil g`re. Ainsi, e ee e e les logiciels, sondes, SE, etc. doivent utiliser la mme reprsentation dans le SAA. e e
57
6.1.2
6.1.2.1
Adaptable
Adaptation des comportements
Comme tout logiciel informatique, le projet de dveloppement dun SAA met en e relation deux acteurs : (1) les utilisateurs (qui sont les administrateurs dans notre contexte) et (2) lquipe de dveloppement. Dans la plupart des cas, ces deux ace e teurs sont spars et ne poss`dent pas les mmes comptences. Le premier poss`de e e e e e e des comptences sur lapplication a administrer tandis que le second ma e ` trise les techniques de dveloppement des SAA. Sur cette base, nous dnissons ladaptae e bilit des comportements dun SAA comme sa capacit a tre modiable par les e e ` e utilisateurs de type (1) sans lintervention des utilisateurs de type (2), dans le but dadresser plusieurs domaines applicatifs. Autrement dit, ladaptabilit des compore tement du SAA permettra au SAA dtre gnrique. Ladaptabilit est une solution e e e e parmi plusieurs qui permettent de construire un SAA gnrique. La question qui e e peut tre pose est celle de savoir pourquoi notre choix sest-il port sur ladaptae e e bilit du SAA comme rponse a la gnricit? e e ` e e e Une solution de gnricit consiste ` fournir des API de bas niveaux utilisables e e e a par les administrateurs pour limplantation de la prise en compte de nouveaux besoins. Cette solution est fournie par le syst`me Jade [26] qui propose les API Fractal. e Cette solution sadresse aux administrateurs avertis, ce qui limite son utilisation lare gie. La rponse aux limites de la solution prcdente est la fourniture des outils de e e e niveaux dabstraction proches des administrateurs. Cette solution limite la gnrie e cit du SAA et entra la construction de SAA par domaine applicatif spcique. e ne e Cest le cas du syst`me TUNe qui se limite aux applications clusters de type ma e treesclave. La derni`re solution allie la fourniture dun niveau dabstraction lev a la ge e e` e nricit du SAA. Elle repose dune part sur ladaptabilit du SAA (la modication, e e e lajout et le remplacement des services du SAA sans avoir une expertise compl`te sur e son dveloppement) et la fourniture des outils dexpressions de besoins dadministrae tion (voir la section 5.5 du chapitre 5). Comme nous le verrons dans la section 6.2, cette derni`re solution implique une architecture a composants du SAA. Elle est e ` celle pour laquelle nous optons et dont nous justions son utilit dans le SAA en e montrant comment elle permettrait au syst`me TUNe de rsoudre une partie de ses e e probl`mes. e Durant nos exprimentations avec le syst`me TUNe (sections 5.4), nous nous e e sommes heurts a plusieurs probl`mes ncessitant son adaptation. Il sagit des proe ` e e bl`mes : 1.2, 2.2, 2.3, 3.3, 3.4, 3.5, 3.6 et 3.7. A prsent, montrons dans quelles e e mesures ladaptabilit de TUNe lui aurait permis de rsoudre ces probl`mes. Ces e e e derniers requi`rent deux types dadaptation : modication/remplacement de come portements (probl`mes 1.2, 2.2, 3.3) et ajout de nouveaux comportements (probl`mes e e 2.3, 3.4, 3.5, 3.6 et 3.7). Que ce soit le dploiement des serveurs SeD dans le cadre de lapplication DIET e Syst`me dadministration autonome adaptable : application au Cloud e
58
(probl`me 1.2) ou le dploiement des VM dans les syst`mes virtualiss et cloud (proe e e e bl`mes 2.2 et 3.3), le remplacement de la fonction de dploiement de base de TUNe e e permet de prendre en compte les particularits de ces applications. Par exemple, e le SAA peut tre fourni avec une fonction basique de dploiement et permettre a e e ` chaque administrateur de fournir la mthode (par surcharge ou rednition de me e e thodes) qui lui est propre en cas de besoin. Ainsi, concernant ladministration des VM, ladministrateur pourra fournir au SAA une mthode de dploiement incluant e e les tlchargements de binaires via internet, des copies via des serveurs NFS, etc. ee Une autre situation ncessitant une adaptation par modication comportemene tale sobserve dans TUNe. Elle concerne le moyen dexcution de fonction dadmie nistration a distance. Par exemple, le syst`me TUNe utilise un protocole g (RMI) ` e e ainsi que des moyens dintrospection et rexion Java pour lexcution de mthodes e e e a distance. Ainsi, lutilisation de TUNe ncessite la prsence dune machine virtuelle ` e e Java sur toutes les machines excutant les lments administrs. Lutilisation dun e ee e protocole comme ssh en remplacement RMI dans un environnement non Java est impossible.
6.1.2.2
Extensibilit e
Ne pouvant prdire toutes les oprations ralisables dans toute administration, e e e ladaptabilit du SAA doit le prdisposer a intgrer de nouveaux modules permettant e e ` e par exemple de prendre en compte de nouveaux oprateurs (probl`mes 2.3 et 3.7) e e ou de nouveaux besoins comme lextension de lenvironnement (probl`mes 3.4, 3.5 e et 3.6). La prise en compte de lopration de migration dans les environnements e virtualiss se traduit par lintgration dun nouvel oprateur move, tel que nous e e e lavons prsent dans les sections 5.4.3 et 5.4.4. Ce qui permettra de raliser des e e e politiques de rconguration bases sur la migration dans ladministration de lIaaS. e e Quant aux probl`mes 3.4, 3.5 et 3.6, ils font ressortir trois types dextensions de e ladministration ncessitant ladaptation du SAA : e lextension de lenvironnement matriel (probl`me 3.4) : Ce probl`me est noe e e tamment rencontr dans les SAA tels que Jade [26], TUNe [29], ADAGE [68], e SmartFrog [57], ORYA[43] ou Kadeploy [kad]. En eet, ils exigent que la liste des supports dexcution (machines) soit dnie avant leur dmarrage. De ce e e e fait, les SE restent gs pendant lexcution enti`re du SAA. Un module pere e e mettant leur extension dynamique permettrait de faire voluer cet environnee ment. lextension de lenvironnement logiciel (probl`me 3.5) : En ce qui concerne e lextension de lenvironnement logiciel, nous distinguons deux types dextensions. La premi`re est celle quore le syst`me TUNe, c-`-d lajout/retrait e e a dinstances de logiciels dont la description tait connue de TUNe au dmare e rage. Elle permet par exemple de raliser la scalabilit des applications J2EE. e e La deuxi`me est lajout de nouveaux logiciels non existant initialement dans e TUNe. La modication du comportement de TUNe aurait permis de prendre en compte ce type dextension. Ce probl`me se pose une fois de plus dans e les applications J2EE. Prenons par exemple une application J2EE ne dispoSyst`me dadministration autonome adaptable : application au Cloud e
59
sant pas initialement de distributeur de charges devant le serveur web Apache (Ha-Proxy [hap] par exemple). Apr`s constatation de lincapacit dun unique e e serveur web a rpondre ` toutes les requtes, ladministrateur peut dcider ` e a e e dintroduire en cours de route dautres instances an de partager les charges. Pour cela, il doit ajouter dans larchitecture initiale un nouveau logiciel (Haproxy), inexistant initialement, pour la distribution de charges aux direntes e instances dApache. lextension des politiques de reconguration (probl`me 3.4) : Comme nous e lavons prsent dans la section 5.4.4, il sagit de la facult du SAA ` intgrer e e e a e de nouvelles politiques dadministration pendant son excution. e
6.1.3
Interoprable et Collaboratif e
Linteroprabilit dun syst`me informatique est sa facult ` dialoguer avec dautres. e e e ea Dans certaines conditions, nous utilisons le terme collaboration pour dsigner line teroprabilit. En eet, nous dnissons la collaboration comme la mise en commue e e nication de plusieurs SAA de mme type (probl`me 3.2) tandis que linteroprabilit e e e e (plus gnraliste) met en commun plusieurs SAA de types et de conceptions die e e rents (probl`me 3.1). e La collaboration dans TUNe, telle que propose par [91] pour ladministration e des applications large chelle (section 5.4.2 du chapitre 5) adresse un probl`me pare e ticulier : le passage a lchelle de TUNe. Elle ne saurait sappliquer au cloud. En ` e eet, [91] propose une collaboration entre plusieurs instances de TUNe partageant la mme application et dcrite par un unique administrateur. Les instances collae e borent entre elles pour accomplir ladministration de lapplication qui est de tr`s e grande taille ici (des milliers dlments). De plus, au regard de son implantation ee (hirarchisation de TUNe), cette solution est propre aux applications large chelle e e de type DIET dont larchitecture est hirarchise. Les mcanismes de communicae e e tion entre les instances de TUNe mises en collaboration sont cbls pour rpondre a e e a ce type dapplication. Qu` cela ne tienne, cette solution de [91] reprsente une ` a e tape pralable de la collaboration des SAA. Dans le cas du cloud par exemple, son e e fonctionnement nest eectif que grce ` la collaboration entre les SAA de niveau ena a treprise et IaaS. Ces SAA sont de natures compl`tement direntes. Tout le principe e e de fonctionnement du cloud repose sur la collaboration entre les deux niveaux. Quelque soit le type dinteroprabilit dans ladministration autonome, les ine e formations changes sont gnralement de dirents types. Nous retrouvons par e e e e e exemple des informations de monitoring (entre le SAA de niveau IaaS et le SAA de niveau entreprise dans le cloud), des mta-informations dcrivant un syst`me de e e e reprsentation rpliqu entre plusieurs instances de SAA ou encore des ordres de e e e reconguration (cas du cloud). Illustrons ce dernier exemple en reprenant ladministration a deux niveaux du cloud que nous dcrivions dans le chapitre 3. Dans cet ` e exemple, plusieurs formes de collaboration sont identiables :
` 6.2. APPROCHE GENERALE ET MODELE ARCHITECTURAL
60
La collaboration du niveau entreprise vers lIaaS est vidente. Cest elle qui pere met ` lentreprise daccder au cloud par rservation de ressources par exemple. a e e Elle permet galement a lentreprise de se renseigner sur ltat des ressources e ` e (VM) qui lui sont alloues. e La collaboration IaaS vers lentreprise, elle survient pour la rsolution de e pannes par exemple. En eet, soit une entreprise ayant une rservation dune e unique VM. A cause de lincapacit de lentreprise a dtecter une panne mae ` e chine de la VM, elle est oblige de compter sur lappel du SAA de niveau IaaS e pour cette dtection. Ainsi, apr`s dtection de pannes et ralisation doprae e e e e tions de rparation prliminaires (redmarrage des VM par exemple), ce SAA e e e informe celui du niveau entreprise propritaire de la VM. e La collaboration entre plusieurs IaaS : elle survient lorsquune plateforme de cloud disposant de moins de ressources et contacte dautres plateformes pour lextension de ses capacits. Lensemble constitu par ces IaaS est appel cloud e e e hybride. Cest le cas de la plateforme OpenNebula [OpenNebula] qui est capable dassocier une plateforme ElasticHost [ElasticHosts] pour tendre ses e ressources.
6.1.4
Synth`se e
Les caractristiques que nous avons prsentes ci-dessus sont issues de nos exe e e priences ralises dans le domaine de ladministration autonome avec les syst`mes e e e e TUNe et Jade. Ces caractristiques sont orthogonales dans la mesure o` elles se e u compl`tent et ne poss`dent aucun lien entre elles. Elles doivent tre envisages lors e e e e de la conception dun SAA a vocation gnrique. Dans la section suivante, nous pr` e e e sentons une approche de conception ainsi quun mod`le architectural possdant les e e caractristiques ci-dessus. e
6.2
6.2.1
Approche gnrale et Mod`le Architectural e e e

Approche Gnrale e e
Les sections prcdentes ont prsent les caractristiques de base que doit foure e e e e nir notre SAA. Ladaptabilit appara comme le crit`re le plus important dans la e t e mesure o` cest lui qui permet au SAA de prendre en compte la majorit des besoins u e dadministration. Elle ncessite une implantation sous forme modulaire de telle sorte e que chaque fonction du SAA soit identie par un module prcis. De plus, limplane e tation modulaire peut faciliter la dynamicit du SAA lorsque ladaptation seectue e pendant lexcution du SAA. Dans ce contexte, nous prconisons une approche de e e dveloppement du SAA suivant un mod`le a composants. Contrairement a TUNe e e ` ` et Jade qui utilisent cette approche uniquement pour lencapsulation des logiciels et Syst`me dadministration autonome adaptable : application au Cloud e
61
Figure 6.1 Mod`le architectural gnral e e e matriels administrs, lapproche que nous proposons ici consiste ` mettre la notion e e a de composant au cur de la conception et de limplantation du SAA. Autrement dit, les fonctionnalits du SAA et les lments administrs doivent respectivement e ee e tre implantes et encapsuls dans des composants. Identions ` prsent le mod`le e e e a e e a composants que doit suivre notre SAA. `
6.2.2
Mod`le Architectural e
Dans le chapitre 4 nous avons prsent les objectifs et le mod`le (gure 4.1) de e e e base dun SAA. Compte tenu de sa simplicit, ce mod`le est tr`s souvent repris dans e e e la littrature sous le terme de MAPE-K LOOP. Il prsente uniquement lorganisae e Syst`me dadministration autonome adaptable : application au Cloud e
62
tion gnrale dun SAA sans prsenter en dtails sa constitution interne. Une des e e e e raisons qui explique cela vient du fait quen fonction des objectifs dimplantation, un SAA peut fournir toute ou partie des fonctionnalits de ladministration autoe nome (dploiement, conguration et reconguration). Cest le cas par exemple du e syst`me Taktuk [72] qui fournit uniquement des fonctionnalits de dploiement de e e e logiciels (notamment des applications parall`les dans les clusters de grande taille). e En ce qui concerne le syst`me que nous envisageons, nous fournissons un SAA reme plissant toutes les fonctions de ladministration autonome et implant suivant une e architecture ou un mod`le a composants (nous utiliserons le terme mod`le). Ce e ` e mod`le fait ressortir tous les composants constituants le SAA. La gure 6.1 prsente e e ce mod`le. e Sommairement, il sagit dun mod`le organis autour dune structure de done e nes (le SR) contenant tous les lments administrs (logiciels, matriels) ainsi que e ee e e les politiques dadministration. Le SAA reoit des ordres dadministration venant de c lextrieur (via lExternal Communicator ). Apr`s construction du SR (par le SR e e Manager ), les composants gravitant autour de lui permettront au SAA de ralie ser ladministration proprement dite. Il sagit : du Deployment Manager pour le dploiement/undeploiement 1 , de lEvent Manager qui dcide des politiques ` exe e a e cuter ` la rception dvnements par lEvent Receiver , et du Policies Manager a e e e pour lexcution des politiques de dadministration ((re)conguration et dmarrage). e e Prsentons ` prsent en dtails le rle de chacun de ces composants. e a e e o External Communicator Il permet au SAA de communiquer avec lextrieur. Il sagit aussi bien de la e communication avec des acteurs humains (les administrateurs) que de la collaboration/interoprabilit avec dautres SAA. Ce composant reprsente le point dentre e e e e dans le SAA. Il joue un rle double dans le SAA. Le premier est la rception et lintero e prtation des requtes dadministration en provenance de lextrieur. Il fera ensuite e e e appel au composant du SAA capable dexcuter lordre dadministration contenue e dans la requte. Son second rle est la restitution a linitiateur de la requte, les e o ` e rsultats de son excution. Cest ainsi que lExternal Communicator fera appel e e au : SR Manager lorsque la requte reue correspondra a la soumission de lapplie c ` cation a administrer au SAA ou la modication du syst`me de reprsentation ` e e (voir ci-dessous) ; Deployment Manager pour le dploiement des applications ; e Event Manager pour lexcution des programmes de reconguration. e SR Manager Il est charg de construire une reprsentation des lments a administrer ainsi que e e ee ` des politiques dadministration de telle sorte que le SAA puisse facilement les manipuler. Compte tenu du fait que ces lments sont considrs comme des bo noires, ee ee tes le SR Manager doit raliser pour chacun dentre eux une opration dencapsulae e
1. Compte tenu de la non existence des antonymes au mot Dploiement et au verbe e Dployer, nous introduisons respectivement le mot Undploiement et le verbe Unde e e ployer pour jouer ces rles. o
63
tion. Cette derni`re consiste ` externaliser (avec le concours de ladministrateur) : e a dune part les fonctions mtiers de llment considr an de les rendre accessibles e ee ee par le SAA ; et dautre part les proprits de llment. Cest en fonction de limee ee plantation de lencapsulation que le fournisseur du SAA dcidera de respecter ou e non le crit`re duniformit que nous avons prsent dans la section 6.1.1. e e e e Nous nommons SR (Syst`me de Reprsentation), lensemble constitu de ces le e e ee ments encapsuls. Il contient a un instant donn la photographie de ltat courant e ` e e de lenvironnement en cours dadministration. Le SR reprsente en quelque sorte la e base de donnes du SAA. Il sera utilis par tous les autres composants du SAA. e e Deployment Manager Il ralise a la fois les oprations de dploiement et undploiement dans le SAA. e ` e e e Pour cela, il sappuie dune part sur le SR an davoir les proprits des lments ee ee a dployer et dautre part sur les eecteurs an dexcuter concr`tement les opra` e e e e tions de dploiement sur la machine distante. La communication avec les eecteurs e seectue par le biais de lInternal Communicator . Pour nir, notons que le Deployment Manager dnit galement les politiques dallocation et de librae e e tion de ressources de lenvironnement administr de telle sorte quelles pourront tre e e adaptables. Internal Communicator Il assure la communication entre le SAA et les lments en cours dexcution ee e (par lintermdiaire des eecteurs). Cest grce ` lui notamment que le SAA pourra e a a rellement excuter les oprations dadministration. e e e Event Receiver Il g`re larrive des vnements/messages vers le SAA en provenance des lments e e e e ee quil administre. Il les transmettra par la suite au gestionnaire dvnements (Event e e Manager ). Event Manager En fonction de ltat du SR et des vnements quil reoit, il dcide de leur prise e e e c e en compte ou non. Dans le cas o` lvnement est pris en compte, il identie dans u e e le SR les programmes dadministration ` excuter par le Policies Manager . a e Policies Manager Il joue le rle dexcution des programmes dadministration. Il doit pour cela o e implanter les services dun interprteur de programmes qui lui permettra didentie er les sries dactions comprises dans les programmes quil dsire excuter. Pour e e e chaque action identie, il fera appel a lInternal Communicator pour son ace ` complissement rel a distance sur la machine dexcution de llment concern par e ` e ee e laction.
` 6.3. SYNTHESE
64
6.2.3
Prise en compte des caractristiques e
Apr`s la prsentation du mod`le architectural devra suivre la conception et le e e e dveloppement dun SAA gnrique, montrons ` prsent comment ce mod`le rpond e e e a e e e aux caractristiques que nous avons identies dans la section 6.1. e e Luniformit des lments administrs dans le SAA est assure dans ce mod`le e ee e e e par le composant SR Manager . En eet, cest dans son implantation que les constructeurs du SAA dcideront de ger ou non les dirences entre les lments e e ee administrs. e Ladaptabilit du SAA est vidente dans ce mod`le dans la mesure o` il rpond e e e u e enti`rement sur une architecture a composants dans lequel tous les services sont e ` identiables par un composant. Pour nir, la collaboration/interoprabilit est une fonctionnalit mise en avant et e e e remplie par le composant External Communicator dans le mod`le. Ce composant e permet lmission et la rception dordres dadministration entre plusieurs SAA de e e natures distinctes.
6.3
Synth`se e
Dans ce chapitre, nous avons propos des directives devant guider la concepe tion et le dveloppement dun SAA hautement adaptable et exible. Ces directives e concernent a la fois les besoins que doit remplir ce SAA, lapproche gnrale de son ` e e implantation et pour nir le mod`le architectural quil devra suivre. De plus, nous e avons montr comment ces directives permettront au SAA de prendre en compte e ladministration dune plateforme de cloud ainsi que des applications quil hberge. e Dans le chapitre suivant, nous tudions les travaux de recherche existants qui e sintressent aux mmes problmatiques que celles que nous adressons dans cette e e e th`se. Il sagit globalement de la construction des SAA exibles et de ladministrae tion autonome dans le cloud.
Chapitre 7 Etat de lart

Contents
7.1 SAA . . . . . . . . . . 7.1.1 Rainbow . . . . . . 7.1.2 Accord . . . . . . . 7.1.3 Unity . . . . . . . 7.1.4 Synth`se . . . . . . e 7.2 SAA pour le cloud . . 7.2.1 OpenNebula . . . 7.2.2 Eucalyptus . . . . 7.2.3 OpenStack . . . . 7.2.4 Microsoft Azure . 7.2.5 Autres plateformes 7.3 Synth`se . . . . . . . . e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . de cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 . 67 . 69 . 71 . 73 . 73 . 74 . 77 . 78 . 80 . 83 . 83
Dans cette th`se, notre principale problmatique est ladministration des platee e formes de cloud et des applications quelles hbergent. Exerant dans le domaine de e c ladministration autonome depuis ces derni`res annes, nous avons tabli le rapproe e e chement entre la problmatique dadministration dans le cloud et celle des grilles e de calculs que nous traitions dans nos recherches. Cest ainsi que nous avons entrepris dtudier lutilisation de notre syst`me dadministration autonome TUNe, conu e e c pour ladministration des applications dans les clusters et les grilles, pour ladministration du cloud dans son ensemble (IaaS et applications des entreprises). Conu c pour tre gnrique et utilisable dans plusieurs domaines, le syst`me TUNe a montr e e e e e cependant quelques dicults a prendre en compte des besoins dadministration de e ` certains domaines applicatifs parmi lesquels le Cloud (voir le chapitre 5). Ltude des dicults de TUNe nous a conduit ` proposer plus gnralement un e e a e e canevas de dveloppement dun vritable syst`me gnrique et adaptable ` tous les e e e e e a domaines applicatifs dont le cloud. Ce canevas prconise trois recommandations a e ` suivre dans le processus de dveloppement dun SAA a vocation gnrique : e ` e e
7.1. SAA
66
(1) Sparer le dveloppement du cur du SAA (fonctionnalits de base) de celui e e e des langages dadministration quutiliseront ses futurs administrateurs. (2) Le SAA devra remplir les crit`res suivants : e luniformit : il ne dispose daucun comportement pr-cbl li ` un type e e a e e a dlment (les machines par exemple). ee ladaptabilit : la modication de ses services ne doit pas ncessiter la connaise e sance enti`re de son processus de dveloppement. e e linteroprabilit : sa facult a initier la communication avec dautres SAA e e e` dune part et a exporter ses interfaces dacc`s distant dautre part. ` e (3) Pour nir, nous recommandons lutilisation dune approche de dveloppement ` e a composants pour son implantation. En somme, nous nous intressons a deux problmatiques : la construction de e ` e SAA gnriques et ladministration du cloud dans son ensemble (niveau IaaS et ene e treprise). Dans ce chapitre, nous tudions les travaux de recherche qui sintressent e e a ces problmatiques. Nous lorganisons de la mani`re suivante. Dans un premier ` e e temps, nous tudions les SAA ` vocation gnrique existants. Dans cette premi`re e a e e e tude, nous prsentons le positionnement de ces SAA par rapport aux recommane e dations que nous avons numres ci-dessus. Dans un second temps, nous tudions e ee e les syst`mes dadministration spciques aux environnements de cloud. Comme nous e e lavions prcis dans la section 3.3, ces syst`mes doivent remplir les crit`res suivants : e e e e Interoprable : capacit a dialoguer avec dautres syst`mes de gestion de e e ` e cloud et galement avec des syst`mes dadministration des applications dene e treprises. Auto-rparable : capacit a prendre en compte automatiquement les pannes e e` dans lenvironnement quil administre (machines, VM et logiciels). Extensible : capacit ` prendre en compte de nouveaux lments dans lenea ee vironnement (nouvelles machines relles et virtuelles, nouveaux logiciels). e Programmable : capacit a prendre en compte de nouvelles politiques dade` ministration (nouvelles mthodes de consolidation, de scalabilit, etc.). e e Adaptable : capacit ` permettre le remplacement ou la modication de ses ea modules an de prendre en compte des particularits de certaines plateformes e de cloud. Langages ddis : dispose des langages de facilitation de son utilisation. e e Compte tenu de sa spcialisation dans le cloud, il nest pas absurde que ce e syst`me propose des langages facilitant son utilisation. e Remarquons que ces crit`res sont inclus dans ceux que nous avons identis pour les e e SAA gnriques. e e
7.1
SAA
Parmi les travaux de dveloppement de SAA, peu dentre eux ont la vocation de e prendre en compte plusieurs domaines dapplications ` la fois. En eet, ils sinta e ressent chacun pour la plupart ` un domaine prcis. Ainsi, le crit`re dadaptabilit a e e e Syst`me dadministration autonome adaptable : application au Cloud e
7.1. SAA
67
que nous considrons comme le crit`re principal de notre mod`le est tr`s peu pris en e e e e compte dans les autres syst`mes. Pour cette raison, notre revue de lexistant tudiera e e principalement lextensibilit des SAA qui est lun des crit`re dcoulant de ladaptae e e bilit et pris en compte par certains SAA. En rappel, lextensibilit dun SAA dsigne e e e la capacit du SAA ` prendre en compte pendant son excution, lajout/retrait de e a e nouveaux lments logiciels ou des instances de logiciels dont la description existait ee au dmarrage du SAA. e Dans cette section, nous tudions les SAA : Rainbow [55], Accord [70] et Unity [37]. e Le premier se dnit comme SAA adaptable (au sens que nous avons dni dans le e e chapitre prcdent) a des domaines quelconques tandis que les deux derniers sont e e ` spciques a des domaines particuliers. e `
7.1.1
Rainbow
Description gnrale e e La plateforme Rainbow [55] est le fruit du projet DASADA DARPA [das] de luniversit de Carnegie Mellon. Dveloppe au sein de lquipe ABLE [abl], elle est e e e e disponible comme logiciel open source. A lexception des SAA TUNe et Jade, Rainbow est lun des rares SAA que nous avons parcourus (Pragma [83], Cascada [22], Accord [70], Unity [37], etc.) qui se rclament tre adaptable a tous types dapplicae e ` tions. Pour cela, son architecture est organise en deux parties : la premi`re partie e e implante les fonctionnalits de base de ladministration autonome tandis que la see conde partie implante les services qui pourront tre adaptable par le suite. Cest e cette deuxi`me partie qui sera personnalise en cas de besoin an de prendre en e e compte un nouveau domaine dapplications. Le syst`me Rainbow est conu pour e c ladministration dapplications pralablement installes et en cours dexcution. Il e e e ne fournit pas les fonctions de dploiement de logiciels. Son excution dbute par la e e e fourniture dun mod`le reprsentant larchitecture de lapplication en cours dexcue e e tion. Ce mod`le sera ensuite maintenu par Rainbow tout au long de son excution e e (via les composants Gauges et Model Manager). Cest lquivalent du syst`me de e e reprsentation (SR) dans TUNe. e Pour nir, le mod`le architectural (gure 7.1) implant par Rainbow est proche e e de celui que nous avons prsent dans la section 6.2 du chapitre 6. A lexception e e de labsence du service de dploiement et de collaboration, nous retrouvons plus ou e moins les mmes lments : e ee Le Model Manager correspond au SR Manager dans notre mod`le. e Le Strategy Executor correspond au Policies Manager dans notre mod`le. e LAdaptation Manager et lArchitecture Evaluator correspondent ` lEvent Maa nager dans notre mod`le. e Le Translation Infrastructure implante lEvent Receiver de notre mod`le. De e plus, il met en place le mcanisme dexcution de mthodes ` distance sur les e e e a machines hbergeant llment administr. Le service implantant ce mcanisme e ee e e nest pas clairement identi dans larchitecture de Rainbow. e
7.1. SAA
68
Figure 7.1 La plateforme Rainbow Ainsi, nous ne prsentons pas les lments prsents dans cette architecture extraite e ee e de [55]. Machine Langage Rainbow implante deux langages : lun pour la description du SR (le langage Acme) et lautre pour la dnition des politiques de reconguration (le langage e Stitch). Linterprtation de ces langages est cble et ne peut tre remplace mme e a e e e e par adaptation (section Adaptable). De plus, ces langages sont propres a lquipe ` e de dveloppement de Rainbow (ABLE). e Approche de dveloppement e Raimbow est implant suivant une approche a composants : le mod`le Acme [56] e ` e dvelopp au sein de la mme quipe. De faon similaire, la description et lencape e e e c sulation des logiciels dans Rainbow se fait par le biais du mme mod`le. e e Uniforme Rainbow organise le SR en deux mod`les : un mod`le contenant les logiciels a e e ` administrer et un mod`le contenant les lments de lenvironnement matriels (les e ee e machines). Il eectue une dirence entre la reprsentation des machines, la repre e e sentation des logiciels et celle des sondes. En exemple : les proprits des machines ee de lenvironnement sont dnies par Rainbow : les sondes ne sont pas considres e ee comme des logiciels administrables. Adaptable La plateforme Rainbow a t conue an dtre adaptable aussi bien conceree c e Syst`me dadministration autonome adaptable : application au Cloud e
7.1. SAA
69
nant ses composants de service que les applications quil administre. Cependant, la construction et lintgration de nouveaux services dans cette plateforme restent e rserves aux ingnieurs ayant une expertise sur la plateforme. Pour palier a cette e e e ` dicult, une plateforme graphique de facilitation de cette tche est dsormais foure a e nie. Il sagit de RAIDE [36]. Lorsque nous nous intressons aux composants de service de Rainbow qui sont e personnalisables, nous nous rendons compte quil ne sagit pas eectivement des fonctions de service telles que nous les avons identies dans notre mod`le dans la e e section 6.2 du chapitre 6. En eet, les composants dont parlent les constructeurs de Rainbow sont : les eecteurs, les sondes, les lments du SR (r`gles de reconee e guration, logiciels, proprits des logiciels). Par contre, les composants grant la ee e construction du SR par exemple, ou encore les interprteurs de langages dadminise tration ne font pas partie des services personnalisables. Interoprable e Aucune fonctionnalit dinteroprabilit nest fournie par Rainbow. e e e
7.1.2
Accord
Description gnrale e e Accord [70] [69] fait partie des contributions du projet AutoMate [18] ` lunivera sit du New Jersey. Le but du projet AutoMate est de fournir des solutions dade ministration autonome pour des syst`mes complexes. Dans ce projet, Accord (via e son implantation DIOS++) est une plateforme de programmation dapplications scientiques auto-administrables. De la mme faon que TUNe, Accord consid`re e c e les lments a administrer comme des bo noires. ee ` tes Lencapsulation dun logiciel se fait par la dnition de port de communication e dans Accord. Il identie trois types de port : port fonctionnel : correspond aux points dentres des fonctions mtiers de e e llment. Il est utilis pour relier les logiciels entre eux an de permettre leurs ee e interactions. port de contrle : permet de dnir les points dentre/sortie des eecteurs et o e e sondes. port de gestion : utilis pour linjection et lexcution de r`gles dadaptation e e e du logiciel. Il associe a chaque lment administr un Manager qui soccupe du contrle (monito` ee e o ring de ltat, du dclenchement des vnements et de lorchestration de lexcution e e e e e des actions de reconguration) de son excution. Le Manager sexcute sur la mme e e e machine que llment quil contrle. De cette faon, Accord dcentralise ladminisee o c e tration. La gure 7.2 rsume lencapsulation dun lment dans Accord. Pour nir, e ee notons quAccord nassure pas le dploiement des logiciels quil administre. Cette e tche est laisse ` la charge des administrateurs. Par contre, il contrle le dploiea e a o e ment des politiques de reconguration.
7.1. SAA
70
Figure 7.2 Encapsulation dun logiciel dans Accord Machine Langage Ladministration dans Accord dbute par la dnition du contexte applicatif. Il e e sagit de la base syntaxique et smantique quutilisera plus tard ladministrateur e pour la dnition des lments administrs et des r`gles de reconguration. Pour e ee e e cela, Accord se base sur les langages SIDL [88] et WSDL [38] pour la dnition de e ce contexte. SIDL est utilis pour la dnition des composants tandis que WSDL est e e utilis pour la dnition des ports de contrle. De plus, il fournit et cble le langage e e o a utilis pour la dnition des programmes de reconguration. Il sagit dun langage e e simpliste de type IF <condition> THEN <action>. Approche de dveloppement e Limplantation actuelle dAccord (DIOS++) repose sur deux approches de dvee loppement : oriente objet (c++) et mod`le ` composants (CCAFFEINE CCA [20]). e e a La premi`re a t utilise pour limplantation de DIOS (un prototype dAccord). e ee e Quant a la seconde approche, Accord lutilise uniquement pour lencapsulation des ` logiciels a administrer. Cest une approche analogue a celle utilise par le syst`me ` ` e e TUNe [29]. Uniforme Parmi les lments administrs, Accord ne prend pas en compte les lments ee e ee matriels constituant lenvironnement dexcution. Il fait lhypoth`se quils sont inse e e talls et grs par des syst`mes externes [18] (Rudder, Meteo et Sesame/DAIS). e ee e Concernant les lments logiciels, il eectue une dirence entre les logiciels raliee e e sant les fonctions mtiers de lapplication et les sondes jouant le rle de monitoring. e o En eet, les sondes doivent tre programmes dans la plateforme Accord. Elles ne e e sont pas considres comme des logiciels administrables. Ainsi, pour une application ee disposant dun vritable logiciel de monitoring, ce dernier devra tre rimplant dans e e e e Accord.
7.1. SAA
71
Adaptable Le dveloppement DIOS++ (implantation dAccord) ne suit pas une approche e a composants et na pas envisag dans sa conception la possibilit de modier/rem` e e placer/ajouter de nouvelles fonctionnalits par un utilisateur extrieur. Qu` cela ne e e a tienne, intressons nous aux facettes adaptables et non adaptables dAcccord. e Accord permet la modication dune part de larchitecture et dautre part des fonctionnalits dun logiciel en cours dadministration. En eet, tant donn quil utie e e lise un mod`le a composants pour lencapsulation des logiciels, la modication de lare ` chitecture ou encore lenrichissement des fonctionnalits dun logiciel deviennent pose sibles. La modication de larchitecture comprend les oprations suivantes : lajout, e le remplacement et le retrait des logiciels de larchitecture. Concernant lajout des logiciels, il ne se limite pas uniquement aux lments existants initialement dans la ee dnition fournie a Accord par ladministrateur. Quant a la modication du come ` ` portement dun logiciel, elle se ralise par la modication de liaison, la suppression e ou lajout de ports fonctionnels. Cependant, Accord garde le contrle sur limplantation du processus de remplao cement des logiciels. Par exemple, cest lui qui implante les politiques de rparation e de logiciel ou de remplacement de logiciels par dautres plus optimiss. e Interoprable e La seule interoprabilit quimplante Accord est celle quil eectue avec les syse e t`mes de gestion de lenvironnement matriel et rseau (Rudder, Meteo et Sesame/e e e DAIS [99]) dans lesquels sexcuteront les logiciels quil auto-administre. Globalee ment, aucune API de collaboration avec dautres SAA nest fournie dans Accord.
7.1.3
Unity
Description gnrale e e Unity [37] est lun des premiers SAA qui a vue le jour apr`s la pose des bases de e ladministration autonome par IBM en 2001 [64]. En eet, il est le prototype dun SAA dvelopp par IBM an de valider les principes quil a nonc auparavant. Il e e e e est conu pour ladministration des services OGSA [50]. c De la mme faon que la plateforme Accord (section 7.1.2), tous les lments e c ee a administrer dans Unity sont autonomes. Il associe a chaque lment administr, ` ` ee e un composant Manager qui sera dploy et excut sur la mme machine de cet e e e e e lment. Le rle du Manager est la gestion de llment qui lui est associ : gestion ee o ee e des liaisons/interactions avec les autres lments, monitoring, dclenchement des ee e programmes de reconguration (appels r`gles) et maintien de ltat de llment e e e ee (par renseignement de proprits). Notons galement quUnity auto-administre, de ee e la mme faon que les lments de ladministrateur, ses propres constituants (le c ee ee ments destins a la ralisation de ses services prsents ci-dessous). De la mme e ` e e e e faon quAccord, lassociation de Managers aux lments permet de dcentraliser c ee e
7.1. SAA
72
ladministration dans Unity. Unity est construit autour de six lments : ee Le gestionnaire de lenvironnement du logiciel : il g`re les ressources dont e lapplication a besoin pour atteindre ses objectifs. Lune de ses principales responsabilits est de prdire le comportement du logiciel en cas de de monte e e e et baisse de charges sur les ressources qui lui sont alloues. e Le gestionnaire de ressources : cest lui qui implante la politique dassignation de ressources aux logiciels. Chaque gestionnaire denvironnement de logiciel lui fournit une valuation des ressources dont a besoin son logiciel. Ensuite, e le gestionnaire de ressources dcidera des quantits de ressources a allouer a e e ` ` chaque logiciel. Il dcide galement de linstant dassignation ou retrait des e e ressources. lannuaire : cest le lieu denregistrement des rfrences des lments admiee ee nistrs par Unity ainsi que des ressources de lenvironnement. A travers cet e annuaire, chaque lment dUnity pourra dcouvrir les lments dont il a beee e ee soin pour son fonctionnement. Le gestionnaire des r`gles de reconguration : il permet a ladministrateur de e ` dnir et de stocker les r`gles de reconguration. e e Les sentinelles : permettent a un lment dintrospecter ltat dun autre. ` ee e Les lments administrs : il sagit des logiciels (server ) et des ressources (OSee e Container ) prsents dans lenvironnement. e Larchitecture du syst`me Unity nest pas loigne de celle du syst`me Accord. e e e e Machine Langage Les logiciels ` administrer par Unity doivent tre dvelopps en Java dans la a e e e plateforme Autonomic Manager Toolset fournie galement par IBM. Unity fournit e galement un langage dit de haut niveau (sur lequel nous disposons peu dinformae tions dans la littrature consacre a cette plateforme) pour la dnition des r`gles e e ` e e de reconguration. Approche de dveloppement e Unity utilise un mod`le a composants a la fois pour son dveloppement et pour e ` ` e le dveloppement des logiciels administrs. Il pratique le tout composant. e e Uniforme La plateforme Unity dnit un type, cbl en son sein, pour chaque type dle a e ee ment quil administre. A chaque type est associ un comportement prcis. Ainsi : les e e logiciels administrs et les constituants dUnity sont dit de type server ; les machines e hbergeant les servers sont de type OSContainer. e Adaptable Unity na pas envisag ladaptabilit de ses composants. Aucune architecture a e e ` composants dUnity nest disponible dans la littrature et nous ne saurions valuer e e le niveau de dicult de ladaptation dun service dUnity pour un administrateur e non averti. Ladaptabilit dUnity par contre peut tre observe sous langle de lextensibilit e e e e
7.2. SAA POUR LE CLOUD
73
de lenvironnement administr. Unity permet la prise en compte dynamique de : e nouvelles r`gles de reconguration, nouvelles machines dans lenvironnement, ou e encore de nouveaux logiciels ` administrer dans lapplication. Cette fonctionnalit a e est permise grce a lauto-administration de chaque lment de lenvironnement. a ` ee Ainsi, il sera capable de sintgrer dans lenvironnement sans ncessiter larrt du e e e syst`me. e Interoprable e Aucune fonctionnalit dinteroprabilit nest fournie par Unity. e e e
7.1.4
Synth`se e
Nous avons tudi trois SAA dans cette section : Rainbow [55], Accord [70] et e e Unity [37]. Parmi ces syst`mes, seule larchitecture de Rainbow se rapproche de celle e que nous avons propos dans la section 6.2.2 du chapitre prcdent. Quant a Accord e e e ` et Unity, ils se situent dans la mme ligne que les SAA tels que Pragma [83] ou e e Cascada [22] que nous navons pas prsents ici. Malgr son caract`re adaptable, e e e e Rainbow (comme les autres SAA que nous avons tudis) nest pas utilisable pour e e ladministration du cloud. Dans la section suivante, nous prsentons des SAA conus e c particuli`rement pour ladministration du cloud. e
7.2
SAA pour le cloud
Depuis ces derni`res annes, plusieurs projets autour du cloud computing ont vu e e le jour et donn naissance a autant de syst`mes dadministration dans le cloud. Dans e ` e cette section, nous tudions les plus importants et disponibles dentre-eux. Par e disponibilit ici, nous entendons les syst`mes pour lesquels la documentation exise e tante est susamment dveloppe pour faire lobjet dune tude telle que nous la soue e e haitons. En eet, parmi les plateformes de cloud importantes, la plupart dentre elles sont propritaires et tr`s peu documentes. Par soucis dexhaustivit, nous identions e e e e deux plateformes non documentes dont nous fournirons uniquement une description e gnrale. Il sagit des plateformes Amazone EC2 [61] et RightScale [RIGHSCALE]. e e Quant aux plateformes documentes, nous nous intressons aux syst`mes : Opene e e Nebula [OpenNebula], Eucalyptus [80], OpenStack [Inc.] et Windows Azure [76]. Les syst`mes OpenNebula [OpenNebula], Eucalyptus [80] et OpenStack [Inc.] sont issus e des projets open source et ne fournissent que le support logiciel (et pas matriel) de e la mise en place dune vritable plateforme de cloud. Quant a la plateforme Windows e ` Azure [76], elle est propritaire et commerciale. e
74
7.2.1
OpenNebula
Description gnrale e e La syst`me OpenNebula [OpenNebula] voit le jour en 2005 ` luniversit Come a e plutense de Madrid dans le cadre du projet europen open source RESERVOIR [87]. e Son objectif dans le cadre de ce projet est ladministration des IaaS virtualiss. e Autrement dit, il fournit des services permettant de dployer et dexcuter dans e e un environnement matriel virtualis des VM. Notons quune version commerciale e e dOpenNebula (OpenNebulaPro) est disponible depuis 2010. Dans sa version actuelle, OpenNebula est capable de prendre en compte simultanment dans lIaaS des hyperviseurs Xen [23], kvm [97] et VMware [VMware.org]. e Il organise lIaaS sous forme de clusters et de VLAN (rseaux virtuels). Un cluster e contient un ensemble de machines physiques tandis quun VLAN est dni pour un e ensemble de VM. Lors de la cration dune VM, le client choisit la machine et le e VLAN dans lequel il souhaite lexcuter. Notons que dans lesprit du cloud, il ne e revient pas au client de choisir la machine sur laquelle il souhaite excuter sa VM. e Toutes les oprations dadministration sont coordonnes a partir dune unique e e ` machine de lIaaS appele Frontend. Son fonctionnement est rgi par cinq processus e e et une base de donnes (gure 7.3) : e Virtual Machine Manager (VMM) Driver : il g`re les API dinterfaage avec les e c dirents hyperviseurs prsents dans lIaaS. Pour cela, il dploie sur toutes les e e e machines de lIaaS les scripts dinterfaage avec lhyperviseur sur la machine. c Transfert Manager (TM) Driver : il g`re le transfert des images de VM dans e direntes situations : avant leur excution (du serveur de stockage vers la e e machine dexcution de la VM) ; pendant leur excution (migration de VM e e dune machine ` une autre) ou apr`s leur excution (suppression ou sauvegarde a e e de limage). Information Manager (IM) Driver : il fournit les sondes de monitoring et g`re e les informations que celles-ci obtiennent de lexcution des VM. Il dploie sur e e toutes les machines de lIaaS une sonde (en fonction de lhyperviseur utilis) e charge de collecter les informations lies aux VM en cours dexcution sur la e e e machine. Scheduler : Il g`re les politiques de consolidation des VM dans lIaaS. e Oned : Il congure, dmarre et orchestre lexcution des processus prcdents. e e e e Cest le point dentre et de ralliement de lensemble de ces processus. e DB : Cest la base de donnes qui contient toutes les informations concernant e ltat de lIaaS et de ses utilisateurs. Elle correspond au SR de notre mod`le e e de SAA. Interoprable e OpenNebula fournit plusieurs moyens de communication avec lextrieur. Ces e moyens sont bass sur un ensemble dAPI de bas niveau (utilisables par des dvee e loppeurs dextension ` OpenNebula) et une interface de ligne de commandes. Cette a derni`re est essentiellement rserve aux acteurs humains du cloud. Les interfaces de e e e
75
Figure 7.3 Composition dOpenNebula bas niveau et linterface de ligne de commandes sont utilises pour lexcution des e e commandes dadministration de base (rservation de VM, dmarrage, arrt de VM, e e e etc.). OpenNebula ne fournit aucun support permettant aux entreprises de facilement dployer et administrer leur applications dans lIaaS. Cependant, ses API peuvent e tre exploites par un SAA de niveau entreprise an dautomatiser les oprations de e e e rservation et de monitoring des VM dune entreprise. Par contre, en dehors de la e communication avec les plateformes Amazon EC2 [61] et ElasticHost [ElasticHosts] (deux plateformes payantes de cloud), OpenNebula ne dispose daucun autre moyen de ladapter pour linitiation de la collaboration avec dautres plateformes de cloud. Auto-rparable e OpenNebula g`re deux types de pannes : pannes de machines et pannes de VM. e Dans les deux cas, ladministrateur dnit au dmarrage de Oned, les politiques de e e rparation quil dsire appliquer en cas de pannes. OpenNebula utilise le mcanisme e e e dvnement-action (quil appelle Hook ). Un vnement correspond ` la variation e e e e a de ltat dune machine (physique ou VM). Ltat de la machine est rguli`rement e e e e renseign par les sondes de lIM Driver. e Lexcution des actions associes a un vnement est locale (sur la machine dexe e ` e e e cution de Oned ) ou distante (sur la machine o` la panne a t dtecte). Cette exu ee e e e cution est donc limite a une seule machine. Il revient a ladministrateur de dnir e ` ` e le lieu dexcution des actions de rparation. De plus, les Hook dOpenNebula ne e e permettent pas de prendre en compte les pannes concernant ses propres serveurs. En eet, ne faisant pas partie des proccupations dOpenNebula, aucune sonde nest e prvue pour leur surveillance. La panne dun serveur DNS par exemple ne pourra ni e tre dtecte ni tre rpare par OpenNebula. e e e e e e Extensible La gestion de lIaaS par OpenNebula repose enti`rement sur lextension de ses e lments. En eet, il dmarre lIaaS sans aucun lment et attend leur ajout par ee e ee ladministrateur. Cest ainsi que les clusters de machines, les utilisateurs et les de nitions de VM lui sont rajouts pendant son excution. Il fournit parmi ses API le e e moyen dajouter/retirer des lments de lenvironnement. Cependant, il ne permet ee pas la modication des lments pralablement ajouts. Par exemple, la modicaee e e Syst`me dadministration autonome adaptable : application au Cloud e
76
tion des caractristiques (nom DNS ou adresse rseau) dun VLAN enregistr nest e e e pas possible. De la mme faon, lajustement des ressources dune VM en cours e c dexcution dans lIaaS nest pas permis. e Programmable Aucune interface de programmation nest fournie pour les applications entreprises. La programmation des politiques dadministration dans OpenNebula se limite uniquement au niveau de lIaaS. La consolidation de VM est ralise par un procese e sus particulier : le Scheduler. Ce dernier sexcute sur le Frontend et est indpendant e e de lexcution de Oned. Il sexcute rguli`rement ` la recherche de VM devant tre e e e e a e dplaces vers des machines plus adquates selon la politique de consolidation. Dans e e e son implantation actuelle, le Scheduler dOpenNebula propose quatre politiques de consolidation : clatement/regroupement de VM suivant leur nombre sur une mae chine, clatement/regroupement de VM suivant leur consommation CPU. Toutes ces e politiques sont utilisables simultanment, ce qui peut entra e ner des contradictions (clatement pour certaines VM et regroupement pour dautres). Lintgration de e e nouvelles politiques a ce Scheduler est impossible. Le seul moyen de lamliorer est ` e son remplacement tout entier. Cependant, il nest pas prvu de support logiciel pour e la conception de politique de consolidation. Cest la raison pour laquelle seules des solutions issues de son cosyst`me (dveloppements auxiliaires au projet OpenNee e e bula) existent. Il sagit des schedulers Haizea [89] et Claudia [cla]. Les politiques de consolidation de VM sont associes par le propritaire de la VM e e lors de sa rservation. Il semble trange quOpenNebula utilise cette stratgie. En e e e eet, la prise de dcision pour la consolidation devra prendre en compte les exigences e particuli`res de chaque VM et non de celui du cloud dans son ensemble. Rappelons e que lobjectif de la consolidation dans le cloud est doptimiser lutilisation de ses ressources et non de celles des VM. La consolidation est ralise dans lintrt du e e ee fournisseur du cloud et non de celui de la VM ` qui des ressources sont alloues et a e garanties. Adaptable La construction dOpenNebula sous forme modulaire le rend enti`rement adape table. Toutes les tches dadministration sont identiables et remplaables sans aua c cun besoin de connaissance de limplantation enti`re dOpenNebula (` lexception e a du Scheduler ). En eet, il associe a chacun de ses services un ensemble de scripts ` dnis dans un rpertoire prcis du Frontend de telle sorte que la modication du e e e service seectue a un unique endroit. Cependant, il ncessite de la part de ladmi` e nistrateur une expertise vis a vis des syst`mes Linux. De plus, pour les services les ` e plus basiques, comme le moyen de connexion sur les machines distantes (protocole SSH), il est extrmement dicile de les adapter. En eet, son utilisation par tous e les services, implique que son adaptation entra nera celui de tous les services. En outre, on pourrait se poser la question de la dynamicit de ladaptabilit e e dOpenNebula. La modication dun de ses modules ncessite le redmarrage de e e lensemble de ses serveurs ainsi que des VM en cours dexcution dans lIaaS. e
77
Langages ddis e e OpenNebula ne fournit aucune facilit langage pour lexpression des politiques e dadministration. Ladministrateur doit avoir une bonne comptence en programe mation syst`me Linux et Java. e
7.2.2
Eucalyptus
Description gnrale e e Comme OpenNebula, Eucalyptus [80] est galement une plateforme open source 1 e de cloud computing issu en 2007 du projet VGrADS [vgr] a luniversit de Californie, ` e Santa Barbara. Il permet dexcuter des VM dans un IaaS virtualis. Actuellement, e e Eucalyptus prend en compte des IaaS munis des syst`mes de virtualisation Xen, kvm, e VMware. Il organise lIaaS de faon hirarchique : les machines au niveau des feuilles, c e les clusters (groupe de machines) au niveau intermdiaire et le cloud (ensemble de e clusters) a la racine. Son fonctionnement est organis de la mme faon. Il associe a ` e e c ` chaque niveau de lIaaS un composant prcis (gure 7.4) : e Instance Manager (IM) : il sexcute sur chaque machine de lIaaS. Il a pour e rle de grer le cycle de vie des VM. o e Group Manager (GM) : il se trouve a la tte dun cluster. Il collecte les infor` e mations des IM prsents sur les machines de son cluster. Il sexcute sur une e e machine du cluster (pouvant galement hberger un IM). e e Cloud Manager (CM) : Cest le point dentre du cloud (pour ladministrateur e et les clients). Il est reli aux dirents GM de lIaaS. e e Storage Controller (SC) : il g`re le stockage des images de VM. e Warlus : serveur de stockage de donnes des utilisateurs externes au cloud. e Il permet en quelque sorte au cloud dtre utilis comme centre de donnes. e e e Notons que les donnes quil stocke peuvent tre utilises par des VM en cours e e e dexcution (en fonction des propritaires). e e
Figure 7.4 Organisation dEucalyptus Interoprable e Les API (de programmation) quorent Eucalyptus permettent aux syst`mes e externes de le contacter. Par contre, un syst`me Eucalyptus nest pas prvu pour e e
1. Une version commerciale dEucalyptus existe depuis 2009.
78
initier la communication avec lextrieur. La plupart de ces API sont compatibles e avec la plateforme de cloud Amazon EC2. Auto-Rparable e Eucalyptus ne met en place aucun moyen dauto-rparation de VM ou de ses e serveurs. Une panne de VM ne peut tre constate que sur la demande du propritaire e e e de la VM ou du fournisseur de lIaaS par demande de ltat de la VM. e Extensible Comme OpenNebula, Eucalyptus permet lextension de lIaaS. Par contre, ladministrateur doit initialement installer sur la machine ` ajouter, tous les packages a Eucalyptus ncessaires pour lexcution de lIM. En eet, contrairement ` OpenNee e a bula qui se charge de linitialisation des machines ajoutes, Eucalyptus laisse cette e charge a ladministrateur. ` Programmable Aucune politique de consolidation de VM nest mise en place par Eucalyptus. Il se limite uniquement au placement de VM pendant leur dmarrage (choix de la machine e dexcution de la VM). De plus, ce placement est tr`s simpliste. En eet, lorsquun e e client demande lexcution dune VM dans un cluster, le GM de ce cluster choisit la e premi`re machine pouvant laccueillir. Pour cela, il contacte ses IM squentiellement e e a la recherche de celui pouvant hberger la VM. Il est pratiquement impossible pour ` e un non dveloppeur Eucalyptus de modier cette politique de placement. e Adaptable Malgr le discours autour de son adaptabilit et sa exibilit, il est dicile de les e e e mettre eectivement en uvre dans Eucalyptus. Par exemple, apr`s une installation e dEucalyptus, la modication de la politique de copie dimages de VM ncessitera e la rinstallation des IM sur toutes les machines de lIaaS. e Langages ddis e e A lexception des commandes et des API dutilisation du CM, aucun langage ddi nest fourni par Eucalyptus pour faciliter son administration ou son utilisae e tion. Cependant, le pluging Hybridfox [Labs] peut tre utilis sur le navigateur ree e fox [Mozilla] pour eectuer des fonctions de base comme lallocation des machines VM, lauthentication, etc.
7.2.3
OpenStack
Description gnrale e e OpenStack [Inc.] est une pile doutils open source pour la mise en place et ladministration dune plateforme de cloud. Les principaux contributeurs de ce projet sont Rackspace [Rackspace] et la NASA [NASA]. Rackspace fournit les outils de gestion de chiers dans le cloud tandis que la NASA apporte les outils de gestion de lIaaS
79
issus du syst`me Nebula [NASA] 2 . OpenStack sorganise autour de trois composants e et des API qui leur permettent de communiquer (gure 7.5) : Compute Infrastructure (Nova) : Il fournit les fonctionnalits de gestion du e cycle de vie des VM (via le sous composant nova-compute), du rseau (via e nova-network) et des authentications. Il implante galement les programmes e de scheduling de VM ` travers son composant nova-Scheduler. Son sous coma posant Queue Server implante le mcanisme de dispatching de requtes aux e e autres sous composants en fonction des actions quelles requi`rent e Storage Infrastructure (Swift) : il g`re le stockage de donnes dans le cloud. Les e e donnes sont stockes de faon redondante pour assurer de la tolrance aux e e c e pannes. Compte tenu de son isolation dans larchitecture, nous ne le faisons pas gur dans la gure 7.5. e Imaging Service (Glance) : g`re le stockage des images VM. e Notons que ces composants peuvent sexcuter sparment dans le cloud. e e e
Figure 7.5 Organisation dOpenStack
Interoprable e Aucun mcanisme dinteroprabilit ou de collaboration avec dautres plateforme e e e nest envisag. e Auto-Rparable e Aucun mcanisme de rparation nest mis en place dans OpenStack. En eet, il e e nimplante aucun mcanisme de monitoring et de rparation dans le cloud. e e Extensible Il est extensible dans la mesure o` lajout dun nouveau nud dans lIaaS reu vient a y installer un composant nova-Compute sur ce nud. La conguration de ` ce composant lui permettra de contacter les autres composants ncessaires pour son e fonctionnement (Glance, nova-Network et nova-Scheduler) et galement de sinsrer e e
2. Ne ma confondre Nebula fourni par la NASA et OpenNebula.
80
dans lenvironnement lIaaS. Lajout/retrait de nud ne ncessite donc pas darrt e e du cloud. Programmable Le Scheduler fournit uniquement un algorithme de placement (pas de consolidation) de VM. Il implante trois politiques de scheduling. la premi`re (chance) e choisit le nud alatoirement dans la liste des nuds de lIaaS. La seconde politique e (availability zone) est similaire a la premi`re ` la dirence quelle se limite ` une ` e a e a zone/cluster de machines prcises a lavance. La derni`re politique (simple) choisit e e ` e le nud ayant la consommation courant la moins leve. e e Adaptable La construction modulaire dOpenStack lui permet dtre adaptable. Par exemple, e le changement de la politique de gestion des congurations rseaux dans les VM se e fait facilement en remplaant le composant nova-Network. c Langages ddis e e Aucun langage particulier dutilisation du cloud nest fourni. Il se limite ` la a fourniture dAPI et doutils de ligne de commandes. Comme Eucalyptus, il supporte galement lutilisation du pluging Hybridfox [Labs] du navigateur refox [Mozilla] e pour eectuer des fonctions dadministration de base dans lIaaS (comme la gestion du cycle de vie des images de VM et des VM, lauthentication, etc).
7.2.4
Microsoft Azure
Description gnrale e e Microsoft Azure [76] (que nous appellerons Azure) est une plateforme commerciale de cloud dveloppe par le groupe Microsoft. Il joue un double rle : accome e o pagnement des clients dans le processus dexternalisation, et gestion de lIaaS (uniquement le syst`me de virtualisation Hyper-V [74]). Il est organis autour de quatre e e composants principaux : AppFabric : il ralise le premier rle de la plateforme. Cest la plateforme de de o e veloppement des applications entreprises qui seront externalises vers le cloud. e Les applications issues de cette plateforme seront facilement administres dans e lIaaS. Il correspond au SAA de niveau entreprise. Cest grce a lAppFabric a ` que la plateforme Azure est considre dans la littrature comme un PaaS. ee e Windows Azure : il ralise le second rle de la plateforme. Cest lui qui dploie e o e et excute les VM dans lIaaS (grce a son composant FrabricController conu e a ` c pour le syst`me de virtualisation Hyper-V). e SQL Azure : Cest le syst`me de gestion de base de donnes dAzure. e e Marketplace : Cest une plateforme de vente et dachat de composants logiciels dvelopps sur AppFabric. En eet, dans le but de faciliter les dvelope e e pements sur AppFabric, les clients peuvent se procurer des briques logiciels pr-dveloppes et mises en vente sur Marketplace. e e e
81
Les facilits dadministration fournies par Azure se limitent aux applications (appee les rle 3 dans Azure) web de type n-tiers. En eet, le composant AppFrabric ne e o permet que le dveloppement de ce type dapplications. Cependant, il est capable e dhberger dautres types dapplications directement fournies dans des VM (appele e e rle VM). Dans ce cas, la charge est laisse au client de construire et soumettre au o e cloud les VM contenant ses logiciels. Quant aux applications construites via AppFrabric, lIaaS prend en charge la construction des VM devant les hberger. La gure 7.6 e rsume la vue gnrale de Microsoft Azure. e e e
Figure 7.6 Vue gnrale de Microsoft Azure e e Interoprable e Azure ne dispose daucune interface de collaboration avec dautres plateformes de cloud : ni dAzure vers lextrieur, ni de lextrieur vers Azure. Il pourrait sagir e e dune stratgie de Microsoft empchant les autres plateformes de cloud de conqurir e e e ses clients. Cependant, Azure dispose des mcanismes de collaboration interne entre e le gestionnaire de lIaaS (Windows Azure) et le gestionnaire des applications entreprises (AppFabric). En eet, lAppFabric sadresse au composant Windows Azure (gestionnaire de lIaaS) pour la cration de VM, lobtention des informations de moe nitoring, etc. Cette collaboration est cble et ma ee par les deux composants a e tris Windows Azure et AppFabric. Auto-Rparable e Lauto-rparation est uniquement fournie pour les VM construites par lIaaS. e Autrement dit, il sagit des VM excutants les applications issues de AppFabric. e Dans ce cas, lIaaS duplique lexcution des logiciels en dmarrant deux instances de e e
3. terme utilis par Windows Azure pour dsigner les lments quil administrent e e ee
82
VM pour chacun deux (la VM supplmentaire prend le relais si la premi`re tombe e e en panne). Toutes les oprations dcritures sont eectues dans un emplacement e e e rpliqu partag ne se trouvant par sur les VM. De cette faon, lorsquune instance e e e c de VM est en panne, Windows Azure le redmarre ` partir de son tat davant la e a e panne. Quant aux VM construites par le client, cest a ce dernier dimplanter les mca` e nismes dauto-rparation. e Extensible Nous navons aucune possibilit dtudier cette facette dAzure car elle est proe e pritaire et sa gestion interne est inconnue. e Programmable Aucune politique de consolidation des machines virtuelles sur lIaaS nest mise en place dans Azure. Par contre, il propose des politiques de scalabilit pour les applie cations clientes sous son contrle (c-`-d issues de AppFabric). Elles sont dclenches o a e e via des API par les applications elles-mmes ou par leur propritaire. Cependant, il e e est impossible dintroduire de nouvelles politiques de reconguration dans une application issues de AppFrabric). En ce qui concerne la conguration des applications directement construites dans les VM par le client, Azure permet limplantation de programme (adapters) permettant de les raliser. Ces programmes sont associs a la VM et sexcutent a son e e ` e ` dmarrage. e Adaptable Nous navons aucune possibilit dtudier cette facette dAzure car elle est proe e pritaire et son code source est inaccessible. e Langages ddis e e Microsoft Azure fournit ` travers sa plateforme de dveloppement des langages a e et API de dveloppement dapplications pour son cloud. Ces langages sont des lane gages classiques de dveloppement (java, .Net et C#) et du XML. Le dveloppement, e e lassemblage, linterconnexion des composants logiciels ainsi que leur conguration seectuent par programmation dans AppFabric. Pour les applications non issues de AppFabric, il fournit un outil (Hyper-V Manager ) de construction et de tlchargement dimages de VM vers le cloud. Il utilise ee 4 le format Virtual Hard Disk (VHD) pour la description de limage a construire. ` Ce format est bas sur XML et permet de dcrire le contenu de limage de VM a e e ` construire.
4. VHD est chez Microsoft ce quest OVF (Open Virtual Format) chez VMWare.
` 7.3. SYNTHESE
83
7.2.5
Autres plateformes de cloud
Amazon EC2 Amazon Elastic Compute Cloud (EC2) [61] est une plateforme commerciale de cloud multi-services. Il peut a la fois tre utilis comme espace de stockage de don` e e nes, espace de calculs pour les applications scientiques ou comme centre dhbere e gements dapplications orientes web. Pour ces deux derniers services, le client doit e se servir de machines virtuelles. Il excute des VM dOS de type Linux ou Windows. e Son infrastructure matrielle est rpartie sur plusieurs zones gographiques (deux e e e zones aux USA, une zone en Europe et une zone en Asie) an de proposer aux clients des lieux dexcution proches. Cette pratique permet galement ` Amazon de e e a minimiser les communications rseaux avec lIaaS. e En ce qui concerne lassistance aux clients, Amazon fournit des services web dobservation de charges des VM. Pour des applications web de type J2EE, il fournit des politiques de passage a lchelle (scalabilit). Par contre, il ne pratique aucune po` e e litique de consolidation de VM au niveau de lIaaS. Pour nir, Amazon nimplante pas de mcanisme de dpannage de VM. Il revient au client de limplanter. e e RightScale RightScale [RIGHSCALE] est prsent dans la littrature et par ses fournisseurs e e e comme tant une plateforme de cloud. En ralit, il permet de prsenter de faon e e e e c uniforme lacc`s a plusieurs plateforme de cloud. En eet, il est reli ` plusieurs e ` e a vritables plateformes de cloud (Amazon EC2 par exemple) dont il peut eectuer e des rservations de VM. e Le principal apport de RightScale est sa facilitation du processus dexternalisation de lentreprise vers le cloud. Cette facilitation se limite aux applications web de type J2EE. Il implante toutes les fonctions dadministration au niveau entreprise telles que nous les avons prsentes dans la section 3.2 du chapitre 3. Il fournit des e e moyens de construction de VM, tlchargement dimages VM vers le cloud, dploieee e ment de serveurs J2EE, rparation de VM et de serveurs J2EE, passage a lchelle e ` e des tiers J2EE et monitoring des VM.
7.3
Synth`se e
Ltude des travaux autour de la construction de SAA montre quil existe tr`s e e peu dtudes qui sintressent ` ladministration dapplications appartenant a des e e a ` domaines tr`s varis. La plupart dentre elles sont spciques ` un domaine voir e e e a une application particuli`re. Ltude du syst`me Rainbow [55] (section 7.1.1), qui se e e e rclame de la catgorie des SAA gnriques et exibles, sest rvle non concluante. e e e e e ee En eet, la partie du syst`me quil dnit comme adaptable ne concerne que les e e eecteurs, les sondes et les lments du SR. Or, ces lments ne correspondent pas ee ee aux composants de base constituants le SAA, qui dterminent le degr dadaptabilit e e e dun SAA. Syst`me dadministration autonome adaptable : application au Cloud e
` 7.3. SYNTHESE
84
Face a ce constat, il est dicile denvisager lapplication de ces syst`mes dans le ` e cadre de ladministration des plateformes de cloud, notre proccupation initiale. e Par ailleurs, nous avons pass en revue les plateformes de cloud et tudi leur cae e e pacit dadministration autonome. Le principale constat qui dcoule de cette tude e e e est labsence de la prise en compte (par ces plateformes de cloud) de la collaboration entre les syst`mes dadministration des applications entreprises et le syst`me e e dadministration de lIaaS. Dans le chapitre suivant, nous prsentons donc limplantation dun SAA suivant e les directives que nous avons identies dans le chapitre prcdant. Comme nous le e e e verrons, il sera par la suite utilis pour ladministration dune plateforme de cloud (un e prototype que nous implanterons galement) ainsi que des applications entreprises e quexcutera cette plateforme. Pour nir, la collaboration entre les deux niveaux sera e favorise par cette uniformit des SAA de niveaux IaaS et applications entreprises. e e
Chapitre 8 Contributions : TUNeEngine

Contents
8.1 Mod`le dtaill de TUNeEngine . . . . . . . e e e 8.1.1 Soumission de commandes et Collaboration . 8.1.2 Construction du SR . . . . . . . . . . . . . . 8.1.3 Dploiement . . . . . . . . . . . . . . . . . . e 8.1.4 Conguration, Dmarrage . . . . . . . . . . . e 8.1.5 Rconguration . . . . . . . . . . . . . . . . . e 8.2 Le formalisme ` composants Fractal . . . . . a 8.3 Implantation de TUNeEngine . . . . . . . . . 8.3.1 Le composant TUNeEngine . . . . . . . . . . 8.3.2 Soumission de commandes et Collaboration . 8.3.3 Construction du SR . . . . . . . . . . . . . . 8.3.4 Dploiement . . . . . . . . . . . . . . . . . . e 8.3.5 Excution de programmes dadministration . e 8.4 Synth`se . . . . . . . . . . . . . . . . . . . . . . e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 87 87 89 90 91 92 94 94 95 96 98 100 102
Les syst`mes Jade[26] et TUNe (section 5 du chapitre 5) ont t prcurseurs en e ee e ce qui concerne le dveloppement des SAA ` vocation gnrique. Cependant, les e a e e dicults observes dans lutilisation de ces syst`mes nous ont conduit ` proposer e e e a dans le chapitre 6, une nouvelle approche dimplantation de SAA hautement exible et adaptable. Cette approche identie les besoins que doit remplir un tel syst`me. e Elle dbouche ensuite sur un mod`le architecturale bas sur les composants. Dans e e e ce chapitre nous prsentons une implantation de ce mod`le que nous baptisons : e e TUNeEngine. Reprenant la base de code de TUNe, limplantation de TUNeEngine est bas sur e le formalisme a composants 1 Fractal [31]. `
1. An dviter toute ambigu e de comprhension avec le mod`le que nous prsentions e t e e e dans le chapitre 6, nous nutilisons pas lexpression mod`le ` composants Fractal mais e a plutt formalisme ` composants Fractal. o a
` 8.1. MODELE DETAILLE DE TUNEENGINE
86
Figure 8.1 Mod`le dtaill de TUNeEngine e e e Ce chapitre est organis de la faon suivante. Nous commenons par la prsentae c c e tion du mod`le architectural dtaill de TUNeEngine. Ce mod`le est un enrichissee e e e ment de celui que nous avons prsent dans le chapitre 6. Ensuite, nous prsentons e e e de faon succincte un aperu du formalisme Fractal sur lequel est bas limplantation c c e de TUNeEngine. Nous terminons ce chapitre par la prsentation de limplantation e Fractal du mod`le dtaill de TUNeEngine. e e e
8.1
Mod`le dtaill de TUNeEngine e e e
Dans la section 6.2.2 du chapitre 6, nous avons prsent le mod`le architectural e e e que devra suivre limplantation de TUNeEngine. Nous le revisitons en lenrichissant des composants les plus basiques que doit implanter TUNeEngine. La gure 8.1 prsente ce nouveau mod`le enrichi. An de justier les composants de ce mod`le, e e e explorons le processus dadministration dune application quelconque par un SAA. Ce processus va de la soumission de lapplication a administrer au SAA, jusquau ` suivi de son excution en passant par son dploiement. Notons que lexploration de e e ce processus nous sert uniquement de l conducteur dans notre prsentation. e
87
8.1.1
Soumission de commandes et Collaboration
La premi`re tape dans le processus dadministration autonome est la soumission e e des politiques dadministration au SAA par ladministrateur ou un syst`me externe. e Ces politiques contiennent aussi bien la description des lments ` administrer (maee a chines et logiciels) que les politiques de reconguration. De plus, le SAA peut initier la communication avec lextrieur dans certaines situations. Par exemple lorsquil e sollicite, par collaboration, les services dun SAA externe pour laccomplissement dune tche. En conclusion, on peut parler dun dialogue entre un acteur externe a (un administrateur ou un SAA) et le SAA. Le composant External Communicator de notre mod`le permet de raliser ce dialogue. e e En fonction du type de dialogue, lExternal Communicator sappuie sur deux composants internes : lInterface de Ligne de Commandes (CLI) et le Collaborator . Le premier soccupe de la communication avec des acteurs humains tandis que le second soccupe de la collaboration/interoprabilit avec dautres SAA. e e Les commandes mises/reues sont de dirents ordres. Il peut sagir de la soue c e mission au SAA de lenvironnement a administrer, des politiques dadministration ` a appliquer, des ordres de dploiement/undploiement, etc. Pour distinguer ces re` e e qutes, le composant External Communicator est muni dun interprteur de e e commandes (CmdInterpreter ). Ce dernier a galement pour rle de vrier la ` e o e conformit syntaxique et smantique des commandes (autrement dit si elles seront e e comprhensibles par le SAA). En cas de conformit, le CmdInterpreter fait appel e e au composant du SAA capable de raliser lopration contenue dans la commande : e e la construction du SR par exemple. Adaptabilit e Ladaptation du composant Collaborator peut permettre au SAA dimplanter un nouveau protocole de communication avec les SAA externes. Dans le cadre de limplantation de TUNeEngine par exemple, nous utilisons un mcanisme bas sur e e RMI pour la collaboration avec des SAA externes (voir la section 8.3.2). Le remplacement du composant Collaborator dans TUNeEngine permettra dimplanter par exemple une collaboration ` base du protocole REST tels que pratiques dans les a e plateformes de cloud comme Eucalyptus ou OpenNebula. Ladaptation du composant CmdInterpreter permet de modier la syntaxe de soumission des commandes au SAA. Au lieu dune soumission de commandes ligne pas ligne, le SAA pourra permettre lexpression de plusieurs commandes sur la mme e ligne et spares par des points virgules par exemple. e e
8.1.2
Construction du SR
Une fois les lments a administrer soumis au SAA, celui-ci doit construire en ee ` son sein une reprsentation de ces lments : cest le rle du SR Manager dans e ee o notre mod`le. Il sappuie sur trois sous composants : le Parser , le Wrapper et le e Syst`me dadministration autonome adaptable : application au Cloud e
88
SR. Le Parser a pour rle didentier a partir de la soumission de ladministrateur : o ` la liste des lments a administrer par le SAA, leurs proprits, ainsi que les relations ee ` ee entre eux. Il peut tre organis en plusieurs Parser s an de prendre galement en e e e compte les lments comme les programmes dadministration. Pour chaque lment ee ee identi, le Parser demande au Wrapper de construire le reprsentant de cet le e ee ment dans le SAA. Construire le reprsentant dun lment dans le SAA signie encapsuler son e ee comportement dans une structure de donnes qui facilitera son administration par e le SAA. Nous appelons galement wrapper ce reprsentant. Pour le construire, le e e Wrapper utilise les informations fournies par le Parser . Les lments construits ee peuvent tre des logiciels, des machines, des liaisons, des lments constituant un e ee programme de reconguration, etc. Nous proposons dans notre mod`le, lutilisae tion du formalisme a composants Fractal pour la construction des wrappers. Comme ` nous le verrons ci-dessous, ce choix de Fractal ne remet pas en cause ladaptabilit e du Wrapper . En eet, construire un reprsentant dans le SAA revient a construire e ` a terme une architecture logiciel. Cette fonctionnalit est parfaitement remplie par ` e Fractal. Utiliser un formalisme ou un moyen autre que Fractal revient a utiliser/im` planter un formalisme quivalent. En ralit, le choix port sur Fractal est favoris e e e e e par ses API qui rpondent parfaitement a nos attentes dans la construction des ree ` prsentants. Notons que limplantation du Wrapper dcidera du cblage ou non e e a des types dlments dans le SAA (voir le crit`re duniformisation de la section 6.1.1 ee e du chapitre 6). Dans le cadre du syst`me TUNeEngine, nous utilisons (comme nous e lavons prconise) une unique structure de donnes pour lencapsulation de tout e e e type dlments. ee Pour nir, le SR dans notre mod`le joue deux rles. Il reprsente dune part e o e la structure de donnes contenant lensemble des reprsentants des lments admie e ee nistrs et programmes de reconguration dans le SAA. Nous reprenons lexpression e de Syst`me de Reprsentation introduit par le syst`me TUNe pour le dsigner. e e e e Dautre part, il fournit le moyen dintrospection des wrappers et du syst`me de e reprsentation. Il sera sollicit par les autres composants du SAA lorsquils voue e dront avoir des proprits, des fonctions ou autres informations du reprsentant. Par ee e exemple, le Wrapper fera appel ` lui pour lobtention de la rfrence Fractal des a ee wrappers de deux lments lors de la construction dune liaison ces deux lments. ee ee Adaptabilit e Ladaptation du Parser permet au SAA de prendre en compte de nouveaux langages de description des besoins dadministration (lments et programmes de reee conguration). On pourra par exemple prendre en compte lADL du syst`me TUNe e qui est bas sur les diagrammes de classe UML. e En ce qui concerne le Wrapper , son adaptation permet par exemple a ladminis` trateur dexprimer un nouveau moyen dencapsulation dans le SAA ou dassocier un comportement particulier ` un reprsentant dun lment administr. Pour illustrer a e ee e le premier cas, prenons un exemple dans lequel ladministrateur dsire encapsuler ses e lments dans une base de donnes. Compte tenu du fait que nous adoptons Fractal ee e
89
comme la base de construction de wrappers dans le SAA (ce qui nempche lutilisae tion dautres moyens), ladaptation du Wrapper construira donc deux wrappers : un composant Fractal et une entre dans la base de donnes. Associ a cette adaptae e e` tion du Wrapper , le composant SR devra tre galement adapt. En eet, il devra e e e associer aux API dintrospection des composants Fractal (ce que permet Fractal) le moyen daccder aux informations concernant ` la fois le composant Fractal lui mme e a e (le wrapper de base), mais galement lentre correspondant a ce composant dans e e ` la base de donnes (nouvelle structure dencapsulation). En somme, lutilisation de e Fractal dans notre mod`le sert dinterfaage lorsque que la mthode dencapsulation e c e est adapte. e Quant au second cas (ladaptation du Wrapper pour lassociation dun comportement particulier a un lment), il permet par exemple de reproduire le choix ` ee dimplantation du syst`me TUNe dans lequel il associe aux supports dexcution e e (machines physiques), un comportement dirent de celui des lments logiciels. La e ee seul dirence ici est le non cblage de cette dirence dans le SAA. e a e Pour nir, ladaptation du SR permet, comme nous lavons voqu dans ladape e tation du Wrapper , denrichir les API dintrospection de Fractal.
8.1.3
Dploiement e
Apr`s la reprsentation interne des lments administrs, la phase de dploiement e e ee e e marque le dbut du processus dadministration proprement dit. Il est assur par le e e composant Deployment Manager . Ce dernier ralise le dploiement en plusieurs e e phases internes a savoir : ` le choix du support dexcution (SE) : ralis par le composant NodeAllocae e e tor . Il dtermine le lieu dexcution de llment en cours de dploiement. Il e e ee e se sert du SR an davoir les informations sur les SE disponibles et retourne ensuite un ou plusieurs SE en fonction des besoins de llment dploy. ee e e initialisation du SE : a laide dun moyen (ssh, rsh, etc.) et des informations ` (nom de connexion, mot de passe, etc.) de connexion fourni par le reprsentant e du SE dans le SR, le composant Deployer initialise le SE. Cette initialisation permet au SAA davoir acc`s et main mise sur le SE distant. e Lobtention et linstallation des binaires : ralises par le composant Binary e e Manager , il rend disponible les binaires et chiers ncessaires pour lexcution e e de llment dploy sur le SE distant (exemple de linstallation des packages ee e e sous Linux dans le rpertoire /var/cache/apt/archives/ ). Il dispose ensuite les e chiers selon larborescence requise par linstallation de llment en cours de ee dploiement (dans lexemple des packages Linux, il sagit du dsarchivage des e e chiers vers les rpertoires requis). e A linverse, notons que les composants prcdemment prsents ralisent galement e e e e e e lopration de dsinstallation. Le NodeAllocator lib`re le SE apr`s son nettoyage e e e e par le Binary Manager . Adaptabilit e
90
Ladaptation du NodeAllocator permet dimplanter plusieurs politiques dallocation ou de libration de SE dans le SAA. Par exemple, on pourra implanter e lallocation par tourniquet ou round-robin utilise par le syst`me TUNe. e e Quant au Deployer , prenons lexemple de ladministration des quipements e rseaux comme les imprimantes. Ladaptation du Deployer permettra de ne pas e dployer le reprsentant du SAA sur lquipement rseau (car impossible) comme e e e e on le fera dans le cadre de ladministration dune machine physique. Dans ce cas, le Deployer pourra par exemple se contenter dun dploiement de ce reprsentant e e sur la machine dadministration, qui fera par la suite un contrle distant selon le o protocole de communication fourni par lquipement. e Pour nir, ladaptation du Binary Manager permettra au SAA de prendre en compte direntes mthodes dobtention de binaires : par copie distant, par te e e lchargement web comme cest le cas avec linstallation des syst`me dexploitation, e e etc.
8.1.4
Conguration, Dmarrage e
Les phases de conguration et de dmarrage suivent celle du dploiement. Etant e e donn quelles sont de mme nature (excution de programme), le SAA utilise le e e e mme composant (Policies Manager ) pour les raliser. Il se met en marche lorse e quil reoit un ordre venant de lExternal Communicator ou de lEvent Mac nager . Lexcution dun programme dadministration seectue en deux tapes : e e linterprtation du programme : ralise par le composant ProgramInterpree e e ter . Ce dernier utilise une partie du SR reprsentant le programme ` excuter. e a e Il identie dans le programme la liste des actions a excuter. Son implantation ` e dpendra du langage dadministration choisi par ladministrateur. e lexcution des actions identies dans ltape prcdente : les actions identie e e e e es sont excutes par le composant Executor . Pour chaque action, lExecutor e e e introspecte le SR a la recherche est lments concerns par laction. Il fait ` ee e ensuite appel au composant RemoteExecutor qui implante le moyen dexe cution a distante des actions sur le logiciel ou le SE dans lenvironnement rel. ` e
Adaptabilit e Ladaptation du ProgramInterpreter permet de changer le langage dexpression des programmes de reconguration. On pourra ainsi avoir des programmes JAVA ou encore un langage tel que RDL du syst`me TUNe. e Ladaptation de lExecutor permet par exemple dimplanter une mthode dexe e cution daction dans laquelle le lieu dexcution des actions est soit local (sur la e machine dadministration), soit distant (sur le SE du logiciel concern). En eet, des e actions contenues dans les programmes de reconguration peuvent concernes des e modications de larchitecture du SR. Dans ce cas, ces actions doivent tre ralises e e e sur la machine dadministration (car cest elle qui contient le SR). Syst`me dadministration autonome adaptable : application au Cloud e
91
Pour nir, ladaptation du RemoteConnector permet de changer le mcae nisme dexcution a distance des fonctions dadministration. Il pourra utiliser du e ` RMI comme cest le cas dans TUNe ou encore une excution basique base sur un e e appel de commandes a distance avec du SSH. `
8.1.5
Rconguration e
Apr`s le dmarrage des lments, la suite de ladministration consiste en leur e e ee suivi dans le but davertir le SAA de leur tat courant. La ralisation de cette tche e e a nappartient pas au SAA. En eet, elle dpend de limplantation de chaque lment e ee administr (vu comme une bo noire). Il revient donc a ladministrateur dintroe te ` duire parmi les lments ` administrer, des logiciels (observateurs) qui joueront ce ee a rle. Les lments administrs (y compris les observateurs), ont la mme considrao ee e e e tion de la part du SAA. Par contre, il revient au SAA de mettre en place un moyen de communication entre chaque lment administr et lui. ee e Dans cette situation, la communication est initie par llment administr. Elle e ee e seectue de son support dexcution (SE) vers la machine dexcution du SAA. e e Le composant Event Receiver est charg dimplanter ce mcanisme de commue e nication. Il est compos de deux sous composants : lEvent Channel et lEvent e Driver . Le premier est utilis par llment administr, sexcutant sur son SE, e ee e e pour mettre ses vnements. Le second implante la mthode de transport dvnee e e e e e ments des SE de lenvironnement vers la machine dadministration. LEvent Driver communique lvnement reu au niveau de la machine dadministration a lEvent e e c ` Manager . Ce dernier implante le module dcisionnel du SAA. Son rle est de choie o sir en fonction des vnements reus, les programmes dadministration ` excuter e e c a e pour rpondre aux signes mis par lenvironnement encours dadministration. Pour e e cela, il sappuie sur ltat courant du SR. Apr`s dcision des programmes de recone e e guration a excuter, lEvent Manager fait appel au Policies Manager pour ` e leur excution. Le procd dexcution celui que nous avons dcri dans la section e e e e e prcdente. e e Adaptabilit e Ladaptation de lEvent Channel permet de modier la mthode dobtention e dvnements ` partir de lexcution dun lment sur son SE. e e a e ee Quant ` lEvent Driver , son adaptation permet dimplanter par exemple le a mcanisme de transport dvnements par le biais dun serveur de messages tel que e e e JMS. Ainsi, lEvent Manager sabonnera au serveur JMS an dtre inform des e e vnements survenus. e e Pour nir la modication de lEvent Manager permettra a ladministrateur ` de produire un mcanisme de gestion des vnements avanc comme la technologie e e e e CPE [71] (Complex Event Processing). Par exemple, il pourra prendre prendre en compte des vnements estampiller de linstant denvoie dapparition de lvnement e e e e an de grer des vnements temporels. Ceci lui permet par exemple dimplanter e e e
` 8.2. LE FORMALISME A COMPOSANTS FRACTAL
92
diverses mthodes de stockage ou dapprentissage du comportement de lapplication e en cours dadministration.
8.2
Le formalisme ` composants Fractal a
Comme nous lavons voqu au debut de ce chapitre, le mod`le de SAA que nous e e e utilisons repose sur le formalisme Fractal. Ce dernier est bas sur trois notions : les e composants, les interfaces, les liaisons et les contrleurs [32]. Un composant est une o entit excutable. Fractal distingue deux types de composants : les composants prie e mitifs et les composants composites. Les composants primitifs encapsulent une unit e excutable dcrite dans un langage de programmation tandis que les composants e e composites sont des assemblages de composants. Dans ce contexte, un composant Fractal peut appartenir ` plusieurs composants composites : on parle de composant a partag. e Une interface est un point dacc`s ou de sortie sur un composant. Fractal introe duit en eet deux catgories dinterfaces : e Interface serveur : il sagit dun point dacc`s au composant. Un composant e dnissant une interface serveur implique que ce composant fournit les sere vices implants par cette interface. Dans le cas dun composant primitif, le e code source du composant doit contenir limplantation de linterface. Quant aux composites, Fractal ne permet pas de leur associer des codes sources. Interface cliente : il sagit dun point de sortie du composant. Un composant dnissant une interface cliente signie que ce composant requiert les services e implants par cette interface. Ainsi, lexcution de ce composant ncessite au e e e pralable sa liaison avec un autre implantant ce service. e Notons que dans le cas des composants composites, Fractal associe automatiquement a chaque interface serveur (respectivement cliente), une interface cliente (respec` tivement interface serveur) qui nest visible que des composants interne au composite : on parle dinterfaces complmentaires (voir la gure 8.2(a)). Ces derni`res e e peuvent tre lies aux interfaces des composants internes. e e Une liaison est un canal de communication tabli entre les composants Fractal. e De la mme faon que les composants, Fractal distingue deux types de liaisons : prie c mitives et composites. Une liaison primitive est une liaison entre deux composants du mme espace dadressage (contenu dans le mme composite) via leurs interfaces e e cliente et serveur. Ce type de liaison est implante par des pointeurs ou des mcae e nismes propres au langage de programmation comme les rfrences Java. Une liaison ee composite est une liaison implante par un composant ou une cha de plusieurs e ne composants. Une liaison peut tre multiple dans le sens o` une interface cliente peut e u tre lie ` plusieurs interfaces serveurs. e e a Les contrleurs constituent la membrane des composants. Ils ont pour rles dexo o poser les services du composant, dintercepter les messages en direction du compoSyst`me dadministration autonome adaptable : application au Cloud e
` 8.2. LE FORMALISME A COMPOSANTS FRACTAL
93
Figure 8.2 Exemple darchitecture Fractal sant et galement dintrospecter le composant. Fractal nimpose pas dimplantation e pour la dnition des contrleurs, ce qui permet dexercer un contrle adapt sur e o o e les composants. Cependant, il fournit quelques exemples de contrleurs utiles qui o peuvent tre combins et tendus : e e e Le contrleur dattributs (AttributeController ) : il permet de congurer les o attributs dun composant. Le contrleur de liaisons (BindingController ) : il permet dtablir ou de o e rompre une liaison primitive a partir du composant dnissant linterface ` e cliente. Le contrleur de contenu (ContentController ) : il permet de lister, dajouter o et de retirer des sous-composants dun composant composite. Le contrleur de cycle de vie (LifeCycleController ) : il permet de contrler o o le cycle de vie du composant qui poss`de le contrleur. Le cycle de vie dun e o composant est reprsent par un automate a deux tats : started (le composant e e ` e est dans un tat dmarr) et stopped (le composant est dans un tat darrt). e e e e e Le contrleur permet de passer dun tat ` lautre. Il est le principal artisan o e a dans les opration de dajout/retrait de composants dune architecture dj` en e ea cours dexcution. e La gure 8.2 dcrit les direntes entits mises en jeu dans une architecture e e e Fractal. Le rectangle noir reprsente le contrle du composant alors que lintrieur e o e du rectangle reprsente le contenu du composant. Les `ches correspondent aux e e liaisons tandis que les formes en T attaches aux rectangles correspondent aux e interfaces du composant. Les interfaces de contrle sont reprsentes par des lettres : o e e c pour composant, lc pour le contrleur de cycle de vie, bc pour le contrleur de o o liaisons, cc pour le contrleur de contenu et ac pour le contrleur dattributs. Les o o interfaces serveurs (respectivement cliente) sont disposes a gauche (respectivement e ` a droite) du rectangle noir. ` Lapplication dcrite dans la gure 8.2 se compose de deux composants primitifs : e Client et Server. Ces composants sont lis par une liaison entre une interface client e s du composant Client et une interface serveur s du composant Serveur .
8.3. IMPLANTATION DE TUNEENGINE
94
8.3
Implantation de TUNeEngine
Comme nous lavons voque en prambule de ce chapitre, limplantation de e e e TUNeEngine utilise Fractal (limplantation Julia [30]). Il est implant dans un come posant composite nomm TUNeEngine. Ce composant contient tous les composants e constituants le syst`me, y compris les lments administrs. De faon gnrale, tous e ee e c e e les composants primitifs dnissent une interface de gestion dattributs (ou parae m`tres). Cette interface tend linterface AttributeController prdnie par Fractal. e e e e TUNeEngine sexcute sur une machine que nous appellerons la machine dade ministration. Cest ` partir de cette machine quil coordonnera toutes les oprations a e dadministration. Dans ce chapitre, nous prsentons limplantation TUNeEngine du mod`le dtaill e e e e que nous avons prsent ci-dessus.Compte tenu du caract`re adaptable de notre moe e e d`le, limplantation de ses composants dans cette version de TUNeEngine permet e de raliser toutes les oprations dadministration que permettait le syst`me TUNe. e e e Dans un premier temps, nous prsentons limplantation du composant composite e TUNeEngine. Ensuite, suivant le mme l conducteur que celui adopt dans la sece e tion 8.1, nous prsentons limplantation de chaque composant de TUNeEngine. Pour e illustration, nous associerons ` chaque section (si ncessaire) une gure rsumant la a e e prsentation faite dans la dite section. Cette gure prsentera le contenu du come e posite TUNeEngine conformment a la prsentation, associ parfois au contenu de e ` e e lenvironnement rel dexcution. Par souci de lisibilit, la gure associe a une sece e e e ` tion X ne reprendra pas obligatoirement tous les lments des gures des sections ee qui lui prc`dent. e e
8.3.1
Le composant TUNeEngine
Lensemble des composants du syst`me TUNeEngine sont contenus au sein dun e composant composite appel TUNeEngine. Ce dernier est vu de lextrieur comme e e le syst`me TUNeEngine. Il dnit deux interfaces serveurs. La premi`re g`re les e e e e param`tres dexcution du SAA. Cette interface est une extension de linterface Ate e tributeController 2 que fournit Fractal. Ces param`tres seront ensuite utiliss pour e e linitialisation des composants internes de TUNeEngine. En eet, compte tenu de son statut de reprsentant de TUNeEngine, son dmarrage entra e e nera celui de ses sous-composants. Or ces derniers ont besoin de certains param`tres pour leur initialie sation. Cest le cas par exemple du composant CLI qui requiert pour son dmarrage e le niveau de verbosit indiquant le degr de dtails avec lequel TUNeEngine doit re e e e pondre aux requtes des administrateurs. e La deuxi`me interface est le dmarreur de TUNeEngine. Elle dmarre tous les e e e composants de services et ne rend la main qu` larrt de ces derniers. Compte tenu a e
2. En eet, linterface de contrle AttributeController nest pas prdnie dans Fractal o e e pour les composites
95
de son caract`re de composant composite, TUNeEngine contient un composant prie mitif TUNeEngineDelegate qui implmente rellement ses deux interfaces serveurs. e e Ce composant est reli a tous les autres sous-composants de TUNeEngine an de e` leur communiquer leurs param`tres dinitialisation. e Le composant TUNeEngineDelegate est implant par une classe Java dnissant e e une interface AttributeController et Thread.
8.3.2
Soumission de commandes et Collaboration
Limplantation du composant CLI dans TUNeEngine obtient les requtes de e ladministrateur via une socket rseau et fournit les rsultats via une console locale. e e Les param`tres dinitialisation rseau (nom de la machine dexcution et numro de e e e e port) et le niveau de verbosit lui ont t fournis lors du dmarrage de TUNeEngine. e ee e Comme le composant TUNeEngineDelegate, il dnit deux interfaces. La premi`re e e g`re les param`tres dinitialisation tandis que la seconde dmarre le dmon dcoute e e e e e de requte et dacheminement de rsultats. e e Quant au composant Collaborator , nous utilisons le mcanisme de communie cation ` distance RMI pour eectuer la collaboration avec dautres SAA. Ce ma e canisme ncessite la prsence dun annuaire denregistrement dobjets RMI dans le e e rseau. Ainsi, le dmarrage de Collaborator requiert plusieurs param`tres dinie e e tialisation dont : le nom de linstance de TUNeEngine en cours dexcution (TUe NeEngineName), le nom DNS de la machine dexcution, le nom DNS de lannuaire e denregistrement RMI et son numro de port. Il implante une interface RMI dont e lexportation (` travers lannuaire RMI) permet a un SAA distant de soumettre a ` des requtes ` TUNeEngine. Lenregistrement de cette interface se fait au dmare a e rage sous le nom TUNeEngineName. Quelque soit le composant de communication externe (Collaborator ou CLI ), les natures des requtes mises sont identiques. e e Toute requte reue est soumise au CmdInterpreter avec qui ils sont lis a travers e c e ` une interface cliente. N.B. : Dans une volution future, nous envisageons a la place e ` de la technologie RMI utilise pour la collaboration, lutilisation des web services e bass sur WSDL. e Dans sa version actuelle, le composant CmdInterpreter ne prend en compte que les requtes de la forme : une ligne quivaut a une requte. La commande est e e ` e reprsente par le premier mot de la ligne et le reste correspond aux param`tres de la e e e commande. Son adaptation permettra de modier la syntaxe de soumission de commandes au SAA. Voici la liste de quelques commandes prises en compte actuellement par le CmdInterpreter : Larrt de TUNeEngine : entra larrt de tous les services internes. e ne e La soumission dun environnement a administrer : entra lappel du compo` ne sant composite SR Manager ; Le dploiement/undploiement : entra lappel du composant Deployment e e ne Manager ; Lexcution dune politique de reconguration : entra lappel du composant e ne Policies Manager ;
96
etc. Lenrichissement de cette liste de commandes se fait par ajout, dans le composant composite TUNeEngine, des composants remplissant les services requises par les commandes qui seront ajoutes. La gure 8.3 rsume limplantation Fractal de lene e semble TUNeEngine a ce stade. `
Figure 8.3 Soumission de commandes et Collaboration
8.3.3
Construction du SR
Cette tape reprsente le cur de TUNeEngine. En eet, elle permet de construire e e la structure de donnes contenant tous les lments administrs et dadministration e ee e (machines, logiciels, et les programmes dadministration). Dans notre implantation, ces lments sont fournis a TUNeEngine de deux faons : sous forme dADL 3 Fractal ee ` c ou par des composants Fractal. Cette dernier mthode consiste de la part de lade ministrateur (averti) a construire larchitecture Fractal de ses lments et ensuite ` ee les linsrer dans le composite TUNeEngine. Dans les deux cas, les API Fractal ime plantent tout ou partie des rles des composants Parser , Wrapper et SR. o
Lorsque les descriptions de lenvironnement et des programmes de reconguration sont fournies par ADL, le Parser est enti`rement implant par appel aux API e e Julia de Fractal. Dans le cas o` les composants sont directement fournis en Fracu tal, le Parser ne joue aucun rle. En ce qui concerne le Wrapper , il implante o le comportement gnrique et adaptable (voir ci-dessous) des lments du SR et e e ee obtient des administrateurs des comportements spciques. Ladministrateur foure nit une classe Java implantant toutes les fonctions dadministration de llment ` ee a encapsuler. Cette classe implante deux types de mthodes dencapsulation : la pree mi`re sapplique aux lments administrs tandis que la seconde sapplique aux proe ee e grammes dadministration. Quant au SR, une partie de son implantation est fournie
3. Architecture Description Language
97
par les API Fractal. Son implantation est par la suite complte par la ralisation ee e des liaisons Fractal entre les lments encapsuls et les composants encapsulant les ee e services de TUNeEngine (Deployer , Policies Manager , et Event Manager ). Encapsulation des lments administrs ee e Chaque lment administr est encapsul dans un composant primitif. Dans ceree e e tains cas, les lments appartenant ` une mme famille (selon ladministrateur) ee a e peuvent tre regroups dans des composants composites. Par exemple, soit une e e application a administrer constitue de plusieurs modules. Soit un module conte` e nant plusieurs logiciels. Dans cet exemple, TUNeEngine permet lencapsulation du module ` lintrieur dun composant composite contenant les composants primitifs a e encapsulant les logiciels de ce module. Le mme raisonnement peut galement tre e e e appliqu pour un cluster (dont le Wrapper fournit les procdures dadministration) e e contenant plusieurs SE. Dans tous les cas, les interfaces de gestion des composants sont identiques (crit`re duniformit de notre SAA). e e Le Wrapper associe ` chaque composant les interfaces suivantes : une interface a serveur de gestion des attributs du composant (les param`tres de llment encape ee sul), deux interfaces cliente et serveur (le nombre dinterfaces pouvant tre modi e e e par adaptation du Wrapper ) lui permettant dtre reli a dautres composants ; une e e` interface serveur dexcution de fonctions dadministration (qui se trouvent dans les e programmes dadministration) et une dinterface serveur deploy lui permettant dtre dpoy/undeploy. Limplantation de cette derni`re est fournie par ladminise e e e e trateur et sera excut par le composant Deployer pendant la phase de dploiement. e e e Cependant, dans son implantation actuelle dans TUNeEngine, le Wrapper fournit une implantation basique reprenant celle du syst`me TUNe. Nous revenons sur cette e interface dans la section suivante. Notons que limplantation de toutes ces interfaces par le Wrapper nest utilise quen comportement par dfaut. En eet, ladminise e trateur est capable de fournir par adaptation des comportements spciques aux e lments en cas de besoins. Par exemple, il fournira en fonction de la nature dun SE ee prsent dans son architecture, dirents moyens de connexion sur ce SE (utilisable e e pendant les oprations de dploiement). e e Encapsulation des programmes dadministration Les programmes dadministration sont regroups dans des composites nomms e e AunonomicManager. Un AutonomicManager peut contenir plusieurs programmes dadministration. Le Wrapper introduit dans chaque AunonomicManager un composant primitif (le Dispatcher ) charg de choisir le programme dadministration ` e a excuter (voir la section 8.3.5 pour plus de dtails). Dans limplmentation actuelle de e e e TUNeEngine, les programmes dadministration sont des automates a tats. Chaque è tat est un composant primitif implantant laction a eectuer. Ce composant de ` e nit une interface serveur run et deux interfaces clientes sr et next. Linterface run permet de dclencher lexcution de laction. Cette interface doit tre fournie par e e e ladministrateur. Limplantation de laction a la possibilit daccder au SR via line e terface sr de ltat. En eet, certaines actions de reconguration peuvent entra la e ner modication du SR ou encore ncessiter la rcupration des param`tres de certains e e e e lments du SR. Pour nir, linterface next permet de relier ltat aux autres. Elle ee e
98
donne ainsi le sens de progression de lexcution de lautomate. e Chaque automate contient un point dentre (ltat initial) et un point de sortie e e (ltat nal). Ltat initial renseigne le Dispatcher (via un attribut) des vnements e e e e pour lesquels lautomate quil reprsente peut tre excut. Nous prsentons dans e e e e e la section 8.3.5, la description de lexcution des programmes dadministration dans e TUNeEngine. La gure 8.4 rsume lorganisation des composants Fractal dans le SR et dans e le composant TUNeEngine. Les composants de service de TUNeEngine ne sont pas tous reprsents dans cette gure. Ils sont symboliss par un unique composant que e e e nous appelons Service.
Figure 8.4 Construction du SR
8.3.4
Dploiement e
Le composant Deployment Manager de notre mod`le est implant par un e e composant composite de mme nom dans TUNeEngine. Ce composant implante a e ` la fois les fonctionnalits de dploiement et de undploiement. Il dnit deux intere e e e faces serveurs (deploie et undeploie) et une interface cliente (sr ). Linterface deploie dmarre le processus de dploiement dun ou des lments du syst`me de reprsene e ee e e tation. Quant ` linterface undeploie, elle eectue lopration inverse. Linterface sr a e permet de relier le composant Deployment Manager au SR an quil puisse y Syst`me dadministration autonome adaptable : application au Cloud e
99
retrouver tous les lments administrs. ee e Dans notre implantation, le Deployer ne ralise pas proprement dit les ope e rations de dploiement et de undploiement. Son rle est de prparer, orchestrer, e e o e et complter ces oprations. Soit E un lment ` dployer : voici la ralisation du e e ee a e e dploiement de E dans TUNeEngine. Lordre de dploiement de E contient plusieurs e e informations : llment a dployer, son SE ou les caractristiques que doivent respecee ` e e ter le SE choisi par NodeAllocator . Lorsque le SE nest pas fourni, le Deployer sollicite le composant NodeAllocator an que celui-ci lui fournisse un SE selon les caractristiques fournies dans lordre de dploiement. Pour cela, le composant e e NodeAllocator acc`de au SR via linterface sr du Deployment Manager . Noe deAllocator implante deux interfaces serveurs : allocate (pour lallocation de SE) et free (pour la libration dun SE). Limplantation de ces deux interfaces (qui repre e sente les politiques dallocation et de libration de SE) est enti`rement fournie par e e ladministrateur. Dans son implantation actuelle, TUNeEngine fournit une politique dallocation base sur lalgorithme de tourniquet. Le Deployer communique avec e le NodeAllocator via ces deux interfaces. Une fois le SE choisi par le NodeAllocator ou fourni dans lordre de dploiee ment, le Deployer sassure que le SE estest pralablement dploy. Dans le cas e e e contraire, il dmarre son processus de dploiement. Concr`tement, les oprations de e e e e dploiement et undploiement proprement dites sont ralises par les lments ade e e e ee ministrs eux-mmes. Comme nous lavons prsent dans la section prcdente, le e e e e e e Wrapper ajoute a chaque lment encapsul deux interfaces serveurs pour raliser ` ee e e ces tches. a Concernant le SE, limplantation particuli`re de son processus de dploiement e e consiste en : Dploiement (comme ctait dj` le cas avec le syst`me TUNe) sur le SE des e e ea e binaires et codes sources ncessaire pour excuter le reprsentant de TUNeEne e e gine : RemoteLauncher. Ce dernier est le bras de TUNeEngine sur le SE. Dmarrage sur le SE du RemoteLauncher et enregistrement de sa rfrence e ee RMI dans le registre RMI dmarr sur la machine dadministration TUNeEne e gine. Le reprsentant du SE dans le SR contient le moyen de copie et dexcution a dise e ` tance de commandes sur le SE lorsque celui-ci ne contient encore aucun reprsentant e de TUNeEngine (RemoteLauncher ). En ce qui concerne les autres lments faisant lobjet du dploiement, le processus ee e de dploiement est le suivant : e Dploiement (comme ctait dj` le cas avec le syst`me TUNe) sur le SE de e e ea e llment a dployer, des binaires et codes sources ncessaires pour excuter ee ` e e e le reprsentant de TUNeEngine de cet lment son SE : RemoteWrapper. Ce e ee dernier est charg dexcuter sur le SE les futures actions de reconguration. e e Dmarrage du RemoteWrapper par le RemoteLauncher. Ce dernier enregistre e galement la rfrence RMI du RemoteWrapper dans lannuaire RMI sur la e ee machine dadministration. Nous verrons dans la section suivante que cette rfrence est utilise plus tard pour lexcution ` distance des actions de reee e e a conguration.
100
Dmarrage du dmon jouant le rle dEvent Channel sur le SE. Nous verrons e e o dans la section suivante limplantation de ce dmon. e Apr`s le dploiement et le dmarrage des reprsentants, le processus de dploiement e e e e e des lments a administrer se droule comme dcrit dans la section 8.1.3. ee ` e e Le composants Binary Manager dans notre mod`le nest pas implant sous e e forme de composant Fractal. Il est implant comme mthodes Java dans la classe e e dimplantation (fournie par ladministrateur) des interfaces deploie et undeploie. Dans son comportement par dfaut (fourni par TUNeEngine et adaptable), le de e ploiement (respectivement le undploiement) se limite ` la copie (respectivement la e a suppression) de chiers de la machine TUNeEngine vers un rpertoire particulier sur e le SE. Il sagit du comportement que proposait le syst`me TUNe. e Inversement, dans le cadre du undeploiement, le Deployer sassure que llment ee undeploy nhberge plus dlments. Il dfait galement la liaison entre llment e e ee e e ee undeploy et son SE. e La gure 8.5 rsume limplantation Fractal de ces oprations ainsi quune vue e e globale de lenvironnement denvironnement apr`s cette tape. Les lments du SR e e ee dans cette gure sont symboliss par un lment symbolique nomm SR. On peut e ee e observer sur cette gure la relation entre chaque logiciel (pouvant jouer le rle de o sonde) et lEvent Channel . Remarquons galement que comme les logiciels, un SE e (reprsent par son RemoteLauncher ) peut se voir associer un logiciel de sonde qui e e communiquera son tat ` lEvent Driver . Pour nir, les rfrences des Remotee a ee Wrapper et RemoteLauncher sont enregistres dans lannuaire RMI de la machine e dadministration.
8.3.5
Excution de programmes dadministration e
Nous regroupons dans cette section les tapes de conguration, dmarrage et e e de reconguration. Pour toutes ces tapes, ils sagit globalement dexcution de e e programmes dadministration. Comme nous lavons voqu dans la section 8.3.3, les e e programmes dadministration sont encapsuls dans des composants Fractal que nous e appelons AutonomicManager. Dans limplantation de TUNeEngine, ils peuvent tre e dclenchs soit par une commande issu du composant External Communicator , e e soit par des lments administrs. Dans le premier cas, lvnement est directement ee e e e transmis ` lEvent Manager par le composant External Communicator . Dans a le second cas, ces vnements sont achemins du SE jusqu` la machine dadminise e e a tration par le composant Event Driver . Ce dernier est implant par un composant e Fractal sexcutant sur la machine dadministration. Ce composant dispose de deux e interface : linterface serveur er pouvant tre excute par RMI et une interface e e e cliente em permettant de contacter lEvent Manager en cas dvnements. Le e e composant Event Driver , dmarr au dmarrage de TUNeEngine, enregistre la e e e rfrence RMI de linterface er dans lannuaire RMI situe sur la machine dadmiee e nistration. Limplantation de cette interface contactera le composant Event Manager via linterface cliente em de lEvent Driver .
101
Figure 8.5 Dploiement et Undeploiement e Comme nous lavons voqu dans la section prcdente, le composant Event e e e e Channel est implant sous forme de dmon, associ ` chaque lment administr e e ea ee e et excut a distance. Pendant son dmarrage, il initialise le tube dans lequel lle e` e ee ment administr qui lui est associ posera ses vnements. Il obtient du registre RMI e e e e de la machine dadministration, la rfrence de linterface er du composant Event ee Driver . Cette interface implante la mthode notify qui permet denvoyer un vnee e e ment a TUNeEngine. LEvent Channel associe a chaque vnement la refrence ` ` e e e de llment administr a lorigine de lvnement. Il peut tre enrichi par adaptation ee e` e e e an dy associer des informations comme linstant denvoie de lvnement. e e Le composant Event Manager reoit les vnements via son interface serveur c e e em. Il dnit en outre dautres interface Fractal : une interface cliente sr lui pere mettant davoir acc`s au SR, et une interface cliente pm lui permettant davoir e acc`s au composant Policies Manager . Limplantation actuelle de linterface sere veur em de Event Manager prend en compte tous les vnements reus et ne e e c comprend aucune logique dcisionnelle. Il choisit via le Dispatcher de chaque Aue tonomicManager, les programmes de reconguration ` excuter. Ce choix est dict a e e par un attribut de ltat initial du programme. Cet attribut contient une liste dve e e nements pour lesquels le programme est apte. Syst`me dadministration autonome adaptable : application au Cloud e
` 8.4. SYNTHESE
102
Apr`s dcision des programmes ` excuter, lEvent Manager fait appel au come e a e posant Policies Manager en lui passant la liste des programmes dadministration (rfrences des composants encapsulant les tats initiaux) des AutonomicManager a ee e ` excuter. Limplantation de lEvent Manager est ralise par un composant come e e posite contenant deux composants primitifs : Executor et ProgramInterpreter . Ce composant composite dnit : une interface serveur pm relie ` linterface exee e a cute de Executor ; une interface cliente sr lui permettant daccder au SR ; et e une interface cliente re relie au RemoteExecutor . Le composant Executor , e via son interface execute, parcourt chaque programme en partant du composant reprsentant ltat initial. Pour chaque tat, laction a excuter est dnit soit dans e e e ` e e un attribut, soit par une interface serveur run de ltat, soit les deux. Lorsquelle e est dnie par un attribut, lExecutor fait appel au ProgramInterpreter an e dinterprter laction a eectuer. Les deux composants sont relis via leur interface e ` e interprete. Dans son implantation actuelle, le ProgramInterpreter implante linterprtation du langage RDL (section 5.2.3 du chapitre 5) du syst`me TUNe. Cette e e implantation peut videmment tre modie an de prendre en compte un nouveau e e e langage. Dans tous les cas, linterface run est excute ` la n de linterprtation. e e a e Lutilisation de linterface run est rserve aux administrateurs avertis. En eet, e e ils devront implanter pour chaque action (programme Java ici), le parcours du SR et lappel du mcanisme dexcution a distance pour lexcution proprement dite e e ` e des fonctions de reconguration sur la machine distante. Par contre, dans le cas dune action interprte, cette tche est factorise dans le ProgramInterpreter ee a e et est gnrique pour toutes les actions. De plus, une fois les actions interprtes, e e ee lExecutor se charge dexcuter rellement laction sur le SE distant de llment e e ee concern par laction. Pour cela, il fait appel au RemoteExecutor via son interface e re relie a linterface re du composite Policies Manager . e ` Limplantation de linterface serveur re du RemoteExecutor obtient du registre RMI la rfrence RMI du RemoteWrapper de llment sur lequel il doit excuee ee e ter une action. Le RemoteWrapper implante une interface eect qui permet dexe cuter rellement la fonction de reconguration sur le SE distant. Limplantation de e linterface eect utilise les mcanismes dintrospection et de reexion Java pour e identier et excuter la fonction sur le SE distant. Pour nir lExecutor constate e la n de lexcution du programme de reconguration lorsquil atteint ltat nal du e e programme. La gure 8.6 rsume limplantation Fractal de TUNeEngine ainsi que e les interactions entre les direntes lments distants constituant lenvironnement e ee administr. Le transfert dvnement et lexcution a distance des fonctions de ree e e e ` conguration sont raliss par des appels RMI. Les reprsentants RemoteWrapper et e e e RemoteLauncher jouent les rles deecteurs sur les lments en cours dexcution o ee e sur les SE distants.
8.4
Synth`se e
Dans ce chapitre nous avons prsent le mod`le dtaill de larchitecture dun e e e e e SAA hautement adaptable, exible et remplissant les crit`res que nous avons idene Syst`me dadministration autonome adaptable : application au Cloud e
` 8.4. SYNTHESE
103
Figure 8.6 Excution de programmes dadministration e tis dans le chapitre 6. Limplantation de ce mod`le, baptise TUNeEngine, est e e e une premi`re validation dont les composants remplissent les services du syst`me e e TUNe son inspirateur. Globalement, tous les lments administrs sont grs de la ee e ee mme faon. Chaque lment dispose dun reprsentant (wrapper ) dans le syst`me e c ee e e de reprsentant de TUNeEngine et galement dun reprsentant (RemoteWrapper ou e e e RemoteLauncher ) sur le SE dexcution distant. Pour raliser aussi bien la commue e nication des vnements que lexcution des fonctions dadministration a distance, e e e ` TUNeEngine utilise des appels RMI (implantes respectivement par lEvent Ree ceiver et le RemoteExecutor ). Comme nous lavons voqu tout au long de ce chapitre, tous les mcanismes e e e utiliss par TUNeEngine sont adaptables. Le chapitre suivant montre notamment e une adaptation et utilisation de TUNeEngine pour ladministration dune part du Cloud et dautre part des applications de niveau entreprise quil hberge. e Syst`me dadministration autonome adaptable : application au Cloud e
Chapitre 9 Contributions : application au Cloud

Contents
Un IaaS simpli : CloudEngine . . . . . . . . . . . . . . e 9.1.1 Vision globale : CloudEngine-TUNeEngine, ApplicationTUNeEngine-CloudEngine . . . . . . . . . . . . . . . . . . 9.1.2 RepositoryController . . . . . . . . . . . . . . . . . . . . . 9.1.3 VMController . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.4 VLANController . . . . . . . . . . . . . . . . . . . . . . . 9.1.5 ResourceController . . . . . . . . . . . . . . . . . . . . . . 9.1.6 MonitoringController . . . . . . . . . . . . . . . . . . . . . 9.1.7 Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Utilisation de CloudEngine . . . . . . . . . . . . . . . . . 9.2.1 Construction et enregistrement de VM . . . . . . . . . . . 9.2.2 Administration dapplications . . . . . . . . . . . . . . . . 9.3 Reconguration dapplications et de CloudEngine . . . . 9.3.1 Rparation de VM . . . . . . . . . . . . . . . . . . . . . . e 9.3.2 Consolidation de VM et Scalabilit de serveurs . . . . . . e 9.3.2.1 Excution dapplications statique . . . . . . . . e 9.3.2.2 Excution dapplications variables . . . . . . . . e 9.4 Synth`se . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 9.1 105 107 108 111 112 112 113 114 114 115 115 116 116 117 118 118 119
La premi`re problmatique de ce travail de th`se fut ladministration du cloud e e e ainsi que des applications quil hberge. Lors dune tentative dutilisation du syse t`me dadministration autonome TUNe, nous nous sommes heurts ` la dicult e e a e dutilisation de TUNe dans ce nouveau contexte quest le cloud. Cest ainsi que nous avons entrepris de concevoir et dimplanter un nouveau SAA le plus gnrique et e e exible possible de tel sorte que son utilisation pour ladministration du cloud et ses applications soit une personnalisation de ce SAA (vitant une r-implantation fastie e dieuse). Dans le chapitre prcdent, nous avons prsent une implantation (baptis e e e e e
9.1. UN IAAS SIMPLIFIE : CLOUDENGINE
105
TUNeEngine) de SAA hautement adaptable. Nous validons dans le chapitre courant ladaptabilit de ce syst`me en montrant comment il peut tre utilis pour (1) e e e e ladministration dune plateforme de cloud et (2) ladministration des applications entreprises sexcutant dans le cloud. e Comme nous lavons prsent dans ltat de lart, plusieurs travaux autour du e e e cloud sintressent ` ladministration du cloud en proposant des solutions plus ou e a moins compl`tes. De plus, ces solutions sont pour la plupart intgres et lies a une e e e e ` unique plateforme de cloud. An davoir un degr de libert dans lapplication de e e TUNeEngine a ladministration du cloud, nous proposons dans le cadre de cette th`se ` e limplantation dun syst`me simpli de cloud, baptis CloudEngine. Ce dernier se e e e limite uniquement a lIaaS et ses services de base. Les services lis a la facturation ` e ` ou ` lauthentication des clients ne sont pas implants dans CloudEngine. Cepena e dant, cette application de TUNeEngine a notre plateforme simplie de cloud ne ` e limite pas son application ` dautres plateformes orant des composants clairement a identiables. Cest le cas dOpenNebula [OpenNebula] pour lequel nous avons utilis e TUNeEngine pour automatiser son administration. Ce chapitre est organis de la faon suivante. Dans un premier temps, nous pre c e sentons limplantation de CloudEngine ainsi que des adaptations de TUNeEngine pour le prendre en compte. Ensuite, nous prsentons ladministration de CloudEne gine par le syst`me TUNeEngine adapt. Dans cette prsentation, nous nous limie e e tons aux tches de dploiement et de dmarrage de CloudEngine. Ensuite, nous a e e prsentons ladaptation et lutilisation de TUNeEngine pour ladministration des e applications entreprises devant sexcuter dans CloudEngine. La n de ce chapitre e est consacre ` la prsentation de limplantation de quelques politiques dadminise a e tration de lensemble CloudEngine-applications entreprises par des instances de TUNeEngine.
9.1
Un IaaS simpli : CloudEngine e
Comme nous lavons annonc a la n du chapitre 2, nous nous intressons aux e` e plateformes de cloud dans lesquelles lisolation est ralise par les syst`mes de vire e e tualisation. Ainsi, limplantation dIaaS simpli que nous proposons (CloudEngine) e sappuie sur un syst`me de virtualisation de type hyperviseur (section 2.2.4 du chae pitre 2). Le syst`me CloudEngine sinspire des implantations dIaaS existants tels e que OpenNebula [OpenNebula] et Eucalyptus [80]. Il implante la partie IaaS du mod`le de cloud que nous avons prsent dans le chapitre 3 a la gure 3.2. e e e ` La gure 9.1 montre lorganisation des services de lIaaS de quimplante CloudEngine. Ces services interagissent entre eux an daccomplir leurs taches. Les lments ee en bleu sur la gure 9.1 reprsentent les services tandis que les lments en jaune e ee reprsentent les ressources du cloud. Une `che pleine entre deux lments montre e e ee quun lment peut acqurir les services de llment point. En bref, les services ee e ee e fournis par CloudEngine sont :
106
RepositoryController : g`re la soumission des images OS en provenance de e lextrieur. Il cre pour chaque image OS, un Repository charg de recevoir e e e et de stocker limage. Lexcution dune VM utilisant une image Repository e pourra se servir dune copie ExecutedVMRepository de cette image. VMController : g`re la cration, la migration, larrt et la sauvegarde des VM. e e e Il fournit les interfaces dacc`s aux hyperviseurs prsents sur les machines de e e lIaaS. Pour son fonctionnement, le VMController a besoin des services des autres composants du cloud. Pour le dmarrage dune VM par exemple, il e obtiendra du RepositoryController limage OS quutilisera la VM. VLANController : g`re les rseaux virtuelles dans lesquels les VM du cloud e e seront connes. Il est sollicit par le VMController pour la conguration ou e e la libration des adresses rseaux des VM lors de leur cration, destruction ou e e e migration. A la n de son intervention, les VM cres doivent tre accessibles e e de lextrieur par leur propritaire. e e ResourceController : soccupe de lallocation et de la libration des ressource e dans le cloud. Il fournit au VMController la machine la plus adquate pour e lexcution dune VM dans le cloud. Comme nous le verrons dans la suite e (observ galement sur la gure 9.1), le ResourceController peut galement e e e tre sollicit par dautres composants du cloud. e e MonitoringController : g`re ltat des ressources matrielles de lIaaS ainsi que e e e celui des VM en cours dexcution. Les informations quil dispose peuvent tre e e utilises par les autres composants du cloud pour la ralisation de leurs tches. e e a En guise dexemple, lallocation de ressources aux VM par le ResourceController ncessite de sa part ltablissement dune cartographie de lensemble des e e ressources du cloud. Cette cartographie est ralise ` partir des informations e e a obtenues du MonitoringController. Scheduler : implante les politiques de relocalisation et consolidation de VM en cours dexcution dans le cloud. Pour cela, il utilise les services du Monitoringe Controller (pour lobtention des tats des VM), du ResourceController (pour e lobtention des machines de relocalisation/consolidation) et du VMController (pour les relocalisations/consolidations proprement dites). Dans cette section, nous prsentons limplantation de ces services ainsi que leur e intgration dans TUNeEngine. Dans un premier temps, nous prsentons une visions e e globale de cette implantation ainsi que son intgration dans TUNeEngine. Ensuite, e nous prsentons en dtails les composants de CloudEngine et leur implantation dans e e TUNeEngine. Notons quapr`s ladaptation de TUNeEngine pour implanter lquie e valent du syst`me TUNe, cette adaptation de TUNeEngine est la seconde validation e de lecacit de notre mod`le en terme de respect des caractristiques que nous e e e avons identies dans le chapitre 6. e
107
Figure 9.1 CloudEngine
9.1.1
Vision globale : CloudEngine-TUNeEngine, ApplicationTUNeEngine-CloudEngine
Comme toute application administre par un SAA, ladministration de notre e plateforme simplie de cloud par TUNeEngine ncessite lorganisation de ses come e posants en deux catgories : les composants administrables (dploys sur les SE e e e distants) et les politiques dadministration (dclenches par des vnements). Dans e e e e le cadre de CloudEngine, la majorit de ses lments sont intgrs dans TUNeEngine e ee e e comme programmes dadministration (plus prcisment programmes de recongurae e tion). Comme le montre la gure 9.2(2)(b), il sagit du VMController, du RepositoryController, du VLANController, du VMController et du Scheduler. Ces composants se mettent en marche lorsquune entreprise cliente du cloud contacte le cloud pour soumission dimage OS ou allocation de VM. A ce sujet, les entreprises utilisent gae lement des instances de TUNeEngine (gure 9.2(1)) (` travers son composant Exa ternalCommunicator ) pour le dploiement de leurs applications dans le cloud. e En ce qui concerne les lments administrs, nous retrouvons le Monitoringee e Controller, les Repository, les VM et les VLAN (gure 9.2(2)(a)). A lexception du MonitoringController, les lments administrs sont cres dynamiquement par les ee e e programmes de reconguration prsents prcdemment. Les VM par exemple sont e e e e cres par le VMController. Pour nir, le ResourceController est une adaptation ee
108
du composant NodeAllocator , sous-composant du Deployer de TUNeEngine (gure 9.2(1)(d)). Ladministration de CloudEngine par TUNeEngine ncessite pralablement la e e description de son architecture et de ses politiques dadministration dans un langage quelconque. Dans lattente de limplantation des API de la couche langage de TUNeEngine (gure 5.7 de la section 5.5), nous conservons les composants de TUNeEngine permettant de raliser cette description a savoir le (Parser et Proe ` gramInterpreter ). Rappelons que ces composants sont prdisposs a recevoir des e e ` descriptions en ADL de Fractal et notation pointe (RDL) du syst`me TUNe (sece e tion 5.2.3 du chapitre 5). Le premier permet de dcrire larchitecture des applications e quadministre TUNeEngine (CloudEngine et applications entreprises notamment). Quant au second langage, il simplie la description des actions dadministration contenues dans les programmes dadministration a excuter par TUNeEngine. Pour ` e cette adaptation de TUNeEngine, ce second langage est une extension de celui implant par le syst`me TUNe. e e Les lments a administrer ainsi que les politiques dadministration de CloudEnee ` gine sont dnis a laide de chiers ADL Fractal. Ces derniers sont ensuite excuts e ` e e par TUNeEngine pendant son dmarrage. Cette excution de TUNeEngine dmarre e e e le cloud. Linstance dexcution de TUNeEngine reprsente le point dentre de notre e e e platefome de cloud : nous lappelons frontend dans ce document. Lenregistrement de la rfrence du frontend dans lannuaire de collaboration (voir la section 8.3.2 ee du chapitre prcdent) permettra aux entreprises de rserver et dexcuter des VM e e e e dans le cloud. De faon gnrale, les instances TUNeEngine de niveau entreprise administrent c e e les applications entreprises de la mme faon que le syst`me TUNe. A lexception du e c e NodeAllocator de ces instances, limplantation des composants de TUNeEngine est identique a celle que nous avons prsente dans le chapitre prcdent. En eet, le ` e e e e NodeAllocator nobtient pas les composants SE (sur lesquels seront dploys les e e logiciels) du SR de son instance TUNeEngine. Il contacte linstance TUNeEngine de CloudEngine (par le biais de lExternalCommunicator des deux instances TUNeEngine du cloud et d niveau entreprise) an dobtenir les SE (qui sont des VM).
9.1.2
RepositoryController
Le RepositoryController g`re les soumissions de syst`mes de chiers de VM dans e e le cloud. Chaque syst`me de chiers est contenu dans un chier au format iso que e nous appelons galement image. Pour cela, nous rservons dans lenvironnement e e matriel du cloud une machine de stockage. Chaque image est gre par un compoe ee sant Repository qui sexcute sur le serveur de stockage et soccupe du stockage de e limage. Le RepositoryController attend continuellement des requtes sur deux canaux e
109
Figure 9.2 Vision synthtique : intgration de CloudEngine a TUNeEngine et e e ` utilisation de TUNeEngine pour le dploiement dapplications entreprises dans le e cloud.
110
rseaux. Les requtes reues de ces canaux sont de types dirents. Les premi`res e e c e e viennent des clients extrieurs du cloud. Elles correspondent au tlchargement dans e ee le cloud dimages iso de VM. Dans ce cas, le syst`me de chiers est transmis bloc e par bloc du client vers le RepositoryController. Notons que les deux intervenants ngocient initialement la taille dun bloc. A la n du tlchargement des blocs, le e ee RepositoryController reconstitue limage iso et linstrumentalise pour faciliter la future conguration rseau des VM qui lutiliseront. Linstrumentalisation de limage e consiste en lajout dune partition particuli`re dans la description des partitions e disque de lOS. Cette partition contiendra les programmes dinitialisation rseau des e VM qui excuteront cette image. Cette technique permet ` notre plateforme de cloud e a de prendre en compte des images dOS standard. Nous revenons sur la description de ces programmes dans la section 9.1.4. Les deuxi`mes requtes reues par le RepositoryController viennent du service e e c VMController lorsque celui-ci est sur le point de dmarrer une VM. En eet, comme e nous lavons voqu dans la section 3, lexcution dune VM dans le cloud ncessite e e e e la duplication de son image de base (pour une rutilisation ultrieure). Dans notre e e implantation, cest le RepositoryController qui ralise cette duplication. Limage e duplique est ensuite transfre sur le lieu dexcution de la VM (lment Execue ee e ee tedVMRepository dans la gure 9.1). Ce lieu peut tre la machine dexcution de la e e VM ou encore un serveur de partage de chiers accessible par la machine dexcue tion de la VM. Dans notre cas, il sagit dun serveur NFS accessible par toutes les machines de lIaaS. Implantation dans TUNeEngine. Le service RepositoryController est implant dans TUNeEngine par un programme de reconguration. Son excution est e e dclenche par une requte denregistrement dimages de VM. Pour chaque image, e e e lexcution du RepositoryController cre et dmarre dans le SR de TUNeEngine un e e e composant Repository reprsentant limage. Le dploiement et lexcution du Repoe e e sitory seectue sur le serveur de stockage (gure 9.2(2)(f)). Cest lui qui est charg e de recevoir du client externe, le contenu de limage. Il obtient du RepositoryController les param`tres tels que : le rpertoire denregistrement des images, les param`tres e e e dcoutes rseaux, la taille des blocs de rception dimages VM, le nom de limage, la e e e taille de limage et le type dOS contenu dans limage. Lintgration des composants e Repository dans le SR permet a CloudEngine de faciliter la tche de cration de VM ` a e du VMController. Le dmarrage dune VM dans le cloud entra la cration dune image secone ne e daire, replica de limage OS originale. Cette nouvelle image est reprsente dans e e le SR par un composant ExecutedVMRepository dont le dploiement et lexcution e e duplique rellement limage originale reprsente par un Repository. e e e
111
9.1.3
VMController
Il soccupe du dmarrage, de larrt et de la migration des VM a la demande des e e ` clients externes ou du Scheduler. Pour le dmarrage des VM, il requiert le nom de e limage contenant lOS a dmarrer, le nombre de VM ` dmarrer et les ressources ` e a e de la VM (nombre de processeurs, taille mmoire, nombre dinterface rseau, etc). e e Le procd quil suit pour le dmarrage de chaque VM est le suivant : e e e Il sadresse au gestionnaire de ressources (ResourceController ) pour lacquisition du lieu dexcution (SE) de la VM. e Comme nous lavons voqu dans la section prcdente, il sollicite le Reposie e e e toryController an que celui-ci mette a la disposition du SE limage de la VM ` (par la cration et lexcution de lExecutedVMRepository reprsentant limage e e e de la VM). En fonction du type de limage, il obtient du VLANController les scripts dinitialisation rseau de la VM. Ces scripts sont enregistrs dans la partition dinie e tialisation rseau de telle sorte quils sexcutent au dmarrage de la VM. e e e Il utilise les API fournies par lhyperviseur du SE pour dmarrer la VM. e Pour nir, les scripts dinitialisation utilisent lhyperviseur pour communiquer les param`tres rseaux obtenus par la VM. Il transmettra ces param`tres au e e e client propritaire de la VM an que celui-ci puisse accder ` ses VM. e e a Inversement, larrt dune VM lib`re les adresses rseaux quelle utilise. Le VMCone e e troller sollicite galement le ResourceController pour le nettoyage du lieu dexcution e e de la VM. Ce nettoyage peut consister ` supprimer lExecutedVMRepository de la a VM ou remplacer le Repository de la VM par son ExecutedVMRepository. Implantation dans TUNeEngine. Le VMController est implant dans TUe NeEngine sous la forme dun programme dadministration. Il est excut dune part e e lorsquun client souscrit ou met n a lexcution dune VM. Comme nous le verrons ` e dans la section 9.2, les demandes des clients se traduisent en vnements de rcone e e guration au niveau de linstance TUNeEngine qui g`re lIaaS. Dautre part, son e excution peut tre dclenche par dautres services de CloudEngine ` linstar du e e e e a Scheduler (lorsquil dsir relocaliser ou consolider une VM). e Comme lenregistrement des images, il associe ` chaque VM excute dans le a e e cloud un composant dans le SR encapsulant les fonctions de manipulation de la VM. Il sagit des fonctions de dmarrage, darrt et de migration. Ainsi, le dploiement e e e dune VM consistera au dploiement de son reprsentant du SR, comme tout autre e e logiciel, sur la machine fournie par le ResourceController. La classe dencapsulation dune VM implante galement les fonctions de dploiement et de undploiement e e e telles que requise par lIaaS. Cest notamment dans cette classe que les requtes au e VLANController sont eectues pour solliciter la conguration de la VM. e
112
9.1.4
VLANController
Il soccupe des congurations rseaux des VM dans CloudEngine. Pour cela, il e g`re un chier dadresses MAC a allouer aux VM. Son implantation suppose la pre ` e sence dun serveur DHCP dans lenvironnement du cloud. Le VLANController sexcute sous forme de dmon et attend sur une socket e e des ventuelles requtes du composant VMController lorsque celui-ci dsire dmare e e e rer/arrter une VM. Dans le cas du dmarrage, il alloue une adresse MAC inutilise e e e et reconnue par le serveur DHCP. Il lui fournit galement les scripts dinitialisation e rseau de la VM en fonction du type dimage quelle excute. Dans son implantation e e actuelle, le VLANController ne g`re que des OS de types CentOS [cen] et Debian [6]. e Enn, il congure le rseau de telle sorte que les VM appartenant au mme client e e feront partie dun unique VLAN. Par contre, lorsque la requte du VMController concerne larrt dune VM, le e e VLANController lib`re ladresse MAC de cette VM de telle sorte quelle puisse a e ` nouveau tre alloue a une autre VM. e e ` Implantation dans TUNeEngine. Il est implant dans TUNeEngine comme e un programme de reconguration. Son excution, dclenche par ladministrateur e e e du cloud, permet la cration ou la suppression de composants VLAN dans le SR. e Le rle de ces composants est la conguration de VLAN dans lIaaS. Chaque como posant VLAN implante une procdure de conguration rseau particuli`re. Ils foure e e nissent galement les param`tres dinitialisation rseau des VM aux composants e e e VM les reprsentants. Il sagit des informations sur les serveurs DNS, DHCP et les e adresses MAC reconnues dans le rseau. Comme les Repository, le dploiement et e e lexcution des composants VLAN seectuent sur une unique machine de lIaaS e (gure 9.2(2)(e)). Cest ` partir de cette machine quils ralisent la conguration des a e VLAN et des VM sexcutant dans lIaaS. e
9.1.5
ResourceController
Il est le responsable de lallocation des machines dexcution des VM (les mae chines hbergeant un hyperviseur) dans le cloud. Il intervient sur la demande du e VMController an de lui fournir la machine dexcution la plus adquate a lexcue e ` e tion dune VM. Pour cela, le VMController lui fournit les besoins en ressources de la VM quil souhaite excuter. En fonction de ces informations et de celles fournies e par le MonitoringController, il choisit la machine dexcution de la VM. e Dans son implantation actuelle, le choix de la machine dexcution sappuie sur e deux algorithmes dit de placement : clatement et regroupement des VM. Dans le e premier algorithme, le ResourceController choisit la machine dexcution la moins e utilise. Dans ce cas, les machines nhbergeant aucune VM sont privilgies. Dans le e e e e second algorithme, il choisit la machine la plus utilise pouvant excuter la nouvelle e e VM sans seondrer. Les crit`res deondrement dune machine sont congurs par e e
113
ladministrateur du cloud avant son excution. Ils prennent en compte les capacits e e mmoire, processeur, rseau et disque de la machine. e e Implantation dans TUNeEngine. Le ResourceController (gure 9.2(2)(d)) correspond dans TUNeEngine au NodeAllocator . Grce a ladaptabilit de TUa ` e NeEngine, nous remplaons son NodeAllocator par le ResourceController. Comme c nous lavons prsente dans la section 8.3.4, son excution est dclenche par le VMe e e e e Controller via le Deployer de TUNeEngine. Nous regroupons les ressources de lIaaS en deux catgories (gure 9.2(2)(c)) : e les machines dexcution des composants services de lIaaS (VLAN, Repository et e MonitoringController ) et les ressources dexcution des VM. Chaque ensemble de e ressources est reprsent par un cluster : ControllerCluster et IaaSCluster. Le Rese e sourceController g`re les ressources de lIaaSCluster. Les composants Fractal VM e sont congurs dans TUNeEngine de telle sorte que leur excution se fasse dans e e lIaaSCluster. De cette faon, le ResourceController sera contacter pour le choix du c SE parmi les machines de ce cluster.
9.1.6
MonitoringController
Il g`re le monitoring de lIaaSCluster. Pour cela, il installe sur toutes les machines e de lIaaS des serveurs qui observent les performances de la machine et de ses VM. Ces serveurs communiquent leurs informations de monitoring a un serveur centralis ` e (qui est le vritable MonitoringController ) qui sexcute sur le frontend. Ces sere e veurs recherchent deux types dinformations : ltat des VM ; et les consommations e de chaque VM et de la machine enti`re. e En ce qui concerne les tats de VM, nous considrons quune VM peut tre dans e e e deux tats : soit accessible soit inaccessible. Une VM est considre comme accessible e ee lorsquelle rpond correctement a au moins une requte rseau de type ping. Quant e ` e e aux informations de consommation, nous prenons en compte les consommations re seau, CPU et mmoire de chaque VM et de toute la machine. e Pour obtenir ces informations, le Monitoringcontroller et ses serveurs utilisent des API de lhyperviseur et de ceux du syst`me dexploitation. Ces informations pere mettront par exemple au ResourceController de dterminer le niveau deondrement e dune machine dexcution de VM ou encore au MonitoringController de dclarer la e e panne dune VM. Implantation dans TUNeEngine. Un composant Fractal encapsule le service Monitoringcontroller qui sexcute sur le frondent. Quant aux serveurs de monitoe ring, ils sagit de serveurs associs (par encapsulation) a chaque nud (ce choix de e ` conception peut tre remise en cause). En eet, comme tout lment administr par e ee e TUNeEngine, nous dnissons dans la classe Java dencapsulation de tout nud de e lIaaSCluster des programmes jouant les rles suivants : o rle de sonde : il enregistre dans un chier les consommations en ressources des o VM quhberge le nud. Ces informations seront par la suite transfres vers le e ee
9.2. UTILISATION DE CLOUDENGINE
114
MonitoringController (sur demande de ladministrateur) ou le Scheduler (sur a demande). c role de dtecteur (et rparation) de pannes : il initie dans certain cas, la rpae e e ration des VM en cas de panne dtecte. Cest le cas lorsque le cloud pratique e e une rparation par checkpointing tel que nous le verrons dans la section 9.3.1. e
9.1.7
Scheduler
Le Scheduler g`re la rorganisation/consolidation des VM dans lIaaS pendant e e leur excution. Cette consolidation permet notamment aux ressources de lIaaS dtre e e mieux utilises. Son implantation dpend des politiques que souhaitent ladminise e trateur. Dans le chapitre 10 de prsentation des exprimentations de nos syst`mes e e e TUNeEgine et CloudEngine, nous prsenterons en dtails plusieurs politiques de e e consolidation. Qu` cela ne tienne, le Scheduler sappuie sur les informations du Moa nitoringController an dtablir une cartographie de lutilisation des ressources. e Son excution nest pas continue durant tout le cycle de vie du cloud. Il survient e rguli`rement (apr`s un temps de repos ou un changement de lIaaS par exemple) e e e an de dterminer les consolidations ` eectuer dans lIaaS. e a Implantation dans TUNeEngine. Comme le VMController, le Scheduler est implant par un programme de rconguration dans TUNeEngine. Il est dclench au e e e e dmarrage du cloud et ne sinterrompe qu` larrt de TUNeEngine. Le programme e a e de rconguration qui lencapsule comprend un seul tat excutant une classe java e e e implantant la politique de scheduling. Sa dnition sous forme de programme de e rconguration lui permet davoir acc`s au SR (donc de la liste des machines et des e e VM). A laide des informations du SR et des appels rguliers au MonitoringCone troller, il constitue a son rveil la cartographie dutilisation des ressources. Cette ` e cartographie lui permet de dcider de la liste des machines virtuelles a dplacer. e ` e
9.2
Utilisation de CloudEngine
Apr`s sa mise en route par TUNeEngine, notre plateforme de cloud est prte a ace e ` cueillir des applications clientes venues de lextrieur. Comme nous lavons annonc e e en prambule de ce chapitre, nous proposons galement ladaptation du syst`me e e e TUNeEngine pour faciliter ladministration des applications clientes dans CloudEngine. Cette section est consacre a la prsentation de cette adaptation. Nous de ` e e butons par la prsentation de lutilisation de TUNeEngine pour laccomplissement e de la premi`re opration dexternalisation dans le cloud ` savoir la construction et e e a le tlchargement dimages de VM (section 3 du chapitre 2). Ensuite, nous prsenee e tons ladaptation de TUNeEngine pour le dploiement dapplications CloudEngine. e A lexception du dploiement proprement dit des application dans le cloud, nous e ne prsentons pas en dtails lutilisation de TUNeEngine pour la conguration et e e Syst`me dadministration autonome adaptable : application au Cloud e
9.2. UTILISATION DE CLOUDENGINE
115
le dmarrage des applications. En eet, ces utilisations sont similaires a celles du e ` syst`me TUNe dont limplantation de base de TUNeEngine reprend. e La gure 9.2 montre les deux niveaux dutilisation de TUNeEngine pour ladministration dans le cloud. Une instance de TUNeEngine (gure 9.2(2)) sert a ladmi` nistration de CloudEngine et plusieurs autres instances sont utilises pour ladmie nistration des applications entreprises sexcutant dans le cloud (gure 9.2(1)). Ces e derni`res instances collaborent avec la premi`re pour remplir leurs objectifs. e e
9.2.1
Construction et enregistrement de VM
A laide de TUNeEngine, nous proposons un syst`me dautomatisation du proe cessus de construction et de tlchargement vers le cloud dune image VM. Dans ee le reste de ce document, nous nommons ImageConstructor, lensemble constitu de e TUNeEngine et cette application. Dans son implantation actuelle, ImageConstructor se limite ` lautomatisation de linstallation des OS de type Linux. Pour cela, a il sappuie sur les outils syst`mes fournis par un syst`me Linux (Kickstart [Fedora], e e Debootstrap [7], etc). En consquence, il requiert pour son excution que le client e e de CloudEngine dispose dun syst`me Linux. e Sans rentrer dans les dtails, lImageConstructor cre dans le SR un compoe e sant Fractal pour chaque image a construire. Ce composant dnit les param`tres ` e e dinstallation de lOS (distribution Linux, partitionnement, package, utilisateur, mot de passe, etc). Son excution ralisera la construction progremment dite le limage. e e LImageConstructor dnit galement les param`tres permettant de contacter linse e e tance TUNeEngine du cloud (pour la suite, nous dirons tout simplement CloudEngine). Il sagit du nom de la rfrence de CloudEngine dans lannuaire ainsi que ee ladresse de cette annuaire. Apr`s la construction de limage, son enregistrement dans le cloud est gr par e ee lexcution du composant associ ` limage dans le SR. Ce composant contacte le e ea cloud (via les informations obtenues de lImageConstructor ) an de raliser le tle ee chargement de limage dans le Cloud. Ce contact se traduit au sein de CloudEngine par lexcution du RepositoryController. Apr`s ngociation de la taille des blocs e e e dchange avec le RepositoryController, le composant reprsentant limage OS dans e e linstance TUNeEngine de niveau entreprise transmet le contenu de limage bloc par bloc vers le composant Repository le reprsentant au niveau de CloudEngine. e
9.2.2
Administration dapplications
Comme nous lavons voqu ci-dessus, nous ne revenons par en dtails sur le e e e procd dutilisation de TUNeEngine pour la ralisation des tches de conguration e e e a et dmarrage des applications dployes dans le cloud. A lexception du dploiement e e e e que nous prsentons ci-dessous, ladministration dune application par TUNeEngine e Syst`me dadministration autonome adaptable : application au Cloud e
9.3. RECONFIGURATION DAPPLICATIONS ET DE CLOUDENGINE
116
(au niveau applications entreprises) est identique ` celle des services de CloudEngine a prsente dans la section 9.1. e e La description de lapplication a administrer avec TUNeEngine dans le cloud ` requiert limplantation dun NodeAllocator particulier (gure 9.2(1)). En eet, les machines dexcution des applications ne sont ni existantes, ni connues initialement e par le client. De la mme faon que nous dnissions un composant FrontEnd repre c e e sentant le cloud dans la construction des images, nous dnissons ici un composant e jouant le mme rle. Ce composant permet au NodeAllocator de souscrire aux VM e o dans le cloud. Cette souscription entra nera dans le cloud, lexcution du VMCone troller. Ce dernier retournera par la suite au NodeAllocator du client, les adresses de connexion aux VM lui appartenant. Cest galement pendant cette souscription e que le client ngocie avec CloudEngine des modalits de gestion de ses VM. e e En guise dexemple, CloudEngine permet au client de ngocier le moyen de re e paration des VM en cas de pannes. Dans les sections suivantes, nous prsentons e les direntes mthodes de rparations pouvant tre implantes par les deux parties. e e e e e Plus gnralement, nous prsentons des politiques dadministration (reconguration) e e e a la fois dans CloudEngine et ses applications entreprises. `
9.3
Reconguration dapplications et de CloudEngine
Dans cette section, nous prsentons limplantation des principales oprations de e e reconguration que nous avions prsentes dans la section 3 du chapitre 2. e e
9.3.1
Rparation de VM e
Nous identions deux mthodes de rparation de VM dans le cloud : rparation e e e non collaborative et rparation collaborative. Avant de prsenter ces deux mthodes, e e e nous tudions deux moyens de dtection de pannes de VM dans le cloud. e e Dans limplantation de CloudEngine, nous avons dcrit la premi`re mthode de e e e dtection de pannes. Elle est ralise par les serveurs du MonitoringController de e e e lIaaS (section 9.1.6). Cependant, un client nest pas tenu a souscrire ` ce service de ` a surveillance. Dans ce cas, il insrera parmi ses logiciels a dployer dans le cloud, des e ` e logiciels particuliers jouant le rles de surveillance. De plus, le client doit organiser o le dploiement de ces logiciels de telle sorte que lobservateur dune VM ne sexcute e e pas sur cette VM. Quelque soit le moyen de dtection utilis, nous distinguons deux e e mthodes de rparation de VM. Partant de la dtection par IaaS, prsentons ces e e e e deux mthodes de rparation. e e
117
Rparation non collaborative e Dans ce type de rparation, lIaaS est le seul ` soccuper de la rparation des VM. e a e Les serveurs de monitoring de CloudEngine (ceux associs aux reprsentants des mae e chines dans le SR) enregistrent rguli`rement ltat entier des VM quils monitorent e e e (contenu des mmoires, disque, communications rseau, etc.). Seuls les deux derniers e e tats sont maintenus. Pour cela, ils se servent de la fonctionnalit de checkpointing e e que fournissent les hyperviseurs de lIaaS (voir la section 2.2.3 du chapitre 2). Ainsi, lorsquune panne de VM est dcele, lexcution dun programme de rparation est e e e e dclenche par le MonitoringController ou linstance . Ce programme dmarre (via e e e le VMController ) une nouvelle VM ayant non seulement les mmes caractristiques e e que la VM en panne mais aussi le dernier tat correcte connu de cette VM. e Comme nous le verrons dans le chapitre suivant, linconvnient de cette me e thode de rparation est la dgradation de lexcution des applications clientes dans e e e le cloud. En eet, le checkpointing entra larrt momentan de la VM, ce qui ne e e ralentit lexcution de ses applications. e Rparation collaborative e La seconde mthode vite le checkpointing. En cas de panne, un programme e e de rparation de CloudEngine dmarre une nouvelle VM en remplacement de celle e e tombe en panne. Cette VM sappuie uniquement sur limage de celle en panne. Cee pendant, les logiciels clients prcdemment en cours dexcution dans la VM ne sont e e e pas dmarrs par ce programme. En eet, le cloud ne dispose daucune connaissance e e des logiciels sexcutant dans les VM quil hberge. e e Le dmarrage des logiciels sera donc ralis par linstance TUNeEngine du client. e e e La communication CloudEngine vers linstance TUNeEngine du client se fait de la mme faon que du client vers le cloud. En eet, le ResourceAllocator du client e c fournit au cloud pendant la souscription aux VM, les rfrences de contact de linsee tance TUNeEngine du client. Il sagit de limplantation dune sorte de callback dans CloudEngine. Ainsi, le programme de rparation de VM au niveau du cloud pourra e faire appel au programme de rparation de VM au niveau du client. Ce dernier e programme excutera le processus dinstallation et de dmarrage des logiciels. e e
9.3.2
Consolidation de VM et Scalabilit de serveurs e
Apr`s limplantation des programmes de rparation dans CloudEngine, nous nous e e intressons dans cette section a limplantation des autres tches de reconguration e ` a dans le cloud et ses applications. Au niveau de CloudEngine, il sagit des oprations e de consolidation que met en place ladministrateur pour optimiser la gestion des ressources. Quant aux applications clientes, compte tenu de la multitude des oprae tions possibles, nous nous limitons a celles ayant un impact sur le cloud. Il sagit des ` recongurations qui entra nent lajout ou le retrait de VM pendant lexcution des e applications clientes. Lorsquelles surviennent dans la mme application, plusieurs e appellations sont utilises dans la littrature pour dsigner ces deux oprations : e e e e sizing, scalabilit ou encore passage a lchelle. e ` e
118
Dans cette section, nous prsentons plusieurs situations dexcution de Cloue e dEngine et des applications clientes pour lesquelles nous proposons dirents proe grammes de reconguration. Pour cela, nous supposerons que les clients du cloud excutent des applications de type J2EE. e
9.3.2.1
Excution dapplications statique e
La situation la plus basique est celle dans laquelle les clients du cloud surdimensionne a chaque rservation le nombre de VM dont ils ont besoins pour lex` e e cution de leurs applications. De plus, nous supposons que toutes les VM dun client sont dmarres ou arrtes au mme instant (nous considrons le cas inverse comme e e ee e e du sizing, section suivante). Dans cette situation, le cloud ` intrt a mettre en place a ee ` un syst`me de consolidation bas sur les consommations relles des VM. En eet, e e e tant donn que le client a sur-dimensionn ses allocations en termes de VM, celles-ci e e e seront souvent sous utilises. Si le Cloud rserve les machines en fonction des tailles e e des VM, tel que prvu par le contrat qui le lie au client, elles seront clates sur un e e e grand nombre de machines. Lapplication dun programme de consolidation bas sur e le niveau dutilisation eectif des VM permettra au cloud de rduire le nombre de e machines alloues aux VM. En eet, ce programme les consolidera sur un nombre e restreint de machines en cas de sous utilisation et les clatera sur plus de machines e lorsque la consommation saccentuera.
9.3.2.2
Excution dapplications variables e
Cette seconde situation concerne les clients avertis. En eet, nous supposons ici que les clients pratiquent du sizing dans leurs applications. Contrairement ` la a situation prcdente, ici le nombre de VM du mme client est variable. LIaaS prote e e e de ces arrts de VM, donc libration de ressources, pour rorganiser les VM par e e e consolidation. Pour illustrer cela, prenons quelques exemples prcis : e Si le cloud excute une seule application et que celle-ci pratique du sizing e ordonn, alors aucune opration de consolidation nest ncessaire. Nous parlons e e e de sizing ordonn lorsque les VM retires sont les derni`res a tre ajoutes. e e e è e Si le cloud excute une seule application pratiquant un sizing non ordonn, e e alors la consolidation est ncessaire. Cette situation est identique a celle dans e ` laquelle le cloud excute plusieurs applications appartenant a un ou plusieurs e ` clients. En eet, la n dune application (qui entra la n de ses VM), pendant ne lexcution dautres, laissera des trous sur les machines hbergeant les VM e e de cette application. Cette libration de ressources correspond celle que nous e observons dans une application pratiquant un sizing non ordonn. e Une situation plus ne est celle dans laquelle le cloud donne la possibilit au e client de faire varier la taille dune VM pendant son excution. Ainsi, avant e dajouter une nouvelle VM pour absorber une charge, le client pourra tout dabord augmenter progressivement les ressources de la VM jusqu` atteindre a Syst`me dadministration autonome adaptable : application au Cloud e
` 9.4. SYNTHESE
119
la ressource maximale (celle de la machine qui lhberge). Et, cest a lissu e ` de ces augmentations quil ajoutera concr`tement une nouvelle VM. Le mme e e raisonnement est valable pour le retrait. Dans ce scnario, la consolidation au e niveau de lIaaS prend vritablement tout son sens. Les variations de tailles e des VM, libreront des ressources (avec apparition des trous) et ncessiteront e e ainsi des consolidations/clatements de VM dans lIaaS. Notons galement e e quici, le client est dans lobligation dadapter galement les distributeurs de e charges de ses applications. Nous valuons dans le chapitre suivant toutes ces scnarios de reconguration ` la e e a fois dans le cloud et dans les applications clientes.
9.4
Synth`se e
Dans ce chapitre, nous avons prsent une adaptation de TUNeEngine pour lade e ministration de la plateforme de cloud simplie CloudEngine ainsi que des applie cations quelle hberge. La gure 9.3 prsente une vue globale de ces adaptations e e de TUNeEngine : a gauche de la gure, nous avons lutilisation de TUNeEngine ` pour ladministration dune application entreprise J2EE sexcutant dans le cloud ; e a droite nous avons dune part lutilisation de TUNeEngine pour ladministration ` de CloudEngine et dautre part le contenu des machines de lIaaS. Par soucis de lisibilit, toutes les liaisons Fractal entre les composants ne sont pas prsentes dans e e e cette gure. Le syst`me de reprsentation de linstance TUNeEngine du cloud est organis en e e e quatre composants : Un composant (IaaS sur la gure) contenant les wrappers des serveurs de lIaaS ainsi que ceux des futures images et VM quhbergera le cloud. Remare quons que dans cet exemple, le cloud propose une image de VM par dfaut e (DefaultImage) dont la description est montre dans la gure 9.4(a). Plusieurs e congurations de VLAN peuvent tre utilises dans lIaaS. La gure 9.4(b) e e prsente un exemple de conguration dun VLAN. Cette description contient e par exemple ladresse IP rseau quutiliseront les VM de ce VLAN. e Un composant (Ressources sur la gure) contenant les wrappers des machines de lIaaS. Ces machines peuvent tre regroupes en cluster. e e Un composant (IaaS AutonomicManager sur le gure) contenant les programmes dadministration et de reconguration des serveurs de lIaaS. Ce composant est reli au composant IaaS de la gure. On retrouve par exemple le e VMController que nous avons prsent dans les sections prcdentes comme e e e e un programme dadministration. Un composant (Ressources AutonomicManager sur le gure) contenant les programmes de dmarrage des logiciels de monitoring (sonde) des machines de e lIaaS. Ce composant est reli au composant Ressources de la gure. Nous e associons une sonde par machine (voir le logiciel Sonde sur la partie droite basse de la gure 9.4)
` 9.4. SYNTHESE
120
Quant au syst`me de reprsentation de linstance TUNeEngine dadministration de e e lapplication entreprise J2EE, il est organis en deux composants : e Un composant contenant les wrappers des serveurs J2EE et un wrapper de crivant les informations dinitiation de la collaboration avec le cloud. Chaque wrapper de serveur J2EE contient dune part les informations de conguration du serveur proprement dit et dautre part les informations dcrivant la quantit e e de ressources VM de ce serveur. La gure 9.4(c) montre la description du wrapper dun serveur Apache de lapplication entreprise J2EE. Dans sa premi`re e partie, nous retrouvons les informations de conguration dApache comme le ApacheUser tandis que dans sa deuxi`me partie, nous retrouvons les infore mations de conguration de la VM qui hbergera cet Apache (par exemple e cpu : la quantit de processeur a garantir ` cette VM). e ` a Un composant contenant les programmes de conguration, dmarrage, recone guration et rparation des serveurs J2EE. e Le composant ResourceController (remplaant le NodeAllocator ) de linsc tance TUNeEngine de niveau entreprise obtient du serveur RMI de collaboration, la rfrence RMI du composant Collaborator du Cloud. A partir de cette rfrence, ee ee le ResourceController pourra allouer ou librer des VM pour lexcution des sere e veurs de lapplication entreprise. Dans cette collaboration, la plus part des ordres mis par le ResourceController a destination du cloud seront rsolus par le VMe ` e Controller . En rponse a la rservation dune VM pour lexcution dun serveur e ` e e Apache par exemple, le VMController construit et ins`re dans le syst`me de ree e prsentation de CloudEngine un wrapper de VM dont une description est prsente e e e dans la gure 9.4(d). Les informations de conguration de cette VM sont transmises par le ResourceController du niveau entreprise dans lordre de rservation. e Dans la mme logique, limplantation du composant ProbreMySQL utilise la re e frence RMI du Collaborator an davoir les informations de monitoring des VM e hbergeant les serveurs MySQL dont il observe. Ainsi, il pourra (` partir de ces ine a formations) dcider de la scalabilit ou non des serveurs MySQL en cas de ncessit. e e e e Pour nir, nous pouvons observer un empilement de serveurs sur les machines de VMCluster. Ainsi, sexcutent au dessus de lhyperviseur les reprsentants Ree e moteLauncher et RemoteWrapper dploys par linstance TUNeEngine du cloud. e e Chaque RemoteWrapper est associ ` lexcution dune VM, qui est considre par ea e ee linstance TUNeEngine du cloud comme un lment administrable. Ensuite, chaque ee VM contient les reprsentants RemoteLauncher et RemoteWrapper dploys par e e e linstance TUNeEngine de niveau entreprise. Chaque RemoteWrapper de chaque VM est associ ` lexcution dun serveur J2EE. Les dirents reprsentants des e a e e e instances TUNeEngine des deux niveaux (entreprise et cloud) sont enti`rement ine dpendantes et ne disposent daucun lien entre eux. e
` 9.4. SYNTHESE
121
Figure 9.3 Vue globale dadministration et dutilisation de CloudEngine via TUNeEngine
` 9.4. SYNTHESE
122
Figure 9.4 (a) Description dune image de VM dans le SR de CloudEngine, (b) Description dune VM dans le SR de CloudEngine, (c) Description du logiciel Apache dans le SR de linstance TUNeEngine de niveau application Entreprise, et (d) Description dune VM dans lIaaS gnre par le VMController de CloudEngine. e ee
Chapitre 10 Exprimentations e
Contents
10.1 Environnements dexprimentation . . . . . . . . e 10.1.1 LIaaS . . . . . . . . . . . . . . . . . . . . . . . . 10.1.2 Les applications entreprises : RUBIS . . . . . . . 10.1.3 Les mtriques . . . . . . . . . . . . . . . . . . . . e 10.2 Evaluations . . . . . . . . . . . . . . . . . . . . . . 10.2.1 Rparation de VM . . . . . . . . . . . . . . . . . e 10.2.1.1 Rparation non collaborative . . . . . . e 10.2.1.2 Rparation collaborative . . . . . . . . e 10.2.2 Scalabilit et Consolidation . . . . . . . . . . . . e 10.2.2.1 Scalabilit . . . . . . . . . . . . . . . . e 10.2.2.2 Consolidation . . . . . . . . . . . . . . 10.2.2.3 Scalabilit et Consolidation simultanes e e 10.3 Synth`se . . . . . . . . . . . . . . . . . . . . . . . . e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 124 125 126 126 126 127 128 130 130 132 134 143
Dans ce chapitre, nous prsentons une valuation de notre SAA TUNeEngine e e appliqu a la plateforme de cloud CloudEngine et aux applications quelle administre. e` Compte tenu de la dicult dvaluation de certains aspects de ladministration e e (conguration, dploiement et reconguration par exemple), nous nous limitons dans e ce chapitre aux aspects suivants : construction dimages de VM et leur enregistrement dans le cloud ; utilisation de TUNeEngine pour la rparation de VM dans le cloud ; et e utilisation de TUNeEngine pour la gestion de ressources de lIaaS et des applications entreprises. Ce chapitre est organis de la faon suivante : dans un premier temps, nous e c dcrivons les environnements matriels et logiciels sur lesquels nous nous appuyons e e pour la ralisation de nos exprimentations. Ensuite, nous prsentons les rsultats e e e e dvaluation de TUNeEngine pour la rparation de VM dans CloudEngine. Pour e e nir, nous prsentons lvaluation de lutilisation de TUNeEngine pour la gestion de e e ressources de lIaaS ainsi que celle des applications entreprises.
10.1. ENVIRONNEMENTS DEXPERIMENTATION
124
10.1
10.1.1
Environnements dexprimentation e
LIaaS
Lenvironnement matriel dexprimentation que nous avons mis en place co e e ncide avec notre mod`le simpli dIaaS prsent dans la section 9.1 du chapitre e e e e prcdent. Les ressources matrielles sont organises en clusters de machines de type e e e e OPTIPLEX 755 : Un ensemble de machines (CloudEngine) hbergeant les dirents serveurs de e e CloudEngine a raison de : une machine hbergeant le serveur de stockage (NFS) ` e des images de VM (Repository et ExecutedVMRepository), les serveurs de congurations des VLAN, le MonitoringController ; et une machine hbergeant le e Scheduler, le VMController, le ResourceController, autres programmes de reconguration de CloudEngine et le registre RMI de sauvegarde des rfrences ee des instance de TUNeEngine. Cette derni`re machine est le point dentre e e de CloudEngine car cest elle qui hberge galement linstance TUNeEngine e e charge de ladministration de CloudEngine. Notons que cette organisation de e serveurs peut tre dcentralise, par adaptation de TUNeEngine, pour un envie e e ronnement large chelle. Les machines de ce cluster disposent chacune de 4Go e de mmoire, de 2 processeurs de type Intel Core 2 Duo 2.66GHz et utilisent e des distributions CentOS 5.6 du syst`me Linux. e Un cluster dhbergement des VM (5 machines). Les machines de ce cluster e sont celles qui seront utilises pour lexcution des VM rserves par les entree e e e prises. Toutes les politiques de gestions de ressources dans lIaaS sappliquent uniquement a ce cluster. Toutes ses machines excutent lhyperviseur Xen dans ` e sa version 4.1 sous un syst`me Linux CentOS 5.6. Elles disposent de 4Go de e mmoire, dun processeur de type Intel Core 2 Duo 2.66GHz (un cur dsace e tiv). Les congurations lies a lhyperviseur Xen sont les suivantes : 512Mo de e e ` mmoire pour le dom0 (le syst`me Linux hte) ; et lalgorithme de scheduling e e o de VM est sched-credit [cre]. Un cluster (ClusterExterne dans la gure 10.1) constitu de 2 machines rsere e ves aux entreprises et clients des applications sexcutant dans le cloud. Ces e e machines sont identiques a celles du premier cluster. ` Tous les clusters utilisent le mme rseau IP et sont relis entre eux via un switch e e e 1Gb. La gure 10.1 rsume lorganisation de notre environnement. Pour nir, les e images de VM construites et utilises dans nos exprimentations sont de 2Go de e e taille (inuenceront le dploiement des VM) et utilisent une distribution CentOS e 5.6 de Linux. Elles sont construites de telle sorte que les machines rserves aux e e entreprises aient un acc`s SSH ne requrant aucun mot de passe (an de faciliter e e lacc`s de linstance TUNeEngine des entreprises vers leurs VM). e
10.1. ENVIRONNEMENTS DEXPERIMENTATION
125
Figure 10.1 Environnement matriel de notre IaaS e
10.1.2
Les applications entreprises : RUBIS
RUBIS [19] (Rice University BIdding System) est une implantation dune application J2EE de commerce lectronique. RUBIS est issu du projet JMOB [jmo] et e dvelopp par le consortium OW2 [ow2]. RUBIS repose sur un serveur web (Apache e e par exemple), un conteneur de servlet et/ou EJB (Tomcat et JBoss par exemple) et un serveur de base de donnes (MySQL par exemple). En parall`le, il fournit e e un simulateur de clients web permettant deectuer des benchmarck sur le site web implant par RUBIS. e RUBIS dnit 27 types dinteractions pouvant tre ralises par un client exe e e e terne. Les interactions les plus importantes sont celles de : consultation des produits par catgories/rgions, passer des ordres, acheter des produits, vendre des produits, e e poser des commentaires ou consulter son prol. La plupart des intractions (22) ne e cessitent la construction dynamique des pages. RUBIS permet de dnir deux prols de benchmarking : avec lecture de done nes uniquement ou avec 15% de lecture-criture de donnes. Dans le cadre de nos e e e exprimentations, nous utilisons le premier prole. e Le simulateur de clients web propos par RUBIS implante un comportement e proche de celui dun client humain dun site de commerce en ligne. Il permet le dmarrage de plusieurs clients web, chacun sexcutant dans une session de dure e e e prcise. A laide dune table de transition dnissant le prol de charge, chaque e e client met rguli`rement une requte a destination du site web RUBIS. Chaque e e e e ` client simule une dure de rexion entre chaque requte an de se rapprocher du e e e comportement humain. Cette dure est choisie alatoirement entre 7 secondes et 15 e e minutes suivant une distribution exponentielle ngative [34]. Lalgorithme de passage e dune requte web ` une autre est bas sur une matrice de transition contenant e a e des valeurs de probabilits observes dans la ralit. Enn, chaque client gn`re e e e e e e Syst`me dadministration autonome adaptable : application au Cloud e
10.2. EVALUATIONS
126
un ensemble de donnes statistiques rcapitulant son excution. Ces informations e e e contiennent le nombre derreurs survenues durant son excution, les performances e des serveurs J2EE, les types de requtes mises, etc. e e
10.1.3
Les mtriques e
Les expriences ralises durant cette th`se ont pour but de valider lutilisation e e e e du SAA TUNeEngine pour ladministration de la plateforme de cloud CloudEngine et des applications quelle hberge. Au niveau de lIaaS, les principales mtriques qui e e nous intressent sont : la charge CPU et le nombre de VM par machine physique. e La charge CPU comprend la consommation CPU de chaque VM, la consommation CPU du dom0 (syst`me hte avant linstallation de lhyperviseur) et la charge CPU e o de la machine physique qui est la somme de toutes les charges CPU des VM quelle hberge. e Au niveau des applications entreprises, nous nous intressons au dbit et au temps e e de rponse des requtes de lapplication RUBIS, observs au niveau du serveur web e e e Apache.
10.2
10.2.1
Evaluations
Rparation de VM e
Dans cette exprimentation, nous valuons les deux types de rparation que nous e e e avons dcrites dans la section 9.3.1 du chapitre prcdent. Il sagit de la rparation e e e e collaborative et non collaborative dont nous rappellerons bri`vement les principes e dans les sections suivantes. De faon gnrale, dans les expriences que nous ralisons pour lvaluation de c e e e e e la rparation, les pannes sont dtectes par linstance TUNeEngine de niveau IaaS. e e e Nous dmarrons lIaaS de telle sorte que les serveurs du MonitoringController, instale ls sur chaque machine de lIaaS, scrutent ltat des VM toutes les 2 secondes. Nous e e considrons quune VM est en panne lorsquelle ne rpond plus a une requte IP (la e e ` e commande ping ` partir dune autre machine) ou encore lorsque son hyperviseur a Xen indique un tat derreur. e Pour chacune des valuations des deux mthodes de rparation, nous excutons e e e e un benchmark RUBIS pyramidal (monte de charge, charge constante et baisse de e charge). Nous simulons une panne sur une VM hbergeant un serveur MySQL de e lapplication RUBIS excute. En outre, nous associons ` ces exprimentations une e e a e exprience particuli`re jouant le rle de rep`re. En eet, cette exprience sera utilise e e o e e e pour la comparaison des deux mthodes de rparation. Elle consiste en lexcution e e e dun benchmack RUBIS dans lequel aucune panne nest simule. La comparaison e Syst`me dadministration autonome adaptable : application au Cloud e
10.2. EVALUATIONS
127
des deux mthodes de rparation est eectue sur la base du dbit en requtes et du e e e e e nombre derreurs observes durant chaque exprience. e e Pour nir, lapplication RUBIS excute dans cette exprience est compose de : e e e e 1 serveur Apache, 1 serveur Tomcat, 1 serveur MySQL-Proxy et 1 serveur MySQL. Les VM hbergeant ces serveurs sont congures de telle sorte quelles sexcutee e e rons chacune sur des machines distinctes. Cette conguration na aucune inuence particuli`re sur les rsultats de lexprimentation. e e e
10.2.1.1
Rparation non collaborative e
Nous dnissons la rparation non collaborative comme celle dans laquelle linse e tance TUNeEngine de lIaaS est lunique responsable du dpannage des VM. Dans e notre exprimentation, TUNeEngine dmarre sur chaque machine de lIaaS un sere e veur dont le rle est de sauvegarder toutes les 7 secondes ltat de chaque VM. Le o e choix de la frquence de sauvegarde ne doit pas tre ni trop petite, au risque de e e pnaliser lexcution de la VM (comme nous le verrons), ni grande au risque davoir e e un grand cart entre la VM dpanne et son tat avant la panne. Nous avons choisi e e e e une dure de 7 secondes en rapport avec la dure minimale dattente entre chaque e e mission de requte de client RUBIS. Les tats de VM sauvegards sont stocks, e e e e e non pas sur le serveur NFS, mais sur la machine hbergeant la VM. Ces sauvegardes e seront transfres avec la VM lors des oprations de consolidation. ee e La gure 10.2 montre la comparaison entre lexprimentation rep`re (courbe e e rouge) et lexprimentation avec rparation par checkpointing (courbe verte) dans e e laquelle aucune panne na t simule. Cette gure nous permet uniquement dobseree e ver limpact du checkpointing de VM sur les performances de lapplication RUBIS sexcutant dans le cloud. Nous observons une baisse de dbit de requtes traites e e e e dans ce type de rparation : courbe rouge au dessus de la courbe verte. Nous vae e luons cette baisse de dbit a 46% environ. Elle est due a larrt rgulier des VM lors e ` ` e e du checkpointing dans lIaaS. En eet, le checkpointing implant par Xen provoque e lindisponibilit de la VM pendant sa sauvegarde. Ainsi, toutes les requtes en die e rection ou ` lintrieur de cette VM sexcuteront apr`s la sauvegarde. Ceci explique a e e e galement de grandes uctuations du dbit sur la courbe verte. e e La gure 10.3 prsente le rsultat de lapplication de la mthode de rparation e e e e de VM par checkpointing dans le cloud, avec simulation de pannes sur la VM du serveur MySQL. Linstant Tp reprsente linstant auquel la panne a t provoque e ee e tandis que linstant Tr marque la n de la rparation. La dure de rparation dans e e e cette exprience est denviron 22 secondes. Cette dure comprend le temps coul e e e e avant la dtection de la panne et galement la dure de redmarrage de la VM a e e e e ` partir de son dernier tat sauvegard. e e Nous constatons galement dans cette exprimentation quaucune requte nest e e e perdue a la fois pendant les sauvegardes de VM que pendant la rparation. En eet, ` e pour ce qui est de la sauvegarde, le protocole TCP/IP sur lequel repose notre rseau e se charge de rmettre une requte lorsque celle-ci na pas abouti. Ainsi, durant ee e Syst`me dadministration autonome adaptable : application au Cloud e
10.2. EVALUATIONS
128
Figure 10.2 Cot du checkpointing dans la rparation de VM dans lIaaS u e la sauvegarde, lindisponibilit ngligeable de la VM nentra pas la rupture des e e ne communications TCP/IP et celles-ci sont reprises a la n de la sauvegarde. Quant ` a la non perte de requtes durant la rparation, elle sexplique par le comportement ` e e du client RUBIS. En eet, il rmet en cas derreur la mme requte 6 fois toutes ee e e les secondes, ce qui laisse le temps a la rparation (dmarrage de la VM avec son ` e e ancien tat) de se raliser. Notons que pour certaines applications comme MPI, e e lindisponibilit de la VM (mme ngligeable), suivit du changement dtat de la e e e e VM ne saurait tre tolre. e ee
10.2.1.2
Rparation collaborative e
La seconde mthode de rparation est dite collaborative dans la mesure o` les e e u oprations de rpartition sont ralises ` la fois par linstance TUNeEngine de niveau e e e e a IaaS et linstance TUNeEngine de niveau application entreprise. En eet, linstance TUNeEngine de niveau IaaS dtecte la panne de VM, redmarre la VM a partir de e e ` son image initiale et fait appel a linstance TUNeEngine propritaire de la VM pour ` e naliser la rparation. Linstance TUNeEngine de niveau application est quant a elle e ` charge de : dployer sur la VM redmarre les logiciels qui y sexcutaient avant la e e e e e panne ; congurer et dmarrer ces logiciels. La taille des logiciels a dployer ainsi que e ` e la dure dexcution des programmes de conguration et de dmarrage des logiciels e e e sur la VM inuencent la dure de la rparation. e e
10.2. EVALUATIONS
129
Figure 10.3 Rparation de VM de lIaaS par checkpointing e La gure 10.4 prsente deux courbes : la courbe rouge reprsente lexprimene e e tation rep`re tandis que la courbe verte reprsente le rsultat de lexprimentation e e e e avec panne et rparation collaborative. Nous constatons que cette mthode de re e e paration, contrairement a la prcdente, na aucun impact sur les performances de ` e e lapplication RUBIS lorsquaucune panne nintervient. Cette constatation est visible sur la gure 10.4 dans les zones (1) et (3). La zone (2) reprsente la dure de la e e rparation. Elle inclut : le temps de dtection de la panne, la dure de dploiement e e e e et de redmarrage de la VM, la dure de la copie des binaires du serveur MySQL e e sexcutant sur la VM et enn la dure de redmarrage du serveur MySQL. Pour e e e ces raisons, nous constatons dans cette exprience, une rparation en 5 minutes 30 e e secondes. Cette dure importante de la rparation entra une perte de requtes au e e ne e niveau des clients RUBIS. Cette perte est de deux ordres : Des pertes lies aux requtes eectivement mises par le client RUBIS, mais e e e heurtes a lindisponibilit du serveur MySQL. Nous valuons cette perte a e ` e e ` environ 0.12% des requtes excutes. La valeur ngligeable de cette perte e e e e vient dune part du fait que chaque client RUBIS met 6 fois la mme requte e e e en cas derreurs, avec une pause dune seconde entre chaque tentative. Dautre part, les timeout des serveurs J2EE impliqus dans ces requtes sont suprieurs e e e a la minute. ` En comparaison avec lexprimentation rep`re, nous observons la rduction du e e e nombre globale de requtes excutes durant cette exprience. Nous estimons e e e e cette rduction a environ 23% de requtes traites dans lexprimentation ree ` e e e p`re. Cette valeur sexplique par la perte de temps des clients RUBIS dans e leurs tentatives de rmission de requtes pendant la dure de la rparation. ee e e e
10.2. EVALUATIONS
130
Notons que lutilisation dun serveur miroir, gnralement pratique dans les applie e e cations, permettra de palier cette latence importante. Dans certains cas, ce miroir est mis en place par lIaaS. Cest le cas de la plateforme de cloud Windows Azure que nous avons prsent dans la section 7.2.4 du chapitre etatDeLart. e e
Figure 10.4 Rparation collaborative de VM e
10.2.2
Scalabilit et Consolidation e
Pour ces valuations, la gure 10.5 rsume les direntes situations que nous e e e exprimentons. Elle montre galement pour chaque situation, les mtriques sur lese e e quelles les prises de dcision sont bases. e e
10.2.2.1
Scalabilit e
Le but de cette exprimentation est de montrer lutilisation de TUNeEngine e pour lallocation dynamique de ressources (VM) au niveau de lapplication RUBIS dans le cloud. La consolidation au niveau CloudEngine est neutralise. Son instance e TUNeEngine soccupe uniquement du placement des VM pendant leur dmarrage. e Lapplication RUBIS ainsi que la sonde de monitoring des serveurs MySQL sont congures de la faon suivante : e c 1 serveur Apache reli ` 2 serveurs Tomcat. Ces derniers sont relis a 1 serveur ea e ` MySQL-Proxy qui distribue des requtes a 1 serveur MySQL (initialement). e ` Syst`me dadministration autonome adaptable : application au Cloud e
10.2. EVALUATIONS
131
Figure 10.5 Rcapitulatif de quelques situations ncessitant scalabilit et de e e e consolidation dans le cloud et les applications quil hberge e La sonde dobservation du tiers MySQL obtient du MonitoringController de linstance TUNeEngine de lIaaS les informations sur la charge CPU des VM hbergeant les serveurs MySQL. Elle dclenchera lajout dun nouveau serveur e e MySQL lorsque la charge CPU du tiers MySQL (moyenne des charges CPU des serveurs MySQL) sera suprieure ` 60%. Inversement, elle dclenchera le e a e retrait dun serveur MySQL lorsque le tiers MySQL aura une charge CPU infrieure a 10%. Lordre de retrait des serveurs MySQL est lordre inverse des e ` ajouts. Autrement dit, le dernier serveur ajout sera le premier retir. Le seuil e e de charge CPU maximum est x ` 60% parce quil correspond, apr`s plusieurs ea e tests, au seuil pour lequel le dbit en requtes traites par lapplication RUBIS e e e ne progresse plus. Cette limitation est due a une saturation de la taille mmoire ` e des VM hbergeant les serveurs MySQL (qui sont sollicits pour des requtes e e e de grande taille). Cette sonde pourrait tre couple a une sonde mmoire an e e ` e davoir une prise de dcision plus ecace. Quant au seuil minimum de 10%, il e est choisi parmi des valeurs possibles tel que le retrait dun serveur ne provoque pas le dpassement du seuil de 60% des serveurs restants. e Le nombre de clients RUBIS augmente/diminue de 50 toutes les minutes durant lexprience. e La gure 10.6 montre les rsultats obtenus durant cette exprimentation. La courbe e e verte montre lvolution du nombre de client RUBIS soumis ` lapplication RUBIS. e a La courbe noire montre lvolution de la charge CPU du tiers MySQl. Les autres e courbes montrent lvolution du nombre de VM sur chaque machine de lIaaS. Voici e linterprtation de ces courbes : e La premi`re partie correspond a la phase de dploiement des VM. Chaque e ` e machine de lIaaS hberge une VM. e La seconde phase correspond au dploient des binaires et au dmarrage du e e serveur MySQL sur sa VM. Le zone (a) correspond ` lajout dun nouveau serveur MySQL suivi de la a chute de la charge CPU du tiers MySQL. Cette chute est due au redmare rage du serveur MySQL-Proxy an de prendre en compte le nouveau serveur Syst`me dadministration autonome adaptable : application au Cloud e
10.2. EVALUATIONS
132
MySQL. De plus, nous constatons que la dcision dajouter un nouveau serveur e MySQL nest pas aussitt prise lorsque la charge CPU atteint 60%. En eet, o la sonde eectue plusieurs prises de charges CPU an davoir conrmation du dpassement du seuil. e La zone (b) correspond au retrait dun serveur MySQL apr`s que la sonde ait e constat une baisse de charge conrme en dessous de 10%. e e
Figure 10.6 Scalabilit de serveurs MySQL dans une application J2EE dans le e cloud
10.2.2.2
Consolidation
Apr`s lvaluation de lutilisation de TUNeEngine pour lallocation dynamique e e de ressources au niveau des applications entreprises dans le cloud (ce qui correspond a ce que faisait le syst`me TUNe, son inspirateur), montrons ` prsent comment TU` e a e NeEngine permet de grer par consolidation de VM les ressources de lIaaS. Nous e montons pour cette exprimentation un scnario montrant lutilit de la consolidae e e tion dans lIaaS. Comme nous lavons nonc dans la section 9.3.2.1 du chapitre e e prcdent, nous considrons un scnario excutant au niveau applicatif une seule ape e e e e plication. La version TUNeEngine dadministration de cette application nimplante aucune politique dallocation dynamique de ressources. Quant au niveau IaaS, nous utilisons une politique de placement de VM consistant a maximiser le nombre de ` VM par machine. Le but de cette exprience est de valider lexistence et lecacit e e Syst`me dadministration autonome adaptable : application au Cloud e
10.2. EVALUATIONS
133
du Scheduler de CloudEngine, dont le rle est de grer la consolidation des VM dans o e lIaaS. Pour cette exprimentation, lapplication RUBIS excute dans le cloud ainsi que e e e le Scheduler de lIaaS sont congurs de la faon suivante : e c 1 serveur Apache, 2 serveurs Tomcat, 1 serveur MySQL-Proxy et 2 serveurs MySQL. Toute VM hbergent un serveur RUBIS se voit allouer 512Mo de mmoire. e e Cette conguration fera tenir initialement toutes les VM sur la mme machine e physique (512Mo * 6 serveurs + 512Mo du dom0 = 3Go512Mo < 4Go, taille dune machine physique). Le Scheduler est congur pour retirer une VM dune machine physique lorsque e la charge CPU de cette machine dpasse 60%. Dans ce cas, la VM la moins e charge est dplace vers la machine de lIaaS la moins charge pouvant lace e e e cueillir. A linverse, le Scheduler regroupe des VM sur des machines selon la politique suivante. Soit Ma et Md les machines les moins charges de lIaaS e contenant des VM telles que Ma est plus charge que Md . Soit V Md , la VM la e moins charge de la machine Md . Si la charge de Ma additionne a la charge e e ` de V Md est infrieure ` 60% et que la taille mmoire de Ma additionne a la e a e e ` taille mmoire de V Md est infrieure ` 4Go, alors le Scheduler dplace V Md e e a e vers la machine Ma . Cette politique est une parmi tant dautres. Notons que le but de cette exprience nest pas de produire et dvaluer direntes polie e e tiques de consolidation. Les travaux raliss par le syst`me Entropy [59] sont e e e enti`rement consacrs ` cette problmatique. e e a e La gure 10.7 montre les rsultats de notre exprience : la gure 10.7(a) prsente e e e la variation des charges CPU sur les machines de lIaaS tandis que la gure 10.7(b) prsente le contenu de chaque machine de lIaaS en terme de nombre de VM par e machine. Sachant que la taille et le nombre de logiciels dploys dans cette exprience e e e sont xes, les variations de nombre de VM par machine dmontre la ralisation de e e la consolidation dans lIaaS coordonne par le Scheduler de CloudEngine. Ces deux e gures sont interprtes de la faon suivante : ee c La premi`re partie des courbes correspond au dploiement des VM dans lIaaS. e e Compte tenu de la politique de placement et de la taille des VM, toutes les VM sont dployes initialement sur la machine Node1. Ceci explique lobsere e vation dune charge CPU uctuante sur la courbe CPU de la machine Node1 et labsence de charge sur les autres machines de la gure 10.7(a). La premi`re e partie de la gure 10.7(b) montre galement ce regroupement de VM sur la e machine Node1. Pendant lexcution du benchmark RUBIS, nous observons un premier clatee e ment dune VM de la machine Node1 vers la machine Node4 lorsque la charge CPU de la machine Node1 dpasse le seuil de 60%. Ceci explique la prsence e e dune charge CPU sur la machine Node4 sur la gure 10.7(a)(1) et la prsence e dune VM sur cette machine a la gure 10.7(b)(1). Il en est de mme pour le ` e (2) des gures 10.7(a) et 10.7(b). Durant lexcution de ce benchmark, le Scheduler peut tre amen a regrouper e e e` les VM lorsque la charge dune machine le permet. Cest notamment le cas
10.2. EVALUATIONS
134
de la VM de la machine Node4 qui sera dplace vers la machine Node5 en e e mesure de supporter cette VM ` linstant reprsent sur la gure 10.7(a)(3). a e e Pour nir, les VM sont regroupes a la n de lexcution du benchmark sur un e ` e nombre restreint de machines. On peut remarquer que toutes les VM ne sont pas regroupes sur une unique machine physique comme initialement. Ceci e sexplique par le fait que la migration pratique par Xen (le syst`me de vire e tualisation utilis par lIaaS) dune VM ncessite 2 conditions : (1) la machine e e de destination dispose dassez de mmoire pour excuter la VM ` migrer ; (2) e e a la machine de destination dispose galement dun surplus de mmoire destie e ne a la ralisation de lopration de VM, consommatrice de mmoire. Cette e ` e e e consommation de mmoire est moins importante pendant la phase de dmare e rage dune VM que pendant lexcution. Ainsi, la machine Node5 hbergeant e e dj` toutes les autres VM, ne dispose pas assez de mmoire pour accueillir la ea e derni`re VM se trouvant sur la machine Node4. e 10.2.2.3 Scalabilit et Consolidation simultanes e e
Dans cette section, nous prsentons deux exprimentations dans lesquelles la e e consolidation au niveau de lIaaS et lallocation dynamique de ressources au niveau entreprise sont actives dans les deux instances de TUNeEngine. Nous avons justi e e dans la section 9.3.2.2 du chapitre prcdent le choix des deux scnarios que nous e e e exprimentons. e Scnario 1 : VM de taille xe et Scalabilit non ordonne e e e Rappelons quelques dnitions avant la description de lexprimentation : e e La scalabilit ordonne est la scalabilit dans laquelle les premiers serveurs e e e ajouts sont les derniers serveurs retirs. Dans cette exprience, nous avons choisi e e e dutiliser la scalabilit non ordonne au niveau application entreprise. Nous entene e dons par scalabilit non ordonne ici celle dans laquelle lordre de retrait des sere e veurs est le mme que lordre dajout (les premiers serveurs ajouts sont les premiers e e retirs). e Une VM de taille xe est une VM dont les quantits de ressources initialement e acquises par lentreprise nvoluent pas durant son cycle de vie. e Lobjectif de cette exprimentation est de montrer que lexcution dans le cloud e e dapplications pratiquant de la scalabilit non ordonne et utilisant des VM de e e tailles xes ncessite a limplantation des politiques de consolidation de VM au e ` niveau de lIaaS. Ainsi, linstance TUNeEngine de niveau entreprise implante la scalabilit non ordonne tandis que le Scheduler de CloudEngine est activ dans e e e linstance TUNeEngine de lIaaS. Dcrivons a prsent les congurations de lIaaS et e ` e des serveurs J2EE que nous utilisons dans le cadre de cette exprience. e Au niveau de lIaaS : La politique de placement de VM (lors du dmarrage) est le regroupement e maximum de VM par machine physique.
10.2. EVALUATIONS
135
Figure 10.7 Consolidation dans le cloud : (a) Evolution de la charge CPU sur les machines de lIaaS, (b) Evolution du nombre de VM par machine de lIaaS.
10.2. EVALUATIONS
136
Le Scheduler de lIaaS consolide les VM en fonction de leur quota de ressources (CPU ou mmoire). Ici, nous utiliseront le quota mmoire dans la mesure o` e e u toutes les VM disposent dun quota inni de CPU (0 ou 100). Au niveau application entreprise, nous excutons une seule application J2EE RUBIS e munie dune sonde associe au tiers MySQL. Les serveurs J2EE de cette application e sont congurs de la faon suivante : e c 1 serveur Apache dont la VM utilise 3Go de mmoire ; e 2 serveurs Tomcat, 1 serveur MySQL-Proxy, 1 serveur M ySQL1 dont chaque VM utilise 1.5Go de mmoire ; e La sonde dobservation du tiers MySQL provoque lajout dun serveur MySQL lorsque la charge CPU moyenne des serveurs MySQL est suprieure a 60%. e ` Inversement, elle provoque le retrait lorsque cette charge est infrieure ` 20%. e a N.B. Nous choisissons un seuil minimum de 20% au lieu de 10% comme dans la premi`re exprience pour la raison suivante : un seuil de 10% (qui entra e e nera une scalabilit presque a la n du benchmark) dans cette exprience ne laise ` e sera pas le temps dobserver leet de la consolidation (qui suit le scalabilit) e pendant le benchmark. La consolidation ntant pas value dans la premi`re e e e e exprience, ce seuil tait acceptable. e e Cette conguration entra nera linstance TUNeEngine de lIaaS a dployer les VM ` e hbergeant les serveurs RUBIS de la faon suivante (gure 10.8(a)) : e c Compte tenu de la taille mmoire de la VM dApache, une machine physique e enti`re (de taille 4Go) sera utilise pour son hbergement ; e e e Les 2 serveurs Tomcat seront hbergs sur une machine physique de telle sorte e e que cette machine ne pourra accueillir dautres VM ; Les serveurs MySQL-Proxy et M ySQL1 seront hbergs sur une machine phye e sique de telle sorte que cette machine ne pourra accueillir dautres VM ; La monte en charge du nombre de client web RUBIS entra e nera lajout dun serveur MySQL (M ySQL2 ), par linstance de TUNeEngine du niveau application. M ySQL2 sera excut par linstance TUNeEngine de niveau IaaS dans une nouvelle VM sur e e une nouvelle machine physique (gure 10.8(b)). Inversement, la baisse de charges en dessous du seuil minimal entra nera le retrait dun serveur MySQL, donc de la VM lhbergeant. Cest ` ce niveau que nous implantons la scalabilit non ordone a e ne : linstance TUNeEngine du niveau application excute une politique de retrait e e de MySQL de telle sorte que les serveurs retirs sont prioritairement les premiers e serveurs dmarrs. Cette politique se traduira dans notre exprience par le retrait e e e du serveur M ySQL1 . En consquence, la machine hbergeant la VM du serveur e e M ySQL1 se retrouvera avec une seule VM : celle hbergeant le serveur MySQLe Proxy (gure 10.8(c)). A cette tape, nous disposons de deux machines hbergeant e e deux VM dont les tailles permettent leur regroupement. Lexcution permanente du Scheduler de CloudEngine dans linstance TUNeEne gine de lIaaS regroupera les deux VM hbergeant M ySQL2 et MySQL-Proxy sur e une seule machine physique (gure 10.8(d)). N.B. Rappelons que lapparition de trous observe ici dans lexcution dune seule application dans le cloud sobserve e e galement dans une excution de plusieurs applications dans le cloud. La n dune e e application librera des ressources et favorisera pour la consolidation. e
10.2. EVALUATIONS
137
Figure 10.8 Scalabilit niveau application J2EE et Consolidation de VM niveau e IaaS : rsum de lexprimentation e e e La gure 10.9 montre les rsultats de lexprimentation ralise suivant le scnario e e e e e ci-dessus. La courbe en rouge montre lvolution du dbit de lapplication RUBIS e e vue de lextrieur (` partir du serveur Apache). Le rle de cette courbe est dune e a o part de prouver limplantation de la scalabilit au niveau applicatif et dautre part e de montrer le rapport entre la scalabilit et la consolidation au niveau IaaS. e Les autres courbes montrent lvolution du nombre de VM sur chaque machine de e lIaaS. Pour des raisons de lisibilit, nous ne prsentons pas sur ces courbes lvolution e e e de la charge client RUBIS ainsi que la variation CPU des serveurs MySQL (elles sont similaires aux courbes observes dans les expriences prcdentes). Linterprtation e e e e e des rsultats de cette exprience, prsents dans la gure 10.9, est la suivante : e e e e La premi`re phase correspond au dploiement des VM hbergeant les serveurs e e e J2EE. Le nombre de VM par machine correspond a la description que nous ` avons faite prcdemment. e e La monte en charge au niveau du tiers MySQL entra lajout dun noue ne veau serveur visible sur la gure 10.9 par le point (a). On constate dune part que la VM ajoute est dmarre sur une nouvelle machine (Node4). Dautre e e e part, la chute du dbit observe sur la courbe rouge correspond au temps de e e reconguration du serveur MySQL-Proxy pour la prise en compte du nouveau serveur MySQL. Le dcalage temporel entre lallocation dun nouveau serveur e et la reconguration de MySQL-Proxy sexplique par le fait que lallocation Syst`me dadministration autonome adaptable : application au Cloud e
10.2. EVALUATIONS
138
du nouveau MySQL comprend : la copie et le dmarrage de la VM devant e lhberger (2Go), le dploiement des binaires de MySQL (35Mo) sur la VM et e e dmarrage de MySQL. e La baisse de la charge au niveau du tiers MySQL entra le retrait dun serveur ne MySQL visible sur la gure 10.9 par le point (b). La chute du dbit correspond e au redmarrage du serveur MySQL-Proxy. Cette chute survient avant le retrait e de la VM hbergeant le serveur MySQL parce que nous recongurons le serveur e MySQL-Proxy avant de dclencher lopration de retrait qui prend plus de e e temps (arrt de la VM et undploiement de la VM). e e Le retrait de la VM entra la consolidation au niveau IaaS, visible sur la ne gure 10.9 par le point (c). On observe une lg`re inexion du dbit. Cette e e e inexion correspond a linstant de consolidation (par migration de VM). En ` eet, la migration provoque une grande activit sur les machines impliques, e e ce qui rduira le temps processeur allou aux VM qui sy excutent ( y compris e e e de la VM en cours de migration).
Figure 10.9 Scalabilit au niveau application J2EE et Consolidation de VM au e niveau IaaS Scnario 2 : VM de taille variable et Scalabilit ordonne e e e Dans cette exprimentation, la conguration de lIaaS et des serveurs J2EE (` e a lexception des serveurs MySQL et leur sonde) que nous utilisons est identique a ` celle utilise dans lexprience prcdente. Les VM hbergeant les serveurs MySQL e e e e e sont celles sur lesquelles nous appliquons la variation de taille. Nous dnissons e la taille dune VM par deux valeurs : quota CPU et quota mmoire qui lui sont e allous. Reprsentons cette taille par le couple [CPU=xxx ;Mmoire=yyy], avec xxx e e e le quota CPU et yyy le quota mmoire en mga octet. Ainsi, la taille maximale dune e e
10.2. EVALUATIONS
139
VM sera celle dune machine physique de lIaaS : [CPU=0 ;Mmoire=tailleRAMe TailleMmoireDom0]. Cette derni`re correspond a : e e ` un quota CPU de 0 ou 100 signie que la VM a le droit dutiliser toutes les ressources CPU de la machine qui lhberge. e le quota mmoire maximal dune VM est la taille mmoire de la machine e e physique lhbergeant a laquelle est soustraite la taille mmoire du dom0. e ` e Au niveau de lapplication RUBIS, la sonde charge dobserver le niveau dutie lisation du tiers MySQL utilise pour mtrique de dcision, le temps de rponse de e e e lapplication 1 . En eet, dans les expriences prcdentes, les charges CPU des VM e e e sont obtenues du MonitoringController de linstance TUNeEngine de gestion du cloud. Or, ces charges ne re`tent pas rellement la consommation CPU de la VM e e lorsque celle-ci est congure avec un quota CPU dirent de 0/100. La charge CPU e e de la VM, observ par les sondes de lIaaS a partir du dom0 des machines (sans e ` acc`s a la VM) ne correspond a la charge interne de la VM lorsque le quota de cette e ` ` VM est dirents de 0 ou 100. Cette charge reprsente en ralit lutilisation CPU e e e e de la VM vis a vis de lutilisation globale des processeurs de la machine physique. ` Lutilisation des quota empchera donc les sondes de lIaaS dobserver une charge e CPU suprieure au quota de la VM. e Au niveau IaaS, nous implantons un programme de reconguration (ResizeVM ) dont le but est dassigner a une VM de lIaaS la taille souhaite par son propritaire. ` e e Ce programme pourra dcider en cas de ncessit, de la migration de la VM de sa e e e machine dhbergement initiale, vers une autre machine pouvant supporter lauge mentation de la VM. Cette situation survient lorsque la machine hbergeant la VM e contient dautres VM telle que laugmentation de la taille de cette VM ne soit pas possible sur sa machine dorigine (manque de ressources sur la machine). Quant au Scheduler, il sexcute rguli`rement et consolide les VM lorsque des e e e trous (laisss par la modication des tailles de VM ou migration) sont constats e e sur les machines de lIaaS. Le scnario mis en place pour notre exprience est le suivant. Lorsque la sonde e e dobservation du tiers MySQL se rend compte du dpassement du temps de rponse e e dun seuil maximal (40 secondes dans notre cas), il dclenche dans linstance de e TUNeEngine dadministration de lapplication RUBIS, lexcution dun programme e de sizing. Ce dernier choisit la VM de plus petite taille et met en destination de e linstance TUNeEngine du Cloud, une requte daugmentation de la taille de cette. e Le programme de sizing est inform du succ`s ou de lchec de la ralisation de sa e e e e requte. Lchec peut tre due ` lindisponibilit de ressources dans le cloud ou lime e e a e possibilit daugmenter la taille de la VM car ayant atteint la taille maximale dune e machine physique. Dans ce cas, le programme de sizing demande lallocation dune nouvelle VM sur laquelle il dmarrera un nouveau serveur MySQL (scalabilit). Cette e e demande pourra galement choue si le cloud ne dispose plus de ressources. e e e Inversement, lobservation de la baisse du temps de rponse en dessous dun seuil e
1. Compte tenue de la conguration de nos serveurs J2EE, laugmentation du temps de rponse de lapplication dpend de la charge des serveurs MySQL. En eet les autres e e serveurs sont en sous charge durant toutes les exprimentations e
10.2. EVALUATIONS
140
minimal (5 secondes dans notre exprience) entra e nera la diminution de la taille de la VM ayant la plus grande taille. Le choix de cette politique permet de maintenir pendant la baisse de la charge, un quilibre de taille des serveurs MySQL. Il permet e de palier la non implantation de lquilibrage de charge au niveau du rpartiteur de e e charges MySQL-Proxy. Pour nir, la diminution de la taille dune VM jusqu` latteinte de sa taille mia nimale (xe dans notre exprience a [CPU=50 ;Mmoire=512]) entra son retrait e e ` e ne de larchitecture J2EE sil existe dautres serveurs MySQL. Notons quapr`s le ree trait dune VM, le Scheduler de niveau cloud interviendra pour raliser dventuelles e e consolidations provoques par les variations des tailles des VM. e Dans cette exprience, lapplication RUBIS est dploy initialement avec un e e e unique serveur MySQL de taille [CPU=50 ;Mmoire=512]. La sonde de monitoring e dclenche laugmentation (respectivement la diminution) de la taille du plus pee tit (respectivement du plus grand) serveur MySQL de 25 quota de CPU et 512Mo quota de mmoire. Lexcution de la VM hbergeant la premi`re instance de serveur e e e e MySQL (M ySQL1 ) seectue sur la mme machine que le serveur MySQL-Proxy (e gure 10.10(a)) comme dans lexprience prcdente. Avec laugmentation du temps e e e de rponse, due a laugmentation du nombre de clients RUBIS, la taille de M ySQL1 e ` passera successivement de [CPU=50 ;Mmoire=512] a [CPU=75 ;Mmoire=1024] puis e ` e [CPU=100 ;Mmoire=1536]. Cette derni`re taille de M ySQL1 , ne pouvant tenir e e sur la machine lhbergeant initialement (car ncessitant les capacits CPU dune e e e machine enti`re), la VM lhbergeant sera migrer vers une nouvelle machine (e e gure 10.10(b)). Ensuite, laugmentation de la charge entra nera lajout dun nouveau serveur MySQL (M ySQL2 ) (associ a une nouvelle nouvelle VM). Lexcution de e` e la VM de M ySQL2 dbute avec la taille minimale. Ainsi, le ResourceAllocator de e CloudEngine fournira comme machine dexcution de cette VM, la machine hbere e geant le serveur MySQL-Proxy (gure 10.10(c)). Inversement, lorsque le nombre de client RUBIS baisse et entra une amliorane e tion du temps de rponse, les tailles des VM des deux serveurs MySQL sont rduites e e selon la politique dcrite ci-dessus. On constatera une consolidation de VM par le e Scheduler au niveau du cloud (gure 10.10(d)). La gure 10.11 montre les rsultats de notre exprimentation. En rouge, nous pre e e sentons la variation du temps de rponse de lapplication. Les deux autres courbes e montrent lvolution du nombre de VM sur les machines de lIaaS hbergeant les sere e veurs MySQL. La courbe montrant lvolution du nombre de clients RUBIS nest pas e prsente dans cette gure car elle est similaire a celle des expriences prcdentes. e e ` e e e Linterprtation de cette gure est la suivante : e En (a) nous observons laugmentation de la taille de la VM hbergeant M ySQL1 . e Cette VM passe a une taille de [CPU=75 ;Mmoire=1024]. Cette augmenta` e tion permet damliorer le temps de rponse (observable par la baisse du temps e e de rponse). Cette baisse ne provoque pas la diminution de la taille de la mae chine. En eet, pour dclencher la diminution de la taille de la machine, nous e imposons une priode de dcision susamment long pour viter les eets yo-yo. e e e
10.2. EVALUATIONS
141
Figure 10.10 Scalabilit niveau application J2EE avec VM de taille variable et e Consolidation de VM niveau IaaS : rsum de lexprimentation e e e En (b) nous observons une autre augmentation de la taille de la VM de M ySQL1 . Elle passe a [CPU=100 ;Mmoire=1536]. Cette augmentation sef` e fectue apr`s la migration de cette VM de la machine Node3 vers la machine e Node4 a cause de la ncessit dobtenir un quota CPU de 100, autrement ` e e dit, une machine enti`re. Cette augmentation de la taille de la VM par contre e nentra pas une baisse signicative du temps de rponse. En eet, le nombre ne e important de requte RUBIS mises ` ce stade du benchmark empche les sere e a e veurs davoir du repos. Cest ce que nous observons en (c). En (c) nous observons une monte du temps de rponse qui entra lajout e e ne dune nouvelle VM dexcution dun nouveau serveur MySQL (M ySQL2 ). e Cette VM sexcute sur la machine Node3 compte tenue de sa petite taille e initiale. En (d), les uctuations de temps de rponses sont dues ` la prsence de deux e a e serveurs MySQL de tailles direntes, alors que le nombre de requtes mis e e e est important. En eet, la petite VM fournit un temps de rponse suprieure e e a celui de la grande VM. De plus, les requtes ne sont pas intelligemment ` e distribues aux deux serveurs en fonction de leur taille. Une exprimentation e e plus aboutie pourra prendre en compte la reconguration du rpartiteur de e requtes MySQL-Proxy an que celui-ci sollicite les serveurs en fonction de e leur taille. Syst`me dadministration autonome adaptable : application au Cloud e
10.2. EVALUATIONS
142
Apr`s cette ajout du serveur MySQL, lIaaS nacceptera plus dajout de VM e tant que des ressources supplmentaires ne lui seront pas alloues (ou en cas e e de libration de ressources). e En (e) nous observeront laugmentation de la taille de la VM de M ySQL2 jusqu` la taille [CPU=75 ;Mmoire=1024]. LIaaS ne peut aller au del` de a e a cette taille dans la mesure o` aucune machine ne peut fournir une quantit de u e ressources pouvant supporter une VM de taille [CPU=100 ;Mmoire=1536]. e Par soucis de lisibilit des courbes, nous avons limit les valeurs de temps e e de rponse sur la courbe rouge au seuil maximal de 40 secondes. Les valeurs e suprieures a ce seuil, reprsentes par la zone (e), ne sont pas visibles dans la e ` e e gure. En (f) nous observons que la diminution des tailles des VM de M ySQL1 et M ySQL2 provoquera la consolidation de la VM de M ySQL1 sur la machine Node3. Pour nir, la baisse continuelle de la charge provoquera le retrait dun serveur MySQL (M ySQL2 , car scalabilit ordonne), ainsi que de sa VM. e e
Figure 10.11 Scalabilit au niveau application J2EE et Consolidation de VM de e tailles variables au niveau IaaS
` 10.3. SYNTHESE
143
10.3
Synth`se e
Dans ce chapitre, nous avons prsent direntes valuations des aspects de lade e e e ministration dune plateforme de cloud simplie CloudEngine avec le SAA TUe NeEngine. Ces valuations ont galement pris en compte ladministration par TUe e NeEngine des applications sexcutant dans le cloud. Les aspects de ladministration e que nous avons valus sont : e e Deux politiques de rparation de VM dans le cloud. La premi`re mthode e e e dite non collaborative rduit lecacit des applications sexcutant dans le e e e cloud. Quant ` la seconde, son impact nest visible que lorsque survient une a panne de VM. Comme nous lavons voque, cet impact peut tre minimis e e e e par lintroduction de serveurs miroirs. Une politique de scalabilit au niveau application entreprise : nous avons mone tr comment le syst`me TUNeEngine peut tre utilis pour implanter la scae e e e labilit de serveurs dans le cloud an dallouer ecacement des VM. e Une politique de consolidation : nous avons montr lutilisation de TUNeEne gine dans le cloud pour limplantation dune politique de consolidation lorsque les VM rserves par les entreprises ne sont pas utilises ecacement (sous e e e utilises). e Pour nir, nous avons valu deux scnarios mettant en valeur les apports dune e e e gestion simultane de ressources par plusieurs les deux niveaux dutilisation de e TUNeEngine dans le cloud : consolidation au niveau de lIaaS et scalabilit au e niveau application entreprise. Le but de ces expriences na pas t dvaluer de faon exhaustive tous les scnae ee e c e rios dadministration avec TUNeEngine dans le cloud. Il sagissait de prouver dune part laspect fonctionnel de TUNeEngine et dautre part son adaptation ` dirents a e scnarios dadministration. e
Chapitre 11 Conclusion et perspectives

Contents
11.1 Conclusion . . . . . . . . . . . . . . . . . . . . 11.2 Perspectives . . . . . . . . . . . . . . . . . . . . 11.2.1 Perspectives ` court terme . . . . . . . . . . . a 11.2.2 Perspectives ` long terme . . . . . . . . . . . a . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 146 146 148
11.1
Conclusion
Ces deux derni`res annes ont vu le dveloppement dune nouvelle pratique dhe e e e bergement : le Cloud Computing. Le principe fondateur de cette pratique est de dporter la gestion des services informatique des entreprises dans des centres dhe e bergement grs par des entreprise tiers. Ce dport a pour principal avantage une ee e rduction des cots pour lentreprise cliente, les moyens ncessaires ` la gestion de e u e a ces services tant mutualiss entre clients et grs par lentreprise hbergeant ces e e ee e services. Cette volution implique la gestion de structures dhbergement ` grande e e a chelle, que la dimension et la complexit rendent diciles ` administrer. Prsent e e a e e dans la littrature comme une nouvelle technologie, nous retenons de ltude du e e Cloud Computing quil sagit globalement dune plateforme de grille ou centre dhe bergement fournissant a ses clients des services de plus ou moins haut niveau. ` Ltude des probl`mes que nous avons mene autour du Cloud Computing fait e e e ressortir deux dicults majeures : lisolation (des dfaillances, des ressources, des e e utilisateurs) et ladministration dans son ensemble (y compris les applications quil excutent). Ces deux ds jouent un rle important dans le processus de vulgarisation e e o et dadoption du cloud aupr`s des entreprises clientes. Comme nous lavons prsent e e e dans ce document, le d disolation est rsolu dans la plupart des plateformes de e e cloud par lutilisation des syst`mes de virtualisation comme couche intermdiaire e e entre les ressources du cloud et les clients. Quant ` ladministration dans le cloud, a ltude des travaux de recherches eectus dans ce domaine montre que la majorit e e e
11.1. CONCLUSION
145
des plateformes de cloud ne prennent pas en compte tous les aspects de ladministration. Cette tude rv`le notamment des besoins dadministration a des niveaux e e e ` dirents (hbergeur, client). e e Notre contribution dans ce contexte a t de fournir, sur les bases dun syst`me ee e dadministration autonome (SAA), une plateforme permettant dadministrer ` la fois a des plateformes quelconques de cloud ainsi que les applications entreprises quelles hbergent. Notre choix port sur lutilisation dun SAA a t naturellement motiv e e ee e par laptitude quont montrs les SAA a fournir des solutions dadministration dans e ` des infrastructures de grilles, proches du cloud. Cest ainsi que nous avons entrepris dutiliser notre SAA TUNe pour ladministration dans le cloud. La dicult dadaptation du syst`me TUNe pour le cloud nous a amen ` concee e ea voir et ` implanter une nouvelle plateforme hautement adaptable et gnrique de a e e telle sorte quelle pourra prendre en compte dirents domaines applicatifs (parmi e lesquels le cloud). Nous avons propos dans cette th`se un mod`le de conception et de dveloppee e e e ment des SAA hautement adaptables et gnriques. Dans un premier temps, nous e e avons identi un ensemble de crit`res essentiels que devront respecter de tels syse e t`me. Il sagit de luniformit des lments administrs (revenant a ne pas ger e e ee e ` certains mcanismes dans le SAA), de ladaptabilit du SAA et de sa capacit a e e e ` collaborer/interagir avec dautres SAA. Ensuite, nous avons prsent un mod`le are e e chitecturale prenant en compte ces crit`res et remplissant les services dun SAA. e Pour valider ce mod`le, nous avons dvelopp un SAA (inspir de TUNe) et conu e e e e c selon notre approche. Il sagit en quelque sorte dun exoSAA baptis TUNeEngine. e Ce dernier a par la suite t adapt (crit`re dadaptabilit) an de prendre en compte ee e e e ladministration des plateformes de cloud. En ce qui concerne ladministration dans le cloud, nous avons conu une platec forme simplie de cloud (CloudEngine), dont les composants sont clairement idene tiables (contrairement aux autres plateformes), an de montrer la prise en compte de toutes les facettes de ladministration dans le cloud. Ainsi, nous avons adapt e le syst`me TUNeEngine pour la ralisation des tches dadministration suivantes : e e a construction dimages de VM et tlchargement dans le cloud ; dploiement, conee e guration, et dmarrage des services de CloudEngine ; dploiement et dmarrage des e e e machines virtuelles dans le cloud ; rparations des machines virtuelles ; et intgration e e de quelques politiques dallocation de ressources dans le clouds. Dans le mme ordre e dides, nous avons montr comment le syst`me TUNeEngine peut tre utilis pour e e e e e ladministration des applications entreprises dans le cloud. Cette utilisation va de linteroprabilit avec le cloud pour lallocation dynamique des machines virtuelles, e e au dploiement et suivi de lexcution des applications dans le cloud. e e Pour nir, nous avons identi quelques scnarios dvaluations de notre SAA e e e TUNeEngine appliqu a la plateforme de cloud CloudEngine, ce qui correspond a e` ` notre problmatique initiale. Cest ainsi que nous avons valu dans un premier e e e temps deux mthodes de rparations de VM dans le cloud. Ensuite, nous avons e e explor quelques scnarios de consolidation de VM dans le cloud pour une gestion e e
11.2. PERSPECTIVES
146
ecace de lutilisation des ressources. Enn nous avons montr comment la gestion e de ressources dans le cloud est lie a celle ralise par les applications entreprises e ` e e quil hberge. Nous constatons par exemple que certaines mthodes de scalabilit ou e e e dallocation de VM au niveau application entreprise sont propices a la consolidation ` au niveau du cloud.
11.2
Perspectives
Tout au long de la ralisation de cette th`se, nous avons identi dirents axes e e e e potentiels de prolongement de nos travaux. Ces axes concernent a la fois les travaux ` autour du cloud et de notre SAA adaptable TUNeEngine. Ces axes peuvent tre e classs en deux catgories : les travaux ralisables dans un futur proche, et ceux e e e ralisables dans un futur plus lointain compte tenu de leur ampleur. e
11.2.1
Perspectives ` court terme a
Clouds Existants Administration des Clouds Existants : Une prochaine validation de ladaptabilit de notre SAA TUNeEngine, pourra consister a lutiliser pour lamlioration e ` e de ladministration des plateformes de cloud existantes. A ce sujet, nous avons initi e une adaptation de TUNeEngine pour lencapsulation des services de la plateforme de cloud OpenNebula [OpenNebula]. Ce travail, non rapport dans ce document de e th`se, est prometteur dans la mesure o` cette personnalisation de TUNeEngine pour e u OpenNebula permet notamment (` ce stade) denrichir les capacits de reconguraa e tion de VM, jusque l` dicilement intgrables dans OpenNebula. a e Clouds hybrides : Administre par TUNeEngine, notre plateforme de cloud e CloudEngine se contente actuellement du composant de collaboration propos par e le syst`me TUNeEngine pour linteraction avec des syst`mes externes. Cette collaboe e ration a t exprimente uniquement dans le contexte o` les syst`mes externes sont ee e e u e galement administrs par TUNeEngine. Nous proposons dtendre ces exprimene e e e tations a dautres plateformes externes utilisant dautres syst`mes dadministration ` e comme Eucalyptus [80] ou OpenNebula [OpenNebula]. Une premi`re approche de e cette interoprabilit pourra consister a tendre le composant de collaboration de e e ` e TUNeEngine, utilis par CloudEngine, par des API WSDL compatible EC2. Dans e lattente dune standardisation des API dinteroprabilit, EC2 est utilis actuellee e e ment par plusieurs plateformes de cloud. Intgration de programmes de reconguration e Dans sa premi`re validation, le syst`me TUNeEngine reprend et ore tous les e e services du syst`me TUNe. En particulier, sa prise en compte des programmes de e reconguration ncessite la description du programme sous forme dautomates. Dans e le cadre dune collaboration courante avec le Laboratoire Informatique de Grenoble Syst`me dadministration autonome adaptable : application au Cloud e
11.2. PERSPECTIVES
147
(LIG), les composants dinterprtation et dexcution des programmes de recongue e ration ont t adapts pour la prise en compte des programmes de reconguration ee e implants sous forme de programmes Java. En eet, nos collaborateurs du LIG se e servent actuellement du syst`me TUNeEngine pour la prise en compte dynamique de e programmes de coordination de boucles de contrles dans le syst`me TUNeEngine, o e gnrs par un syst`me externe. e ee e Construction dimages Limplantation actuelle de notre plateforme de cloud ainsi que son constructeur dimages de VM se limitent aux distributions Linux CentOS. En eet, les techniques de construction dimages et dinitialisation rseau des machines virtuelles dpendent e e du type dOS contenu dans limage. Dans ce premier prototype, nous nous sommes limits dans nos travaux a une unique distribution. Dans le futur, nous comptons e ` tendre cette construction dimages a dautres distributions Linux. Dans lattente e ` dun langage standard dexpression de contenu dimages de VM, nous pourrons nous appuyer sur le format de description dimages OVF (Open Virtual Format) de VMWare (le plus tendu). e Prise en compte dautres hyperviseurs Dans notre implantation actuelle, le VMController (charg de linterfaage avec e c les hyperviseurs) de CloudEngine ne prend en compte que les hyperviseurs de type Xen. Nous comptons faire voluer limplantation de ce composant via lutilisation e des librairies de virtualisation libvirt [lib]. De cette faon, nous pourront tendre c e CloudEngine pour la prise en compte des autres syst`mes de virtualisation. e Gestion des utilisateurs Pour nir, la gestion des utilisateurs na pas gur parmi nos proccupations e e initiales. Dans la suite, nous pourront associer a CloudEngine un module de gestion ` dutilisateurs et dauthentication. Ainsi, il pourra fournir a chaque utilisateur des ` modes de gestion personnalise de VM. e Intgration dEntropy e Malgr leur pertinences, les politiques de consolidation et de placement de VM e dans notre plateforme actuelle de cloud sont simplistes. En eet, elles ne reprsentent e pas le cur de nous proccupations dans ce travail de th`se. Cependant, il est envie e sageable dintgrer dans la personnalisation TUNeEngine pour ladministration du e cloud, un syst`me plus volu de gestion de ressources dans le cloud. Le syst`me e e e e Entropy [59], situ dans cette catgorie, constitue une perspective intressante. e e e Auto rparation de TUNeEngine e Dans son implantation actuelle, le syst`me TUNeEngine ne peut rsister a une e e ` panne dun de ses composants. Lapparition dune telle panne paralyserait le syst`me. e Une amlioration de TUNeEngine pour la tolrance aux pannes pourrait consister e e a utiliser limplantation Fractal HA pour la construction de ses composants. En ` eet, Fractal HA fournit un mcanisme de rplication de composants et maintien la e e
11.2. PERSPECTIVES
148
cohrence entre les rplicas. De cette faon, un composant en panne sera remplac e e c e par son rplica et ce dernier sera dupliqu de nouveau. e e
11.2.2
Perspectives ` long terme a
Edition de DSL TUNeEngine nest actuellement utilisable quau travers dinterfaces de bas niveau que sont lADL et les API de Fractal. Dans le cadre de notre projet de recherche, une autre th`se sintresse ` la conception dun environnement permettant la conception e e a de DSL. Comme nous lavons voqu dans ltude des problmatiques du syst`me e e e e e TUNe (inspirateur de TUNeEngine), cette plateforme de conception de DSL ge nrera pour chaque langage les adaptations ncessaires a leur prise en compte par e e ` TUNeEngine. Autrement dit, ` chaque DSL sera associe une personnalisation de a e TUNeEngine. De cette faon, nous pourront notamment dnir un langage dexpresc e sion de besoin dadministration dans le cadre du Cloud.
Bibliographie
149
Bibliographie
[abl] Able : Architecture based languages and environments. http://www.cs.cmu. edu/able/. [cla] Claudia platform. http ://claudia.morfeo-project.org/. [cen] The community enterprise operating system. http ://www.centos.org/. [cre] Credit-based cpu scheduler. http://wiki.xensource.com/xenwiki/CreditScheduler. [das] Darpa /afrl dasada. http://www.if.afrl.af.mil/tech/programs/dasada/. [6] Debian. http ://www.debian.org/index.fr.html. [7] Debootstrap. http ://wiki.debian.org/Debootstrap. [hap] Haproxy : The reliable, high performance tcp/http load balancer. http ://haproxy.1wt.eu/. [jbo] JBoss. http ://www.jboss.org/. [kad] Kadeploy : Grid5000 project. http ://kadeploy.imag.fr/index.html. [jmo] Object web open source midelware. http://jmob.ow2.org/. [ora] Oracle cloud computing. http ://www.oracle.com/us/technologies/cloud/index.htm. [ow2] Ow2 : The open source community for infrastructure software. http://www. ow2.org/. [top] Topcased : The open-source http ://www.topcased.org/. [uml] The user-mode linux linux.sourceforge.net/index.html. kernel. toolkit for critical systems.
http
://user-mode-
[vgr] The vgrads project. http ://vgrads.rice.edu/. [lib] The virtualization api. http://libvirt.org/. [18] Agarwal, M., Bhat, V., Liu, H., Matossian, V., Putty, V., Schmidt, C., Zhang, G., Zhen, L., Parashar, M., Khargharia, B., and Hariri, S. (2003). Automate : Enabling autonomic applications on the grid. In IN : AUTONOMIC COMPUTING WORKSHOP, THE FIFTH ANNUAL INTERNATIONAL WORKSHOP ON ACTIVE MIDDLEWARE SERVICES (AMS 2003, pages 4857. IEEE Computer Society Press. [19] Amza, C., Cecchet, E., Chanda, A., Cox, A. L., Elnikety, S., Gil, R., Marguerite, J., Rajamani, K., and Zwaenepoel, W. (2002). Specication and Implementation of Dynamic Web Site Benchmarks. In EEE 5th Annual Workshop on Workload Characterization (WWC-5). Austin, TX. Syst`me dadministration autonome adaptable : application au Cloud e
Bibliographie
150
[20] Armstrong, R., Kumfert, G., McInnes, L. C., Parker, S., Allan, B., Sottile, M., Epperly, T., and Dahlgren, T. (2006). The cca component model for highperformance scientic computing. Concurr. Comput. : Pract. Exper., 18 :215229. [21] Bakshi, K. (2009). Cisco cloud computing - data center strategy, architecture, and solutions point of view white paper for u.s. public sector 1st edition. http ://www.cisco.com/web/strategy/docs/gov/CiscoCloudComputing WP.pdf. [22] Baresi, L., Ferdin, A. D., Manzalini, A., Baresi, L., Ferdinando, A. D., Manzalini, A., and Zambonelli, F. (2009). The cascadas framework for autonomic communications. In Autonomic Communication (Springer, Heidelberg and. [23] Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris, T., Ho, A., Neugebauer, R., Pratt, I., and Wareld, A. (2003). Xen and the art of virtualization. In ACM symposium on Operating systems principles (SOSP03), pages 164177, New York, NY, USA. ACM. [24] Berg, A. (2008a). Separate the static from the dynamic with Tomcat and Apache. Linux J., 2008(165) :9. [25] Bolze, R., Cappello, F., Caron, E., Dayd, M., Desprez, F., Jeannot, E., Jgou, e e Y., Lanteri, S., Leduc, J., Melab, N., Mornet, G., Namyst, R., Primet, P., Quetier, B., Richard, O., Talbi, E.-G., and Touche, I. (2006). Grid5000 : A Large Scale And Highly Recongurable Experimental Grid Testbed. Int. J. High Perform. Comput. Appl., 20(4) :481494. [26] Bouchenak, S., Boyer, F., Krakowiak, S., Hagimont, D., Mos, A., Jean-Bernard, S., de Palma, N., and Quema, V. (2005). Architecture-based autonomous repair management : An application to j2ee clusters. In SRDS 05 : Proceedings of the 24th IEEE Symposium on Reliable Distributed Systems, pages 1324, Washington, DC, USA. IEEE Computer Society. [27] Braham, P., Dragovic, B., Fraser, K., Hand, S., Haris, T., Alex, Neugebauer, R., Pratt, I., and Wareld, A. (2003). Xen and the art of virtualization. SOSP 03 : Proceedings of the nineteenth ACM symposium on Operating systems principles, 2 :14. [28] Broto, L. (2008). Support langage et syst`me pour ladministration autonome. e PhD thesis, INP Toulouse. [29] Broto, L., Hagimont, D., Stolf, P., Depalma, N., and Temate, S. (2008). Autonomic management policy specication in Tune. In SAC 08 : Proceedings of the 2008 ACM symposium on Applied computing, pages 16581663, New York, NY, USA. ACM. [30] Bruneton, E., Coupaye, T., Leclercq, M., Quma, V., and Stefani, J.-B. (2004). e An open component model and its support in java. In CBSE, pages 722. [31] Bruneton, E., Coupaye, T., Leclercq, M., Quma, V., and Stefani, J.-B. (2006a). e The FRACTAL component model and its support in Java : Experiences with Syst`me dadministration autonome adaptable : application au Cloud e
Bibliographie
151
Auto-adaptive and Recongurable Systems. Softw. Pract. Exper., 36(11-12) :1257 1284. [32] Bruneton, E., Coupaye, T., Leclercq, M., QuA ma, V., and Stefani, J.-B. (September 2006b). The fractal component model and its support in java. In Software - Practice and Experience, special issue on Experiences with Auto-adaptive and Recongurable Systems, 36(11-12) :1257-1284. [33] Caron, E. and Desprez, F. (2006). Diet : A scalable toolbox to build network enabled servers on the grid. International Journal of High Performance Computing Applications, 20(3) :335352. [34] Cecchet, E., Marguerite, J., and Zwaenepoel, W. (2002). Performance and scalability of ejb applications. In In Proceedings of the 17th ACM Conference on Object-oriented programming, systems, languages, and applications. [35] Chakravorty, S., Mendes, C. L., and Kal, L. V. (2006). Proactive fault tolerance e in mpi applications via task migration. In In International Conference on High Performance Computing. [36] Cheng, S.-W., Garlan, D., and Schmerl, B. R. (2009). Raide for engineering architecture-based self-adaptive systems. In ICSE Companion, pages 435436. [37] Chess, D. M., Segal, A., Whalley, I., and White, S. R. (2004). Unity : Experiences with a prototype autonomic computing system. In ICAC, pages 140147. [38] Christensen, E., Curbera, F., Meredith, G., and Weerawarana, S. (2001). Web services description language (WSDL) 1.1. W3c note, World Wide Web Consortium. [Cloud] Cloud, I. Ielo cloud. http ://www.ielo.net/solutions/externalisation/cloud/. [40] Combemale, B., Broto, L., Crgut, X., Dayd, M., and Hagimont, D. (2008). e e Autonomic Management Policy Specication : From UML to DSML. In Czarnecki, K., Ober, I., Bruel, J.-M., Uhl, A., and Vlter, M., editors, 11th Internatioo nal Conference on Model Driven Engineering Languages and Systems (MoDELS 2008), volume 5301 of LNCS, pages 584599. Springer. [CORDYS] CORDYS. http ://www.cordys.com. Cordys : Cloud provisioning software.
[Corporation] Corporation, I. Intel virtualization technology for directed i/o. http ://www.intel.com/technology/itj/2006/v10i3/2-io/2intro.htm ?iid=tech vt rsrc+art itj v10i3. [43] Cunin, P.-Y., Lestideau, V., and Merle, N. (2005). Orya : A strategy oriented deployment framework. In Component Deployment, pages 177180. [ElasticHosts] ElasticHosts. Elastic Hosts. http://www.elastichosts.com/.
Bibliographie
152
[45] Energy, W. E. . (2010). Microsoft, accenture and wsp environment & energy study shows signicant energy and carbon emissions reduction potential from cloud computing. Technical report, WSP Environment & Energy. [46] Engineers, G. S. (2009). Getting started : Java - google app engine. [facebook] facebook. http ://www.facebook.com. [Fedora] Fedora. Anaconda ject.org/wiki/Anaconda/Kickstart. kickstart. http ://fedorapro-
[49] Forester Research James Staten, with Simon Yates, F. E. G. (2008). Is cloud computing ready for the enterprise ? http ://www.forrester.com/rb/Research/is cloud computing ready for enterprise/q/id/44229/t/2 ?src=46613pdf. [50] Foster, I., Kesselman, C., Nick, J. M., and Tuecke, S. (2002). The physiology of the grid an open grid services architecture for distributed systems integration. [51] Foster, I. T., Zhao, Y., Raicu, I., and Lu, S. (2009). Cloud computing and grid computing 360-degree compared. CoRR, abs/0901.0131. [52] Foundation, T. A. S. Apache HTTP Server Project. http ://httpd.apache.org/. [53] Foundation, T. A. S. Shachor G Tomcat Documentation. The Apache Jakarta Project. http ://jakarta.apache.org/tomcat/tomcat-3.3-doc/. [54] Foundation, T. A. S. The http ://tomcat.apache.org/connectors-doc/. Apache Tomcat Connector.
[55] Garlan, D., Cheng, S.-W., Huang, A.-C., Schmerl, B. R., and Steenkiste, P. (2004). Rainbow : Architecture-based self-adaptation with reusable infrastructure. IEEE Computer, pages 4654. [56] Garlan, D., Monroe, R. T., and Wile, D. (2000). Acme : Architectural description of component-based systems. In Leavens, G. T. and Sitaraman, M., editors, Foundations of Component-Based Systems, pages 4768. Cambridge University Press. [57] Goldsack, P., Guijarro, J., Lain, A., Mecheneau, G., Murray, P., and Toft, P. (2003). Smartfrog : Conguration and automatic ignition of distributed applications. Technical report, HP. [58] Goth, G. (2007). Virtualization : Old technology oers huge new potential. IEEE Distributed Systems Online, 8(2). [59] Hermenier, F., Lorca, X., Menaud, J.-M., Muller, G., and Lawall, J. L. (2009). Entropy : a consolidation manager for clusters. In VEE09, pages 4150. [60] Horn, P. (2001). Autonomic computing : Ibms perspective on the state of information technology. Syst`me dadministration autonome adaptable : application au Cloud e
Bibliographie
153
[61] Inc, A. (2008). Amazon Elastic Compute Cloud (Amazon EC2). Amazon Inc., http ://aws.amazon.com/ec2/#pricing. [Inc.] Inc., R. U. Openstack cloud software : Open source software for building private and public clouds. http ://www.openstack.org/. [63] Kephart, J. O. (2005). Research challenges of autonomic computing. In ICSE 05 : Proceedings of the 27th international conference on Software engineering, pages 1522, New York, NY, USA. ACM. [64] Kephart, J. O. and Chess, D. M. (2003). The vision of autonomic computing. In IEEE Computer Magazine, 36-1. [65] Kesselman, C. and Foster, I. (1998). The Grid : Blueprint for a New Computing Infrastructure. Morgan Kaufmann Publishers. [66] Kneschke, J. (2007). Mysql proxy forge.mysql.com/wiki/MySQL Proxy Overview. overview. http ://-
[Labs] Labs, C. C. R. Hybridfox. http ://code.google.com/p/hybridfox/. [68] Lacour, S., Perez, C., and Priol, T. (2005). Generic application description model : Toward automatic deployment of applications on computational grids. In GRID 05 : Proceedings of the 6th IEEE/ACM International Workshop on Grid Computing, pages 284287, Washington, DC, USA. IEEE Computer Society. [69] Liu, H. and Parashar, M. (2003). Dios++ : A framework for rule-basedn autonomic management of distributed scientic applications. In Euro-Par, pages 6673. [70] Liu, H., Parashar, M., and Member, S. (2006). Accord : A programming framework for autonomic applications. IEEE Transactions on Systems, Man and Cybernetics, Special Issue on Engineering Autonomic Systems, Editors : R. Sterritt and T. Bapty, IEEE Press, 36 :341352. [71] Luckham, D. (2002). The Power of Events : An Introduction to Complex Event Processing in Distributed Enterprise Systems. Addison-Wesley Professional. [72] Martin, C. and Richard, O. (2003). Algorithme de vol de travail appliqu au e dploiement dapplications parall`les. In Actes Renpar 15. e e [73] Massie, M. L., Chun, B. N., and Culler, D. E. (2003). The ganglia distributed monitoring system : Design, implementation and experience. Parallel Computing, 30 :2004. [74] Microsoft. Hyper-v server 2008 r2. http ://www.microsoft.com/en-us/servercloud/hyper-v-server/default.aspx. [75] Microsoft. Microsoft exchange server 2007. http ://technet.microsoft.com/frfr/library/bb124558%28EXCHG.80%29.aspx.
Bibliographie [76] Microsoft. Windows azure : Microsofts http ://www.microsoft.com/windowsazure/. cloud services
154 platform.
[Mozilla] Mozilla. Mozilla refox. http ://www.mozilla.org/fr/refox/. [78] Murch, R. (2004). Autonomic Computing. IBM Press. [NASA] NASA. Nasa nebula cloud computing platform. http ://nebula.nasa.gov/. [80] Nurmi, D., Wolski, R., Grzegorczyk, C., Obertelli, G., Soman, S., Youse, L., and Zagorodnov, D. (2009). The eucalyptus open-source cloud-computing system. In Cappello, F., Wang, C.-L., and Buyya, R., editors, CCGRID, pages 124131. IEEE Computer Society. [81] OMG (2007). Unied Modeling Language (UML) 2.1.2 Superstructure. Object Management Group, Inc. Final Adopted Specication. [OpenNebula] OpenNebula. Opennebula.org : The open source toolkit for cloud computing. http ://opennebula.org. [83] Parashar, M. and Hariri, S. (2002). Pragma : An infrastructure for runtime management of grid applications. In Proceedings of the 16th International Parallel and Distributed Processing Symposium, IPDPS 02, pages 269, Washington, DC, USA. IEEE Computer Society. [84] Popek, G. J. and Goldberg, R. P. (1974). Formal requirements for virtualizable third generation architectures. In Commun. ACM, volume 17, pages 412421. [Rackspace] Rackspace, U. I. Cloud computing, cloud hosting & online storage by rackspace hosting. http ://www.rackspace.com/cloud/. [RIGHSCALE] RIGHSCALE. http ://www.rightscale.com/. Righscale : Cloud management platform.
[87] Rochwerger, B., Breitgand, D., Levy, E., Galis, A., Nagin, K., Llorente, I. M., Montero, R., Wolfsthal, Y., Elmroth, E., Cceres, J., Ben-Yehuda, M., Emmerich, a W., and Galn, F. (2009). The reservoir model and architecture for open federated a cloud computing. IBM J. Res. Dev., 53 :535545. [88] Sivathanu, M., Arpaci-Dusseau, A. C., and Arpaci-Dusseau, R. H. (2002). Evolving rpc for active storage. In Proceedings of the 10th international conference on Architectural support for programming languages and operating systems, ASPLOSX, pages 264276, New York, NY, USA. ACM. [89] Sotomayor, B., Montero, R. S., Llorente, I. M., and Foster, I. (2009). Virtual infrastructure management in private and hybrid clouds. IEEE Internet Computing, 13 :1422. [90] Tchana, A., Temate, S., Combemale, B., Broto, L., and Hagimont, D. (2009). Exploitation des techniques de virtualisation pour ladministration autonome dinfrastructures logicielles rparties. In Actes de la Confrence Francophone sur les e e Architectures Logicielles (CAL), Nancy, France. Editions Cpadu`s, RNTI. e e Syst`me dadministration autonome adaptable : application au Cloud e
Bibliographie
155
[91] Toure, M. A. (2010). Administration dapplications rparties ` grande chelle. e a e PhD thesis, INP Toulouse. [Ubuntu] Ubuntu. Ubuntu server cloud. http ://www.ubuntu.com/cloud. [VeePee] VeePee. Veepee : Operateur de services ip. http ://www.veepee.com/. [VirtualBox.org] VirtualBox.org. Virtualbox. http ://www.virtualbox.org. [VMware.org] VMware.org. http ://www.vmware.com. [96] Wankar, R. (2008). Grid computing with globus : An overview and research challenges. International Journal of Computer Science & Applications, 5 :5669. [97] Warnke, R. and Ritzau, T. (2010). qemu-kvm & libvirt. Books on Demand GmbH, Norderstedt 4. Edition, (German). [98] Widenius, M. and Axmark, D. (2002). Mysql Reference Manual. OReilly & Associates, Inc., Sebastopol, CA, USA. [99] Zhang, G. and Parashar, M. (2004). Context-aware dynamic access control for pervasive applications. In Proceedings of the Communication Networks and Distributed Systems Modeling and Simulation Conference, page 2130. [Zynga] Zynga. Connecting the world through games. http ://www.zynga.com.
Table des gures

1.1 2.1 2.2 2.3 2.4 3.1 3.2 4.1 5.1 5.2 5.3 5.4 5.5 5.6 5.7 6.1 7.1 7.2 7.3 7.4 7.5 7.6 8.1 8.2 8.3 8.4 8.5 8.6 9.1 9.2 Plan en U de ce document de th`se . . . . . . . . . . . . . . . . . . . e Evolution vers le Cloud . . . . . . . . (a)Vision classique. (b) Notre vision. Vue des syst`mes virtualiss . . . . . e e Techniques de virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
. 6 . 13 . 17 . 20
Architecture simplie du Cloud . . . . . . . . . . . . . . . . . . . . . 23 e Administration dans le cloud . . . . . . . . . . . . . . . . . . . . . . . 27 Organisation dun SAA . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Exemple dune architecture J2EE . . . . . . . Exemple dADL : cas dune application J2EE Exemple de wrapping : cas du logiciel Apache Principes de TUNe . . . . . . . . . . . . . . . Vue globale de TUNe . . . . . . . . . . . . . . Architecture de DIET . . . . . . . . . . . . . Nouvelle orientation du projet TUNe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 41 42 43 45 49 53
Mod`le architectural gnral . . . . . . . . . . . . . . . . . . . . . . . 61 e e e La plateforme Rainbow . . . . . . . . . . Encapsulation dun logiciel dans Accord Composition dOpenNebula . . . . . . . Organisation dEucalyptus . . . . . . . . Organisation dOpenStack . . . . . . . . Vue gnrale de Microsoft Azure . . . . . e e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 70 75 77 79 81 86 93 96 98 101 103
Mod`le dtaill de TUNeEngine . . . . . . . e e e Exemple darchitecture Fractal . . . . . . . . Soumission de commandes et Collaboration . Construction du SR . . . . . . . . . . . . . . Dploiement et Undeploiement . . . . . . . . e Excution de programmes dadministration . e CloudEngine . . . . . . . . . . . Vision synthtique : intgration e e utilisation de TUNeEngine pour prises dans le cloud. . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 107 de CloudEngine ` TUNeEngine et a le dploiement dapplications entree . . . . . . . . . . . . . . . . . . . . . 109
157 9.3 9.4 Vue globale dadministration et dutilisation de CloudEngine via TUNeEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 (a) Description dune image de VM dans le SR de CloudEngine, (b) Description dune VM dans le SR de CloudEngine, (c) Description du logiciel Apache dans le SR de linstance TUNeEngine de niveau application Entreprise, et (d) Description dune VM dans lIaaS gnre e ee par le VMController de CloudEngine. . . . . . . . . . . . . . . . . . . 122
Environnement matriel de notre IaaS . . . . . . . . . . . . . . . . . 125 e Cot du checkpointing dans la rparation de VM dans lIaaS . . . . . 128 u e Rparation de VM de lIaaS par checkpointing . . . . . . . . . . . . . 129 e Rparation collaborative de VM . . . . . . . . . . . . . . . . . . . . . 130 e Rcapitulatif de quelques situations ncessitant scalabilit et de consoe e e lidation dans le cloud et les applications quil hberge . . . . . . . . . 131 e 10.6 Scalabilit de serveurs MySQL dans une application J2EE dans le cloud132 e 10.7 Consolidation dans le cloud : (a) Evolution de la charge CPU sur les machines de lIaaS, (b) Evolution du nombre de VM par machine de lIaaS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 10.8 Scalabilit niveau application J2EE et Consolidation de VM niveau e IaaS : rsum de lexprimentation . . . . . . . . . . . . . . . . . . . 137 e e e 10.9 Scalabilit au niveau application J2EE et Consolidation de VM au e niveau IaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 10.10Scalabilit niveau application J2EE avec VM de taille variable et e Consolidation de VM niveau IaaS : rsum de lexprimentation . . . 141 e e e 10.11Scalabilit au niveau application J2EE et Consolidation de VM de e tailles variables au niveau IaaS . . . . . . . . . . . . . . . . . . . . . . 142
10.1 10.2 10.3 10.4 10.5
158

Tchana

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tchana

Uploaded by

Copyright:

Available Formats

Institut National Polytechnique de Toulouse (INP Toulouse)

Sret de logiciel et calcul de haute performance (SLCHP)

Systme d'Administration Autonome Adaptable: application au Cloud

Syst`me dadministration autonome adaptable : e application au Cloud

Mr. Mr. Mr. Mr. Mr. Mr.

Table des mati`res e

3.2.5 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Synth`se : syst`me dadministration autonome pour le cloud . . . . . 31 e e 32 32 33 34 35 36 37 38 39 39 41 42 43 46 46 47 48 50 52 54 55 56 57 57 58 59 60 60 60 61 64 64 65 66 67 69 71

Syst`me dadministration autonome adaptable : application au Cloud e

2.1. LE CLOUD COMPUTING

2.1. LE CLOUD COMPUTING

Figure 2.1 Evolution vers le Cloud

2.1. LE CLOUD COMPUTING

Syst`me dadministration autonome adaptable : application au Cloud e

2.1. LE CLOUD COMPUTING

Syst`me dadministration autonome adaptable : application au Cloud e

2.1. LE CLOUD COMPUTING Pour lentreprise

Syst`me dadministration autonome adaptable : application au Cloud e

2.1. LE CLOUD COMPUTING

Par raison de dveloppement e

2.1. LE CLOUD COMPUTING

Syst`me dadministration autonome adaptable : application au Cloud e

2.1. LE CLOUD COMPUTING 2.1.5.2 Par niveau de service

Syst`me dadministration autonome adaptable : application au Cloud e

2.1. LE CLOUD COMPUTING

Figure 2.2 (a)Vision classique. (b) Notre vision.

Syst`me dadministration autonome adaptable : application au Cloud e

2.1. LE CLOUD COMPUTING

2.1. LE CLOUD COMPUTING

Syst`me dadministration autonome adaptable : application au Cloud e

2.2. ISOLATION PAR LA VIRTUALISATION

Isolation par la virtualisation

2.2. ISOLATION PAR LA VIRTUALISATION

Figure 2.3 Vue des syst`mes virtualiss e e

Syst`me dadministration autonome adaptable : application au Cloud e

2.2. ISOLATION PAR LA VIRTUALISATION

Bnces pour les entreprises e e

Syst`me dadministration autonome adaptable : application au Cloud e

2.2. ISOLATION PAR LA VIRTUALISATION

Syst`me dadministration autonome adaptable : application au Cloud e

2.2. ISOLATION PAR LA VIRTUALISATION

Figure 2.4 Techniques de virtualisation

2.2. ISOLATION PAR LA VIRTUALISATION

Syst`me dadministration autonome adaptable : application au Cloud e

Chapitre 3 Administration dans le Cloud

3.1. ADMINISTRATION NIVEAU IAAS

Figure 3.1 Architecture simplie du Cloud e

Administration niveau IaaS

Syst`me dadministration autonome adaptable : application au Cloud e

3.1. ADMINISTRATION NIVEAU IAAS

3.1. ADMINISTRATION NIVEAU IAAS

Syst`me dadministration autonome adaptable : application au Cloud e

3.1. ADMINISTRATION NIVEAU IAAS

Syst`me dadministration autonome adaptable : application au Cloud e

3.2. ADMINISTRATION NIVEAU ENTREPRISE

Figure 3.2 Administration dans le cloud

Administration niveau Entreprise

Syst`me dadministration autonome adaptable : application au Cloud e

3.2. ADMINISTRATION NIVEAU ENTREPRISE

3.2. ADMINISTRATION NIVEAU ENTREPRISE

Syst`me dadministration autonome adaptable : application au Cloud e

3.2. ADMINISTRATION NIVEAU ENTREPRISE

` ` 3.3. SYNTHESE : SYSTEME DADMINISTRATION AUTONOME POUR LE CLOUD 31

Synth`se : syst`me dadministration autonome e e pour le cloud