tchana

8/2/2019 tchana

1/171

M :

Institut National Polytechnique de Toulouse (INP Toulouse)

Mathmatiques Informatique Tlcommunications (MITT)

Systme d'Administration Autonome Adaptable: application au Cloud

mardi 29 novembre 2011

Alain-B. TCHANA

Sret de logiciel et calcul de haute performance (SLCHP)

Mr. Nol DE PALMAMr. Jean-Marc MENAUD

Mr. Daniel HAGIMONT

Institut de Recherche en Informatique de Toulouse (IRIT)

Mr. Nol DE PALMA, Universit Joseph Fourier, RapporteurMr. Jean-Marc MENAUD, Ecole des Mines de Nantes, Rapporteur

Mr. Michel DAYDE, Institut National Polytechnique de Toulouse, ExaminateurMr. Maurice TCHUENTE, Universit de Yaound I, Examinateur

Mr. Daniel HAGIMONT, Institut National Polytechnique de Toulouse, Directeur de ThseMr. Laurent BROTO, Institut National Polytechnique de Toulouse, Examinateur

8/2/2019 tchana

2/171

TH ESE

soutenue en vue de lobtention du titre de

DOCTEUR DE LUNIVERSIT E DE TOULOUSE

Specialite : INFORMATIQUE

delivree par

lINSTITUT NATIONAL POLYTECHNIQUE DE TOULOUSE

Systeme dadministration autonome adaptable :application au Cloud

Presentee et soutenue publiquement par

Alain-B. TCHANA

le 29/11/2011, devant le jury compose de :

Mr. Jean-Marc MENAUD Ecole des Mines de Nantes RapporteurMr. Noel DE PALMA Universite Joseph Fourier RapporteurMr. Maurice TCHUENTE Universite de Yaounde I ExaminateurMr. Michel DAYDE Institut National Polytechnique de Toulouse ExaminateurMr. Laurent BROTO Institut National Polytechnique de Toulouse Co-Directeur de the

Mr. Daniel HAGIMONT Institut National Polytechnique de Toulouse Directeur de these

Ecole doctorale MITT : Mathematique, Informatique, Telecommunication de ToulouseDirecteur de these : Daniel HAGIMONT(IRIT, ENSEEIHT)

Laboratoire : Institut de Recherche en Informatique de Toulouse - UMR 5505-IRIT/ENSEEIHTCNRS - INP - UPS - UT1 - UTM

118 Route de Narbonne, 31062 Toulouse Cedex 09. Tel : 05.61.55.67.65

8/2/2019 tchana

3/171

ii

8/2/2019 tchana

4/171

A Helene Marechau. Je ne trouverai jamais assez demots, ni despace, ni de temps pour te dire a quel point ton aide ma ete capitale Helene. Jai toujours imagine

plus jeune (au secondaire) que toute these aboutissait sur une decouverte ou une invention. Ta rencontre sera

ma plus grande trouvaille de ces dernieres annees et jespere quelle le restera.

Hommage au systeme educatif

Francais pour mavoir accueilli et nance ma these.

Alain TCHANA .

8/2/2019 tchana

5/171

8/2/2019 tchana

6/171

Remerciements

Je tiens initialement à remercier tous les membres du jury pour le temps quevous avez consacre a levaluation de mon travail. Merci à mes rapporteurs No el DePALMA et Jean-Marc MENAUD ` a qui a ete conee la responsabilite de critiquer laforme et le fond de mon travail. Merci a Michel DAYDE qui a accepte de presider le jury et dexaminer mon travail. Merci a Maurice TCHUENTE qui ma fait lhonneurdu deplacement du Cameroun, lieu o` u jai acquis les bases des connaissances misesa prot dans cette these.

Merci a mon directeur de these Daniel HAGIMONT et co-Directeur LaurentBROTO. Vous mavez mis dans les conditions ideales pour realiser cette these, tantsur le plan professionnel que personnel. Je dois a Daniel (le lieutenant Dan) mes mo-destes qualites redactionnelles, desprit critique et de recul dans la realisation dun

travail de recherche. Laurent, tu as ete une des premieres personnes qui ma impres-sionne techniquement dans les domaines de linformatique et de la mecanique. Tuas reussi a me transmettre ta serenite face ` a tout probleme et systeme informatique.En dehors du laboratoire, vous avez ete tous les deux ma seconde famille. Je vousai souvent presente ` a la fois comme encadreurs, tuteurs et potes. Ce fut un bonheurde travailler avec vous et jespere continuer.

Un grand merci a nos admirables secretaires Sylvie ARMENGAUD et SylvieEICHEN. Vous etes exceptionnelles dans votre travail et vous avez contribue ` a faci-

liter le mien.

Je remercie la grande equipe ASTRE, multi-culturelle et tres animee dans letravail. Merci au professeur TOURE Mohamed qui ma accueilli et traite commeun frere durant son sejour dans cette equipe. Merci ` a Suzy TEMATE qui apportaittoujours la lumiere et la fracheur dans le bureau. Un merci ` a Aeman GADAFI avecqui jai passe de longues nuits de travail au laboratoire amenant son epouse a sedemander qui est ce Alain. Merci a Raymond ESSOMBA, Larissa MAYAP et TranSON avec qui jai termine dans une bonne ambiance mon sejour au sein de lequipe.

Je remercie les membres du grain : le moussokologueAmadou BAGAYOKO quia toujours laisse sa porte ouverte à toute heure ; le jeune Bang SAMBOU et Me-kossou BAKAYOKO pour votre amitie et disponibilite ; ` a Cheik OUMAR AIDARA,Aboubakar DIALLO et Cheik TALL pour vos debats houleux et enrichissants lessoirs de foot. Tachez toujours de faire respecter les fondamentaux.

Je ne saurai oublier ma tres grande famille qui ma toujours soutenu dans tousmes choix. Vous constituez une grande partie de mes motivations et jespere toujoursvous faire honneur. Un merci particulier à mon pere et ma mere qui ont toujours mislecole au centre de tout. Merci a la 1759 qui represente un membre permanent dela famille auquel je peux faire appel a tout moment :).

v

8/2/2019 tchana

7/171

8/2/2019 tchana

8/171

8/2/2019 tchana

9/171

Abstract

Last years have seen the development of cloud computing. The main underlyingprinciple of to externalize the management of companies IT services in hosting

centers which are managed by third party companies. This externalization allowssaving costs for the client company, since the resources required to manage theseservices are mutualized between clients and managed by the hosting company. Thisorientation implies the management of large scale hosting centers, whose dimensionand 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 automa-tized management of these environments. We refer to these system as Autonomic

Management Systems (AMS). They aim at providing services which automate admi-nistration tasks such as software deployment, fault repair or dynamic dimensioningaccording to a load.

Therefore, in this context, it is natural to consider the use of AMS for the ad-ministration of a cloud infrastructure. However, we observe that currently availableAMS have been designed to address the requirements of a particular application do-main. It should be possible to adapt an AMS according to the considered domain, inparticular that of the cloud. Moreover, in the cloud computing area, different requi-rements have to be accounted : those of the administrator of the hosting center andthose of the user of the hosting center (who deploys his application in the cloud).Therefore, an AMS should be adaptable to fulll such various needs.

In this thesis, we investigate the design and implementation of an adaptableAMS. Such an AMS must allow adaptation of all the services it provides, accordingto the domains where it is used. We next describe the application of this adaptableAMS for the autonomic management of a cloud environment.

viii

8/2/2019 tchana

10/171

Table des matieres

1 Introduction 1

2 Le cloud 4

2.1 Le Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.1 Generalites et Denition . . . . . . . . . . . . . . . . . . . . . 52.1.2 Cloud vs Grilles . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.4 Beneces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.5 Classication . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.5.1 Par raison de developpement . . . . . . . . . . . . . 102.1.5.2 Par niveau de service . . . . . . . . . . . . . . . . . . 11

2.1.6 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.6.1 Isolation . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.6.2 Administration . . . . . . . . . . . . . . . . . . . . . 142.1.6.3 Interoperabilite et Portabilite . . . . . . . . . . . . . 14

2.2 Isolation par la virtualisation . . . . . . . . . . . . . . . . . . . . . . 162.2.1 Denition et Principes . . . . . . . . . . . . . . . . . . . . . . 162.2.2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.3 Beneces pour les entreprises . . . . . . . . . . . . . . . . . . 182.2.4 Classication . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.5 Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Administration dans le Cloud 223.1 Administration niveau IaaS . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.1 Allocation de ressources . . . . . . . . . . . . . . . . . . . . . 243.1.2 Deploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.1.3 Conguration et Demarrage . . . . . . . . . . . . . . . . . . . 253.1.4 Reconguration . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.5 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2 Administration niveau Entreprise . . . . . . . . . . . . . . . . . . . . 273.2.1 Construction de VM et Deploiement . . . . . . . . . . . . . . 28

3.2.2 Allocation de ressources . . . . . . . . . . . . . . . . . . . . . 293.2.3 Conguration et Demarrage . . . . . . . . . . . . . . . . . . . 293.2.4 Reconguration . . . . . . . . . . . . . . . . . . . . . . . . . . 30

8/2/2019 tchana

11/171

3.2.5 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3 Synthese : systeme dadministration autonome pour le cloud . . . . . 31

4 Administration Autonome 324.1 Denition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.3 Beneces pour les entreprises . . . . . . . . . . . . . . . . . . . . . . 344.4 Classication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.5 Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5 TUNe 375.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.2 Principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2.1 Architecture Description Language (ADL) . . . . . . . . . . . 395.2.2 Wrapping Description Language (WDL) . . . . . . . . . . . . 415.2.3 Reconguration Description Language (RDL) . . . . . . . . . 42

