Formalisation et Évaluation de Stratégies d’Élasticité Multi-couches dans le Cloud

HAL Id: tel-02271523

https://tel.archives-ouvertes.fr/tel-02271523

Submitted on 2 Mar 2020

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Multi-couches dans le Cloud

Khaled Khebbeb

To cite this version:

Khaled Khebbeb. Formalisation et Évaluation de Stratégies d’Élasticité Multi-couches dans le Cloud.

Informatique [cs]. LIUPPA - Laboratoire Informatique de l’Université de Pau et des Pays de l’Adour;

LIRE - Laboratoire d’Informatique Répartie de l’Université Constantine 2, 2019. Français. �NNT :

2019PAUU3010�. �tel-02271523�

Universit´ e Constantine 2 Abdelhamid Mehri - Facult´ e des Nouvelles Technologies de l’Information et de la Communication - D´ epartement des Technologies Logicielles et Syst` emes

d’Information

Formalisation et ´ evaluation de strat´ egies d’´ elasticit´ e multi-couches

dans le Cloud

TH´ ESE

pour l’obtention du titre de

Docteur en informatique

pr´epar´ee dans le cadre d’une cotutelle entre

Universit´ e de Pau et des Pays de l’Adour

et

Universit´ e Constantine 2 - Abdelhamid Mehri

pr´esent´ee et soutenue par

Khaled KHEBBEB

Le 29 Juin 2019 `a Universit´e Constantine 2

Composition du jury

Pr´esident: Pr. Mahmoud BOUFAIDA Universit´e Constantine 2 - Abdelhamid Mehri, Alg´erie

Rapporteurs: Pr. Yamine AIT-AMEUR Institut National Polytechnique ENSEEIHT, Toulouse, France Pr. Kamel BARKAOUI Conservatoire National des Arts et M´etiers, Paris, France Examinateurs: Pr. Lakhdar DERDOURI Universit´e d’Oum El Bouaghi, Alg´erie

Directeurs: Pr. Faiza BELALA Universit´e Constantine 2 - Abdelhamid Mehri, Alg´erie Dr. Nabil HAMEURLAIN Universit´e de Pau et des Pays de l’Adour, France

Laboratoire d’Informatique de l’Universit´ e de Pau et des Pays de l’Adour (LIUPPA EA 3000)

Chuck Schuldiner

Il me sera tr`es difficile de remercier tout le monde car c’est grˆ ace ` a l’aide de nombreuses personnes que j’ai pu mener cette th`ese `a son terme.

Je voudrais tout d’abord remercier grandement mes deux directeurs de th`ese, madame Faiza Belala, professeur `a l’universit´e Constantine 2, et monsieur Nabil Hameurlain, maˆıtre de conf´erences habilit´e `a diriger des recherches `a l’universit´e de Pau et des Pays de l’Adour (UPPA), pour toute leur aide. Je suis ravi d’avoir travaill´e en leur compagnie car outre leur appui scientifique, leur p´edagogie et leur patience, ils ont toujours ´et´e l` a pour me soutenir et me conseiller au cours de l’´elaboration de cette th`ese. J’exprime ma gratitude ` a Monsieur Hameurlain qui m’a dignement accueilli pendant trois ann´ees au sein de l’´equipe MOVIES du laboratoire LIUPPA. C’est `a ses cˆot´es que j’ai compris ce que rigueur et pr´ecision voulaient dire.

Je tiens ` a remercier monsieur Kamel Barkaoui, professeur au centre national des arts et m´etiers (CNAM) de Paris, et monsieur Yamine Ait-Ameur, professeur ` a l’institut national polytechnique de Toulouse (INP ENSEEIHT), pour l’honneur qu’ils m’ont fait en acceptant d’ˆetre rapporteurs de cette th`ese, et pour le temps qu’ils ont consacr´e ` a mon travail.

Je remercie monsieur Mauro Gaio et monsieur Ernesto Exposito, professeurs ` a l’universit´e de Pau et des pays de l’Adour, et je r´eit`ere mes remerciements ` a monsieur Ait-Ameur, pour leur participation et leur disponibilit´e pendant les divers comit´es de suivi de th`ese. Il ont pris le temps de m’´ecouter et de discuter avec moi. Leur remarques m’ont permis de faire avancer mon projet et d’envisager mon travail sous un autre angle.

Je tiens ` a remercier monsieur Mahmoud Boufaida, professeur ` a l’universit´e Constantine 2 pour avoir accept´e de pr´esider mon jury de th`ese, ainsi que monsieur Lakhdar Derdouri, professeur ` a l’universit´e de Oum Bouaghi, pour avoir accept´e d’ˆetre dans mon jury de th`ese en tant qu’examinateur. Je les remercie pour l’honneur qu’ils me font, pour leur participation scientifique ainsi que pour le temps qu’ils ont consacr´e ` a ma recherche.

Un grand merci aux membres du d´epartement d’informatique du coll`ege STEE de l’UPPA, aux membres du LIUPPA du site de Pau, ainsi qu’au personnel de l’´ecole doctorale SEA (ED 211) de l’UPPA pour leur accueil et leur support, tout au long de la r´ealisation de mes travaux.

Je tiens particuli`erement ` a remercier les personnes qui ont partag´e mon quotidien durant ces ann´ees de th`ese. Je pense aux amiti´es tiss´ees et ` a toutes ces personnes qui ont su ˆetre pr´esentes en toutes circonstances.

Mes derniers remerciements vont ` a ma famille, et en particulier ` a mon p`ere, qui a tout

fait pour m’aider, qui m’a soutenu et support´e dans tout ce que j’ai entrepris.

