P. 1
tchana

tchana

|Views: 16|Likes:
Published by Nadia Metoui

More info:

Published by: Nadia Metoui on Mar 11, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

04/21/2014

pdf

text

original

Sections

Institut National Polytechnique de Toulouse (INP Toulouse

)
Sûreté de logiciel et calcul de haute performance (SLCHP)

Alain-B. TCHANA
mardi 29 novembre 2011

Système d'Administration Autonome Adaptable: application au Cloud

Mathématiques Informatique Télécommunications (MITT) Institut de Recherche en Informatique de Toulouse (IRIT) Mr. Daniel HAGIMONT

Mr. Noël DE PALMA Mr. Jean-Marc MENAUD M : Mr. Noël 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 Thèse Mr. Laurent BROTO, Institut National Polytechnique de Toulouse, Examinateur

` THESE
soutenue en vue de l’obtention du titre de ´ DOCTEUR DE L’UNIVERSITE DE TOULOUSE Sp´cialit´ : INFORMATIQUE e e d´livr´e par e e l’INSTITUT NATIONAL POLYTECHNIQUE DE TOULOUSE

Syst`me d’administration autonome adaptable : e application au Cloud
Pr´sent´e 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 : Math´matique, Informatique, T´l´communication 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 H´l`ne Mar´chau. Je ne trouverai jamais assez de ee e mots, ni d’espace, ni de temps pour te dire ` quel point a ton aide m’a ´t´ capitale H´l`ne. J’ai toujours imagin´ ee ee e plus jeune (au secondaire) que toute th`se aboutissait e sur une d´couverte ou une invention. Ta rencontre sera e ma plus grande trouvaille de ces derni`res ann´es et e e j’esp`re quelle le restera. e

Hommage au syst`me ´ducatif e e Fran¸ais pour m’avoir accueilli et c financ´ 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 l’´valuation de mon travail. Merci a mes rapporteurs No¨l De e` e ` e PALMA et Jean-Marc MENAUD a qui a ´t´ confi´e la responsabilit´ de critiquer la ` ee e e forme et le fond de mon travail. Merci a Michel DAYDE qui a accept´ de pr´sider le ` e e jury et d’examiner mon travail. Merci a Maurice TCHUENTE qui m’a fait l’honneur ` du d´placement du Cameroun, lieu o` j’ai acquis les bases des connaissances mises e u a profit dans cette th`se. ` e Merci ` mon directeur de th`se Daniel HAGIMONT et co-Directeur Laurent a e BROTO. Vous m’avez mis dans les conditions id´ales pour r´aliser cette th`se, tant e e e sur le plan professionnel que personnel. Je dois ` Daniel (le lieutenant Dan) mes moa destes qualit´s r´dactionnelles, d’esprit critique et de recul dans la r´alisation d’un e e e travail de recherche. Laurent, tu as ´t´ une des premi`res personnes qui m’a impresee e sionn´ techniquement dans les domaines de l’informatique et de la m´canique. Tu e e as r´ussi a me transmettre ta s´r´nit´ 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 pr´sent´ ` la fois comme encadreurs, tuteurs et potes. Ce fut un bonheur e ea de travailler avec vous et j’esp`re continuer. e Un grand merci a nos admirables secr´taires 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 anim´e dans le e e e travail. Merci au ”professeur” TOURE Mohamed qui m’a accueilli et trait´ comme e un fr`re durant son s´jour 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 j’ai 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 j’ai termin´ dans une bonne ambiance mon s´jour au sein de l’´quipe. 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” Bafing SAMBOU et Mee ` kossou BAKAYOKO pour votre amiti´ et disponibilit´ ; ` Cheik OUMAR AIDARA, e e a Aboubakar DIALLO et Cheik TALL pour vos d´bats houleux et enrichissants les e soirs de foot. Tˆchez toujours de faire respecter les fondamentaux. a Je ne saurai oublier ma tr`s grande famille qui m’a toujours soutenu dans tous e mes choix. Vous constituez une grande partie de mes motivations et j’esp`re toujours e vous faire honneur. Un merci particulier a mon p`re et ma m`re qui ont toujours mis ` e e l’´cole au centre de tout. Merci a la ”1759” qui repr´sente un membre permanent de e ` e la famille auquel je peux faire appel a tout moment :). ` v

R´sum´ e e Ces derni`res ann´es ont vu le d´veloppement du cloud computing. Le principe e e e fondateur est de d´porter la gestion des services informatiques des entreprises dans e des centres d’h´bergement g´r´s par des entreprises tiers. Ce d´port a pour principal e ee e avantage une r´duction des coˆts pour l’entreprise cliente, les moyens n´cessaires ` la e u e a gestion de ces services ´tant mutualis´s entre clients et g´r´s par l’entreprise h´bere e ee e geant ces services. Cette ´volution implique la gestion de structures d’h´bergement e e a grande ´chelle, que la dimension et la complexit´ rendent difficiles a administrer. ` e e ` Avec le d´veloppement des infrastructures de calcul de type cluster ou grilles ont e ´merg´ des syst`mes fournissant un support pour l’administration automatis´e de ces e e e e environnements. Ces syst`mes sont d´sign´s sous le terme Syst`mes d’Administration e e e e Autonome (SAA). Ils visent a fournir des services permettant d’automatiser les ` tˆches d’administration comme le d´ploiement des logiciels, la r´paration en cas a e e de panne ou leur dimensionnement dynamique en fonction de la charge. Ainsi, il est naturel d’envisager l’utilisation des SAA pour l’administration d’une infrastructure d’h´bergement de type cloud. Cependant, nous remarquons que les e SAA disponibles ` l’heure actuelle ont ´t´ pour la plupart con¸us pour r´pondre aux a ee c e besoins d’un domaine applicatif particulier. Un SAA doit pouvoir ˆtre adapt´ en e e fonction du domaine consid´r´, en particulier celui de l’administration d’un cloud. ee De plus, dans le domaine du cloud, diff´rents besoins doivent ˆtre pris en compte : e e ceux de l’administrateur du centre d’h´bergement et ceux de l’utilisateur du centre e d’h´bergement qui d´ploie ses applications dans le cloud. Ceci implique qu’un SAA e e doit pouvoir ˆtre adapt´ pour r´pondre a ces besoins divers. e e e ` Dans cette th`se, nous ´tudions la conception et l’implantation d’un SAA adape e table. Un tel SAA doit permettre d’adapter les services qu’il offre aux besoins des domaines dans lesquels il est utilis´. Nous montrons ensuite comment ce SAA adape table peut ˆtre utilis´ pour l’administration autonome d’un 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 difficult 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, different 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 fulfill 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 G´n´ralit´s et D´finition . . . . . . . . e e e e 2.1.2 Cloud vs Grilles . . . . . . . . . . . . . 2.1.3 Principes . . . . . . . . . . . . . . . . 2.1.4 B´n´fices . . . . . . . . . . . . . . . . . e e 2.1.5 Classification . . . . . . . . . . . . . . 2.1.5.1 Par raison de d´veloppement 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 Interop´rabilit´ et Portabilit´ e e e 2.2 Isolation par la virtualisation . . . . . . . . . 2.2.1 D´finition et Principes . . . . . . . . . e 2.2.2 Objectifs . . . . . . . . . . . . . . . . . 2.2.3 B´n´fices pour les entreprises . . . . . e e 2.2.4 Classification . . . . . . . . . . . . . . 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 D´ploiement . . . . . . . . . . . . . . e 3.1.3 Configuration et D´marrage . . . . . e 3.1.4 Reconfiguration . . . . . . . . . . . . 3.1.5 Monitoring . . . . . . . . . . . . . . 3.2 Administration niveau Entreprise . . . . . . 3.2.1 Construction de VM et D´ploiement e 3.2.2 Allocation de ressources . . . . . . . 3.2.3 Configuration et D´marrage . . . . . e 3.2.4 Reconfiguration . . . . . . . . . . . . 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 d’administration 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 D´finition . . . . . . . . . . . e 4.2 Objectifs . . . . . . . . . . . . 4.3 B´n´fices pour les entreprises e e 4.4 Classification . . . . . . . . . 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 Reconfiguration Description Language (RDL) 5.3 Choix d’implantation . . . . . . . . . . . . . . . . . . 5.4 Exp´rimentations et Probl´matiques . . . . . . . . . e e 5.4.1 Applications cluster . . . . . . . . . . . . . . . 5.4.2 Applications large ´chelle : cas de DIET . . . e 5.4.3 Applications virtualis´es . . . . . . . . . . . . e 5.4.4 Cloud . . . . . . . . . . . . . . . . . . . . . . 5.5 Synth`se et nouvelle orientation . . . . . . . . . . . . e 6 Orientation g´n´rale e e 6.1 Caract´ristiques . . . . . . . . . . . . . . . . . . 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 Interop´rable et Collaboratif . . . . . . . e 6.1.4 Synth`se . . . . . . . . . . . . . . . . . . e 6.2 Approche g´n´rale et Mod`le Architectural . . . e e e 6.2.1 Approche G´n´rale . . . . . . . . . . . . e e 6.2.2 Mod`le Architectural . . . . . . . . . . . e 6.2.3 Prise en compte des caract´ristiques . . . e 6.3 Synth`se . . . . . . . . . . . . . . . . . . . . . . e 7 Etat de l’art 7.1 SAA . . . . . . 7.1.1 Rainbow 7.1.2 Accord . 7.1.3 Unity .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

x

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 d´taill´ de TUNeEngine . . . . . . . . . . . e e e 8.1.1 Soumission de commandes et Collaboration 8.1.2 Construction du SR . . . . . . . . . . . . . . 8.1.3 D´ploiement . . . . . . . . . . . . . . . . . . e 8.1.4 Configuration, D´marrage . . . . . . . . . . e 8.1.5 R´configuration . . . . . . . . . . . . . . . . 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 D´ploiement . . . . . . . . . . . . . . . . . . e 8.3.5 Ex´cution de programmes d’administration . e 8.4 Synth`se . . . . . . . . . . . . . . . . . . . . . . . . e

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

9 Contributions : application au Cloud 104 9.1 Un IaaS simplifi´ : 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 d’applications . . . . . . . . . . . . . . . . . . 115 9.3 Reconfiguration d’applications et de CloudEngine . . . . . . . . . . . 116 9.3.1 R´paration de VM . . . . . . . . . . . . . . . . . . . . . . . . 116 e 9.3.2 Consolidation de VM et Scalabilit´ de serveurs . . . . . . . . . 117 e 9.3.2.1 Ex´cution d’applications statique . . . . . . . . . . . 118 e

xi

9.4

9.3.2.2 Ex´cution d’applications 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 Exp´rimentations e 10.1 Environnements d’exp´rimentation . . . . . . . . . . . . e 10.1.1 L’IaaS . . . . . . . . . . . . . . . . . . . . . . . . 10.1.2 Les applications entreprises : RUBIS . . . . . . . 10.1.3 Les m´triques . . . . . . . . . . . . . . . . . . . . e ´ 10.2 Evaluations . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.1 R´paration de VM . . . . . . . . . . . . . . . . . e 10.2.1.1 R´paration non collaborative . . . . . . e 10.2.1.2 R´paration 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 simultan´es 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 ` l’augmentation continuelle des coˆts 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 confiant ` des entreprises sp´cialis´es comme les fournisseurs de a e e clouds. L’int´rˆt principal de cette strat´gie pour les entreprises r´side dans le fait ee e e qu’elles ne paient que pour les services effectivement consomm´s. Quant au foure nisseur du cloud, son but est de r´pondre aux besoins des clients en d´pensant le e e minimum de ressources possibles. Une des approches qu’utilise le fournisseur consiste a mutualiser les ressources dont il dispose afin de les partager entre plusieurs entre` prises. Dans ce contexte, plusieurs d´fis, parmi lesquels l’isolation (des ressources, e d´faillances, performances, espaces utilisateur) et l’administration optimale des rese sources, se posent pour permettre un r´el d´veloppement du cloud. e e Actuellement, la plupart des d´veloppements de plateformes de cloud utilisent e la virtualisation [58] comme support technologique pour assurer l’isolation. Ainsi, l’unit´ d’allocation de ressources dans le cloud est la machine virtuelle, autrement e dit une portion de machine physique. Quant a l’administration dans le cloud, nous ` constatons que les services fournis restent limit´s et sont plus ou moins semblables e d’une plateforme a l’autre. Il s’agit essentiellement des services de r´servation, de ` e d´marrage et d’arrˆt des machines virtuelles. Les tˆches d’administration des mae e a chines virtuelles et des applications des entreprises sont laiss´es a la charge des e ` diff´rents administrateurs. A titre d’exemple, les op´rations de consolidation de mae e chines virtuelles ou encore de passage ` l’´chelle des applications clientes doivent a e ˆtre implant´es par les administrateurs a travers des API de bas niveau. L’objectif e e ` principal de cette th`se est la conception d’un logiciel permettant l’administration e du cloud dans son ensemble. Depuis plusieurs ann´es, des chercheurs se sont int´ress´s a la conception de e e e ` syst`mes d’administration autonome (SAA). Ces syst`mes visent a fournir des sere e ` vices permettant d’automatiser les tˆches d’administration comme le d´ploiement a e des logiciels, la r´paration 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 d’administration autonome et les besoins d’administration dans le cloud. e

CHAPITRE 1. INTRODUCTION

2

Figure 1.1 – Plan en U de ce document de th`se e En effet, dans les deux niveaux d’administration dans le cloud (cloud et applications qu’il ex´cute), les administrateurs sont confront´s aux op´rations d’installation (de e e e machines virtuelles et des logiciels), de configuration, de d´pannage, d’allocation de e ressources et autres tˆches de reconfiguration. La principale diff´rence entre ces deux a e niveaux est la nature des entit´s administr´es : les machines virtuelles au niveau du e e cloud (l’h´bergeur) et les logiciels applicatifs au niveau du client. e Dans le cadre de nos travaux dans le domaine de l’administration, nous avons con¸u et d´velopp´ un syst`me d’administration autonome baptis´ TUNe [29]. En c e e e e plus de valider une approche de d´veloppement des syst`mes d’administration aue e tonome, TUNe a ´t´ utilis´ pour l’administration de plusieurs types d’applications. ee e Cependant, il s’est relativement inadapt´ pour l’administration des syst`mes large e e ´chelle ou virtualis´s. Ainsi, sur les bases de TUNe, nous proposons dans cette th`se e e e la conception d’un SAA hautement flexible et adaptable, pouvant ˆtre notame ment sp´cialis´ pour une utilisation dans le cloud. Cette d´marche de construction e e e d’un SAA adaptable au cloud (et non sp´cifique au cloud) s’explique par le fait que e notre activit´ de recherche ne s’inscrit pas (et ne s’inscrira pas dans le futur) uniquee ment dans la technologie du cloud, mais toujours dans l’administration autonome. Compte tenu de la double probl´matique que nous adressons (construction d’un e SAA adaptable et application pour l’administration dans le cloud), l’organisation de ce document de th`se suit globalement une trajectoire en U r´sum´e par la figure 1.1 : e e e – Partie I : Contexte du cloud Cette partie est compos´e des chapitres 2 et 3. Le chapitre 2 pr´sente le cloud et e e ses apports dans les entreprises (tout en clarifiant quelques d´finitions) tandis e que le chapitre 3 pr´sente en quoi consiste les tˆches d’administration dans le e a cloud. – Partie II : Contexte SAA Cette partie regroupe les chapitres 4 et 5. Le chapitre 4 pr´sente le contexte e Syst`me d’administration autonome adaptable : application au Cloud e

CHAPITRE 1. INTRODUCTION

3

scientifique qu’est l’administration autonome en parcourant quelques approches de conception de SAA. Quant au chapitre 5, il pr´sente le prototype de SAA e TUNe (d´velopp´ au sein de notre ´quipe) ainsi que ses difficult´s a r´pondre e e e e ` e aux besoins d’administration du cloud. – Partie III : Positionnement Cette partie regroupe les chapitres 6 et 7. Dans le chapitre 6, nous proposons un canevas de conception d’un SAA adaptable et g´n´rique. Quant au chapitre 7, e e il pr´sente une ´tude des travaux de recherche effectu´s autour des SAA et des e e e plateformes d’administration dans le cloud. – Partie IV : Contribution SAA Cette partie se r´sume au chapitre 8 dans lequel nous pr´sentons l’implantation e e d’un SAA adaptable suivant le canevas que nous avons pr´c´demment propos´. e e e – Partie V : Contribution Cloud Cette partie contient les chapitres 9 et 10. Le chapitre 9 pr´sente la persone nalisation du SAA adaptable que nous avons implant´, pour l’administration e dans le cloud. Quant au chapitre 10, il montre les ´valuations de cette persone nalisation dans la r´alisation des tˆches d’administration dans le cloud. e a

Syst`me d’administration autonome adaptable : application au Cloud e

Chapitre 2 Le cloud
Contents
Le Cloud Computing . . . . . . . . . . . . . . 2.1.1 G´n´ralit´s et D´finition . . . . . . . . . . . . e e e e 2.1.2 Cloud vs Grilles . . . . . . . . . . . . . . . . 2.1.3 Principes . . . . . . . . . . . . . . . . . . . . 2.1.4 B´n´fices . . . . . . . . . . . . . . . . . . . . e e 2.1.5 Classification . . . . . . . . . . . . . . . . . . 2.1.5.1 Par raison de d´veloppement . . . . 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 Interop´rabilit´ et Portabilit´ . . . . e e e 2.2 Isolation par la virtualisation . . . . . . . . . 2.2.1 D´finition et Principes . . . . . . . . . . . . . e 2.2.2 Objectifs . . . . . . . . . . . . . . . . . . . . 2.2.3 B´n´fices pour les entreprises . . . . . . . . . e e 2.2.4 Classification . . . . . . . . . . . . . . . . . . 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

5

2.1
2.1.1

Le Cloud Computing
G´n´ralit´s et D´finition e e e e

Face ` l’augmentation continuelle des coˆts 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 confient leur gestion (des services informatiques) ` des ena treprises sp´cialis´es (que nous appelons fournisseurs). L’int´rˆt principal de cette e e ee strat´gie r´side dans le fait que l’entreprise ne paie que pour les services effectivee e ment consomm´s. En effet, une gestion interne de ces services par l’entreprise ne e serait pas compl`tement amortie, en particulier lorsque les besoins d’utilisation vae rient. Le d´veloppement de ce mode de fonctionnement a ´t´ favoris´ par plusieurs e ee e facteurs tels que l’´volution et la g´n´ralisation des acc`s internet, l’augmentation e e e e de la puissance des ordinateurs et des r´seaux informatiques. Le Cloud Computing e se situe dans cette orientation r´cente. e Devant le manque de consensus sur la d´finition de la notion de Cloud Compue ting, nous reprenons la d´finition propos´e par CISCO [21] : ”le Cloud Computing e e est une plateforme de mutualisation informatique fournissant aux entreprises des services ` la demande avec l’illusion d’une infinit´ des a e ressources”. Dans cette d´finition, nous retrouvons quelques similitudes avec les e plateformes connues comme les grilles de calcul ou encore les centres d’h´bergee ment. Il est pr´sent´ dans la litt´rature comme une ´volution de ces infrastructures e e e e d’h´bergement mutualis´es. En guise d’exemple, prenons l’´volution propos´e par e e e e [49] (figure 2.1) qui est largement cit´e dans la litt´rature. D’apr`s [49], le cloud e e e computing est le fruit d’une ´volution pouvant ˆtre pr´sent´e en 5 phases : e e e e – Elle d´bute avec les Fournisseurs d’Acc`s Internet (FAI 1.0). Ils ont pour but e e de mettre en place des moyens de t´l´communication afin d’assurer le raccoree dement des personnes ou entreprises au r´seau internet. e – La seconde phase est l’orientation des FAI vers l’h´bergement de pages web e (FAI 2.0). Cette phase marque un grand bond dans le d´veloppement d’intere net. – La troisi`me phase (FAI 3.0) est la possibilit´ qu’offrent les FAI ` h´berger des e e a e applications m´tiers des entreprises. e – Une connaissance des besoins applicatifs des entreprises permettent aux FAI de faire ´voluer leur domaine d’intervention. Ils mettent en place des platee formes de g´n´ration d’applications a la demande. Il s’agit des ASP (Applie e ` cation Service Provider) dont les ”Software as a Service” (section 2.1.5.2) sont des d´riv´s : c’est le FAI 4.0. e e – La g´n´ralisation des pratiques pr´c´dentes, la prise en compte de nouvelles e e e e pratiques et l’int´gration des principes que nous pr´sentons dans les sections e e suivantes donnent naissance au cloud computing. Suivant cette ´volution, nous pr´sentons dans la section suivante notre point de e e vue concernant la position du cloud computing par rapport aux plateformes d’h´e Syst`me d’administration autonome adaptable : application au Cloud e

2.1. LE CLOUD COMPUTING

6

bergement mutualis´es comme les grilles [65] (grid5000 [25], Globus [96]). e N.B : Dans ce document, nous utilisons l’acronyme ”CC” pour d´signer la teche nologie Cloud Computing et le terme ”cloud” pour parler d’une 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 ann´es 90, les grilles de calcul situent e e la mutualisation au cœur de leur technologie. De mˆme, la mutualisation est au e cœur de la technologie du CC. La question que nous nous posons : ”A quel niveau se situe la diff´rence entre le cloud et les grilles (si elle existe) ?”. Autrement dit, le e terme ”Cloud Computing” n’est-il pas une autre appellation de ”Grid Computing”? Apr`s consultation de la litt´rature, nous ne trouvons qu’une ´tude s´rieuse consacr´e e e e e e enti`rement a cette comparaison ([51]). Le constat global de [51] est proche du nˆtre. e ` o D’un point de vue technologique nous n’identifions pas de r´elle diff´rence entre e e les plateformes de grille et de cloud. Cependant, l’ouverture du cloud aux utilisateurs de diff´rents niveaux (pas toujours des informaticiens comme dans les grilles) et e ´ventuellement son caract`re commercial sont les potentielles diff´rences que nous e e e identifions. De plus, dans les environnements de grilles, les applications (appel´es e le plus souvent job) s’ex´cutent g´n´ralement sur une dur´e limit´e (mˆme si cellee e e e e e ci peut ˆtre illimit´e comme dans le cloud). Comme nous le pr´sentons dans la e e e section 3, ces diff´rences rendent la gestion et l’utilisation des plateformes de cloud e plus complexes que dans les grilles. Somme toute, nous consid´rons que la technologie de cloud computing utilise la e technologie de grille a laquelle elle associe les principes d’ouverture au public, de ` Syst`me d’administration autonome adaptable : application au Cloud e

2.1. LE CLOUD COMPUTING

7

facturation, et d’h´bergement durable. Dans la section suivante, nous d´taillons ces e e diff´rents principes. e

2.1.3

Principes

Nous avons ´nonc´ dans la section pr´c´dente quelques principes fondamentaux e e e e du cloud. Ces principes lui permettent de se d´marquer des plateformes d’h´bere e gement classiques (grille, data center, centre d’h´bergements). Les plus importants e d’entre eux sont la mutualisation et la facturation des ressources a l’usage : ` La mutualisation. C’est la pratique qui consiste ` partager l’utilisation d’un a ensemble de ressources par des entreprises (ou entit´s quelconques) n’ayant aucun e lien entre elles. Les ressources peuvent ˆtre de diverses natures : logicielles ou mat´e e rielles (machines, ´quipements r´seau, ´nergie ´lectrique). Cette pratique d´pend du e e e e e d´sir des entreprises de d´localiser 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 li´s a son exploitation et utilisation. Il s’agit des probl`mes classiques tels e e ` e que la s´curit´, la disponibilit´, l’int´grit´, la fiabilit´ et l’uniformit´ d’acc`s aux e e e e e e e e donn´es. e L’allocation et facturation ` la demande. Contrairement aux centres d’h´a e bergement web classiques dans lesquels le paiement se fait ` l’avance sous forme de a forfait, le cloud propose une facturation ` l’usage. Cette derni`re peut ˆtre impl´mena e e e t´e de deux fa¸ons. La premi`re consiste a facturer ` l’entreprise la dur´e d’utilisation e c e ` a e d’un ensemble de ressources quelque soit l’utilisation effective. Par exemple, soit r l’ensemble des ressources r´serv´es par l’entreprise. Soient t1 et t2 respectivement e e l’instant de d´but et de fin d’utilisation des ressources. Soit Cu le coˆt d’utilisation e u d’une ressource durant une unit´ de temps. Ainsi, le coˆt total d’utilisation de l’ene u semble des ressources r est : Cr =(t2 -t1 )*Cu *r . Quant a la deuxi`me fa¸on, elle est ` e c beaucoup plus fine que la premi`re. Elle consiste a facturer les v´ritables instants e ` e pendant lesquels les ressources ont ´t´ utilis´es. En partant des mˆmes param`tres ee e e e que pr´c´demment, soit T={tu1 ,tu2 ,. . . ,tun } avec tui ∈[t1 ;t2 ], 1≤i≤n, l’ensemble des e e unit´s de temps pendant lesquelles les ressources ont ´t´ r´ellement utilis´es. Dans ce e ee e e cas, le coˆt total d’utilisation de l’ensemble 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 cons´quences e e de l’utilisation du cloud peuvent ˆtre b´n´fiques ` la fois pour le fournisseur et pour e e e a les entreprises qui y ont recours.

Syst`me d’administration autonome adaptable : application au Cloud e

2.1. LE CLOUD COMPUTING

8

2.1.4

B´n´fices e e

Les retomb´es des principes du cloud sont b´n´fiques a la fois pour son fournise e e ` seur, les entreprises d´localisant 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 ` l’entreprise de se concentrer sur les tˆches de e a a production autres que la maintenance de syst`mes informatiques. e

Pour le fournisseur Les b´n´fices du fournisseur sont uniquement dˆs au fait de la mutualisation e e u des ressources. En effet, apr`s son investissement dans la mise en place des infrae structures pour le cloud, il fait payer aux entreprises la marge n´cessaire pour sa e rentabilisation. Comme pour une entreprise disposant d’une plateforme interne, il paie pour les frais d’administration de l’ensemble. Cette d´pense peut ˆtre amortie e e par facturation aux entreprises. En plus de cette marge, il b´n´ficie des coˆts de e e u r´utilisation des ressources. En effet, compte tenu de la non appartenance des rese sources aux entreprises, elles (les ressources) leurs sont factur´es a chaque usage. La e ` mˆme ressource peut ainsi faire l’objet de plusieurs facturations. e

Pour l’environnement A l’`re de l’´cologie et des politiques de r´duction de la consommation ´nerg´e e e e e tique, l’investissement dans les plateformes de cloud repr´sente un geste envers la e nature. La mutualisation de ressources (telle que pratiqu´e dans le cloud) accompae gn´e par la d´localisation des infrastructures d’entreprise vers les clouds permettent e e de r´duire les consommations ´nerg´tiques. Pour illustrer cette affirmation, reprenons e e e l’´tude [45] r´alis´e 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 r´sum´e 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 d´localisation e des applications Microsoft Exchange Server 2007 [75] des entreprises vers le cloud Microsoft Azure permet de r´duire d’au moins 30% les ´missions CO2 par utilisateur e e de chaque entreprise. Cette r´duction s’explique par deux facteurs. D’une part, la e d´localisation permet de r´duire le nombre et la taille des infrastructures informae e tiques en service. Ceci implique donc une r´duction de la consommation ´nerg´tique e e e (donc moins de rejet de CO2 ). D’autre part, le fournisseur Microsoft implante dans son cloud des techniques d’utilisation efficace de ressources.
1. Groupe de Consulting en mati`re d’environnement, d’´nergie et de climat : e e www.wspenvironmental.com

Syst`me d’administration autonome adaptable : application au Cloud e

2.1. LE CLOUD COMPUTING Pour l’entreprise

9

C’est elle la premi`re gagnante de cette technologie. Elle r´alise des b´n´fices en e e e e argent et en flexibilit´ dans sa capacit´ ` s’agrandir. e ea La r´duction des coˆ ts. Le recours au cloud permet a l’entreprise d’ˆtre factue u ` e r´e ` l’usage, en fonction de ses besoins. Pour avoir une id´e du gain r´alis´, reprenons e a e e e cette observation de Michael Crandell du groupe RightScale [RIGHSCALE] a propos ` du cloud d’Amazon [61] : ”Le coˆt ` pleine charge d’un serveur sur Amazon se situe u a entre 70$ et 150$ par mois alors qu’il s’´l`ve ` 400$ en moyenne par mois s’il ´tait ee a e h´berg´ par l’entreprise en interne”. Plusieurs raisons expliquent cette diff´rence de e e e coˆt. En effet, une gestion interne de l’infrastructure implique l’achat des mat´riels, u e l’affectation du personnel (et donc du coˆt salarial qu’il induit) pour la gestion de u l’infrastructure et divers moyens de production mis en place pour le fonctionnement de l’ensemble (´lectricit´, locaux, etc). Le partage de ressources tel que pratiqu´ dans e e e le cloud permet au fournisseur de r´partir ces coˆts entre plusieurs entreprises. e u La r´duction des gaspillages. Les infrastructures g´r´es en interne sont soue ee vent sous-utilis´es, alors que l’infrastructure d’un cloud mutualise l’ensemble de rese sources pour un grand nombre d’entreprises. La mutualisation consiste a mettre ` ` a la disposition de plusieurs utilisateurs une base commune de ressources. Elle permet ainsi d’augmenter le taux d’utilisation de ces ressources. En effet, les ressources n’´tant pas d´di´es ` un seul utilisateur, elles pourront servir a d’autres en cas de e e e a ` besoin. La flexibilit´ et acc`s aux ressources large ´chelle. L’entreprise peut auge e e menter la capacit´ de son infrastructure sans investissement majeur. En effet, grˆce e a a l’allocation dynamique (` la demande) des ressources qu’offre le cloud, il suffit de ` a souscrire ` de nouvelles ressources et celles-ci sont directement allou´es. De plus, a e l’entreprise est libre de ses all´es et venues car les contrats d’utilisation sont limit´s e e dans le temps (autour de l’heure). Ainsi, l’entreprise peut augmenter ou r´duire son e infrastructure ` sa guise a moindre coˆt et dans un d´lai r´duit. Rappelons que le a ` u e e cloud offre ainsi ` l’entreprise une possibilit´ d’acc´der ` une quantit´ de ressources a e e a e dont elle ne pourrait se l’offrir en interne. Elle peut dor´navant envisager des ape plications large ´chelle sans se soucier de l’obtention des ´quipements. A ce sujet, e e on observe quelques d´rives avec des groupes qui acqui`rent un grand nombre de e e ressources dans les clouds a des fins criminelles (d´cryptage de cl´ de s´curit´ ou ` e e e e 2 d´nis de service en sont des exemples) . e Notons que cette flexibilit´ d´pend du type de cloud consid´r´ (section suivante). e e ee Par exemple, l’augmentation 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 d´cision est prise de fa¸on coll´giale (entre toutes les entreprises intervee c e
2. Attaque pour d´cryptage de la cl´ de s´curit´ des Network PlayStation de Sony en e e e e mai 2011

Syst`me d’administration autonome adaptable : application au Cloud e

2.1. LE CLOUD COMPUTING

10

nantes) et peut donc prendre un temps consid´rable. A l’oppos´, dans le second cas, e e l’op´ration se r´alise dans l’imm´diat. e e e

2.1.5

Classification

Avant de pr´senter les diff´rents types de cloud pouvant ˆtre d´velopp´s, nous e e e e e ´tablissons dans un premier temps quelques crit`res de classification : e e • La raison de d´veloppement (business model ). C’est la raison qui justifie la e mise en place de la plateforme. Elle peut ˆtre commerciale, scientifique ou e communautaire. • Le niveau de services. C’est l’ambition du cloud a fournir aux entreprises une ` plateforme proche ou pas de leurs attentes. • L’accessibilit´. 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 d´veloppons pas celui-ci ´tant donn´ sa simplicit´ de compr´hension. e e e e e

2.1.5.1

Par raison de d´veloppement e

L’utilisation 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 cat´gories de plateformes de CC a savoir : e ` Cloud d’Entreprises. Dans cette cat´gorie, 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 d’un projet de cloud afin de mutualiser leurs capacit´s. La plateforme qui en d´coule est priv´e, e e e c’est-`-dire accessible uniquement par les entit´s des diff´rentes entreprises. Cette a e e plateforme a l’avantage d’ˆtre de petite taille et d’acc`s restreint ` des utilisateurs ` e e a connus. Ainsi, les probl`mes de s´curit´ sont r´duits et l’administration peut ˆtre e e e e e sp´cialis´e. Les groupes Amazon EC2 [61] (via le ”Virtual Private Cloud ”), VMe e ware [VMware.org] ou encore VeePee [VeePee] offrent par exemple des solutions de clouds priv´s. e En comparaison avec les technologies existantes, cette cat´gorie est identique aux e clusters priv´s. e Cloud Gouvernemental et Recherche Scientifique. Pour des raisons de recherche et de d´veloppement, des instituts de recherche mettent sur pied des ene vironnements de cloud. Leur d´veloppement est encourag´ et financ´ par des goue e e vernements. L’acc`s est exclusivement r´serv´ aux personnes exer¸ant dans le mˆme e e e c e domaine de recherche, ou appartenant aux instituts de recherche associ´s, ou ayant e une d´rogation pr´cise. Ces plateformes sont pour la plupart orient´es projets. Seules e e e les avanc´es scientifiques obtenues par les groupes de recherche qui l’utilisent pere mettent de valoriser la plateforme. Syst`me d’administration autonome adaptable : application au Cloud e

2.1. LE CLOUD COMPUTING

11

D’un point de vue technologique, d’objectif et d’utilisation, aucune diff´rence e n’est notable avec les grilles scientifiques comme grid5000 [25]. Cloud pour R´seaux Sociaux et Jeux. Le d´veloppement des r´seaux soe e e ciaux et des jeux en ligne n´cessite de plus en plus de grandes quantit´s de ressources. e e Cette n´cessit´ est due a la croissance presque exponentielle d’utilisateurs. De plus, e e ` l’essence de ces environnements est la mise en commun d’un certains nombre de donn´es et de connaissances (donc de ressources). Dans ce contexte, le d´veloppement e e d’une plateforme similaire au cloud devient une ´vidence pour optimiser l’utilisae tion des ressources et faciliter le partage de donn´es. En effet, elles sont consid´r´es e ee comme plateforme de cloud a cause de leur recours aux principes de d´veloppement ` e de celui-ci. L’ouverture de ces plateformes a tous et le nombre important d’utilisateurs pour` raient constituer un handicap pour leur gestion. Or n’h´bergeant qu’une seule ape plication (celle du fournisseur), leur gestion est sp´cialis´e et moins complexe. Elles e e sont comparables aux clusters/griles priv´s. Les plateformes comme celles du r´seau e e social facebook [facebook] ou des jeux en ligne zynga [Zynga] font partie de cette cat´gorie. e Cloud pour Fournisseurs de Services. C’est le mod`le le plus r´pandu. Une e e entreprise, appel´e fournisseur, met a la disposition d’autres (appel´es clients) une e ` e plateforme d’ex´cution d’applications et assure le service informatique inh´rent. Il e e s’agit d’un mod`le ouvert a tout public et ` caract`re commercial. La plateforme e ` a e h´berge tous types d’applications et l’acc`s ` ces applications est ouvert aux utilie e a sateurs externes. Les d´fis de s´curit´ et d’administration (que nous d´taillons 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 cat´gorie. Sachant que cette e cat´gorie peut regrouper les autres, les contributions que nous apportons dans cette e th`se s’adressent a cette cat´gorie de cloud. Notons que quelque soit le mod`le de e ` e e d´veloppement consid´r´, la plateforme qui en d´coule peut ´galement ˆtre class´e e ee e e e e selon son niveau d’utilisation (section suivante). Notons qu’il existe des communaut´s de d´veloppement logiciels autour de ces e e cat´gories de cloud. Elles fournissent des briques logicielles permettant de construie re/enrichir une plateforme de cloud. Tr`s souvent, il s’agit d’entreprises dont le but e est de fid´liser ses clients (futurs propri´taires de plateformes de cloud). Les logie e ciels sont pr´sent´s a ces derniers comme une valeur ajout´e de l’´volution d’un e e ` e e produit existant (comme un syst`me d’exploitation). Ce d´veloppement est le plus e e souvent pratiqu´ par des communaut´s de logiciels libres (plateforme Ubuntu Ene e terprise Cloud [Ubuntu] ou Eucalyptus [80]) ou encore par des grands groupes de d´veloppement de logiciels sp´cialis´s (Oracle Cloud Computing [ora]). e e e

Syst`me d’administration autonome adaptable : application au Cloud e

2.1. LE CLOUD COMPUTING 2.1.5.2 Par niveau de service

12

En fonction du niveau d’abstraction qu’offre le cloud aux entreprises, nous identifions dans la litt´rature trois cat´gories de plateformes de CC (figure 2.2(a)) : e e Infrastructure as a Service (IaaS). C’est le niveau de service le plus bas. Le cloud fournit des ressources mat´rielles aux entreprises (capacit´ de traitement, e e de stockage, etc.). L’acc`s a ces ressources peut ˆtre direct ou virtuel (section 2.2). e ` e On retrouve dans cette cat´gorie les plateformes comme Amazon Elastic Compute e Cloud (EC2) [61] et IELO Cloud [Cloud]. Platform as a Service (PaaS). Il s’agit d’un niveau d’abstraction au-dessus de l’IaaS dans lequel le cloud fournit une plateforme applicative de programmation. Elle permet ` l’entreprise de programmer des applications facilement administrables a dans le cloud. Elle oblige l’entreprise d’une part a maˆ ` ıtriser l’API du PaaS et d’autre part ` r´-impl´menter 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 tˆches d’administration sont a assur´es par le cloud ; l’entreprise n’a pas grand chose a effectuer. Tr`s sp´cialis´ (par e ` e e e l’application qu’il fournit), ce type de cloud est le moins r´pandu. Les clouds pour e r´seaux sociaux et jeux (pr´sent´s pr´c´demment) font partie de cette cat´gorie. e e e e e e Comme exemple de plateforme SaaS, nous pouvons citer Rightscale [RIGHSCALE] ou encore CORDYS [CORDYS]. Cette classification est la plus r´pandue dans la litt´rature. Dans le but d’´viter e e e tout malentendu, nous proposons dans le paragraphe suivant, une vision simplifi´e du e cloud. Cette pr´sentation est proche des clusters/grilles qui sont technologiquement e identiques au cloud. Notre vision. Sans entrer en contradiction avec la pr´sentation pr´c´dente, e e e nous consid´rons toute plateforme de cloud comme une plateforme ` deux niveaux e a (figure 2.2(b)) : • Abstraction et mutualisation des ressources. Ce niveau correspond exactement a l’IaaS 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 ` l’exploitation du cloud. Il s’agit a aussi bien des applications du SaaS, des applications d´velopp´es ` partir d’un e e a PaaS, que de celles issues ni du PaaS ni du SaaS. Pour aller plus loin, nous consid´rons le PaaS comme une application s’ex´cutant sur l’IaaS. De ce fait, e e il a le mˆme statut que les autres applications. L’un des d´fis du cloud est e e l’isolation de ces diff´rentes applications. e

Syst`me d’administration autonome adaptable : application au Cloud e

2.1. LE CLOUD COMPUTING

13

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

2.1.6

Challenges

Le CC n’est pas une r´volution technologique en soit mais constitue une oriene tation vers un mode de gestion des infrastructures informatiques des entreprises. Cependant, l’id´e d’h´berger plusieurs applications d’utilisateurs diff´rents pose quelques e e e d´fis que doit surmonter le cloud. Il s’agit de l’isolation, l’administration, l’interop´e 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 m´canismes (s´curit´, comptage de rese e e sources, conflit d’acc`s, etc). Le plus important de ces derniers est la gestion des e conflits/interf´rences d’acc`s entres les utilisateurs. Une r´ponse id´ale pour la mise e e e e en place de la mutualisation est l’isolation. Nous regroupons sous ce terme plusieurs types d’isolation a savoir : l’isolation des ressources, l’isolation d’espaces utilisateurs, ` l’isolation des performances et l’isolation des d´faillances. e • L’isolation des ressources (ou encore partitionnement) garantit au client l’exclusivit´ d’acc`s ` un ensemble de fractions (”morceaux”) de ressources due e a rant toute sa pr´sence dans le cloud (malgr´ la mutualisation). Le client a e e l’illusion d’ˆtre le propri´taire et consid`re l’ensemble comme des machines ene e e ti`res. Cette isolation permet d’´viter les situations de famine aux applications e e du client (situation dans laquelle une application attend ind´finiment une rese source d´tenue par une autre). De plus, elle permet au fournisseur du cloud e d’identifier et de compter les utilisations de ressources pour chaque utilisateur. Ce d´compte servira par la suite ` la facturation. e a • L’isolation d’espaces utilisateurs donne a chaque client du cloud l’illusion ` d’ˆtre le seul utilisateur. Rien ne doit le laisser pr´sager la pr´sence d’autres e e e utilisateurs ou applications. Illustrons cela a travers l’exemple d’un cloud four`

Syst`me d’administration autonome adaptable : application au Cloud e

2.1. LE CLOUD COMPUTING

14

nissant des environnements Linux. Dans cet environnement, chaque client peut acc´der en mode super utilisateur (root sous Linux) aux machines lui appare tenant. Cependant, l’ex´cution de la commande ps -aux (affichage de la liste e des processus) par exemple ne doit pr´senter que les processus d´marr´s par e e e l’utilisateur en question. • L’isolation des performances permet au cloud d’assurer le non monopole des ressources globales du cloud par un seul client. Prenons l’exemple des ressources r´seaux pour illustrer cela. Une utilisation intensive de la bande e passante sur le cloud par une application cliente peut affecter l’ensemble du r´seau et ainsi avoir un impact sur les autres utilisateurs. e • L’isolation des d´faillances permet d’assurer la non violation des espaces e utilisateurs dans le cloud. Il comprend ´galement le d´fi de s´curit´. En tant e e e e que centre d’h´bergement d’applications multi-utilisateurs, le cloud doit garane tir l’int´grit´ de chaque espace utilisateur vis-`-vis des autres. Ainsi, aucune e e a action malveillante r´alis´e par un client ne doit alt´rer ni le fonctionnement e e e du cloud ni celui des applications appartenant a d’autres clients. Cet objectif ` est d’autant plus important que la plupart des utilisateurs du cloud sont non identifiables. Il s’agit des utilisateurs des services h´berg´s par les entreprises e e dans le cloud. La prise en compte de ce d´fi a ´t´ effectu´e grˆce ` l’introduction des techniques e ee e a a de virtualisation (section 2.2) dans l’impl´mentation du cloud. e

2.1.6.2

Administration

Comme nous l’avons pr´sent´e pr´c´demment, l’exploitation des plateformes de e e e e cloud implique l’intervention de trois types d’utilisateurs : l’administrateur du cloud, les entreprises et les utilisateurs des applications des entreprises. Les deux premiers (administrateur et entreprises) sont confront´s quotidiennement ` plusieurs tˆches e a a d’administration (pour la plupart r´p´titives). L’all`gement de ces tˆches conditionne e e e a l’expansion du cloud dans les entreprises. En effet, afin d’´viter le mˆme constat e e observ´ de l’utilisation des grilles de calculs (r´serv´s aux scientifiques, donc aux e e e utilisateurs avertis), les plateformes de cloud doivent prendre en compte et faciliter les tˆches d’administration de ces deux utilisateurs. Comme nous le pr´sentons dans a e la section 3, les op´rations d’administration effectu´es par ces deux utilisateurs sont e e semblables. Notons que l’objet de cette th`se porte essentiellement sur ce challenge. e

2.1.6.3

Interop´rabilit´ et Portabilit´ e e e

Face a la multiplication des plateformes de cloud, les clients pourront ˆtre confron` e t´s plus tard ` deux choix : (1) la migration d’une application d’un cloud vers un e a autre et (2) l’utilisation de plusieurs clouds pour l’h´bergement de la mˆme applie e cation. Le choix (1) se pose par exemple lorsque la concurrence entraˆ un client ` ıne a partir du cloud qui h´berge son application vers un autre plus attrayant. Elle peut e Syst`me d’administration autonome adaptable : application au Cloud e

2.1. LE CLOUD COMPUTING

15

´galement survenir lorsque la plateforme initiale d´cide 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 l’application du e e cloud initial vers le cloud de destination. Quant au choix (2), il survient lorsque le cloud h´bergeant l’application se retrouve a cour de ressources. Dans ce cas, le client e ` ou le fournisseur peut d´cider d’associer au cloud initial des ressources venant d’une e autre plateforme. Ainsi, la mˆme application s’ex´cute dans deux environnements de e e cloud diff´rents appartenant a des fournisseurs distincts. L’ensemble form´ par les e ` e deux plateformes constitue un ”cloud hybride”. Cette situation soul`ve le probl`me e e d’interop´rabilit´ entre les plateformes de CC. Dans ces deux situations ((1) et (2)), e e la mise en place d’une API harmonis´e (par standardisation) pour le d´veloppement e e des plateformes de CC est la bienvenue.

Syst`me d’administration autonome adaptable : application au Cloud e

2.2. ISOLATION PAR LA VIRTUALISATION

16

2.2

Isolation par la virtualisation

Comme nous l’avons pr´sent´e dans la section 2.1.6.1, l’isolation (au sens de la e e pr´sentation de la section 2.1.6.1) repr´sente l’un des d´fis majeurs dans l’impl´mene e e e tation des plateformes de cloud. Il existe plusieurs fa¸ons de la mettre en œuvre : c – La premi`re m´thode consiste ` allouer la ressource mat´rielle enti`re a une e e a e e ` entreprise mˆme si celle-ci ne souscrit que pour une fraction de cette ressource. e Cette m´thode ne permet qu’une r´solution partielle des probl`mes d’isolation. e e e En effet, certaines ressources comme le r´seau et sa bande passante restent e partag´es entre les entreprises dans le cloud. A moins que le fournisseur ale loue exclusivement a chaque entreprise des ´quipements et la bande passante ` e r´seaux (ce qui n’est pas raisonnable), il est impossible avec cette m´thode e e d’´viter des situations de monopole de ces ressources par entreprise. Elle doit e ˆtre compl´t´e avec une solution logicielle. e ee – La seconde m´thode consiste ` laisser la responsabilit´ aux entreprises d’ime a e planter les m´canismes d’isolation. Cette m´thode n’est pas envisageable dans e e la mesure o` le cloud ne dispose d’aucun moyen d’introspection des applicau tions d’entreprise afin de s’assurer de l’implantation de ces m´canismes. e – La derni`re m´thode est interm´diaire (mat´rielle et logicielle) aux deux pree e e e mi`res. Tout en impl´mentant les m´canismes d’isolation, elle donne l’illusion ` e e e a l’entreprise d’avoir un acc`s direct et exclusif a la ressource mat´rielle. Parall`e ` e e lement, elle garantie au cloud le non acc`s direct des entreprises aux ressources e mat´rielles. C’est de l’isolation par virtualisation. e

2.2.1

D´finition et Principes e

La virtualisation [58] se d´finit comme l’ensemble des techniques mat´rielles et/ou e e logicielles qui permettent de faire fonctionner sur une seule machine, plusieurs syst`mes d’exploitation (appel´s machines virtuelles (VM), ou encore OS invit´). Elle e e e garantie l’ind´pendance et l’isolation des VM (l’isolation telle que pr´sent´e dans la e e e section 2.1.6.1). En bref, elle permet d’obtenir au niveau des VM la mˆme isolation e qu’offre les machines r´elles. e L’impl´mentation d’un syst`me de virtualisation repose sur une application s’ex´e e e cutant entre le mat´riel et les machines virtuelles : c’est la ”Virtual Machine Monitor e (VMM)”. C’est elle qui implante les m´canismes d’isolation et de partage des rese sources mat´rielles. La figure 2.3 montre l’architecture globale d’un syst`me d’une e e machine virtualis´e (c-`-d ex´cutant un syst`me de virtualisation). La VMM est cae a e e pable de d´marrer simultan´ment plusieurs machines virtuelles de diff´rents types e e e (Linux, Mac ou encore Windows) sur le mˆme mat´riel. Comme dans un syst`me e e e d’exploitation normal, chaque VM conserve son fonctionnement habituel. Autrement dit, elle a l’illusion de g´rer les acc`s m´moire, disque, r´seaux, processeur et e e e e autres p´riph´riques de ses processus. Vu de l’ext´rieur, l’utilisateur per¸oit l’ene e e c Syst`me d’administration autonome adaptable : application au Cloud e

2.2. ISOLATION PAR LA VIRTUALISATION

17

semble comme un environnement constitu´ de plusieurs machines r´elles. e e Quoique les VM g`rent les acc`s aux ressources, aucun acc`s aux ressources n’est e e e possible sans l’aval et le concours de la VMM. Elle d´cide notamment des attribue tions de temps processeurs aux machines virtuelles. Quant a la communication avec ` l’ext´rieur, la VMM peut fournir plusieurs techniques pour rendre accessible ou non e les VM. Elle peut la r´aliser par assignation d’adresses IP et par implantation des e m´canismes d’acc`s r´seaux aux VM (par routage, filtrage de communication, etc). e e e

En plus de fournir un syst`me d’isolation de syst`me d’exploitation, l’un des e e premiers objectifs de la virtualisation est d’offrir des performances proches de celles des machines r´elles. La section suivante pr´sente ces objectifs. e e

Figure 2.3 – Vue des syst`mes virtualis´s e e

2.2.2

Objectifs

De fa¸on g´n´rale, l’impl´mentation d’un syst`me de virtualisation doit remplir c e e e e les trois objectifs suivants [84] : L’´quivalence : toute ex´cution d’application dans un syst`me virtualis´ doit e e e e ˆtre identique a une ex´cution sur une machine r´elle ; ` l’exception du temps d’ex´e ` e e a e cution li´ ` la disponibilit´ des ressources (plusieurs ´tudes [23] montrent leur rapea e e prochement). L’efficacit´ : la majorit´ des instructions de la VM doit directement ˆtre ex´e e e e cut´e par le processeur sans intervention du logiciel de virtualisation. e Le contrˆle de ressources : l’ensemble des ressources est g´r´ de fa¸on excluo ee c sive (voir la section pr´c´dente) par le logiciel de virtualisation. Ceci permet d’assurer e e l’isolation de performance et de s´curit´. e e

Syst`me d’administration autonome adaptable : application au Cloud e

2.2. ISOLATION PAR LA VIRTUALISATION

18

2.2.3

B´n´fices pour les entreprises e e

Malgr´ le surcoˆt d’ex´cution induit (3%[27]) par les syst`mes de virtualisation e u e e actuels, la virtualisation offre plusieurs avantages aux entreprises qui en font l’usage. Nous remarquons dans la litt´rature, qu’il existe un amalgame entre les apports teche nologiques de la virtualisation et les cons´quences de ces apports dans une entreprise. e Dans cette section, nous ´vitons de faire cet amalgame. e Le tour est vite fait lorsqu’il s’agit de trouver les apports techniques de la virtualisation dans le domaine des syst`mes (en tant que domaine de recherche) : il s’agit e essentiellement de l’isolation. Pr´sent´ de cette fa¸on, d’aucuns compareront cette e e c isolation a celle d´j` propos´e par les syst`mes d’exploitation pour les processus. En ` ea e e r´alit´, le v´ritable apport est la capacit´ a isoler l’ex´cution de plusieurs syst`mes e e e e` e e d’exploitation (et non processus) dans le mˆme syst`me d’exploitation. En raison du e e rapprochement avec certains objectifs du CC, l’isolation propos´e par la virtualisae tion se d´cline ´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 b´n´fices possibles sont les suivants : e e R´duction des coˆ ts. Au lieu d’acqu´rir plusieurs serveurs mat´riels pour l’ex´e u e e e cution de logiciels incapables de cohabiter, l’entreprise utilise des machines virtuelles afin d’isoler chaque logiciel. Pour les mˆmes raisons que le CC, cette ex´cution ree e group´e permet ´galement de r´duire les coˆts en consommation ´lectrique, ou encore e e e u e en superficie des locaux qui abritent les serveurs. Un atout concerne les d´veloppeurs e de syst`mes d’exploitation. Au lieu de d´dier une machine pour la r´alisation des e e e tests, les d´veloppeurs peuvent se servir des machines virtuelles. e Unit´ de facturation. Dans un centre d’h´bergement, au lieu d’utiliser une e e machine enti`re comme unit´ d’allocation, la virtualisation permet d’allouer 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 d’´valuation. Elle se caract´rise 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 d’un des serveurs. La virtualisation permet de sauvegarder p´riodiquee ment l’´tat d’ex´cution d’une VM et de la red´marrer en cas de n´cessit´ a partir e e e e e` d’un point de sauvegarde. Cette op´ration est appel´e checkpointing dans le jargon e e de la virtualisation. Transfert de services. Nous entendons par transfert de services la possibilit´ e de d´placer l’ex´cution d’un service d’une machine r´elle a une autre sans intere e e ` ruption. Cette caract´ristique est permise dans la virtualisation via des op´rations e e de ”migration a chaud”. Elle permet d’exploiter les ressources d’une machine r´elle ` e sous-utilis´e par un service en cours d’ex´cution sur une machine r´elle sur-utilis´e. e e e e Inversement, elle permet de consolider sur un nombre r´duit de machines, des sere vices en cours d’ex´cution sur plusieurs machines sous utilis´es. Notons que tous e e

Syst`me d’administration autonome adaptable : application au Cloud e

2.2. ISOLATION PAR LA VIRTUALISATION

19

les syst`mes de virtualisation ne fournissent pas ce service. De plus leur efficacit´ e e d´pend de la technique d’impl´mentation utilis´e. e e e

2.2.4

Classification

Face ` la difficult´ de mise en œuvre du mod`le de virtualisation propos´ inia e e e tialement (virtualisation compl`te du mat´riel), a cause de la non compatibilit´ des e e ` e drivers mat´riels, plusieurs techniques de virtualisation se sont d´velopp´es. Am´lioe e e e r´es au fil des ann´es, les techniques d’impl´mentation de syst`mes virtuels peuvent e e e e ˆtre regroup´es en diff´rentes cat´gories selon le rapprochement/´loignement entre la e e e e e VM et le mat´riel. La figure 2.4 recense les cat´gories majeures que nous pr´sentons e e e bri`vement dans cette section. Le sens des fl`ches dans cette figure repr´sente cette e e e ´volution chronologique. La pr´sentation que nous donnons dans cette section suit e e ´galement cet ordre. Ainsi le d´veloppement des syst`mes les plus r´cents se justie e e e fie par les inconv´nients des pr´d´cesseurs. Notons que certains termes employ´s ici e e e e peuvent se retrouver dans la litt´rature avec des descriptions diff´rentes. e e Virtualisation du syst`me de fichiers (figure 2.4(a)). C’est une m´thode e e qui repose sur un syst`me d’exploitation pr´-install´ (syst`me hˆte). Ce dernier e e e e o permet de construire des espaces utilisateurs (d´signation de la VM ici) dont les syse t`mes de fichiers sont compl`tement isol´s. Chaque VM dispose d’une arborescence e e e de syst`me de fichiers a exclusif qui lui est propre. Les autres ressources telles que la e ` m´moire, les cartes r´seaux, le processeur sont directement accessibles par les VM. e e Il n’existe aucune isolation pour ces ressources. On retrouve dans cette cat´gorie des e outils chroot ou UML (User Mode Linux) [uml]. L’´mulation (figure 2.4(b)). La cat´gorie pr´c´dente ne permettant pas l’inse e e e tallation d’OS, il s’est d´velopp´ une technologie bas´e sur l’´mulation. Cette teche e e e nique propose une application (le virtualisateur) qui s’ex´cute au-dessus du syst`me e e hˆte, dans l’espace utilisateur. Cette application (qui correspond ` la VMM) a pour o a mission d’´muler le mat´riel et permet ainsi de d´marrer plusieurs syst`mes d’exe e e e ploitation r´els dans l’espace utilisateur. Cette technique de virtualisation induit un e surcoˆt consid´rable dans l’ex´cution des machines virtuelles. En effet, chaque op´u e e e ration effectu´e dans la VM est intercept´e et interpr´t´e par la VMM. Le syst`me e e ee e de virtualisation VirtualBox [VirtualBox.org] est bas´ sur cette technique. e Paravirtualisation (figure 2.4(c)). La paravirtualisation a ´t´ d´velopp´e ee e e pour r´soudre les probl`mes de la cat´gorie pr´c´dente. Elle consiste ` modifier les e e e e e a OS des VM afin qu’ils soient au courant de leur statut (de VM). Ainsi, le mat´riel e est mapp´ dans la VM et donc accessible directement sous le contrˆle de la VMM e o (hyperviseur sur la figure 2.4(c)). Cette derni`re s’ex´cute directement au-dessus du e e mat´riel. Elle remplace l’OS hˆte, qui est consid´r´ comme une VM. La contrainte de e o ee modification d’OS des VM est une limite ` cette technique. En effet, elle ne permet a pas l’ex´cution de VM munies d’OS propri´taires (comme Windows). La plateforme e e

Syst`me d’administration autonome adaptable : application au Cloud e

2.2. ISOLATION PAR LA VIRTUALISATION

20

Xen [23] est le syst`me de paravirtualisation le plus r´pandu grˆce au niveau de e e a performance qu’il offre [27]. Les travaux de cette th`se sont notamment bas´s sur ce e e syst`me. e Virtualisation assist´e par le mat´riel (figure 2.4(d)). L’´volution actuelle e e e des drivers mat´riels et des processeurs (technologie Intel VT [Corporation]) vers la e prise en compte de la virtualisation permet de d´velopper une nouvelle technique de e virtualisation. Ainsi, l’intervention de la VMM sur les actions des VM est limit´e et e celles-ci n’ont plus besoin d’ˆtre modifi´es. Les nouvelles impl´mentations de Xen e e e ou VMware [VMware.org] permettent d’utiliser cette technique lorsque le mat´riel e le supporte.

Figure 2.4 – Techniques de virtualisation

2.2.5

Synth`se e

Apr`s cette pr´sentation de la virtualisation, nous constatons qu’elle r´pond pare e e faitement au challenge d’isolation auquel est confront´ le cloud. De plus, nous constae tons que les b´n´fices de la virtualisation vis a vis des entreprises rejoignent ceux du e e ` Syst`me d’administration autonome adaptable : application au Cloud e

2.2. ISOLATION PAR LA VIRTUALISATION

21

cloud. Elle amplifie notamment la pratique de la mutualisation des ressources, qui est au cœur du cloud. Quant aux techniques d’isolation par r´servation enti`re de e e ressources, nous montrons qu’elles sont moins b´n´fiques. En outre, elle ne couvrent e e pas tous les besoins d’isolation 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 d’isolation. C’est cette cat´gorie de cloud qui nous int´resse e e dans cette th`se. e Son introduction dans le cloud implique la modification du mode de gestion des ressources et plus globalement des tˆches d’administration. En ce qui concerne la a gestion des ressources, l’unit´ d’allocation dans le cloud passe de la machine r´elle e e a la machine virtuelle. Quant ` l’administration, elle contraint les administrateurs ` a du cloud d’acqu´rir des comp´tences en mati`re de virtualisation. Dans la section e e e suivante, nous d´crivons a quoi correspond l’administration dans une plateforme de e ` CC bas´e sur la virtualisation. e

Syst`me d’administration autonome adaptable : application au Cloud e

Chapitre 3 Administration dans le Cloud
Contents
3.1 Administration niveau IaaS . . . . . . . . . . . 3.1.1 Allocation de ressources . . . . . . . . . . . . . 3.1.2 D´ploiement . . . . . . . . . . . . . . . . . . . e 3.1.3 Configuration et D´marrage . . . . . . . . . . . e 3.1.4 Reconfiguration . . . . . . . . . . . . . . . . . . 3.1.5 Monitoring . . . . . . . . . . . . . . . . . . . . 3.2 Administration niveau Entreprise . . . . . . . . 3.2.1 Construction de VM et D´ploiement . . . . . . e 3.2.2 Allocation de ressources . . . . . . . . . . . . . 3.2.3 Configuration et D´marrage . . . . . . . . . . . e 3.2.4 Reconfiguration . . . . . . . . . . . . . . . . . . 3.2.5 Monitoring . . . . . . . . . . . . . . . . . . . . 3.3 Synth`se : syst`me d’administration autonome e e cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pour le . . . . . . 23 . 24 . 24 . 25 . 25 . 26 . 27 . 28 . 29 . 29 . 30 . 30 . 31

Con¸ues comme une ´volution des plateformes partag´es, les clouds n´cessitent c e e e des tˆches d’administration rencontr´es dans les grilles et les environnements disa e tribu´s en g´n´ral. A celles-ci s’ajoutent celles relatives a l’introduction de la vire e e ` tualisation. Elles concernent les diff´rents protagonistes dans le cloud. Comme nous e l’avons pr´sent´ dans la section 2.1.5.2, nous distinguons trois types d’utilisateurs e e dans le cloud (figure 3.1) : le fournisseur (administre le cloud), les entreprises clientes (utilisent les ressources du cloud et administrent ses applications) et les utilisateurs finaux (ceux qui utilisent les services fournis par les applications entreprises). Contrairement aux deux premiers utilisateurs, le dernier n’est confront´ a aucune e ` tˆche d’administration. L’analyse de cette derni`re laisse paraˆ une sym´trie entre a e ıtre e les op´rations d’administration r´alis´es par le fournisseur du cloud (niveau IaaS) e e e et celles r´alis´es par les administrateurs des entreprises clientes du cloud (niveau e e entreprise) (observable sur la figure 3.2). Globalement, les gestionnaires des deux niveaux d’administration assurent des tˆches de : a

3.1. ADMINISTRATION NIVEAU IAAS

23

– D´ploiement : d´ploiement de VM au niveau IaaS et d´ploiement de logiciels e e e pour l’entreprise cliente ; – Monitoring : monitoring des ressources mat´rielles et VM au niveau IaaS (ase sur´ par l’´l´ment ”MonitoringController ” dans la figure 3.2) et monitoring des e ee logiciels au niveau entreprise cliente (assur´ par l’´l´ment ”AppMonitoringCone ee trolle” dans la figure 3.2) ; – Gestion des ressources : allocation efficace des ressources mat´rielles au nie veau IaaS (assur´e par l’´l´ment ”ResourceController ” dans la figure 3.2) et e ee r´servation efficace de VM au niveau entreprise cliente (assur´e par l’´l´ment e e ee ”AppResourceController ” dans la figure 3.2) ; – Reconfiguration : reconfiguration des VM au niveau de l’IaaS (assur´e par e l’´l´ment ”AppMonitoringControlle” dans la figure 3.2) et reconfiguration des ee logiciels, pour le passage ` l’´chelle par exemple, au niveau entreprise cliente a e (assur´e par l’´l´ment ”AppScheduler ” dans la figure 3.2). e ee Dans cette section, nous pr´sentons en d´tail et s´par´ment d’une part l’adminise e e e tration telle qu’effectu´e dans l’IaaS et d’autre part les op´rations d’administration e e r´alis´es par l’entreprise. e e

Figure 3.1 – Architecture simplifi´e du Cloud e

3.1

Administration niveau IaaS

Directement rattach´e a l’environnement mat´riel, l’administration au niveau de e ` e l’IaaS se r´sume a la gestion des machines virtuelles (pour une utilisation efficace e ` des ressources) et de ses serveurs de gestion (scheduler, serveurs de stockage, etc.). Ne pouvant ˆtre r´alis´es en avance, certaines tˆches d’administration de l’IaaS sont e e e a provoqu´es par celles des entreprises (elles seront interpr´t´es comme des op´rations e ee e de reconfiguration). Parmi les op´rations d’administration au niveau IaaS, les plus e courantes sont : l’allocation de ressources, le d´ploiement de ses serveurs et des VM, e la configuration et le d´marrage (des VM et ses serveurs). Quant aux autres, elles sont e

Syst`me d’administration autonome adaptable : application au Cloud e

3.1. ADMINISTRATION NIVEAU IAAS

24

provoqu´es par des ´v´nements externes pour certaines (consolidation, r´paration) e e e e et r´guli`res pour d’autres (monitoring). e e

3.1.1

Allocation de ressources

C’est la premi`re op´ration r´alis´e dans le cloud. Elle attribue ` l’entreprise e e e e a cliente sa portion de ressources exploitables. Par ressources, nous regroupons ` la fois a la m´moire, le processeur, l’espace de stockage, la bande passante et les ´quipements e e informatiques. Mutualis´es entre tous les utilisateurs, les ressources repr´sentent le e e point de rentabilit´ pour le fournisseur. Ainsi, la conception et l’impl´mentation e e des politiques d’allocation dans le cloud d´pendent de la strat´gie commerciale du e e fournisseur. Notons que l’allocation est provoqu´e entre autres par une r´servation e e de l’entreprise. Le fournisseur peut dont proposer plusieurs mani`res de r´servation : e e 1. R´servation pour une dur´e ind´termin´e : dans ce mode, un contrat est ´tabli e e e e e avec l’entreprise pour une dur´e infinie et continue (on peut ´galement parler e e de forfait). 2. R´servation pour une utilisation ` venir et pour une dur´e limit´e : dans ce e a e e mode, la difficult´ se situe dans la gestion des plages de r´servation. On retrouve e e le probl`me tr`s connu et complexe qui est celui de la planification. e e 3. R´servation pour une utilisation imm´diate et limit´e dans le temps : dans ce e e e cas, les ressources requises doivent ˆtre disponibles dans l’imm´diat. e e La prise en compte de ces modes de r´servation peut complexifier l’allocation dans le e cloud. Notamment, il peut ˆtre amen´ ` mettre en place des files d’attente, avec des e ea notions de priorit´. Ainsi, en guise d’exemple, les ressources obtenues par le dernier e mode de r´servation peuvent ˆtre consid´r´es comme moins prioritaires que celles e e ee obtenues via les deux premiers. Dans ce cas, le cloud doit ˆtre capable d’identifier e les ressources ` lib´rer en cas de besoin d’une application plus prioritaire. a e

3.1.2

D´ploiement e

Le d´ploiement dans l’IaaS concerne essentiellement les syst`mes de fichiers des e e machines virtuelles. Il est r´alis´ ` deux occasions. Premi`rement (fl`che (2) de la e ea e e figure 3.2) lors de l’enregistrement dans le cloud des syst`mes de fichiers d’OS (´gae e lement appel´s images) et des donn´es de l’entreprise. Pour cela, le cloud utilise un e e serveur de stockage (que nous appelons RepositoryController dans la figure 3.2) distinct des lieux d’ex´cution des VM. Le second d´ploiement (fl`che (4) de la figure 3.2) e e e intervient a l’ex´cution de celles-ci. En effet, l’image utilis´e pour l’ex´cution d’une ` e e e VM dans le cloud est une copie de l’image initiale. Ceci s’explique par deux raisons. La premi`re est la possible inaccessibilit´ des machines hˆtes (h´bergeant les VM) e e o e au serveur de stockage. Tr`s souvent, pour des raisons d’efficacit´, le format de stoe e ckage des donn´es (y compris les syst`mes de fichiers) par le serveur de stockage e e peut ˆtre diff´rent de celui attendu par le syst`me de virtualisation qui ex´cutera la e e e e Syst`me d’administration autonome adaptable : application au Cloud e

3.1. ADMINISTRATION NIVEAU IAAS

25

VM. C’est le cas dans le cloud Amazon EC2 [61]. La deuxi`me raison est la possible e utilisation de la mˆme image pour l’ex´cution de plusieurs VM. De plus, l’entreprise e e peut souhaiter retrouver l’image originale apr`s l’ex´cution de la VM (sauf demande e e contraire).

3.1.3

Configuration et D´marrage e

L’op´ration de d´marrage des machines virtuelles n´cessite pr´alablement leur e e e e configuration. Cette derni`re d´pend d’une part des demandes de l’entreprise et e e d’autre part de la politique d’allocation de ressources dans le cloud. Pendant la phase de r´servation, une entreprise souscrit pour des VM dont elle fournit les cae ract´ristiques au cloud. Ces caract´ristiques concernent : la quantit´ de m´moires, e e e e le nombre de processeurs, le lieu g´om´trique d’ex´cution de la VM et le syst`me de e e e e fichiers repr´sentant l’OS de la VM. Quant aux contraintes de configuration venant e de l’IaaS, il s’agit des configurations r´seaux. En effet, l’IaaS peut impl´menter plue e sieurs configurations d’acc`s r´seaux : l’attribution d’un r´seau virtuel (VLAN) aux e e e VM appartenant a la mˆme entreprise ou encore l’utilisation d’un VLAN commun ` e pour toutes les VM (il ne s’agit que d’exemples). Il doit ´galement configurer les e contrˆles r´seaux (pare feu ou encore les quotas d’utilisation r´seau) en fonction des o e e souscriptions de l’entreprise.

3.1.4

Reconfiguration

Comme nous l’avons ´voqu´ dans le pr´ambule de cette section, la plupart des e e e tˆches d’administration au niveau de l’IaaS peuvent ˆtre interpr´t´es comme des a e ee op´rations de reconfiguration (r´alis´es par le ”VMController ” sur la figure 3.2). En e e e effet, elles interviennent pendant l’ex´cution de l’IaaS et modifient sa composition. e Dans cette section, nous pr´sentons quelques tˆches de reconfigurations particuli`res, e a e li´es essentiellement a la gestion des VM : la consolidation et la r´paration. e ` e Consolidation de VM Nous nous rappelons des plateformes d’h´bergement dans lesquelles des machines e enti`res ´taient d´di´es ` un client. Dans ces plateformes, aucune tˆche d’adminise e e e a a tration de la part du fournisseur n’´tait envisageable une fois la machine allou´e e e au client (au risque de violer l’exclusivit´ d’utilisation de la machine par le client). e A l’inverse, les clouds bas´s sur la virtualisation offrent une marge a l’administrae ` teur de l’IaaS pour une intervention sur les machines physiques. Cette possibilit´ e est offerte par le caract`re isolant de la virtualisation. Elle permet entre autres au e fournisseur d’impl´menter diff´rentes politiques d’allocation ou redistribution de rese e sources, dans le but d’effectuer des ´conomies ou de respecter un contrat client. e La premi`re intervention dans la gestion de ressources survient pendant la phase e

Syst`me d’administration autonome adaptable : application au Cloud e

3.1. ADMINISTRATION NIVEAU IAAS

26

d’allocation de VM (elle est ´galement dite phase de placement). Durant cette phase, e l’IaaS doit ˆtre capable d’identifier l’ensemble des machines physiques correspondant e a la politique d’allocation implant´e 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 d´placement des e VM en cours d’ex´cution afin de lib´rer de la place pour la VM allou´e. On parle e e e de consolidation de VM. Par exemple prenons le cas d’un IaaS constitu´ de trois e machines physiques M P1 , M P2 et M P3 de puissance identique not´e p. Supposons e que M P1 et M P2 utilis´es respectivement ` moiti´ de leur puissance. Soit un client e a e ayant besoin d’une machine virtuelle dont la puissance requise est 3 p. Dans cette 4 situation, au lieu de faire recours a la troisi`me machine virtuelle, l’IaaS 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 d’allouer par la suite l’une des machines lib´r´es ` ee a la nouvelle machine virtuelle. Notons que la consolidation peut ´galement s’effectuer en dehors des op´rations e e d’allocation. En effet, l’IaaS scrute r´guli`rement son environnement et r´organise e e e la disposition des VM sur les machines afin de lib´rer certaines. Cette lib´ration de e e machines permet de r´duire les taux de consommation ´nerg´tique de l’IaaS. e e e R´paration de pannes e Compte tenu de la taille du cloud et de la multitude d’utilisateurs et du nombre de clients qu’il accueille, le risque d’apparition de pannes est important. L’apparition d’un dysfonctionnement doit ˆtre rapidement identifi´e et trait´e par l’administrae e e teur afin de ne pas p´naliser les entreprises. L’une des pannes les plus critiques dans e l’IaaS est le dysfonctionnement d’une machine physique ou virtuelle. En effet, elle affecte les applications des entreprises. A cause de sa non intrusivit´, l’IaaS n’est pas e au courant des logiciels en cours d’ex´cution dans les VM qu’il h´berge. De ce fait, e e l’IaaS ne saurait r´soudre efficacement une panne sans la collaboration de l’entreprise e concern´e. Malgr´ cette limitation, l’IaaS peut profiter des atouts de la virtualisation e e et proposer ainsi plusieurs politiques de r´paration. Celles-ci peuvent aller des plus e simples (red´marrage de la VM concern´e) aux plus sophistiqu´es (red´marrage sur e e e e le dernier point de sauvegarde). L’application de ces politiques peut d´pendre des e termes du contrat souscrit par l’entreprise. Dans tous les cas, la mise en place de ces politiques d´pend du syst`me de surveillance implant´ dans l’IaaS. e e e

3.1.5

Monitoring

Les sections pr´c´dentes ont introduit la notion de monitoring. En effet, toutes e e les tˆches d’administration dans le cloud d´pendent des informations obtenues par a e monitoring des environnements mat´riels, virtuels et logiciels (r´alis´ par ”Monitoe e e ringController ” sur la figure 3.2). Parmi les informations de monitoring qui nous int´ressent, nous pouvons citer le taux d’utilisation des processeurs, des disques, du e r´seau, de la m´moire, etc. Cependant, l’architecture particuli`re du cloud et des ape e e

Syst`me d’administration autonome adaptable : application au Cloud e

3.2. ADMINISTRATION NIVEAU ENTREPRISE

27

plications qui y sont ex´cut´es constitue un facteur limitant pour le monitoring. En e e effet, r´put´ comme une tˆche complexe dans les environnements distribu´s constie e a e tu´s de machines r´elles, le monitoring dans le cloud est un v´ritable challenge. e e e Les ressources ´tant virtualis´es dans le cloud, il n’est pas ´vident de fournir une e e e image refl´tant l’´tat r´el des machines. En effet, nous distinguons deux niveaux e e e d’observation et d’analyse de ressources : la machine virtuelle et la machine physique. D’une part, l’IaaS doit ˆtre capable de s´parer les ressources consomm´es par e e e chaque niveau afin de fournir aux clients des informations relatives uniquement a ` leur consommation. D’autre part, l’IaaS doit fournir ` son administrateur les infora mations concernant a la fois les VM et les machines les h´bergeant. Dans les deux ` e cas, les informations doivent ˆtre compr´hensibles et exploitables. e e Jusqu’` pr´sent, nous n’´voquons que des informations locales ` chaque machine a e e a physique ou virtuelle. Or le cloud est un syst`me r´parti et h´t´rog`ne. Dans la e e ee e plupart des cas, l’administrateur s’int´resse aux informations agr´g´es et obtenues e e e par calculs group´s des observations locales. Par exemple, ce calcul peut se faire par e combinaison des informations provenant d’un ensemble de machines appartenant ` a la mˆme zone g´ographique ou a la mˆme entreprise. e e ` e

Figure 3.2 – Administration dans le cloud

3.2

Administration niveau Entreprise

Malgr´ les avantages qu’il offre, le cloud peine a s´duire les entreprises depuis sa e ` e vulgarisation. Cette h´sitation est d’ordre id´ologique : l’id´e de confier ses donn´es e e e e (essentielles pour la concurrence) a une entreprise externe n’est pas encore compl`` e tement accept´e dans les entreprises. Face cette id´e, le cloud r´pond avec plus de e e e

Syst`me d’administration autonome adaptable : application au Cloud e

3.2. ADMINISTRATION NIVEAU ENTREPRISE

28

d´veloppement de la s´curit´ et la confidentialit´. Comme en interne, l’administrae e e e tion d’applications sur le cloud est une tˆche fastidieuse pour l’entreprise. De plus, a dans le cadre des clouds virtualis´s, la gestion des VM repr´sente une op´ration e e e suppl´mentaire. En somme, l’administration d’applications dans un cloud virtualis´ e e comprend les tˆches suivantes : a • Construction de syst`mes d’exploitation (ou VM) ; e • R´servation/Allocation de ressources sur le cloud ; e • Installation et d´marrage des logiciels ; e • Suivi de l’ex´cution des logiciels et des VM ; e • Reconfiguration/Optimisation (scalabilit´, mise ` jour des logiciels, r´paration, e a e etc.).

3.2.1

Construction de VM et D´ploiement e

L’ex´cution de toute application par une entreprise dans le cloud a lieu dans e une VM. L’ex´cution de cette derni`re requiert la pr´sence de son image dans le e e e serveur de stockage du cloud. Pour l’entreprise, le d´ploiement peut donc s’effectuer e a deux occasions : pendant le t´l´chargement du syst`me de fichiers des VM (fl`che ` ee e e (2) sur la figure 3.2) et pendant la copie (de l’entreprise vers les VM) des binaires des logiciels constituant son application (fl`che (5) sur la figure 3.2). Comme nous le e pr´sentons dans cette section, le second d´ploiement peut s’appuyer sur le premier. e e La premi`re ´tape avant toute r´servation sur le cloud est la construction des e e e syst`mes de fichiers. Elle comprend les phases suivantes : (1) installation du syst`me e e d’exploitation, (2) configuration du syst`me d’exploitation et (3) ´ventuellement e e l’installation des packages ou binaires des futurs logiciels. Dans certains cas, les phases (1) et (2) ne sont pas n´cessaires lorsque le cloud fournit un syst`me de e e fichiers r´pondant aux attentes de l’entreprise. Dans tous les cas, l’entreprise effectue e la derni`re ´tape qui est l’installation de ses logiciels. Cette tˆche peut s’effectuer de e e a diff´rentes fa¸ons. e c M´thode 1 : Elle construit un OS contenant tous les binaires et packages de tous e ses logiciels (fl`ches (1), (1’) et (1”) sur la figure 3.2). La construction s’effectue chez e elle et le r´sultat (un OS de grande taille) est ensuite transf´r´ sur le cloud grˆce aux e ee a protocoles de sauvegarde qu’il fournit. C’est par exemple le cas avec Simple Storage Service (S3) du cloud Amazon EC2. Le b´n´fice de cette m´thode est la r´duction e e e e du nombre de syst`mes de fichiers sauvegard´s dans le cloud (donc des coˆts de e e u stockage). Par contre a l’ex´cution, l’entreprise paye le prix fort. En effet, l’ex´cution ` e e de toute VM a partir de cet OS augmente l’espace de stockage de l’entreprise et donc ` le coˆt d’ex´cution. u e M´thode 2 : Construction d’un syst`me de fichiers d´di´ pour chaque type de e e e e logiciels (fl`ches (1) et [(1’) ou (1”)] sur la figure 3.2). Les avantages de cette m´thode e e sont les inconv´nients de la pr´c´dente et inversement. Autrement dit, elle est moins e e e Syst`me d’administration autonome adaptable : application au Cloud e

3.2. ADMINISTRATION NIVEAU ENTREPRISE

29

coˆteuse lorsque les VM sont a l’ex´cution qu’` l’arrˆt. En effet, soient ts la taille u ` e a e d’un syst`me d’exploitation, n le nombre de logiciels constituant l’application, tli la e taille du i`me logiciel avec i ∈[1 ; n] . L’espace de stockage dans cette m´thode est e e n n n*ts + i=1 tli (avec n le nombre de logiciels) tandis qu’il est de ts + i=1 tli dans la premi`re m´thode. e e M´thode 3 : La derni`re est une solution interm´diaire aux deux premi`res e e e e (fl`ches (5) sur la figure 3.2). Le syst`me de fichier ne contient que l’OS minimal ` e e a ex´cuter. Ainsi a l’ex´cution, l’administrateur effectue les op´rations de d´ploiement e ` e e e et d’installation des logiciels sur ses instances de VM. Elle pr´sente les avantages e de la premi`re et de la seconde approche. Par contre, elle est plus technique, fase tidieuse et n´cessite plusieurs connexions ` distance sur les VM. Ainsi, pour une e a ex´cution multiple du mˆme logiciel, l’administrateur r´alise plusieurs installations e e e de ce logiciel.

3.2.2

Allocation de ressources

L’allocation de ressources pour l’entreprise peut consister en la r´servation des e lieux de stockage ou encore des machines. La premi`re permet de stocker les images e d’OS construites ou des donn´es utilisables par la suite par les VM. Rappelons e que ces derni`res ne sont pas vues par l’entreprise comme des VM. Pour elle, il e s’agit de machines physiques mises a sa disposition par le cloud et dont elle est ` propri´taire. Cette op´ration est faite sous forme de contrats pass´s avec le cloud. e e e L’entreprise souscrit pour plusieurs ressources de capacit´s identiques ou non (en e terme de processeur, m´moire, bande passante, etc). Cette r´servation se traduit au e e niveau de l’IaaS par le d´marrage des VM correspondantes et par la transmission e a l’entreprise des informations de connexion (fl`che (3) sur la figure 3.2). La fin ` e du contrat entraˆ l’arrˆt des VM et la lib´ration des ressources qui leur ´taient ıne e e e allou´es. e

3.2.3

Configuration et D´marrage e

Une fois les VM d´marr´es et les binaires des logiciels d´ploy´s, l’administrateur e e e e de l’entreprise planifie la configuration et le d´marrage des logiciels. Ces op´rations e e n´cessitent des acc`s multiples aux VM via les adresses IP ou nom DNS des VM. e e Elles d´pendent des logiciels administr´s. Dans certains cas, le d´marrage peut n´e e e e cessiter la configuration des liens de communication entre logiciels situ´s sur des VM e diff´rentes. A cause de la multitude des logiciels, ces op´rations sont souvent sources e e d’erreurs. De plus, certaines applications imposent un ordre de d´marrage entre les e logiciels. C’est le cas par exemple des serveurs Tomcat qui doivent ˆtre d´marr´s e e e avant les serveurs web Apache dans une application J2EE.

Syst`me d’administration autonome adaptable : application au Cloud e

3.2. ADMINISTRATION NIVEAU ENTREPRISE

30

3.2.4

Reconfiguration

Comme pour l’IaaS, les op´rations de reconfiguration r´alisables par l’entreprise e e peuvent ˆtre d´nombr´es a l’infini (r´alis´es par ”Scheduler d’applications” sur la e e e ` e e figure 3.2). Dans cette section, nous pr´sentons deux op´rations particuli`res, tr`s e e e e courantes dans l’administration des applications distribu´es : e Scalabilit´ e Une fois l’application d´marr´e, l’entreprise doit ˆtre capable de suivre l’´tat des e e e e diff´rents logiciels (voir la section suivante sur le monitoring) afin d’intervenir en e cas de n´cessit´. Par exemple, l’observation d’une mont´e en charge au niveau d’un e e e tiers J2EE incitera l’administrateur ` r´server une nouvelle VM et effectuer tout le a e processus de d´marrage d’une nouvelle instance du logiciel concern´ afin d’absorber e e le surplus de charge. Inversement, il pourra retirer des instances de serveurs lorsque celles-ci sont sous utilis´es. L’ensemble de ces deux op´rations permettra de r´aliser e e e des ´conomies (par diminution du nombre de VM en utilisation dans le cloud). Cette e pratique est commun´ment appel´e scalabilit´ ou principe de la croissance ` e e e a la demande. R´paration e Comme en interne, deux types de pannes peuvent survenir durant l’ex´cution e de l’application : (1) une panne machine (VM ici) ou (2) une panne logicielle. Ne disposant d’aucune action r´paratrice sur ses VM, l’entreprise peut souscrire (aupr`s e e du cloud) pour un contrat de r´paration en cas de (1). Dans ce cas, l’entreprise peut e ˆtre amen´e a red´ployer et d´marrer les logiciels qui s’ex´cutaient sur la VM avant e e ` e e e la panne. Si l’IaaS implante la sauvegarde r´guli`re des VM, l’entreprise n’a aucune e e r´paration ` effectuer. Quant aux pannes de type (2), leurs r´parations d´pendent e a e e de l’application. Elles sont de ce fait hors de la port´e du cloud. Dans certaines e applications, une panne de type (1) ou (2) peut entraˆ ıner la reconfiguration enti`re e de l’application. C’est le cas de l’application J2EE dans laquelle une panne du logiciel Tomcat n´cessite le red´marrage du logiciel Apache. e e

3.2.5

Monitoring

La plupart des informations de monitoring recueillies a ce niveau proviennent ` directement des API de l’IaaS (liaison entre ”Monitoring d’applications” et ”Monitoring de l’IaaS ” sur la figure 3.2). Cependant, dans certains cas, ces informations sont insuffisantes. Par exemple, la d´termination de l’´tat de surcharge d’un serveur e e de base de donn´es est plus significatif lorsqu’on observe son temps de r´ponse au e e lieu de la charge CPU de la machine qui l’h´berge. Pour ces cas particuliers, l’ade ministrateur introduit dans son application, des logiciels particuliers jouant le rˆle o de sonde (liaisons entre ”Monitoring d’applications” et les VM sur la figure 3.2). Les informations r´cup´r´es par ces sondes sont analys´es de fa¸on individuelle ou e ee e c group´e et servent a la prise de d´cision (pour des reconfigurations). e ` e Syst`me d’administration autonome adaptable : application au Cloud e

` ` 3.3. SYNTHESE : SYSTEME D’ADMINISTRATION AUTONOME POUR LE CLOUD 31

3.3

Synth`se : syst`me d’administration autonome e e pour le cloud

En r´sum´, l’administration dans le cloud est essentiellement li´e a son exploie e e ` tation niveau IaaS et niveau entreprise. Dans les deux niveaux, nous retrouvons des op´rations d’administration du mˆme type. Elles sont proches de celles rencontr´es e e e dans les grilles de calcul et les environnements distribu´s. Au niveau IaaS, l’adminise tration consiste en la gestion des ressources. De plus l’utilisation de la virtualisation implique des tˆches d’administration suppl´mentaires qui lui sont propres. Quant a e a l’entreprise, ses tˆches d’administration sont ` l’origine des reconfigurations au ` a a niveau de l’IaaS. Elles sont pour la plupart propres aux applications h´berg´es. e e Devant la multitude de ces tˆches, fournir une solution fig´e serait limit´e et a e e inappropri´e dans certaines situations. De plus, ni le cloud, ni l’entreprise ne peut e s’offrir les services d’administrateurs humains qui assureront de fa¸on permanente c et continue (` longueur de journ´e) toutes ces tˆches. Ainsi, comme nous l’avons a e a effectu´ dans l’administration des syst`mes distribu´s (grilles et cluster), nous proe e e posons dans cette th`se l’utilisation d’un syst`me d’administration autonome pour e e am´liorer l’administration dans le cloud. Ce syst`me doit ˆtre utilisable par les deux e e e types d’intervenants. Pour cela, il doit globalement remplir les crit`res suivants : e – Interop´rable : capacit´ a dialoguer avec d’autres syst`mes de gestion de e e ` e cloud et ´galement des syst`mes d’administration des applications qu’il h´e e e berge. – Auto-r´parable : capacit´ ` prendre en compte les pannes dans l’environnee ea ment qu’il administre (machines, VM et logiciels). – Extensible : capacit´ ` prendre en compte de nouveaux ´l´ments dans l’enea ee vironnement (nouvelles machines r´elles et virtuelles, nouveaux logiciels). e – Programmable : capacit´ a prendre en compte de nouvelles politiques d’ade` ministration (nouvelle m´thode de consolidation, de scalabilit´, etc.). e e – Adaptable : capacit´ a prendre en compte le remplacement ou la modification e` d’un de ses modules afin de s’appliquer a d’autres plateformes de cloud. ` – Langages d´di´s : propose des facilit´s d’utilisation par le biais des langages e e e d’administration proches des comp´tences des intervenants. e Dans le chapitre suivant, nous montrons en quoi consiste l’administration autonome et dans quelle mesure l’administration autonome peut ˆtre utilis´e dans cette proe e bl´matique. e

Syst`me d’administration autonome adaptable : application au Cloud e

Chapitre 4 Administration Autonome
Contents
4.1 4.2 4.3 4.4 4.5 D´finition . . . . . . . . . . . . e Objectifs . . . . . . . . . . . . . B´n´fices pour les entreprises e e Classification . . . . . . . . . . Synth`se . . . . . . . . . . . . . e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 33 34 35 36

Nous constatons depuis plusieurs ann´es la complexit´ croissante des infrastruce e tures et syst`mes informatiques. Cette complexit´ est due ` plusieurs facteurs tels e e a que la diversification des supports informatiques, la mobilit´ des utilisateurs, la mule tiplication des besoins et des logiciels, et l’augmentation du nombre d’utilisateurs d’outils 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 diff´rentes. De ce fait, leurs administration peut devenir un v´ritable obse e tacle a leur p´rennit´. Elle peut devenir source d’erreurs et ˆtre tr`s consommatrice ` e e e e en ressources humaines. Dans cette section, nous pr´sentons une solution consistant e a confier cette tˆche a un autre syst`me informatique (on parle d’administration ` a ` e autonome).

4.1

D´finition e

Un Syst`me d’Administration Autonome est un syst`me informatique con¸u pour e e c l’administration d’autres syst`mes informatiques (mat´riels et logiciels). Dans la e e suite de ce document, nous utilisons l’acronyme SAA pour d´signer un Syst`me e e d’Administration Autonome. Le fonctionnement d’un tel syst`me repose sur quatre e modules essentiels (figure 4.1) : • Le syst`me de repr´sentation : Il maintient une image de l’ex´cution r´elle e e e e de l’application administr´e. e

4.2. OBJECTIFS

33

• Les sondes : Elles repr´sentent en quelque sorte l’œil du SAA sur les machines e h´bergeant les logiciels qu’il administre. e • Un module d´cisionnel : En fonction des observations faites par les sondes e et de l’´tat courant de l’application, le SAA peut prendre des d´cisions confore e m´ment aux pr´visions de l’administrateur humain. e e • Les effecteurs/actionneurs : Contrairement aux sondes, ils permettent au SAA de r´aliser effectivement les op´rations d’administration. 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 repr´sentation. Leur intervention peut modifier le comportement e e de l’application administr´e. e

Figure 4.1 – Organisation d’un SAA

4.2

Objectifs

R´alis´e par des humains, l’administration 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 s’ex´cutant dans des environnements h´t´rog`nes et distribu´s e ee e e (cas d’un environnement de cloud). Parmi ces limites, nous pouvons citer : • Le manque de r´activit´ dans la r´alisation des tˆches : par exemple en r´ponse e e e a e a une panne ou configuration d’un syst`me constitu´ de plusieurs logiciels. ` e e • Le gaspillage de ressources. C’est une cons´quence du manque de r´activit´. e e e Dans le but de pr´venir des fortes demandes en ressources, l’administrateur e a tendance a sur-´valuer celles-ci. Cette sur-´valuation lui permet d’avoir une ` ` e e marge de temps avant l’intervention.

Syst`me d’administration autonome adaptable : application au Cloud e

´ ´ 4.3. BENEFICES POUR LES ENTREPRISES

34

En r´ponses a ces limites, le d´veloppement de syst`mes informatiques jouant e ` e e le rˆle d’administrateur est une solution ´prouv´e ` travers plusieurs travaux de o e e a recherche. Pour cela, le SAA prend g´n´ralement en compte tout le cycle de vie de e e l’application administr´e a savoir [60] [78] [63] : e ` Le d´ploiement. Il consiste en l’allocation de ressources mat´rielles suivie de e e leur initialisation. Nous entendons par ressources toutes les ressources m´moire, e CPU, disques, r´seau et machines n´cessaires au fonctionnement de l’application. e e L’initialisation de la machine consiste au ravitaillement de celle-ci en fichiers ou binaires constituant l’application. La configuration. Elle consiste ` d´finir les param`tres requis par l’application a e e pour son fonctionnement. Elle se fait g´n´ralement par la modification des fichiers e e ou encore le positionnement de certaines variables. Le d´marrage et l’arrˆt. Il s’agit de l’ex´cution des diff´rentes commandes e e e e mettant en marche ou non l’application. Comme nous l’avons ´voqu´ dans la sece e tion 3.2.3, le d´marrage peut s’av´rer quelques fois ordonn´. e e e La reconfiguration dynamique. Il s’agit des op´rations survenant durant e l’ex´cution de l’application. Elle peut ˆtre caus´e par plusieurs facteurs : l’apparition e e e d’une panne, l’essoufflement d’un logiciel faisant partie de l’application, l’apparition d’une mise ` jour, le d´sir d’optimisation, etc. Dans la litt´rature, les op´rations de a e e e configuration, de d´marrage et d’arrˆt peuvent ˆtre pr´sent´es comme des tˆches de e e e e e a reconfiguration. La prise en compte de ces tˆches par les syst`mes d’administration autonome a e justifie son adoption dans des entreprises comme solution d’administration. Dans la section suivante, nous pr´sentons les b´n´fices d’une telle pratique dans une entree e e prise.

4.3

B´n´fices pour les entreprises e e

Les b´n´fices de l’administration autonome en entreprise sont aussi ´vidents que e e e ceux de l’informatique dans une entreprise qui n’en dispose pas. En effet, con¸u pour c remplir les fonctions d’un administrateur humain, un SAA permet ` l’entreprise de a r´aliser des ´conomies : e e Gain de temps. L’administration assur´e par l’humain implique des intervene tions ´valu´es en minutes, heures et voie jours. Or l’utilisation d’un SAA fait passer e e les temps d’intervention ` la seconde ou milliseconde dans certains cas. Cette diff´a e rence peut ˆtre facilement observ´e dans les tˆches de d´ploiement des applications e e a e grande ´chelle (centaines de logiciels). e

Syst`me d’administration autonome adaptable : application au Cloud e

4.4. CLASSIFICATION

35

R´duction des ressources. Le remplacement des administrateurs humains par e un syst`me informatique permet dans un premier temps a l’entreprise de r´duire e ` e son effectif. Cette r´duction implique moins de d´penses salariales. De plus, comme e e nous l’avons ´voqu´ dans la section pr´c´dente, l’introduction d’une administration e e e e autonome implique moins de gaspillage en ressources mat´rielles. En effet, l’entree prise n’´tant plus limit´e par la lenteur de l’humain et donc de sa surestimation, e e les ressources sont allou´es et utilis´es par n´cessit´. Cette r´duction de ressources e e e e e implique ´galement une ´conomie en ´nergie ´lectrique. e e e e Adaptabilit´ des logiciels. L’administration autonome permet de rendre adape table les logiciels n’ayant pas ´t´ con¸us a cet effet. C’est le cas des logiciels tels que ee c ` Apache [52] ou Tomcat [53]. On dit d’un syst`me qu’il est adaptable lorsqu’il est e capable de prendre en compte des modifications de son environnement ou encore de son fonctionnement. L’adoption d’un SAA permettra de prendre en compte ces modifications. Il peut s’agir d’une adaptation ` une surcharge de travail d’un logiciel. a Nous pouvons ´galement citer le cas de la r´paration d’une panne logicielle. e e

4.4

Classification

Depuis la pose des pr´misses de cette technologie par IBM en 2003, plusieurs e projets de construction de SAA ont vu le jour. Ces d´veloppements s’effectuent e suivant diff´rentes orientations. Dans cette section, nous proposons quelques crit`res e e permettant de les regrouper par familles. Centralis´ ou distribu´. L’efficacit´ (en terme de temps d’ex´cution) d’un e e e e SAA est fortement li´e 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 ` l’administration des syst`mes de taille r´duite (` a e e a cause du risque d’un goulot d’´tranglement). Quant au fonctionnement distribu´, e e l’administration peut ˆtre effectu´e ` n’importe quel lieu de l’environnement. 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 distribu´s. Ces derniers e e incluent ` la fois les SAA hi´rarchis´s et non hi´rarchis´s. Dans le premier cas, chaque a e e e e point d’administration ` la responsabilit´ d’un morceau de l’application administr´e. a e e En cas d’impossibilit´ d’administration, la tˆche est transmise au point sup´rieur 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 afin d’avoir des ´tats identiques. e e Adaptable ou non. Les SAA apportent de l’adaptabilit´ aux infrastructures e qu’ils administrent. Cela ne les empˆche pas de poss´der ´galement les mˆmes facule e e e t´s. Un SAA adaptable donne la possibilit´ ` l’utilisateur de remplacer des modules e ea ou des fonctions de base de l’administration. Par exemple, les m´thodes de d´ploiee e ment ou d’acc`s a distance sur les machines administr´es peuvent ˆtre remplac´es e ` e e e par d’autres fonctions propres a l’utilisation courante. ` Syst`me d’administration autonome adaptable : application au Cloud e

` 4.5. SYNTHESE

36

G´n´rique ou sp´cifique. La plupart des SAA existants sont con¸us 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 l’application administr´e n´cessite la e e r´implantation du SAA. e

4.5

Synth`se e

A la lumi`re de cette pr´sentation, nous constatons dans un premier temps que le e e cloud fait partie des infrastructures dites complexes : plusieurs utilisateurs, plusieurs types d’applications, plusieurs technologies mises en commun, environnements distribu´s et large ´chelle. Dans un second temps, nous constatons que les tˆches d’ade e a ministration dans le cloud (section 3) correspondent parfaitement a celles auxquelles ` r´pond l’administration autonome. A cause de sa nouveaut´, les solutions d’adminise e tration autonome n’ont pas fait l’objet de plusieurs exp´rimentations dans le cadre e du cloud. Dans la suite de ce document, nous explorons l’utilisation de SAA pour l’administration dans le cloud. Notre ´tude s’appuie sur le SAA TUNe [28] d´velopp´ e e e au sein de notre ´quipe. Le chapitre suivant pr´sente les principes fondateurs de ce e e syst`me. e

Syst`me d’administration autonome adaptable : application au Cloud 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 Reconfiguration Description Language (RDL) 5.3 Choix d’implantation . . . . . . . . . . . . . . 5.4 Exp´rimentations et Probl´matiques . . . . . e e 5.4.1 Applications cluster . . . . . . . . . . . . . . 5.4.2 Applications large ´chelle : cas de DIET . . . e 5.4.3 Applications virtualis´es . . . . . . . . . . . . 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

Exer¸ant dans le domaine de l’administration autonome depuis plusieurs ann´es c e maintenant, l’´quipe dans laquelle ces travaux ont ´t´ r´alis´s a d´velopp´ autour du e ee e e e e projet TUNe [29], un SAA baptis´ du mˆme nom. Avant de pr´senter ses principes e e e fondamentaux, nous revenons sur son historique. La fin de ce chapitre pr´sente les e diff´rentes exp´riences r´alis´es avec ce syst`me, ses limitations ainsi que sa nouvelle e e e e e orientation. Pour des fins d’illustration, tout exemple dans ce chapitre se base sur l’administration d’une application J2EE. Il s’agit d’une application web dynamique organis´e e suivant une architecture n-tiers (figure 5.1) compos´e 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 afin d’absorber une quantit´ importante e` e d’utilisateurs ; – Tomcat [53] : le serveur d’applications qui, a la demande de Apache (via ` son connecteur ModJK [54] par exemple), effectue des traitements pour la construction d’une page web ;

5.1. HISTORIQUE

38

Figure 5.1 – Exemple d’une architecture J2EE – MySQL [98] et MySQL-Proxy [66] : ce dernier permet de relier le serveur d’applications a plusieurs sources de donn´es MySQL. En cas de besoin, le ` e serveur d’applications fait appel au serveur de donn´es MySQL pour le retrait e ou la sauvegarde de donn´es venant des clients web. e

5.1

Historique

Le projet TUNe voit le jour en 2008 au sein de l’´quipe Astre du laboratoire e IRIT (Institut de Recherche en Informatique de Toulouse). Il s’inscrit dans la continuit´ des projets SELFWARE 1 et SCOrWare 2 . L’objectif principal du projet SELFe WARE est le d´veloppement d’une plateforme logicielle pour la construction de e syst`mes informatiques r´partis sous administration autonome, et son application e e a deux domaines particuliers : l’administration de serveurs d’applications J2EE et ` l’administration d’un bus d’information d’entreprise. Quant au projet SCOrWare, il a pour ambition de fournir une implantation en logiciel libre des r´centes sp´e e cifications Service Component Architecture (SCA) d´finies par l’Open SOA Cole laboration. L’objectif de TUNe dans ces projets est la proposition d’une nouvelle plateforme d’administration palliant aux limites de son pr´d´cesseur Jade [26]. Ce e e dernier a ´t´ d´velopp´ au sein de l’INRIA dans le projet SARDES 3 a Grenoble. ee e e ` Jade est l’un des premiers SAA offrant les fonctionnalit´s d’administration telles que e d´crites par [64] (d´ploiement, configuration et reconfiguration). Sa grande particue e larit´ est l’administration de logiciels patrimoniaux, c’est-`-dire ceux n’ayant pas e a ´t´ con¸us avec des facilit´s d’administration. En plus de fournir un support pour ee c e l’administration des logiciels dans un environnement r´parti, il prend ´galement en e e compte la supervision de l’environnement mat´riel administr´. Il permet entre autre e e de d´finir des enchaˆ e ınements d’actions ex´cutables (de fa¸on autonome) en r´ponse e c e a un ´v´nement particulier dans l’environnement administr´ (comme des pannes ou ` e e e des surcharges). Alors qu’il a permis de valider l’apport des SAA et l’approche de d´veloppement de SAA ` base de composants, Jade s’adresse 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/

Syst`me d’administration autonome adaptable : application au Cloud e

5.2. PRINCIPES

39

lisateurs avertis du domaine a composants. En effet, 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 d’implanter sous les bases de Jade, un SAA dont l’utilisation est moins contraignante. Ainsi, TUNe implante des langages d’administration de haut niveau, bas´s sur les profils UML [81], e donc plus accessibles aux utilisateurs non initi´s ` Fractal. Dans la section suivante, e a nous pr´sentons ces langages et leur utilisation dans TUNe. e

5.2

Principes

La conception et l’implantation du syst`me TUNe repose sur une approche bas´e e e composants. Approche tr`s prometteuse, cette derni`re est ´galement au cœur de la e e e conception d’autres SAA tels que Rainbow [55]. Le principe g´n´ral est d’encapsue e ler les ´l´ments administr´s dans des composants et d’administrer l’environnement ee e logiciel comme une architecture a composants. Ainsi, le SAA b´n´ficie des atouts ` e e du mod`le ` composants utilis´ tels que l’encapsulation, les outils de d´ploiement et e a e e les interfaces de reconfiguration pour l’implantation des proc´dures d’administration e autonome. Grˆce ` cette approche, le SAA offre une vision uniforme de l’environa a nement logiciel et mat´riel ` 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´ li´e 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 l’administration de syst`mes large e ´chelle tout en minimisant les difficult´s rencontr´es avec Jade. Bas´ sur les profils e e e e UML [81] (largement utilis´s) et un langage de navigation architectural, TUNe foure nit trois langages d’administration. Ces langages permettent a la fois la description ` des applications, de l’environnement mat´riel et des politiques de reconfiguration e dynamique. Les sections suivantes n’ont pas vocation a pr´senter en d´tails le sys` e e t`me TUNe et son implantation. Pour plus d’informations, le lecteur peu se reporter e vous ` la th`se [28]. a e

5.2.1

Architecture Description Language (ADL)

Le processus d’administration avec TUNe d´bute par la description de l’applicae tion ` administrer. Comme son ancˆtre Jade, TUNe prend en compte l’administraa e tion d’applications distribu´es s’ex´cutant dans un environnement r´parti. L’ADL e e e fournit dans TUNe permet de d´crire a la fois l’application et l’environnement mae ` t´riel dans lequel l’application s’ex´cute. Bas´ sur le diagramme de classe UML [81], e e e

Syst`me d’administration autonome adaptable : application au Cloud e

5.2. PRINCIPES

40

TUNe permet l’utilisation des outils de mod´lisation graphique de l’IDM 4 pour la e d´finition des ´l´ments administr´s. e ee e Concernant la description de l’application, chaque type de logiciel de l’application est repr´sent´ par une classe UML. L’assignation d’attributs a la classe permet e e ` d’indiquer les propri´t´s du type de logiciel qu’elle repr´sente. En plus des propri´t´s ee e ee propres au type de logiciel d´crit, TUNe impose des attributs particuliers pour son e utilisation interne (les attributs en rouge sur la figure 5.2). Dans la figure 5.2(a), nous d´crivons 4 types de logiciels constituant une application J2EE ` administrer. L’ate a tribut ”legacyFile” pr´sent dans toutes les classes indique a TUNe l’archive contenant e ` les binaires du logiciel concern´. Par contre, l’attribut ”port” du type Apache par e exemple repr´sente une propri´t´ 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 d’ˆtre utilis´es dans les autres langages de TUNe pour d´signer des logiciels d’un e e e bout de l’application a un autre (exemple de la liaison ”workers” entre Apache et ` Tomcat). Les sections suivantes pr´sentent en d´tail cette utilisation. De fa¸on g´e e c e n´rale, cette premi`re ´tape de description par ADL permet de poser les bases pour e e e les autres langages. De fa¸on analogue, TUNe permet l’utilisation des diagrammes de classes UML c pour la description de l’environnement mat´riel dans lequel s’ex´cute l’application e e administr´e. TUNe consid`re l’environnement mat´riel comme un ensemble constie e e tu´ de groupes de machines (clusters). Chaque cluster repr´sente un ensemble de e e machines homog`nes (OS, syst`mes de fichiers et toutes autres caract´ristiques idene e e tiques). Ainsi, dans la description de l’environnement mat´riel, chaque classe repr´e e sente un cluster. Contrairement aux logiciels, tous les attributs d’un cluster sont impos´s par TUNe. En guise d’exemple, l’attribut ”nodefile” de la classe Cluster (fie gure 5.2(b)) indique un nom de fichier contenant la liste des machines constituant le cluster. Quant ` l’attribut ”allocator-policy”, il d´finit la politique d’allocation de a e machines (aux logiciels) dans ce cluster. Les interconnexions d´crites ici entre les e clusters sont des relations d’h´ritage d’attributs. Contrairement a l’utilit´ qu’ont les e ` e liaisons entre les ´l´ments logiciels, les liaisons d’h´ritage servent uniquement ` facee e a toriser la description des attributs entre les clusters. Rappelons que tous les attributs d´finis par les clusters sont impos´s par TUNe. L’administrateur ne peut introduire e e de nouveaux attributs. Description intuitive La premi`re particularit´ de l’ADL propos´e par TUNe est la description des e e e types de logiciels. Contrairement aux SAA (comme [26], [68], [57], [43] par exemple) dans lesquels l’administrateur doit d´finir 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 l’administrateur (via l’attribut ”initial ”, e ` qui repr´sente le nombre d’instances au d´marrage, et des op´rations de reconfigue e e ration). Cette particularit´ permettra par exemple de d´crire l’instanciation de dix e e
4. Ingenierie Dirig´e par les Mod`les : exemple de Topcased [top] e e

Syst`me d’administration autonome adaptable : application au Cloud e

5.2. PRINCIPES

41

Figure 5.2 – Exemple d’ADL : cas d’une application J2EE Tomcat dans une application J2EE via la description d’un seul type de logiciel Tomcat et la position de son attribut ”initial ” ` dix. a Cependant, cette facilit´ influence la d´finition des interconnexions entre les types e e de logiciels. Il revient ` TUNe la charge de r´aliser les connexions entre les instances a e logicielles. En effet, TUNe les interpr`te comme un pattern r´gissant les liaisons e e entre les instances de logiciels. Il utilise la s´mantique UML d´finissant les assoe e ciations entre classes. Les liaisons entre types de logiciels sont ainsi accompagn´es e de cardinalit´s. Ces derniers permettent a TUNe de construire et de maintenir un e ` mod`le a composants conforme au pattern architectural d´crit par l’administrateur. e ` e Dans la section 5.3, nous revenons sur l’interpr´tation de cette description dans e TUNe. Pour finir, le rapport entre la description des types de logiciels et la description de l’environnement mat´riel est le d´ploiement. Cette relation est indiqu´e dans la e e e description des types de logiciels via l’attribut ”host-familly” (qui d´signe un cluster) e impos´ par TUNe pour chaque type de logiciel (trait en pointill´ sur la figure 5.2). e e Ainsi, toutes les instances appartenant au mˆme type logiciel sont d´ploy´es et ex´e e e e cut´es sur des machines appartenant au mˆme cluster. e e

5.2.2

Wrapping Description Language (WDL)

L’ADL fournit par TUNe ne permet qu’une description structurelle de l’environnement d’administration. En ce qui concerne la description des op´rations d’adminise 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 d´crire l’action de r´aliser cette op´ration. Pour chaque type de loe e e giciel d´crit dans l’ADL, l’administrateur d´finit (attribut wrapper de chaque type e e logiciel dans la figure 5.2(a)) dans un fichier XML l’ensemble des fonctions pouvant ˆtre ex´cut´es (exemple de la figure 5.3) par les instances logicielles de ce type. e e e Syst`me d’administration autonome adaptable : application au Cloud e

5.2. PRINCIPES

42

Figure 5.3 – Exemple de wrapping : cas du logiciel Apache Chaque fonction correspond ` une m´thode java (exemple de m´thode apacheMaa e e nager de la classe java J2EEWrapping sur la figure 5.3) et est sp´cifique au type e logiciel qui lui est associ´. e Le langage de wrapping de TUNe permet une description de m´thodes avec pase sage de param`tres. Compte tenu de la non connaissance des valeurs exactes des e propri´t´s des logiciels pendant la phase de wrapping, les param`tres d´finis 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 mˆme tout au long de l’ex´cution de e e l’application et du SAA. Ils ont une s´mantique comparable a celle des constantes e ` dans les langages de programmation comme java. C’est le cas du premier param`tre e de la fonction ”start” des instances logicielles de type Apache de la figure 5.3(a). Quant aux param`tres de type variable, TUNe offre un langage de d´signation de e e logiciels ainsi que de ses attributs. Il s’agit d’un langage de navigation architecturale. Autrement dit, il permet de parcourir, a l’aide d’une notation point´e, toute l’archi` e tecture suivant les liaisons entre les ´l´ments administr´s. Ainsi, la valeur r´elle du ee e e param`tre ne sera ´valu´e (par r´solution de nom) qu’` l’ex´cution de la m´thode. e e e e a e e Les deuxi`me et troisi`me param`tres de la figure 5.3 (5.3(b) et 5.3(c)) sont des e e e exemples. Le premier (5.3(b)) fait r´f´rence a l’attribut port de l’instance d’Apache ee ` courant tandis que le second (5.3(c)) fait r´f´rence aux num´ros de port des connecee e teurs AJP [24] des serveurs Tomcat li´s a l’instance Apache courant (via la connexion e ` nomm´e workers). e L’ex´cution des fonctions de wrapping d´pend de leur pr´sence ou non dans les e e e politiques de reconfiguration. Dans la section suivante, nous pr´sentons le langage e permettant de mettre en application les fonctions de wrapping : le langage de reconfiguration.

5.2.3

Reconfiguration Description Language (RDL)

L’exploitation des d´finitions faites par ADL et WDL est la d´finition de poe e litiques d’administration. TUNe fournit un langage proche des diagrammes d’´tate transition d’UML : baptis´ Reconfiguration Description Language (RDL) dans TUNe. e Le terme ”automate” est ´galement utilis´ pour d´signer ces diagrammes ou polie e e tiques d’administration. Les automates d´crits ` l’aide de ce langage s’ex´cutent a e a e ` Syst`me d’administration autonome adaptable : application au Cloud e

5.3. CHOIX D’IMPLANTATION

43

Figure 5.4 – Principes de TUNe chaque apparition d’un ´v´nement dans l’environnement administr´. Chaque ´tat e e e e de l’automate d´finit une action a ex´cuter. Deux types d’actions sont possibles : la e ` e modification de param`tres et l’appel de fonctions d´crites lors du wrapping. En plus e e des fonctions de wrapping, TUNe met ` la disposition de l’administrateur deux fonca tions particuli`res pour l’ajout et le retrait d’instances logicielles de l’architecture. e Apr`s l’ex´cution de ces fonctions, il assure la coh´rence entre : (1) les patterns are e e chitecturaux d´finis auparavant par ADL, (2) la repr´sentation interne qu’il dispose e e (de l’environnement) et (3) l’environnement d’ex´cution r´elle (sur les machines). e e En effet, l’ajout et le retrait d’instances modifient l’architecture courante de l’application. Comme son pr´d´cesseur Jade, la description des programmes (cas de Jade) ou e e automates (cas de TUNe) de (re)configuration d´pend des logiciels administr´s et e e des ´v´nements attendus par l’administrateur. Ainsi, le nombre de ces politiques e e d´pend des besoins de l’application administr´e. Par contre, deux automates partie e culiers sont requis par TUNe pour l’administration de toute application : l’automate de d´marrage et l’automate d’arrˆt des logiciels administr´s. La figure 5.4 montre un e e e exemple d’automate d´crivant ` la fois la configuration et le d´marrage des serveurs e a e de l’application J2EE. On constate par exemple que les serveurs J2EE peuvent ˆtre e configur´s parall`lement alors que le d´marrage par contre doit respecter un ordre e e e (MySQL, MySQL-Proxy, Tomcat et enfin Apache). De la mˆme fa¸on qu’avec le WDL, la navigation ` travers l’architecture (par e c a notation point´e) est utilisable dans la d´finition des actions. e e

5.3

Choix d’implantation

L’administration bas´e composants fournit une couche d’abstraction pour un ene semble d’´l´ments mat´riels ou logiciels. S’appuyant sur le mod`le ` composants ee e e a Fractal, TUNe construit une architecture ` composants interne repr´sentant l’ena e Syst`me d’administration autonome adaptable : application au Cloud e

5.3. CHOIX D’IMPLANTATION

44

vironnement administr´. Cette architecture est conforme a la description par ADL e ` faite de l’application par l’administrateur. Cette structure interne se nomme Syst`me e de Repr´sentation (SR) dans TUNe. Elle contient ` la fois les ´l´ments logiciels et e a ee 5 mat´riels. Chaque instance logicielle est encapsul´e dans un composant Fractal. Ce e e dernier impl´mente les fonctions de base de l’administration ` savoir : le d´ploiee a e ment, le wrapping et l’ex´cution a distance de fonctions. Les interconnexions entre e ` les instances sont repr´sent´es par des liaisons (binding) bidirectionnelles entre les e e composants Fractal correspondants. Cette bidirectionnalit´ facilite la navigation par e notation point´e (navigation dans deux sens entre deux instances li´es). Dans la fie e gure 5.5 les fl`ches bleues en pointill´ (de l’environnement d’´dition vers le syst`me e e e e de repr´sentation) repr´sentent la relation d’encapsulation entre les types de logiciels e e et les composants Fractal. Notons que conform´ment ` la valeur de l’attribut ”inie a tial ”, l’´l´ment Tomcat g´n`re deux composants Fractal (deux instances du logiciel ee e e Tomcat). Contrairement aux composants logiciels, les machines de chaque cluster ne sont pas repr´sent´es par un seul composant Fractal. TUNe repr´sente le cluster par un e e e composant Fractal. Ce composant impl´mente les fonctions d’allocation et de lib´e e ration de machines. Les liaisons d’h´ritage ne sont pas maintenues dans le SR. Le e d´ploiement d’un logiciel dans le cluster entraˆ une liaison Fractal entre le compoe ıne sant logiciel repr´sentant ce logiciel et le composant Fractal repr´sentant le cluster. e e Cette liaison (composant logiciel-composant cluster ; fl`ches rouges sur la figure 5.5) e permet de r´cup´rer les propri´t´s des machines h´bergeant un logiciel. e e ee e Afin d’accomplir les tˆches d’administration qui lui sont confi´es, TUNe ex´cute a e e sur les machines distantes deux types de serveurs. Le premier serveur (RemoteLauncher ) permet d’effectuer des actions g´n´rales non li´es ` un logiciel particulier e e e a de l’application administr´e. C’est notamment lui qui initialise la machine distante e avant le d´ploiement des logiciels. Il d´marre ´galement, ` la demande de TUNe, les e e e a serveurs de second type. C’est (RemoteLauncher ) le repr´sentant de TUNe sur la e machine distante. Contrairement au premier (qui est unique sur la machine), TUNe associe a chaque instance logicielle un repr´sentant (serveurs de second type) sur la ` e machine distante. Ce serveur de second type (RemoteWrapper ) est charg´ de l’ex´e e cution des op´rations d’administration li´es ` l’instance logicielle a laquelle il est e e a ` associ´. Il entre en action suite ` l’invocation d’une fonction de wrapping issue de e a l’ex´cution d’un automate de reconfiguration. C’est a lui que revient par exemple e ` la charge d’ex´cuter la fonction ”Apache.start” (de l’automate de d´marrage de la e e figure 5.4) sur une instance du serveur Apache. D’autre part, ce serveur joue le rˆle o de communicant d’´v´nements. C’est par son biais que les ´v´nements rep´r´s par e e e e ee des logiciels de monitoring sont communiqu´s a TUNe (mat´rialis´s par les fl`ches e ` e e e vertes de la figure 5.5). Depuis sa mise en œuvre, cette conception de TUNe a fait l’objet de plusieurs
5. Contrairement ` sa signification habituelle dans la litt´rature (implantation compl`te a e e du comportement d’un logiciel), l’expression ”encapsuler un logiciel” dans ce document signifie : implanter les contrˆleurs permettant de manipuler un logiciel existant (consid´r´ o ee comme une boˆ noire). Afin d’´viter l’ambigu¨ e avec le terme ”contrˆleur” d´j` pr´sent ıte e ıt´ o ea e dans les mod`les ` composants, nous utilisons le terme ”encapsuler”. e a

Syst`me d’administration autonome adaptable : application au Cloud e

5.3. CHOIX D’IMPLANTATION

45

Figure 5.5 – Vue globale de TUNe

Syst`me d’administration autonome adaptable : application au Cloud e

´ ´ 5.4. EXPERIMENTATIONS ET PROBLEMATIQUES

46

exp´rimentations dans divers domaines applicatifs. Comme nous le pr´sentons dans e e la section suivante, certaines de ces exp´rimentations ont r´v´l´ les limites de cette e e ee conception de TUNe.

5.4

Exp´rimentations et Probl´matiques e e

Les exp´rimentations r´alis´es avec le syst`me TUNe (par nos partenaires et e e e e nous) durant ces derni`res ann´es couvrent plusieurs domaines applicatifs. Sans ˆtre e e e exhaustif dans la liste de ces exp´riences, nous d´crivons dans cette section quelques e e unes d’entre elles qui ont motiv´ la nouvelle orientation du projet TUNe. Il s’agit de e l’utilisation de TUNe pour l’administration des applications clusters de type maˆ ıtreesclave(exemple de J2EE), des applications large ´chelle et des applications virtualie s´es. Ces pr´sentations mettent en exergue d’une part l’efficacit´ du syst`me TUNe e e e e et d’autre part ses limites. En plus de ces exp´rimentations, nous achevons cette e section par la pr´sentation des limites li´es a la tentative d’utilisation de TUNe e e ` pour l’administration du cloud dans son ensemble. La complexit´ de ce dernier nous e permet de compl´ter l’analyse faite des limitations de TUNe. e

5.4.1

Applications cluster

Le syst`me TUNe a ´t´ con¸u pour l’administration des applications r´parties. e ee c e Pour des besoins de d´veloppement, il utilise des applications de type J2EE (fie gure 5.1) comme support de test. De ce fait, ses langages d’administration r´pondent e parfaitement avec les besoins d’administration attendus par ce type d’applications. Parcourons a pr´sent ces besoins afin de montrer l’efficacit´ de TUNe. ` e e Concernant l’installation des serveurs J2EE sur les machines distantes, TUNe propose une m´thode de d´ploiement consistant ` copier des binaires de la machine e e a d’administration vers les machines distantes. Ces binaires doivent ˆtre soumis a e ` TUNe sous forme d’archives. L’attribut ”legacyFile”, impos´ par TUNe pour chaque e type de logiciel, permet a l’administrateur d’indiquer l’archive d’installation du lo` giciel. Les binaires sont par la suite d´sarchiv´s par TUNe (par l’interm´diaire de e e e son ”RemoteLauncher ”) sur les machines distantes. Cette m´thode de d´ploiement e e r´pond parfaitement a l’installation des serveurs J2EE qui sont livr´s par leur d´vee ` e e loppeur sous forme d’archives. Apr`s l’installation, les op´rations de configuration et de d´marrage des serveurs e e e J2EE sont ´galement exprimables grˆce au WDL et RDL de TUNe. En effet, la confie a guration de ces serveurs consiste essentiellement en la modification des fichiers de type cl´-valeur. La d´finition d’une fonction permettant de r´aliser ces modifications e e e est facilement r´alisable par WDL. Comme nous l’avons indiqu´ dans la section 5.2.2, e e le WDL permet de d´finir des fonctions d’administration via des m´thodes de classes e e java. Ces derni`res peuvent donc implant´es la modification des fichiers. Quant au e e d´marrage des serveurs, il s’effectue par ex´cution de commandes shell. De la mˆme e e e Syst`me d’administration autonome adaptable : application au Cloud e

´ ´ 5.4. EXPERIMENTATIONS ET PROBLEMATIQUES

47

fa¸on qu’il proc`de pour la configuration, l’administrateur n’aura qu’` implanter les c e a op´rations de d´marrage via des m´thodes de classes java. La seule d´finition des e e e e fonctions de d´marrage n’est pas suffisante. En effet, contrairement aux op´rations e e de configuration qui peuvent s’ex´cuter en parall`le (sur les serveurs), le d´marrage e e e des serveurs J2EE requiert un ordre. En guise d’exemple, le serveur d’application Tomcat doit ˆtre d´marr´ avant le serveur web Apache qui lui est connect´. Le RDL e e e e de TUNe, bas´ sur les diagrammes d’´tat-transition d’UML, permet d’exprimer ces e e contraintes. Ses ´tats particuliers, que sont le ”fork ” et le ”join”, permettent respece tivement de parall´liser des op´rations et d’attendre l’ex´cution d’un flux parall`le e e e e d’op´rations. Une fois le d´marrage effectu´, l’un des besoins les plus importants e e e dans l’administration d’une application de ce type est la gestion des variations de charge au niveau des diff´rents tiers. e L’administrateur souhaite ajouter des serveurs a un tiers afin d’absorber la sur` charge lorsque celui-ci est surcharg´. Inversement, il souhaite ´galement r´duire le e e e nombre de serveurs d’un tiers lorsqu’il est sous utilis´. Cette derni`re op´ration lui e e e permet de r´aliser des ´conomies d’utilisation de machines (tr`s b´n´fique lorsque e e e e e celles-ci sont payantes). L’ensemble de ces deux op´rations est appel´ sizing ou pase e sage ` l’´chelle ou scalabilit´ de serveurs. Pour r´aliser cela dans TUNe, l’administraa e e e teur associe aux serveurs J2EE des logiciels particuliers jouant le rˆle de sondes. Ces o derni`res d´clencheront (en cas de sous/sur charge d’un tiers) dans TUNe des autoe e mates de reconfiguration permettant d’ajouter ou retirer des serveurs. Les deux op´e rateurs d’ajout (suivis d’un d´ploiement) et de retrait (suivis d’un un-d´ploiement) e e d’instances logicielles propos´es par TUNe permettent de r´aliser ce besoin. e e La g´n´ralisation de ces besoins permettent ` TUNe d’adresser d’autres applie e a cations cluster de type maˆ ıtre-esclave comme Ganglia [73]. Cependant, lorsque la taille de l’application devient importante, nous observons des limites d’utilisation de TUNe. C’est le cas avec les applications large ´chelle comme le serveur de calculs e DIET [33] dans l’environnement de grille grid5000 [25].

5.4.2

Applications large ´chelle : cas de DIET e

L’application DIET [33] permet de d´ployer des serveurs (nomm´s agents dans e e DIET) de calculs dans un environnement de grille. Ces serveurs sont organis´s sous e forme arborescente et sont de trois types. Les serveurs de premier type se trouvent a la racine de l’arbre : ils sont nomm´s Master Agent (MA). Ces derniers re¸oivent ` e c les demandes de calculs venant des clients et les orientent vers les serveurs de calculs (serveur de troisi`me type) les mieux adapt´s. Ces derniers sont d´termin´s par e e e e les serveurs MA en fonction des informations de monitoring qu’ils obtiennent des serveurs de second type : nomm´s Local Agent (LA). Enfin, les serveurs de troisi`me e e type sont situ´s aux feuilles de l’arbre. Ils sont les v´ritables serveurs de calculs : e e nomm´s Server Daemon (SeD). Ils re¸oivent des requˆtes des clients et restituent e c e les r´sultats une fois le calcul effectu´. Notons qu’un MA pourrait directement ˆtre e e e reli´ aux SeD si ceux-ci ne sont pas de grand nombre. L’introduction des LA permet e d’´viter la saturation des MA lorsque l’application DIET utilise un grand nombre de e

Syst`me d’administration autonome adaptable : application au Cloud e

´ ´ 5.4. EXPERIMENTATIONS ET PROBLEMATIQUES

48

serveurs de calculs. Plusieurs niveaux de LA sont introduits entre le MA et les SeD en fonction de la taille de l’application. La figure 5.6 r´sume l’architecture de cette e application. Elle peut ˆtre constitu´e de milliers de serveurs lorsque l’environnement e e mat´riel le permet (cas de grid5000). L’utilisation de TUNe pour l’administration e (d´ploiement, configuration et d´marrage) 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 l’application DIET. Cette e description devient fastidieuse (r´p´tition dans la description) lorsque l’application 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 d’un d´ploiement multiple d’instances de mˆme type via l’attribut ”initial ”. En effet, e e l’attribut ”initial ” (section 5.2.1) qui indique a TUNe le nombre d’instances ` d´` a e ployer initialement pour un type de logiciel a ´t´ introduit pour prendre en compte ee le d´ploiement des serveurs DIET sur grid5000. Comme nous l’avons d´crit dans la e e section 5.2.1, cet attribut simplifie la description de l’architecture d’une application contenant plusieurs instances du mˆme logiciel. Notons que cette modification du e langage ADL de TUNe n’a n´cessit´ aucune modification du cœur de TUNe. e e Probl`me 1.2 e La deuxi`me limite concerne le d´ploiement des serveurs de calculs SeD. La pere e formance de ces derniers ´tant li´e aux caract´ristiques mat´rielles des machines sur e e e e lesquelles ils s’ex´cutent, l’administrateur dispose de diff´rentes versions d’installae e tion pour chaque cluster de la grille. Or le processus de d´ploiement fourni par TUNe e ne pr´voit qu’une seule archive (qui correspond ` une version) pour chaque type de e a logiciel. De plus, le choix de la version n’´tant possible que pendant le d´ploiement e e (c-`-d une fois le cluster connu), l’administrateur souhaite associer ` chaque cluster a a une version pr´cise de SeD. e Probl`me 1.3 e La derni`re difficult´ (que nous d´crivons dans ce document) concernant l’ade e e ministration de cette application est li´e au caract`re centralis´ de TUNe. En effet, e e e l’administration d’une application constitu´e de milliers de logiciels par une unique e instance de TUNe devient impossible a cause des limites de la machine qui l’h´berge. ` e Par exemple, l’ouverture d’une connexion r´seau entre la machine d’administration e et tous les serveurs administr´s est limit´e par les capacit´s m´moire de la machine e e e e d’administration.

5.4.3

Applications virtualis´es e

Notre derni`re tentative d’administration avec TUNe concerne l’utilisation des e machines virtuelles (section 2.2) pour une gestion optimale des ressources dans un cluster J2EE [90]. En bref, il s’agit d’utiliser une instance de TUNe pour l’admi-

Syst`me d’administration autonome adaptable : application au Cloud e

´ ´ 5.4. EXPERIMENTATIONS ET PROBLEMATIQUES

49

Figure 5.6 – Architecture de DIET nistration a la fois des serveurs J2EE et des VM sur lesquelles ils s’ex´cuteront. ` e Ainsi, grˆce aux atouts des VM, nous implantons plusieurs politiques de gestions a de ressources. Malgr´ l’obtention de r´sultats prometteurs concernant la gestion de e e ressources, le syst`me TUNe s’est montr´ inadapt´ pour l’administration des VM. e e e Probl`me 2.1 e Premi`rement, l’expression de la double identit´ des VM (` la fois machine et e e a logiciel, section 2.2) est irr´alisable dans TUNe. En effet, les langages et le cœur de e TUNe diff´rencient les machines et les logiciels. Il impose d’une part une descripe tion sous forme de cluster pour les machines et les repr´sente en son sein a l’aide e ` d’un seul composant. Ceci empˆche la manipulation individuelle des VM qui est un e besoin important dans cette exp´rimentation. D’autre part, les logiciels sont d´crits e e et repr´sent´s de fa¸on individuelle dans le SR. Qu’elle repr´sentation utilisera donc e e c e l’administrateur pour d´crire les VM qui jouent les deux rˆles ? e o Probl`me 2.2 e Apr`s les probl`mes de description par ADL et de repr´sentation, l’installation e e e d’une VM ne se limite pas (comme dans TUNe) ` la copie de binaires sur la machine a distante. En effet, installer une VM revient ` installer un syst`me d’exploitation. a e Ce qui implique une succession d’op´rations de natures diff´rentes parmi lesquelles : e e l’initialisation du syst`me de fichiers, l’installation des pacquages, etc. Prendre en e compte cette particularit´ d’installation revient ` personnaliser la m´thode de d´e a e e ploiement propos´e par TUNe. e Probl`me 2.3 e Pour finir, la prise en compte de l’op´ration de migration de VM (voir la sece tion 2.2), essentielle dans notre exp´rimentation [90] est impossible dans TUNe. Il e

Syst`me d’administration autonome adaptable : application au Cloud e

´ ´ 5.4. EXPERIMENTATIONS ET PROBLEMATIQUES

50

s’agit du d´placement de l’ex´cution d’une VM d’une machine physique vers une e e autre. Elle n´cessite entre autre l’ex´cution atomique du couple d’op´rations [und´e e e e ploiement de la VM ; d´ploiement de la VM sur la machine de destination]. Autree ment dit, elle n´cessite une op´ration du genre ”move”. Ce que ne permettent ni les e e langages, ni l’implantation de TUNe.

5.4.4

Cloud

Les exp´rimentations r´alis´es avec TUNe dans les domaines pr´c´dents nous ont e e e e e conduit vers un domaine beaucoup plus complet et complexe qu’est le cloud. Comme nous l’avons pr´sent´ dans la section 3, le cloud dans son ensemble (IaaS et applie e cations entreprise) repr´sente un cas d’administration dans lequel l’utilisation d’un e SAA apparaˆ ´vidente. Ainsi, nous pr´sentons dans cette section une tentative d’utiıt e e lisation du syst`me TUNe pour l’administration du cloud dans son ensemble. Sans e reprendre la pr´sentation de l’administration dans le cloud r´alis´e dans la section 3, e e e nous nous appuyons sur cette derni`re pour effectuer notre ´tude. Plus pr´cis´ment, e e e e cette ´tude pr´sente les limitations du syst`me TUNe pour l’administration dans le e e e cloud.

Probl`me 3.1 e Administrer le cloud dans son ensemble avec TUNe revient ` ex´cuter plusieurs a e instances de TUNe par niveau d’utilisation : une instance pour l’administration de l’IaaS et plusieurs instances (` raison d’une instance par entreprise) pour l’admia nistration des applications entreprise. Reposant sur la collaboration entre les deux niveaux, l’administration du cloud implique ´galement la collaboration/interop´e e rabilit´ entre les instances de TUNe de niveau entreprise et l’instance de TUNe de e niveau IaaS. Probl`me 3.2 e Comme les environnements de grille, l’IaaS peut ˆtre constitu´ d’un grand nombre e e de ressources. Ces derni`res peuvent ˆtre r´parties dans plusieurs localit´s (cas e e e e d’Amazon EC2 avec X localit´s). Dans ce contexte, l’utilisation de TUNe est proe bl´matique et rejoint la situation d´crite dans le Probl`me 1.3 de la section 5.4.2. e e e Probl`me 3.3 e L’instance TUNe de niveau IaaS administre des ´l´ments de diverses natures : ee des serveurs assurant les services de base de l’IaaS (facturation, stockage de donn´es, r´seaux, etc.), des VM qui servent de support d’ex´cution pour les applications e e e entreprise, et des ´quipements mat´riels. Dans le processus d’administration, le d´e e e ploiement des serveurs et celui des VM n’est pas r´alisable de la mˆme mani`re. On e e e retrouve le mˆme probl`me que nous avons ´voqu´ dans la section 5.4.2 (Probl`me e e e e e 1.2).

Syst`me d’administration autonome adaptable : application au Cloud e

´ ´ 5.4. EXPERIMENTATIONS ET PROBLEMATIQUES

51

Probl`me 3.4 e Comme toute plateforme informatique, les op´rations de maintenance font partie e du cycle de vie du cloud. Ces op´rations peuvent entraˆ e ıner la mise en indisponibilit´ e partielle ou totale d’un ensemble de machines. La prise en compte de cette activit´ e par TUNe se traduit par le retrait des machines concern´es du SR. Cependant, e cette op´ration n’est pas possible dans TUNe. Si le retrait concerne un cluster tout e entier, uniquement la modification des langages de TUNe permettra de prendre en compte cette op´ration. Dans le cas o` le retrait concerne des ressources individuelles, e u la modification des langages et du coeur de TUNe sont n´cessaires. Ceci s’explique e par le fait que le syst`me TUNe ne repr´sente pas de fa¸on individuelle les ressources e e c mat´rielles dans le SR. Il est donc impossible de les manipuler individuellement. De e fa¸on analogue, l’extension du cloud par ajout de nouvelles machines ne peut c ˆtre pris en compte par TUNe. Ces deux situations s’observent ´galement au niveau e e entreprise. Pour illustrer cela, prenons l’ex´cution dans le cloud d’une application de e type maˆ ıtre-esclave par une entreprise. La scalabilit´ telle que nous l’avons pr´sent´e e e e dans la section 5.4.1) entraˆ ınera des ajout/retrait de VM (vues comme des ressources mat´rielles par les entreprises). e Probl`me 3.5 e Comme nous l’avons pr´sent´ dans la section 3, la plupart des op´rations d’ade e e ministration dans le cloud sont d´clench´es par celles du niveau entreprise. C’est e e ainsi que l’ajout/retrait de VM au niveau de l’IaaS survient apr`s l’extension/r´duce e tion des ressources au niveau entreprise (les op´rations d´crites dans le paragraphe e e pr´c´dent). Cette op´ration n’est pas possible dans le syst`me TUNe. En effet, il e e e e le permet uniquement pour des logiciels dont la description est connue avant son (TUNe) d´marrage. De plus, les entreprises ou le fournisseur de l’IaaS peuvent soue haiter int´grer de nouveaux types de logiciels dans l’environnement apr`s le d´mare e e rage de TUNe (ce qu’il ne permet pas). En guise d’exemple, prenons une entreprise ex´cutant dans le cloud une application J2EE constitu´e des serveurs Apache, Tome e cat, MySQL-Proxy et MySQL. Initialement, l’application est constitu´e d’une seule e instance d’Apache et aucun distributeur de charges devant Apache n’existe. Apr`s e saturation du serveur Apache, l’entreprise peut souhaiter de joindre un distributeur de charges (HA-Proxy) tout en gardant l’ex´cution de l’ensemble de l’application et e du SAA. Probl`me 3.6 e Le changement ou la d´finition d’une strat´gie commerciale (d´finition d’un noue e e veau type de contrat, d’une nouvelle m´thode de tol´rance aux pannes des VM, etc.) e e par le fournisseur du cloud se traduit par l’ajout ou le retrait de politiques de reconfiguration dans l’instance TUNe de niveau IaaS. Cette situation est similaire aux deux pr´c´dentes. Elle peut ´galement concerner le niveau entreprise. De e e e la mˆme fa¸on que l’administrateur de l’IaaS ajoute/retire des logiciels/mat´riels, il e c e peut effectuer la mˆme op´ration pour les politiques de reconfiguration. e e Probl`me 3.7 e Dans la section 5.4.3, nous avons pr´sent´ une politique de gestion de ressources e e

Syst`me d’administration autonome adaptable : application au Cloud e

` 5.5. SYNTHESE ET NOUVELLE ORIENTATION

52

bas´e sur la migration des VM. Reposant ´galement sur la virtualisation, le cloud e e peut mettre en place ces politiques au niveau de l’instance TUNe de l’IaaS. Comme nous l’avons fait remarqu´, cette op´ration n’est pas r´alisable dans TUNe : ni au e e e niveau langage, ni au niveau interne.

5.5

Synth`se et nouvelle orientation e

Les exp´rimentations r´alis´es avec TUNe font ressortir deux types de limites : e e e – Les limites dues uniquement ` l’insuffisance de ses langages d’administration ; a – Les limites dues a l’inadaptation de son architecture et de sa conception. ` L’analyse [40] de leurs causes souligne la variation des besoins d’administration en fonction des domaines d’applications. Nous montrons a travers ces exp´riences que ` e l’implantation actuelle de TUNe ne le pr´dispose pas ` s’adapter ` ces variations. e a a Ces derni`res n´cessitent un syst`me tr`s flexible et tr`s g´n´rique (voir le chapitre e e e e e e e suivant). Or la conception et l’implantation de TUNe sont r´alis´es autour de ses e e langages d’administration (on parle ´galement de machine langages pour d´signer ce e e type de syst`me). En outre, la conception de ces langages a ´t´ dirig´e par l’admie ee e nistration des applications cluster de type maˆ ıtre-esclave. Ainsi, cette d´pendance e entre le cœur de TUNe et ses langages le rend moins flexible et moins adaptable pour adresser d’autres domaines applicatifs. Face a ce constat, nous proposons la construction d’un SAA ne reposant sur au` cun langage ou domaine d’administration. L’objectif de ce SAA sera la fourniture d’un ensemble d’API permettant de le rendre le plus flexible et g´n´rique possible. e e Il sera sans doute complexe et donc difficile a utiliser. Pour surpasser cette difficult´ ` e d’utilisation, nous fournissons au dessus de ce SAA une pile de logiciels (couche (2) sur la figure 5.7) facilitant son utilisation. Cette pile contient des logiciels permettant aux administrateurs de d´finir d’eux mˆme les langages d’administration correspone e dant a leurs besoins applicatifs. Il s’agit d’outils d’IDM (Ingenierie Dirig´e par les ` e Mod`les) pour la r´alisation de langages sp´cifiques (Domain Specific Language ou e e e DSL dans le jargon IDM) a l’administration autonome (ce qui r´sout les probl`mes ` e e d’inadaptation 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 flexible et g´n´rique pouvant supporter plusieurs domaines e e d’applications (couche (1) sur la figure 5.7). Quant a la couche sup´rieure (couche ` e (2) sur la figure 5.7), elle fait l’objet d’autres travaux de th`se. La d´monstration de e e l’efficacit´ du SAA que nous proposons sera son application ` l’administration d’un e a environnement complexe comme le cloud. Avant la pr´sentation de ce SAA, nous e d´crivons dans le chapitre suivant les crit`res et l’approche qu’un tel syst`me doit e e e respecter.

Syst`me d’administration autonome adaptable : application au Cloud e

` 5.5. SYNTHESE ET NOUVELLE ORIENTATION

53

Figure 5.7 – Nouvelle orientation du projet TUNe

Syst`me d’administration autonome adaptable : application au Cloud e

Chapitre 6 Orientation g´n´rale e e
Contents
6.1 Caract´ristiques . . . . . . . . . . . . . . . . . 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 Interop´rable et Collaboratif . . . . . . . . . e 6.1.4 Synth`se . . . . . . . . . . . . . . . . . . . . . e 6.2 Approche g´n´rale et Mod`le Architectural e e e 6.2.1 Approche G´n´rale . . . . . . . . . . . . . . . e e 6.2.2 Mod`le Architectural . . . . . . . . . . . . . . e 6.2.3 Prise en compte des caract´ristiques . . . . . e 6.3 Synth`se . . . . . . . . . . . . . . . . . . . . . . e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 . 56 . 57 . 57 . 58 . 59 . 60 . 60 . 60 . 61 . 64 . 64

Les exp´riences r´alis´es avec le syst`me TUNe ont permis de valider d’une part e e e e les principes de l’administration autonome et d’autre part l’approche d’administration ` base de composants. En particulier, ces exp´riences ont montr´ son ad´quation a e e e pour l’administration des applications cluster de type maˆ ıtre-esclave (application J2EE par exemple). Cependant, contrairement ` son aspiration initiale (administraa tion g´n´rique), il est difficile de l’utiliser dans plusieurs domaines applicatifs (voir la e e fin du chapitre pr´c´dent pour les raisons). Ainsi, la principale recommandation que e e nous avons tir´ de ces exp´rimentations est : ”La conception d’un SAA ` voe e a cation g´n´rique et flexible doit suivre une architecture ` deux niveaux e e a (figure 5.7 du chapitre pr´c´dent). Le premier niveau (1) est un supe e port pour l’administration ` l’ex´cution (c’est la machine d’ex´cution a e e ou encore le SAA g´n´rique). Le second niveau (2) fournit un support e e langage pour l’expression des politiques d’administration.”. La conception et le d´veloppement du premier niveau fait l’objet de cette th`se. Il s’agit en quelque e e sorte du d´veloppement d’un exo-SAA que nous baptisons ”TUNeEngine”. e L’objectif de ce chapitre est double. Dans un premier temps, nous identifions les

´ 6.1. CARACTERISTIQUES

55

caract´ristiques id´ales qu’un tel SAA doit remplir afin d’ˆtre en mesure de r´pondre e e e e a divers besoins d’administration. Dans la pr´sentation de ces caract´ristiques, nous ` e e montrons a chaque fois dans quelles mesures elles r´pondent aux probl`mes identi` e e fi´s dans le syst`me TUNe. Dans un second temps, nous proposons une approche de e e conception ainsi qu’un mod`le architectural de ce SAA. e

6.1

Caract´ristiques e

Fort de nos diff´rentes exp´rimentations dans le domaine de l’administration e e autonome, nous proposons les caract´ristiques (consid´r´es comme crit`res ou direce ee e tives) suivantes pour la construction d’un SAA hautement g´n´rique : e e – Uniforme : Nous d´finissons un SAA uniforme comme un SAA dans lequel les e diff´rences de rˆles entre ´l´ments administr´s ne sont pas cˆbl´es. Autrement e o ee e a e dit, il s’agit d’un SAA dans lequel les ´l´ments administr´s utilisent la mˆme ee e e repr´sentation interne quelque soit leur nature. Ce crit`re se traduit dans le e e syst`me TUNe par la non diff´renciation entre la description et la repr´sentae e e tion (dans le SR) des machines et des logiciels (probl`me 2.1 de la section 5.4.3 e du chapitre pr´c´dent). e e – Adaptable : Nous d´finissons un SAA adaptable comme un SAA capable e d’´voluer en fonction des besoins d’administration. L’adaptabilit´ du SAA ree e vˆt diff´rents aspects. (1) L’adaptation de l’implantation du SAA : c’est la moe e dification des portements de base du SAA par modification/remplacement/ajout de services sans connaissance enti`re de son implantation. (2) La capacit´ e e du SAA ` faire ´voluer dynamiquement les ´l´ments qu’il administre. En effet, a e ee un SAA peut se borner ` administrer un ensemble d’´l´ments fixes ou faire a ee ´voluer ces ´l´ments par ajout de logiciels, de machines voir de programmes e ee de reconfiguration. De nos caract´ristiques, l’adaptabilit´ est la plus importante du SAA que nous e e envisageons. Cette caract´ristique permettra par exemple d’adapter le d´ploiee e ment du syst`me TUNe pour l’administration des syst`mes virtualis´s (proe e e bl`me 2.2 de la section 5.4.3 du chapitre pr´c´dent). e e e – Interop´rable ou Collaboratif : Comme nous l’avons montr´e dans le cadre e e des applications large ´chelle (probl`me 1.2 de la section 5.4.2 du chapitre e e pr´c´dent) par exemple, l’administration d’une infrastructure peut n´cessiter e e e le concours de plusieurs SAA. Ce dernier est dit interop´rable/collaboratif e lorsqu’il est capable d’´changer des informations ou des ordres d’administration e avec d’autres SAA distincts. Apr`s ces br`ves d´finitions des caract´ristiques du SAA que nous envisageons, e e e e le reste de ce chapitre est consacr´ dans sa deuxi`me partie ` leur pr´sentation e e a e d´taill´e. Pour illustrer ces pr´sentations, nous nous appuyons sur les exp´riences e e e e r´alis´es avec le syst`me TUNe (chapitre pr´c´dent) et plus particuli`rement sur le e e e e e e cas de l’administration dans le domaine du cloud.

Syst`me d’administration autonome adaptable : application au Cloud e

´ 6.1. CARACTERISTIQUES

56

6.1.1

Uniforme

L’ex´cution d’un logiciel est une relation entre deux entit´s : le support d’ex´cue e e tion (SE) et le logiciel. Le support d’ex´cution (SE) h´berge et ex´cute le logiciel. e e e Il impl´mente tous les m´canismes n´cessaires pour l’ex´cution du logiciel. Il est e e e e comparable a une machine munie de son syst`me d’exploitation. D’ailleurs, dans un ` e environnement d’administration, les ´l´ments mat´riels jouent toujours le rˆle de SE. ee e o Par contre, les logiciels peuvent ´galement se comporter comme des SE. Consid´rons e e l’exemple des machines virtuelles que nous avons pr´sent´es dans la section 2.2. Dans e e la relation [machines physique ; VM], la VM est consid´r´e comme logiciel a l’´gard ee ` e de la machine physique qui l’h´berge. Par contre, dans la relation [VM ; logiciel], la e VM joue le rˆle de SE vis a vis du logiciel qu’elle h´berge. o ` e Un autre exemple qui illustre ce double rˆle que peut jouer un logiciel concerne o les serveurs d’applications (dans les applications J2EE) comme JBoss [jbo] ou Tomcat [53]. Pour les mˆmes raisons que les VM, ces serveurs sont par d´finition des e e logiciels. Cependant, leurs fonctionnalit´s dans une application J2EE est l’ex´cution e e des servlets : ils sont notamment appel´s conteneurs de servlets. Ils implantent tous e les m´canismes permettant l’ex´cution et l’acc`s aux servlets. Ces m´canismes sont e e e e comparables ` ceux que l’on retrouve dans les syst`mes d’exploitation ` savoir : la a e a gestion des acc`s (s´curit´), la gestion de la m´moire, le scheduling, la gestion des e e e e entr´es/sorties, etc. Pour ces raisons, ils peuvent ˆtre consid´r´s comme SE vis ` vis e e ee a des servlets. Pour finir, nous retrouvons le probl`me d’uniformit´ dans certains SAA comme e e Accord [70] (conf`re chapitre 7 sur l’´tat de l’art). En effet, Accord fige (par ime e plantation) la diff´rence entre les logiciels jouant le rˆle de sondes et les logiciels e o fournissant les services fonctionnels de l’application administr´e. En cons´quence, il e e est difficile d’int´grer dans Accord des sondes comme boites noires et de les d´finir e e comme ´l´ments administrables. ee En sommes, il r´sulte des deux premiers exemples que dans l’administration d’une e application, les ´l´ments administr´s peuvent ˆtre soit des SE, soit des logiciels, soit ee e e les deux a la fois. Il s’agit de la situation que nous avons identifi´e par le probl`mes ` e e 2.1 de la section 5.4.3 du chapitre pr´c´dent. Quant au troisi`me exemple, il pose e e e le probl`me de la diff´renciation des rˆles des ´l´ments administr´s dans le SAA. e e o ee e De fa¸on g´n´rale, la recommandation que nous proposons est la suivante : le SAA c e e ne doit pas figer dans sa conception les diff´rences de rˆles des ´l´ments e o ee qu’il administre. Cette recommandation se traduit dans le SAA par l’utilisation d’une repr´sentation uniforme pour tous les ´l´ments administr´s qu’il g`re. Ainsi, e ee e e les logiciels, sondes, SE, etc. doivent utiliser la mˆme repr´sentation dans le SAA. e e

Syst`me d’administration autonome adaptable : application au Cloud e

´ 6.1. CARACTERISTIQUES

57

6.1.2
6.1.2.1

Adaptable
Adaptation des comportements

Comme tout logiciel informatique, le projet de d´veloppement d’un SAA met en e relation deux acteurs : (1) les utilisateurs (qui sont les administrateurs dans notre contexte) et (2) l’´quipe de d´veloppement. Dans la plupart des cas, ces deux ace e teurs sont s´par´s et ne poss`dent pas les mˆmes comp´tences. Le premier poss`de e e e e e e des comp´tences sur l’application a administrer tandis que le second maˆ e ` ıtrise les techniques de d´veloppement des SAA. Sur cette base, nous d´finissons l’adaptae e bilit´ des comportements d’un SAA comme sa capacit´ a ˆtre modifiable par les e e ` e utilisateurs de type (1) sans l’intervention des utilisateurs de type (2), dans le but d’adresser plusieurs domaines applicatifs. Autrement dit, l’adaptabilit´ des compore tement du SAA permettra au SAA d’ˆtre g´n´rique. L’adaptabilit´ est une solution e e e e parmi plusieurs qui permettent de construire un SAA g´n´rique. La question qui e e peut ˆtre pos´e est celle de savoir ”pourquoi notre choix s’est-il port´ sur l’adaptae e e bilit´ du SAA comme r´ponse a la g´n´ricit´”? e e ` e e e Une solution de g´n´ricit´ consiste ` fournir des API de bas niveaux utilisables e e e a par les administrateurs pour l’implantation 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 s’adresse aux administrateurs avertis, ce qui limite son utilisation ´lare gie. La r´ponse aux limites de la solution pr´c´dente est la fourniture des outils de e e e niveaux d’abstraction proches des administrateurs. Cette solution limite la g´n´rie e cit´ du SAA et entraˆ la construction de SAA par domaine applicatif sp´cifique. e ıne e C’est le cas du syst`me TUNe qui se limite aux applications clusters de type maˆ e ıtreesclave. La derni`re solution allie la fourniture d’un niveau d’abstraction ´lev´ a la g´e e e` e n´ricit´ du SAA. Elle repose d’une part sur l’adaptabilit´ du SAA (la modification, e e e l’ajout et le remplacement des services du SAA sans avoir une expertise compl`te sur e son d´veloppement) et la fourniture des outils d’expressions de besoins d’administrae 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 justifions son utilit´ dans le SAA en e montrant comment elle permettrait au syst`me TUNe de r´soudre une partie de ses e e probl`mes. e Durant nos exp´rimentations avec le syst`me TUNe (sections 5.4), nous nous e e sommes heurt´s a plusieurs probl`mes n´cessitant son adaptation. Il s’agit des proe ` e e bl`mes : 1.2, 2.2, 2.3, 3.3, 3.4, 3.5, 3.6 et 3.7. A pr´sent, montrons dans quelles e e mesures l’adaptabilit´ de TUNe lui aurait permis de r´soudre ces probl`mes. Ces e e e derniers requi`rent deux types d’adaptation : modification/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 d´ploiement des serveurs SeD dans le cadre de l’application DIET e Syst`me d’administration autonome adaptable : application au Cloud e

´ 6.1. CARACTERISTIQUES

58

(probl`me 1.2) ou le d´ploiement des VM dans les syst`mes virtualis´s et cloud (proe e e e bl`mes 2.2 et 3.3), le remplacement de la fonction de d´ploiement de base de TUNe e e permet de prendre en compte les particularit´s de ces applications. Par exemple, e le SAA peut ˆtre fourni avec une fonction basique de d´ploiement et permettre a e e ` chaque administrateur de fournir la m´thode (par surcharge ou red´finition de m´e e e thodes) qui lui est propre en cas de besoin. Ainsi, concernant l’administration des VM, l’administrateur pourra fournir au SAA une m´thode de d´ploiement incluant e e les t´l´chargements de binaires via internet, des copies via des serveurs NFS, etc. ee Une autre situation n´cessitant une adaptation par modification comportemene tale s’observe dans TUNe. Elle concerne le moyen d’ex´cution de fonction d’admie nistration a distance. Par exemple, le syst`me TUNe utilise un protocole fig´ (RMI) ` e e ainsi que des moyens d’introspection et r´flexion Java pour l’ex´cution de m´thodes e e e a distance. Ainsi, l’utilisation de TUNe n´cessite la pr´sence d’une machine virtuelle ` e e Java sur toutes les machines ex´cutant les ´l´ments administr´s. L’utilisation d’un e ee e protocole comme ssh en remplacement RMI dans un environnement non Java est impossible.

6.1.2.2

Extensibilit´ e

Ne pouvant pr´dire toutes les op´rations r´alisables dans toute administration, e e e l’adaptabilit´ du SAA doit le pr´disposer a int´grer de nouveaux modules permettant e e ` e par exemple de prendre en compte de nouveaux op´rateurs (probl`mes 2.3 et 3.7) e e ou de nouveaux besoins comme l’extension de l’environnement (probl`mes 3.4, 3.5 e et 3.6). La prise en compte de l’op´ration de migration dans les environnements e virtualis´s se traduit par l’int´gration d’un nouvel op´rateur move, tel que nous e e e l’avons pr´sent´ dans les sections 5.4.3 et 5.4.4. Ce qui permettra de r´aliser des e e e politiques de r´configuration bas´es sur la migration dans l’administration de l’IaaS. e e Quant aux probl`mes 3.4, 3.5 et 3.6, ils font ressortir trois types d’extensions de e l’administration n´cessitant l’adaptation du SAA : e – l’extension de l’environnement mat´riel (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 effet, ils exigent que la liste des supports d’ex´cution (machines) soit d´finie avant leur d´marrage. De ce e e e fait, les SE restent fig´s pendant l’ex´cution enti`re du SAA. Un module pere e e mettant leur extension dynamique permettrait de faire ´voluer cet environnee ment. – l’extension de l’environnement logiciel (probl`me 3.5) : En ce qui concerne e l’extension de l’environnement logiciel, nous distinguons deux types d’extensions. La premi`re est celle qu’offre le syst`me TUNe, c-`-d l’ajout/retrait e e a d’instances de logiciels dont la description ´tait connue de TUNe au d´mare e rage. Elle permet par exemple de r´aliser la scalabilit´ des applications J2EE. e e La deuxi`me est l’ajout de nouveaux logiciels non existant initialement dans e TUNe. La modification du comportement de TUNe aurait permis de prendre en compte ce type d’extension. Ce probl`me se pose une fois de plus dans e les applications J2EE. Prenons par exemple une application J2EE ne dispoSyst`me d’administration autonome adaptable : application au Cloud e

´ 6.1. CARACTERISTIQUES

59

sant pas initialement de distributeur de charges devant le serveur web Apache (Ha-Proxy [hap] par exemple). Apr`s constatation de l’incapacit´ d’un unique e e serveur web a r´pondre ` toutes les requˆtes, l’administrateur peut d´cider ` e a e e d’introduire en cours de route d’autres instances afin de partager les charges. Pour cela, il doit ajouter dans l’architecture initiale un nouveau logiciel (Haproxy), inexistant initialement, pour la distribution de charges aux diff´rentes e instances d’Apache. – l’extension des politiques de reconfiguration (probl`me 3.4) : Comme nous e l’avons pr´sent´ dans la section 5.4.4, il s’agit de la facult´ du SAA ` int´grer e e e a e de nouvelles politiques d’administration pendant son ex´cution. e

6.1.3

Interop´rable et Collaboratif e

L’interop´rabilit´ d’un syst`me informatique est sa facult´ ` dialoguer avec d’autres. e e e ea Dans certaines conditions, nous utilisons le terme ”collaboration” pour d´signer l’ine terop´rabilit´. En effet, nous d´finissons la collaboration comme la mise en commue e e nication de plusieurs SAA de mˆme type (probl`me 3.2) tandis que l’interop´rabilit´ e e e e (plus g´n´raliste) met en commun plusieurs SAA de types et de conceptions diff´e e e rents (probl`me 3.1). e La collaboration dans TUNe, telle que propos´e par [91] pour l’administration e des applications large ´chelle (section 5.4.2 du chapitre 5) adresse un probl`me pare e ticulier : le passage a l’´chelle de TUNe. Elle ne s’aurait s’appliquer au cloud. En ` e effet, [91] propose une collaboration entre plusieurs instances de TUNe partageant la mˆme application et d´crite par un unique administrateur. Les instances collae e borent entre elles pour accomplir l’administration de l’application qui est de tr`s e grande taille ici (des milliers d’´l´ments). De plus, au regard de son implantation ee (hi´rarchisation de TUNe), cette solution est propre aux applications large ´chelle e e de type DIET dont l’architecture est hi´rarchis´e. Les m´canismes de communicae e e tion entre les instances de TUNe mises en collaboration sont cˆbl´s pour r´pondre a e e a ce type d’application. Qu’` cela ne tienne, cette solution de [91] repr´sente une ` a e ´tape pr´alable de la collaboration des SAA. Dans le cas du cloud par exemple, son e e fonctionnement n’est effectif que grˆce ` la collaboration entre les SAA de niveau ena a treprise et IaaS. Ces SAA sont de natures compl`tement diff´rentes. Tout le principe e e de fonctionnement du cloud repose sur la collaboration entre les deux niveaux. Quelque soit le type d’interop´rabilit´ dans l’administration autonome, les ine e formations ´chang´es sont g´n´ralement de diff´rents 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 m´ta-informations d´crivant un syst`me de e e e repr´sentation r´pliqu´ entre plusieurs instances de SAA ou encore des ordres de e e e reconfiguration (cas du cloud). Illustrons ce dernier exemple en reprenant l’administration a deux niveaux du cloud que nous d´crivions dans le chapitre 3. Dans cet ` e exemple, plusieurs formes de collaboration sont identifiables :

Syst`me d’administration autonome adaptable : application au Cloud e

´ ´ ` 6.2. APPROCHE GENERALE ET MODELE ARCHITECTURAL

60

– La collaboration du niveau entreprise vers l’IaaS est ´vidente. C’est elle qui pere met ` l’entreprise d’acc´der au cloud par r´servation de ressources par exemple. a e e Elle permet ´galement a l’entreprise de se renseigner sur l’´tat des ressources e ` e (VM) qui lui sont allou´es. e – La collaboration IaaS vers l’entreprise, elle survient pour la r´solution de e pannes par exemple. En effet, soit une entreprise ayant une r´servation d’une e unique VM. A cause de l’incapacit´ de l’entreprise a d´tecter une panne mae ` e chine de la VM, elle est oblig´e de compter sur l’appel du SAA de niveau IaaS e pour cette d´tection. Ainsi, apr`s d´tection de pannes et r´alisation d’op´rae e e e e tions de r´paration pr´liminaires (red´marrage des VM par exemple), ce SAA e e e informe celui du niveau entreprise propri´taire de la VM. e – La collaboration entre plusieurs IaaS : elle survient lorsqu’une plateforme de cloud disposant de moins de ressources et contacte d’autres plateformes pour l’extension de ses capacit´s. L’ensemble constitu´ par ces IaaS est appel´ cloud e e e hybride. C’est le cas de la plateforme OpenNebula [OpenNebula] qui est capable d’associer une plateforme ElasticHost [ElasticHosts] pour ´tendre ses e ressources.

6.1.4

Synth`se e

Les caract´ristiques que nous avons pr´sent´es ci-dessus sont issues de nos exe e e p´riences r´alis´es dans le domaine de l’administration autonome avec les syst`mes e e e e TUNe et Jade. Ces caract´ristiques sont orthogonales dans la mesure o` elles se e u compl`tent et ne poss`dent aucun lien entre elles. Elles doivent ˆtre envisag´es lors e e e e de la conception d’un SAA a vocation g´n´rique. Dans la section suivante, nous pr´` e e e sentons une approche de conception ainsi qu’un mod`le architectural poss´dant les e e caract´ristiques ci-dessus. e

6.2
6.2.1

Approche g´n´rale et Mod`le Architectural e e e
Approche G´n´rale e e

Les sections pr´c´dentes ont pr´sent´ les caract´ristiques de base que doit foure e e e e nir notre SAA. L’adaptabilit´ apparaˆ comme le crit`re le plus important dans la e ıt e mesure o` c’est lui qui permet au SAA de prendre en compte la majorit´ des besoins u e d’administration. Elle n´cessite une implantation sous forme modulaire de telle sorte e que chaque fonction du SAA soit identifi´e par un module pr´cis. De plus, l’implane e tation modulaire peut faciliter la dynamicit´ du SAA lorsque l’adaptation s’effectue e pendant l’ex´cution du SAA. Dans ce contexte, nous pr´conisons une approche de e e d´veloppement du SAA suivant un mod`le a composants. Contrairement a TUNe e e ` ` et Jade qui utilisent cette approche uniquement pour l’encapsulation des logiciels et Syst`me d’administration autonome adaptable : application au Cloud e

´ ´ ` 6.2. APPROCHE GENERALE ET MODELE ARCHITECTURAL

61

Figure 6.1 – Mod`le architectural g´n´ral e e e mat´riels administr´s, l’approche que nous proposons ici consiste ` mettre la notion e e a de composant au cœur de la conception et de l’implantation du SAA. Autrement dit, les fonctionnalit´s du SAA et les ´l´ments administr´s doivent respectivement e ee e ˆtre implant´es et encapsul´s dans des composants. Identifions ` pr´sent 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 pr´sent´ les objectifs et le mod`le (figure 4.1) de e e e base d’un SAA. Compte tenu de sa simplicit´, ce mod`le est tr`s souvent repris dans e e e la litt´rature sous le terme de MAPE-K LOOP. Il pr´sente uniquement l’organisae e Syst`me d’administration autonome adaptable : application au Cloud e

´ ´ ` 6.2. APPROCHE GENERALE ET MODELE ARCHITECTURAL

62

tion g´n´rale d’un SAA sans pr´senter en d´tails sa constitution interne. Une des e e e e raisons qui explique cela vient du fait qu’en fonction des objectifs d’implantation, un SAA peut fournir toute ou partie des fonctionnalit´s de l’administration autoe nome (d´ploiement, configuration et reconfiguration). C’est le cas par exemple du e syst`me Taktuk [72] qui fournit uniquement des fonctionnalit´s de d´ploiement 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 l’administration 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 figure 6.1 pr´sente e e ce mod`le. e Sommairement, il s’agit d’un mod`le organis´ autour d’une structure de done e n´es (le SR) contenant tous les ´l´ments administr´s (logiciels, mat´riels) ainsi que e ee e e les politiques d’administration. Le SAA re¸oit des ordres d’administration venant de c l’ext´rieur (via l’External Communicator ). Apr`s construction du SR (par le SR e e Manager ), les composants gravitant autour de lui permettront au SAA de r´alie ser l’administration proprement dite. Il s’agit : du Deployment Manager pour le d´ploiement/undeploiement 1 , de l’Event Manager qui d´cide des politiques ` ex´e e a e cuter ` la r´ception d’´v´nements par l’Event Receiver , et du Policies Manager a e e e pour l’ex´cution des politiques de d’administration ((re)configuration et d´marrage). e e Pr´sentons ` pr´sent en d´tails le rˆle de chacun de ces composants. e a e e o External Communicator Il permet au SAA de communiquer avec l’ext´rieur. Il s’agit aussi bien de la e communication avec des acteurs humains (les administrateurs) que de la collaboration/interop´rabilit´ avec d’autres SAA. Ce composant repr´sente le point d’entr´e e e e e dans le SAA. Il joue un rˆle double dans le SAA. Le premier est la r´ception et l’intero e pr´tation des requˆtes d’administration en provenance de l’ext´rieur. Il fera ensuite e e e appel au composant du SAA capable d’ex´cuter l’ordre d’administration contenue e dans la requˆte. Son second rˆle est la restitution a l’initiateur de la requˆte, les e o ` e r´sultats de son ex´cution. C’est ainsi que l’External Communicator fera appel e e au : – SR Manager lorsque la requˆte re¸ue correspondra a la soumission de l’applie c ` cation a administrer au SAA ou la modification du syst`me de repr´sentation ` e e (voir ci-dessous) ; – Deployment Manager pour le d´ploiement des applications ; e – Event Manager pour l’ex´cution des programmes de reconfiguration. e SR Manager Il est charg´ de construire une repr´sentation des ´l´ments a administrer ainsi que e e ee ` des politiques d’administration de telle sorte que le SAA puisse facilement les manipuler. Compte tenu du fait que ces ´l´ments sont consid´r´s comme des boˆ noires, ee ee ıtes le SR Manager doit r´aliser pour chacun d’entre eux une op´ration d’encapsulae e
1. Compte tenu de la non existence des antonymes au mot ”D´ploiement” et au verbe e ”D´ployer”, nous introduisons respectivement le mot ”Und´ploiement” et le verbe ”Und´e e e ployer” pour jouer ces rˆles. o

Syst`me d’administration autonome adaptable : application au Cloud e

´ ´ ` 6.2. APPROCHE GENERALE ET MODELE ARCHITECTURAL

63

tion. Cette derni`re consiste ` externaliser (avec le concours de l’administrateur) : e a d’une part les fonctions m´tiers de l’´l´ment consid´r´ afin de les rendre accessibles e ee ee par le SAA ; et d’autre part les propri´t´s de l’´l´ment. C’est en fonction de l’imee ee plantation de l’encapsulation que le fournisseur du SAA d´cidera de respecter ou e non le crit`re d’uniformit´ que nous avons pr´sent´ dans la section 6.1.1. e e e e Nous nommons SR (Syst`me de Repr´sentation), l’ensemble constitu´ de ces ´l´e e e ee ments encapsul´s. Il contient a un instant donn´ la photographie de l’´tat courant e ` e e de l’environnement en cours d’administration. Le SR repr´sente en quelque sorte la e base de donn´es du SAA. Il sera utilis´ par tous les autres composants du SAA. e e Deployment Manager Il r´alise a la fois les op´rations de d´ploiement et und´ploiement dans le SAA. e ` e e e Pour cela, il s’appuie d’une part sur le SR afin d’avoir les propri´t´s des ´l´ments ee ee a d´ployer et d’autre part sur les effecteurs afin d’ex´cuter concr`tement les op´ra` e e e e tions de d´ploiement sur la machine distante. La communication avec les effecteurs e s’effectue par le biais de l’Internal Communicator . Pour finir, notons que le Deployment Manager d´finit ´galement les politiques d’allocation et de lib´rae e e tion de ressources de l’environnement administr´ de telle sorte qu’elles pourront ˆtre e e adaptables. Internal Communicator Il assure la communication entre le SAA et les ´l´ments en cours d’ex´cution ee e (par l’interm´diaire des effecteurs). C’est grˆce ` lui notamment que le SAA pourra e a a r´ellement ex´cuter les op´rations d’administration. e e e Event Receiver Il g`re l’arriv´e des ´v´nements/messages vers le SAA en provenance des ´l´ments e e e e ee qu’il administre. Il les transmettra par la suite au gestionnaire d’´v´nements (Event e e Manager ). Event Manager En fonction de l’´tat du SR et des ´v´nements qu’il re¸oit, il d´cide de leur prise e e e c e en compte ou non. Dans le cas o` l’´v´nement est pris en compte, il identifie dans u e e le SR les programmes d’administration ` ex´cuter par le Policies Manager . a e Policies Manager Il joue le rˆle d’ex´cution des programmes d’administration. Il doit pour cela o e implanter les services d’un interpr´teur de programmes qui lui permettra d’identie fier les s´ries d’actions comprises dans les programmes qu’il d´sire ex´cuter. Pour e e e chaque action identifi´e, il fera appel a l’Internal Communicator pour son ace ` complissement r´el a distance sur la machine d’ex´cution de l’´l´ment concern´ par e ` e ee e l’action.

Syst`me d’administration autonome adaptable : application au Cloud e

` 6.3. SYNTHESE

64

6.2.3

Prise en compte des caract´ristiques e

Apr`s la pr´sentation du mod`le architectural devra suivre la conception et le e e e d´veloppement d’un SAA g´n´rique, montrons ` pr´sent comment ce mod`le r´pond e e e a e e e aux caract´ristiques que nous avons identifi´es dans la section 6.1. e e L’uniformit´ des ´l´ments administr´s dans le SAA est assur´e dans ce mod`le e ee e e e par le composant SR Manager . En effet, c’est dans son implantation que les constructeurs du SAA d´cideront de figer ou non les diff´rences entre les ´l´ments e e ee administr´s. e L’adaptabilit´ du SAA est ´vidente dans ce mod`le dans la mesure o` il r´pond e e e u e enti`rement sur une architecture a composants dans lequel tous les services sont e ` identifiables par un composant. Pour finir, la collaboration/interop´rabilit´ est une fonctionnalit´ mise en avant et e e e remplie par le composant External Communicator dans le mod`le. Ce composant e permet l’´mission et la r´ception d’ordres d’administration 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 d´veloppement d’un SAA hautement adaptable et flexible. Ces directives e concernent a la fois les besoins que doit remplir ce SAA, l’approche g´n´rale de son ` e e implantation et pour finir le mod`le architectural qu’il devra suivre. De plus, nous e avons montr´ comment ces directives permettront au SAA de prendre en compte e l’administration d’une plateforme de cloud ainsi que des applications qu’il h´berge. e Dans le chapitre suivant, nous ´tudions les travaux de recherche existants qui e s’int´ressent aux mˆmes probl´matiques que celles que nous adressons dans cette e e e th`se. Il s’agit globalement de la construction des SAA flexibles et de l’administrae tion autonome dans le cloud.

Syst`me d’administration autonome adaptable : application au Cloud e

Chapitre 7 Etat de l’art
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 probl´matique est l’administration des platee e formes de cloud et des applications qu’elles h´bergent. Exer¸ant dans le domaine de e c l’administration autonome depuis ces derni`res ann´es, nous avons ´tabli le rapproe e e chement entre la probl´matique d’administration dans le cloud et celle des grilles e de calculs que nous traitions dans nos recherches. C’est ainsi que nous avons entrepris d’´tudier l’utilisation de notre syst`me d’administration autonome TUNe, con¸u e e c pour l’administration des applications dans les clusters et les grilles, pour l’administration du cloud dans son ensemble (IaaS et applications des entreprises). Con¸u c pour ˆtre g´n´rique et utilisable dans plusieurs domaines, le syst`me TUNe a montr´ e e e e e cependant quelques difficult´s a prendre en compte des besoins d’administration de e ` certains domaines applicatifs parmi lesquels le Cloud (voir le chapitre 5). L’´tude des difficult´s de TUNe nous a conduit ` proposer plus g´n´ralement un e e a e e canevas de d´veloppement d’un v´ritable syst`me g´n´rique et adaptable ` tous les e e e e e a domaines applicatifs dont le cloud. Ce canevas pr´conise trois recommandations a e ` suivre dans le processus de d´veloppement d’un SAA a vocation g´n´rique : e ` e e

7.1. SAA

66

(1) S´parer le d´veloppement du cœur du SAA (fonctionnalit´s de base) de celui e e e des langages d’administration qu’utiliseront ses futurs administrateurs. (2) Le SAA devra remplir les crit`res suivants : e – l’uniformit´ : il ne dispose d’aucun comportement pr´-cˆbl´ li´ ` un type e e a e e a d’´l´ment (les machines par exemple). ee – l’adaptabilit´ : la modification de ses services ne doit pas n´cessiter la connaise e sance enti`re de son processus de d´veloppement. e e – l’interop´rabilit´ : sa facult´ a initier la communication avec d’autres SAA e e e` d’une part et a exporter ses interfaces d’acc`s distant d’autre part. ` e (3) Pour finir, nous recommandons l’utilisation d’une approche de d´veloppement ` e a composants pour son implantation. En somme, nous nous int´ressons a deux probl´matiques : la construction de e ` e SAA g´n´riques et l’administration du cloud dans son ensemble (niveau IaaS et ene e treprise). Dans ce chapitre, nous ´tudions les travaux de recherche qui s’int´ressent e e a ces probl´matiques. Nous l’organisons de la mani`re suivante. Dans un premier ` e e temps, nous ´tudions les SAA ` vocation g´n´rique existants. Dans cette premi`re e a e e e ´tude, nous pr´sentons le positionnement de ces SAA par rapport aux recommane e dations que nous avons ´num´r´es ci-dessus. Dans un second temps, nous ´tudions e ee e les syst`mes d’administration sp´cifiques aux environnements de cloud. Comme nous e e l’avions pr´cis´ dans la section 3.3, ces syst`mes doivent remplir les crit`res suivants : e e e e – Interop´rable : capacit´ a dialoguer avec d’autres syst`mes de gestion de e e ` e cloud et ´galement avec des syst`mes d’administration des applications d’ene e treprises. – Auto-r´parable : capacit´ a prendre en compte automatiquement les pannes e e` dans l’environnement qu’il administre (machines, VM et logiciels). – Extensible : capacit´ ` prendre en compte de nouveaux ´l´ments dans l’enea ee vironnement (nouvelles machines r´elles et virtuelles, nouveaux logiciels). e – Programmable : capacit´ a prendre en compte de nouvelles politiques d’ade` ministration (nouvelles m´thodes de consolidation, de scalabilit´, etc.). e e – Adaptable : capacit´ ` permettre le remplacement ou la modification de ses ea modules afin de prendre en compte des particularit´s de certaines plateformes e de cloud. – Langages d´di´s : dispose des langages de facilitation de son utilisation. e e Compte tenu de sa sp´cialisation dans le cloud, il n’est 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 identifi´s pour les e e SAA g´n´riques. e e

7.1

SAA

Parmi les travaux de d´veloppement de SAA, peu d’entre eux ont la vocation de e prendre en compte plusieurs domaines d’applications ` la fois. En effet, ils s’int´a e ressent chacun pour la plupart ` un domaine pr´cis. Ainsi, le crit`re d’adaptabilit´ a e e e Syst`me d’administration autonome adaptable : application au Cloud e

7.1. SAA

67

que nous consid´rons 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 l’existant ´tudiera e e principalement l’extensibilit´ des SAA qui est l’un des crit`re d´coulant de l’adaptae e e bilit´ et pris en compte par certains SAA. En rappel, l’extensibilit´ d’un SAA d´signe e e e la capacit´ du SAA ` prendre en compte pendant son ex´cution, l’ajout/retrait de e a e nouveaux ´l´ments logiciels ou des instances de logiciels dont la description existait ee au d´marrage du SAA. e Dans cette section, nous ´tudions les SAA : Rainbow [55], Accord [70] et Unity [37]. e Le premier se d´finit comme SAA adaptable (au sens que nous avons d´fini dans le e e chapitre pr´c´dent) a des domaines quelconques tandis que les deux derniers sont e e ` sp´cifiques a des domaines particuliers. e `

7.1.1

Rainbow

Description g´n´rale e e La plateforme Rainbow [55] est le fruit du projet DASADA DARPA [das] de l’universit´ de Carnegie Mellon. D´velopp´e au sein de l’´quipe ABLE [abl], elle est e e e e disponible comme logiciel open source. A l’exception des SAA TUNe et Jade, Rainbow est l’un des rares SAA que nous avons parcourus (Pragma [83], Cascada [22], Accord [70], Unity [37], etc.) qui se r´clament ˆtre adaptable a tous types d’applicae e ` tions. Pour cela, son architecture est organis´e en deux parties : la premi`re partie e e implante les fonctionnalit´s de base de l’administration autonome tandis que la see conde partie implante les services qui pourront ˆtre adaptable par le suite. C’est e cette deuxi`me partie qui sera personnalis´e en cas de besoin afin de prendre en e e compte un nouveau domaine d’applications. Le syst`me Rainbow est con¸u pour e c l’administration d’applications pr´alablement install´es et en cours d’ex´cution. Il e e e ne fournit pas les fonctions de d´ploiement de logiciels. Son ex´cution d´bute par la e e e fourniture d’un mod`le repr´sentant l’architecture de l’application en cours d’ex´cue e e tion. Ce mod`le sera ensuite maintenu par Rainbow tout au long de son ex´cution e e (via les composants Gauges et Model Manager). C’est l’´quivalent du syst`me de e e repr´sentation (SR) dans TUNe. e Pour finir, le mod`le architectural (figure 7.1) implant´ par Rainbow est proche e e de celui que nous avons pr´sent´ dans la section 6.2 du chapitre 6. A l’exception e e de l’absence du service de d´ploiement et de collaboration, nous retrouvons plus ou e moins les mˆmes ´l´ments : 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 – L’Adaptation Manager et l’Architecture Evaluator correspondent ` l’Event Maa nager dans notre mod`le. e – Le Translation Infrastructure implante l’Event Receiver de notre mod`le. De e plus, il met en place le m´canisme d’ex´cution de m´thodes ` distance sur les e e e a machines h´bergeant l’´l´ment administr´. Le service implantant ce m´canisme e ee e e n’est pas clairement identifi´ dans l’architecture de Rainbow. e –

Syst`me d’administration autonome adaptable : application au Cloud e

7.1. SAA

68

Figure 7.1 – La plateforme Rainbow Ainsi, nous ne pr´sentons pas les ´l´ments pr´sents dans cette architecture extraite e ee e de [55]. Machine Langage Rainbow implante deux langages : l’un pour la description du SR (le langage Acme) et l’autre pour la d´finition des politiques de reconfiguration (le langage e Stitch). L’interpr´tation de ces langages est cˆbl´e et ne peut ˆtre remplac´e mˆme e a e e e e par adaptation (section Adaptable). De plus, ces langages sont propres a l’´quipe ` e de d´veloppement de Rainbow (ABLE). e Approche de d´veloppement e Raimbow est implant´ suivant une approche a composants : le mod`le Acme [56] e ` e d´velopp´ au sein de la mˆme ´quipe. De fa¸on similaire, la description et l’encape e e e c sulation des logiciels dans Rainbow se fait par le biais du mˆme 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 ´l´ments de l’environnement mat´riels (les e ee e machines). Il effectue une diff´rence entre la repr´sentation des machines, la repr´e e e sentation des logiciels et celle des sondes. En exemple : les propri´t´s des machines ee de l’environnement sont d´finies par Rainbow : les sondes ne sont pas consid´r´es e ee comme des logiciels administrables. Adaptable La plateforme Rainbow a ´t´ con¸ue afin d’ˆtre adaptable aussi bien conceree c e Syst`me d’administration autonome adaptable : application au Cloud e

7.1. SAA

69

nant ses composants de service que les applications qu’il administre. Cependant, la construction et l’int´gration de nouveaux services dans cette plateforme restent e r´serv´es aux ing´nieurs ayant une expertise sur la plateforme. Pour palier a cette e e e ` difficult´, une plateforme graphique de facilitation de cette tˆche est d´sormais foure a e nie. Il s’agit de RAIDE [36]. Lorsque nous nous int´ressons aux composants de service de Rainbow qui sont e personnalisables, nous nous rendons compte qu’il ne s’agit pas effectivement des fonctions de service telles que nous les avons identifi´es dans notre mod`le dans la e e section 6.2 du chapitre 6. En effet, les composants dont parlent les constructeurs de Rainbow sont : les effecteurs, les sondes, les ´l´ments du SR (r`gles de reconee e figuration, logiciels, propri´t´s des logiciels). Par contre, les composants g´rant la ee e construction du SR par exemple, ou encore les interpr´teurs de langages d’adminise tration ne font pas partie des services personnalisables. Interop´rable e Aucune fonctionnalit´ d’interop´rabilit´ n’est fournie par Rainbow. e e e

7.1.2

Accord

Description g´n´rale e e Accord [70] [69] fait partie des contributions du projet AutoMate [18] ` l’univera sit´ du New Jersey. Le but du projet AutoMate est de fournir des solutions d’ade ministration autonome pour des syst`mes complexes. Dans ce projet, Accord (via e son implantation DIOS++) est une plateforme de programmation d’applications scientifiques auto-administrables. De la mˆme fa¸on que TUNe, Accord consid`re e c e les ´l´ments a administrer comme des boˆ noires. ee ` ıtes L’encapsulation d’un logiciel se fait par la d´finition de port de communication e dans Accord. Il identifie trois types de port : – port fonctionnel : correspond aux points d’entr´es des fonctions m´tiers de e e l’´l´ment. Il est utilis´ pour relier les logiciels entre eux afin de permettre leurs ee e interactions. – port de contrˆle : permet de d´finir les points d’entr´e/sortie des effecteurs et o e e sondes. – port de gestion : utilis´ pour l’injection et l’ex´cution de r`gles d’adaptation e e e du logiciel. Il associe a chaque ´l´ment administr´ un Manager qui s’occupe du contrˆle (monito` ee e o ring de l’´tat, du d´clenchement des ´v´nements et de l’orchestration de l’ex´cution e e e e e des actions de reconfiguration) de son ex´cution. Le Manager s’ex´cute sur la mˆme e e e machine que l’´l´ment qu’il contrˆle. De cette fa¸on, Accord d´centralise l’adminisee o c e tration. La figure 7.2 r´sume l’encapsulation d’un ´l´ment dans Accord. Pour finir, e ee notons qu’Accord n’assure pas le d´ploiement des logiciels qu’il administre. Cette e tˆche est laiss´e ` la charge des administrateurs. Par contre, il contrˆle le d´ploiea e a o e ment des politiques de reconfiguration.

Syst`me d’administration autonome adaptable : application au Cloud e

7.1. SAA

70

Figure 7.2 – Encapsulation d’un logiciel dans Accord Machine Langage L’administration dans Accord d´bute par la d´finition du contexte applicatif. Il e e s’agit de la base syntaxique et s´mantique qu’utilisera plus tard l’administrateur e pour la d´finition des ´l´ments administr´s et des r`gles de reconfiguration. Pour e ee e e cela, Accord se base sur les langages SIDL [88] et WSDL [38] pour la d´finition de e ce contexte. SIDL est utilis´ pour la d´finition des composants tandis que WSDL est e e utilis´ pour la d´finition des ports de contrˆle. De plus, il fournit et cˆble le langage e e o a utilis´ pour la d´finition des programmes de reconfiguration. Il s’agit d’un langage e e simpliste de type IF <condition> THEN <action>. Approche de d´veloppement e L’implantation actuelle d’Accord (DIOS++) repose sur deux approches de d´vee loppement : orient´e objet (c++) et mod`le ` composants (CCAFFEINE CCA [20]). e e a La premi`re a ´t´ utilis´e pour l’implantation de DIOS (un prototype d’Accord). e ee e Quant a la seconde approche, Accord l’utilise uniquement pour l’encapsulation des ` logiciels a administrer. C’est une approche analogue a celle utilis´e par le syst`me ` ` e e TUNe [29]. Uniforme Parmi les ´l´ments administr´s, Accord ne prend pas en compte les ´l´ments ee e ee mat´riels constituant l’environnement d’ex´cution. Il fait l’hypoth`se qu’ils sont inse e e tall´s et g´r´s par des syst`mes externes [18] (Rudder, Meteo et Sesame/DAIS). e ee e Concernant les ´l´ments logiciels, il effectue une diff´rence entre les logiciels r´aliee e e sant les fonctions m´tiers de l’application et les sondes jouant le rˆle de monitoring. e o En effet, les sondes doivent ˆtre programm´es dans la plateforme Accord. Elles ne e e sont pas consid´r´es comme des logiciels administrables. Ainsi, pour une application ee disposant d’un v´ritable logiciel de monitoring, ce dernier devra ˆtre r´implant´ dans e e e e Accord.

Syst`me d’administration autonome adaptable : application au Cloud e

7.1. SAA

71

Adaptable Le d´veloppement DIOS++ (implantation d’Accord) ne suit pas une approche e a composants et n’a pas envisag´ dans sa conception la possibilit´ de modifier/rem` e e placer/ajouter de nouvelles fonctionnalit´s par un utilisateur ext´rieur. Qu’` cela ne e e a tienne, int´ressons nous aux facettes adaptables et non adaptables d’Acccord. e Accord permet la modification d’une part de l’architecture et d’autre part des fonctionnalit´s d’un logiciel en cours d’administration. En effet, ´tant donn´ qu’il utie e e lise un mod`le a composants pour l’encapsulation des logiciels, la modification de l’are ` chitecture ou encore l’enrichissement des fonctionnalit´s d’un logiciel deviennent pose sibles. La modification de l’architecture comprend les op´rations suivantes : l’ajout, e le remplacement et le retrait des logiciels de l’architecture. Concernant l’ajout des logiciels, il ne se limite pas uniquement aux ´l´ments existants initialement dans la ee d´finition fournie a Accord par l’administrateur. Quant a la modification du come ` ` portement d’un logiciel, elle se r´alise par la modification de liaison, la suppression e ou l’ajout de ports fonctionnels. Cependant, Accord garde le contrˆle sur l’implantation du processus de remplao cement des logiciels. Par exemple, c’est lui qui implante les politiques de r´paration e de logiciel ou de remplacement de logiciels par d’autres plus optimis´s. e Interop´rable e La seule interop´rabilit´ qu’implante Accord est celle qu’il effectue avec les syse e t`mes de gestion de l’environnement mat´riel et r´seau (Rudder, Meteo et Sesame/e e e DAIS [99]) dans lesquels s’ex´cuteront les logiciels qu’il auto-administre. Globalee ment, aucune API de collaboration avec d’autres SAA n’est fournie dans Accord.

7.1.3

Unity

Description g´n´rale e e Unity [37] est l’un des premiers SAA qui a vue le jour apr`s la pose des bases de e l’administration autonome par IBM en 2001 [64]. En effet, il est le prototype d’un SAA d´velopp´ par IBM afin de valider les principes qu’il a ´nonc´ auparavant. Il e e e e est con¸u pour l’administration des services OGSA [50]. c De la mˆme fa¸on que la plateforme Accord (section 7.1.2), tous les ´l´ments e c ee a administrer dans Unity sont autonomes. Il associe a chaque ´l´ment administr´, ` ` ee e un composant Manager qui sera d´ploy´ et ex´cut´ sur la mˆme machine de cet e e e e e ´l´ment. Le rˆle du Manager est la gestion de l’´l´ment qui lui est associ´ : gestion ee o ee e des liaisons/interactions avec les autres ´l´ments, monitoring, d´clenchement des ee e programmes de reconfiguration (appel´s r`gles) et maintien de l’´tat de l’´l´ment e e e ee (par renseignement de propri´t´s). Notons ´galement qu’Unity auto-administre, de ee e la mˆme fa¸on que les ´l´ments de l’administrateur, ses propres constituants (´l´e c ee ee ments destin´s a la r´alisation de ses services pr´sent´s ci-dessous). De la mˆme e ` e e e e fa¸on qu’Accord, l’association de Managers aux ´l´ments permet de d´centraliser c ee e

Syst`me d’administration autonome adaptable : application au Cloud e

7.1. SAA

72

l’administration dans Unity. Unity est construit autour de six ´l´ments : ee – Le gestionnaire de l’environnement du logiciel : il g`re les ressources dont e l’application a besoin pour atteindre ses objectifs. L’une de ses principales responsabilit´s est de pr´dire le comportement du logiciel en cas de de mont´e e e e et baisse de charges sur les ressources qui lui sont allou´es. e – Le gestionnaire de ressources : c’est lui qui implante la politique d’assignation de ressources aux logiciels. Chaque gestionnaire d’environnement de logiciel lui fournit une ´valuation des ressources dont a besoin son logiciel. Ensuite, e le gestionnaire de ressources d´cidera des quantit´s de ressources a allouer a e e ` ` chaque logiciel. Il d´cide ´galement de l’instant d’assignation ou retrait des e e ressources. – l’annuaire : c’est le lieu d’enregistrement des r´f´rences des ´l´ments admiee ee nistr´s par Unity ainsi que des ressources de l’environnement. A travers cet e annuaire, chaque ´l´ment d’Unity pourra d´couvrir les ´l´ments dont il a beee e ee soin pour son fonctionnement. – Le gestionnaire des r`gles de reconfiguration : il permet a l’administrateur de e ` d´finir et de stocker les r`gles de reconfiguration. e e – Les sentinelles : permettent a un ´l´ment d’introspecter l’´tat d’un autre. ` ee e – Les ´l´ments administr´s : il s’agit des logiciels (server ) et des ressources (OSee e Container ) pr´sents dans l’environnement. e L’architecture du syst`me Unity n’est pas ´loign´e de celle du syst`me Accord. e e e e Machine Langage Les logiciels ` administrer par Unity doivent ˆtre d´velopp´s 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 d’informae tions dans la litt´rature consacr´e a cette plateforme) pour la d´finition des r`gles e e ` e e de reconfiguration. Approche de d´veloppement e Unity utilise un mod`le a composants a la fois pour son d´veloppement et pour e ` ` e le d´veloppement des logiciels administr´s. Il pratique le ”tout composant”. e e Uniforme La plateforme Unity d´finit un type, cˆbl´ en son sein, pour chaque type d’´l´e a e ee ment qu’il administre. A chaque type est associ´ un comportement pr´cis. Ainsi : les e e logiciels administr´s et les constituants d’Unity sont dit de type server ; les machines e h´bergeant les servers sont de type OSContainer. e Adaptable Unity n’a pas envisag´ l’adaptabilit´ de ses composants. Aucune architecture a e e ` composants d’Unity n’est disponible dans la litt´rature et nous ne saurions ´valuer e e le niveau de difficult´ de l’adaptation d’un service d’Unity pour un administrateur e non averti. L’adaptabilit´ d’Unity par contre peut ˆtre observ´e sous l’angle de l’extensibilit´ e e e e

Syst`me d’administration autonome adaptable : application au Cloud e

7.2. SAA POUR LE CLOUD

73

de l’environnement administr´. Unity permet la prise en compte dynamique de : e nouvelles r`gles de reconfiguration, nouvelles machines dans l’environnement, ou e encore de nouveaux logiciels ` administrer dans l’application. Cette fonctionnalit´ a e est permise grˆce a l’auto-administration de chaque ´l´ment de l’environnement. a ` ee Ainsi, il sera capable de s’int´grer dans l’environnement sans n´cessiter l’arrˆt du e e e syst`me. e Interop´rable e Aucune fonctionnalit´ d’interop´rabilit´ n’est 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 l’architecture de Rainbow se rapproche de celle e que nous avons propos´ dans la section 6.2.2 du chapitre pr´c´dent. Quant a Accord e e e ` et Unity, ils se situent dans la mˆme lign´e que les SAA tels que Pragma [83] ou e e Cascada [22] que nous n’avons pas pr´sent´s ici. Malgr´ son caract`re adaptable, e e e e Rainbow (comme les autres SAA que nous avons ´tudi´s) n’est pas utilisable pour e e l’administration du cloud. Dans la section suivante, nous pr´sentons des SAA con¸us e c particuli`rement pour l’administration du cloud. e

7.2

SAA pour le cloud

Depuis ces derni`res ann´es, plusieurs projets autour du cloud computing ont vu e e le jour et donn´ naissance a autant de syst`mes d’administration dans le cloud. Dans e ` e cette section, nous ´tudions les plus importants et disponibles d’entre-eux. Par e disponibilit´ ici, nous entendons les syst`mes pour lesquels la documentation exise e tante est suffisamment d´velopp´e pour faire l’objet d’une ´tude telle que nous la soue e e haitons. En effet, parmi les plateformes de cloud importantes, la plupart d’entre elles sont propri´taires et tr`s peu document´es. Par soucis d’exhaustivit´, nous identifions e e e e deux plateformes non document´es dont nous fournirons uniquement une description e g´n´rale. Il s’agit des plateformes Amazone EC2 [61] et RightScale [RIGHSCALE]. e e Quant aux plateformes document´es, nous nous int´ressons 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 mat´riel) de e la mise en place d’une v´ritable plateforme de cloud. Quant a la plateforme Windows e ` Azure [76], elle est propri´taire et commerciale. e

Syst`me d’administration autonome adaptable : application au Cloud e

7.2. SAA POUR LE CLOUD

74

7.2.1

OpenNebula

Description g´n´rale e e La syst`me OpenNebula [OpenNebula] voit le jour en 2005 ` l’universit´ Come a e plutense de Madrid dans le cadre du projet europ´en open source RESERVOIR [87]. e Son objectif dans le cadre de ce projet est l’administration des IaaS virtualis´s. e Autrement dit, il fournit des services permettant de d´ployer et d’ex´cuter dans e e un environnement mat´riel virtualis´ des VM. Notons qu’une version commerciale e e d’OpenNebula (OpenNebulaPro) est disponible depuis 2010. Dans sa version actuelle, OpenNebula est capable de prendre en compte simultan´ment dans l’IaaS des hyperviseurs Xen [23], kvm [97] et VMware [VMware.org]. e Il organise l’IaaS sous forme de clusters et de VLAN (r´seaux virtuels). Un cluster e contient un ensemble de machines physiques tandis qu’un VLAN est d´fini pour un e ensemble de VM. Lors de la cr´ation d’une VM, le client choisit la machine et le e VLAN dans lequel il souhaite l’ex´cuter. Notons que dans l’esprit du cloud, il ne e revient pas au client de choisir la machine sur laquelle il souhaite ex´cuter sa VM. e Toutes les op´rations d’administration sont coordonn´es a partir d’une unique e e ` machine de l’IaaS appel´e Frontend. Son fonctionnement est r´gi par cinq processus e e et une base de donn´es (figure 7.3) : e – Virtual Machine Manager (VMM) Driver : il g`re les API d’interfa¸age avec les e c diff´rents hyperviseurs pr´sents dans l’IaaS. Pour cela, il d´ploie sur toutes les e e e machines de l’IaaS les scripts d’interfa¸age avec l’hyperviseur sur la machine. c – Transfert Manager (TM) Driver : il g`re le transfert des images de VM dans e diff´rentes situations : avant leur ex´cution (du serveur de stockage vers la e e machine d’ex´cution de la VM) ; pendant leur ex´cution (migration de VM e e d’une machine ` une autre) ou apr`s leur ex´cution (suppression ou sauvegarde a e e de l’image). – Information Manager (IM) Driver : il fournit les sondes de monitoring et g`re e les informations que celles-ci obtiennent de l’ex´cution des VM. Il d´ploie sur e e toutes les machines de l’IaaS une sonde (en fonction de l’hyperviseur utilis´) e charg´e de collecter les informations li´es aux VM en cours d’ex´cution sur la e e e machine. – Scheduler : Il g`re les politiques de consolidation des VM dans l’IaaS. e – Oned : Il configure, d´marre et orchestre l’ex´cution des processus pr´c´dents. e e e e C’est le point d’entr´e et de ralliement de l’ensemble de ces processus. e – DB : C’est la base de donn´es qui contient toutes les informations concernant e l’´tat de l’IaaS et de ses utilisateurs. Elle correspond au SR de notre mod`le e e de SAA. Interop´rable e OpenNebula fournit plusieurs moyens de communication avec l’ext´rieur. Ces e moyens sont bas´s sur un ensemble d’API de bas niveau (utilisables par des d´vee e loppeurs d’extension ` OpenNebula) et une interface de ligne de commandes. Cette a derni`re est essentiellement r´serv´e aux acteurs humains du cloud. Les interfaces de e e e

Syst`me d’administration autonome adaptable : application au Cloud e

7.2. SAA POUR LE CLOUD

75

Figure 7.3 – Composition d’OpenNebula bas niveau et l’interface de ligne de commandes sont utilis´es pour l’ex´cution des e e commandes d’administration de base (r´servation de VM, d´marrage, arrˆt de VM, e e e etc.). OpenNebula ne fournit aucun support permettant aux entreprises de facilement d´ployer et administrer leur applications dans l’IaaS. Cependant, ses API peuvent e ˆtre exploit´es par un SAA de niveau entreprise afin d’automatiser les op´rations de e e e r´servation et de monitoring des VM d’une 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 d’aucun autre moyen de l’adapter pour l’initiation de la collaboration avec d’autres plateformes de cloud. Auto-r´parable e OpenNebula g`re deux types de pannes : pannes de machines et pannes de VM. e Dans les deux cas, l’administrateur d´finit au d´marrage de Oned, les politiques de e e r´paration qu’il d´sire appliquer en cas de pannes. OpenNebula utilise le m´canisme e e e d’´v´nement-action (qu’il appelle Hook ). Un ´v´nement correspond ` la variation e e e e a de l’´tat d’une machine (physique ou VM). L’´tat de la machine est r´guli`rement e e e e renseign´ par les sondes de l’IM Driver. e L’ex´cution des actions associ´es a un ´v´nement est locale (sur la machine d’ex´e e ` e e e cution de Oned ) ou distante (sur la machine o` la panne a ´t´ d´tect´e). Cette ex´u ee e e e cution est donc limit´e a une seule machine. Il revient a l’administrateur de d´finir e ` ` e le lieu d’ex´cution des actions de r´paration. De plus, les Hook d’OpenNebula ne e e permettent pas de prendre en compte les pannes concernant ses propres serveurs. En effet, ne faisant pas partie des pr´occupations d’OpenNebula, aucune sonde n’est e pr´vue pour leur surveillance. La panne d’un serveur DNS par exemple ne pourra ni e ˆtre d´tect´e ni ˆtre r´par´e par OpenNebula. e e e e e e Extensible La gestion de l’IaaS par OpenNebula repose enti`rement sur l’extension de ses e ´l´ments. En effet, il d´marre l’IaaS sans aucun ´l´ment et attend leur ajout par ee e ee l’administrateur. C’est ainsi que les clusters de machines, les utilisateurs et les d´fie nitions de VM lui sont rajout´s pendant son ex´cution. Il fournit parmi ses API le e e moyen d’ajouter/retirer des ´l´ments de l’environnement. Cependant, il ne permet ee pas la modification des ´l´ments pr´alablement ajout´s. Par exemple, la modificaee e e Syst`me d’administration autonome adaptable : application au Cloud e

7.2. SAA POUR LE CLOUD

76

tion des caract´ristiques (nom DNS ou adresse r´seau) d’un VLAN enregistr´ n’est e e e pas possible. De la mˆme fa¸on, l’ajustement des ressources d’une VM en cours e c d’ex´cution dans l’IaaS n’est pas permis. e Programmable Aucune interface de programmation n’est fournie pour les applications entreprises. La programmation des politiques d’administration dans OpenNebula se limite uniquement au niveau de l’IaaS. La consolidation de VM est r´alis´e par un procese e sus particulier : le Scheduler. Ce dernier s’ex´cute sur le Frontend et est ind´pendant e e de l’ex´cution de Oned. Il s’ex´cute r´guli`rement ` la recherche de VM devant ˆtre e e e e a e d´plac´es vers des machines plus ad´quates selon la politique de consolidation. Dans e e e son implantation actuelle, le Scheduler d’OpenNebula 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 simultan´ment, ce qui peut entraˆ e ıner des contradictions (´clatement pour certaines VM et regroupement pour d’autres). L’int´gration de e e nouvelles politiques a ce Scheduler est impossible. Le seul moyen de l’am´liorer est ` e son remplacement tout entier. Cependant, il n’est pas pr´vu de support logiciel pour e la conception de politique de consolidation. C’est la raison pour laquelle seules des solutions issues de son ´cosyst`me (d´veloppements auxiliaires au projet OpenNee e e bula) existent. Il s’agit des schedulers Haizea [89] et Claudia [cla]. Les politiques de consolidation de VM sont associ´es par le propri´taire de la VM e e lors de sa r´servation. Il semble ´trange qu’OpenNebula utilise cette strat´gie. En e e e effet, la prise de d´cision 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 l’objectif de la consolidation dans le cloud est d’optimiser l’utilisation de ses ressources et non de celles des VM. La consolidation est r´alis´e dans l’int´rˆt du e e ee fournisseur du cloud et non de celui de la VM ` qui des ressources sont allou´es et a e garanties. Adaptable La construction d’OpenNebula sous forme modulaire le rend enti`rement adape table. Toutes les tˆches d’administration sont identifiables et rempla¸ables sans aua c cun besoin de connaissance de l’implantation enti`re d’OpenNebula (` l’exception e a du Scheduler ). En effet, il associe a chacun de ses services un ensemble de scripts ` d´finis dans un r´pertoire pr´cis du Frontend de telle sorte que la modification du e e e service s’effectue a un unique endroit. Cependant, il n´cessite de la part de l’admi` 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 extrˆmement difficile de les adapter. En effet, 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 l’adaptabilit´ e e d’OpenNebula. La modification d’un de ses modules n´cessite le red´marrage de e e l’ensemble de ses serveurs ainsi que des VM en cours d’ex´cution dans l’IaaS. e

Syst`me d’administration autonome adaptable : application au Cloud e

7.2. SAA POUR LE CLOUD

77

Langages d´di´s e e OpenNebula ne fournit aucune facilit´ langage pour l’expression des politiques e d’administration. L’administrateur doit avoir une bonne comp´tence en programe mation syst`me Linux et Java. e

7.2.2

Eucalyptus

Description g´n´rale 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 l’universit´ de Californie, ` e Santa Barbara. Il permet d’ex´cuter 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 l’IaaS de fa¸on hi´rarchique : les machines au niveau des feuilles, c e les clusters (groupe de machines) au niveau interm´diaire et le cloud (ensemble de e clusters) a la racine. Son fonctionnement est organis´ de la mˆme fa¸on. Il associe a ` e e c ` chaque niveau de l’IaaS un composant pr´cis (figure 7.4) : e – Instance Manager (IM) : il s’ex´cute sur chaque machine de l’IaaS. Il a pour e rˆle de g´rer le cycle de vie des VM. o e – Group Manager (GM) : il se trouve a la tˆte d’un cluster. Il collecte les infor` e mations des IM pr´sents sur les machines de son cluster. Il s’ex´cute sur une e e machine du cluster (pouvant ´galement h´berger un IM). e e – Cloud Manager (CM) : C’est le point d’entr´e du cloud (pour l’administrateur e et les clients). Il est reli´ aux diff´rents GM de l’IaaS. e e – Storage Controller (SC) : il g`re le stockage des images de VM. e – Warlus : serveur de stockage de donn´es des utilisateurs externes au cloud. e Il permet en quelque sorte au cloud d’ˆtre utilis´ comme centre de donn´es. e e e Notons que les donn´es qu’il stocke peuvent ˆtre utilis´es par des VM en cours e e e d’ex´cution (en fonction des propri´taires). e e

Figure 7.4 – Organisation d’Eucalyptus Interop´rable e Les API (de programmation) qu’offrent Eucalyptus permettent aux syst`mes e externes de le contacter. Par contre, un syst`me Eucalyptus n’est pas pr´vu pour e e
1. Une version commerciale d’Eucalyptus existe depuis 2009.

Syst`me d’administration autonome adaptable : application au Cloud e

7.2. SAA POUR LE CLOUD

78

initier la communication avec l’ext´rieur. La plupart de ces API sont compatibles e avec la plateforme de cloud Amazon EC2. Auto-R´parable e Eucalyptus ne met en place aucun moyen d’auto-r´paration de VM ou de ses e serveurs. Une panne de VM ne peut ˆtre constat´e que sur la demande du propri´taire e e e de la VM ou du fournisseur de l’IaaS par demande de l’´tat de la VM. e Extensible Comme OpenNebula, Eucalyptus permet l’extension de l’IaaS. Par contre, l’administrateur doit initialement installer sur la machine ` ajouter, tous les packages a Eucalyptus n´cessaires pour l’ex´cution de l’IM. En effet, contrairement ` OpenNee e a bula qui se charge de l’initialisation des machines ajout´es, Eucalyptus laisse cette e charge a l’administrateur. ` Programmable Aucune politique de consolidation de VM n’est mise en place par Eucalyptus. Il se limite uniquement au placement de VM pendant leur d´marrage (choix de la machine e d’ex´cution de la VM). De plus, ce placement est tr`s simpliste. En effet, lorsqu’un e e client demande l’ex´cution d’une VM dans un cluster, le GM de ce cluster choisit la e premi`re machine pouvant l’accueillir. Pour cela, il contacte ses IM s´quentiellement e e a la recherche de celui pouvant h´berger la VM. Il est pratiquement impossible pour ` e un non d´veloppeur Eucalyptus de modifier cette politique de placement. e Adaptable Malgr´ le discours autour de son adaptabilit´ et sa flexibilit´, il est difficile de les e e e mettre effectivement en œuvre dans Eucalyptus. Par exemple, apr`s une installation e d’Eucalyptus, la modification de la politique de copie d’images de VM n´cessitera e la r´installation des IM sur toutes les machines de l’IaaS. e Langages d´di´s e e A l’exception des commandes et des API d’utilisation du CM, aucun langage d´di´ n’est fourni par Eucalyptus pour faciliter son administration ou son utilisae e tion. Cependant, le pluging Hybridfox [Labs] peut ˆtre utilis´ sur le navigateur firee e fox [Mozilla] pour effectuer des fonctions de base comme l’allocation des machines VM, l’authentification, etc.

7.2.3

OpenStack

Description g´n´rale e e OpenStack [Inc.] est une pile d’outils open source pour la mise en place et l’administration d’une plateforme de cloud. Les principaux contributeurs de ce projet sont Rackspace [Rackspace] et la NASA [NASA]. Rackspace fournit les outils de gestion de fichiers dans le cloud tandis que la NASA apporte les outils de gestion de l’IaaS

Syst`me d’administration autonome adaptable : application au Cloud e

7.2. SAA POUR LE CLOUD

79

issus du syst`me Nebula [NASA] 2 . OpenStack s’organise autour de trois composants e et des API qui leur permettent de communiquer (figure 7.5) : – Compute Infrastructure (Nova) : Il fournit les fonctionnalit´s de gestion du e cycle de vie des VM (via le sous composant nova-compute), du r´seau (via e nova-network) et des authentifications. Il implante ´galement les programmes e de scheduling de VM ` travers son composant nova-Scheduler. Son sous coma posant Queue Server implante le m´canisme de dispatching de requˆtes aux e e autres sous composants en fonction des actions qu’elles requi`rent e – Storage Infrastructure (Swift) : il g`re le stockage de donn´es dans le cloud. Les e e donn´es sont stock´es de fa¸on redondante pour assurer de la tol´rance aux e e c e pannes. Compte tenu de son isolation dans l’architecture, nous ne le faisons pas figur´ dans la figure 7.5. e – Imaging Service (Glance) : g`re le stockage des images VM. e Notons que ces composants peuvent s’ex´cuter s´par´ment dans le cloud. e e e

Figure 7.5 – Organisation d’OpenStack

Interop´rable e Aucun m´canisme d’interop´rabilit´ ou de collaboration avec d’autres plateforme e e e n’est envisag´. e Auto-R´parable e Aucun m´canisme de r´paration n’est mis en place dans OpenStack. En effet, il e e n’implante aucun m´canisme de monitoring et de r´paration dans le cloud. e e Extensible Il est extensible dans la mesure o` l’ajout d’un nouveau nœud dans l’IaaS reu vient a y installer un composant nova-Compute sur ce nœud. La configuration de ` ce composant lui permettra de contacter les autres composants n´cessaires pour son e fonctionnement (Glance, nova-Network et nova-Scheduler) et ´galement de s’ins´rer e e
2. Ne ma confondre Nebula fourni par la NASA et OpenNebula.

Syst`me d’administration autonome adaptable : application au Cloud e

7.2. SAA POUR LE CLOUD

80

dans l’environnement l’IaaS. L’ajout/retrait de nœud ne n´cessite donc pas d’arrˆt 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 nœud al´atoirement dans la liste des nœuds de l’IaaS. La seconde politique e (availability zone) est similaire a la premi`re ` la diff´rence qu’elle se limite ` une ` e a e a zone/cluster de machines pr´cis´es a l’avance. La derni`re politique (simple) choisit e e ` e le nœud ayant la consommation courant la moins ´lev´e. e e Adaptable La construction modulaire d’OpenStack lui permet d’ˆtre adaptable. Par exemple, e le changement de la politique de gestion des configurations r´seaux dans les VM se e fait facilement en rempla¸ant le composant nova-Network. c Langages d´di´s e e Aucun langage particulier d’utilisation du cloud n’est fourni. Il se limite ` la a fourniture d’API et d’outils de ligne de commandes. Comme Eucalyptus, il supporte ´galement l’utilisation du pluging Hybridfox [Labs] du navigateur firefox [Mozilla] e pour effectuer des fonctions d’administration de base dans l’IaaS (comme la gestion du cycle de vie des images de VM et des VM, l’authentification, etc).

7.2.4

Microsoft Azure

Description g´n´rale e e Microsoft Azure [76] (que nous appellerons Azure) est une plateforme commerciale de cloud d´velopp´e par le groupe Microsoft. Il joue un double rˆle : accome e o pagnement des clients dans le processus d’externalisation, et gestion de l’IaaS (uniquement le syst`me de virtualisation Hyper-V [74]). Il est organis´ autour de quatre e e composants principaux : – AppFabric : il r´alise le premier rˆle de la plateforme. C’est la plateforme de d´e o e veloppement des applications entreprises qui seront externalis´es vers le cloud. e Les applications issues de cette plateforme seront facilement administr´es dans e l’IaaS. Il correspond au SAA de niveau entreprise. C’est grˆce a l’AppFabric a ` que la plateforme Azure est consid´r´e dans la litt´rature comme un PaaS. ee e – Windows Azure : il r´alise le second rˆle de la plateforme. C’est lui qui d´ploie e o e et ex´cute les VM dans l’IaaS (grˆce a son composant FrabricController con¸u e a ` c pour le syst`me de virtualisation Hyper-V). e – SQL Azure : C’est le syst`me de gestion de base de donn´es d’Azure. e e – Marketplace : C’est une plateforme de vente et d’achat de composants logiciels d´velopp´s sur AppFabric. En effet, dans le but de faciliter les d´velope e e pements sur AppFabric, les clients peuvent se procurer des briques logiciels pr´-d´velopp´es et mises en vente sur Marketplace. e e e

Syst`me d’administration autonome adaptable : application au Cloud e

7.2. SAA POUR LE CLOUD

81

Les facilit´s d’administration fournies par Azure se limitent aux applications (appee l´es ”rˆle 3 ” dans Azure) web de type n-tiers. En effet, le composant AppFrabric ne e o permet que le d´veloppement de ce type d’applications. Cependant, il est capable e d’h´berger d’autres types d’applications directement fournies dans des VM (appel´e e e rˆle VM). Dans ce cas, la charge est laiss´e au client de construire et soumettre au o e cloud les VM contenant ses logiciels. Quant aux applications construites via AppFrabric, l’IaaS prend en charge la construction des VM devant les h´berger. La figure 7.6 e r´sume la vue g´n´rale de Microsoft Azure. e e e

Figure 7.6 – Vue g´n´rale de Microsoft Azure e e Interop´rable e Azure ne dispose d’aucune interface de collaboration avec d’autres plateformes de cloud : ni d’Azure vers l’ext´rieur, ni de l’ext´rieur vers Azure. Il pourrait s’agir e e d’une strat´gie de Microsoft empˆchant les autres plateformes de cloud de conqu´rir e e e ses clients. Cependant, Azure dispose des m´canismes de collaboration interne entre e le gestionnaire de l’IaaS (Windows Azure) et le gestionnaire des applications entreprises (AppFabric). En effet, l’AppFabric s’adresse au composant Windows Azure (gestionnaire de l’IaaS) pour la cr´ation de VM, l’obtention des informations de moe nitoring, etc. Cette collaboration est cˆbl´e et maˆ ee par les deux composants a e ıtris´ Windows Azure et AppFabric. Auto-R´parable e L’auto-r´paration est uniquement fournie pour les VM construites par l’IaaS. e Autrement dit, il s’agit des VM ex´cutants les applications issues de AppFabric. e Dans ce cas, l’IaaS duplique l’ex´cution des logiciels en d´marrant deux instances de e e
3. terme utilis´ par Windows Azure pour d´signer les ´l´ments qu’il administrent e e ee

Syst`me d’administration autonome adaptable : application au Cloud e

7.2. SAA POUR LE CLOUD

82

VM pour chacun d’eux (la VM suppl´mentaire prend le relais si la premi`re tombe e e en panne). Toutes les op´rations d’´critures sont effectu´es dans un emplacement e e e r´pliqu´ partag´ ne se trouvant par sur les VM. De cette fa¸on, lorsqu’une instance e e e c de VM est en panne, Windows Azure le red´marre ` partir de son ´tat d’avant la e a e panne. Quant aux VM construites par le client, c’est a ce dernier d’implanter les m´ca` e nismes d’auto-r´paration. e Extensible Nous n’avons aucune possibilit´ d’´tudier cette facette d’Azure car elle est proe e pri´taire et sa gestion interne est inconnue. e Programmable Aucune politique de consolidation des machines virtuelles sur l’IaaS n’est mise en place dans Azure. Par contre, il propose des politiques de scalabilit´ pour les applie cations clientes sous son contrˆle (c-`-d issues de AppFabric). Elles sont d´clench´es o a e e via des API par les applications elles-mˆmes ou par leur propri´taire. Cependant, il e e est impossible d’introduire de nouvelles politiques de reconfiguration dans une application issues de AppFrabric). En ce qui concerne la configuration des applications directement construites dans les VM par le client, Azure permet l’implantation de programme (adapters) permettant de les r´aliser. Ces programmes sont associ´s a la VM et s’ex´cutent a son e e ` e ` d´marrage. e Adaptable Nous n’avons aucune possibilit´ d’´tudier cette facette d’Azure car elle est proe e pri´taire et son code source est inaccessible. e Langages d´di´s e e Microsoft Azure fournit ` travers sa plateforme de d´veloppement des langages a e et API de d´veloppement d’applications pour son cloud. Ces langages sont des lane gages classiques de d´veloppement (java, .Net et C#) et du XML. Le d´veloppement, e e l’assemblage, l’interconnexion des composants logiciels ainsi que leur configuration s’effectuent par programmation dans AppFabric. Pour les applications non issues de AppFabric, il fournit un outil (Hyper-V Manager ) de construction et de t´l´chargement d’images de VM vers le cloud. Il utilise ee 4 le format Virtual Hard Disk (VHD) pour la description de l’image a construire. ` Ce format est bas´ sur XML et permet de d´crire le contenu de l’image de VM a e e ` construire.
4. VHD est chez Microsoft ce qu’est OVF (Open Virtual Format) chez VMWare.

Syst`me d’administration autonome adaptable : application au Cloud e

` 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 n´es, espace de calculs pour les applications scientifiques ou comme centre d’h´bere e gements d’applications orient´es web. Pour ces deux derniers services, le client doit e se servir de machines virtuelles. Il ex´cute des VM d’OS de type Linux ou Windows. e Son infrastructure mat´rielle est r´partie sur plusieurs zones g´ographiques (deux e e e zones aux USA, une zone en Europe et une zone en Asie) afin de proposer aux clients des lieux d’ex´cution proches. Cette pratique permet ´galement ` Amazon de e e a minimiser les communications r´seaux avec l’IaaS. e En ce qui concerne l’assistance aux clients, Amazon fournit des services web d’observation de charges des VM. Pour des applications web de type J2EE, il fournit des politiques de passage a l’´chelle (scalabilit´). Par contre, il ne pratique aucune po` e e litique de consolidation de VM au niveau de l’IaaS. Pour finir, Amazon n’implante pas de m´canisme de d´pannage de VM. Il revient au client de l’implanter. e e RightScale RightScale [RIGHSCALE] est pr´sent´ dans la litt´rature et par ses fournisseurs e e e comme ´tant une plateforme de cloud. En r´alit´, il permet de pr´senter de fa¸on e e e e c uniforme l’acc`s a plusieurs plateforme de cloud. En effet, il est reli´ ` plusieurs e ` e a v´ritables plateformes de cloud (Amazon EC2 par exemple) dont il peut effectuer e des r´servations de VM. e Le principal apport de RightScale est sa facilitation du processus d’externalisation de l’entreprise vers le cloud. Cette facilitation se limite aux applications web de type J2EE. Il implante toutes les fonctions d’administration au niveau entreprise telles que nous les avons pr´sent´es dans la section 3.2 du chapitre 3. Il fournit des e e moyens de construction de VM, t´l´chargement d’images VM vers le cloud, d´ploieee e ment de serveurs J2EE, r´paration de VM et de serveurs J2EE, passage a l’´chelle e ` e des tiers J2EE et monitoring des VM.

7.3

Synth`se e

L’´tude des travaux autour de la construction de SAA montre qu’il existe tr`s e e peu d’´tudes qui s’int´ressent ` l’administration d’applications appartenant a des e e a ` domaines tr`s vari´s. La plupart d’entre elles sont sp´cifiques ` un domaine voir e e e a une application particuli`re. L’´tude du syst`me Rainbow [55] (section 7.1.1), qui se e e e r´clame de la cat´gorie des SAA g´n´riques et flexibles, s’est r´v´l´e non concluante. e e e e e ee En effet, la partie du syst`me qu’il d´finit comme adaptable ne concerne que les e e effecteurs, les sondes et les ´l´ments du SR. Or, ces ´l´ments ne correspondent pas ee ee aux composants de base constituants le SAA, qui d´terminent le degr´ d’adaptabilit´ e e e d’un SAA. Syst`me d’administration autonome adaptable : application au Cloud e

` 7.3. SYNTHESE

84

Face a ce constat, il est difficile d’envisager l’application de ces syst`mes dans le ` e cadre de l’administration des plateformes de cloud, notre pr´occupation initiale. e Par ailleurs, nous avons pass´ en revue les plateformes de cloud et ´tudi´ leur cae e e pacit´ d’administration autonome. Le principale constat qui d´coule de cette ´tude e e e est l’absence de la prise en compte (par ces plateformes de cloud) de la collaboration entre les syst`mes d’administration des applications entreprises et le syst`me e e d’administration de l’IaaS. Dans le chapitre suivant, nous pr´sentons donc l’implantation d’un SAA suivant e les directives que nous avons identifi´es dans le chapitre pr´c´dant. Comme nous le e e e verrons, il sera par la suite utilis´ pour l’administration d’une plateforme de cloud (un e prototype que nous implanterons ´galement) ainsi que des applications entreprises e qu’ex´cutera cette plateforme. Pour finir, la collaboration entre les deux niveaux sera e favoris´e par cette uniformit´ des SAA de niveaux IaaS et applications entreprises. e e

Syst`me d’administration autonome adaptable : application au Cloud e

Chapitre 8 Contributions : TUNeEngine
Contents
8.1 Mod`le d´taill´ de TUNeEngine . . . . . . . e e e 8.1.1 Soumission de commandes et Collaboration . 8.1.2 Construction du SR . . . . . . . . . . . . . . 8.1.3 D´ploiement . . . . . . . . . . . . . . . . . . e 8.1.4 Configuration, D´marrage . . . . . . . . . . . e 8.1.5 R´configuration . . . . . . . . . . . . . . . . . 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 D´ploiement . . . . . . . . . . . . . . . . . . e 8.3.5 Ex´cution de programmes d’administration . 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´ pr´curseurs en e ee e ce qui concerne le d´veloppement des SAA ` vocation g´n´rique. Cependant, les e a e e difficult´s observ´es dans l’utilisation de ces syst`mes nous ont conduit ` proposer e e e a dans le chapitre 6, une nouvelle approche d’implantation de SAA hautement flexible et adaptable. Cette approche identifie les besoins que doit remplir un tel syst`me. e Elle d´bouche ensuite sur un mod`le architecturale bas´ sur les composants. Dans e e e ce chapitre nous pr´sentons une implantation de ce mod`le que nous baptisons : e e TUNeEngine. Reprenant la base de code de TUNe, l’implantation de TUNeEngine est bas´ sur e le formalisme a composants 1 Fractal [31]. `
1. Afin d’´viter toute ambigu¨ e de compr´hension avec le mod`le que nous pr´sentions e ıt´ e e e dans le chapitre 6, nous n’utilisons pas l’expression ”mod`le ` composants Fractal” mais e a plutˆt ”formalisme ` composants Fractal”. o a

` ´ ´ 8.1. MODELE DETAILLE DE TUNEENGINE

86

Figure 8.1 – Mod`le d´taill´ de TUNeEngine e e e Ce chapitre est organis´ de la fa¸on suivante. Nous commen¸ons par la pr´sentae c c e tion du mod`le architectural d´taill´ de TUNeEngine. Ce mod`le est un enrichissee e e e ment de celui que nous avons pr´sent´ dans le chapitre 6. Ensuite, nous pr´sentons e e e de fa¸on succincte un aper¸u du formalisme Fractal sur lequel est bas´ l’implantation c c e de TUNeEngine. Nous terminons ce chapitre par la pr´sentation de l’implantation e Fractal du mod`le d´taill´ de TUNeEngine. e e e

8.1

Mod`le d´taill´ de TUNeEngine e e e

Dans la section 6.2.2 du chapitre 6, nous avons pr´sent´ le mod`le architectural e e e que devra suivre l’implantation de TUNeEngine. Nous le revisitons en l’enrichissant des composants les plus basiques que doit implanter TUNeEngine. La figure 8.1 pr´sente ce nouveau mod`le enrichi. Afin de justifier les composants de ce mod`le, e e e explorons le processus d’administration d’une application quelconque par un SAA. Ce processus va de la soumission de l’application a administrer au SAA, jusqu’au ` suivi de son ex´cution en passant par son d´ploiement. Notons que l’exploration de e e ce processus nous sert uniquement de fil conducteur dans notre pr´sentation. e

Syst`me d’administration autonome adaptable : application au Cloud e

` ´ ´ 8.1. MODELE DETAILLE DE TUNEENGINE

87

8.1.1

Soumission de commandes et Collaboration

La premi`re ´tape dans le processus d’administration autonome est la soumission e e des politiques d’administration au SAA par l’administrateur ou un syst`me externe. e Ces politiques contiennent aussi bien la description des ´l´ments ` administrer (maee a chines et logiciels) que les politiques de reconfiguration. De plus, le SAA peut initier la communication avec l’ext´rieur dans certaines situations. Par exemple lorsqu’il e sollicite, par collaboration, les services d’un SAA externe pour l’accomplissement d’une tˆche. En conclusion, on peut parler d’un dialogue entre un acteur externe a (un administrateur ou un SAA) et le SAA. Le composant External Communicator de notre mod`le permet de r´aliser ce dialogue. e e En fonction du type de dialogue, l’External Communicator s’appuie sur deux composants internes : l’Interface de Ligne de Commandes (CLI) et le Collaborator . Le premier s’occupe de la communication avec des acteurs humains tandis que le second s’occupe de la collaboration/interop´rabilit´ avec d’autres SAA. e e Les commandes ´mises/re¸ues sont de diff´rents ordres. Il peut s’agir de la soue c e mission au SAA de l’environnement a administrer, des politiques d’administration ` a appliquer, des ordres de d´ploiement/und´ploiement, etc. Pour distinguer ces re` e e quˆtes, le composant External Communicator est muni d’un interpr´teur de e e commandes (CmdInterpreter ). Ce dernier a ´galement pour rˆle de v´rifier la ` e o e conformit´ syntaxique et s´mantique des commandes (autrement dit si elles seront e e compr´hensibles par le SAA). En cas de conformit´, le CmdInterpreter fait appel e e au composant du SAA capable de r´aliser l’op´ration contenue dans la commande : e e la construction du SR par exemple. Adaptabilit´ e L’adaptation du composant Collaborator peut permettre au SAA d’implanter un nouveau protocole de communication avec les SAA externes. Dans le cadre de l’implantation de TUNeEngine par exemple, nous utilisons un m´canisme 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 d’implanter par exemple une collaboration ` base du protocole REST tels que pratiqu´es dans les a e plateformes de cloud comme Eucalyptus ou OpenNebula. L’adaptation du composant CmdInterpreter permet de modifier la syntaxe de soumission des commandes au SAA. Au lieu d’une soumission de commandes ligne pas ligne, le SAA pourra permettre l’expression de plusieurs commandes sur la mˆme e ligne et s´par´es par des points virgules par exemple. e e

8.1.2

Construction du SR

Une fois les ´l´ments a administrer soumis au SAA, celui-ci doit construire en ee ` son sein une repr´sentation de ces ´l´ments : c’est le rˆle du SR Manager dans e ee o notre mod`le. Il s’appuie sur trois sous composants : le Parser , le Wrapper et le e Syst`me d’administration autonome adaptable : application au Cloud e

` ´ ´ 8.1. MODELE DETAILLE DE TUNEENGINE

88

SR. Le Parser a pour rˆle d’identifier a partir de la soumission de l’administrateur : o ` la liste des ´l´ments a administrer par le SAA, leurs propri´t´s, ainsi que les relations ee ` ee entre eux. Il peut ˆtre organis´ en plusieurs Parser s afin de prendre ´galement en e e e compte les ´l´ments comme les programmes d’administration. Pour chaque ´l´ment ee ee identifi´, le Parser demande au Wrapper de construire le repr´sentant de cet ´l´e e ee ment dans le SAA. Construire le repr´sentant d’un ´l´ment dans le SAA signifie encapsuler son e ee comportement dans une structure de donn´es qui facilitera son administration par e le SAA. Nous appelons ´galement wrapper ce repr´sentant. Pour le construire, le e e Wrapper utilise les informations fournies par le Parser . Les ´l´ments construits ee peuvent ˆtre des logiciels, des machines, des liaisons, des ´l´ments constituant un e ee programme de reconfiguration, etc. Nous proposons dans notre mod`le, l’utilisae 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 l’adaptabilit´ e du Wrapper . En effet, construire un repr´sentant 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 r´alit´, le choix port´ sur Fractal est favoris´ e e e e e par ses API qui r´pondent parfaitement a nos attentes dans la construction des ree ` pr´sentants. Notons que l’implantation du Wrapper d´cidera du cˆblage ou non e e a des types d’´l´ments dans le SAA (voir le crit`re d’uniformisation de la section 6.1.1 ee e du chapitre 6). Dans le cadre du syst`me TUNeEngine, nous utilisons (comme nous e l’avons pr´conis´e) une unique structure de donn´es pour l’encapsulation de tout e e e type d’´l´ments. ee Pour finir, le SR dans notre mod`le joue deux rˆles. Il repr´sente d’une part e o e la structure de donn´es contenant l’ensemble des repr´sentants des ´l´ments admie e ee nistr´s et programmes de reconfiguration dans le SAA. Nous reprenons l’expression e de ”Syst`me de Repr´sentation” introduit par le syst`me TUNe pour le d´signer. e e e e D’autre part, il fournit le moyen d’introspection des wrappers et du syst`me de e repr´sentation. Il sera sollicit´ par les autres composants du SAA lorsqu’ils voue e dront avoir des propri´t´s, des fonctions ou autres informations du repr´sentant. Par ee e exemple, le Wrapper fera appel ` lui pour l’obtention de la r´f´rence Fractal des a ee wrappers de deux ´l´ments lors de la construction d’une liaison ces deux ´l´ments. ee ee Adaptabilit´ e L’adaptation du Parser permet au SAA de prendre en compte de nouveaux langages de description des besoins d’administration (´l´ments et programmes de reee configuration). On pourra par exemple prendre en compte l’ADL 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 l’adminis` trateur d’exprimer un nouveau moyen d’encapsulation dans le SAA ou d’associer un comportement particulier ` un repr´sentant d’un ´l´ment administr´. Pour illustrer a e ee e le premier cas, prenons un exemple dans lequel l’administrateur d´sire encapsuler ses e ´l´ments dans une base de donn´es. Compte tenu du fait que nous adoptons Fractal ee e

Syst`me d’administration autonome adaptable : application au Cloud e

` ´ ´ 8.1. MODELE DETAILLE DE TUNEENGINE

89

comme la base de construction de wrappers dans le SAA (ce qui n’empˆche l’utilisae tion d’autres moyens), l’adaptation du Wrapper construira donc deux wrappers : un composant Fractal et une entr´e dans la base de donn´es. Associ´ a cette adaptae e e` tion du Wrapper , le composant SR devra ˆtre ´galement adapt´. En effet, il devra e e e associer aux API d’introspection des composants Fractal (ce que permet Fractal) le moyen d’acc´der aux informations concernant ` la fois le composant Fractal lui mˆme e a e (le wrapper de base), mais ´galement l’entr´e correspondant a ce composant dans e e ` la base de donn´es (nouvelle structure d’encapsulation). En somme, l’utilisation de e Fractal dans notre mod`le sert d’interfa¸age lorsque que la m´thode d’encapsulation e c e est adapt´e. e Quant au second cas (l’adaptation du Wrapper pour l’association d’un comportement particulier a un ´l´ment), il permet par exemple de reproduire le choix ` ee d’implantation du syst`me TUNe dans lequel il associe aux supports d’ex´cution e e (machines physiques), un comportement diff´rent de celui des ´l´ments logiciels. La e ee seul diff´rence ici est le non cˆblage de cette diff´rence dans le SAA. e a e Pour finir, l’adaptation du SR permet, comme nous l’avons ´voqu´ dans l’adape e tation du Wrapper , d’enrichir les API d’introspection de Fractal.

8.1.3

D´ploiement e

Apr`s la repr´sentation interne des ´l´ments administr´s, la phase de d´ploiement e e ee e e marque le d´but du processus d’administration proprement dit. Il est assur´ par le e e composant Deployment Manager . Ce dernier r´alise le d´ploiement en plusieurs e e phases internes a savoir : ` – le choix du support d’ex´cution (SE) : r´alis´ par le composant NodeAllocae e e tor . Il d´termine le lieu d’ex´cution de l’´l´ment en cours de d´ploiement. Il e e ee e se sert du SR afin d’avoir les informations sur les SE disponibles et retourne ensuite un ou plusieurs SE en fonction des besoins de l’´l´ment d´ploy´. ee e e – initialisation du SE : a l’aide d’un moyen (ssh, rsh, etc.) et des informations ` (nom de connexion, mot de passe, etc.) de connexion fourni par le repr´sentant e du SE dans le SR, le composant Deployer initialise le SE. Cette initialisation permet au SAA d’avoir acc`s et main mise sur le SE distant. e – L’obtention et l’installation des binaires : r´alis´es par le composant Binary e e Manager , il rend disponible les binaires et fichiers n´cessaires pour l’ex´cution e e de l’´l´ment d´ploy´ sur le SE distant (exemple de l’installation des packages ee e e sous Linux dans le r´pertoire /var/cache/apt/archives/ ). Il dispose ensuite les e fichiers selon l’arborescence requise par l’installation de l’´l´ment en cours de ee d´ploiement (dans l’exemple des packages Linux, il s’agit du d´sarchivage des e e fichiers vers les r´pertoires requis). e A l’inverse, notons que les composants pr´c´demment pr´sent´s r´alisent ´galement e e e e e e l’op´ration de d´sinstallation. Le NodeAllocator lib`re le SE apr`s son nettoyage e e e e par le Binary Manager . Adaptabilit´ e

Syst`me d’administration autonome adaptable : application au Cloud e

` ´ ´ 8.1. MODELE DETAILLE DE TUNEENGINE

90

L’adaptation du NodeAllocator permet d’implanter plusieurs politiques d’allocation ou de lib´ration de SE dans le SAA. Par exemple, on pourra implanter e l’allocation par tourniquet ou round-robin utilis´e par le syst`me TUNe. e e Quant au Deployer , prenons l’exemple de l’administration des ´quipements e r´seaux comme les imprimantes. L’adaptation du Deployer permettra de ne pas e d´ployer le repr´sentant du SAA sur l’´quipement r´seau (car impossible) comme e e e e on le fera dans le cadre de l’administration d’une machine physique. Dans ce cas, le Deployer pourra par exemple se contenter d’un d´ploiement de ce repr´sentant e e sur la machine d’administration, qui fera par la suite un contrˆle distant selon le o protocole de communication fourni par l’´quipement. e Pour finir, l’adaptation du Binary Manager permettra au SAA de prendre en compte diff´rentes m´thodes d’obtention de binaires : par copie distant, par t´e e e l´chargement web comme c’est le cas avec l’installation des syst`me d’exploitation, e e etc.

8.1.4

Configuration, D´marrage e

´ Les phases de configuration et de d´marrage suivent celle du d´ploiement. Etant e e donn´ qu’elles sont de mˆme nature (ex´cution de programme), le SAA utilise le e e e mˆme composant (Policies Manager ) pour les r´aliser. Il se met en marche lorse e qu’il re¸oit un ordre venant de l’External Communicator ou de l’Event Mac nager . L’ex´cution d’un programme d’administration s’effectue en deux ´tapes : e e – l’interpr´tation du programme : r´alis´e par le composant ProgramInterpree e e ter . Ce dernier utilise une partie du SR repr´sentant le programme ` ex´cuter. e a e Il identifie dans le programme la liste des actions a ex´cuter. Son implantation ` e d´pendra du langage d’administration choisi par l’administrateur. e – l’ex´cution des actions identifi´es dans l’´tape pr´c´dente : les actions identie e e e e fi´es sont ex´cut´es par le composant Executor . Pour chaque action, l’Executor e e e introspecte le SR a la recherche est ´l´ments concern´s par l’action. Il fait ` ee e ensuite appel au composant RemoteExecutor qui implante le moyen d’ex´e cution a distante des actions sur le logiciel ou le SE dans l’environnement r´el. ` e

Adaptabilit´ e L’adaptation du ProgramInterpreter permet de changer le langage d’expression des programmes de reconfiguration. On pourra ainsi avoir des programmes JAVA ou encore un langage tel que RDL du syst`me TUNe. e L’adaptation de l’Executor permet par exemple d’implanter une m´thode d’ex´e e cution d’action dans laquelle le lieu d’ex´cution des actions est soit local (sur la e machine d’administration), soit distant (sur le SE du logiciel concern´). En effet, des e actions contenues dans les programmes de reconfiguration peuvent concern´es des e modifications de l’architecture du SR. Dans ce cas, ces actions doivent ˆtre r´alis´es e e e sur la machine d’administration (car c’est elle qui contient le SR). Syst`me d’administration autonome adaptable : application au Cloud e

` ´ ´ 8.1. MODELE DETAILLE DE TUNEENGINE

91

Pour finir, l’adaptation du RemoteConnector permet de changer le m´cae nisme d’ex´cution a distance des fonctions d’administration. Il pourra utiliser du e ` RMI comme c’est le cas dans TUNe ou encore une ex´cution basique bas´e sur un e e appel de commandes a distance avec du SSH. `

8.1.5

R´configuration e

Apr`s le d´marrage des ´l´ments, la suite de l’administration consiste en leur e e ee suivi dans le but d’avertir le SAA de leur ´tat courant. La r´alisation de cette tˆche e e a n’appartient pas au SAA. En effet, elle d´pend de l’implantation de chaque ´l´ment e ee administr´ (vu comme une boˆ noire). Il revient donc a l’administrateur d’introe ıte ` duire parmi les ´l´ments ` administrer, des logiciels (observateurs) qui joueront ce ee a rˆle. Les ´l´ments administr´s (y compris les observateurs), ont la mˆme consid´rao 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 ´l´ment administr´ et lui. ee e Dans cette situation, la communication est initi´e par l’´l´ment administr´. Elle e ee e s’effectue de son support d’ex´cution (SE) vers la machine d’ex´cution du SAA. e e Le composant Event Receiver est charg´ d’implanter ce m´canisme de commue e nication. Il est compos´ de deux sous composants : l’Event Channel et l’Event e Driver . Le premier est utilis´ par l’´l´ment administr´, s’ex´cutant sur son SE, e ee e e pour ´mettre ses ´v´nements. Le second implante la m´thode de transport d’´v´nee e e e e e ments des SE de l’environnement vers la machine d’administration. L’Event Driver communique l’´v´nement re¸u au niveau de la machine d’administration a l’Event e e c ` Manager . Ce dernier implante le module d´cisionnel du SAA. Son rˆle est de choie o sir en fonction des ´v´nements re¸us, les programmes d’administration ` ex´cuter e e c a e pour r´pondre aux signes ´mis par l’environnement encours d’administration. Pour e e cela, il s’appuie sur l’´tat courant du SR. Apr`s d´cision des programmes de recone e e figuration a ex´cuter, l’Event Manager fait appel au Policies Manager pour ` e leur ex´cution. Le proc´d´ d’ex´cution celui que nous avons d´cri dans la section e e e e e pr´c´dente. e e Adaptabilit´ e L’adaptation de l’Event Channel permet de modifier la m´thode d’obtention e d’´v´nements ` partir de l’ex´cution d’un ´l´ment sur son SE. e e a e ee Quant ` l’Event Driver , son adaptation permet d’implanter par exemple le a m´canisme de transport d’´v´nements par le biais d’un serveur de messages tel que e e e JMS. Ainsi, l’Event Manager s’abonnera au serveur JMS afin d’ˆtre inform´ des e e ´v´nements survenus. e e Pour finir la modification de l’Event Manager permettra a l’administrateur ` de produire un m´canisme de gestion des ´v´nements avanc´ comme la technologie e e e e CPE [71] (Complex Event Processing). Par exemple, il pourra prendre prendre en compte des ´v´nements estampiller de l’instant d’envoie d’apparition de l’´v´nement e e e e afin de g´rer des ´v´nements temporels. Ceci lui permet par exemple d’implanter e e e

Syst`me d’administration autonome adaptable : application au Cloud e

` 8.2. LE FORMALISME A COMPOSANTS FRACTAL

92

diverses m´thodes de stockage ou d’apprentissage du comportement de l’application e en cours d’administration.

8.2

Le formalisme ` composants Fractal a

Comme nous l’avons ´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 contrˆleurs [32]. Un composant est une o entit´ ex´cutable. Fractal distingue deux types de composants : les composants prie e mitifs et les composants composites. Les composants primitifs encapsulent une unit´ e ex´cutable d´crite 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 d’acc`s ou de sortie sur un composant. Fractal introe duit en effet deux cat´gories d’interfaces : e – Interface serveur : il s’agit d’un point d’acc`s au composant. Un composant e d´finissant une ”interface serveur” implique que ce composant fournit les sere vices implant´s par cette interface. Dans le cas d’un composant primitif, le e code source du composant doit contenir l’implantation de l’interface. Quant aux composites, Fractal ne permet pas de leur associer des codes sources. – Interface cliente : il s’agit d’un point de sortie du composant. Un composant d´finissant une ”interface cliente” signifie que ce composant requiert les services e implant´s par cette interface. Ainsi, l’ex´cution de ce composant n´cessite au e e e pr´alable 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 n’est visible que des composants interne au composite : on parle d’interfaces compl´mentaires (voir la figure 8.2(a)). Ces derni`res e e peuvent ˆtre li´es aux interfaces des composants internes. e e Une liaison est un canal de communication ´tabli entre les composants Fractal. e De la mˆme fa¸on que les composants, Fractal distingue deux types de liaisons : prie c mitives et composites. Une liaison primitive est une liaison entre deux composants du mˆme espace d’adressage (contenu dans le mˆme composite) via leurs interfaces e e cliente et serveur. Ce type de liaison est implant´e par des pointeurs ou des m´cae e nismes propres au langage de programmation comme les r´f´rences Java. Une liaison ee composite est une liaison implant´e 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 li´e ` plusieurs interfaces serveurs. e e a Les contrˆleurs constituent la membrane des composants. Ils ont pour rˆles d’exo o poser les services du composant, d’intercepter les messages en direction du compoSyst`me d’administration autonome adaptable : application au Cloud e

` 8.2. LE FORMALISME A COMPOSANTS FRACTAL

93

Figure 8.2 – Exemple d’architecture Fractal sant et ´galement d’introspecter le composant. Fractal n’impose pas d’implantation e pour la d´finition des contrˆleurs, ce qui permet d’exercer un contrˆle adapt´ sur e o o e les composants. Cependant, il fournit quelques exemples de contrˆleurs utiles qui o peuvent ˆtre combin´s et ´tendus : e e e – Le contrˆleur d’attributs (AttributeController ) : il permet de configurer les o attributs d’un composant. – Le contrˆleur de liaisons (BindingController ) : il permet d’´tablir ou de o e rompre une liaison primitive a partir du composant d´finissant l’interface ` e cliente. – Le contrˆleur de contenu (ContentController ) : il permet de lister, d’ajouter o et de retirer des sous-composants d’un composant composite. – Le contrˆleur de cycle de vie (LifeCycleController ) : il permet de contrˆler o o le cycle de vie du composant qui poss`de le contrˆleur. Le cycle de vie d’un e o composant est repr´sent´ par un automate a deux ´tats : started (le composant e e ` e est dans un ´tat d´marr´) et stopped (le composant est dans un ´tat d’arrˆt). e e e e e Le contrˆleur permet de passer d’un ´tat ` l’autre. Il est le principal artisan o e a dans les op´ration de d’ajout/retrait de composants d’une architecture d´j` en e ea cours d’ex´cution. e La figure 8.2 d´crit les diff´rentes entit´s mises en jeu dans une architecture e e e Fractal. Le rectangle noir repr´sente le contrˆle du composant alors que l’int´rieur e o e du rectangle repr´sente le contenu du composant. Les fl`ches correspondent aux e e liaisons tandis que les formes en ”T” attach´es aux rectangles correspondent aux e interfaces du composant. Les interfaces de contrˆle sont repr´sent´es par des lettres : o e e ”c” pour composant, ”lc” pour le contrˆleur de cycle de vie, ”bc” pour le contrˆleur de o o liaisons, ”cc” pour le contrˆleur de contenu et ”ac” pour le contrˆleur d’attributs. Les o o interfaces serveurs (respectivement cliente) sont dispos´es a gauche (respectivement e ` a droite) du rectangle noir. ` L’application d´crite dans la figure 8.2 se compose de deux composants primitifs : e Client et Server. Ces composants sont li´s par une liaison entre une interface client e s du composant ”Client” et une interface serveur s du composant ”Serveur ”.

Syst`me d’administration autonome adaptable : application au Cloud e

8.3. IMPLANTATION DE TUNEENGINE

94

8.3

Implantation de TUNeEngine

Comme nous l’avons ´voqu´e en pr´ambule de ce chapitre, l’implantation de e e e TUNeEngine utilise Fractal (l’implantation 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 ´l´ments administr´s. De fa¸on g´n´rale, tous e ee e c e e les composants primitifs d´finissent une interface de gestion d’attributs (ou parae m`tres). Cette interface ´tend l’interface AttributeController pr´d´finie par Fractal. e e e e TUNeEngine s’ex´cute sur une machine que nous appellerons la machine d’ade ministration. C’est ` partir de cette machine qu’il coordonnera toutes les op´rations a e d’administration. Dans ce chapitre, nous pr´sentons l’implantation TUNeEngine du mod`le d´taill´ e e e e que nous avons pr´sent´ ci-dessus.Compte tenu du caract`re adaptable de notre moe e e d`le, l’implantation de ses composants dans cette version de TUNeEngine permet e de r´aliser toutes les op´rations d’administration que permettait le syst`me TUNe. e e e Dans un premier temps, nous pr´sentons l’implantation du composant composite e TUNeEngine. Ensuite, suivant le mˆme fil conducteur que celui adopt´ dans la sece e tion 8.1, nous pr´sentons l’implantation de chaque composant de TUNeEngine. Pour e illustration, nous associerons ` chaque section (si n´cessaire) une figure r´sumant la a e e pr´sentation faite dans la dite section. Cette figure pr´sentera le contenu du come e posite TUNeEngine conform´ment a la pr´sentation, associ´ parfois au contenu de e ` e e l’environnement r´el d’ex´cution. Par souci de lisibilit´, la figure associ´e a une sece e e e ` tion X ne reprendra pas obligatoirement tous les ´l´ments des figures des sections ee qui lui pr´c`dent. e e

8.3.1

Le composant TUNeEngine

L’ensemble des composants du syst`me TUNeEngine sont contenus au sein d’un e composant composite appel´ TUNeEngine. Ce dernier est vu de l’ext´rieur comme e e le syst`me TUNeEngine. Il d´finit deux interfaces serveurs. La premi`re g`re les e e e e param`tres d’ex´cution du SAA. Cette interface est une extension de l’interface Ate e tributeController 2 que fournit Fractal. Ces param`tres seront ensuite utilis´s pour e e l’initialisation des composants internes de TUNeEngine. En effet, compte tenu de son statut de repr´sentant de TUNeEngine, son d´marrage entraˆ e e ınera celui de ses sous-composants. Or ces derniers ont besoin de certains param`tres pour leur initialie sation. C’est le cas par exemple du composant CLI qui requiert pour son d´marrage e le niveau de verbosit´ indiquant le degr´ de d´tails avec lequel TUNeEngine doit r´e e e e pondre aux requˆtes des administrateurs. e La deuxi`me interface est le d´marreur de TUNeEngine. Elle d´marre tous les e e e composants de services et ne rend la main qu’` l’arrˆt de ces derniers. Compte tenu a e
2. En effet, l’interface de contrˆle AttributeController n’est pas pr´d´finie dans Fractal o e e pour les composites

Syst`me d’administration autonome adaptable : application au Cloud e

8.3. IMPLANTATION DE TUNEENGINE

95

de son caract`re de composant composite, TUNeEngine contient un composant prie mitif TUNeEngineDelegate qui impl´mente r´ellement ses deux interfaces serveurs. e e Ce composant est reli´ a tous les autres sous-composants de TUNeEngine afin de e` leur communiquer leurs param`tres d’initialisation. e Le composant TUNeEngineDelegate est implant´ par une classe Java d´finissant e e une interface AttributeController et Thread.

8.3.2

Soumission de commandes et Collaboration

L’implantation du composant CLI dans TUNeEngine obtient les requˆtes de e l’administrateur via une socket r´seau et fournit les r´sultats via une console locale. e e Les param`tres d’initialisation r´seau (nom de la machine d’ex´cution et num´ro de e e e e port) et le niveau de verbosit´ lui ont ´t´ fournis lors du d´marrage de TUNeEngine. e ee e Comme le composant TUNeEngineDelegate, il d´finit deux interfaces. La premi`re e e g`re les param`tres d’initialisation tandis que la seconde d´marre le d´mon d’´coute e e e e e de requˆte et d’acheminement de r´sultats. e e Quant au composant Collaborator , nous utilisons le m´canisme de communie cation ` distance RMI pour effectuer la collaboration avec d’autres SAA. Ce m´a e canisme n´cessite la pr´sence d’un annuaire d’enregistrement d’objets RMI dans le e e r´seau. Ainsi, le d´marrage de Collaborator requiert plusieurs param`tres d’inie e e tialisation dont : le nom de l’instance de TUNeEngine en cours d’ex´cution (TUe NeEngineName), le nom DNS de la machine d’ex´cution, le nom DNS de l’annuaire e d’enregistrement RMI et son num´ro de port. Il implante une interface RMI dont e l’exportation (` travers l’annuaire RMI) permet a un SAA distant de soumettre a ` des requˆtes ` TUNeEngine. L’enregistrement de cette interface se fait au d´mare a e rage sous le nom TUNeEngineName. Quelque soit le composant de communication externe (Collaborator ou CLI ), les natures des requˆtes ´mises sont identiques. e e Toute requˆte re¸ue est soumise au CmdInterpreter avec qui ils sont li´s a travers e c e ` une interface cliente. N.B. : Dans une ´volution future, nous envisageons a la place e ` de la technologie RMI utilis´e pour la collaboration, l’utilisation des web services e bas´s sur WSDL. e Dans sa version actuelle, le composant CmdInterpreter ne prend en compte que les requˆtes de la forme : une ligne ´quivaut a une requˆte. La commande est e e ` e repr´sent´e par le premier mot de la ligne et le reste correspond aux param`tres de la e e e commande. Son adaptation permettra de modifier la syntaxe de soumission de commandes au SAA. Voici la liste de quelques commandes prises en compte actuellement par le CmdInterpreter : – L’arrˆt de TUNeEngine : entraˆ l’arrˆt de tous les services internes. e ıne e – La soumission d’un environnement a administrer : entraˆ l’appel du compo` ıne sant composite SR Manager ; – Le d´ploiement/und´ploiement : entraˆ l’appel du composant Deployment e e ıne Manager ; – L’ex´cution d’une politique de reconfiguration : entraˆ l’appel du composant e ıne Policies Manager ;

Syst`me d’administration autonome adaptable : application au Cloud e

8.3. IMPLANTATION DE TUNEENGINE

96

– etc. L’enrichissement 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 ajout´es. La figure 8.3 r´sume l’implantation Fractal de l’ene e semble TUNeEngine a ce stade. `

Figure 8.3 – Soumission de commandes et Collaboration

8.3.3

Construction du SR

Cette ´tape repr´sente le cœur de TUNeEngine. En effet, elle permet de construire e e la structure de donn´es contenant tous les ´l´ments administr´s et d’administration e ee e (machines, logiciels, et les programmes d’administration). Dans notre implantation, ces ´l´ments sont fournis a TUNeEngine de deux fa¸ons : sous forme d’ADL 3 Fractal ee ` c ou par des composants Fractal. Cette dernier m´thode consiste de la part de l’ade ministrateur (averti) a construire l’architecture Fractal de ses ´l´ments et ensuite ` ee les l’ins´rer dans le composite TUNeEngine. Dans les deux cas, les API Fractal ime plantent tout ou partie des rˆles des composants Parser , Wrapper et SR. o

Lorsque les descriptions de l’environnement et des programmes de reconfiguration 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 rˆle. En ce qui concerne le Wrapper , il implante o le comportement g´n´rique et adaptable (voir ci-dessous) des ´l´ments du SR et e e ee obtient des administrateurs des comportements sp´cifiques. L’administrateur foure nit une classe Java implantant toutes les fonctions d’administration de l’´l´ment ` ee a encapsuler. Cette classe implante deux types de m´thodes d’encapsulation : la pree mi`re s’applique aux ´l´ments administr´s tandis que la seconde s’applique aux proe ee e grammes d’administration. Quant au SR, une partie de son implantation est fournie
3. Architecture Description Language

Syst`me d’administration autonome adaptable : application au Cloud e

8.3. IMPLANTATION DE TUNEENGINE

97

par les API Fractal. Son implantation est par la suite compl´t´e par la r´alisation ee e des liaisons Fractal entre les ´l´ments encapsul´s et les composants encapsulant les ee e services de TUNeEngine (Deployer , Policies Manager , et Event Manager ). Encapsulation des ´l´ments administr´s ee e Chaque ´l´ment administr´ est encapsul´ dans un composant primitif. Dans ceree e e tains cas, les ´l´ments appartenant ` une mˆme famille (selon l’administrateur) ee a e peuvent ˆtre regroup´s dans des composants composites. Par exemple, soit une e e application a administrer constitu´e de plusieurs modules. Soit un module conte` e nant plusieurs logiciels. Dans cet exemple, TUNeEngine permet l’encapsulation du module ` l’int´rieur d’un composant composite contenant les composants primitifs a e encapsulant les logiciels de ce module. Le mˆme raisonnement peut ´galement ˆtre e e e appliqu´ pour un cluster (dont le Wrapper fournit les proc´dures d’administration) e e contenant plusieurs SE. Dans tous les cas, les interfaces de gestion des composants sont identiques (crit`re d’uniformit´ 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 l’´l´ment encape ee sul´), deux interfaces cliente et serveur (le nombre d’interfaces pouvant ˆtre modifi´ e e e par adaptation du Wrapper ) lui permettant d’ˆtre reli´ a d’autres composants ; une e e` interface serveur d’ex´cution de fonctions d’administration (qui se trouvent dans les e programmes d’administration) et une d’interface serveur ”deploy” lui permettant d’ˆtre d´poy´/undeploy´. L’implantation de cette derni`re est fournie par l’adminise e e e e trateur et sera ex´cut´ par le composant Deployer pendant la phase de d´ploiement. 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 l’implantation de toutes ces interfaces par le Wrapper n’est utilis´e qu’en comportement par d´faut. En effet, l’adminise e trateur est capable de fournir par adaptation des comportements sp´cifiques aux e ´l´ments en cas de besoins. Par exemple, il fournira en fonction de la nature d’un SE ee pr´sent dans son architecture, diff´rents moyens de connexion sur ce SE (utilisable e e pendant les op´rations de d´ploiement). e e Encapsulation des programmes d’administration Les programmes d’administration sont regroup´s dans des composites nomm´s e e AunonomicManager. Un AutonomicManager peut contenir plusieurs programmes d’administration. Le Wrapper introduit dans chaque AunonomicManager un composant primitif (le Dispatcher ) charg´ de choisir le programme d’administration ` e a ex´cuter (voir la section 8.3.5 pour plus de d´tails). Dans l’impl´mentation actuelle de e e e TUNeEngine, les programmes d’administration sont des automates a ´tats. Chaque `e ´tat est un composant primitif implantant l’action a effectuer. Ce composant d´fie ` e nit une interface serveur run et deux interfaces clientes sr et next. L’interface run permet de d´clencher l’ex´cution de l’action. Cette interface doit ˆtre fournie par e e e l’administrateur. L’implantation de l’action a la possibilit´ d’acc´der au SR via l’ine e terface sr de l’´tat. En effet, certaines actions de reconfiguration peuvent entraˆ la e ıner modification du SR ou encore n´cessiter la r´cup´ration des param`tres de certains e e e e ´l´ments du SR. Pour finir, l’interface next permet de relier l’´tat aux autres. Elle ee e

Syst`me d’administration autonome adaptable : application au Cloud e

8.3. IMPLANTATION DE TUNEENGINE

98

donne ainsi le sens de progression de l’ex´cution de l’automate. e Chaque automate contient un point d’entr´e (l’´tat initial) et un point de sortie e e (l’´tat final). L’´tat initial renseigne le Dispatcher (via un attribut) des ´v´nements e e e e pour lesquels l’automate qu’il repr´sente peut ˆtre ex´cut´. Nous pr´sentons dans e e e e e la section 8.3.5, la description de l’ex´cution des programmes d’administration dans e TUNeEngine. La figure 8.4 r´sume l’organisation des composants Fractal dans le SR et dans e le composant TUNeEngine. Les composants de service de TUNeEngine ne sont pas tous repr´sent´s dans cette figure. Ils sont symbolis´s par un unique composant que e e e nous appelons Service.

Figure 8.4 – Construction du SR

8.3.4

D´ploiement e

Le composant Deployment Manager de notre mod`le est implant´ par un e e composant composite de mˆme nom dans TUNeEngine. Ce composant implante a e ` la fois les fonctionnalit´s de d´ploiement et de und´ploiement. Il d´finit deux intere e e e faces serveurs (deploie et undeploie) et une interface cliente (sr ). L’interface deploie d´marre le processus de d´ploiement d’un ou des ´l´ments du syst`me de repr´sene e ee e e tation. Quant ` l’interface undeploie, elle effectue l’op´ration inverse. L’interface sr a e permet de relier le composant Deployment Manager au SR afin qu’il puisse y Syst`me d’administration autonome adaptable : application au Cloud e

8.3. IMPLANTATION DE TUNEENGINE

99

retrouver tous les ´l´ments administr´s. ee e Dans notre implantation, le Deployer ne r´alise pas proprement dit les op´e e rations de d´ploiement et de und´ploiement. Son rˆle est de pr´parer, orchestrer, e e o e et compl´ter ces op´rations. Soit E un ´l´ment ` d´ployer : voici la r´alisation du e e ee a e e d´ploiement de E dans TUNeEngine. L’ordre de d´ploiement de E contient plusieurs e e informations : l’´l´ment a d´ployer, son SE ou les caract´ristiques que doivent respecee ` e e ter le SE choisi par NodeAllocator . Lorsque le SE n’est pas fourni, le Deployer sollicite le composant NodeAllocator afin que celui-ci lui fournisse un SE selon les caract´ristiques fournies dans l’ordre de d´ploiement. Pour cela, le composant e e NodeAllocator acc`de au SR via l’interface sr du Deployment Manager . Noe deAllocator implante deux interfaces serveurs : allocate (pour l’allocation de SE) et free (pour la lib´ration d’un SE). L’implantation de ces deux interfaces (qui repr´e e sente les politiques d’allocation et de lib´ration de SE) est enti`rement fournie par e e l’administrateur. Dans son implantation actuelle, TUNeEngine fournit une politique d’allocation bas´e sur l’algorithme de tourniquet. Le Deployer communique avec e le NodeAllocator via ces deux interfaces. Une fois le SE choisi par le NodeAllocator ou fourni dans l’ordre de d´ploiee ment, le Deployer s’assure que le SE estest pr´alablement d´ploy´. Dans le cas e e e contraire, il d´marre son processus de d´ploiement. Concr`tement, les op´rations de e e e e d´ploiement et und´ploiement proprement dites sont r´alis´es par les ´l´ments ade e e e ee ministr´s eux-mˆmes. Comme nous l’avons pr´sent´ dans la section pr´c´dente, le e e e e e e Wrapper ajoute a chaque ´l´ment encapsul´ deux interfaces serveurs pour r´aliser ` ee e e ces tˆches. a Concernant le SE, l’implantation particuli`re de son processus de d´ploiement e e consiste en : – D´ploiement (comme c’´tait d´j` le cas avec le syst`me TUNe) sur le SE des e e ea e binaires et codes sources n´cessaire pour ex´cuter le repr´sentant de TUNeEne e e gine : RemoteLauncher. Ce dernier est le bras de TUNeEngine sur le SE. – D´marrage sur le SE du RemoteLauncher et enregistrement de sa r´f´rence e ee RMI dans le registre RMI d´marr´ sur la machine d’administration TUNeEne e gine. Le repr´sentant du SE dans le SR contient le moyen de copie et d’ex´cution a dise e ` tance de commandes sur le SE lorsque celui-ci ne contient encore aucun repr´sentant e de TUNeEngine (RemoteLauncher ). En ce qui concerne les autres ´l´ments faisant l’objet du d´ploiement, le processus ee e de d´ploiement est le suivant : e – D´ploiement (comme c’´tait d´j` le cas avec le syst`me TUNe) sur le SE de e e ea e l’´l´ment a d´ployer, des binaires et codes sources n´cessaires pour ex´cuter ee ` e e e le repr´sentant de TUNeEngine de cet ´l´ment son SE : RemoteWrapper. Ce e ee dernier est charg´ d’ex´cuter sur le SE les futures actions de reconfiguration. e e – D´marrage du RemoteWrapper par le RemoteLauncher. Ce dernier enregistre e ´galement la r´f´rence RMI du RemoteWrapper dans l’annuaire RMI sur la e ee machine d’administration. Nous verrons dans la section suivante que cette r´f´rence est utilis´e plus tard pour l’ex´cution ` distance des actions de reee e e a configuration.

Syst`me d’administration autonome adaptable : application au Cloud e

8.3. IMPLANTATION DE TUNEENGINE

100

– D´marrage du d´mon jouant le rˆle d’Event Channel sur le SE. Nous verrons e e o dans la section suivante l’implantation de ce d´mon. e Apr`s le d´ploiement et le d´marrage des repr´sentants, le processus de d´ploiement e e e e e des ´l´ments a administrer se d´roule comme d´crit dans la section 8.1.3. ee ` e e Le composants Binary Manager dans notre mod`le n’est pas implant´ sous e e forme de composant Fractal. Il est implant´ comme m´thodes Java dans la classe e e d’implantation (fournie par l’administrateur) des interfaces deploie et undeploie. Dans son comportement par d´faut (fourni par TUNeEngine et adaptable), le d´e e ploiement (respectivement le und´ploiement) se limite ` la copie (respectivement la e a suppression) de fichiers de la machine TUNeEngine vers un r´pertoire particulier sur e le SE. Il s’agit du comportement que proposait le syst`me TUNe. e Inversement, dans le cadre du undeploiement, le Deployer s’assure que l’´l´ment ee undeploy´ n’h´berge plus d’´l´ments. Il d´fait ´galement la liaison entre l’´l´ment e e ee e e ee undeploy´ et son SE. e La figure 8.5 r´sume l’implantation Fractal de ces op´rations ainsi qu’une vue e e globale de l’environnement d’environnement apr`s cette ´tape. Les ´l´ments du SR e e ee dans cette figure sont symbolis´s par un ´l´ment symbolique nomm´ SR. On peut e ee e observer sur cette figure la relation entre chaque logiciel (pouvant jouer le rˆle de o sonde) et l’Event Channel . Remarquons ´galement que comme les logiciels, un SE e (repr´sent´ par son RemoteLauncher ) peut se voir associer un logiciel de sonde qui e e communiquera son ´tat ` l’Event Driver . Pour finir, les r´f´rences des Remotee a ee Wrapper et RemoteLauncher sont enregistr´es dans l’annuaire RMI de la machine e d’administration.

8.3.5

Ex´cution de programmes d’administration e

Nous regroupons dans cette section les ´tapes de configuration, d´marrage et e e de reconfiguration. Pour toutes ces ´tapes, ils s’agit globalement d’ex´cution de e e programmes d’administration. Comme nous l’avons ´voqu´ dans la section 8.3.3, les e e programmes d’administration sont encapsul´s dans des composants Fractal que nous e appelons AutonomicManager. Dans l’implantation de TUNeEngine, ils peuvent ˆtre e d´clench´s soit par une commande issu du composant External Communicator , e e soit par des ´l´ments administr´s. Dans le premier cas, l’´v´nement est directement ee e e e transmis ` l’Event Manager par le composant External Communicator . Dans a le second cas, ces ´v´nements sont achemin´s du SE jusqu’` la machine d’adminise e e a tration par le composant Event Driver . Ce dernier est implant´ par un composant e Fractal s’ex´cutant sur la machine d’administration. Ce composant dispose de deux e interface : l’interface serveur ”er” pouvant ˆtre ex´cut´e par RMI et une interface e e e cliente ”em” permettant de contacter l’Event Manager en cas d’´v´nements. Le e e composant Event Driver , d´marr´ au d´marrage de TUNeEngine, enregistre la e e e r´f´rence RMI de l’interface ”er” dans l’annuaire RMI situ´e sur la machine d’admiee e nistration. L’implantation de cette interface contactera le composant Event Manager via l’interface cliente ”em” de l’Event Driver .

Syst`me d’administration autonome adaptable : application au Cloud e

8.3. IMPLANTATION DE TUNEENGINE

101

Figure 8.5 – D´ploiement et Undeploiement e Comme nous l’avons ´voqu´ dans la section pr´c´dente, le composant Event e e e e Channel est implant´ sous forme de d´mon, associ´ ` chaque ´l´ment administr´ e e ea ee e et ex´cut´ a distance. Pendant son d´marrage, il initialise le tube dans lequel l’´l´e e` e ee ment administr´ qui lui est associ´ posera ses ´v´nements. Il obtient du registre RMI e e e e de la machine d’administration, la r´f´rence de l’interface ”er” du composant Event ee Driver . Cette interface implante la m´thode notify qui permet d’envoyer un ´v´nee e e ment a TUNeEngine. L’Event Channel associe a chaque ´v´nement la ref´rence ` ` e e e de l’´l´ment administr´ a l’origine de l’´v´nement. Il peut ˆtre enrichi par adaptation ee e` e e e afin d’y associer des informations comme l’instant d’envoie de l’´v´nement. e e Le composant Event Manager re¸oit les ´v´nements via son interface serveur c e e ”em”. Il d´finit en outre d’autres interface Fractal : une interface cliente ”sr” lui pere mettant d’avoir acc`s au SR, et une interface cliente ”pm” lui permettant d’avoir e acc`s au composant Policies Manager . L’implantation actuelle de l’interface sere veur ”em” de Event Manager prend en compte tous les ´v´nements re¸us et ne e e c comprend aucune logique d´cisionnelle. Il choisit via le Dispatcher de chaque Aue tonomicManager, les programmes de reconfiguration ` ex´cuter. Ce choix est dict´ a e e par un attribut de l’´tat initial du programme. Cet attribut contient une liste d’´v´e e e nements pour lesquels le programme est apte. Syst`me d’administration autonome adaptable : application au Cloud e

` 8.4. SYNTHESE

102

Apr`s d´cision des programmes ` ex´cuter, l’Event Manager fait appel au come e a e posant Policies Manager en lui passant la liste des programmes d’administration (r´f´rences des composants encapsulant les ´tats initiaux) des AutonomicManager a ee e ` ex´cuter. L’implantation de l’Event Manager est r´alis´e par un composant come e e posite contenant deux composants primitifs : Executor et ProgramInterpreter . Ce composant composite d´finit : une interface serveur ”pm” reli´e ` l’interface ”exee e a cute” de Executor ; une interface cliente ”sr” lui permettant d’acc´der au SR ; et e une interface cliente ”re” reli´e au RemoteExecutor . Le composant Executor , e via son interface ”execute”, parcourt chaque programme en partant du composant repr´sentant l’´tat initial. Pour chaque ´tat, l’action a ex´cuter est d´finit soit dans e e e ` e e un attribut, soit par une interface serveur ”run” de l’´tat, soit les deux. Lorsqu’elle e est d´finie par un attribut, l’Executor fait appel au ProgramInterpreter afin e d’interpr´ter l’action a effectuer. Les deux composants sont reli´s via leur interface e ` e ”interprete”. Dans son implantation actuelle, le ProgramInterpreter implante l’interpr´tation du langage RDL (section 5.2.3 du chapitre 5) du syst`me TUNe. Cette e e implantation peut ´videmment ˆtre modifi´e afin de prendre en compte un nouveau e e e langage. Dans tous les cas, l’interface ”run” est ex´cut´e ` la fin de l’interpr´tation. e e a e L’utilisation de l’interface ”run” est r´serv´e aux administrateurs avertis. En effet, e e ils devront implanter pour chaque action (programme Java ici), le parcours du SR et l’appel du m´canisme d’ex´cution a distance pour l’ex´cution proprement dite e e ` e des fonctions de reconfiguration sur la machine distante. Par contre, dans le cas d’une action interpr´t´e, cette tˆche est factoris´e dans le ProgramInterpreter ee a e et est g´n´rique pour toutes les actions. De plus, une fois les actions interpr´t´es, e e ee l’Executor se charge d’ex´cuter r´ellement l’action sur le SE distant de l’´l´ment e e ee concern´ par l’action. Pour cela, il fait appel au RemoteExecutor via son interface e ”re” reli´e a l’interface ”re” du composite Policies Manager . e ` L’implantation de l’interface serveur ”re” du RemoteExecutor obtient du registre RMI la r´f´rence RMI du RemoteWrapper de l’´l´ment sur lequel il doit ex´cuee ee e ter une action. Le RemoteWrapper implante une interface ”effect” qui permet d’ex´e cuter r´ellement la fonction de reconfiguration sur le SE distant. L’implantation de e l’interface ”effect” utilise les m´canismes d’introspection et de reflexion Java pour e identifier et ex´cuter la fonction sur le SE distant. Pour finir l’Executor constate e la fin de l’ex´cution du programme de reconfiguration lorsqu’il atteint l’´tat final du e e programme. La figure 8.6 r´sume l’implantation Fractal de TUNeEngine ainsi que e les interactions entre les diff´rentes ´l´ments distants constituant l’environnement e ee administr´. Le transfert d’´v´nement et l’ex´cution a distance des fonctions de ree e e e ` configuration sont r´alis´s par des appels RMI. Les repr´sentants RemoteWrapper et e e e RemoteLauncher jouent les rˆles d’effecteurs sur les ´l´ments en cours d’ex´cution o ee e sur les SE distants.

8.4

Synth`se e

Dans ce chapitre nous avons pr´sent´ le mod`le d´taill´ de l’architecture d’un e e e e e SAA hautement adaptable, flexible et remplissant les crit`res que nous avons idene Syst`me d’administration autonome adaptable : application au Cloud e

` 8.4. SYNTHESE

103

Figure 8.6 – Ex´cution de programmes d’administration e tifi´s dans le chapitre 6. L’implantation de ce mod`le, baptis´e 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 ´l´ments administr´s sont g´r´s de la ee e ee mˆme fa¸on. Chaque ´l´ment dispose d’un repr´sentant (wrapper ) dans le syst`me e c ee e e de repr´sentant de TUNeEngine et ´galement d’un repr´sentant (RemoteWrapper ou e e e RemoteLauncher ) sur le SE d’ex´cution distant. Pour r´aliser aussi bien la commue e nication des ´v´nements que l’ex´cution des fonctions d’administration a distance, e e e ` TUNeEngine utilise des appels RMI (implant´es respectivement par l’Event Ree ceiver et le RemoteExecutor ). Comme nous l’avons ´voqu´ tout au long de ce chapitre, tous les m´canismes e e e utilis´s par TUNeEngine sont adaptables. Le chapitre suivant montre notamment e une adaptation et utilisation de TUNeEngine pour l’administration d’une part du Cloud et d’autre part des applications de niveau entreprise qu’il h´berge. e Syst`me d’administration autonome adaptable : application au Cloud e

Chapitre 9 Contributions : application au Cloud
Contents
Un IaaS simplifi´ : 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 d’applications . . . . . . . . . . . . . . . . 9.3 Reconfiguration d’applications et de CloudEngine . . . . 9.3.1 R´paration de VM . . . . . . . . . . . . . . . . . . . . . . e 9.3.2 Consolidation de VM et Scalabilit´ de serveurs . . . . . . e 9.3.2.1 Ex´cution d’applications statique . . . . . . . . e 9.3.2.2 Ex´cution d’applications 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 probl´matique de ce travail de th`se fut l’administration du cloud e e e ainsi que des applications qu’il h´berge. L’ors d’une tentative d’utilisation du syse t`me d’administration autonome TUNe, nous nous sommes heurt´s ` la difficult´ e e a e d’utilisation de TUNe dans ce nouveau contexte qu’est le cloud. C’est ainsi que nous avons entrepris de concevoir et d’implanter un nouveau SAA le plus g´n´rique et e e flexible possible de tel sorte que son utilisation pour l’administration du cloud et ses applications soit une personnalisation de ce SAA (´vitant une r´-implantation fastie e dieuse). Dans le chapitre pr´c´dent, nous avons pr´sent´ 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 l’adaptabilit´ de ce syst`me en montrant comment il peut ˆtre utilis´ pour (1) e e e e l’administration d’une plateforme de cloud et (2) l’administration des applications entreprises s’ex´cutant dans le cloud. e Comme nous l’avons pr´sent´ dans l’´tat de l’art, plusieurs travaux autour du e e e cloud s’int´ressent ` l’administration du cloud en proposant des solutions plus ou e a moins compl`tes. De plus, ces solutions sont pour la plupart int´gr´es et li´es a une e e e e ` unique plateforme de cloud. Afin d’avoir un degr´ de libert´ dans l’application de e e TUNeEngine a l’administration du cloud, nous proposons dans le cadre de cette th`se ` e l’implantation d’un syst`me simplifi´ de cloud, baptis´ CloudEngine. Ce dernier se e e e limite uniquement a l’IaaS et ses services de base. Les services li´s a la facturation ` e ` ou ` l’authentification des clients ne sont pas implant´s dans CloudEngine. Cepena e dant, cette application de TUNeEngine a notre plateforme simplifi´e de cloud ne ` e limite pas son application ` d’autres plateformes offrant des composants clairement a identifiables. C’est le cas d’OpenNebula [OpenNebula] pour lequel nous avons utilis´ e TUNeEngine pour automatiser son administration. Ce chapitre est organis´ de la fa¸on suivante. Dans un premier temps, nous pr´e c e sentons l’implantation de CloudEngine ainsi que des adaptations de TUNeEngine pour le prendre en compte. Ensuite, nous pr´sentons l’administration de CloudEne gine par le syst`me TUNeEngine adapt´. Dans cette pr´sentation, nous nous limie e e tons aux tˆches de d´ploiement et de d´marrage de CloudEngine. Ensuite, nous a e e pr´sentons l’adaptation et l’utilisation de TUNeEngine pour l’administration des e applications entreprises devant s’ex´cuter dans CloudEngine. La fin de ce chapitre e est consacr´e ` la pr´sentation de l’implantation de quelques politiques d’adminise a e tration de l’ensemble ”CloudEngine-applications entreprises” par des instances de TUNeEngine.

9.1

Un IaaS simplifi´ : CloudEngine e

Comme nous l’avons annonc´ a la fin du chapitre 2, nous nous int´ressons aux e` e plateformes de cloud dans lesquelles l’isolation est r´alis´e par les syst`mes de vire e e tualisation. Ainsi, l’implantation d’IaaS simplifi´ que nous proposons (CloudEngine) e s’appuie sur un syst`me de virtualisation de type hyperviseur (section 2.2.4 du chae pitre 2). Le syst`me CloudEngine s’inspire des implantations d’IaaS existants tels e que OpenNebula [OpenNebula] et Eucalyptus [80]. Il implante la partie IaaS du mod`le de cloud que nous avons pr´sent´ dans le chapitre 3 a la figure 3.2. e e e ` La figure 9.1 montre l’organisation des services de l’IaaS de qu’implante CloudEngine. Ces services interagissent entre eux afin d’accomplir leurs taches. Les ´l´ments ee en bleu sur la figure 9.1 repr´sentent les services tandis que les ´l´ments en jaune e ee repr´sentent les ressources du cloud. Une fl`che pleine entre deux ´l´ments montre e e ee qu’un ´l´ment peut acqu´rir les services de l’´l´ment point´. En bref, les services ee e ee e fournis par CloudEngine sont :

Syst`me d’administration autonome adaptable : application au Cloud e

´ 9.1. UN IAAS SIMPLIFIE : CLOUDENGINE

106

– RepositoryController : g`re la soumission des images OS en provenance de e l’ext´rieur. Il cr´e pour chaque image OS, un Repository charg´ de recevoir e e e et de stocker l’image. L’ex´cution d’une VM utilisant une image Repository e pourra se servir d’une copie ExecutedVMRepository de cette image. – VMController : g`re la cr´ation, la migration, l’arrˆt et la sauvegarde des VM. e e e Il fournit les interfaces d’acc`s aux hyperviseurs pr´sents sur les machines de e e l’IaaS. Pour son fonctionnement, le VMController a besoin des services des autres composants du cloud. Pour le d´marrage d’une VM par exemple, il e obtiendra du RepositoryController l’image OS qu’utilisera la VM. – VLANController : g`re les r´seaux virtuelles dans lesquels les VM du cloud e e seront confin´es. Il est sollicit´ par le VMController pour la configuration ou e e la lib´ration des adresses r´seaux des VM lors de leur cr´ation, destruction ou e e e migration. A la fin de son intervention, les VM cr´es doivent ˆtre accessibles e e de l’ext´rieur par leur propri´taire. e e – ResourceController : s’occupe de l’allocation et de la lib´ration des ressource e dans le cloud. Il fournit au VMController la machine la plus ad´quate pour e l’ex´cution d’une VM dans le cloud. Comme nous le verrons dans la suite e (observ´ ´galement sur la figure 9.1), le ResourceController peut ´galement e e e ˆtre sollicit´ par d’autres composants du cloud. e e – MonitoringController : g`re l’´tat des ressources mat´rielles de l’IaaS ainsi que e e e celui des VM en cours d’ex´cution. Les informations qu’il dispose peuvent ˆtre e e utilis´es par les autres composants du cloud pour la r´alisation de leurs tˆches. e e a En guise d’exemple, l’allocation de ressources aux VM par le ResourceController n´cessite de sa part l’´tablissement d’une cartographie de l’ensemble des e e ressources du cloud. Cette cartographie est r´alis´e ` partir des informations e e a obtenues du MonitoringController. – Scheduler : implante les politiques de relocalisation et consolidation de VM en cours d’ex´cution dans le cloud. Pour cela, il utilise les services du Monitoringe Controller (pour l’obtention des ´tats des VM), du ResourceController (pour e l’obtention des machines de relocalisation/consolidation) et du VMController (pour les relocalisations/consolidations proprement dites). Dans cette section, nous pr´sentons l’implantation de ces services ainsi que leur e int´gration dans TUNeEngine. Dans un premier temps, nous pr´sentons une visions e e globale de cette implantation ainsi que son int´gration dans TUNeEngine. Ensuite, e nous pr´sentons en d´tails les composants de CloudEngine et leur implantation dans e e TUNeEngine. Notons qu’apr`s l’adaptation de TUNeEngine pour implanter l’´quie e valent du syst`me TUNe, cette adaptation de TUNeEngine est la seconde validation e de l’efficacit´ de notre mod`le en terme de respect des caract´ristiques que nous e e e avons identifi´es dans le chapitre 6. e

Syst`me d’administration autonome adaptable : application au Cloud e

´ 9.1. UN IAAS SIMPLIFIE : CLOUDENGINE

107

Figure 9.1 – CloudEngine

9.1.1

Vision globale : CloudEngine-TUNeEngine, ApplicationTUNeEngine-CloudEngine

Comme toute application administr´e par un SAA, l’administration de notre e plateforme simplifi´e de cloud par TUNeEngine n´cessite l’organisation de ses come e posants en deux cat´gories : les composants administrables (d´ploy´s sur les SE e e e distants) et les politiques d’administration (d´clench´es par des ´v´nements). Dans e e e e le cadre de CloudEngine, la majorit´ de ses ´l´ments sont int´gr´s dans TUNeEngine e ee e e comme programmes d’administration (plus pr´cis´ment programmes de reconfigurae e tion). Comme le montre la figure 9.2(2)(b), il s’agit du VMController, du RepositoryController, du VLANController, du VMController et du Scheduler. Ces composants se mettent en marche lorsqu’une entreprise cliente du cloud contacte le cloud pour soumission d’image OS ou allocation de VM. A ce sujet, les entreprises utilisent ´gae lement des instances de TUNeEngine (figure 9.2(1)) (` travers son composant Exa ternalCommunicator ) pour le d´ploiement de leurs applications dans le cloud. e En ce qui concerne les ´l´ments administr´s, nous retrouvons le Monitoringee e Controller, les Repository, les VM et les VLAN (figure 9.2(2)(a)). A l’exception du MonitoringController, les ´l´ments administr´s sont cr´es dynamiquement par les ee e e programmes de reconfiguration pr´sent´s pr´c´demment. Les VM par exemple sont e e e e cr´´es par le VMController. Pour finir, le ResourceController est une adaptation ee

Syst`me d’administration autonome adaptable : application au Cloud e

´ 9.1. UN IAAS SIMPLIFIE : CLOUDENGINE

108

du composant NodeAllocator , sous-composant du Deployer de TUNeEngine (figure 9.2(1)(d)). L’administration de CloudEngine par TUNeEngine n´cessite pr´alablement la e e description de son architecture et de ses politiques d’administration dans un langage quelconque. Dans l’attente de l’implantation des API de la couche langage de TUNeEngine (figure 5.7 de la section 5.5), nous conservons les composants de TUNeEngine permettant de r´aliser cette description a savoir le (Parser et Proe ` gramInterpreter ). Rappelons que ces composants sont pr´dispos´s a recevoir des e e ` descriptions en ADL de Fractal et notation point´e (RDL) du syst`me TUNe (sece e tion 5.2.3 du chapitre 5). Le premier permet de d´crire l’architecture des applications e qu’administre TUNeEngine (CloudEngine et applications entreprises notamment). Quant au second langage, il simplifie la description des actions d’administration contenues dans les programmes d’administration a ex´cuter 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 ´l´ments a administrer ainsi que les politiques d’administration de CloudEnee ` gine sont d´finis a l’aide de fichiers ADL Fractal. Ces derniers sont ensuite ex´cut´s e ` e e par TUNeEngine pendant son d´marrage. Cette ex´cution de TUNeEngine d´marre e e e le cloud. L’instance d’ex´cution de TUNeEngine repr´sente le point d’entr´e de notre e e e platefome de cloud : nous l’appelons frontend dans ce document. L’enregistrement de la r´f´rence du frontend dans l’annuaire de collaboration (voir la section 8.3.2 ee du chapitre pr´c´dent) permettra aux entreprises de r´server et d’ex´cuter des VM e e e e dans le cloud. De fa¸on g´n´rale, les instances TUNeEngine de niveau entreprise administrent c e e les applications entreprises de la mˆme fa¸on que le syst`me TUNe. A l’exception du e c e NodeAllocator de ces instances, l’implantation des composants de TUNeEngine est identique a celle que nous avons pr´sent´e dans le chapitre pr´c´dent. En effet, le ` e e e e NodeAllocator n’obtient pas les composants SE (sur lesquels seront d´ploy´s les e e logiciels) du SR de son instance TUNeEngine. Il contacte l’instance TUNeEngine de CloudEngine (par le biais de l’ExternalCommunicator des deux instances TUNeEngine du cloud et d niveau entreprise) afin d’obtenir les SE (qui sont des VM).

9.1.2

RepositoryController

Le RepositoryController g`re les soumissions de syst`mes de fichiers de VM dans e e le cloud. Chaque syst`me de fichiers est contenu dans un fichier au format iso que e nous appelons ´galement ”image”. Pour cela, nous r´servons dans l’environnement e e mat´riel du cloud une machine de stockage. Chaque image est g´r´e par un compoe ee sant Repository qui s’ex´cute sur le serveur de stockage et s’occupe du stockage de e l’image. Le RepositoryController attend continuellement des requˆtes sur deux canaux e

Syst`me d’administration autonome adaptable : application au Cloud e

´ 9.1. UN IAAS SIMPLIFIE : CLOUDENGINE

109

Figure 9.2 – Vision synth´tique : int´gration de CloudEngine a TUNeEngine et e e ` utilisation de TUNeEngine pour le d´ploiement d’applications entreprises dans le e cloud.

Syst`me d’administration autonome adaptable : application au Cloud e

´ 9.1. UN IAAS SIMPLIFIE : CLOUDENGINE

110

r´seaux. Les requˆtes re¸ues de ces canaux sont de types diff´rents. Les premi`res e e c e e viennent des clients ext´rieurs du cloud. Elles correspondent au t´l´chargement dans e ee le cloud d’images iso de VM. Dans ce cas, le syst`me de fichiers est transmis bloc e par bloc du client vers le RepositoryController. Notons que les deux intervenants n´gocient initialement la taille d’un bloc. A la fin du t´l´chargement des blocs, le e ee RepositoryController reconstitue l’image iso et l’instrumentalise pour faciliter la future configuration r´seau des VM qui l’utiliseront. L’instrumentalisation de l’image e consiste en l’ajout d’une partition particuli`re dans la description des partitions e disque de l’OS. Cette partition contiendra les programmes d’initialisation r´seau des e VM qui ex´cuteront cette image. Cette technique permet ` notre plateforme de cloud e a de prendre en compte des images d’OS standard. Nous revenons sur la description de ces programmes dans la section 9.1.4. Les deuxi`mes requˆtes re¸ues par le RepositoryController viennent du service e e c VMController lorsque celui-ci est sur le point de d´marrer une VM. En effet, comme e nous l’avons ´voqu´ dans la section 3, l’ex´cution d’une VM dans le cloud n´cessite e e e e la duplication de son image de base (pour une r´utilisation ult´rieure). Dans notre e e implantation, c’est le RepositoryController qui r´alise cette duplication. L’image e dupliqu´e est ensuite transf´r´e sur le lieu d’ex´cution de la VM (´l´ment Execue ee e ee tedVMRepository dans la figure 9.1). Ce lieu peut ˆtre la machine d’ex´cution de la e e VM ou encore un serveur de partage de fichiers accessible par la machine d’ex´cue tion de la VM. Dans notre cas, il s’agit d’un serveur NFS accessible par toutes les machines de l’IaaS. Implantation dans TUNeEngine. Le service RepositoryController est implant´ dans TUNeEngine par un programme de reconfiguration. Son ex´cution est e e d´clench´e par une requˆte d’enregistrement d’images de VM. Pour chaque image, e e e l’ex´cution du RepositoryController cr´e et d´marre dans le SR de TUNeEngine un e e e composant Repository repr´sentant l’image. Le d´ploiement et l’ex´cution du Repoe e e sitory s’effectue sur le serveur de stockage (figure 9.2(2)(f)). C’est lui qui est charg´ e de recevoir du client externe, le contenu de l’image. Il obtient du RepositoryController les param`tres tels que : le r´pertoire d’enregistrement des images, les param`tres e e e d’´coutes r´seaux, la taille des blocs de r´ception d’images VM, le nom de l’image, la e e e taille de l’image et le type d’OS contenu dans l’image. L’int´gration des composants e Repository dans le SR permet a CloudEngine de faciliter la tˆche de cr´ation de VM ` a e du VMController. Le d´marrage d’une VM dans le cloud entraˆ la cr´ation d’une image secone ıne e daire, replica de l’image OS originale. Cette nouvelle image est repr´sent´e dans e e le SR par un composant ExecutedVMRepository dont le d´ploiement et l’ex´cution e e duplique r´ellement l’image originale repr´sent´e par un Repository. e e e

Syst`me d’administration autonome adaptable : application au Cloud e

´ 9.1. UN IAAS SIMPLIFIE : CLOUDENGINE

111

9.1.3

VMController

Il s’occupe du d´marrage, de l’arrˆt et de la migration des VM a la demande des e e ` clients externes ou du Scheduler. Pour le d´marrage des VM, il requiert le nom de e l’image contenant l’OS a d´marrer, le nombre de VM ` d´marrer et les ressources ` e a e de la VM (nombre de processeurs, taille m´moire, nombre d’interface r´seau, etc). e e Le proc´d´ qu’il suit pour le d´marrage de chaque VM est le suivant : e e e – Il s’adresse au gestionnaire de ressources (ResourceController ) pour l’acquisition du lieu d’ex´cution (SE) de la VM. e – Comme nous l’avons ´voqu´ dans la section pr´c´dente, il sollicite le Reposie e e e toryController afin que celui-ci mette a la disposition du SE l’image de la VM ` (par la cr´ation et l’ex´cution de l’ExecutedVMRepository repr´sentant l’image e e e de la VM). – En fonction du type de l’image, il obtient du VLANController les scripts d’initialisation r´seau de la VM. Ces scripts sont enregistr´s dans la partition d’inie e tialisation r´seau de telle sorte qu’ils s’ex´cutent au d´marrage de la VM. e e e – Il utilise les API fournies par l’hyperviseur du SE pour d´marrer la VM. e – Pour finir, les scripts d’initialisation utilisent l’hyperviseur pour communiquer les param`tres r´seaux obtenus par la VM. Il transmettra ces param`tres au e e e client propri´taire de la VM afin que celui-ci puisse acc´der ` ses VM. e e a Inversement, l’arrˆt d’une VM lib`re les adresses r´seaux qu’elle utilise. Le VMCone e e troller sollicite ´galement le ResourceController pour le nettoyage du lieu d’ex´cution e e de la VM. Ce nettoyage peut consister ` supprimer l’ExecutedVMRepository 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 d’un programme d’administration. Il est ex´cut´ d’une part e e lorsqu’un client souscrit ou met fin a l’ex´cution d’une VM. Comme nous le verrons ` e dans la section 9.2, les demandes des clients se traduisent en ´v´nements de r´cone e e figuration au niveau de l’instance TUNeEngine qui g`re l’IaaS. D’autre part, son e ex´cution peut ˆtre d´clench´e par d’autres services de CloudEngine ` l’instar du e e e e a Scheduler (lorsqu’il d´sir relocaliser ou consolider une VM). e Comme l’enregistrement des images, il associe ` chaque VM ex´cut´e dans le a e e cloud un composant dans le SR encapsulant les fonctions de manipulation de la VM. Il s’agit des fonctions de d´marrage, d’arrˆt et de migration. Ainsi, le d´ploiement e e e d’une VM consistera au d´ploiement de son repr´sentant du SR, comme tout autre e e logiciel, sur la machine fournie par le ResourceController. La classe d’encapsulation d’une VM implante ´galement les fonctions de d´ploiement et de und´ploiement e e e telles que requise par l’IaaS. C’est notamment dans cette classe que les requˆtes au e VLANController sont effectu´es pour solliciter la configuration de la VM. e

Syst`me d’administration autonome adaptable : application au Cloud e

´ 9.1. UN IAAS SIMPLIFIE : CLOUDENGINE

112

9.1.4

VLANController

Il s’occupe des configurations r´seaux des VM dans CloudEngine. Pour cela, il e g`re un fichier d’adresses MAC a allouer aux VM. Son implantation suppose la pr´e ` e sence d’un serveur DHCP dans l’environnement du cloud. Le VLANController s’ex´cute sous forme de d´mon et attend sur une socket e e des ´ventuelles requˆtes du composant VMController lorsque celui-ci d´sire d´mare e e e rer/arrˆter une VM. Dans le cas du d´marrage, il alloue une adresse MAC inutilis´e e e e et reconnue par le serveur DHCP. Il lui fournit ´galement les scripts d’initialisation e r´seau de la VM en fonction du type d’image qu’elle ex´cute. Dans son implantation e e actuelle, le VLANController ne g`re que des OS de types CentOS [cen] et Debian [6]. e Enfin, il configure le r´seau de telle sorte que les VM appartenant au mˆme client e e feront partie d’un unique VLAN. Par contre, lorsque la requˆte du VMController concerne l’arrˆt d’une VM, le e e VLANController lib`re l’adresse MAC de cette VM de telle sorte qu’elle puisse a e ` nouveau ˆtre allou´e a une autre VM. e e ` Implantation dans TUNeEngine. Il est implant´ dans TUNeEngine comme e un programme de reconfiguration. Son ex´cution, d´clench´e par l’administrateur e e e du cloud, permet la cr´ation ou la suppression de composants VLAN dans le SR. e Le rˆle de ces composants est la configuration de VLAN dans l’IaaS. Chaque como posant VLAN implante une proc´dure de configuration r´seau particuli`re. Ils foure e e nissent ´galement les param`tres d’initialisation r´seau des VM aux composants e e e VM les repr´sentants. Il s’agit des informations sur les serveurs DNS, DHCP et les e adresses MAC reconnues dans le r´seau. Comme les Repository, le d´ploiement et e e l’ex´cution des composants VLAN s’effectuent sur une unique machine de l’IaaS e (figure 9.2(2)(e)). C’est ` partir de cette machine qu’ils r´alisent la configuration des a e VLAN et des VM s’ex´cutant dans l’IaaS. e

9.1.5

ResourceController

Il est le responsable de l’allocation des machines d’ex´cution des VM (les mae chines h´bergeant un hyperviseur) dans le cloud. Il intervient sur la demande du e VMController afin de lui fournir la machine d’ex´cution la plus ad´quate a l’ex´cue e ` e tion d’une VM. Pour cela, le VMController lui fournit les besoins en ressources de la VM qu’il souhaite ex´cuter. En fonction de ces informations et de celles fournies e par le MonitoringController, il choisit la machine d’ex´cution de la VM. e Dans son implantation actuelle, le choix de la machine d’ex´cution s’appuie sur e deux algorithmes dit de placement : ´clatement et regroupement des VM. Dans le e premier algorithme, le ResourceController choisit la machine d’ex´cution la moins e utilis´e. Dans ce cas, les machines n’h´bergeant aucune VM sont privil´gi´es. Dans le e e e e second algorithme, il choisit la machine la plus utilis´e pouvant ex´cuter la nouvelle e e VM sans s’effondrer. Les crit`res d’effondrement d’une machine sont configur´s par e e

Syst`me d’administration autonome adaptable : application au Cloud e

´ 9.1. UN IAAS SIMPLIFIE : CLOUDENGINE

113

l’administrateur du cloud avant son ex´cution. Ils prennent en compte les capacit´s e e m´moire, processeur, r´seau et disque de la machine. e e Implantation dans TUNeEngine. Le ResourceController (figure 9.2(2)(d)) correspond dans TUNeEngine au NodeAllocator . Grˆce a l’adaptabilit´ de TUa ` e NeEngine, nous rempla¸ons son NodeAllocator par le ResourceController. Comme c nous l’avons pr´sent´e dans la section 8.3.4, son ex´cution est d´clench´e par le VMe e e e e Controller via le Deployer de TUNeEngine. Nous regroupons les ressources de l’IaaS en deux cat´gories (figure 9.2(2)(c)) : e les machines d’ex´cution des composants services de l’IaaS (VLAN, Repository et e MonitoringController ) et les ressources d’ex´cution des VM. Chaque ensemble de e ressources est repr´sent´ par un cluster : ControllerCluster et IaaSCluster. Le Rese e sourceController g`re les ressources de l’IaaSCluster. Les composants Fractal VM e sont configur´s dans TUNeEngine de telle sorte que leur ex´cution se fasse dans e e l’IaaSCluster. De cette fa¸on, 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 l’IaaSCluster. Pour cela, il installe sur toutes les machines e de l’IaaS 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 v´ritable MonitoringController ) qui s’ex´cute sur le frontend. Ces sere e veurs recherchent deux types d’informations : l’´tat 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 consid´rons qu’une VM peut ˆtre dans e e e deux ´tats : soit accessible soit inaccessible. Une VM est consid´r´e comme accessible e ee lorsqu’elle r´pond correctement a au moins une requˆte r´seau de type ping. Quant e ` e e aux informations de consommation, nous prenons en compte les consommations r´e seau, CPU et m´moire de chaque VM et de toute la machine. e Pour obtenir ces informations, le Monitoringcontroller et ses serveurs utilisent des API de l’hyperviseur et de ceux du syst`me d’exploitation. Ces informations pere mettront par exemple au ResourceController de d´terminer le niveau d’effondrement e d’une machine d’ex´cution de VM ou encore au MonitoringController de d´clarer la e e panne d’une VM. Implantation dans TUNeEngine. Un composant Fractal encapsule le service Monitoringcontroller qui s’ex´cute sur le frondent. Quant aux serveurs de monitoe ring, ils s’agit de serveurs associ´s (par encapsulation) a chaque nœud (ce choix de e ` conception peut ˆtre remise en cause). En effet, comme tout ´l´ment administr´ par e ee e TUNeEngine, nous d´finissons dans la classe Java d’encapsulation de tout nœud de e l’IaaSCluster des programmes jouant les rˆles suivants : o – rˆle de sonde : il enregistre dans un fichier les consommations en ressources des o VM qu’h´berge le nœud. Ces informations seront par la suite transf´r´es vers le e ee

Syst`me d’administration autonome adaptable : application au Cloud e

9.2. UTILISATION DE CLOUDENGINE

114

MonitoringController (sur demande de l’administrateur) ou le Scheduler (sur ¸a demande). c – role de d´tecteur (et r´paration) de pannes : il initie dans certain cas, la r´pae e e ration des VM en cas de panne d´tect´e. C’est le cas lorsque le cloud pratique e e une r´paration par checkpointing tel que nous le verrons dans la section 9.3.1. e

9.1.7

Scheduler

Le Scheduler g`re la r´organisation/consolidation des VM dans l’IaaS pendant e e leur ex´cution. Cette consolidation permet notamment aux ressources de l’IaaS d’ˆtre e e mieux utilis´es. Son implantation d´pend des politiques que souhaitent l’adminise e trateur. Dans le chapitre 10 de pr´sentation des exp´rimentations de nos syst`mes e e e TUNeEgine et CloudEngine, nous pr´senterons en d´tails plusieurs politiques de e e consolidation. Qu’` cela ne tienne, le Scheduler s’appuie sur les informations du Moa nitoringController afin d’´tablir une cartographie de l’utilisation des ressources. e Son ex´cution n’est pas continue durant tout le cycle de vie du cloud. Il survient e r´guli`rement (apr`s un temps de repos ou un changement de l’IaaS par exemple) e e e afin de d´terminer les consolidations ` effectuer dans l’IaaS. e a Implantation dans TUNeEngine. Comme le VMController, le Scheduler est implant´ par un programme de r´configuration dans TUNeEngine. Il est d´clench´ au e e e e d´marrage du cloud et ne s’interrompe qu’` l’arrˆt de TUNeEngine. Le programme e a e de r´configuration qui l’encapsule comprend un seul ´tat ex´cutant une classe java e e e implantant la politique de scheduling. Sa d´finition sous forme de programme de e r´configuration lui permet d’avoir acc`s au SR (donc de la liste des machines et des e e VM). A l’aide des informations du SR et des appels r´guliers au MonitoringCone troller, il constitue a son r´veil la cartographie d’utilisation des ressources. Cette ` e cartographie lui permet de d´cider de la liste des machines virtuelles a d´placer. e ` e

9.2

Utilisation de CloudEngine

Apr`s sa mise en route par TUNeEngine, notre plateforme de cloud est prˆte a ace e ` cueillir des applications clientes venues de l’ext´rieur. Comme nous l’avons annonc´ e e en pr´ambule de ce chapitre, nous proposons ´galement l’adaptation du syst`me e e e TUNeEngine pour faciliter l’administration des applications clientes dans CloudEngine. Cette section est consacr´e a la pr´sentation de cette adaptation. Nous d´e ` e e butons par la pr´sentation de l’utilisation de TUNeEngine pour l’accomplissement e de la premi`re op´ration d’externalisation dans le cloud ` savoir la construction et e e a le t´l´chargement d’images de VM (section 3 du chapitre 2). Ensuite, nous pr´senee e tons l’adaptation de TUNeEngine pour le d´ploiement d’applications CloudEngine. e A l’exception du d´ploiement proprement dit des application dans le cloud, nous e ne pr´sentons pas en d´tails l’utilisation de TUNeEngine pour la configuration et e e Syst`me d’administration autonome adaptable : application au Cloud e

9.2. UTILISATION DE CLOUDENGINE

115

le d´marrage des applications. En effet, ces utilisations sont similaires a celles du e ` syst`me TUNe dont l’implantation de base de TUNeEngine reprend. e La figure 9.2 montre les deux niveaux d’utilisation de TUNeEngine pour l’administration dans le cloud. Une instance de TUNeEngine (figure 9.2(2)) sert a l’admi` nistration de CloudEngine et plusieurs autres instances sont utilis´es pour l’admie nistration des applications entreprises s’ex´cutant dans le cloud (figure 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 l’aide de TUNeEngine, nous proposons un syst`me d’automatisation du proe cessus de construction et de t´l´chargement vers le cloud d’une image VM. Dans ee le reste de ce document, nous nommons ImageConstructor, l’ensemble constitu´ de e TUNeEngine et cette application. Dans son implantation actuelle, ImageConstructor se limite ` l’automatisation de l’installation des OS de type Linux. Pour cela, a il s’appuie sur les outils syst`mes fournis par un syst`me Linux (Kickstart [Fedora], e e Debootstrap [7], etc). En cons´quence, il requiert pour son ex´cution que le client e e de CloudEngine dispose d’un syst`me Linux. e Sans rentrer dans les d´tails, l’ImageConstructor cr´e dans le SR un compoe e sant Fractal pour chaque image a construire. Ce composant d´finit les param`tres ` e e d’installation de l’OS (distribution Linux, partitionnement, package, utilisateur, mot de passe, etc). Son ex´cution r´alisera la construction progremment dite le l’image. e e L’ImageConstructor d´finit ´galement les param`tres permettant de contacter l’inse e e tance TUNeEngine du cloud (pour la suite, nous dirons tout simplement CloudEngine). Il s’agit du nom de la r´f´rence de CloudEngine dans l’annuaire ainsi que ee l’adresse de cette annuaire. Apr`s la construction de l’image, son enregistrement dans le cloud est g´r´ par e ee l’ex´cution du composant associ´ ` l’image dans le SR. Ce composant contacte le e ea cloud (via les informations obtenues de l’ImageConstructor ) afin de r´aliser le t´l´e ee chargement de l’image dans le Cloud. Ce contact se traduit au sein de CloudEngine par l’ex´cution du RepositoryController. Apr`s n´gociation de la taille des blocs e e e d’´change avec le RepositoryController, le composant repr´sentant l’image OS dans e e l’instance TUNeEngine de niveau entreprise transmet le contenu de l’image bloc par bloc vers le composant Repository le repr´sentant au niveau de CloudEngine. e

9.2.2

Administration d’applications

Comme nous l’avons ´voqu´ ci-dessus, nous ne revenons par en d´tails sur le e e e proc´d´ d’utilisation de TUNeEngine pour la r´alisation des tˆches de configuration e e e a et d´marrage des applications d´ploy´es dans le cloud. A l’exception du d´ploiement e e e e que nous pr´sentons ci-dessous, l’administration d’une application par TUNeEngine e Syst`me d’administration autonome adaptable : application au Cloud e

9.3. RECONFIGURATION D’APPLICATIONS ET DE CLOUDENGINE

116

(au niveau applications entreprises) est identique ` celle des services de CloudEngine a pr´sent´e dans la section 9.1. e e La description de l’application a administrer avec TUNeEngine dans le cloud ` requiert l’implantation d’un NodeAllocator particulier (figure 9.2(1)). En effet, les machines d’ex´cution des applications ne sont ni existantes, ni connues initialement e par le client. De la mˆme fa¸on que nous d´finissions un composant FrontEnd repr´e c e e sentant le cloud dans la construction des images, nous d´finissons ici un composant e jouant le mˆme rˆle. Ce composant permet au NodeAllocator de souscrire aux VM e o dans le cloud. Cette souscription entraˆ ınera dans le cloud, l’ex´cution du VMCone troller. Ce dernier retournera par la suite au NodeAllocator du client, les adresses de connexion aux VM lui appartenant. C’est ´galement pendant cette souscription e que le client n´gocie avec CloudEngine des modalit´s de gestion de ses VM. e e En guise d’exemple, CloudEngine permet au client de n´gocier le moyen de r´e e paration des VM en cas de pannes. Dans les sections suivantes, nous pr´sentons e les diff´rentes m´thodes de r´parations pouvant ˆtre implant´es par les deux parties. e e e e e Plus g´n´ralement, nous pr´sentons des politiques d’administration (reconfiguration) e e e a la fois dans CloudEngine et ses applications entreprises. `

9.3

Reconfiguration d’applications et de CloudEngine

Dans cette section, nous pr´sentons l’implantation des principales op´rations de e e reconfiguration que nous avions pr´sent´es dans la section 3 du chapitre 2. e e

9.3.1

R´paration de VM e

Nous identifions deux m´thodes de r´paration de VM dans le cloud : r´paration e e e non collaborative et r´paration collaborative. Avant de pr´senter ces deux m´thodes, e e e nous ´tudions deux moyens de d´tection de pannes de VM dans le cloud. e e Dans l’implantation de CloudEngine, nous avons d´crit la premi`re m´thode de e e e d´tection de pannes. Elle est r´alis´e par les serveurs du MonitoringController de e e e l’IaaS (section 9.1.6). Cependant, un client n’est pas tenu a souscrire ` ce service de ` a surveillance. Dans ce cas, il ins´rera parmi ses logiciels a d´ployer dans le cloud, des e ` e logiciels particuliers jouant le rˆles de surveillance. De plus, le client doit organiser o le d´ploiement de ces logiciels de telle sorte que l’observateur d’une VM ne s’ex´cute e e pas sur cette VM. Quelque soit le moyen de d´tection utilis´, nous distinguons deux e e m´thodes de r´paration de VM. Partant de la d´tection par IaaS, pr´sentons ces e e e e deux m´thodes de r´paration. e e

Syst`me d’administration autonome adaptable : application au Cloud e

9.3. RECONFIGURATION D’APPLICATIONS ET DE CLOUDENGINE

117

R´paration non collaborative e Dans ce type de r´paration, l’IaaS est le seul ` s’occuper de la r´paration des VM. e a e Les serveurs de monitoring de CloudEngine (ceux associ´s aux repr´sentants des mae e chines dans le SR) enregistrent r´guli`rement l’´tat entier des VM qu’ils monitorent e e e (contenu des m´moires, disque, communications r´seau, 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 l’IaaS (voir la section 2.2.3 du chapitre 2). Ainsi, lorsqu’une panne de VM est d´cel´e, l’ex´cution d’un programme de r´paration est e e e e d´clench´e par le MonitoringController ou l’instance . Ce programme d´marre (via e e e le VMController ) une nouvelle VM ayant non seulement les mˆmes caract´ristiques 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, l’inconv´nient de cette m´e e thode de r´paration est la d´gradation de l’ex´cution des applications clientes dans e e e le cloud. En effet, le checkpointing entraˆ l’arrˆt momentan´ de la VM, ce qui ıne e e ralentit l’ex´cution de ses applications. e R´paration collaborative e La seconde m´thode ´vite le checkpointing. En cas de panne, un programme e e de r´paration de CloudEngine d´marre une nouvelle VM en remplacement de celle e e tomb´e en panne. Cette VM s’appuie uniquement sur l’image de celle en panne. Cee pendant, les logiciels clients pr´c´demment en cours d’ex´cution dans la VM ne sont e e e pas d´marr´s par ce programme. En effet, le cloud ne dispose d’aucune connaissance e e des logiciels s’ex´cutant dans les VM qu’il h´berge. e e Le d´marrage des logiciels sera donc r´alis´ par l’instance TUNeEngine du client. e e e La communication CloudEngine vers l’instance TUNeEngine du client se fait de la mˆme fa¸on que du client vers le cloud. En effet, le ResourceAllocator du client e c fournit au cloud pendant la souscription aux VM, les r´f´rences de contact de l’insee tance TUNeEngine du client. Il s’agit de l’implantation d’une sorte de callback dans CloudEngine. Ainsi, le programme de r´paration de VM au niveau du cloud pourra e faire appel au programme de r´paration de VM au niveau du client. Ce dernier e programme ex´cutera le processus d’installation et de d´marrage des logiciels. e e

9.3.2

Consolidation de VM et Scalabilit´ de serveurs e

Apr`s l’implantation des programmes de r´paration dans CloudEngine, nous nous e e int´ressons dans cette section a l’implantation des autres tˆches de reconfiguration e ` a dans le cloud et ses applications. Au niveau de CloudEngine, il s’agit des op´rations e de consolidation que met en place l’administrateur pour optimiser la gestion des ressources. Quant aux applications clientes, compte tenu de la multitude des op´rae tions possibles, nous nous limitons a celles ayant un impact sur le cloud. Il s’agit des ` reconfigurations qui entraˆ ınent l’ajout ou le retrait de VM pendant l’ex´cution des e applications clientes. Lorsqu’elles surviennent dans la mˆme application, plusieurs e appellations sont utilis´es dans la litt´rature pour d´signer ces deux op´rations : e e e e sizing, scalabilit´ ou encore passage a l’´chelle. e ` e

Syst`me d’administration autonome adaptable : application au Cloud e

9.3. RECONFIGURATION D’APPLICATIONS ET DE CLOUDENGINE

118

Dans cette section, nous pr´sentons plusieurs situations d’ex´cution de Cloue e dEngine et des applications clientes pour lesquelles nous proposons diff´rents proe grammes de reconfiguration. Pour cela, nous supposerons que les clients du cloud ex´cutent des applications de type J2EE. e

9.3.2.1

Ex´cution d’applications statique e

La situation la plus basique est celle dans laquelle les clients du cloud surdimensionne a chaque r´servation le nombre de VM dont ils ont besoins pour l’ex´` e e cution de leurs applications. De plus, nous supposons que toutes les VM d’un client sont d´marr´es ou arrˆt´es au mˆme instant (nous consid´rons le cas inverse comme e e ee e e du sizing, section suivante). Dans cette situation, le cloud ` int´rˆt a mettre en place a ee ` un syst`me de consolidation bas´ sur les consommations r´elles des VM. En effet, 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 utilis´es. Si le Cloud r´serve les machines en fonction des tailles e e des VM, tel que pr´vu par le contrat qui le lie au client, elles seront ´clat´es sur un e e e grand nombre de machines. L’application d’un programme de consolidation bas´ sur e le niveau d’utilisation effectif des VM permettra au cloud de r´duire le nombre de e machines allou´es aux VM. En effet, 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 s’accentuera.

9.3.2.2

Ex´cution d’applications variables e

Cette seconde situation concerne les clients avertis. En effet, nous supposons ici que les clients pratiquent du sizing dans leurs applications. Contrairement ` la a situation pr´c´dente, ici le nombre de VM du mˆme client est variable. L’IaaS profite e e e de ces arrˆts de VM, donc lib´ration de ressources, pour r´organiser les VM par e e e consolidation. Pour illustrer cela, prenons quelques exemples pr´cis : e – Si le cloud ex´cute une seule application et que celle-ci pratique du sizing e ordonn´, alors aucune op´ration de consolidation n’est n´cessaire. Nous parlons e e e de sizing ordonn´ lorsque les VM retir´es sont les derni`res a ˆtre ajout´es. e e e `e e – Si le cloud ex´cute une seule application pratiquant un sizing non ordonn´, e e alors la consolidation est n´cessaire. Cette situation est identique a celle dans e ` laquelle le cloud ex´cute plusieurs applications appartenant a un ou plusieurs e ` clients. En effet, la fin d’une application (qui entraˆ la fin de ses VM), pendant ıne l’ex´cution d’autres, laissera des trous sur les machines h´bergeant les VM e e de cette application. Cette lib´ration de ressources correspond celle que nous e observons dans une application pratiquant un sizing non ordonn´. e – Une situation plus fine est celle dans laquelle le cloud donne la possibilit´ au e client de faire varier la taille d’une VM pendant son ex´cution. Ainsi, avant e d’ajouter une nouvelle VM pour absorber une charge, le client pourra tout d’abord augmenter progressivement les ressources de la VM jusqu’` atteindre a Syst`me d’administration autonome adaptable : application au Cloud e

` 9.4. SYNTHESE

119

la ressource maximale (celle de la machine qui l’h´berge). Et, c’est a l’issu e ` de ces augmentations qu’il ajoutera concr`tement une nouvelle VM. Le mˆme e e raisonnement est valable pour le retrait. Dans ce sc´nario, la consolidation au e niveau de l’IaaS prend v´ritablement tout son sens. Les variations de tailles e des VM, lib´reront des ressources (avec apparition des ”trous”) et n´cessiteront e e ainsi des consolidations/´clatements de VM dans l’IaaS. Notons ´galement e e qu’ici, le client est dans l’obligation d’adapter ´galement les distributeurs de e charges de ses applications. Nous ´valuons dans le chapitre suivant toutes ces sc´narios de reconfiguration ` la e e a fois dans le cloud et dans les applications clientes.

9.4

Synth`se e

Dans ce chapitre, nous avons pr´sent´ une adaptation de TUNeEngine pour l’ade e ministration de la plateforme de cloud simplifi´e CloudEngine ainsi que des applie cations qu’elle h´berge. La figure 9.3 pr´sente une vue globale de ces adaptations e e de TUNeEngine : a gauche de la figure, nous avons l’utilisation de TUNeEngine ` pour l’administration d’une application entreprise J2EE s’ex´cutant dans le cloud ; e a droite nous avons d’une part l’utilisation de TUNeEngine pour l’administration ` de CloudEngine et d’autre part le contenu des machines de l’IaaS. Par soucis de lisibilit´, toutes les liaisons Fractal entre les composants ne sont pas pr´sent´es dans e e e cette figure. Le syst`me de repr´sentation de l’instance TUNeEngine du cloud est organis´ en e e e quatre composants : – Un composant (”IaaS” sur la figure) contenant les wrappers des serveurs de l’IaaS ainsi que ceux des futures images et VM qu’h´bergera le cloud. Remare quons que dans cet exemple, le cloud propose une image de VM par d´faut e (DefaultImage) dont la description est montr´e dans la figure 9.4(a). Plusieurs e configurations de VLAN peuvent ˆtre utilis´es dans l’IaaS. La figure 9.4(b) e e pr´sente un exemple de configuration d’un VLAN. Cette description contient e par exemple l’adresse IP r´seau qu’utiliseront les VM de ce VLAN. e – Un composant (”Ressources” sur la figure) contenant les wrappers des machines de l’IaaS. Ces machines peuvent ˆtre regroup´es en cluster. e e – Un composant (”IaaS AutonomicManager” sur le figure) contenant les programmes d’administration et de reconfiguration des serveurs de l’IaaS. Ce composant est reli´ au composant ”IaaS” de la figure. On retrouve par exemple le e VMController que nous avons pr´sent´ dans les sections pr´c´dentes comme e e e e un programme d’administration. – Un composant (”Ressources AutonomicManager” sur le figure) contenant les programmes de d´marrage des logiciels de monitoring (sonde) des machines de e l’IaaS. Ce composant est reli´ au composant ”Ressources” de la figure. Nous e associons une sonde par machine (voir le logiciel ”Sonde” sur la partie droite basse de la figure 9.4)

Syst`me d’administration autonome adaptable : application au Cloud e

` 9.4. SYNTHESE

120

Quant au syst`me de repr´sentation de l’instance TUNeEngine d’administration de e e l’application entreprise J2EE, il est organis´ en deux composants : e – Un composant contenant les wrappers des serveurs J2EE et un wrapper d´e crivant les informations d’initiation de la collaboration avec le cloud. Chaque wrapper de serveur J2EE contient d’une part les informations de configuration du serveur proprement dit et d’autre part les informations d´crivant la quantit´ e e de ressources VM de ce serveur. La figure 9.4(c) montre la description du wrapper d’un serveur Apache de l’application entreprise J2EE. Dans sa premi`re e partie, nous retrouvons les informations de configuration d’Apache comme le ”ApacheUser” tandis que dans sa deuxi`me partie, nous retrouvons les infore mations de configuration de la VM qui h´bergera cet Apache (par exemple e ”cpu” : la quantit´ de processeur a garantir ` cette VM). e ` a – Un composant contenant les programmes de configuration, d´marrage, recone figuration et r´paration des serveurs J2EE. e Le composant ResourceController (rempla¸ant le NodeAllocator ) de l’insc tance TUNeEngine de niveau entreprise obtient du serveur RMI de collaboration, la r´f´rence RMI du composant Collaborator du Cloud. A partir de cette r´f´rence, ee ee le ResourceController pourra allouer ou lib´rer des VM pour l’ex´cution des sere e veurs de l’application entreprise. Dans cette collaboration, la plus part des ordres ´mis par le ResourceController a destination du cloud seront r´solus par le VMe ` e Controller . En r´ponse a la r´servation d’une VM pour l’ex´cution d’un serveur e ` e e Apache par exemple, le VMController construit et ins`re dans le syst`me de ree e pr´sentation de CloudEngine un wrapper de VM dont une description est pr´sent´e e e e dans la figure 9.4(d). Les informations de configuration de cette VM sont transmises par le ResourceController du niveau entreprise dans l’ordre de r´servation. e Dans la mˆme logique, l’implantation du composant ProbreMySQL utilise la r´e e f´rence RMI du Collaborator afin d’avoir les informations de monitoring des VM e h´bergeant les serveurs MySQL dont il observe. Ainsi, il pourra (` partir de ces ine a formations) d´cider de la scalabilit´ ou non des serveurs MySQL en cas de n´cessit´. e e e e Pour finir, nous pouvons observer un empilement de serveurs sur les machines de VMCluster. Ainsi, s’ex´cutent au dessus de l’hyperviseur les repr´sentants Ree e moteLauncher et RemoteWrapper d´ploy´s par l’instance TUNeEngine du cloud. e e Chaque RemoteWrapper est associ´ ` l’ex´cution d’une VM, qui est consid´r´e par ea e ee l’instance TUNeEngine du cloud comme un ´l´ment administrable. Ensuite, chaque ee VM contient les repr´sentants RemoteLauncher et RemoteWrapper d´ploy´s par e e e l’instance TUNeEngine de niveau entreprise. Chaque RemoteWrapper de chaque VM est associ´ ` l’ex´cution d’un serveur J2EE. Les diff´rents repr´sentants des e a e e e instances TUNeEngine des deux niveaux (entreprise et cloud) sont enti`rement ine d´pendantes et ne disposent d’aucun lien entre eux. e

Syst`me d’administration autonome adaptable : application au Cloud e

` 9.4. SYNTHESE

121

Figure 9.3 – Vue globale d’administration et d’utilisation de CloudEngine via TUNeEngine

Syst`me d’administration autonome adaptable : application au Cloud e

` 9.4. SYNTHESE

122

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

Syst`me d’administration autonome adaptable : application au Cloud e

Chapitre 10 Exp´rimentations e
Contents
10.1 Environnements d’exp´rimentation . . . . . . . . e 10.1.1 L’IaaS . . . . . . . . . . . . . . . . . . . . . . . . 10.1.2 Les applications entreprises : RUBIS . . . . . . . 10.1.3 Les m´triques . . . . . . . . . . . . . . . . . . . . e ´ 10.2 Evaluations . . . . . . . . . . . . . . . . . . . . . . 10.2.1 R´paration de VM . . . . . . . . . . . . . . . . . e 10.2.1.1 R´paration non collaborative . . . . . . e 10.2.1.2 R´paration 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 simultan´es e e 10.3 Synth`se . . . . . . . . . . . . . . . . . . . . . . . . e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 124 125 126 126 126 127 128 130 130 132 134 143

Dans ce chapitre, nous pr´sentons une ´valuation de notre SAA TUNeEngine e e appliqu´ a la plateforme de cloud CloudEngine et aux applications qu’elle administre. e` Compte tenu de la difficult´ d’´valuation de certains aspects de l’administration e e (configuration, d´ploiement et reconfiguration par exemple), nous nous limitons dans e ce chapitre aux aspects suivants : construction d’images de VM et leur enregistrement dans le cloud ; utilisation de TUNeEngine pour la r´paration de VM dans le cloud ; et e utilisation de TUNeEngine pour la gestion de ressources de l’IaaS et des applications entreprises. Ce chapitre est organis´ de la fa¸on suivante : dans un premier temps, nous e c d´crivons les environnements mat´riels et logiciels sur lesquels nous nous appuyons e e pour la r´alisation de nos exp´rimentations. Ensuite, nous pr´sentons les r´sultats e e e e d’´valuation de TUNeEngine pour la r´paration de VM dans CloudEngine. Pour e e finir, nous pr´sentons l’´valuation de l’utilisation de TUNeEngine pour la gestion de e e ressources de l’IaaS ainsi que celle des applications entreprises.

´ 10.1. ENVIRONNEMENTS D’EXPERIMENTATION

124

10.1
10.1.1

Environnements d’exp´rimentation e
L’IaaS

L’environnement mat´riel d’exp´rimentation que nous avons mis en place co¨ e e ıncide avec notre mod`le simplifi´ d’IaaS pr´sent´ dans la section 9.1 du chapitre e e e e pr´c´dent. Les ressources mat´rielles sont organis´es en clusters de machines de type e e e e OPTIPLEX 755 : – Un ensemble de machines (CloudEngine) h´bergeant les diff´rents serveurs de e e CloudEngine a raison de : une machine h´bergeant le serveur de stockage (NFS) ` e des images de VM (Repository et ExecutedVMRepository), les serveurs de configurations des VLAN, le MonitoringController ; et une machine h´bergeant le e Scheduler, le VMController, le ResourceController, autres programmes de reconfiguration de CloudEngine et le registre RMI de sauvegarde des r´f´rences ee des instance de TUNeEngine. Cette derni`re machine est le point d’entr´e e e de CloudEngine car c’est elle qui h´berge ´galement l’instance TUNeEngine e e charg´e de l’administration de CloudEngine. Notons que cette organisation de e serveurs peut ˆtre d´centralis´e, par adaptation de TUNeEngine, pour un envie e e ronnement large ´chelle. Les machines de ce cluster disposent chacune de 4Go e de m´moire, 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 d’h´bergement des VM (5 machines). Les machines de ce cluster e sont celles qui seront utilis´es pour l’ex´cution des VM r´serv´es par les entree e e e prises. Toutes les politiques de gestions de ressources dans l’IaaS s’appliquent uniquement a ce cluster. Toutes ses machines ex´cutent l’hyperviseur Xen dans ` e sa version 4.1 sous un syst`me Linux CentOS 5.6. Elles disposent de 4Go de e m´moire, d’un processeur de type Intel Core 2 Duo 2.66GHz (un cœur d´sace e tiv´). Les configurations li´es a l’hyperviseur Xen sont les suivantes : 512Mo de e e ` m´moire pour le dom0 (le syst`me Linux hˆte) ; et l’algorithme de scheduling e e o de VM est sched-credit [cre]. – Un cluster (ClusterExterne dans la figure 10.1) constitu´ de 2 machines r´sere e v´es aux entreprises et clients des applications s’ex´cutant dans le cloud. Ces e e machines sont identiques a celles du premier cluster. ` Tous les clusters utilisent le mˆme r´seau IP et sont reli´s entre eux via un switch e e e 1Gb. La figure 10.1 r´sume l’organisation de notre environnement. Pour finir, les e images de VM construites et utilis´es dans nos exp´rimentations sont de 2Go de e e taille (influenceront le d´ploiement des VM) et utilisent une distribution CentOS e 5.6 de Linux. Elles sont construites de telle sorte que les machines r´serv´es aux e e entreprises aient un acc`s SSH ne requ´rant aucun mot de passe (afin de faciliter e e l’acc`s de l’instance TUNeEngine des entreprises vers leurs VM). e

Syst`me d’administration autonome adaptable : application au Cloud e

´ 10.1. ENVIRONNEMENTS D’EXPERIMENTATION

125

Figure 10.1 – Environnement mat´riel de notre IaaS e

10.1.2

Les applications entreprises : RUBIS

RUBIS [19] (Rice University BIdding System) est une implantation d’une application J2EE de commerce ´lectronique. RUBIS est issu du projet JMOB [jmo] et e d´velopp´ 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 donn´es (MySQL par exemple). En parall`le, il fournit e e un simulateur de clients web permettant d’effectuer des benchmarck sur le site web implant´ par RUBIS. e RUBIS d´finit 27 types d’interactions pouvant ˆtre r´alis´es par un client exe e e e terne. Les interactions les plus importantes sont celles de : consultation des produits par cat´gories/r´gions, passer des ordres, acheter des produits, vendre des produits, e e poser des commentaires ou consulter son profil. La plupart des int´ractions (22) n´e e cessitent la construction dynamique des pages. RUBIS permet de d´finir deux profils de benchmarking : avec lecture de done n´es uniquement ou avec 15% de lecture-´criture de donn´es. Dans le cadre de nos e e e exp´rimentations, nous utilisons le premier profile. e Le simulateur de clients web propos´ par RUBIS implante un comportement e proche de celui d’un client humain d’un site de commerce en ligne. Il permet le d´marrage de plusieurs clients web, chacun s’ex´cutant dans une session de dur´e e e e pr´cise. A l’aide d’une table de transition d´finissant le profil de charge, chaque e e client ´met r´guli`rement une requˆte a destination du site web RUBIS. Chaque e e e e ` client simule une dur´e de r´flexion entre chaque requˆte afin de se rapprocher du e e e comportement humain. Cette dur´e est choisie al´atoirement entre 7 secondes et 15 e e minutes suivant une distribution exponentielle n´gative [34]. L’algorithme de passage e d’une requˆte web ` une autre est bas´ sur une matrice de transition contenant e a e des valeurs de probabilit´s observ´es dans la r´alit´. Enfin, chaque client g´n`re e e e e e e Syst`me d’administration autonome adaptable : application au Cloud e

´ 10.2. EVALUATIONS

126

un ensemble de donn´es statistiques r´capitulant son ex´cution. Ces informations e e e contiennent le nombre d’erreurs survenues durant son ex´cution, les performances e des serveurs J2EE, les types de requˆtes ´mises, etc. e e

10.1.3

Les m´triques e

Les exp´riences r´alis´es durant cette th`se ont pour but de valider l’utilisation e e e e du SAA TUNeEngine pour l’administration de la plateforme de cloud CloudEngine et des applications qu’elle h´berge. Au niveau de l’IaaS, les principales m´triques qui e e nous int´ressent 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 hˆte avant l’installation de l’hyperviseur) et la charge CPU e o de la machine physique qui est la somme de toutes les charges CPU des VM qu’elle h´berge. e Au niveau des applications entreprises, nous nous int´ressons au d´bit et au temps e e de r´ponse des requˆtes de l’application RUBIS, observ´s au niveau du serveur web e e e Apache.

10.2
10.2.1

´ Evaluations
R´paration de VM e

Dans cette exp´rimentation, nous ´valuons les deux types de r´paration que nous e e e avons d´crites dans la section 9.3.1 du chapitre pr´c´dent. Il s’agit de la r´paration e e e e collaborative et non collaborative dont nous rappellerons bri`vement les principes e dans les sections suivantes. De fa¸on g´n´rale, dans les exp´riences que nous r´alisons pour l’´valuation de c e e e e e la r´paration, les pannes sont d´tect´es par l’instance TUNeEngine de niveau IaaS. e e e Nous d´marrons l’IaaS de telle sorte que les serveurs du MonitoringController, instale l´s sur chaque machine de l’IaaS, scrutent l’´tat des VM toutes les 2 secondes. Nous e e consid´rons qu’une VM est en panne lorsqu’elle ne r´pond plus a une requˆte IP (la e e ` e commande ”ping” ` partir d’une autre machine) ou encore lorsque son hyperviseur a Xen indique un ´tat d’erreur. e Pour chacune des ´valuations des deux m´thodes de r´paration, nous ex´cutons e e e e un benchmark RUBIS pyramidal (mont´e de charge, charge constante et baisse de e charge). Nous simulons une panne sur une VM h´bergeant un serveur MySQL de e l’application RUBIS ex´cut´e. En outre, nous associons ` ces exp´rimentations une e e a e exp´rience particuli`re jouant le rˆle de rep`re. En effet, cette exp´rience sera utilis´e e e o e e e pour la comparaison des deux m´thodes de r´paration. Elle consiste en l’ex´cution e e e d’un benchmack RUBIS dans lequel aucune panne n’est simul´e. La comparaison e Syst`me d’administration autonome adaptable : application au Cloud e

´ 10.2. EVALUATIONS

127

des deux m´thodes de r´paration est effectu´e sur la base du d´bit en requˆtes et du e e e e e nombre d’erreurs observ´es durant chaque exp´rience. e e Pour finir, l’application RUBIS ex´cut´e dans cette exp´rience est compos´e de : e e e e 1 serveur Apache, 1 serveur Tomcat, 1 serveur MySQL-Proxy et 1 serveur MySQL. Les VM h´bergeant ces serveurs sont configur´es de telle sorte qu’elles s’ex´cutee e e rons chacune sur des machines distinctes. Cette configuration n’a aucune influence particuli`re sur les r´sultats de l’exp´rimentation. e e e

10.2.1.1

R´paration non collaborative e

Nous d´finissons la r´paration non collaborative comme celle dans laquelle l’inse e tance TUNeEngine de l’IaaS est l’unique responsable du d´pannage des VM. Dans e notre exp´rimentation, TUNeEngine d´marre sur chaque machine de l’IaaS un sere e veur dont le rˆle est de sauvegarder toutes les 7 secondes l’´tat de chaque VM. Le o e choix de la fr´quence de sauvegarde ne doit pas ˆtre ni trop petite, au risque de e e p´naliser l’ex´cution de la VM (comme nous le verrons), ni grande au risque d’avoir e e un grand ´cart entre la VM d´pann´e et son ´tat avant la panne. Nous avons choisi e e e e une dur´e de 7 secondes en rapport avec la dur´e minimale d’attente entre chaque e e ´mission de requˆte de client RUBIS. Les ´tats de VM sauvegard´s sont stock´s, e e e e e non pas sur le serveur NFS, mais sur la machine h´bergeant la VM. Ces sauvegardes e seront transf´r´es avec la VM lors des op´rations de consolidation. ee e La figure 10.2 montre la comparaison entre l’exp´rimentation rep`re (courbe e e rouge) et l’exp´rimentation avec r´paration par checkpointing (courbe verte) dans e e laquelle aucune panne n’a ´t´ simul´e. Cette figure nous permet uniquement d’obseree e ver l’impact du checkpointing de VM sur les performances de l’application RUBIS s’ex´cutant dans le cloud. Nous observons une baisse de d´bit de requˆtes trait´es e e e e dans ce type de r´paration : courbe rouge au dessus de la courbe verte. Nous ´vae e luons cette baisse de d´bit a 46% environ. Elle est due a l’arrˆt r´gulier des VM lors e ` ` e e du checkpointing dans l’IaaS. En effet, le checkpointing implant´ par Xen provoque e l’indisponibilit´ de la VM pendant sa sauvegarde. Ainsi, toutes les requˆtes en die e rection ou ` l’int´rieur de cette VM s’ex´cuteront apr`s la sauvegarde. Ceci explique a e e e ´galement de grandes fluctuations du d´bit sur la courbe verte. e e La figure 10.3 pr´sente le r´sultat de l’application de la m´thode de r´paration e e e e de VM par checkpointing dans le cloud, avec simulation de pannes sur la VM du serveur MySQL. L’instant Tp repr´sente l’instant auquel la panne a ´t´ provoqu´e e ee e tandis que l’instant Tr marque la fin de la r´paration. La dur´e de r´paration dans e e e cette exp´rience est d’environ 22 secondes. Cette dur´e comprend le temps ´coul´ e e e e avant la d´tection de la panne et ´galement la dur´e de red´marrage de la VM a e e e e ` partir de son dernier ´tat sauvegard´. e e Nous constatons ´galement dans cette exp´rimentation qu’aucune requˆte n’est e e e perdue a la fois pendant les sauvegardes de VM que pendant la r´paration. En effet, ` e pour ce qui est de la sauvegarde, le protocole TCP/IP sur lequel repose notre r´seau e se charge de r´´mettre une requˆte lorsque celle-ci n’a pas abouti. Ainsi, durant ee e Syst`me d’administration autonome adaptable : application au Cloud e

´ 10.2. EVALUATIONS

128

Figure 10.2 – Coˆt du checkpointing dans la r´paration de VM dans l’IaaS u e la sauvegarde, l’indisponibilit´ n´gligeable de la VM n’entraˆ pas la rupture des e e ıne communications TCP/IP et celles-ci sont reprises a la fin de la sauvegarde. Quant ` a la non perte de requˆtes durant la r´paration, elle s’explique par le comportement ` e e du client RUBIS. En effet, il r´´met en cas d’erreur la mˆme requˆte 6 fois toutes ee e e les secondes, ce qui laisse le temps a la r´paration (d´marrage de la VM avec son ` e e ancien ´tat) de se r´aliser. Notons que pour certaines applications comme MPI, e e l’indisponibilit´ de la VM (mˆme n´gligeable), suivit du changement d’´tat de la e e e e VM ne saurait ˆtre tol´r´e. e ee

10.2.1.2

R´paration collaborative e

La seconde m´thode de r´paration est dite collaborative dans la mesure o` les e e u op´rations de r´partition sont r´alis´es ` la fois par l’instance TUNeEngine de niveau e e e e a IaaS et l’instance TUNeEngine de niveau application entreprise. En effet, l’instance TUNeEngine de niveau IaaS d´tecte la panne de VM, red´marre la VM a partir de e e ` son image initiale et fait appel a l’instance TUNeEngine propri´taire de la VM pour ` e finaliser la r´paration. L’instance TUNeEngine de niveau application est quant a elle e ` charg´e de : d´ployer sur la VM red´marr´e les logiciels qui y s’ex´cutaient avant la e e e e e panne ; configurer et d´marrer ces logiciels. La taille des logiciels a d´ployer ainsi que e ` e la dur´e d’ex´cution des programmes de configuration et de d´marrage des logiciels e e e sur la VM influencent la dur´e de la r´paration. e e

Syst`me d’administration autonome adaptable : application au Cloud e

´ 10.2. EVALUATIONS

129

Figure 10.3 – R´paration de VM de l’IaaS par checkpointing e La figure 10.4 pr´sente deux courbes : la courbe rouge repr´sente l’exp´rimene e e tation rep`re tandis que la courbe verte repr´sente le r´sultat de l’exp´rimentation e e e e avec panne et r´paration collaborative. Nous constatons que cette m´thode de r´e e e paration, contrairement a la pr´c´dente, n’a aucun impact sur les performances de ` e e l’application RUBIS lorsqu’aucune panne n’intervient. Cette constatation est visible sur la figure 10.4 dans les zones (1) et (3). La zone (2) repr´sente la dur´e de la e e r´paration. Elle inclut : le temps de d´tection de la panne, la dur´e de d´ploiement e e e e et de red´marrage de la VM, la dur´e de la copie des binaires du serveur MySQL e e s’ex´cutant sur la VM et enfin la dur´e de red´marrage du serveur MySQL. Pour e e e ces raisons, nous constatons dans cette exp´rience, une r´paration en 5 minutes 30 e e secondes. Cette dur´e importante de la r´paration entraˆ une perte de requˆtes au e e ıne e niveau des clients RUBIS. Cette perte est de deux ordres : – Des pertes li´es aux requˆtes effectivement ´mises par le client RUBIS, mais e e e heurt´es a l’indisponibilit´ du serveur MySQL. Nous ´valuons cette perte a e ` e e ` environ 0.12% des requˆtes ex´cut´es. La valeur n´gligeable de cette perte e e e e vient d’une part du fait que chaque client RUBIS ´met 6 fois la mˆme requˆte e e e en cas d’erreurs, avec une pause d’une seconde entre chaque tentative. D’autre part, les timeout des serveurs J2EE impliqu´s dans ces requˆtes sont sup´rieurs e e e a la minute. ` – En comparaison avec l’exp´rimentation rep`re, nous observons la r´duction du e e e nombre globale de requˆtes ex´cut´es durant cette exp´rience. Nous estimons e e e e cette r´duction a environ 23% de requˆtes trait´es dans l’exp´rimentation ree ` e e e p`re. Cette valeur s’explique par la perte de temps des clients RUBIS dans e leurs tentatives de r´´mission de requˆtes pendant la dur´e de la r´paration. ee e e e

Syst`me d’administration autonome adaptable : application au Cloud e

´ 10.2. EVALUATIONS

130

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

Figure 10.4 – R´paration collaborative de VM e

10.2.2

Scalabilit´ et Consolidation e

Pour ces ´valuations, la figure 10.5 r´sume les diff´rentes situations que nous e e e exp´rimentons. Elle montre ´galement pour chaque situation, les m´triques sur lese e e quelles les prises de d´cision sont bas´es. e e

10.2.2.1

Scalabilit´ e

Le but de cette exp´rimentation est de montrer l’utilisation de TUNeEngine e pour l’allocation dynamique de ressources (VM) au niveau de l’application RUBIS dans le cloud. La consolidation au niveau CloudEngine est neutralis´e. Son instance e TUNeEngine s’occupe uniquement du placement des VM pendant leur d´marrage. e L’application RUBIS ainsi que la sonde de monitoring des serveurs MySQL sont configur´es de la fa¸on suivante : e c – 1 serveur Apache reli´ ` 2 serveurs Tomcat. Ces derniers sont reli´s a 1 serveur ea e ` MySQL-Proxy qui distribue des requˆtes a 1 serveur MySQL (initialement). e ` Syst`me d’administration autonome adaptable : application au Cloud e

´ 10.2. EVALUATIONS

131

Figure 10.5 – R´capitulatif de quelques situations n´cessitant scalabilit´ et de e e e consolidation dans le cloud et les applications qu’il h´berge e – La sonde d’observation du tiers MySQL obtient du MonitoringController de l’instance TUNeEngine de l’IaaS les informations sur la charge CPU des VM h´bergeant les serveurs MySQL. Elle d´clenchera l’ajout d’un nouveau serveur e e MySQL lorsque la charge CPU du tiers MySQL (moyenne des charges CPU des serveurs MySQL) sera sup´rieure ` 60%. Inversement, elle d´clenchera le e a e retrait d’un serveur MySQL lorsque le tiers MySQL aura une charge CPU inf´rieure a 10%. L’ordre de retrait des serveurs MySQL est l’ordre inverse des e ` ajouts. Autrement dit, le dernier serveur ajout´ sera le premier retir´. Le seuil e e de charge CPU maximum est fix´ ` 60% parce qu’il correspond, apr`s plusieurs ea e tests, au seuil pour lequel le d´bit en requˆtes trait´es par l’application RUBIS e e e ne progresse plus. Cette limitation est due a une saturation de la taille m´moire ` e des VM h´bergeant les serveurs MySQL (qui sont sollicit´s pour des requˆtes e e e de grande taille). Cette sonde pourrait ˆtre coupl´e a une sonde m´moire afin e e ` e d’avoir une prise de d´cision plus efficace. Quant au seuil minimum de 10%, il e est choisi parmi des valeurs possibles tel que le retrait d’un serveur ne provoque pas le d´passement du seuil de 60% des serveurs restants. e – Le nombre de clients RUBIS augmente/diminue de 50 toutes les minutes durant l’exp´rience. e La figure 10.6 montre les r´sultats obtenus durant cette exp´rimentation. La courbe e e verte montre l’´volution du nombre de client RUBIS soumis ` l’application RUBIS. e a La courbe noire montre l’´volution de la charge CPU du tiers MySQl. Les autres e courbes montrent l’´volution du nombre de VM sur chaque machine de l’IaaS. Voici e l’interpr´tation de ces courbes : e – La premi`re partie correspond a la phase de d´ploiement des VM. Chaque e ` e machine de l’IaaS h´berge une VM. e – La seconde phase correspond au d´ploient des binaires et au d´marrage du e e serveur MySQL sur sa VM. – Le zone (a) correspond ` l’ajout d’un nouveau serveur MySQL suivi de la a chute de la charge CPU du tiers MySQL. Cette chute est due au red´mare rage du serveur MySQL-Proxy afin de prendre en compte le nouveau serveur Syst`me d’administration autonome adaptable : application au Cloud e

´ 10.2. EVALUATIONS

132

MySQL. De plus, nous constatons que la d´cision d’ajouter un nouveau serveur e MySQL n’est pas aussitˆt prise lorsque la charge CPU atteint 60%. En effet, o la sonde effectue plusieurs prises de charges CPU afin d’avoir confirmation du d´passement du seuil. e – La zone (b) correspond au retrait d’un serveur MySQL apr`s que la sonde ait e constat´ une baisse de charge confirm´e 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 l’´valuation de l’utilisation de TUNeEngine pour l’allocation 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 ` pr´sent comment TU` e a e NeEngine permet de g´rer par consolidation de VM les ressources de l’IaaS. Nous e montons pour cette exp´rimentation un sc´nario montrant l’utilit´ de la consolidae e e tion dans l’IaaS. Comme nous l’avons ´nonc´ dans la section 9.3.2.1 du chapitre e e pr´c´dent, nous consid´rons un sc´nario ex´cutant au niveau applicatif une seule ape e e e e plication. La version TUNeEngine d’administration de cette application n’implante aucune politique d’allocation dynamique de ressources. Quant au niveau IaaS, nous utilisons une politique de placement de VM consistant a maximiser le nombre de ` VM par machine. Le but de cette exp´rience est de valider l’existence et l’efficacit´ e e Syst`me d’administration autonome adaptable : application au Cloud e

´ 10.2. EVALUATIONS

133

du Scheduler de CloudEngine, dont le rˆle est de g´rer la consolidation des VM dans o e l’IaaS. Pour cette exp´rimentation, l’application RUBIS ex´cut´e dans le cloud ainsi que e e e le Scheduler de l’IaaS sont configur´s de la fa¸on suivante : e c – 1 serveur Apache, 2 serveurs Tomcat, 1 serveur MySQL-Proxy et 2 serveurs MySQL. – Toute VM h´bergent un serveur RUBIS se voit allouer 512Mo de m´moire. e e Cette configuration fera tenir initialement toutes les VM sur la mˆme machine e physique (512Mo * 6 serveurs + 512Mo du dom0 = 3Go512Mo < 4Go, taille d’une machine physique). – Le Scheduler est configur´ pour retirer une VM d’une machine physique lorsque e la charge CPU de cette machine d´passe 60%. Dans ce cas, la VM la moins e charg´e est d´plac´e vers la machine de l’IaaS la moins charg´e pouvant l’ace e e e cueillir. A l’inverse, le Scheduler regroupe des VM sur des machines selon la politique suivante. Soit Ma et Md les machines les moins charg´es de l’IaaS e contenant des VM telles que Ma est plus charg´e que Md . Soit V Md , la VM la e moins charg´e de la machine Md . Si la charge de Ma additionn´e a la charge e e ` de V Md est inf´rieure ` 60% et que la taille m´moire de Ma additionn´e a la e a e e ` taille m´moire de V Md est inf´rieure ` 4Go, alors le Scheduler d´place V Md e e a e vers la machine Ma . Cette politique est une parmi tant d’autres. Notons que le but de cette exp´rience n’est pas de produire et d’´valuer diff´rentes polie e e tiques de consolidation. Les travaux r´alis´s par le syst`me Entropy [59] sont e e e enti`rement consacr´s ` cette probl´matique. e e a e La figure 10.7 montre les r´sultats de notre exp´rience : la figure 10.7(a) pr´sente e e e la variation des charges CPU sur les machines de l’IaaS tandis que la figure 10.7(b) pr´sente le contenu de chaque machine de l’IaaS en terme de nombre de VM par e machine. Sachant que la taille et le nombre de logiciels d´ploy´s dans cette exp´rience e e e sont fixes, les variations de nombre de VM par machine d´montre la r´alisation de e e la consolidation dans l’IaaS coordonn´e par le Scheduler de CloudEngine. Ces deux e figures sont interpr´t´es de la fa¸on suivante : ee c – La premi`re partie des courbes correspond au d´ploiement des VM dans l’IaaS. e e Compte tenu de la politique de placement et de la taille des VM, toutes les VM sont d´ploy´es initialement sur la machine Node1. Ceci explique l’obsere e vation d’une charge CPU fluctuante sur la courbe CPU de la machine Node1 et l’absence de charge sur les autres machines de la figure 10.7(a). La premi`re e partie de la figure 10.7(b) montre ´galement ce regroupement de VM sur la e machine Node1. – Pendant l’ex´cution du benchmark RUBIS, nous observons un premier ´clatee e ment d’une VM de la machine Node1 vers la machine Node4 lorsque la charge CPU de la machine Node1 d´passe le seuil de 60%. Ceci explique la pr´sence e e d’une charge CPU sur la machine Node4 sur la figure 10.7(a)(1) et la pr´sence e d’une VM sur cette machine a la figure 10.7(b)(1). Il en est de mˆme pour le ` e (2) des figures 10.7(a) et 10.7(b). – Durant l’ex´cution de ce benchmark, le Scheduler peut ˆtre amen´ a regrouper e e e` les VM lorsque la charge d’une machine le permet. C’est notamment le cas

Syst`me d’administration autonome adaptable : application au Cloud e

´ 10.2. EVALUATIONS

134

de la VM de la machine Node4 qui sera d´plac´e vers la machine Node5 en e e mesure de supporter cette VM ` l’instant repr´sent´ sur la figure 10.7(a)(3). a e e – Pour finir, les VM sont regroup´es a la fin de l’ex´cution du benchmark sur un e ` e nombre restreint de machines. On peut remarquer que toutes les VM ne sont pas regroup´es sur une unique machine physique comme initialement. Ceci e s’explique par le fait que la migration pratiqu´e par Xen (le syst`me de vire e tualisation utilis´ par l’IaaS) d’une VM n´cessite 2 conditions : (1) la machine e e de destination dispose d’assez de m´moire pour ex´cuter la VM ` migrer ; (2) e e a la machine de destination dispose ´galement d’un surplus de m´moire destie e n´e a la r´alisation de l’op´ration de VM, consommatrice de m´moire. Cette e ` e e e consommation de m´moire est moins importante pendant la phase de d´mare e rage d’une VM que pendant l’ex´cution. Ainsi, la machine Node5 h´bergeant e e d´j` toutes les autres VM, ne dispose pas assez de m´moire pour accueillir la ea e derni`re VM se trouvant sur la machine Node4. e 10.2.2.3 Scalabilit´ et Consolidation simultan´es e e

Dans cette section, nous pr´sentons deux exp´rimentations dans lesquelles la e e consolidation au niveau de l’IaaS et l’allocation dynamique de ressources au niveau entreprise sont activ´es dans les deux instances de TUNeEngine. Nous avons justifi´ e e dans la section 9.3.2.2 du chapitre pr´c´dent le choix des deux sc´narios que nous e e e exp´rimentons. e Sc´nario 1 : VM de taille fixe et ”Scalabilit´ non ordonn´e” e e e Rappelons quelques d´finitions avant la description de l’exp´rimentation : e e La ”scalabilit´ ordonn´e” est la scalabilit´ dans laquelle les premiers serveurs e e e ajout´s sont les derniers serveurs retir´s. Dans cette exp´rience, nous avons choisi e e e d’utiliser la scalabilit´ non ordonn´e au niveau application entreprise. Nous entene e dons par ”scalabilit´ non ordonn´e” ici celle dans laquelle l’ordre de retrait des sere e veurs est le mˆme que l’ordre d’ajout (les premiers serveurs ajout´s sont les premiers e e retir´s). e Une VM de taille fixe est une VM dont les quantit´s de ressources initialement e acquises par l’entreprise n’´voluent pas durant son cycle de vie. e L’objectif de cette exp´rimentation est de montrer que l’ex´cution dans le cloud e e d’applications pratiquant de la ”scalabilit´ non ordonn´e” et utilisant des VM de e e tailles fixes n´cessite a l’implantation des politiques de consolidation de VM au e ` niveau de l’IaaS. Ainsi, l’instance TUNeEngine de niveau entreprise implante la ”scalabilit´ non ordonn´e” tandis que le Scheduler de CloudEngine est activ´ dans e e e l’instance TUNeEngine de l’IaaS. D´crivons a pr´sent les configurations de l’IaaS et e ` e des serveurs J2EE que nous utilisons dans le cadre de cette exp´rience. e Au niveau de l’IaaS : – La politique de placement de VM (lors du d´marrage) est le regroupement e maximum de VM par machine physique.

Syst`me d’administration autonome adaptable : application au Cloud e

´ 10.2. EVALUATIONS

135

´ Figure 10.7 – Consolidation dans le cloud : (a) Evolution de la charge CPU sur les ´ machines de l’IaaS, (b) Evolution du nombre de VM par machine de l’IaaS.

Syst`me d’administration autonome adaptable : application au Cloud e

´ 10.2. EVALUATIONS

136

– Le Scheduler de l’IaaS consolide les VM en fonction de leur quota de ressources (CPU ou m´moire). Ici, nous utiliseront le quota m´moire dans la mesure o` e e u toutes les VM disposent d’un quota infini de CPU (0 ou 100). Au niveau application entreprise, nous ex´cutons une seule application J2EE RUBIS e munie d’une sonde associ´e au tiers MySQL. Les serveurs J2EE de cette application e sont configur´s de la fa¸on suivante : e c – 1 serveur Apache dont la VM utilise 3Go de m´moire ; e – 2 serveurs Tomcat, 1 serveur MySQL-Proxy, 1 serveur M ySQL1 dont chaque VM utilise 1.5Go de m´moire ; e – La sonde d’observation du tiers MySQL provoque l’ajout d’un serveur MySQL lorsque la charge CPU moyenne des serveurs MySQL est sup´rieure a 60%. e ` Inversement, elle provoque le retrait lorsque cette charge est inf´rieure ` 20%. e a N.B. Nous choisissons un seuil minimum de 20% au lieu de 10% comme dans la premi`re exp´rience pour la raison suivante : un seuil de 10% (qui entraˆ e e ınera une scalabilit´ presque a la fin du benchmark) dans cette exp´rience ne laise ` e sera pas le temps d’observer l’effet de la consolidation (qui suit le scalabilit´) e pendant le benchmark. La consolidation n’´tant pas ´valu´e dans la premi`re e e e e exp´rience, ce seuil ´tait acceptable. e e Cette configuration entraˆ ınera l’instance TUNeEngine de l’IaaS a d´ployer les VM ` e h´bergeant les serveurs RUBIS de la fa¸on suivante (figure 10.8(a)) : e c – Compte tenu de la taille m´moire de la VM d’Apache, une machine physique e enti`re (de taille 4Go) sera utilis´e pour son h´bergement ; e e e – Les 2 serveurs Tomcat seront h´berg´s sur une machine physique de telle sorte e e que cette machine ne pourra accueillir d’autres VM ; – Les serveurs MySQL-Proxy et M ySQL1 seront h´berg´s sur une machine phye e sique de telle sorte que cette machine ne pourra accueillir d’autres VM ; La mont´e en charge du nombre de client web RUBIS entraˆ e ınera l’ajout d’un serveur MySQL (M ySQL2 ), par l’instance de TUNeEngine du niveau application. M ySQL2 sera ex´cut´ par l’instance TUNeEngine de niveau IaaS dans une nouvelle VM sur e e une nouvelle machine physique (figure 10.8(b)). Inversement, la baisse de charges en dessous du seuil minimal entraˆ ınera le retrait d’un serveur MySQL, donc de la VM l’h´bergeant. C’est ` ce niveau que nous implantons la ”scalabilit´ non ordone a e n´e” : l’instance TUNeEngine du niveau application ex´cute une politique de retrait e e de MySQL de telle sorte que les serveurs retir´s sont prioritairement les premiers e serveurs d´marr´s. Cette politique se traduira dans notre exp´rience par le retrait e e e du serveur M ySQL1 . En cons´quence, la machine h´bergeant la VM du serveur e e M ySQL1 se retrouvera avec une seule VM : celle h´bergeant le serveur MySQLe Proxy (figure 10.8(c)). A cette ´tape, nous disposons de deux machines h´bergeant e e deux VM dont les tailles permettent leur regroupement. L’ex´cution permanente du Scheduler de CloudEngine dans l’instance TUNeEne gine de l’IaaS regroupera les deux VM h´bergeant M ySQL2 et MySQL-Proxy sur e une seule machine physique (figure 10.8(d)). N.B. Rappelons que l’apparition de ”trous” observ´e ici dans l’ex´cution d’une seule application dans le cloud s’observe e e ´galement dans une ex´cution de plusieurs applications dans le cloud. La fin d’une e e application lib´rera des ressources et favorisera pour la consolidation. e

Syst`me d’administration autonome adaptable : application au Cloud e

´ 10.2. EVALUATIONS

137

Figure 10.8 – Scalabilit´ niveau application J2EE et Consolidation de VM niveau e IaaS : r´sum´ de l’exp´rimentation e e e La figure 10.9 montre les r´sultats de l’exp´rimentation r´alis´e suivant le sc´nario e e e e e ci-dessus. La courbe en rouge montre l’´volution du d´bit de l’application RUBIS e e vue de l’ext´rieur (` partir du serveur Apache). Le rˆle de cette courbe est d’une e a o part de prouver l’implantation de la scalabilit´ au niveau applicatif et d’autre part e de montrer le rapport entre la scalabilit´ et la consolidation au niveau IaaS. e Les autres courbes montrent l’´volution du nombre de VM sur chaque machine de e l’IaaS. Pour des raisons de lisibilit´, nous ne pr´sentons pas sur ces courbes l’´volution e e e de la charge client RUBIS ainsi que la variation CPU des serveurs MySQL (elles sont similaires aux courbes observ´es dans les exp´riences pr´c´dentes). L’interpr´tation e e e e e des r´sultats de cette exp´rience, pr´sent´s dans la figure 10.9, est la suivante : e e e e – La premi`re phase correspond au d´ploiement des VM h´bergeant les serveurs e e e J2EE. Le nombre de VM par machine correspond a la description que nous ` avons faite pr´c´demment. e e – La mont´e en charge au niveau du tiers MySQL entraˆ l’ajout d’un noue ıne veau serveur visible sur la figure 10.9 par le point (a). On constate d’une part que la VM ajout´e est d´marr´e sur une nouvelle machine (Node4). D’autre e e e part, la chute du d´bit observ´e sur la courbe rouge correspond au temps de e e reconfiguration du serveur MySQL-Proxy pour la prise en compte du nouveau serveur MySQL. Le d´calage temporel entre l’allocation d’un nouveau serveur e et la reconfiguration de MySQL-Proxy s’explique par le fait que l’allocation Syst`me d’administration autonome adaptable : application au Cloud e

´ 10.2. EVALUATIONS

138

du nouveau MySQL comprend : la copie et le d´marrage de la VM devant e l’h´berger (2Go), le d´ploiement des binaires de MySQL (35Mo) sur la VM et e e d´marrage de MySQL. e – La baisse de la charge au niveau du tiers MySQL entraˆ le retrait d’un serveur ıne MySQL visible sur la figure 10.9 par le point (b). La chute du d´bit correspond e au red´marrage du serveur MySQL-Proxy. Cette chute survient avant le retrait e de la VM h´bergeant le serveur MySQL parce que nous reconfigurons le serveur e MySQL-Proxy avant de d´clencher l’op´ration de retrait qui prend plus de e e temps (arrˆt de la VM et und´ploiement de la VM). e e – Le retrait de la VM entraˆ la consolidation au niveau IaaS, visible sur la ıne figure 10.9 par le point (c). On observe une l´g`re inflexion du d´bit. Cette e e e inflexion correspond a l’instant de consolidation (par migration de VM). En ` effet, la migration provoque une grande activit´ sur les machines impliqu´es, e e ce qui r´duira le temps processeur allou´ aux VM qui s’y ex´cutent ( 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 Sc´nario 2 : VM de taille variable et ”Scalabilit´ ordonn´e” e e e Dans cette exp´rimentation, la configuration de l’IaaS et des serveurs J2EE (` e a l’exception des serveurs MySQL et leur sonde) que nous utilisons est identique a ` celle utilis´e dans l’exp´rience pr´c´dente. Les VM h´bergeant les serveurs MySQL e e e e e sont celles sur lesquelles nous appliquons la variation de taille. Nous d´finissons e la taille d’une VM par deux valeurs : quota CPU et quota m´moire qui lui sont e allou´s. Repr´sentons cette taille par le couple [CPU=xxx ;M´moire=yyy], avec xxx e e e le quota CPU et yyy le quota m´moire en m´ga octet. Ainsi, la taille maximale d’une e e

Syst`me d’administration autonome adaptable : application au Cloud e

´ 10.2. EVALUATIONS

139

VM sera celle d’une machine physique de l’IaaS : [CPU=0 ;M´moire=tailleRAMe TailleM´moireDom0]. Cette derni`re correspond a : e e ` – un quota CPU de 0 ou 100 signifie que la VM a le droit d’utiliser toutes les ressources CPU de la machine qui l’h´berge. e – le quota m´moire maximal d’une VM est la taille m´moire de la machine e e physique l’h´bergeant a laquelle est soustraite la taille m´moire du dom0. e ` e Au niveau de l’application RUBIS, la sonde charg´e d’observer le niveau d’utie lisation du tiers MySQL utilise pour m´trique de d´cision, le temps de r´ponse de e e e l’application 1 . En effet, dans les exp´riences pr´c´dentes, les charges CPU des VM e e e sont obtenues du MonitoringController de l’instance TUNeEngine de gestion du cloud. Or, ces charges ne refl`tent pas r´ellement la consommation CPU de la VM e e lorsque celle-ci est configur´e avec un quota CPU diff´rent de 0/100. La charge CPU e e de la VM, observ´ par les sondes de l’IaaS 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 diff´rents de 0 ou 100. Cette charge repr´sente en r´alit´ l’utilisation CPU e e e e de la VM vis a vis de l’utilisation globale des processeurs de la machine physique. ` L’utilisation des quota empˆchera donc les sondes de l’IaaS d’observer une charge e CPU sup´rieure au quota de la VM. e Au niveau IaaS, nous implantons un programme de reconfiguration (ResizeVM ) dont le but est d’assigner a une VM de l’IaaS la taille souhait´e par son propri´taire. ` e e Ce programme pourra d´cider en cas de n´cessit´, de la migration de la VM de sa e e e machine d’h´bergement initiale, vers une autre machine pouvant supporter l’auge mentation de la VM. Cette situation survient lorsque la machine h´bergeant la VM e contient d’autres VM telle que l’augmentation de la taille de cette VM ne soit pas possible sur sa machine d’origine (manque de ressources sur la machine). Quant au Scheduler, il s’ex´cute r´guli`rement et consolide les VM lorsque des e e e ”trous” (laiss´s par la modification des tailles de VM ou migration) sont constat´s e e sur les machines de l’IaaS. Le sc´nario mis en place pour notre exp´rience est le suivant. Lorsque la sonde e e d’observation du tiers MySQL se rend compte du d´passement du temps de r´ponse e e d’un seuil maximal (40 secondes dans notre cas), il d´clenche dans l’instance de e TUNeEngine d’administration de l’application RUBIS, l’ex´cution d’un programme e de ”sizing”. Ce dernier choisit la VM de plus petite taille et ´met en destination de e l’instance TUNeEngine du Cloud, une requˆte d’augmentation de la taille de cette. e Le programme de sizing est inform´ du succ`s ou de l’´chec de la r´alisation de sa e e e e requˆte. L’´chec peut ˆtre due ` l’indisponibilit´ de ressources dans le cloud ou l’ime e e a e possibilit´ d’augmenter la taille de la VM car ayant atteint la taille maximale d’une e machine physique. Dans ce cas, le programme de sizing demande l’allocation d’une nouvelle VM sur laquelle il d´marrera un nouveau serveur MySQL (scalabilit´). Cette e e demande pourra ´galement ´chou´e si le cloud ne dispose plus de ressources. e e e Inversement, l’observation de la baisse du temps de r´ponse en dessous d’un seuil e
1. Compte tenue de la configuration de nos serveurs J2EE, l’augmentation du temps de r´ponse de l’application d´pend de la charge des serveurs MySQL. En effet les autres e e serveurs sont en sous charge durant toutes les exp´rimentations e

Syst`me d’administration autonome adaptable : application au Cloud e

´ 10.2. EVALUATIONS

140

minimal (5 secondes dans notre exp´rience) 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 l’´quilibrage de charge au niveau du r´partiteur de e e charges MySQL-Proxy. Pour finir, la diminution de la taille d’une VM jusqu’` l’atteinte de sa taille mia nimale (fix´e dans notre exp´rience a [CPU=50 ;M´moire=512]) entraˆ son retrait e e ` e ıne de l’architecture J2EE s’il existe d’autres serveurs MySQL. Notons qu’apr`s le ree trait d’une VM, le Scheduler de niveau cloud interviendra pour r´aliser d’´ventuelles e e consolidations provoqu´es par les variations des tailles des VM. e Dans cette exp´rience, l’application RUBIS est d´ploy´ initialement avec un e e e unique serveur MySQL de taille [CPU=50 ;M´moire=512]. La sonde de monitoring e d´clenche l’augmentation (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 m´moire. L’ex´cution de la VM h´bergeant la premi`re instance de serveur e e e e MySQL (M ySQL1 ) s’effectue sur la mˆme machine que le serveur MySQL-Proxy (fie gure 10.10(a)) comme dans l’exp´rience pr´c´dente. Avec l’augmentation du temps e e e de r´ponse, due a l’augmentation du nombre de clients RUBIS, la taille de M ySQL1 e ` passera successivement de [CPU=50 ;M´moire=512] a [CPU=75 ;M´moire=1024] puis e ` e [CPU=100 ;M´moire=1536]. Cette derni`re taille de M ySQL1 , ne pouvant tenir e e sur la machine l’h´bergeant initialement (car n´cessitant les capacit´s CPU d’une e e e machine enti`re), la VM l’h´bergeant sera migrer vers une nouvelle machine (fie e gure 10.10(b)). Ensuite, l’augmentation de la charge entraˆ ınera l’ajout d’un nouveau serveur MySQL (M ySQL2 ) (associ´ a une nouvelle nouvelle VM). L’ex´cution de e` e la VM de M ySQL2 d´bute avec la taille minimale. Ainsi, le ResourceAllocator de e CloudEngine fournira comme machine d’ex´cution de cette VM, la machine h´bere e geant le serveur MySQL-Proxy (figure 10.10(c)). Inversement, lorsque le nombre de client RUBIS baisse et entraˆ une am´lioraıne e tion du temps de r´ponse, les tailles des VM des deux serveurs MySQL sont r´duites e e selon la politique d´crite ci-dessus. On constatera une consolidation de VM par le e Scheduler au niveau du cloud (figure 10.10(d)). La figure 10.11 montre les r´sultats de notre exp´rimentation. En rouge, nous pr´e e e sentons la variation du temps de r´ponse de l’application. Les deux autres courbes e montrent l’´volution du nombre de VM sur les machines de l’IaaS h´bergeant les sere e veurs MySQL. La courbe montrant l’´volution du nombre de clients RUBIS n’est pas e pr´sent´e dans cette figure car elle est similaire a celle des exp´riences pr´c´dentes. e e ` e e e L’interpr´tation de cette figure est la suivante : e – En (a) nous observons l’augmentation de la taille de la VM h´bergeant M ySQL1 . e Cette VM passe a une taille de [CPU=75 ;M´moire=1024]. Cette augmenta` e tion permet d’am´liorer le temps de r´ponse (observable par la baisse du temps e e de r´ponse). Cette baisse ne provoque pas la diminution de la taille de la mae chine. En effet, pour d´clencher la diminution de la taille de la machine, nous e imposons une p´riode de d´cision suffisamment long pour ´viter les effets yo-yo. e e e

Syst`me d’administration autonome adaptable : application au Cloud e

´ 10.2. EVALUATIONS

141

Figure 10.10 – Scalabilit´ niveau application J2EE avec VM de taille variable et e Consolidation de VM niveau IaaS : r´sum´ de l’exp´rimentation e e e – En (b) nous observons une autre augmentation de la taille de la VM de M ySQL1 . Elle passe a [CPU=100 ;M´moire=1536]. Cette augmentation s’ef` e fectue apr`s la migration de cette VM de la machine Node3 vers la machine e Node4 a cause de la n´cessit´ d’obtenir un quota CPU de 100, autrement ` e e dit, une machine enti`re. Cette augmentation de la taille de la VM par contre e n’entraˆ pas une baisse significative du temps de r´ponse. En effet, le nombre ıne e important de requˆte RUBIS ´mises ` ce stade du benchmark empˆche les sere e a e veurs d’avoir du repos. C’est ce que nous observons en (c). – En (c) nous observons une mont´e du temps de r´ponse qui entraˆ l’ajout e e ıne d’une nouvelle VM d’ex´cution d’un nouveau serveur MySQL (M ySQL2 ). e Cette VM s’ex´cute sur la machine Node3 compte tenue de sa petite taille e initiale. – En (d), les fluctuations de temps de r´ponses sont dues ` la pr´sence de deux e a e serveurs MySQL de tailles diff´rentes, alors que le nombre de requˆtes ´mis e e e est important. En effet, la petite VM fournit un temps de r´ponse sup´rieure e e a celui de la grande VM. De plus, les requˆtes ne sont pas intelligemment ` e distribu´es aux deux serveurs en fonction de leur taille. Une exp´rimentation e e plus aboutie pourra prendre en compte la reconfiguration du r´partiteur de e requˆtes MySQL-Proxy afin que celui-ci sollicite les serveurs en fonction de e leur taille. Syst`me d’administration autonome adaptable : application au Cloud e

´ 10.2. EVALUATIONS

142

Apr`s cette ajout du serveur MySQL, l’IaaS n’acceptera plus d’ajout de VM e tant que des ressources suppl´mentaires ne lui seront pas allou´es (ou en cas e e de lib´ration de ressources). e – En (e) nous observeront l’augmentation de la taille de la VM de M ySQL2 jusqu’` la taille [CPU=75 ;M´moire=1024]. L’IaaS 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 ;M´moire=1536]. e Par soucis de lisibilit´ des courbes, nous avons limit´ les valeurs de temps e e de r´ponse sur la courbe rouge au seuil maximal de 40 secondes. Les valeurs e sup´rieures a ce seuil, repr´sent´es par la zone (e), ne sont pas visibles dans la e ` e e figure. – 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 finir, la baisse continuelle de la charge provoquera le retrait d’un serveur MySQL (M ySQL2 , car scalabilit´ ordonn´e), 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

Syst`me d’administration autonome adaptable : application au Cloud e

` 10.3. SYNTHESE

143

10.3

Synth`se e

Dans ce chapitre, nous avons pr´sent´ diff´rentes ´valuations des aspects de l’ade e e e ministration d’une plateforme de cloud simplifi´e CloudEngine avec le SAA TUe NeEngine. Ces ´valuations ont ´galement pris en compte l’administration par TUe e NeEngine des applications s’ex´cutant dans le cloud. Les aspects de l’administration e que nous avons ´valu´s sont : e e – Deux politiques de r´paration de VM dans le cloud. La premi`re m´thode e e e dite non collaborative r´duit l’efficacit´ des applications s’ex´cutant dans le e e e cloud. Quant ` la seconde, son impact n’est visible que lorsque survient une a panne de VM. Comme nous l’avons ´voqu´e, cet impact peut ˆtre minimis´ e e e e par l’introduction 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 afin d’allouer efficacement des VM. e – Une politique de consolidation : nous avons montr´ l’utilisation de TUNeEne gine dans le cloud pour l’implantation d’une politique de consolidation lorsque les VM r´serv´es par les entreprises ne sont pas utilis´es efficacement (sous e e e utilis´es). e – Pour finir, nous avons ´valu´ deux sc´narios mettant en valeur les apports d’une e e e gestion simultan´e de ressources par plusieurs les deux niveaux d’utilisation de e TUNeEngine dans le cloud : consolidation au niveau de l’IaaS et scalabilit´ au e niveau application entreprise. Le but de ces exp´riences n’a pas ´t´ d’´valuer de fa¸on exhaustive tous les sc´nae ee e c e rios d’administration avec TUNeEngine dans le cloud. Il s’agissait de prouver d’une part l’aspect fonctionnel de TUNeEngine et d’autre part son adaptation ` diff´rents a e sc´narios d’administration. e

Syst`me d’administration autonome adaptable : application au Cloud 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 ann´es ont vu le d´veloppement d’une nouvelle pratique d’h´e e e e bergement : le Cloud Computing. Le principe fondateur de cette pratique est de d´porter la gestion des services informatique des entreprises dans des centres d’h´e e bergement g´r´s par des entreprise tiers. Ce d´port a pour principal avantage une ee e r´duction des coˆts pour l’entreprise cliente, les moyens n´cessaires ` la gestion de e u e a ces services ´tant mutualis´s entre clients et g´r´s par l’entreprise h´bergeant ces e e ee e services. Cette ´volution implique la gestion de structures d’h´bergement ` grande e e a ´chelle, que la dimension et la complexit´ rendent difficiles ` administrer. Pr´sent´ e e a e e dans la litt´rature comme une nouvelle technologie, nous retenons de l’´tude du e e Cloud Computing qu’il s’agit globalement d’une plateforme de grille ou centre d’h´e bergement fournissant a ses clients des services de plus ou moins haut niveau. ` L’´tude des probl`mes que nous avons men´e autour du Cloud Computing fait e e e ressortir deux difficult´s majeures : l’isolation (des d´faillances, des ressources, des e e utilisateurs) et l’administration dans son ensemble (y compris les applications qu’il ex´cutent). Ces deux d´fis jouent un rˆle important dans le processus de vulgarisation e e o et d’adoption du cloud aupr`s des entreprises clientes. Comme nous l’avons pr´sent´ e e e dans ce document, le d´fi d’isolation est r´solu dans la plupart des plateformes de e e cloud par l’utilisation des syst`mes de virtualisation comme couche interm´diaire e e entre les ressources du cloud et les clients. Quant ` l’administration dans le cloud, a l’´tude des travaux de recherches effectu´s 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 l’administration. Cette ´tude r´v`le notamment des besoins d’administration a des niveaux e e e ` diff´rents (h´bergeur, client). e e Notre contribution dans ce contexte a ´t´ de fournir, sur les bases d’un syst`me ee e d’administration autonome (SAA), une plateforme permettant d’administrer ` la fois a des plateformes quelconques de cloud ainsi que les applications entreprises qu’elles h´bergent. Notre choix port´ sur l’utilisation d’un SAA a ´t´ naturellement motiv´ e e ee e par l’aptitude qu’ont montr´s les SAA a fournir des solutions d’administration dans e ` des infrastructures de grilles, proches du cloud. C’est ainsi que nous avons entrepris d’utiliser notre SAA TUNe pour l’administration dans le cloud. La difficult´ d’adaptation du syst`me TUNe pour le cloud nous a amen´ ` concee e ea voir et ` implanter une nouvelle plateforme hautement adaptable et g´n´rique de a e e telle sorte qu’elle pourra prendre en compte diff´rents domaines applicatifs (parmi e lesquels le cloud). Nous avons propos´ dans cette th`se un mod`le de conception et de d´veloppee e e e ment des SAA hautement adaptables et g´n´riques. Dans un premier temps, nous e e avons identifi´ un ensemble de crit`res essentiels que devront respecter de tels syse e t`me. Il s’agit de l’uniformit´ des ´l´ments administr´s (revenant a ne pas figer e e ee e ` certains m´canismes dans le SAA), de l’adaptabilit´ du SAA et de sa capacit´ a e e e ` collaborer/interagir avec d’autres SAA. Ensuite, nous avons pr´sent´ un mod`le are e e chitecturale prenant en compte ces crit`res et remplissant les services d’un SAA. e Pour valider ce mod`le, nous avons d´velopp´ un SAA (inspir´ de TUNe) et con¸u e e e e c selon notre approche. Il s’agit en quelque sorte d’un exoSAA baptis´ TUNeEngine. e Ce dernier a par la suite ´t´ adapt´ (crit`re d’adaptabilit´) afin de prendre en compte ee e e e l’administration des plateformes de cloud. En ce qui concerne l’administration dans le cloud, nous avons con¸u une platec forme simplifi´e de cloud (CloudEngine), dont les composants sont clairement idene tifiables (contrairement aux autres plateformes), afin de montrer la prise en compte de toutes les facettes de l’administration dans le cloud. Ainsi, nous avons adapt´ e le syst`me TUNeEngine pour la r´alisation des tˆches d’administration suivantes : e e a construction d’images de VM et t´l´chargement dans le cloud ; d´ploiement, confiee e guration, et d´marrage des services de CloudEngine ; d´ploiement et d´marrage des e e e machines virtuelles dans le cloud ; r´parations des machines virtuelles ; et int´gration e e de quelques politiques d’allocation de ressources dans le clouds. Dans le mˆme ordre e d’id´es, nous avons montr´ comment le syst`me TUNeEngine peut ˆtre utilis´ pour e e e e e l’administration des applications entreprises dans le cloud. Cette utilisation va de l’interop´rabilit´ avec le cloud pour l’allocation dynamique des machines virtuelles, e e au d´ploiement et suivi de l’ex´cution des applications dans le cloud. e e Pour finir, nous avons identifi´ quelques sc´narios d’´valuations de notre SAA e e e TUNeEngine appliqu´ a la plateforme de cloud CloudEngine, ce qui correspond a e` ` notre probl´matique initiale. C’est ainsi que nous avons ´valu´ dans un premier e e e temps deux m´thodes de r´parations de VM dans le cloud. Ensuite, nous avons e e explor´ quelques sc´narios de consolidation de VM dans le cloud pour une gestion e e

Syst`me d’administration autonome adaptable : application au Cloud e

11.2. PERSPECTIVES

146

efficace de l’utilisation des ressources. Enfin nous avons montr´ comment la gestion e de ressources dans le cloud est li´e a celle r´alis´e par les applications entreprises e ` e e qu’il h´berge. Nous constatons par exemple que certaines m´thodes de scalabilit´ ou e e e d’allocation de VM au niveau application entreprise sont propices a la consolidation ` au niveau du cloud.

11.2

Perspectives

Tout au long de la r´alisation de cette th`se, nous avons identifi´ diff´rents 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 class´s en deux cat´gories : les travaux r´alisables dans un futur proche, et ceux e e e r´alisables 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 l’adaptabilit´ de notre SAA TUNeEngine, pourra consister a l’utiliser pour l’am´lioration e ` e de l’administration des plateformes de cloud existantes. A ce sujet, nous avons initi´ e une adaptation de TUNeEngine pour l’encapsulation 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) d’enrichir les capacit´s de reconfiguraa e tion de VM, jusque l` difficilement int´grables dans OpenNebula. a e Clouds hybrides : Administr´e par TUNeEngine, notre plateforme de cloud e CloudEngine se contente actuellement du composant de collaboration propos´ par e le syst`me TUNeEngine pour l’interaction avec des syst`mes externes. Cette collaboe e ration a ´t´ exp´riment´e uniquement dans le contexte o` les syst`mes externes sont ee e e u e ´galement administr´s par TUNeEngine. Nous proposons d’´tendre ces exp´rimene e e e tations a d’autres plateformes externes utilisant d’autres syst`mes d’administration ` e comme Eucalyptus [80] ou OpenNebula [OpenNebula]. Une premi`re approche de e cette interop´rabilit´ pourra consister a ´tendre le composant de collaboration de e e ` e TUNeEngine, utilis´ par CloudEngine, par des API WSDL compatible EC2. Dans e l’attente d’une standardisation des API d’interop´rabilit´, EC2 est utilis´ actuellee e e ment par plusieurs plateformes de cloud. Int´gration de programmes de reconfiguration e Dans sa premi`re validation, le syst`me TUNeEngine reprend et offre tous les e e services du syst`me TUNe. En particulier, sa prise en compte des programmes de e reconfiguration n´cessite la description du programme sous forme d’automates. Dans e le cadre d’une collaboration courante avec le Laboratoire Informatique de Grenoble Syst`me d’administration autonome adaptable : application au Cloud e

11.2. PERSPECTIVES

147

(LIG), les composants d’interpr´tation et d’ex´cution des programmes de reconfigue e ration ont ´t´ adapt´s pour la prise en compte des programmes de reconfiguration ee e implant´s sous forme de programmes Java. En effet, 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 contrˆles dans le syst`me TUNeEngine, o e g´n´r´s par un syst`me externe. e ee e Construction d’images L’implantation actuelle de notre plateforme de cloud ainsi que son constructeur d’images de VM se limitent aux distributions Linux CentOS. En effet, les techniques de construction d’images et d’initialisation r´seau des machines virtuelles d´pendent e e du type d’OS contenu dans l’image. Dans ce premier prototype, nous nous sommes limit´s dans nos travaux a une unique distribution. Dans le futur, nous comptons e ` ´tendre cette construction d’images a d’autres distributions Linux. Dans l’attente e ` d’un langage standard d’expression de contenu d’images de VM, nous pourrons nous appuyer sur le format de description d’images OVF (Open Virtual Format) de VMWare (le plus ´tendu). e Prise en compte d’autres hyperviseurs Dans notre implantation actuelle, le VMController (charg´ de l’interfa¸age avec e c les hyperviseurs) de CloudEngine ne prend en compte que les hyperviseurs de type Xen. Nous comptons faire ´voluer l’implantation de ce composant via l’utilisation e des librairies de virtualisation libvirt [lib]. De cette fa¸on, nous pourront ´tendre c e CloudEngine pour la prise en compte des autres syst`mes de virtualisation. e Gestion des utilisateurs Pour finir, la gestion des utilisateurs n’a pas figur´ parmi nos pr´occupations e e initiales. Dans la suite, nous pourront associer a CloudEngine un module de gestion ` d’utilisateurs et d’authentification. Ainsi, il pourra fournir a chaque utilisateur des ` modes de gestion personnalis´e de VM. e Int´gration d’Entropy e Malgr´ leur pertinences, les politiques de consolidation et de placement de VM e dans notre plateforme actuelle de cloud sont simplistes. En effet, elles ne repr´sentent e pas le cœur de nous pr´occupations dans ce travail de th`se. Cependant, il est envie e sageable d’int´grer dans la personnalisation TUNeEngine pour l’administration 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 cat´gorie, constitue une perspective int´ressante. e e e Auto r´paration de TUNeEngine e Dans son implantation actuelle, le syst`me TUNeEngine ne peut r´sister a une e e ` panne d’un de ses composants. L’apparition d’une telle panne paralyserait le syst`me. e Une am´lioration de TUNeEngine pour la tol´rance aux pannes pourrait consister e e a utiliser l’implantation Fractal HA pour la construction de ses composants. En ` effet, Fractal HA fournit un m´canisme de r´plication de composants et maintien la e e

Syst`me d’administration autonome adaptable : application au Cloud e

11.2. PERSPECTIVES

148

coh´rence entre les r´plicas. De cette fa¸on, un composant en panne sera remplac´ e e c e par son r´plica et ce dernier sera dupliqu´ de nouveau. e e

11.2.2

Perspectives ` long terme a

´ Edition de DSL TUNeEngine n’est actuellement utilisable qu’au travers d’interfaces de bas niveau que sont l’ADL et les API de Fractal. Dans le cadre de notre projet de recherche, une autre th`se s’int´resse ` la conception d’un environnement permettant la conception e e a de DSL. Comme nous l’avons ´voqu´ dans l’´tude des probl´matiques du syst`me e e e e e TUNe (inspirateur de TUNeEngine), cette plateforme de conception de DSL g´e n´rera pour chaque langage les adaptations n´cessaires a leur prise en compte par e e ` TUNeEngine. Autrement dit, ` chaque DSL sera associ´e une personnalisation de a e TUNeEngine. De cette fa¸on, nous pourront notamment d´finir un langage d’expresc e sion de besoin d’administration dans le cadre du Cloud.

Syst`me d’administration autonome adaptable : application au Cloud e

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 : Grid’5000 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 48–57. 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). Specification and Implementation of Dynamic Web Site Benchmarks. In EEE 5th Annual Workshop on Workload Characterization (WWC-5). Austin, TX. Syst`me d’administration 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 scientific computing. Concurr. Comput. : Pract. Exper., 18 :215–229. [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 Warfield, A. (2003). Xen and the art of virtualization. In ACM symposium on Operating systems principles (SOSP’03), pages 164–177, 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., J´gou, 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). Grid’5000 : A Large Scale And Highly Reconfigurable Experimental Grid Testbed. Int. J. High Perform. Comput. Appl., 20(4) :481–494. [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 13–24, Washington, DC, USA. IEEE Computer Society. [27] Braham, P., Dragovic, B., Fraser, K., Hand, S., Haris, T., Alex, Neugebauer, R., Pratt, I., and Warfield, 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 l’administration autonome. e PhD thesis, INP Toulouse. [29] Broto, L., Hagimont, D., Stolf, P., Depalma, N., and Temate, S. (2008). Autonomic management policy specification in Tune. In SAC ’08 : Proceedings of the 2008 ACM symposium on Applied computing, pages 1658–1663, New York, NY, USA. ACM. [30] Bruneton, E., Coupaye, T., Leclercq, M., Qu´ma, V., and Stefani, J.-B. (2004). e An open component model and its support in java. In CBSE, pages 7–22. [31] Bruneton, E., Coupaye, T., Leclercq, M., Qu´ma, V., and Stefani, J.-B. (2006a). e The FRACTAL component model and its support in Java : Experiences with Syst`me d’administration autonome adaptable : application au Cloud e

Bibliographie

151

Auto-adaptive and Reconfigurable 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 Reconfigurable 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) :335–352. [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 435–436. [37] Chess, D. M., Segal, A., Whalley, I., and White, S. R. (2004). Unity : Experiences with a prototype autonomic computing system. In ICAC, pages 140–147. [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., Cr´gut, X., Dayd´, M., and Hagimont, D. (2008). e e Autonomic Management Policy Specification : From UML to DSML. In Czarnecki, K., Ober, I., Bruel, J.-M., Uhl, A., and V¨lter, M., editors, 11th Internatioo nal Conference on Model Driven Engineering Languages and Systems (MoDELS 2008), volume 5301 of LNCS, pages 584–599. 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 177–180. [ElasticHosts] ElasticHosts. Elastic Hosts. http://www.elastichosts.com/.

Syst`me d’administration autonome adaptable : application au Cloud e

Bibliographie

152

[45] Energy, W. E. . (2010). Microsoft, accenture and wsp environment & energy study shows significant 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 46–54. [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 47–68. Cambridge University Press. [57] Goldsack, P., Guijarro, J., Lain, A., Mecheneau, G., Murray, P., and Toft, P. (2003). Smartfrog : Configuration and automatic ignition of distributed applications. Technical report, HP. [58] Goth, G. (2007). Virtualization : Old technology offers 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 VEE’09, pages 41–50. [60] Horn, P. (2001). Autonomic computing : Ibm’s perspective on the state of information technology. Syst`me d’administration 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 15–22, 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 284–287, Washington, DC, USA. IEEE Computer Society. [69] Liu, H. and Parashar, M. (2003). Dios++ : A framework for rule-basedn autonomic management of distributed scientific applications. In Euro-Par, pages 66–73. [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 :341–352. [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 d´ploiement d’applications 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.

Syst`me d’administration autonome adaptable : application au Cloud e

Bibliographie [76] Microsoft. Windows azure : Microsoft’s http ://www.microsoft.com/windowsazure/. cloud services

154 platform.

[Mozilla] Mozilla. Mozilla firefox. http ://www.mozilla.org/fr/firefox/. [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., Youseff, L., and Zagorodnov, D. (2009). The eucalyptus open-source cloud-computing system. In Cappello, F., Wang, C.-L., and Buyya, R., editors, CCGRID, pages 124–131. IEEE Computer Society. [81] OMG (2007). Unified Modeling Language (UML) 2.1.2 Superstructure. Object Management Group, Inc. Final Adopted Specification. [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 412–421. [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., C´ceres, J., Ben-Yehuda, M., Emmerich, a W., and Gal´n, F. (2009). The reservoir model and architecture for open federated a cloud computing. IBM J. Res. Dev., 53 :535–545. [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 264–276, 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 :14–22. [90] Tchana, A., Temate, S., Combemale, B., Broto, L., and Hagimont, D. (2009). Exploitation des techniques de virtualisation pour l’administration autonome d’infrastructures logicielles r´parties. In Actes de la Conf´rence Francophone sur les e e Architectures Logicielles (CAL), Nancy, France. Editions C´padu`s, RNTI. e e Syst`me d’administration autonome adaptable : application au Cloud e

Bibliographie

155

[91] Toure, M. A. (2010). Administration d’applications r´parties ` 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 :56–69. [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. O’Reilly & 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 21–30. [Zynga] Zynga. Connecting the world through games. http ://www.zynga.com.

Syst`me d’administration autonome adaptable : application au Cloud e

Table des figures
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 virtualis´s . . . . . e e Techniques de virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

. 6 . 13 . 17 . 20

Architecture simplifi´e du Cloud . . . . . . . . . . . . . . . . . . . . . 23 e Administration dans le cloud . . . . . . . . . . . . . . . . . . . . . . . 27 Organisation d’un SAA . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Exemple d’une architecture J2EE . . . . . . . Exemple d’ADL : cas d’une 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 g´n´ral . . . . . . . . . . . . . . . . . . . . . . . 61 e e e La plateforme Rainbow . . . . . . . . . . Encapsulation d’un logiciel dans Accord Composition d’OpenNebula . . . . . . . Organisation d’Eucalyptus . . . . . . . . Organisation d’OpenStack . . . . . . . . Vue g´n´rale de Microsoft Azure . . . . . e e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 70 75 77 79 81 86 93 96 98 101 103

Mod`le d´taill´ de TUNeEngine . . . . . . . e e e Exemple d’architecture Fractal . . . . . . . . Soumission de commandes et Collaboration . Construction du SR . . . . . . . . . . . . . . D´ploiement et Undeploiement . . . . . . . . e Ex´cution de programmes d’administration . e CloudEngine . . . . . . . . . . . Vision synth´tique : int´gration e e utilisation de TUNeEngine pour prises dans le cloud. . . . . . . .

. . . . . . . . . . . . . . . . . . . . . 107 de CloudEngine ` TUNeEngine et a le d´ploiement d’applications entree . . . . . . . . . . . . . . . . . . . . . 109

157 9.3 9.4 Vue globale d’administration et d’utilisation de CloudEngine via TUNeEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 (a) Description d’une image de VM dans le SR de CloudEngine, (b) Description d’une VM dans le SR de CloudEngine, (c) Description du logiciel Apache dans le SR de l’instance TUNeEngine de niveau application Entreprise, et (d) Description d’une VM dans l’IaaS g´n´r´e e ee par le VMController de CloudEngine. . . . . . . . . . . . . . . . . . . 122

Environnement mat´riel de notre IaaS . . . . . . . . . . . . . . . . . 125 e Coˆt du checkpointing dans la r´paration de VM dans l’IaaS . . . . . 128 u e R´paration de VM de l’IaaS par checkpointing . . . . . . . . . . . . . 129 e R´paration collaborative de VM . . . . . . . . . . . . . . . . . . . . . 130 e R´capitulatif de quelques situations n´cessitant scalabilit´ et de consoe e e lidation dans le cloud et les applications qu’il h´berge . . . . . . . . . 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 l’IaaS, (b) Evolution du nombre de VM par machine de l’IaaS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 10.8 Scalabilit´ niveau application J2EE et Consolidation de VM niveau e IaaS : r´sum´ de l’exp´rimentation . . . . . . . . . . . . . . . . . . . 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 : r´sum´ de l’exp´rimentation . . . 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

Syst`me d’administration autonome adaptable : application au Cloud e

158

Syst`me d’administration autonome adaptable : application au Cloud e

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->