5.3 Choix dimplantation . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.4 Experimentations et Problematiques . . . . . . . . . . . . . . . . . . 46

5.4.1 Applications cluster . . . . . . . . . . . . . . . . . . . . . . . . 465.4.2 Applications large echelle : cas de DIET . . . . . . . . . . . . 475.4.3 Applications virtualisees . . . . . . . . . . . . . . . . . . . . . 48

5.4.4 Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.5 Synthese et nouvelle orientation . . . . . . . . . . . . . . . . . . . . . 52

6 Orientation generale 546.1 Caracteristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.1.1 Uniforme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.1.2 Adaptable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.1.2.1 Adaptation des comportements . . . . . . . . . . . . 576.1.2.2 Extensibilite . . . . . . . . . . . . . . . . . . . . . . 58

6.1.3 Interoperable et Collaboratif . . . . . . . . . . . . . . . . . . . 59

6.1.4 Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606.2 Approche generale et Modele Architectural . . . . . . . . . . . . . . . 60

6.2.1 Approche Generale . . . . . . . . . . . . . . . . . . . . . . . . 606.2.2 Modele Architectural . . . . . . . . . . . . . . . . . . . . . . . 616.2.3 Prise en compte des caracteristiques . . . . . . . . . . . . . . . 64

6.3 Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

7 Etat de lart 657.1 SAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.1.1 Rainbow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677.1.2 Accord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697.1.3 Unity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

x

8/2/2019 tchana

12/171

7.1.4 Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737.2 SAA pour le cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.2.1 OpenNebula . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747.2.2 Eucalyptus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777.2.3 OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787.2.4 Microsoft Azure . . . . . . . . . . . . . . . . . . . . . . . . . . 807.2.5 Autres plateformes de cloud . . . . . . . . . . . . . . . . . . . 83

7.3 Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

8 Contributions : TUNeEngine 858.1 Modele detaille de TUNeEngine . . . . . . . . . . . . . . . . . . . . . 86

8.1.1 Soumission de commandes et Collaboration . . . . . . . . . . 878.1.2 Construction du SR . . . . . . . . . . . . . . . . . . . . . . . . 878.1.3 Deploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898.1.4 Conguration, Demarrage . . . . . . . . . . . . . . . . . . . . 908.1.5 Reconguration . . . . . . . . . . . . . . . . . . . . . . . . . . 91

8.2 Le formalisme a composants Fractal . . . . . . . . . . . . . . . . . . . 928.3 Implantation de TUNeEngine . . . . . . . . . . . . . . . . . . . . . . 94

8.3.1 Le composant TUNeEngine . . . . . . . . . . . . . . . . . . . 948.3.2 Soumission de commandes et Collaboration . . . . . . . . . . 958.3.3 Construction du SR . . . . . . . . . . . . . . . . . . . . . . . . 96

8.3.4 Deploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988.3.5 Execution de programmes dadministration . . . . . . . . . . . 100

8.4 Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

9 Contributions : application au Cloud 1049.1 Un IaaS simplie : CloudEngine . . . . . . . . . . . . . . . . . . . . . 105

9.1.1 Vision globale : CloudEngine-TUNeEngine, Application-TUNeEngine-CloudEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

9.1.2 RepositoryController . . . . . . . . . . . . . . . . . . . . . . . 1089.1.3 VMController . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119.1.4 VLANController . . . . . . . . . . . . . . . . . . . . . . . . . 1129.1.5 ResourceController . . . . . . . . . . . . . . . . . . . . . . . . 1129.1.6 MonitoringController . . . . . . . . . . . . . . . . . . . . . . . 1139.1.7 Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

9.2 Utilisation de CloudEngine . . . . . . . . . . . . . . . . . . . . . . . . 1149.2.1 Construction et enregistrement de VM . . . . . . . . . . . . . 1159.2.2 Administration dapplications . . . . . . . . . . . . . . . . . . 115

9.3 Reconguration dapplications et de CloudEngine . . . . . . . . . . . 1169.3.1 Reparation de VM . . . . . . . . . . . . . . . . . . . . . . . . 1169.3.2 Consolidation de VM et Scalabilite de serveurs . . . . . . . . . 117

9.3.2.1 Execution dapplications statique . . . . . . . . . . . 118

xi

8/2/2019 tchana

13/171

9.3.2.2 Execution dapplications variables . . . . . . . . . . 1189.4 Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

10 Experimentations 12310.1 Environnements dexperimentation . . . . . . . . . . . . . . . . . . . 124

10.1.1 LIaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12410.1.2 Les applications entreprises : RUBIS . . . . . . . . . . . . . . 12510.1.3 Les metriques . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

10.2 Evaluations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12610.2.1 Reparation de VM . . . . . . . . . . . . . . . . . . . . . . . . 126

10.2.1.1 Reparation non collaborative . . . . . . . . . . . . . 12710.2.1.2 Reparation collaborative . . . . . . . . . . . . . . . . 128

10.2.2 Scalabilite et Consolidation . . . . . . . . . . . . . . . . . . . 13010.2.2.1 Scalabilite . . . . . . . . . . . . . . . . . . . . . . . . 13010.2.2.2 Consolidation . . . . . . . . . . . . . . . . . . . . . . 13210.2.2.3 Scalabilite et Consolidation simultanees . . . . . . . 134

10.3 Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

11 Conclusion et perspectives 14411.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14411.2 Perspect ives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

11.2.1 Perspectives a court terme . . . . . . . . . . . . . . . . . . . . 14611.2.2 Perspectives a long terme . . . . . . . . . . . . . . . . . . . . 148

xii

8/2/2019 tchana

14/171

Chapitre 1

Introduction

Face a laugmentation continuelle des co uts de mise en place et de maintenancedes systemes informatiques, les entreprises externalisent de plus en plus leurs servicesinformatiques en les conant a des entreprises specialisees comme les fournisseurs declouds. Linteret principal de cette strategie pour les entreprises reside dans le faitquelles ne paient que pour les services effectivement consommes. Quant au four-nisseur du cloud, son but est de repondre aux besoins des clients en depensant leminimum de ressources possibles. Une des approches quutilise le fournisseur consistea mutualiser les ressources dont il dispose an de les partager entre plusieurs entre-prises. Dans ce contexte, plusieurs des, parmi lesquels lisolation (des ressources,defaillances, performances, espaces utilisateur) et ladministration optimale des res-sources, se posent pour permettre un reel developpement du cloud.

Actuellement, la plupart des developpements de plateformes de cloud utilisentla virtualisation [ 58] comme support technologique pour assurer lisolation. Ainsi,lunite dallocation de ressources dans le cloud est la machine virtuelle, autrementdit une portion de machine physique. Quant ` a ladministration dans le cloud, nousconstatons que les services fournis restent limites et sont plus ou moins semblablesdune plateforme a lautre. Il sagit essentiellement des services de reservation, dedemarrage et darret des machines virtuelles. Les t aches dadministration des ma-chines virtuelles et des applications des entreprises sont laissees ` a la charge desdifferents administrateurs. A titre dexemple, les operations de consolidation de ma-chines virtuelles ou encore de passage a lechelle des applications clientes doiventetre implantees par les administrateurs ` a travers des API de bas niveau. Lobjectif principal de cette these est la conception dun logiciel permettant ladministrationdu cloud dans son ensemble.

Depuis plusieurs annees, des chercheurs se sont interesses ` a la conception desystemes dadministration autonome (SAA). Ces systemes visent ` a fournir des ser-vices permettant dautomatiser les t aches dadministration comme le deploiement

des logiciels, la reparation en cas de panne ou leur dimensionnement dynamique enfonction de la charge. Nous observons un parfait parallele entre les apports de cessystemes dadministration autonome et les besoins dadministration dans le cloud.

8/2/2019 tchana

15/171

CHAPITRE 1. INTRODUCTION 2

Figure 1.1 Plan en U de ce document de these

En effet, dans les deux niveaux dadministration dans le cloud (cloud et applicationsquil execute), les administrateurs sont confrontes aux operations dinstallation (demachines virtuelles et des logiciels), de conguration, de depannage, dallocation deressources et autres t aches de reconguration. La principale difference entre ces deuxniveaux est la nature des entites administrees : les machines virtuelles au niveau ducloud (lhebergeur) et les logiciels applicatifs au niveau du client.

Dans le cadre de nos travaux dans le domaine de ladministration, nous avonsconcu et developpe un systeme dadministration autonome baptise TUNe [29]. Enplus de valider une approche de developpement des systemes dadministration au-tonome, TUNe a ete utilise pour ladministration de plusieurs types dapplications.Cependant, il sest relativement inadapte pour ladministration des systemes largeechelle ou virtualises. Ainsi, sur les bases de TUNe, nous proposons dans cette thesela conception dun SAA hautement exible et adaptable , pouvant etre notam-ment specialise pour une utilisation dans le cloud. Cette demarche de constructiondun SAA adaptable au cloud (et non specique au cloud) sexplique par le fait quenotre activite de recherche ne sinscrit pas (et ne sinscrira pas dans le futur) unique-ment dans la technologie du cloud, mais toujours dans ladministration autonome.

Compte tenu de la double problematique que nous adressons (construction dunSAA adaptable et application pour ladministration dans le cloud), lorganisation dece document de these suit globalement une trajectoire en U resumee par la gure 1.1 :

Partie I : Contexte du cloudCette partie est composee des chapitres 2 et 3. Le chapitre 2 presente le cloud etses apports dans les entreprises (tout en clariant quelques denitions) tandisque le chapitre 3 presente en quoi consiste les taches dadministration dans le

cloud. Partie II : Contexte SAACette partie regroupe les chapitres 4 et 5. Le chapitre 4 presente le contexte

Systeme dadministration autonome adaptable : application au Cloud

8/2/2019 tchana

16/171

CHAPITRE 1. INTRODUCTION 3

scientique quest ladministration autonome en parcourant quelques approchesde conception de SAA. Quant au chapitre 5, il presente le prototype de SAA

TUNe (developpe au sein de notre equipe) ainsi que ses difficultes ` a repondreaux besoins dadministration du cloud. Partie III : Positionnement