L’´elasticit´e est une propri´et´e qui permet aux syst`emes Cloud de s’auto-adapter ` a leur charge de travail en provisionnant et en lib´erant des ressources informatiques, de mani`ere autonomique, lorsque la demande augmente et diminue. En raison de la nature impr´evisible de la charge de travail et des nombreux facteurs d´eterminant l’´elasticit´e, fournir des plans d’action pr´ecis pour g´erer l’´elasticit´e d’un syst`eme cloud, tout en respectant des politiques de haut niveau (performances, cout, etc.) est une tˆache particuli`erement difficile. Les travaux de cette th`ese visent ` a proposer, en utilisant le formalisme des bigraphes comme mod`ele formel, une sp´ecification et une impl´ementation des syst`emes Cloud Computing ´elastiques sur deux aspects : structurel et comportemental.

Du point de vue structurel, le but est de d´efinir et de mod´eliser une structure correcte des syst`emes Cloud du cˆot´e ” backend ”. Cette partie est support´ee par les capacit´es de sp´ecification fournies par le formalisme des Bigraphes, ` a savoir : le principe de ”sorting” et de r`egles de construction permettant de d´efinir les desiderata du concepteur. Concernant l’aspect comportemental, il s’agit de mod´eliser, valider et impl´ementer des strat´egies g´en´eriques de mise ` a l’´echelle automatique en vue de d´ecrire les diff´erents m´ecanismes d’auto-adaptation

´elastiques des syst`emes cloud (mise ` a l’´echelle horizontale, verticale, migration, etc.), en multi- couches (i.e., aux niveaux service et infrastructure). Ces tˆ aches sont prises en charge par les aspects dynamiques propres aux Syst`emes R´eactifs Bigraphiques (BRS) notamment par le biais des r`egles de r´eaction.

Les strat´egies d’´elasticit´e introduites visent ` a guider le d´eclenchement conditionnel des diff´erentes r`egles de r´eaction d´efinies, afin de d´ecrire les comportements d’auto-adaptation des syst`emes Cloud au niveau service et infrastructure. L’encodage de ces sp´ecifications et leurs impl´ementations sont d´efinis en logique de r´e´ecriture via le langage Maude. Leur bon fonctionnement est v´erifi´e formellement ` a travers une technique de model-checking support´ee par la logique temporelle lin´eaire LTL.

Afin de valider ces contributions d’un point de vue quantitatif, nous proposons une ap- proche ` a base de file d’attente pour analyser, ´evaluer et discuter les strat´egies d’´elasticit´e d’un syst`eme Cloud ` a travers diff´erents sc´enarios simul´es. Dans nos travaux, nous explorons la d´efinition d’une ”bonne” strat´egie en prenant en compte une ´etude de cas qui repose sur la nature changeante de la charge de travail. Nous proposons une mani`ere originale de composer plusieurs strat´egies d’´elasticit´e ` a plusieurs niveaux afin de garantir diff´erentes politiques de haut-niveau.

Mots-cl´ e: Cloud Computing, Syst`emes auto-adaptatifs, Mod´elisation et v´erification

formelles, Syst`emes R´eactifs Bigraphiques, Logique de r´e´ecriture, Th´eorie des files d’attente.

Elasticity property allows Cloud systems to adapt to their incoming workload by provi- sioning and de-provisioning computing resources in an autonomic manner, as the demand rises and drops. Due to the unpredictable nature of the workload and the numerous factors that impact elasticity, providing accurate action plans to insure a Cloud system’s elasticity while preserving high level policies (performance, costs, etc.) is a particularly challenging task.

This thesis aims at providing a thorough specification and implementation of Cloud systems, by relying on bigraphs as a formal model, over two aspects: structural and behavioral.

Structurally, the goal is to define a correct modeling of Cloud systems’ ”back-end” struc- ture. This part is supported by the specification capabilities of Bigraph formalism. Specif- ically, via ”sorting” mechanisms and construction rules that allow defining the designer’s desiderata. As for the behavioral part, it consists of model, implement and validate generic elasticity strategies in order to describe Cloud systems’ auto-adaptive behaviors (i.e., hor- izontal and vertical scaling, migration, etc.) in a cross-layer manner (i.e., at service and infrastructure levels). These tasks are supported by the dynamic aspects of Bigraphical Re- active Systems (BRS) formalism (through reaction rules).

The introduced elasticity strategies aim at guiding the conditional triggering of the defined reaction rules, in order to describe Cloud systems’ auto-scaling behaviors in a cross-layered manner. The encoding of these specifications and their implementation are defined in Rewrite Logic via Maude language. Their correctness is formally verified through a model-checking technique supported by the linear temporal logic LTL.

In order to quantitatively validate these contributions, we propose a queuing-based ap- proach in order to evaluate, analyze and discuss elasticity strategies in Cloud systems through different simulated execution scenarios. In this work, we explore the definition of a “good”

strategy through a case study which considers the changing nature of the input workload.

We propose an original way de compose different cross-layer elasticity strategies in order to guarantee different high-level policies.

Keywords: Cloud Computing, Self-adaptive systems, Formal modeling and verification,

Bigraphical Reactive Systems, Rewrite logic, Queuing Theory.

Table des figures iv

Liste des tableaux vi

Liste des acronymes vii

1 Introduction g´ en´ erale 2

1.1 Contexte . . . . 2

1.2 Probl´ ematique . . . . 3

1.3 Objectifs et contributions . . . . 5

1.4 Plan de th` ese . . . . 6

1.5 Diffusion scientifique . . . . 7

I Etat de l’Art ´ 8 2 Principaux concepts et d´ efinitions 10 2.1 Introduction . . . . 10

2.2 Les syst` emes Cloud Computing . . . . 11

2.2.1 D´ efinitions . . . . 11

2.2.2 Caract´ eristiques . . . . 12

2.2.3 Mod` eles de service . . . . 12

2.2.4 Mod` eles de d´ eploiement . . . . 14

2.2.5 Acteurs du Cloud . . . . 15

2.2.6 Virtualisation . . . . 16

2.2.7 Mod` ele ´ economique . . . . 17

2.2.8 Efficience et Cloud Computing . . . . 19

2.3 Elasticit´ ´ e dans le cloud . . . . 20

2.3.1 D´ efinitions . . . . 20

2.3.2 Niveaux d’action de l’´ elasticit´ e . . . . 22

2.3.3 Strat´ egies d’´ elasticit´ e et techniques sous-jacentes . . . . 22

2.3.4 Objectifs de l’´ elasticit´ e . . . . 24

2.3.5 M´ ethodes d’´ elasticit´ e . . . . 25

2.4 Informatique autonomique . . . . 27

2.4.1 D´ efinitions . . . . 27

2.4.2 Propri´ et´ es autonomiques . . . . 27

2.4.3 Boucle de contrˆ ole autonomique . . . . 29

2.4.4 Contrˆ oleur d’´ elasticit´ e autonomique dans les syst` emes Cloud . . . . 31

2.5 Conclusion . . . . 32

3 Travaux existants sur l’´ elasticit´ e dans le Cloud 34

3.1 Environnements pour la gestion autonomique de l’´ elasticit´ e dans le Cloud . . . . 34

3.1.1 Synth` ese . . . . 39

3.2 Mod` eles formels pour l’´ elasticit´ e dans le Cloud . . . . 40

3.2.1 Synth` ese . . . . 44

3.3 Conclusion . . . . 46

4 Pr´ erequis et fondements formels 48 4.1 Introduction . . . . 48

4.2 Les Syst` emes R´ eactifs Bigraphiques . . . . 49

4.2.1 Anatomie et forme graphique des bigraphes . . . . 50

4.2.2 D´ efinitions Formelles . . . . 52

4.2.3 Op´ erations sur les bigraphes . . . . 53

4.2.4 Forme alg´ ebrique . . . . 56

4.2.5 Logique de typage (sorting) . . . . 59

4.2.6 Dynamique des bigraphes . . . . 60

4.2.7 Bigraphes concrets et bigraphes abstraits . . . . 61

4.2.8 Outils pratiques autour des BRS . . . . 62

4.3 Langage Maude . . . . 63

4.3.1 Syntaxe et notations . . . . 63

4.3.2 Modules fonctionnels . . . . 64

4.3.3 Modules syst` emes . . . . 65

4.3.4 V´ erification formelle dans Maude . . . . 67

4.4 Th´ eorie des files d’attente . . . . 68

4.4.1 Objectif de l’analyse des files d’attente . . . . 69

4.4.2 Caract´ eristiques des syst` emes de files d’attente . . . . 70

4.4.3 Mod` eles de files d’attente . . . . 71

4.4.4 Th´ eorie des files d’attente et gestion dynamique des ressources . . . . 72

4.5 Conclusion . . . . 73

II Contributions 74 5 M´ ethodologie et contributions 76 5.1 Contexte et objectifs . . . . 76

5.2 M´ ethodologie et principes de la solution . . . . 77

5.2.1 Mod´ elisation formelle des syst` emes Cloud ´ elastiques . . . . 77

5.2.2 Ex´ ecution et v´ erification de l’´ elasticit´ e . . . . 78

5.2.3 Evaluation de l’´ ´ elasticit´ e . . . . 79

5.3 Organisation des contributions . . . . 80

6 Formalisation de l’´ elasticit´ e multi-couches dans le Cloud 82 6.1 Introduction . . . . 82

6.2 Approche bigraphique pour la mod´ elisation des syst` emes Cloud ´ elastiques . . . . 83

6.2.1 M´ eta-mod` ele d’un syst` eme Cloud ´ elastique . . . . 84

6.2.2 S´ emantique bigraphique pour la structure d’un syst` eme Cloud . . . . 85

6.2.3 S´ emantique bas´ ee BRS pour la dynamique d’un syst` eme Cloud ´ elastique . 88 6.2.4 Bilan et probl´ ematique . . . . 93

6.3 Strat´ egies d’´ elasticit´ e multi-couches dans le Cloud . . . . 94

6.3.1 Dimensionnement Horizontal . . . . 97

6.3.2 Migration et Load Balancing . . . . 99

6.3.3 Dimensionnement Vertical . . . 100

6.3.4 Bilan . . . 102

6.4 Conclusion . . . 102

7 Impl´ ementation et v´ erification du comportement ´ elastique d’un syst` eme Cloud 104

7.1 Introduction . . . 104

7.2 Encodage des sp´ ecifications bigraphiques dans Maude . . . 105

7.2.1 Principes de l’encodage . . . 105

7.2.2 Encodage des aspects structurels (module fonctionnel) . . . 106

7.2.3 Encodage des strat´ egies d’´ elasticit´ e (module syst` eme) . . . 108

7.2.4 Bilan . . . 110

7.3 V´ erification du comportement ´ elastique . . . 111

7.3.1 Comportement et propri´ et´ es ´ elastiques . . . 111

7.3.2 Encodage d’´ etats et de propri´ et´ es dans Maude . . . 114

7.3.3 V´ erification de propri´ et´ es . . . 115

7.3.4 Bilan . . . 118

7.4 Conclusion . . . 118

8 Evaluation quantitative des strat´ ´ egies d’´ elasticit´ e multi-couches 120 8.1 Introduction . . . 120

8.2 Etude de cas : mod´ ´ elisation de la plateforme Steam r . . . 121

8.3 Evaluation outill´ ´ ee de l’´ elasticit´ e ` a base de files d’attente . . . 124

8.3.1 Mod` ele de files d’attente . . . 124

8.3.2 Principes de la simulation ` a base de files d’attente . . . 126

8.3.3 Un outil pour la simulation de l’´ elasticit´ e dans le Cloud . . . 129

8.4 Simulation et ´ evaluation des comportements ´ elastiques de la plateforme Steam . 131 8.4.1 Param´ etrage des simulations . . . 131

8.4.2 Strat´ egies de dimensionnement Horizontal . . . 133

8.4.3 Migration et Load Balancing . . . 140

8.4.4 Strat´ egies de dimensionnement Vertical . . . 140

8.4.5 Comparaison de l’´ elasticit´ e Horizontale et Verticale . . . 143

8.5 Conclusion et discussion . . . 144

9 Conclusion G´ en´ erale 148 9.1 Contributions . . . 149

9.2 Perspectives . . . 150

Bibliographie 154

2.1 Le Cloud Computing selon le NIST [Dupont, 2016] . . . . 13

2.2 R´ epartition des tˆ aches d’administration des mod` eles de service . . . . 14

2.3 Mod` eles de d´ eploiement [Calliope, 2016] . . . . 15

2.4 Infrastructure virtualis´ ee [Dupont, 2016] . . . . 16

2.5 Architectures des machines virtuelles et des conteneurs Docker . . . . 17

2.6 Illustration de la tarification horaire par type d’instance de VM par Amazon . . . . 18

2.7 Illustration de la tarification horaire par type d’instance de VM par MS Azure . . . 18

2.8 Optimisation de l’utilisation des ressources : comparaison entre les mod` eles Cluster et Cloud. . . . . 20

2.9 Quadruplet de l’´ elasticit´ e [Galante and Bona, 2012] . . . . 22

2.10 ´ Elasticit´ e : sur/sous-dimensionnement dans les mod` eles Cluster et Cloud . . . . 25

2.11 Dimensionnement horizontal et vertical au niveau Infrastructure . . . . 26

2.12 Boucle de contrˆ ole autonomique MAPE-K . . . . 30

2.13 Vue d’ensemble du comportement ´ elastique autonomique d’un syst` eme Cloud . . . . 31

3.1 Vulcan, un gestionnaire de planification de l’´ elasticit´ e Vulcan [Letondeur, 2014] . . . 35

3.2 Coordination de contrˆ oleurs d’´ elasticit´ e entre VMs et conteneurs Docker [Al-Dhuraibi, 2018] . . . . 36

3.3 Architecture g´ en´ erale du Framework SCUBA [Dupont, 2016] . . . . 36

3.4 Architecture du Framework ElaaS [Kranas et al., 2012] . . . . 37

3.5 Architecture du Framework Vadara [Loff and Garcia, 2014] . . . . 38

3.6 M´ etriques de surveillance de l’´ elasticit´ e de MELA [Moldovan et al., 2015] . . . . 38

3.7 Architecture du Framework QoS-Aware Resource Elasticity (QRE) [Kaur and Chana, 2014] . . . . 39

3.8 Principe de mod´ elisation ` a base de files d’attente [Yataghene et al., 2014] . . . . 42

3.9 Vue d’ensemble du contrˆ oleur d’´ elasticit´ e pour les SBP [Amziani, 2015] . . . . 42

3.10 Fonctionnement de MoVeElastic [Sahli, 2017] . . . . 43

4.1 Anatomie des bigraphes . . . . 51

4.2 Graphe de places . . . . 51

4.3 Graphe de liens . . . . 51

4.4 Composition de deux graphes de places : A ^P = G ^P ◦ F ^P . . . . 54

4.5 Composition de deux graphes de liens : A ^L = G ^L ◦ F ^L . . . . 54

4.6 Composition de deux bigraphes : A = G ◦ F . . . . 55

4.7 Produit tensoriel de deux graphes de places : B ^P = B ^P ₀ ⊗ B ₁ ^P . . . . 56

4.8 Produit tensoriel de deux graphes de liens : B ^L = B ₀ ^L ⊗ B ₁ ^L . . . . 56

4.9 Produit tensoriel de deux bigraphes : B = B ₀ ⊗ B ₁ . . . . 57

4.10 Bigraphe U mod´ elisant le bˆ atiment B d’une universit´ e . . . . 60

4.11 Exemple d’une r` egle de r´ eaction bigraphique . . . . 61

4.12 Analyse des files d’attente [Gueroui, 2015] . . . . 70

4.13 Syst` eme de file d’attente simple [Gueroui, 2015] . . . . 70

4.14 Nombre de serveurs dans un syst` eme de files d’attente . . . . 71

4.15 R´ epartition des requˆ etes dans un syst` eme distribu´ e . . . . 72

5.1 Vue d’ensemble des contributions . . . . 77

5.2 Mod´ elisation et validation . . . . 80

6.1 Meta mod` ele : vision d’ensemble d’un syst` eme Cloud ´ elastique . . . . 84

6.2 Exemple d’un bigraphe CS mod´ elisant un syst` eme Cloud . . . . 88

6.3 Mod´ elisation des actions d’adaptations ´ elastiques par des r` egles de r´ eaction bigra- phiques . . . . 89

6.4 Forme graphique des r` egles de r´ eaction R3 et R6 . . . . 91

6.5 Forme graphique des r` egles de r´ eaction R7 et R10 . . . . 92

6.6 Forme graphique des r` egles de r´ eaction R11 et R12 . . . . 93

6.7 Forme graphique des r` egles de r´ eaction R13 et R14 . . . . 94

6.8 Forme graphique de la r` egle de r´ eaction R15 . . . . 96

7.1 Vue d’ensemble du principe d’encodage des sp´ ecifications bigraphiques dans Maude . 106 7.2 Syst` eme de transition pour l’´ elasticit´ e horizontale . . . 113

7.3 Syst` eme de transition pour l’´ elasticit´ e verticale . . . 113

7.4 Vue d’ensemble de la solution de sp´ ecification, d’ex´ ecution et de v´ erification dans Maude . . . 115

7.5 R´ esultat de la v´ erification de l’´ elasticit´ e horizontale sous LTL Maude . . . 116

7.6 Contre-exemple r´ esultant de la v´ erification de l’´ elasticit´ e horizontale par la n´ egation 117 7.7 R´ esultat de la v´ erification de l’´ elasticit´ e verticale sous LTL Maude . . . 117

7.8 Contre-exemple r´ esultant de la v´ erification de l’´ elasticit´ e horizontale par la n´ egation 118 8.1 Repr´ esentation bigraphique d’une configuration du service de vente en ligne Steam . 122 8.2 Principe d’application de l’approche file d’attente sur les syst` emes Cloud . . . 125

8.3 Impact du taux de service et de la taille de la file d’attente . . . 127

8.4 Mod` ele de workload impr´ evisible . . . 128

8.5 Infrastructures statiques vs. infrastructures ´ elastiques . . . 129

8.6 Structure fonctionnelle de l’outil de simulation de l’´ elasticit´ e . . . 129

8.7 Monitoring du sc´ enario H1 . . . 134

8.8 Monitoring du sc´ enario H2 . . . 135

8.9 Monitoring du sc´ enario H3 . . . 136

8.10 Monitoring du sc´ enario H4 . . . 138

8.11 ´ Evaluation de l’´ elasticit´ e horizontale en multi-couches . . . 139

8.12 Trace du monitoring de H2 ` a t=93 . . . 140

8.13 Monitoring de l’´ elasticit´ e verticale (sc´ enario V) . . . 142

8.14 Comparaison de l’´ elasticit´ e horizontale et verticale . . . 144

3.1 Etude d’environnements pour la gestion autonomique de l’´ ´ elasticit´ e dans le Cloud . 40 3.2 Etude de mod` ´ eles formels pour la sp´ ecification et la v´ erification de l’´ elasticit´ e dans

le Cloud . . . . 45

4.1 Principaux termes du langage alg´ ebrique des bigraphes . . . . 58

6.1 Contrˆ oles et sortes du bigraphe CS . . . . 86

6.2 R` egles de construction Φ _CS du bigraphe CS . . . . 87

6.3 R` egles de r´ eaction pour le dimensionnement et la migration des ressources . . . . 90

6.4 R` egles de r´ eaction pour l’´ etiquetage des ´ etats . . . . 96

6.5 Strat´ egies d’´ elasticit´ e Horizontale . . . . 98

6.6 Strat´ egies de migration et de load balancing . . . 100

6.7 Strat´ egies de dimensionnement Vertical . . . 101

7.1 Principales d´ eclarations du module fonctionnel Elastic Cloud System . . . 107

7.2 Principales d´ eclarations du module syst` eme Elastic Cloud Behavior . . . 109

7.3 Principales d´ eclarations du module Elastic Cloud Properties . . . 116

8.1 R´ esultats du sc´ enario H1 . . . 134

8.2 R´ esultats du sc´ enario H2 . . . 135

8.3 R´ esultats du sc´ enario H3 . . . 137

8.4 R´ esultats du sc´ enario H4 . . . 138

8.5 R´ esultats du sc´ enario V . . . 142

8.6 Comparaison de l’´ elasticit´ e horizontale et verticale . . . 144

Amazon EC2 Amazon Elastic Compute Cloud

AP Atomic Propositions

API Application Programming Interface BigMC Bigraphical Model Checker

BigraphER Bigraph Evaluator and Rewriting

BPL Bigraphical Programming Language Project BRS Bigraphical Reactive Systems

CdM Chaˆıne de Markov

CLTLt(d) Timed Constraint Linear Temporal Logic CPN Colored Petri Nets

CPU Central Processing Unit ElaaS Elasticity as a Service FIFO First In First Out

IaaS Infrastructure as a Service

LB Load Balancer

LTL Logique Temporelle Lin´ eaire LTS Labeled Transition System

MAPE-K Monitor, Analyse, Plan, Execute - Knowledge MFA Mod` ele de Files d’Attente

MS Microsoft

NIST National Institute of Standards and Technology OCaml Objective Categorical Abstract Machine Language OCCI Open Cloud Computing Interface

OR Objectif de Recherche

OS Operating System

PaaS Platform as a Service

PC Personal Computer

PM Machine Physique

PN Petri Nets

PUE Power Usage Efficiency QoE Quality of Experience QoS Quality of Service

QRE QoS-aware resource elasticity

RAM Random Access Memory

SaaS Software as a Service SAT Satisfiability

SBP Service-based Businesss Process

SJF Shortest Job First

SRB Syst` emes R´ eactifs Bigraphiques TFA Th´ eorie des Files d’Attente

TIC Technologies de l’Information et de la Communication

VM Machine Virtuelle

Introduction g´ en´ erale

Sommaire

1.1 Contexte . . . . 2

1.2 Probl´ ematique . . . . 3

1.3 Objectifs et contributions . . . . 5

1.4 Plan de th` ese . . . . 6

1.5 Diffusion scientifique . . . . 7

1.1 Contexte

Depuis leur ´ emergence, les technologies de l’information et de la communication (TIC) ont connu une ´ evolution constante suivant un rythme tr` es soutenu. Afin de maintenir une pr´ esence sur le march´ e des TIC de plus en plus exigent, de nombreuses organisations, tant industrielles qu’acad´ emiques, ont œvr´ e pour r´ eduire les coˆ uts de fonctionnement des syst` emes informatiques, assurer leur mise ` a l’´ echelle, fournir de bonnes performances ` a leurs applications, tout en optimisant les coˆ uts li´ es ` a l’utilisation des ressources infor- matiques. Plusieurs technologies sont apparues au fil des ann´ ees telles que les syst` emes distribu´ es, le traitement parall` ele, le Grid Computing, la virtualisation et d’autres, afin de relever le d´ efi de l’efficacit´ e de la gestion des ressources et le d´ eploiement des applications [Zhang et al., 2010]. Cependant, avec la croissance de nouvelles exigences m´ etier, notam- ment en termes de flexibilit´ e, de souplesse, de simplicit´ e, d’´ economies financi` eres ou en- core d’efficience ´ energ´ etique, le paradigme Cloud Computing ou ”informatique en nuage”

a ´ emerg´ e cette derni` ere d´ ecennie et s’est impos´ e en apportant une ` ere de renouveau. En se basant sur ces diff´ erentes technologies, le Cloud apporte de nouvelles caract´ eristiques et principes ` a l’approvisionnement des ressources informatiques. La terme ”nuage” est une m´ etaphore qui d´ esigne en r´ ealit´ e un r´ eseau de ressources informatiques (mat´ erielles et logicielles) qui se pr´ esentent sous la forme de services qu’un utilisateur peut consommer

`

a la demande via un r´ eseau, g´ en´ eralement internet, et selon un mod` ele de facturation

”pay-as-you-go”, proportionnel ` a l’utilisation r´ eelle des ressources [Chan, 2014, Fox et al., 2009].

Le Cloud introduit de nombreux avantages tels que le d´ eploiement plus facile et plus

rapide des applications au sein d’infrastructures Cloud, avec l’assurance d’une disponibi-

lit´ e accrue et une fiabilit´ e optimale [Suleiman et al., 2012]. Cela en fait l’un des mod` eles

les plus adopt´ es dans le monde de l’industrie, de la recherche scientifique ainsi que par

le grand public. Afin de satisfaire les exigences de ses usagers, le Cloud offre l’acc` es ` a

des service diff´ erents selon les besoins sp´ ecifiques d’un client. Les services Cloud peuvent

ˆ

etre classifi´ es selon trois couches ou mod` eles : infrastructure en tant que service (IaaS), plateforme en tant que service (PaaS) et logiciel en tant que service (SaaS). Ces mod` eles pr´ esentent des avantages et des inconv´ enients. Pr´ ecis´ ement, la souplesse d’utilisation et la capacit´ e de contrˆ ole des services, ainsi que les connaissances requises pour les utiliser tendent ` a diminuer du niveau IaaS au niveau SaaS. Un service IaaS propose l’acc` es ` a des ressources virtualis´ ees (e.g. Machines Virtuelles - VMs) que l’utilisateur doit configurer, ce qui n’est pas ` a la port´ ee des usagers non sp´ ecialis´ es. D’un autre cˆ ot´ e, un utilisateur d’un service SaaS peut interagir avec son application ` a travers une interface de program- mation (API) facilement exploitable, mais n’a aucun contrˆ ole sur l’infrastructure Cloud sous-jacente.

Avec l’´ evolution constante des exigence du march´ e des TIC et de celles de ses usa- gers, le Cloud incarne d´ esormais un environnement hautement dynamique et variable ` a large ´ echelle. Dans ce contexte, le paradigme Cloud se distingue des autres paradigmes par l’une de ses caract´ eristiques principales : l’´ elasticit´ e. L’´ elasticit´ e dans le Cloud est un concept qui vise ` a optimiser la gestion des ressources informatiques. L’id´ ee est de permettre ` a un syst` eme Cloud, dit ”´ elastique” ou dot´ e d’un ”comportement ´ elastique”

[Bersani et al., 2014], de r´ epondre efficacement aux sollicitions variables de ses clients en termes de d’utilisation de ressources informatiques. Cela consiste ` a rajouter et ` a re- tirer des ressources informatiques en vue de s’adapter aux changement dans sa charge de travail actuelle. L’enjeu consiste ` a maintenir une qualit´ e de service optimale, tout en minimisant les coˆ uts li´ es ` a l’utilisation des ressources informatiques. L’´ elasticit´ e fournit des m´ ecanismes qui permettent ` a un syst` eme Cloud de supporter, au mieux, une mont´ ee de la charge de travail puis un retour ` a la normale, sans interruption de service et si possible sans r´ epercussions sur la qualit´ e du service. D’un autre cˆ ot´ e, l’´ elasticit´ e permet de respecter les engagements ”pay-as-you-go” en fournissant des m´ ecanismes de mise ` a l’´ echelle en cas de baisse de la charge, dans le but d’´ eviter les sur-facturations inutiles.

En d’autres termes, l’´ elasticit´ e incarne l’un des rouages n´ ecessaires ` a l’optimisation des ressources (i.e., optimisation de coˆ uts), tout en assurant aux utilisateurs un niveau de service optimal (i.e., optimisation des performances), dans un contexte de plus en plus dynamique et variable [Herbst et al., 2013].

Un syst` eme Cloud peut adopter un comportement ´ elastique au niveau de l’une ou plusieurs de ses couches (IaaS, PaaS et SaaS). Lorsque l’´ elasticit´ e est appliqu´ ee sur plus d’une couche du Cloud, on parle alors d’´ elasticit´ e multi-couches ou encore de comporte- ment ´ elastique multi-couches [Kouki and Ledoux, 2013, Copil et al., 2013]. L’´ elasticit´ e est assur´ ee selon des strat´ egies r´ eactives ou pr´ edictives et via trois m´ ethodes : le dimension- nement horizontal (ou ´ elasticit´ e horizontale), le dimensionnement vertical (ou ´ elasticit´ e verticale) et la migration. L’´ elasticit´ e horizontale consiste ` a r´ epliquer ou supprimer des instances de VMs ou de services (couche IaaS ou SaaS respectivement). L’´ elasticit´ e ver- ticale augmente ou r´ eduit la quantit´ e de ressources allou´ ees ` a une VM ou un conteneur (selon la couche IaaS ou PaaS respectivement). Enfin, la m´ ethode de migration consiste

`

a d´ eplacer ou red´ eployer une instance d’un hˆ ote vers un autre hˆ ote.

1.2 Probl´ ematique

En vue des exigences m´ etier li´ ees ` a la gestion des ressources informatiques dans le

Cloud telles que la fiabilit´ e, la r´ eactivit´ e et l’efficacit´ e, l’´ elasticit´ e est g´ en´ eralement g´ er´ ee

de mani` ere autonomique. Elle est assur´ ee de mani` ere automatis´ ee et en minimisant les

interventions humaines dont l’efficacit´ e d´ ecline, face ` a ces d´ efis de plus en plus complexes.

Ainsi, l’´ elasticit´ e est g´ en´ eralement assur´ ee par un contrˆ oleur d’´ elasticit´ e : une entit´ e au- tonomique qui r´ egit le comportement ´ elastique d’un syst` eme Cloud, lui conf´ erant des capacit´ es d’auto adaptation en termes de gestion dynamique des ressources [Jamshidi et al., 2014].

Plusieurs grands acteurs de l’industrie du Cloud proposent des solutions pour la ges- tion autonomique de l’´ elasticit´ e tels que Rackspace, Amazon EC2, Google AppEngine et Microsoft Azure. Ces solutions commerciales ne sont globalement pas totalement matures, elles sont relativement r´ ecentes et pr´ esentent des limites en termes de contrˆ ole d’´ elasticit´ e et d’adaptation dynamique de la consommation de ressources. Cela influe sur la dispo- nibilit´ e, la performance ainsi que sur la facturation des services utilis´ es [Gambi et al., 2016]. De plus, les m´ ecanismes propos´ es par ces solutions industrielles se limitent souvent

`

a la sp´ ecification des services Cloud requis, sans tenir compte de leurs comportements

´

elastiques. D’un autre cˆ ot´ e, plusieurs solutions issues du monde acad´ emique mettent au point des contrˆ oleurs d’´ elasticit´ e visant ` a g´ erer, de mani` ere autonomique, l’allocation des ressources dans le Cloud. Ces solutions sont souvent bas´ es sur un principe de boucles de contrˆ ole autonomique ferm´ ees, g´ en´ eralement selon le mod` ele MAPE-K (Monitor, Ana- lyse, Plan, Execute - Knowledge) introduit par IBM [Jacob et al., 2004]. Selon ce mod` ele, le contrˆ oleur d’´ elasticit´ e surveille le syst` eme Cloud g´ er´ e afin de recueillir des informations sur son ´ etat en termes de performances, de consommation de ressources, etc. [Trihinas et al., 2014]. Ensuite, ces informations sont analys´ ees afin de diagnostiquer d’´ eventuels

´

etats non-d´ esir´ es. Enfin, le contrˆ oleur d’´ elasticit´ e d´ ecide des actions ` a d´ eclencher, en termes de m´ ethodes d’´ elasticit´ e, et ´ etablit un plan d’action ` a ex´ ecuter afin de corriger, si besoin, l’´ etat du syst` eme Cloud g´ er´ e.

Les solutions existantes ne d´ ecrivent globalement pas de comportements g´ en´ eriques et traitent d’un aspect particulier de l’´ elasticit´ e. Pr´ ecis´ ement, certaines se focalisent sur l’´ elasticit´ e horizontale et la migration tandis que d’autres traitent uniquement de l’´ elasticit´ e verticale. Certaines se concentrent sur une ou plusieurs couches du Cloud (IaaS, PaaS, SaaS) et d’autres introduisent des strat´ egies d’´ elasticit´ e uniquement ` a un seul ni- veau. Certaines solutions introduisent un mod` ele d’´ elasticit´ e r´ eactive tandis que d’autres proposent un mod` ele d’´ elasticit´ e pr´ edictive. Enfin, la plupart des solutions propos´ ees dans la litt´ erature sont coˆ uteuses et tr` es difficiles ` a mettre en œuvre dans les environnements Cloud. En outre, elles peuvent provoquer des comportements ind´ esirables, si elles ne sont pas correctement con¸cues.

Le comportement ´ elastique d’un syst` eme Cloud d´ epend de la combinaison d’une multi- tude de facteurs tels que la quantit´ e de ressources disponible, la charge de travail en entr´ ee, la logique gouvernant le comportement du contrˆ oleur d’´ elasticit´ e ou encore les diff´ erentes politiques de haut niveau et propri´ et´ es ` a satisfaire. La complexit´ e de ces d´ ependances, ainsi que la maitrise des potentiels effets de bords n´ efastes sur l’´ etat global du syst` eme, rendent la conception des syst` emes Cloud ´ elastiques tr` es difficile.

Face ` a la complexit´ e grandissante des syst` emes Cloud, leur conception est devenue de plus en plus difficile ` a maˆıtriser, et leur maintenance, de plus en plus coˆ uteuse ` a assu- rer. Les m´ ethodes de d´ eveloppement classiques, bien que coˆ uteuses, se montrent souvent inefficaces pour garantir de mani` ere exhaustive le champ de validit´ e du comportement

´

elastique d’un syst` eme Cloud, et peinent ` a assurer sa fiabilit´ e et robustesse.

1.3 Objectifs et contributions

Afin de fournir une bonne gestion de l’´ elasticit´ e, il est indispensable de s’appuyer sur un mod` ele qui permet de d´ ecrire les architectures des syst` emes Cloud, ainsi que leur comportement ´ elastique. La mod´ elisation est une tˆ ache imp´ erative qui permet de d´ eterminer et comprendre les changements structurels et les d´ ependances comportemen- tales dans un syst` eme Cloud ´ elastique afin d’´ eviter l’´ emergence des comportements pro- voquant des situations ind´ esirables telles que l’instabilit´ e dans l’allocation des ressources et la d´ egradation de la qualit´ e de service. Dans ce contexte, les m´ ethodes formelles ca- ract´ eris´ ees par leur efficacit´ e, fiabilit´ e et pr´ ecision, pr´ esentent une solution efficace pour relever ce d´ efi et pour ´ eliminer les ambigu¨ıt´ es s´ emantiques et la complexit´ e provenant de la tˆ ache de mod´ elisation. Ceci permet de raisonner rigoureusement sur les sp´ ecifications formelles obtenues pour d´ emontrer leur validit´ e ` a travers plusieurs techniques de simu- lations et v´ erifications formelles. De plus, afin de garantir l’efficacit´ e des comportements

´

elastiques d´ efinis, il est primordial de les ´ evaluer et de les valider du point de vue quan- titatif, avant de les utiliser dans des environnement Cloud r´ eels.

Afin de proposer une solution compl` ete pour la gestion et l’analyse de l’´ elasticit´ e dans les syst` emes Cloud, nous identifions les principaux objectifs de recherche (OR) suivants : OR1- D´ efinir les comportements ´ elastiques multi-couches d’un syst` eme Cloud.

OR2- Assurer une ex´ ecution autonomique de ces comportements.

OR3- V´ erifier le bon fonctionnement de ces comportements.

OR4- Evaluer les performances et les coˆ ´ uts li´ es ` a ces comportements.

En d’autres termes, l’objectif g´ en´ eral de cette th` ese tend ` a proposer une solution ` a fondements formels pour la sp´ ecification des syst` emes Cloud ´ elastiques, la v´ erification du bon fonctionnement de leurs comportements ´ elastiques ainsi que l’´ evaluation de leurs performances. Le pr´ esent manuscrit pr´ esente les contributions suivantes :

1. S´ emantique bigraphique structurelle : Dans un premier temps, il s’agit de proposer un cadre formel la sp´ ecification des aspects structurels des syst` emes Cloud ´ elastiques.

Un tel mod` ele permettrait d’exprimer les ´ el´ ements pertinents d’une architecture Cloud en multi-couche, c’est ` a dire aux niveaux infrastructure et application. Nous proposons un mod` ele bas´ e sur le formalisme des bigraphes et leur logique de typage associ´ ee afin d´ ecrire une s´ emantique robuste et d´ etaill´ ees pour les syst` emes Cloud et des entit´ es les composant.

2. S´ emantique BRS comportementale et strat´ egies d’´ elasticit´ e multi-couches : En com-

pl´ ement de la pr´ ec´ edente contribution, nous d´ efinissons une s´ emantique bas´ ee sur

les syst` emes r´ eactifs bigraphiques (BRS) pour la mod´ elisation des actions de recon-

figuration dynamiques des syst` emes Cloud. Les reconfigurations du syst` eme sont

mod´ elis´ ees en termes de r` egles de r´ eaction bigraphiques s’appliquant au niveau

des diff´ erentes ressources mat´ erielles et logicielles d´ eploy´ ees au sein du syst` eme

(multi-couches). ` A partir des diff´ erentes actions identifi´ ees, l’id´ ee et de proposer

plusieurs strat´ egies pour le contrˆ ole des reconfigurations du syst` eme. Pr´ ecis´ ement,

nous avons introduit des strat´ egies d´ ecrivant les diff´ erentes m´ ethodes d’´ elasticit´ e

(horizontale, verticale, migration et load balancing) pouvant s’appliquer en multi- couche, ` a diff´ erents niveaux du syst` eme (infrastructure, application, ressources).

3. Repr´ esentation de l’´ etat ´ elastique des syst` emes Cloud : Nous proposons une solu- tion pour la repr´ esentation et l’expression des ´ etats du point de vue de l’´ elasticit´ e d’un syst` eme Cloud. Les ´ etats identifi´ es servent ` a d´ egager des ´ etats d´ esirables et ind´ esirables en termes d’´ elasticit´ e, servant ` a guider le dimensionnement ´ elastique d’un syst` eme Cloud.

4. Impl´ ementation, ex´ ecution autonomique et v´ erification formelle des strat´ egies d’´ elas- ticit´ e : Nous pr´ esentons un encodage des sp´ ecifications bigraphiques et des strat´ egies d’´ elas-ticit´ e dans le langage de sp´ ecification formelle Maude. Cet encodage permet de pr´ eserver la s´ emantique structurelle des syst` emes Cloud tout en l’enrichissant d’aspects quantitatifs et la possibilit´ e d’exprimer les ´ etats du syst` eme ` a travers des pr´ edicats de la logique du premier ordre. En outre, nous proc´ edons ` a la v´ erification formelle de l’´ elasticit´ e des syst` emes Cloud mod´ elis´ es. Cette v´ erification se base sur une technique de model-checking ` a base d’´ etats, support´ ee par la logique temporelle lin´ eaire LTL.

5. Evaluation et validation quantitative : ´ Enfin, nous proposons une ´ etude exp´ erimentale des comportements ´ elastiques introduits d’un syst` eme Cloud. Nous tentons d’´ evaluer ces comportements d’un point de vue quantitatif, ` a travers une ´ etude de cas d’un syst` eme Cloud existant. Nous pr´ esentons une solution outill´ ee, ` a base de files d’at- tente, afin de simuler le fonctionnement des diff´ erentes strat´ egies d’´ elasticit´ e d´ efinies.

1.4 Plan de th` ese

Ce manuscrit de th` ese est d´ ecoup´ e en deux grandes parties organis´ ees comme suit : 1. La premi` ere partie est constitu´ ee de l’art de l’art de la th` ese. Le Chapitre 2 traite du

contexte dans lequel s’inscrit le sujet de la th` ese au travers d’un certain de nombre de d´ efinitions et concepts de base li´ es au paradigme Cloud Computing. Le Chapitre 3 expose un ´ etat de l’art visant ` a recenser et analyser plusieurs travaux existants li´ es ` a l’´ elasticit´ e dans le Cloud. Le but est d’identifier les manques et limites des solutions industrielles et acad´ emiques, en vue d’identifier les manques et limitations et ainsi d´ egager les enjeux de cette th` ese. Enfin, le Chapitre 4 pr´ esente les princi- paux mod` eles et th´ eories formelles, au centre de la th` ese, afin de pr´ eparer le lecteur

`

a une bonne compr´ ehension des contributions qui y sont pr´ esent´ ees.

2. La seconde partie pr´ esente les contributions scientifiques de cette th` ese. Elle est

introduite par le Chapitre 5 donnant une vision d’ensemble des contributions. Le

Chapitre 6 pr´ esente notre approche ` a base de syst` emes r´ eactifs bigraphiques pour

la gestion autonomique de l’´ elasticit´ e multi-couches dans le Cloud, en couvrant les

aspects structurels et comportementaux et en introduisant des strat´ egies pour le

dimensionnement ´ elastique (horizontal, vertical, load balancing et migration) en

multi-couches (infrastructure et application) d’un systt` eme Cloud. Le Chapitre 7

pr´ esente une approche pour l’impl´ ementation, l’ex´ ecution et la v´ erification des com-

portements ´ elastiques d’un syst` eme Cloud. Nous y pr´ esentons un encodage, dans

Maude, des sp´ ecifications bigraphiques introduites ainsi qu’une solution pour la v´ erification formelle des comportements ´ elastiques ` a travers une technique de model- checking support´ e par la logique LTL. Enfin, le Chapitre 8 pr´ esente notre approche outill´ ee pour la simulation et l’´ evaluation de l’´ elasticit´ e d’un syst` eme Cloud. Nous y appliquons notre approche de mod´ elisation formelle sur une ´ etude de cas d’un syst` eme Cloud existant, puis nous simulons, analysons et ´ evaluons ses comporte- ments ´ elastiques.

1.5 Diffusion scientifique

Les travaux pr´ esent´ es dans ce manuscrit ont fait l’objet de plusieurs publications list´ ees ci-dessous.

Revue scientifique avec comit´ e de lecture

— Khebbeb, K., Hameurlain, N., Belala, F., Sahli, H. (2018) Formal Modelling and Verifying Elasticity Strategies in Cloud Systems. In : IET Software. 13(1), pp. 25-35.

The Institution of Engineering and Technology [Khebbeb et al., 2018b].

Conf´ erence internationale avec comit´ e de lecture

— Khebbeb K., Hameurlain N., Belala F. (2018) Modeling and Evaluating Cross-layer Elasticity Strategies in Cloud Systems. In : Abdelwahed E., Bellatreche L., Golfarelli M., M´ ery D., Ordonez C. (eds) Model and Data Engineering. MEDI 2018. Lecture Notes in Computer Science, vol 11163. pp. 168-183. Springer, Cham [Khebbeb et al., 2018a].

— Khebbeb K., Sahli H., Hameurlain N., Belala F. (2017) A BRS Based Approach

for Modeling Elastic Cloud Systems. In : Braubach L. et al. (eds) Service-Oriented

Computing – ICSOC 2017 Workshops. ICSOC 2017. Lecture Notes in Computer

Science, vol 10797. pp. 5-17. Springer, Cham [Khebbeb et al., 2017].

Etat de l’Art ´

Principaux concepts et d´ efinitions

Sommaire

2.1 Introduction . . . 10 2.2 Les syst` emes Cloud Computing . . . 11 2.2.1 D´ efinitions . . . 11 2.2.2 Caract´ eristiques . . . 12 2.2.3 Mod` eles de service . . . 12 2.2.4 Mod` eles de d´ eploiement . . . 14 2.2.5 Acteurs du Cloud . . . 15 2.2.6 Virtualisation . . . 16 2.2.7 Mod` ele ´ economique . . . 17 2.2.8 Efficience et Cloud Computing . . . 19 2.3 Elasticit´ ´ e dans le cloud . . . 20 2.3.1 D´ efinitions . . . 20 2.3.2 Niveaux d’action de l’´ elasticit´ e . . . 22 2.3.3 Strat´ egies d’´ elasticit´ e et techniques sous-jacentes . . . 22 2.3.4 Objectifs de l’´ elasticit´ e . . . 24 2.3.5 M´ ethodes d’´ elasticit´ e . . . 25 2.4 Informatique autonomique . . . 27 2.4.1 D´ efinitions . . . 27 2.4.2 Propri´ et´ es autonomiques . . . 27 2.4.3 Boucle de contrˆ ole autonomique . . . 29 2.4.4 Contrˆ oleur d’´ elasticit´ e autonomique dans les syst` emes Cloud . . . 31 2.5 Conclusion . . . 32

2.1 Introduction

Depuis leur ´ emergence, les technologies de l’information et de la communication (TIC)

ont connu une ´ evolution constante, suivant un rythme tr` es soutenu. Afin de maintenir une

pr´ esence sur le march´ e des TIC de plus en plus exigent, de nombreuses organisations, tant

industrielles qu’acad´ emiques, ont œvr´ e pour trouver la meilleure fa¸con de r´ eduire les coˆ uts

de fonctionnement, assurer la mise ` a l’´ echelle de leurs syst` emes informatiques, fournir une

bonne performance ` a leurs applications tout en optimisant les coˆ uts li´ es ` a l’utilisation des

ressources informatiques. Plusieurs technologies sont apparues au fil des ann´ ees, telles

que les syst` emes distribu´ es, le traitement parall` ele, le Grid Computing, la virtualisa-

tion et d’autres, traitant de l’efficacit´ e de la gestion des ressources et le d´ eploiement des

applications. Avec la croissance de nouvelles exigences m´ etiers, notamment en termes de flexibilit´ e, de souplesse, de simplicit´ e, d’´ economies financi` eres ou encore d’efficience

´

energ´ etiques, le paradigme ”Cloud Computing” a ´ emerg´ e cette derni` ere d´ ecennie, appor- tant une ` ere de renouveau. Ce paradigme se base sur ces technologies tout en apportant de nouvelles caract´ eristiques et principes ` a l’approvisionnement des ressources informa- tiques.

Dans ce premier Chapitre consacr´ e ` a l’´ etat de l’art, nous pr´ esentons le contexte dans lequel s’inscrit le sujet du pr´ esent manuscrit de th` ese. Nous y pr´ esentons un certain nombre de d´ efinition de technologies et de concepts de base li´ es ` a nos travaux. Dans un premier temps, nous pr´ esentons, dans la Section 2.2 le paradigme Cloud Computing, ses d´ efinitions et ses caract´ eristiques. Ensuite, nous introduisons la notion d’´ elasticit´ e, une caract´ eristique essentielle du Cloud. Nous aborderons sa d´ efinition, ses m´ ecanismes et ses enjeux dans la gestion de l’allocation dynamique des ressources dans le cloud (Section 2.3).

Enfin, nous discutons le contexte hautement dynamique et complexe qu’incarne le Cloud Computing dans la Section 2.4. Nous y pr´ esentons le domaine de l’informatique autono- mique, une philosophie visant ` a doter les syst` emes de capacit´ es d’auto-administration.

2.2 Les syst` emes Cloud Computing

Le Cloud Computing ou informatique en nuage est un paradigme r´ ecent de la techno- logie de l’information qui se base sur plusieurs technologies existantes. La terme

nuage

est une m´ etaphore qui d´ esigne en r´ ealit´ e un r´ eseau de ressources informatiques (mat´ e- rielles et logicielles) fournies sous forme de services que l’utilisateur peut consommer ` a la demande via un r´ eseau, g´ en´ eralement internet, selon un mod` ele de facturation pro- portionnel ` a l’utilisation r´ eelle des ressources [Chan, 2014, Fox et al., 2009, Dupont, 2016]. Le terme

Cloud Computing

est apparu vers la fin des ann´ ees 2000. Ce para- digme est le r´ esultat de la recherche et l’ing´ enierie en informatique visant ` a r´ epondre aux probl´ ematiques li´ ees au partage de ressources informatiques et ` a l’optimisation de leur utilisation. En effet, ´ etant donn´ es les coˆ uts ´ elev´ es d’acquisition de mat´ eriel informatique (notamment dans les ann´ ees 1960) et son faible taux d’utilisation, l’id´ ee de fournir un service informatique publique centralis´ e, partag´ e et facilement accessible via un r´ eseau a naturellement vu le jour et fut connue sous le nom d’informatique utilitaire [Garfinkel, 1999, Kleinrock, 1976]. ` A cette ´ epoque, cette vision fut utopique en vue des limitations technologiques. Par la suite, la maturation constante des technologies mat´ erielles, logi- cielles et des r´ eseaux aboutirent ` a une premi` ere concr´ etisation de ces objectifs (dans les ann´ ees 1990) avec l’apparition du Grid Computing. Plus tard, les ann´ ees 2000 connurent enfin l’apparition du paradigme Cloud Computing.

Dans cette Section, nous aborderons les diff´ erents aspects et concepts cl´ es qui d´ efinissent le Cloud Computing. Nous ´ evoquerons l’´ evolution de sa d´ efinition, ses caract´ eristiques, ses mod` eles de service et de d´ eploiement ainsi que les diff´ erents acteurs au centre de son fonctionnement.

2.2.1 D´ efinitions

Tout au long de sa maturation, le paradigme Cloud a connu de nombreuses d´ efinitions

incompl` etes et parfois approximatives, g´ en´ eralement se focalisant sur un aspect particu-

lier de ce mod` ele [Buyya et al., 2008, Fox et al., 2009, Wang et al., 2010, Borenstein and

Blake, 2011]. La d´ efinition la plus adopt´ ee et largement accept´ ee comme la plus compl` ete

a ´ et´ e apport´ ee par le NIST en 2011 : ”Cloud Computing is a model for enabling ubiqui- tous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.

This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models.” [Mell et al., 2011]. Selon le NIST, le mod` ele du Cloud Computing repose sur cinq caract´ eristiques principales, trois mod` eles de service et quatre mod` eles de d´ eploiement (voir Figure 2.1).

2.2.2 Caract´ eristiques

Le cloud se distingue par les cinq caract´ eristiques essentielles suivantes :

— Libre-service ` a la demande (on-demand self-service) : L’utilisateur peut r´ eserver ou lib´ erer les ressources (CPU, stockage, bande pasasnte, etc.) en fonction de ses besoins sans interaction avec le fournisseur du service. Les ressources sont fournies d’une mani` ere enti` erement automatis´ ee au client. Ce dernier peut g´ erer ` a distance ses ressources, g´ en´ eralement au moyen d’une interface.

— Acc` es ubiquitaire via le r´ eseau (broad network access) : L’ensemble des ressources est accessible de partout (navigateurs WEB, smartphones, tablettes, etc.) via le r´ eseau (Internet ou priv´ e) en s’appuyant sur des m´ ecanismes standards facilitant l’acc` es au service pour diff´ erents types de clients.

— Mise en commun des ressources (resource pooling) : Le fournisseur mutualise les ressources (ou services) qu’il attribue dynamiquement aux diff´ erents clients en fonc- tion de la demande. Ce partage des ressources est la caract´ eristique qui diff´ erencie le Cloud Computing de autres mod` eles dits classiques.

— Service mesur´ e (measured service) : L’utilisateur est factur´ e en fonction de son utili- sation en ressources ou services (selon la politique pay-as-you-go). Cette utilisation est contrˆ ol´ ee, mesur´ ee et communiqu´ ee aux usagers ou fournisseur de service de fa¸con transparente.

— Elasticit´ ´ e rapide (rapid elasticity) : L’acc` es aux ressources est assur´ e de mani` ere souple et rapide. Les ressources peuvent ˆ etre approvisionn´ ees ou lib´ er´ ees rapidement, g´ en´ eralement de mani` ere automatis´ ee, pour r´ epondre ` a des besoins qui ´ evoluent vite (e.g., mont´ ee ou baisse soudaine de la charge de travail). Cette automatisation de l’approvisionnement des ressources est assur´ ee de mani` ere dite

autonomique

et est g´ en´ eralement assur´ ee par un composant autonomique connu sous le nom de contrˆ oleur d’´ elasticit´ e (elasticity controller ) [Bersani et al., 2014].

2.2.3 Mod` eles de service

Selon le NIST, le paradigme Cloud se manifeste en trois couches principales :

— SaaS (Software as a Service) : La couche des ”logiciels en tant que service” regroupe

les applications accessibles via internet o` u le mat´ eriel, l’h´ ebergement, l’environne-

ment d’application et le logiciel sont d´ emat´ erialis´ es et dont la gestion est en de-

hors de la responsabilit´ e de l’usager. Les applications de type SaaS sont diverses et

vari´ ees. On peut citer les applications telles que la messagerie Gmail, l’´ editeur de

documents Office 365, le r´ eseau social Facebook, les services de stockage de donn´ ees

Google Drive et DropBox, ou encore le service de cartographie en ligne Google Maps.

Figure 2.1 – Le Cloud Computing selon le NIST [Dupont, 2016]

— IaaS (Infrastructure as a Service) : Dans cette couche, la ressource fournie est une infrastructure informatique compl` ete virtualis´ ee. Physiquement, les ressources mat´ erielles (hardware) proviennent d’une multitude de serveurs et de r´ eseaux g´ en´ era- lement distribu´ es ` a travers de nombreux centres de donn´ ees (datacenters). Une solu- tion IaaS permet aux utilisateurs d’acc´ eder de fa¸con flexible ` a des syst` emes virtuels complets en d´ eployant /arrˆ etant ` a la demande des ressources virtuelles dans des datacenters, dont la responsabilit´ e d’entretien (notamment du mat´ eriel sous-jacent) revient au fournisseur de de l’infrastructure Cloud. Parmi les acteurs principaux de IaaS, on retrouve Amazon EC2 [Cloud, 2011], Microsoft Azure [Copeland et al., 2015] ou encore RackSpace [Rackspace, 2010]. Il existe aussi des solutions open- source telle que OpenStack [Sefraoui et al., 2012].

— PaaS (Platform as a Service) : La couche des ”plateformes en tant que service”

offre l’acc` es ` a un environnement de d´ eveloppement administr´ e, h´ eberg´ e et maintenu par le fournisseurs de la plateforme PaaS. Le but ´ etant de faciliter le d´ eploiement et l’ex´ ecution des applications SaaS en ajoutant une couche de services ` a la couche IaaS.

En d’autres termes, le PaaS, situ´ e entre la couche SaaS et la couche IaaS, abstrait la couche IaaS ` a ses utilisateurs. Cela permet aux ´ equipes de d´ eveloppement de se concentrer sur l’architecture et la r´ ealisation des applications sans se soucier des d´ etails de configuration de l’infrastructure (mat´ eriel, r´ eseau, etc.). Comme exemples de PaaS, on peut citer Cloud Foundry, Google App Engine, ainsi que le projet open- source OpenShift [OpenShift, 2019].

la Figure 2.2 montre les diff´ erentes responsabilit´ es ` a la charge des fournisseurs des diff´ erents

mod` eles de service, en d´ etaillant les tˆ aches d’administration et de gestion qui les in-

combent. Le mod` ele interne repr´ esente les mod` eles dits classiques o` u tous les d´ etails de

l’installation du syst` eme sont ` a la charge du fournisseur de service. R´ ecemment, l’acro-

nyme XaaS (Anything as a Service [Schaffer, 2009]) ou

tout en tant que service

a vu le jour du fait du nombre croissant d’applications bas´ ees sur le concept d’externalisation de fonctionnalit´ es sous forme de services (e.g. DaaS : Data as a Service, NaaS : Network as a Service, GaaS : Gaming as a Service, etc.).

Figure 2.2 – R´ epartition des tˆ aches d’administration des mod` eles de service

2.2.4 Mod` eles de d´ eploiement

Le NIST d´ efinit quatre mod` eles de d´ eploiement pour le Cloud Computing (voir Figure 2.3) :

— Cloud priv´ e : il s’agit d’un environnement dont les ressources servent exclusivement l’entreprise utilisatrice. L’infrastructure peut ˆ etre localis´ ee/g´ er´ ee sur place ou par un tiers mais l’entreprise est la seule ` a l’utiliser. Ce mod` ele offre un haut degr´ e de contrˆ ole et de sensibilit´ e, permettant au propri´ etaire d’un service ` a facilement maitriser et administrer son syst` eme en termes de r` eglementations ou de s´ ecurit´ e, par exemple.

— Cloud communautaire : l’infrastructure est partag´ ee entre plusieurs organisations et peut ˆ etre g´ er´ ee par le groupe ou par un tiers. Ce mod` ele est g´ en´ eralement adopt´ e par les institutions gouvernementales, hˆ opitaux, hˆ otels, etc. afin de profiter de ressources communes (r´ eseau, stockage, s´ ecurit´ e, etc.), ce qui assure un fonctionnement efficace des diff´ erents d´ eploiements concern´ es.

— Cloud public : les ressources sont fournies par un prestataire, propri´ etaire de celles-

ci, et mutualis´ ees pour un usage partag´ e. Ce mod` ele est largement adopt´ e par les

fournisseurs de IaaS afin d’offrir une large offre de ressources partag´ ees, ` a faible coˆ ut

et g´ er´ ees de mani` ere ´ elastique.

— Cloud hybride : il s’agit de la combinaison de plusieurs clouds ind´ ependants publics ou priv´ es. Ceux-ci doivent respecter des standards et des technologies communes pour assurer la portabilit´ e des applications entre les clouds. Dans ce mod` ele de d´ eploiement, une entreprise peut, par exemple, tirer parti du faible coˆ ut d’un cloud public pour l’h´ ebergement de certains services classiques, tout en recourant ` a un cloud priv´ e pour g´ erer des services plus sensibles (confidentialit´ e, s´ ecurit´ e, etc.).

Figure 2.3 – Mod` eles de d´ eploiement [Calliope, 2016]

2.2.5 Acteurs du Cloud

Selon le NIST, on distingue cinq acteurs majeurs au centre du fonctionnement du paradigme Cloud Computing : le fournisseur, l’usager, l’auditeur, le courtier et le trans- porteur de Cloud. Ces acteurs repr´ esentent une entit´ e physique ou morale (une personne ou une organisation) qui prend part ` a un processus ou transactions dans le Cloud, de la mani` ere suivante :

— Le fournisseur (cloud provider) : Repr´ esente une personne ou un organisme met- tant un ensemble de services cloud ` a la disposition d’usagers (ou consommateurs) potentiels.

— L’usager (cloud costumer) : Repr´ esente une personne, un organisme ou une entit´ e qui se prˆ ete ` a l’utilisation des diff´ erents services mis ` a disposition par le fournisseur, g´ en´ eralement via un contrat client.

— L’auditeur (cloud auditor) : Repr´ esente une entit´ e dont la tˆ ache est de mesurer et d’´ evaluer les services Cloud en termes de performances, s´ ecurit´ e, coˆ uts, etc., tout en restant ind´ ependant du fournisseur et des usagers du cloud.

— Le courtier (cloud broker) : Repr´ esente un parti qui s’occupe de la gestion et la pres- tation de service cloud en n´ egociant les relations entre les usagers et le fournisseur Cloud.

— Le transporteur (cloud carrier) : Repr´ esente un organisme ou une entit´ e interm´ ediaire

qui s’occupe de fournir la connectivit´ e et la disponibilit´ e des services Cloud, en les

transportant du fournisseur vers le consommateur.

2.2.6 Virtualisation

La virtualisation est une technique permettant de reproduire le comportement d’une machine physique (Physical Machine - PM) dans un environnement logiciel appel´ e ma- chine virtuelle (Virtual Machine - VM). Cette technique donne ` a l’utilisateur l’illusion de manipuler une PM alors qu’en r´ ealit´ e, il interagit avec un environnement logiciel (VM).

La virtualisation offre la possibilit´ e d’ex´ ecuter plusieurs syst` emes d’exploitation et/ou applications sur un seul serveur physique. Chaque VM ex´ ecute son propre syst` eme d’ex- ploitation (Operating System - OS) permettant ` a l’utilisateur d’h´ eberger des logiciels sur plusieurs plateformes diff´ erentes. Le syst` eme d’exploitation d’une VM est qualifi´ e d’OS- invit´ e pour le distinguer de celui de la PM, appel´ e OS-hˆ ote. Le concept de virtualisation apporte de tr` es nombreux avantages tels que l’optimisation de l’utilisation des ressources existantes par la mutualisation des ressources physiques qui r´ esulte en une ´ economie sur le mat´ eriel. Initialement, cette technique vise ` a

consolider

ou d´ emat´ erialiser les infra- structures physiques afin de maximiser leur utilisation [Poniatowski, 2009]. Une VM est donc un conteneur de logiciels isol´ e, capable d’ex´ ecuter ses propres syst` emes d’exploitation et applications. Les VMs sont cr´ e´ ees et g´ er´ ees par des logiciels appel´ es hyperviseurs (voir Figure 2.4) qui leur permet d’acc´ eder directement au mat´ eriel de la PM. Les diff´ erentes ressources (CPU, RAM, stockage, r´ eseau) sont allou´ ees aux VMs de mani` ere cloisonn´ ee ` a partir d’une PM ce qui permet de maximiser leur utilisation. Ces ressources sont qualifi´ ees de virtuelles mais sont en r´ ealit´ e bien r´ eelles. [Smith and Nair, 2005].

Figure 2.4 – Infrastructure virtualis´ ee [Dupont, 2016]

La virtualisation compl` ete apport´ ee par les VMs implique l’embarquement du syst` eme

d’exploitation en plus de l’ensemble des librairies et applications. Cette contrainte a amen´ e

la communaut´ e ` a proposer une autre approche, notamment avec l’av` enement de Docker

[Docker, 2019] poussant un peu plus loin la notion de mutualisation : les conteneurs l´ egers

(par opposition ` a la VM, parfois qualifi´ ee de conteneur lourd). Cette approche vise ` a mu-

tualiser le syst` eme d’exploitation et certaines librairies all´ egeant ainsi consid´ erablement

la granularit´ e des briques d´ eploy´ ees ce qui permet de gagner en rapidit´ e de d´ eploiement

(cf. Figure 2.5). Un conteneur l´ eger peut ˆ etre d´ eploy´ e aussi bien sur des PMs que sur

des VMs. L’approche conteneurs l´ egers reste parfois critiqu´ ee en termes de s´ ecurit´ e et

d’isolation par rapport aux VMs. En effet, il n’est pas possible ` a l’heure actuelle d’iso-

ler les ressources (i.e. CPU, RAM, etc.) utilis´ ees par des conteneurs bas´ es sur la mˆ eme

machine, ce qui peut amener un conteneur ` a monopoliser les ressources de ses voisins et

ainsi d´ estabiliser l’ensemble du syst` eme. La derni` ere version de Docker introduit la pos-

sibilit´ e d’appliquer une limite maximum de consommation de ressource pour l’ensemble des conteneurs d’une mˆ eme machine. Bien que cela ´ evite les d´ erives, il n’est pas encore possible d’allouer de mani` ere fine et dynamique des ressources aux conteneurs en fonction de leur besoin via l’API de haut niveau. Ceci est toutefois contournable en s’appuyant sur la fonctionnalit´ e cgroups (i.e. control groups) du noyau Linux dans le but de limiter, compter ou isoler l’utilisation des ressources ou encore de prioriser celles-ci pour certains groupes.

Figure 2.5 – Architectures des machines virtuelles et des conteneurs Docker

2.2.7 Mod` ele ´ economique

Grˆ ace ` a la mutualisation des ressources informatiques, le Cloud permet des ´ economies d’´ echelle pour les fournisseurs de service. En effet, la mutualisation de la demande as- soci´ ee aux atouts de la virtualisation, notamment en termes de flexibilit´ e, favorisent une exploitation maximale des ressources disponibles au niveau des PMs. D’autres avantages doivent ˆ etre pris en compte tels que la possibilit´ e pour les gestionnaires de centres de donn´ ees de b´ en´ eficier de remises quantitatives sur le mat´ eriel utilis´ e ou encore la possibi- lit´ e d’automatiser un certain nombre de tˆ aches d’administration. Cela permet, en sortie, de r´ eduire la somme totale des coˆ uts associ´ es. D’un autre cˆ ot´ e, les usagers des services du Cloud b´ en´ eficient ´ egalement d’avantages financiers. En effet, la souplesse du Cloud assure un acc` es facile et quasi imm´ ediat ` a des ressources informatiques sans investissement im- portant (e.g. acquisition de mat´ eriel, de licences, etc.) et sans engagement ` a long terme.

De plus, les coˆ uts d’exploitation associ´ es ` a l’utilisation de ces services sont amoindris (e.g. frais de maintenance, de mise ` a jour, etc.). De cette mani` ere, les usagers prennent moins de risques en s’appuyant sur un fournisseur plus exp´ eriment´ e pour la r´ ealisation de certaines fonctionnalit´ es. Cette option peut finalement s’av´ erer plus rentable du fait qu’ils b´ en´ eficient eux aussi des ´ economies d’´ echelles r´ ealis´ ees par les fournisseurs.

Choix d’offres. Les fournisseurs IaaS proposent une large gamme d’instances (VMs) en fonction des besoins des utilisateurs. Concr` etement, il s’agit de multiples combinaisons en mati` ere de capacit´ es CPU, RAM, stockage et r´ eseau. Chaque type d’instance propose une ou plusieurs tailles possibles en fonction des exigences li´ ees ` a au type de la tˆ ache cibl´ ee.