Cette partie regroupe les chapitres 6 et 7. Dans le chapitre 6, nous proposons uncanevas de conception dun SAA adaptable et generique. Quant au chapitre 7,il presente une etude des travaux de recherche effectues autour des SAA et desplateformes dadministration dans le cloud.

Partie IV : Contribution SAACette partie se resume au chapitre 8 dans lequel nous presentons limplantationdun SAA adaptable suivant le canevas que nous avons precedemment propose.

Partie V : Contribution CloudCette partie contient les chapitres 9 et 10. Le chapitre 9 presente la person-nalisation du SAA adaptable que nous avons implante, pour ladministrationdans le cloud. Quant au chapitre 10, il montre les evaluations de cette person-nalisation dans la realisation des t aches dadministration dans le cloud.


8/2/2019 tchana

17/171

Chapitre 2

Le cloud

Contents2.1 Le Cloud Computing . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Generalites et Denition . . . . . . . . . . . . . . . . . . . 52.1.2 Cloud vs Grilles . . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Principes . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.4 Beneces . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.5 Classication . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.5.1 Par raison de developpement . . . . . . . . . . . 102.1.5.2 Par niveau de service . . . . . . . . . . . . . . . 11

2.1.6 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.6.1 Isolation . . . . . . . . . . . . . . . . . . . . . . 132.1.6.2 Administration . . . . . . . . . . . . . . . . . . . 142.1.6.3 Interoperabilite et Portabilite . . . . . . . . . . . 14

2.2 Isolation par la virtualisation . . . . . . . . . . . . . . . . 162.2.1 Denition et Principes . . . . . . . . . . . . . . . . . . . . 162.2.2 Ob jectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.3 Beneces pour les entreprises . . . . . . . . . . . . . . . . 18

2.2.4 Classication . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.5 Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

8/2/2019 tchana

18/171

2.1. LE CLOUD COMPUTING 5

2.1 Le Cloud Computing

2.1.1 Generalites et Denition

Face a laugmentation continuelle des co uts de mise en place et de maintenancedes systemes informatiques, les entreprises externalisent de plus en plus leurs ser-vices informatiques. Elles conent leur gestion (des services informatiques) `a des en-treprises specialisees (que nous appelons fournisseurs ). Linteret principal de cettestrategie reside dans le fait que lentreprise ne paie que pour les services effective-ment consommes. En effet, une gestion interne de ces services par lentreprise ne

serait pas completement amortie, en particulier lorsque les besoins dutilisation va-rient. Le developpement de ce mode de fonctionnement a ete favorise par plusieursfacteurs tels que levolution et la generalisation des acces internet, laugmentationde la puissance des ordinateurs et des reseaux informatiques. Le Cloud Computing se situe dans cette orientation recente.

Devant le manque de consensus sur la denition de la notion de Cloud Compu-ting , nous reprenons la denition proposee par CISCO [21] : le Cloud Computing est une plateforme de mutualisation informatique fournissant aux en-treprises des services ` a la demande avec lillusion dune innite desressources . Dans cette denition, nous retrouvons quelques similitudes avec lesplateformes connues comme les grilles de calcul ou encore les centres dheberge-ment. Il est presente dans la litterature comme une evolution de ces infrastructuresdhebergement mutualisees. En guise dexemple, prenons levolution proposee par[49] (gure 2.1) qui est largement citee dans la litterature. Dapres [49], le cloudcomputing est le fruit dune evolution pouvant etre presentee en 5 phases :

Elle debute avec les Fournisseurs dAcces Internet (FAI 1.0). Ils ont pour butde mettre en place des moyens de telecommunication an dassurer le raccor-dement des personnes ou entreprises au reseau internet.

La seconde phase est lorientation des FAI vers lhebergement de pages web(FAI 2.0). Cette phase marque un grand bond dans le developpement dinter-net.

La troisieme phase (FAI 3.0) est la possibilite quoffrent les FAI ` a heberger desapplications metiers des entreprises.

Une connaissance des besoins applicatifs des entreprises permettent aux FAIde faire evoluer leur domaine dintervention. Ils mettent en place des plate-formes de generation dapplications ` a la demande. Il sagit des ASP (Appli-cation Service Provider) dont les Software as a Service (section 2.1.5.2) sontdes derives : cest le FAI 4.0.

La generalisation des pratiques precedentes, la prise en compte de nouvellespratiques et lintegration des principes que nous presentons dans les sections

suivantes donnent naissance au cloud computing.Suivant cette evolution, nous presentons dans la section suivante notre point devue concernant la position du cloud computing par rapport aux plateformes dhe-


8/2/2019 tchana

19/171


bergement mutualisees comme les grilles [65] (grid5000 [25], Globus [96]).N.B : Dans ce document, nous utilisons lacronyme CC pour designer la tech-

nologie Cloud Computing et le terme cloudpour parler dune plateforme de CloudComputing.

Figure 2.1 Evolution vers le Cloud

2.1.2 Cloud vs Grilles

Introduites pour la premiere fois dans les annees 90, les grilles de calcul situentla mutualisation au cur de leur technologie. De meme, la mutualisation est aucur de la technologie du CC. La question que nous nous posons : A quel niveause situe la difference entre le cloud et les grilles (si elle existe) ?. Autrement dit, leterme Cloud Computing nest-il pas une autre appellation de Grid Computing?Apres consultation de la litterature, nous ne trouvons quuneetude serieuse consacreeentierement `a cette comparaison ([ 51]). Le constat global de [51] est proche du notre.

Dun point de vue technologique nous nidentions pas de reelle difference entreles plateformes de grille et de cloud. Cependant, louverture du cloud aux utilisateursde differents niveaux (pas toujours des informaticiens comme dans les grilles) eteventuellement son caractere commercial sont les potentielles differences que nousidentions. De plus, dans les environnements de grilles, les applications (appeleesle plus souvent job) sexecutent generalement sur une duree limitee (meme si celle-ci peut etre illimitee comme dans le cloud). Comme nous le presentons dans lasection 3, ces differences rendent la gestion et lutilisation des plateformes de cloudplus complexes que dans les grilles.

Somme toute, nous considerons que la technologie de cloud computing utilise latechnologie de grille a laquelle elle associe les principes douverture au public, de


8/2/2019 tchana

20/171


facturation, et dhebergement durable. Dans la section suivante, nous detaillons cesdifferents principes.

2.1.3 Principes

Nous avons enonce dans la section precedente quelques principes fondamentauxdu cloud. Ces principes lui permettent de se demarquer des plateformes dheber-gement classiques (grille, data center, centre dhebergements). Les plus importantsdentre eux sont la mutualisation et la facturation des ressources a lusage :

La mutualisation . Cest la pratique qui consiste a partager lutilisation dunensemble de ressources par des entreprises (ou entites quelconques) nayant aucunlien entre elles. Les ressources peuvent etre de diverses natures : logicielles ou mate-rielles (machines, equipements reseau, energie electrique). Cette pratique depend dudesir des entreprises de delocaliser leurs services informatiques vers des infrastruc-tures de cloud.

Reposant sur les technologies de grilles, le cloud doit cependant faire face auxproblemes lies `a son exploitation et utilisation. Il sagit des problemes classiques telsque la securite, la disponibilite, lintegrite, la abilite et luniformite dacces auxdonnees.

Lallocation et facturation a la demande . Contrairement aux centres dhe-bergement web classiques dans lesquels le paiement se fait a lavance sous forme deforfait, le cloud propose une facturation `a lusage. Cette derniere peut etre implemen-tee de deux fa cons. La premiere consiste a facturer a lentreprise la duree dutilisationdun ensemble de ressources quelque soit lutilisation effective. Par exemple, soit r lensemble des ressources reservees par lentreprise. Soient t 1 et t 2 respectivementlinstant de debut et de n dutilisation des ressources. Soit C u le cout dutilisationdune ressource durant une unite de temps. Ainsi, le co ut total dutilisation de len-semble des ressources r est : C r =( t 2 -t 1 )* C u *r . Quant a la deuxieme fa con, elle estbeaucoup plus ne que la premiere. Elle consiste a facturer les veritables instants

pendant lesquels les ressources ont ete utilisees. En partant des memes parametresque precedemment, soit T= {t u 1 ,t u 2 , . . . , t un } avec t ui [ t 1 ;t 2 ], 1 i n , lensemble desunites de temps pendant lesquelles les ressources ont ete reellement utilisees. Dans cecas, le cout total dutilisation de lensemble des ressources r est : C r = C u *r* ni =1 t ui .

A la lumiere de ces pratiques, nous montrons dans quelle mesure les consequencesde lutilisation du cloud peuvent etre beneques ` a la fois pour le fournisseur et pourles entreprises qui y ont recours.


8/2/2019 tchana

21/171


2.1.4 Beneces

Les retombees des principes du cloud sont beneques ` a la fois pour son fournis-seur, les entreprises delocalisant leurs infrastructures et plus largement pour la na-ture (au sens ecologique). Globalement, ils assurent aux deux premiers une meilleurerentabilite. De plus ils permettent ` a lentreprise de se concentrer sur les t aches deproduction autres que la maintenance de systemes informatiques.

Pour le fournisseur

Les beneces du fournisseur sont uniquement d us au fait de la mutualisationdes ressources. En effet, apres son investissement dans la mise en place des infra-structures pour le cloud, il fait payer aux entreprises la marge necessaire pour sarentabilisation. Comme pour une entreprise disposant dune plateforme interne, ilpaie pour les frais dadministration de lensemble. Cette depense peut etre amortiepar facturation aux entreprises. En plus de cette marge, il benecie des co uts dereutilisation des ressources. En effet, compte tenu de la non appartenance des res-sources aux entreprises, elles (les ressources) leurs sont facturees `a chaque usage. Lameme ressource peut ainsi faire lobjet de plusieurs facturations.

Pour lenvironnement

A lere de lecologie et des politiques de reduction de la consommation energe-tique, linvestissement dans les plateformes de cloud represente un geste envers lanature. La mutualisation de ressources (telle que pratiquee dans le cloud) accompa-gnee par la delocalisation des infrastructures dentreprise vers les clouds permettentde reduire les consommationsenergetiques. Pour illustrer cette affirmation, reprenonsletude [45] realisee par le groupe WSP Environment & Energy (WSP E&E) 1 pourle compte de Microsoft a propos de la plateforme de cloud Azure [76]. Cette etudeest resumee dans sa conclusion : Moving business applications to the cloud can save30 percent or more in carbon emissions per user.. Elle montre que la delocalisationdes applications Microsoft Exchange Server 2007 [75] des entreprises vers le cloudMicrosoft Azure permet de reduire dau moins 30% les emissions CO 2 par utilisateurde chaque entreprise. Cette reduction sexplique par deux facteurs. Dune part, ladelocalisation permet de reduire le nombre et la taille des infrastructures informa-tiques en service. Ceci implique donc une reduction de la consommation energetique(donc moins de rejet de CO 2 ). Dautre part, le fournisseur Microsoft implante dansson cloud des techniques dutilisation efficace de ressources.

1. Groupe de Consulting en matiere denvironnement, denergie et de climat :www.wspenvironmental.com


8/2/2019 tchana

22/171


Pour lentreprise

Cest elle la premiere gagnante de cette technologie. Elle realise des beneces enargent et en exibilite dans sa capacite ` a sagrandir.

La reduction des co uts . Le recours au cloud permet a lentreprise detre factu-ree a lusage, en fonction de ses besoins. Pour avoir une idee du gain realise, reprenonscette observation de Michael Crandell du groupe RightScale [ RIGHSCALE ] a proposdu cloud dAmazon [61] : Le cout a pleine charge dun serveur sur Amazon se situeentre 70 $ et 150 $ par mois alors quil seleve a 400 $ en moyenne par mois sil etait heberge par lentreprise en interne . Plusieurs raisons expliquent cette difference decout. En effet, une gestion interne de linfrastructure implique lachat des materiels,laffectation du personnel (et donc du co ut salarial quil induit) pour la gestion delinfrastructure et divers moyens de production mis en place pour le fonctionnementde lensemble (electricite, locaux, etc). Le partage de ressources tel que pratique dansle cloud permet au fournisseur de repartir ces couts entre plusieurs entreprises.

La reduction des gaspillages . Les infrastructures gerees en interne sont sou-vent sous-utilisees, alors que linfrastructure dun cloud mutualise lensemble de res-sources pour un grand nombre dentreprises. La mutualisation consiste ` a mettre ala disposition de plusieurs utilisateurs une base commune de ressources. Elle per-met ainsi daugmenter le taux dutilisation de ces ressources. En effet, les ressources

netant pas dediees ` a un seul utilisateur, elles pourront servir ` a dautres en cas debesoin.

La exibilite et acces aux ressources large echelle . Lentreprise peut aug-menter la capacite de son infrastructure sans investissement majeur. En effet, gr acea lallocation dynamique ( a la demande) des ressources quoffre le cloud, il suffit desouscrire a de nouvelles ressources et celles-ci sont directement allouees. De plus,lentreprise est libre de ses allees et venues car les contrats dutilisation sont limitesdans le temps (autour de lheure). Ainsi, lentreprise peut augmenter ou reduire soninfrastructure `a sa guise a moindre cout et dans un delai reduit. Rappelons que le

cloud offre ainsi a lentreprise une possibilite dacceder ` a une quantite de ressourcesdont elle ne pourrait se loffrir en interne. Elle peut dorenavant envisager des ap-plications large echelle sans se soucier de lobtention des equipements. A ce sujet,on observe quelques derives avec des groupes qui acquierent un grand nombre deressources dans les clouds a des ns criminelles (decryptage de cle de securite oudenis de service en sont des exemples) 2 .

Notons que cette exibilite depend du type de cloud considere (section suivante).Par exemple, laugmentation de ressources dans un cloud de type entreprise ne serapas aussi rapide que dans un cloud de type fournisseur de services. Dans le premiercas, la decision est prise de facon collegiale (entre toutes les entreprises interve-

2. Attaque pour decryptage de la cle de securite des Network PlayStation de Sony enmai 2011


8/2/2019 tchana

23/171


nantes) et peut donc prendre un temps considerable. A loppose, dans le second cas,loperation se realise dans limmediat.

2.1.5 Classication

Avant de presenter les differents types de cloud pouvant etre developpes, nousetablissons dans un premier temps quelques criteres de classication :

La raison de developpement ( business model ). Cest la raison qui justie lamise en place de la plateforme. Elle peut etre commerciale, scientique oucommunautaire.

Le niveau de services. Cest lambition du cloud a fournir aux entreprises uneplateforme proche ou pas de leurs attentes.

Laccessibilite. Le cloud peut etre accessible par tous (cloud public) ou res-treint a un public particulier (cloud prive). Contrairement aux deux premiers,nous ne developpons pas celui-ci etant donne sa simplicite de comprehension.

2.1.5.1 Par raison de developpement

Lutilisation du CC ne se limite pas uniquement aux entreprises ` a caractere

commercial. En fonction des raisons de sa mise en place, nous distinguons quatrecategories de plateformes de CC a savoir :

Cloud dEntreprises . Dans cette categorie, nous retrouvons des entreprises depetites et de moyennes tailles disposant chacune de peu de ressources et de moyensde maintenance de leurs infrastructures. Elles se regroupent donc autour dun projetde cloud an de mutualiser leurs capacites. La plateforme qui en decoule est privee,cest-a-dire accessible uniquement par les entites des differentes entreprises. Cetteplateforme a lavantage detre de petite taille et dacces restreint ` a des utilisateursconnus. Ainsi, les problemes de securite sont reduits et ladministration peut etre

specialisee. Les groupes Amazon EC2 [ 61] (via le Virtual Private Cloud ), VM-ware [VMware.org] ou encore VeePee [VeePee ] offrent par exemple des solutions declouds prives.

En comparaison avec les technologies existantes, cette categorie est identique auxclusters prives.

Cloud Gouvernemental et Recherche Scientique . Pour des raisons derecherche et de developpement, des instituts de recherche mettent sur pied des en-vironnements de cloud. Leur developpement est encourage et nance par des gou-vernements. Lacces est exclusivement reserve aux personnes exer cant dans le memedomaine de recherche, ou appartenant aux instituts de recherche associes, ou ayantune derogation precise. Ces plateformes sont pour la plupart orientees projets. Seulesles avancees scientiques obtenues par les groupes de recherche qui lutilisent per-mettent de valoriser la plateforme.


8/2/2019 tchana

24/171


Dun point de vue technologique, dobjectif et dutilisation, aucune differencenest notable avec les grilles scientiques comme grid5000 [25].

Cloud pour Reseaux Sociaux et Jeux . Le developpement des reseaux so-ciaux et des jeux en ligne necessite de plus en plus de grandes quantites de ressources.Cette necessite est due ` a la croissance presque exponentielle dutilisateurs. De plus,lessence de ces environnements est la mise en commun dun certains nombre de don-nees et de connaissances (donc de ressources). Dans ce contexte, le developpementdune plateforme similaire au cloud devient une evidence pour optimiser lutilisa-tion des ressources et faciliter le partage de donnees. En effet, elles sont considereescomme plateforme de cloud a cause de leur recours aux principes de developpementde celui-ci.

Louverture de ces plateformes a tous et le nombre important dutilisateurs pour-raient constituer un handicap pour leur gestion. Or nhebergeant quune seule ap-plication (celle du fournisseur), leur gestion est specialisee et moins complexe. Ellessont comparables aux clusters/griles prives. Les plateformes comme celles du reseausocial facebook [facebook] ou des jeux en ligne zynga [Zynga] font partie de cettecategorie.

Cloud pour Fournisseurs de Services . Cest le modele le plus repandu. Uneentreprise, appelee fournisseur, met ` a la disposition dautres (appelees clients) uneplateforme dexecution dapplications et assure le service informatique inherent. Ilsagit dun modele ouvert a tout public et a caractere commercial. La plateformeheberge tous types dapplications et lacces ` a ces applications est ouvert aux utili-sateurs externes. Les des de securite et dadministration (que nous detaillons dansla section 2.1.6) sont importants dans ce modele. La plateforme de CC AmazonElastic Compute Cloud (EC2) fait partie de ce cette categorie. Sachant que cettecategorie peut regrouper les autres, les contributions que nous apportons dans cettethese sadressent `a cette categorie de cloud. Notons que quelque soit le modele dedeveloppement considere, la plateforme qui en decoule peut egalement etre classeeselon son niveau dutilisation (section suivante).

Notons quil existe des communautes de developpement logiciels autour de ces

categories de cloud. Elles fournissent des briques logicielles permettant de construi-re/enrichir une plateforme de cloud. Tres souvent, il sagit dentreprises dont le butest de deliser ses clients (futurs proprietaires de plateformes de cloud). Les logi-ciels sont presentes `a ces derniers comme une valeur ajoutee de levolution dunproduit existant (comme un systeme dexploitation). Ce developpement est le plussouvent pratique par des communautes de logiciels libres (plateforme Ubuntu En-terprise Cloud [Ubuntu ] ou Eucalyptus [80]) ou encore par des grands groupes dedeveloppement de logiciels specialises (Oracle Cloud Computing [ora]).