Cela varie d’une micro instance avec 1 vCPU et 1 Gio de m´ emoire ` a une 10xlarge instance

avec 40 vCPU et 160 Gio de m´ emoire [Amazon, 2019]. la Figure 2.6 donne un aper¸cu de la tarification horaire d’Amazon EC2 en fonction des offres de VM. La facturation propos´ ee par Microsoft Azure est illustre´ e dans la Figure 2.7 [Microsoft, 2019].

Figure 2.6 – Illustration de la tarification horaire par type d’instance de VM par Amazon

Figure 2.7 – Illustration de la tarification horaire par type d’instance de VM par MS Azure Paiement ` a l’usage. Le mod` ele de facturation ` a l’usage, commun´ ement appel´ e pay-per-use ou selon le mod` ele pay-as-you-go, est l’une des caract´ eristiques du Cloud. Ce mod` ele de facturation assure le client de payer exclusivement ce qu’il consomme r´ eellement au mo- ment o` u il consomme. On distingue de nombreuses offres Cloud de complexit´ e variable.

Au niveau du mod` ele de service IaaS, la tarification est un sujet assez complexe ` a cause

de la difficult´ e de comparaison des offres. Pour la plupart des IaaS publics du march´ e, la

tarification correspond ` a une heure d’instance consomm´ ee pour chaque instance. Cepen-

dant, en sachant que chaque heure partielle consomm´ ee est enti` erement factur´ ee (comme