8/2/2019 tchana

25/171


2.1.5.2 Par niveau de service

En fonction du niveau dabstraction quoffre le cloud aux entreprises, nous iden-tions dans la litterature trois categories de plateformes de CC (gure 2.2(a)) :

Infrastructure as a Service (IaaS) . Cest le niveau de service le plus bas.Le cloud fournit des ressources materielles aux entreprises (capacite de traitement,de stockage, etc.). Lacces a ces ressources peut etre direct ou virtuel (section 2.2).On retrouve dans cette categorie les plateformes comme Amazon Elastic ComputeCloud (EC2) [61] et IELO Cloud [Cloud].

Platform as a Service (PaaS) . Il sagit dun niveau dabstraction au-dessusde lIaaS dans lequel le cloud fournit une plateforme applicative de programmation.Elle permet a lentreprise de programmer des applications facilement administrablesdans le cloud. Elle oblige lentreprise dune part a matriser lAPI du PaaS et dautrepart a re-implementer ses applications suivant cet API. Google App Engine [ 46] etWindows Azure [76] sont des exemples de PaaS.

Software as a Service (SaaS) . Ici, le cloud fournit directement les applica-tions correspondants aux attentes des entreprises. Les t aches dadministration sontassurees par le cloud ; lentreprise na pas grand chose `a effectuer. Tres specialise (parlapplication quil fournit), ce type de cloud est le moins repandu. Les clouds pour

reseaux sociaux et jeux (presentes precedemment) font partie de cette categorie.Comme exemple de plateforme SaaS, nous pouvons citer Rightscale [ RIGHSCALE ]ou encore CORDYS [CORDYS ].

Cette classication est la plus repandue dans la litterature. Dans le but devitertout malentendu, nous proposons dans le paragraphe suivant, une vision simpliee ducloud. Cette presentation est proche des clusters/grilles qui sont technologiquementidentiques au cloud.

Notre vision . Sans entrer en contradiction avec la presentation precedente,

nous considerons toute plateforme de cloud comme une plateforme ` a deux niveaux(gure 2.2(b)) : Abstraction et mutualisation des ressources. Ce niveau correspond exactement

a lIaaS dans la vision classique. Nous y retrouvons donc a la fois les ressourceset les applications permettant leur abstraction et mutualisation.

Les applications des entreprises et celles utiles a lexploitation du cloud. Il sagitaussi bien des applications du SaaS, des applications developpees ` a partir dunPaaS, que de celles issues ni du PaaS ni du SaaS. Pour aller plus loin, nousconsiderons le PaaS comme une application sexecutant sur lIaaS. De ce fait,il a le meme statut que les autres applications. Lun des des du cloud estlisolation de ces differentes applications.


8/2/2019 tchana

26/171


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

2.1.6 Challenges

Le CC nest pas une revolution technologique en soit mais constitue une orien-tation vers un mode de gestion des infrastructures informatiques des entreprises. Ce-pendant, lidee dheberger plusieurs applications dutilisateurs differents pose quelquesdes que doit surmonter le cloud. Il sagit de lisolation, ladministration, linterope-rabilite et la portabilite des applications entre plusieurs plateformes.

2.1.6.1 Isolation

La mutualisation de ressources dans le cloud (comme dans toutes les infrastruc-tures) implique la mise en place de divers mecanismes (securite, comptage de res-sources, conit dacces, etc). Le plus important de ces derniers est la gestion desconits/interferences dacces entres les utilisateurs. Une reponse ideale pour la miseen place de la mutualisation est lisolation. Nous regroupons sous ce terme plusieurstypes disolation a savoir : lisolation des ressources, lisolation despaces utilisateurs,

lisolation des performances et lisolation des defaillances. Lisolation des ressources (ou encore partitionnement) garantit au client

lexclusivite dacces a un ensemble de fractions (morceaux) de ressources du-rant toute sa presence dans le cloud (malgre la mutualisation). Le client alillusion detre le proprietaire et considere lensemble comme des machines en-tieres. Cette isolation permet deviter les situations de famine aux applicationsdu client (situation dans laquelle une application attend indeniment une res-source detenue par une autre). De plus, elle permet au fournisseur du clouddidentier et de compter les utilisations de ressources pour chaque utilisateur.Ce decompte servira par la suite `a la facturation.

Lisolation despaces utilisateurs donne a chaque client du cloud lillusiondetre le seul utilisateur. Rien ne doit le laisser presager la presence dautresutilisateurs ou applications. Illustrons cela ` a travers lexemple dun cloud four-


8/2/2019 tchana

27/171


nissant des environnements Linux. Dans cet environnement, chaque client peutacceder en mode super utilisateur ( root sous Linux) aux machines lui appar-

tenant. Cependant, lexecution de la commande ps -aux (affichage de la listedes processus) par exemple ne doit presenter que les processus demarres parlutilisateur en question.

Lisolation des performances permet au cloud dassurer le non monopoledes ressources globales du cloud par un seul client. Prenons lexemple desressources reseaux pour illustrer cela. Une utilisation intensive de la bandepassante sur le cloud par une application cliente peut affecter lensemble dureseau et ainsi avoir un impact sur les autres utilisateurs.

Lisolation des defaillances permet dassurer la non violation des espacesutilisateurs dans le cloud. Il comprend egalement le de de securite. En tantque centre dhebergement dapplications multi-utilisateurs, le cloud doit garan-tir lintegrite de chaque espace utilisateur vis-` a-vis des autres. Ainsi, aucuneaction malveillante realisee par un client ne doit alterer ni le fonctionnementdu cloud ni celui des applications appartenant ` a dautres clients. Cet objectif est dautant plus important que la plupart des utilisateurs du cloud sont nonidentiables. Il sagit des utilisateurs des services heberges par les entreprisesdans le cloud.

La prise en compte de ce de a ete effectuee grace a lintroduction des techniquesde virtualisation (section 2.2) dans limplementation du cloud.

2.1.6.2 Administration

Comme nous lavons presentee precedemment, lexploitation des plateformes decloud implique lintervention de trois types dutilisateurs : ladministrateur du cloud,les entreprises et les utilisateurs des applications des entreprises. Les deux premiers(administrateur et entreprises) sont confrontes quotidiennement ` a plusieurs t achesdadministration (pour la plupart repetitives). Lallegement de ces t aches conditionnelexpansion du cloud dans les entreprises. En effet, an deviter le meme constatobserve de lutilisation des grilles de calculs (reserves aux scientiques, donc aux

utilisateurs avertis), les plateformes de cloud doivent prendre en compte et faciliterles taches dadministration de ces deux utilisateurs. Comme nous le presentons dansla section 3, les operations dadministration effectuees par ces deux utilisateurs sontsemblables. Notons que lobjet de cette these porte essentiellement sur ce challenge.

2.1.6.3 Interoperabilite et Portabilite

Face a la multiplication des plateformes de cloud, les clients pourront etre confron-tes plus tard `a deux choix : (1) la migration dune application dun cloud vers un

autre et (2) lutilisation de plusieurs clouds pour lhebergement de la meme appli-cation. Le choix (1) se pose par exemple lorsque la concurrence entrane un client `apartir du cloud qui heberge son application vers un autre plus attrayant. Elle peut


8/2/2019 tchana

28/171


egalement survenir lorsque la plateforme initiale decide de rompre ses services, cequi oblige le client a trouver une autre plateforme pouvant accueillir ses applications.

Dans ces deux situations, il se pose le probleme de portabilite de lapplication ducloud initial vers le cloud de destination. Quant au choix (2), il survient lorsque lecloud hebergeant lapplication se retrouve ` a cour de ressources. Dans ce cas, le clientou le fournisseur peut decider dassocier au cloud initial des ressources venant duneautre plateforme. Ainsi, la meme application sexecute dans deux environnements decloud differents appartenant ` a des fournisseurs distincts. Lensemble forme par lesdeux plateformes constitue un cloud hybride. Cette situation souleve le problemedinteroperabilite entre les plateformes de CC. Dans ces deux situations ((1) et (2)),la mise en place dune API harmonisee (par standardisation) pour le developpementdes plateformes de CC est la bienvenue.


8/2/2019 tchana

29/171

2.2. ISOLATION PAR LA VIRTUALISATION 16

2.2 Isolation par la virtualisation

Comme nous lavons presentee dans la section 2.1.6.1, lisolation (au sens de lapresentation de la section 2.1.6.1) represente lun des des majeurs dans limplemen-tation des plateformes de cloud. Il existe plusieurs facons de la mettre en uvre :

La premiere methode consiste à allouer la ressource materielle entiere ` a uneentreprise meme si celle-ci ne souscrit que pour une fraction de cette ressource.Cette methode ne permet quune resolution partielle des problemes disolation.En effet, certaines ressources comme le reseau et sa bande passante restentpartagees entre les entreprises dans le cloud. A moins que le fournisseur al-loue exclusivement a chaque entreprise des equipements et la bande passante

reseaux (ce qui nest pas raisonnable), il est impossible avec cette methodedeviter des situations de monopole de ces ressources par entreprise. Elle doitetre completee avec une solution logicielle.

La seconde methode consiste a laisser la responsabilite aux entreprises dim-planter les mecanismes disolation. Cette methode nest pas envisageable dansla mesure ou le cloud ne dispose daucun moyen dintrospection des applica-tions dentreprise an de sassurer de limplantation de ces mecanismes.

La derniere methode est intermediaire (materielle et logicielle) aux deux pre-mieres. Tout en implementant les mecanismes disolation, elle donne lillusion ` alentreprise davoir un acces direct et exclusif à la ressource materielle. Paralle-

lement, elle garantie au cloud le non acces direct des entreprises aux ressourcesmaterielles. Cest de l isolation par virtualisation .

2.2.1 Denition et Principes

La virtualisation [ 58] se denit comme lensemble des techniques materielles et/oulogicielles qui permettent de faire fonctionner sur une seule machine, plusieurs sys-temes dexploitation (appeles machines virtuelles (VM), ou encore OS invite). Ellegarantie lindependance et lisolation des VM (lisolation telle que presentee dans lasection 2.1.6.1). En bref, elle permet dobtenir au niveau des VM la meme isolationquoffre les machines reelles.

Limplementation dun systeme de virtualisation repose sur une application sexe-cutant entre le materiel et les machines virtuelles : cest la Virtual Machine Monitor (VMM). Cest elle qui implante les mecanismes disolation et de partage des res-sources materielles. La gure 2.3 montre larchitecture globale dun systeme dunemachine virtualisee (c-à-d executant un systeme de virtualisation). La VMM est ca-pable de demarrer simultanement plusieurs machines virtuelles de differents types(Linux, Mac ou encore Windows) sur le meme materiel. Comme dans un systeme

dexploitation normal, chaque VM conserve son fonctionnement habituel. Autre-ment dit, elle a lillusion de gerer les acces memoire, disque, reseaux, processeur etautres peripheriques de ses processus. Vu de lexterieur, lutilisateur per coit len-


8/2/2019 tchana

30/171


semble comme un environnement constitue de plusieurs machines reelles.Quoique les VM gerent les acces aux ressources, aucun acces aux ressources nest

possible sans laval et le concours de la VMM. Elle decide notamment des attribu-tions de temps processeurs aux machines virtuelles. Quant ` a la communication aveclexterieur, la VMM peut fournir plusieurs techniques pour rendre accessible ou nonles VM. Elle peut la realiser par assignation dadresses IP et par implantation desmecanismes dacces reseaux aux VM (par routage, ltrage de communication, etc).

En plus de fournir un systeme disolation de systeme dexploitation, lun despremiers objectifs de la virtualisation est doffrir des performances proches de cellesdes machines reelles. La section suivante presente ces objectifs.

Figure 2.3 Vue des systemes virtualises

2.2.2 Objectifs

De facon generale, limplementation dun systeme de virtualisation doit remplirles trois objectifs suivants [84] :

Lequivalence : toute execution dapplication dans un systeme virtualise doitetre identique `a une execution sur une machine reelle ; `a lexception du temps dexe-cution lie a la disponibilite des ressources (plusieurs etudes [ 23] montrent leur rap-prochement).

Lefficacite : la majorite des instructions de la VM doit directement etre exe-cutee par le processeur sans intervention du logiciel de virtualisation.

Le contr ole de ressources : lensemble des ressources est gere de fa con exclu-sive (voir la section precedente) par le logiciel de virtualisation. Ceci permet dassurerlisolation de performance et de securite.


8/2/2019 tchana

31/171


2.2.3 Beneces pour les entreprises

Malgre le surco ut dexecution induit (3% [27]) par les systemes de virtualisationactuels, la virtualisation offre plusieurs avantages aux entreprises qui en font lusage.Nous remarquons dans la litterature, quil existe un amalgame entre les apports tech-nologiques de la virtualisation et les consequences de ces apports dans une entreprise.Dans cette section, nous evitons de faire cet amalgame.

Le tour est vite fait lorsquil sagit de trouver les apports techniques de la virtua-lisation dans le domaine des systemes (en tant que domaine de recherche) : il sagitessentiellement de lisolation. Presente de cette fa con, daucuns compareront cetteisolation a celle dej a proposee par les systemes dexploitation pour les processus. Enrealite, le veritable apport est la capacite ` a isoler lexecution de plusieurs systemesdexploitation (et non processus) dans le meme systeme dexploitation. En raison durapprochement avec certains objectifs du CC, lisolation proposee par la virtualisa-tion se decline egalement sous plusieurs formes identiques au CC (voir la section 4.1pour leurs descriptions).

Les atouts de la virtualisation peuvent se traduire sous plusieurs formes en en-treprise. Les beneces possibles sont les suivants :

Reduction des co uts. Au lieu dacquerir plusieurs serveurs materiels pour lexe-cution de logiciels incapables de cohabiter, lentreprise utilise des machines virtuellesan disoler chaque logiciel. Pour les memes raisons que le CC, cette execution re-groupee permetegalement de reduire les co uts en consommationelectrique, ou encoreen supercie des locaux qui abritent les serveurs. Un atout concerne les developpeursde systemes dexploitation. Au lieu de dedier une machine pour la realisation destests, les developpeurs peuvent se servir des machines virtuelles.

Unite de facturation. Dans un centre dhebergement, au lieu dutiliser unemachine entiere comme unite dallocation, la virtualisation permet dallouer unefraction de machine aux clients. Cet atout est notamment exploite dans certainesplateformes de cloud.

Sauvegarde de services. Dans certaines applications, la robustesse fait partie

des premiers criteres devaluation. Elle se caracterise par la capacite du systeme ` areprendre son activite dans un etat proche de la normale (c-` a-d avant la panne) encas de panne dun des serveurs. La virtualisation permet de sauvegarder periodique-ment letat dexecution dune VM et de la redemarrer en cas de necessite ` a partirdun point de sauvegarde. Cette operation est appelee checkpointing dans le jargonde la virtualisation.

Transfert de services. Nous entendons par transfert de services la possibilitede deplacer lexecution dun service dune machine reelle `a une autre sans inter-ruption. Cette caracteristique est permise dans la virtualisation via des operationsde migration a chaud. Elle permet dexploiter les ressources dune machine reellesous-utilisee par un service en cours dexecution sur une machine reelle sur-utilisee.Inversement, elle permet de consolider sur un nombre reduit de machines, des ser-vices en cours dexecution sur plusieurs machines sous utilisees. Notons que tous


8/2/2019 tchana

32/171


les systemes de virtualisation ne fournissent pas ce service. De plus leur efficacitedepend de la technique dimplementation utilisee.

2.2.4 Classication

Face a la difficulte de mise en uvre du modele de virtualisation propose ini-tialement (virtualisation complete du materiel), ` a cause de la non compatibilite desdrivers materiels, plusieurs techniques de virtualisation se sont developpees. Amelio-rees au l des annees, les techniques dimplementation de systemes virtuels peuventetre regroupees en differentes categories selon le rapprochement/eloignement entre laVM et le materiel. La gure 2.4 recense les categories majeures que nous presentonsbrievement dans cette section. Le sens des eches dans cette gure represente cetteevolution chronologique. La presentation que nous donnons dans cette section suitegalement cet ordre. Ainsi le developpement des systemes les plus recents se justi-e par les inconvenients des predecesseurs. Notons que certains termes employes icipeuvent se retrouver dans la litterature avec des descriptions differentes.

Virtualisation du systeme de chiers (gure 2.4 (a)). Cest une methodequi repose sur un systeme dexploitation pre-installe (systeme h ote). Ce dernierpermet de construire des espaces utilisateurs (designation de la VM ici) dont les sys-temes de chiers sont completement isoles. Chaque VM dispose dune arborescencede systeme de chiers a exclusif qui lui est propre. Les autres ressources telles que lamemoire, les cartes reseaux, le processeur sont directement accessibles par les VM.Il nexiste aucune isolation pour ces ressources. On retrouve dans cette categorie desoutils chroot ou UML (User Mode Linux) [uml].

Lemulation (gure 2.4 (b)). La categorie precedente ne permettant pas lins-tallation dOS, il sest developpe une technologie basee sur lemulation. Cette tech-nique propose une application (le virtualisateur) qui sexecute au-dessus du systemehote, dans lespace utilisateur. Cette application (qui correspond ` a la VMM) a pourmission demuler le materiel et permet ainsi de demarrer plusieurs systemes dex-

ploitation reels dans lespace utilisateur. Cette technique de virtualisation induit unsurcout considerable dans lexecution des machines virtuelles. En effet, chaque ope-ration effectuee dans la VM est interceptee et interpretee par la VMM. Le systemede virtualisation VirtualBox [ VirtualBox.org ] est base sur cette technique.

Paravirtualisation (gure 2.4 (c)). La paravirtualisation a ete developpeepour resoudre les problemes de la categorie precedente. Elle consiste ` a modier lesOS des VM an quils soient au courant de leur statut (de VM). Ainsi, le materielest mappe dans la VM et donc accessible directement sous le contr ole de la VMM(hyperviseur sur la gure 2.4(c)). Cette derniere sexecute directement au-dessus dumateriel. Elle remplace lOS hote, qui est considere comme une VM. La contrainte demodication dOS des VM est une limite a cette technique. En effet, elle ne permetpas lexecution de VM munies dOS proprietaires (comme Windows). La plateforme


8/2/2019 tchana

33/171


Xen [23] est le systeme de paravirtualisation le plus repandu gr ace au niveau deperformance quil offre [27]. Les travaux de cette these sont notamment bases sur ce

systeme.

Virtualisation assistee par le materiel (gure 2.4 (d)). Levolution actuelledes drivers materiels et des processeurs (technologie Intel VT [ Corporation ]) vers laprise en compte de la virtualisation permet de developper une nouvelle technique devirtualisation. Ainsi, lintervention de la VMM sur les actions des VM est limitee etcelles-ci nont plus besoin detre modiees. Les nouvelles implementations de Xenou VMware [VMware.org] permettent dutiliser cette technique lorsque le materielle supporte.

Figure 2.4 Techniques de virtualisation

2.2.5 Synthese

Apres cette presentation de la virtualisation, nous constatons quelle repond par-faitement au challenge disolation auquel est confronte le cloud. De plus, nous consta-tons que les beneces de la virtualisation vis ` a vis des entreprises rejoignent ceux du


8/2/2019 tchana

34/171


cloud. Elle amplie notamment la pratique de la mutualisation des ressources, quiest au cur du cloud. Quant aux techniques disolation par reservation entiere de

ressources, nous montrons quelles sont moins beneques. En outre, elle ne couvrentpas tous les besoins disolation que requiert le cloud. Pour ces raisons, la majorite desplateformes de cloud ([61], [76], [Cloud], [OpenNebula ], [80], etc.) adopte la virtuali-sation comme technique disolation. Cest cette categorie de cloud qui nous interessedans cette these.

Son introduction dans le cloud implique la modication du mode de gestion desressources et plus globalement des taches dadministration. En ce qui concerne lagestion des ressources, lunite dallocation dans le cloud passe de la machine reellea la machine virtuelle. Quant `a ladministration, elle contraint les administrateursdu cloud dacquerir des competences en matiere de virtualisation. Dans la sectionsuivante, nous decrivons `a quoi correspond ladministration dans une plateforme deCC basee sur la virtualisation.


8/2/2019 tchana

35/171

Chapitre 3

Administration dans le Cloud

Contents3.1 Administration niveau IaaS . . . . . . . . . . . . . . . . . 23

3.1.1 Allocation de ressources . . . . . . . . . . . . . . . . . . . 243.1.2 Deploiement . . . . . . . . . . . . . . . . . . . . . . . . . 243.1.3 Conguration et Demarrage . . . . . . . . . . . . . . . . . 253.1.4 Reconguration . . . . . . . . . . . . . . . . . . . . . . . . 253.1.5 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2 Administration niveau Entreprise . . . . . . . . . . . . . . 273.2.1 Construction de VM et Deploiement . . . . . . . . . . . . 283.2.2 Allocation de ressources . . . . . . . . . . . . . . . . . . . 293.2.3 Conguration et Demarrage . . . . . . . . . . . . . . . . . 293.2.4 Reconguration . . . . . . . . . . . . . . . . . . . . . . . . 303.2.5 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3 Synthese : systeme dadministration autonome pour lecloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Concues comme une evolution des plateformes partagees, les clouds necessitentdes t aches dadministration rencontrees dans les grilles et les environnements dis-tribues en general. A celles-ci sajoutent celles relatives ` a lintroduction de la vir-tualisation. Elles concernent les differents protagonistes dans le cloud. Comme nouslavons presente dans la section 2.1.5.2, nous distinguons trois types dutilisateursdans le cloud (gure 3.1) : le fournisseur (administre le cloud), les entreprises clientes(utilisent les ressources du cloud et administrent ses applications) et les utilisa-teurs naux (ceux qui utilisent les services fournis par les applications entreprises).Contrairement aux deux premiers utilisateurs, le dernier nest confronte ` a aucunet ache dadministration. Lanalyse de cette derniere laisse paratre une symetrie entreles operations dadministration realisees par le fournisseur du cloud (niveau IaaS)

et celles realisees par les administrateurs des entreprises clientes du cloud (niveauentreprise) (observable sur la gure 3.2). Globalement, les gestionnaires des deuxniveaux dadministration assurent des t aches de :

8/2/2019 tchana

36/171

3.1. ADMINISTRATION NIVEAU IAAS 23

Deploiement : deploiement de VM au niveau IaaS et deploiement de logicielspour lentreprise cliente ;

Monitoring : monitoring des ressources materielles et VM au niveau IaaS (as-sure par lelement MonitoringController dans la gure 3.2) et monitoring deslogiciels au niveau entreprise cliente (assure par lelement AppMonitoringCon-trolle dans la gure 3.2) ;

Gestion des ressources : allocation efficace des ressources materielles au ni-veau IaaS (assuree par lelement ResourceController dans la gure 3.2) etreservation efficace de VM au niveau entreprise cliente (assuree par lelementAppResourceController dans la gure 3.2) ;

Reconguration : reconguration des VM au niveau de lIaaS (assuree parlelement AppMonitoringControlle dans la gure 3.2) et reconguration deslogiciels, pour le passage a lechelle par exemple, au niveau entreprise cliente(assuree par lelement AppScheduler dans la gure 3.2).

Dans cette section, nous presentons en detail et separement dune part ladminis-tration telle queffectuee dans lIaaS et dautre part les operations dadministrationrealisees par lentreprise.

Figure 3.1 Architecture simpliee du Cloud

3.1 Administration niveau IaaS

Directement rattachee ` a lenvironnement materiel, ladministration au niveau delIaaS se resume a la gestion des machines virtuelles (pour une utilisation efficacedes ressources) et de ses serveurs de gestion (scheduler, serveurs de stockage, etc.).Ne pouvant etre realisees en avance, certaines t aches dadministration de lIaaS sontprovoquees par celles des entreprises (elles seront interpretees comme des operationsde reconguration). Parmi les operations dadministration au niveau IaaS, les pluscourantes sont : lallocation de ressources, le deploiement de ses serveurs et des VM,la conguration et le demarrage (des VM et ses serveurs). Quant aux autres, elles sont


8/2/2019 tchana

37/171


provoquees par des evenements externes pour certaines (consolidation, reparation)et regulieres pour dautres (monitoring).

3.1.1 Allocation de ressources

Cest la premiere operation realisee dans le cloud. Elle attribue ` a lentreprisecliente sa portion de ressources exploitables. Par ressources, nous regroupons ` a la foisla memoire, le processeur, lespace de stockage, la bande passante et les equipementsinformatiques. Mutualisees entre tous les utilisateurs, les ressources representent lepoint de rentabilite pour le fournisseur. Ainsi, la conception et limplementationdes politiques dallocation dans le cloud dependent de la strategie commerciale dufournisseur. Notons que lallocation est provoquee entre autres par une reservationde lentreprise. Le fournisseur peut dont proposer plusieurs manieres de reservation :

1. Reservation pour une duree indeterminee : dans ce mode, un contrat est etabliavec lentreprise pour une duree innie et continue (on peut egalement parlerde forfait).

2. Reservation pour une utilisation ` a venir et pour une duree limitee : dans cemode, la difficulte se situe dans la gestion des plages de reservation. On retrouvele probleme tres connu et complexe qui est celui de la planication.

3. Reservation pour une utilisation immediate et limitee dans le temps : dans ce

cas, les ressources requises doivent etre disponibles dans limmediat.La prise en compte de ces modes de reservation peut complexier lallocation dans lecloud. Notamment, il peut etre amene ` a mettre en place des les dattente, avec desnotions de priorite. Ainsi, en guise dexemple, les ressources obtenues par le derniermode de reservation peuvent etre considerees comme moins prioritaires que cellesobtenues via les deux premiers. Dans ce cas, le cloud doit etre capable didentierles ressources a liberer en cas de besoin dune application plus prioritaire.

3.1.2 Deploiement

Le deploiement dans lIaaS concerne essentiellement les systemes de chiers desmachines virtuelles. Il est realise ` a deux occasions. Premierement (eche (2) de lagure 3.2) lors de lenregistrement dans le cloud des systemes de chiers dOS (ega-lement appeles images) et des donnees de lentreprise. Pour cela, le cloud utilise unserveur de stockage (que nous appelons RepositoryController dans la gure 3.2) dis-tinct des lieux dexecution des VM. Le second deploiement (eche (4) de la gure 3.2)intervient a lexecution de celles-ci. En effet, limage utilisee pour lexecution duneVM dans le cloud est une copie de limage initiale. Ceci sexplique par deux raisons.La premiere est la possible inaccessibilite des machines h otes (hebergeant les VM)au serveur de stockage. Tres souvent, pour des raisons defficacite, le format de sto-ckage des donnees (y compris les systemes de chiers) par le serveur de stockagepeut etre different de celui attendu par le systeme de virtualisation qui executera la


8/2/2019 tchana

38/171


VM. Cest le cas dans le cloud Amazon EC2 [61]. La deuxieme raison est la possibleutilisation de la meme image pour lexecution de plusieurs VM. De plus, lentreprise

peut souhaiter retrouver limage originale apres lexecution de la VM (sauf demandecontraire).

3.1.3 Conguration et Demarrage

Loperation de demarrage des machines virtuelles necessite prealablement leurconguration. Cette derniere depend dune part des demandes de lentreprise etdautre part de la politique dallocation de ressources dans le cloud. Pendant laphase de reservation, une entreprise souscrit pour des VM dont elle fournit les ca-racteristiques au cloud. Ces caracteristiques concernent : la quantite de memoires,le nombre de processeurs, le lieu geometrique dexecution de la VM et le systeme dechiers representant lOS de la VM. Quant aux contraintes de conguration venantde lIaaS, il sagit des congurations reseaux. En effet, lIaaS peut implementer plu-sieurs congurations dacces reseaux : lattribution dun reseau virtuel (VLAN) auxVM appartenant `a la meme entreprise ou encore lutilisation dun VLAN communpour toutes les VM (il ne sagit que dexemples). Il doit egalement congurer lescontr oles reseaux (pare feu ou encore les quotas dutilisation reseau) en fonction dessouscriptions de lentreprise.

3.1.4 Reconguration

Comme nous lavons evoque dans le preambule de cette section, la plupart dest aches dadministration au niveau de lIaaS peuvent etre interpretees comme desoperations de reconguration (realisees par le VMController sur la gure 3.2). Eneffet, elles interviennent pendant lexecution de lIaaS et modient sa composition.Dans cette section, nous presentons quelques t aches de recongurations particulieres,liees essentiellement a la gestion des VM : la consolidation et la reparation.

Consolidation de VM

Nous nous rappelons des plateformes dhebergement dans lesquelles des machinesentieres etaient dediees ` a un client. Dans ces plateformes, aucune tache dadminis-tration de la part du fournisseur netait envisageable une fois la machine alloueeau client (au risque de violer lexclusivite dutilisation de la machine par le client).A linverse, les clouds bases sur la virtualisation offrent une marge `a ladministra-teur de lIaaS pour une intervention sur les machines physiques. Cette possibiliteest offerte par le caractere isolant de la virtualisation. Elle permet entre autres aufournisseur dimplementer differentes politiques dallocation ou redistribution de res-sources, dans le but deffectuer des economies ou de respecter un contrat client.

La premiere intervention dans la gestion de ressources survient pendant la phase


8/2/2019 tchana

39/171


dallocation de VM (elle est egalement dite phase de placement). Durant cette phase,lIaaS doit etre capable didentier lensemble des machines physiques correspondant

a la politique dallocation implantee par le fournisseur. Pour illustrer cela, prenonsune politique qui consiste a choisir les machines de telle sorte que le risque de gas-pillage soit le plus faible possible. Cette contrainte peut entraner le deplacement desVM en cours dexecution an de liberer de la place pour la VM allouee. On parlede consolidation de VM. Par exemple prenons le cas dun IaaS constitue de troismachines physiques MP 1 , MP 2 et MP 3 de puissance identique notee p. Supposonsque MP 1 et MP 2 utilisees respectivement `a moitie de leur puissance. Soit un clientayant besoin dune machine virtuelle dont la puissance requise est 34 p. Dans cettesituation, au lieu de faire recours a la troisieme machine virtuelle, lIaaS doit etrecapable de regrouper les deux machines virtuelles des deux machines MP 1 et MP 2

sur la machineMP 1

ouMP 2

et dallouer par la suite lune des machines liberees `ala nouvelle machine virtuelle.Notons que la consolidation peut egalement seffectuer en dehors des operations

dallocation. En effet, lIaaS scrute regulierement son environnement et reorganisela disposition des VM sur les machines an de liberer certaines. Cette liberation demachines permet de reduire les taux de consommation energetique de lIaaS.

Reparation de pannes

Compte tenu de la taille du cloud et de la multitude dutilisateurs et du nombrede clients quil accueille, le risque dapparition de pannes est important. Lapparitiondun dysfonctionnement doit etre rapidement identiee et traitee par ladministra-teur an de ne pas penaliser les entreprises. Lune des pannes les plus critiques danslIaaS est le dysfonctionnement dune machine physique ou virtuelle. En effet, elleaffecte les applications des entreprises. A cause de sa non intrusivite, lIaaS nest pasau courant des logiciels en cours dexecution dans les VM quil heberge. De ce fait,lIaaS ne saurait resoudre efficacement une panne sans la collaboration de lentrepriseconcernee. Malgre cette limitation, lIaaS peut proter des atouts de la virtualisationet proposer ainsi plusieurs politiques de reparation. Celles-ci peuvent aller des plussimples (redemarrage de la VM concernee) aux plus sophistiquees (redemarrage surle dernier point de sauvegarde). Lapplication de ces politiques peut dependre des

termes du contrat souscrit par lentreprise. Dans tous les cas, la mise en place de cespolitiques depend du systeme de surveillance implante dans lIaaS.

3.1.5 Monitoring

Les sections precedentes ont introduit la notion de monitoring. En effet, toutesles taches dadministration dans le cloud dependent des informations obtenues parmonitoring des environnements materiels, virtuels et logiciels (realise par Monito-

ringController sur la gure 3.2). Parmi les informations de monitoring qui nousinteressent, nous pouvons citer le taux dutilisation des processeurs, des disques, dureseau, de la memoire, etc. Cependant, larchitecture particuliere du cloud et des ap-


8/2/2019 tchana

40/171

3.2. ADMINISTRATION NIVEAU ENTREPRISE 27

plications qui y sont executees constitue un facteur limitant pour le monitoring. Eneffet, repute comme une t ache complexe dans les environnements distribues consti-

tues de machines reelles, le monitoring dans le cloud est un veritable challenge.Les ressources etant virtualisees dans le cloud, il nest pas evident de fournir uneimage reetant letat reel des machines. En effet, nous distinguons deux niveauxdobservation et danalyse de ressources : la machine virtuelle et la machine phy-sique. Dune part, lIaaS doit etre capable de separer les ressources consommees parchaque niveau an de fournir aux clients des informations relatives uniquement ` aleur consommation. Dautre part, lIaaS doit fournir ` a son administrateur les infor-mations concernant `a la fois les VM et les machines les hebergeant. Dans les deuxcas, les informations doivent etre comprehensibles et exploitables.

Jusqu a present, nous nevoquons que des informations locales ` a chaque machinephysique ou virtuelle. Or le cloud est un systeme reparti et heterogene. Dans laplupart des cas, ladministrateur sinteresse aux informations agregees et obtenuespar calculs groupes des observations locales. Par exemple, ce calcul peut se faire parcombinaison des informations provenant dun ensemble de machines appartenant ` ala meme zone geographique ou a la meme entreprise.

Figure 3.2 Administration dans le cloud

3.2 Administration niveau Entreprise

Malgre les avantages quil offre, le cloud peine a seduire les entreprises depuis savulgarisation. Cette hesitation est dordre ideologique : lidee de coner ses donnees(essentielles pour la concurrence) a une entreprise externe nest pas encore comple-tement acceptee dans les entreprises. Face cette idee, le cloud repond avec plus de


8/2/2019 tchana

41/171


developpement de la securite et la condentialite. Comme en interne, ladministra-tion dapplications sur le cloud est une tache fastidieuse pour lentreprise. De plus,

dans le cadre des clouds virtualises, la gestion des VM represente une operationsupplementaire. En somme, ladministration dapplications dans un cloud virtualisecomprend les t aches suivantes :

Construction de systemes dexploitation (ou VM) ; Reservation/Allocation de ressources sur le cloud ; Installation et demarrage des logiciels ; Suivi de lexecution des logiciels et des VM ; Reconguration/Optimisation (scalabilite, mise ` a jour des logiciels, reparation,

etc.).

3.2.1 Construction de VM et Deploiement

Lexecution de toute application par une entreprise dans le cloud a lieu dansune VM. Lexecution de cette derniere requiert la presence de son image dans leserveur de stockage du cloud. Pour lentreprise, le deploiement peut donc seffectuera deux occasions : pendant le telechargement du systeme de chiers des VM (eche(2) sur la gure 3.2) et pendant la copie (de lentreprise vers les VM) des binaires

des logiciels constituant son application (eche (5) sur la gure 3.2). Comme nous lepresentons dans cette section, le second deploiement peut sappuyer sur le premier.La premiere etape avant toute reservation sur le cloud est la construction des

systemes de chiers. Elle comprend les phases suivantes : (1) installation du systemedexploitation, (2) conguration du systeme dexploitation et (3) eventuellementlinstallation des packages ou binaires des futurs logiciels. Dans certains cas, lesphases (1) et (2) ne sont pas necessaires lorsque le cloud fournit un systeme dechiers repondant aux attentes de lentreprise. Dans tous les cas, lentreprise effectuela derniere etape qui est linstallation de ses logiciels. Cette t ache peut seffectuer dedifferentes fa cons.

Methode 1 : Elle construit un OS contenant tous les binaires et packages de tousses logiciels (eches (1), (1) et (1) sur la gure 3.2). La construction seffectue chezelle et le resultat (un OS de grande taille) est ensuite transfere sur le cloud gr ace auxprotocoles de sauvegarde quil fournit. Cest par exemple le cas avec Simple StorageService (S3) du cloud Amazon EC2. Le benece de cette methode est la reductiondu nombre de systemes de chiers sauvegardes dans le cloud (donc des couts destockage). Par contre `a lexecution, lentreprise paye le prix fort. En effet, lexecutionde toute VM a partir de cet OS augmente lespace de stockage de lentreprise et doncle cout dexecution.

Methode 2 : Construction dun systeme de chiers dedie pour chaque type delogiciels (eches (1) et [(1) ou (1)] sur la gure 3.2). Les avantages de cette methodesont les inconvenients de la precedente et inversement. Autrement dit, elle est moins


8/2/2019 tchana

42/171


couteuse lorsque les VM sont a lexecution qu a larret. En effet, soient t s la tailledun systeme dexploitation, n le nombre de logiciels constituant lapplication, t li la

taille du ieme logiciel avec i [1 ; n] . Lespace de stockage dans cette methode estn* t s + ni =1 t li (avec n le nombre de logiciels) tandis quil est de t s +ni =1 t li dans la

premiere methode.

Methode 3 : La derniere est une solution intermediaire aux deux premieres(eches (5) sur la gure 3.2). Le systeme de chier ne contient que lOS minimal aexecuter. Ainsi a lexecution, ladministrateur effectue les operations de deploiementet dinstallation des logiciels sur ses instances de VM. Elle presente les avantagesde la premiere et de la seconde approche. Par contre, elle est plus technique, fas-tidieuse et necessite plusieurs connexions a distance sur les VM. Ainsi, pour uneexecution multiple du meme logiciel, ladministrateur realise plusieurs installationsde ce logiciel.

3.2.2 A

Documents

tchana