Autonomie, sécurité et QoS de bout en bout dans un environnement de Cloud Computing

HAL Id: tel-01257829

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

Submitted on 18 Jan 2016

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.

Autonomie, sécurité et QoS de bout en bout dans un environnement de Cloud Computing

Mohamad Hamze

To cite this version:

Mohamad Hamze. Autonomie, sécurité et QoS de bout en bout dans un environnement de Cloud

Computing. Réseaux et télécommunications [cs.NI]. Université de Bourgogne, 2015. Français. �NNT :

2015DIJOS033�. �tel-01257829�

Thèse de Doctorat

n

é c o l e d o c t o r a l e s c i e n c e s p o u r l ’ i n g é n i e u r e t m i c r o t e c h n i q u e s

U N I V E R S I T É D E B O U R G O G N E

Autonomie, sécurité et QoS de bout en bout dans un environnement de Cloud Computing

M ^OHAMAD H ^AMZE

Thèse de Doctorat

é c o l e d o c t o r a l e s c i e n c e s p o u r l ’ i n g é n i e u r e t m i c r o t e c h n i q u e s

U N I V E R S I T É D E B O U R G O G N E

THÈSE présentée par

M OHAMAD H ^AMZE

pour obtenir le

Grade de Docteur de l’Université de Bourgogne

Spécialité : Informatique

Autonomie, sécurité et QoS de bout en bout dans un environnement de Cloud Computing

Unité de Recherche :

Le2i - Laboratoire Electronique, Informatique et Image

Soutenue publiquement le 07 décembre 2015 devant le Jury composé de :

F RANCINE K RIEF Rapporteur Professeure à Bordeaux INP

D JAMAL B ENSLIMANE Rapporteur Professeur à l’Université de Lyon

Y EHIA T AHER Examinateur Maître de conférences à l’Université de Versailles

O LIVIER T OGNI Directeur de thèse Professeur à l’Université de Bourgogne

N ADER M BAREK Co-encadrant de thèse Maître de conférences à l’Université de Bourgogne

N ^◦ X X X

R ÉSUMÉ

De nos jours, le Cloud Networking est considéré comme étant l’un des domaines de re- cherche innovants au sein de la communauté de recherche du Cloud Computing. Les principaux défis dans un environnement de Cloud Networking concernent non seulement la garantie de qualité de service (QoS) et de sécurité mais aussi sa gestion en confor- mité avec un accord de niveau de service (SLA) correspondant. Dans cette thèse, nous proposons un Framework pour l’allocation des ressources conformément à un SLA établi de bout en bout entre un utilisateur de services Cloud (CSU) et plusieurs fournisseurs de services Cloud (CSP) dans un environnement de Cloud Networking (architectures d’inter- Cloud Broker et Fédération). Nos travaux se concentrent sur les services Cloud de types NaaS et IaaS. Ainsi, nous proposons l’auto-établissement de plusieurs types de SLA ainsi que la gestion autonome des ressources de Cloud correspondantes en conformité avec ces SLA en utilisant des gestionnaires autonomes spécifiques de Cloud. De plus, nous étendons les architectures et les SLA proposés pour offrir un niveau de service intégrant une garantie de sécurité. Ainsi, nous permettons aux gestionnaires autonomes de Cloud d’élargir leurs objectifs de gestion autonome aux fonctions de sécurité (auto-protection) tout en étudiant l’impact de la sécurité proposée sur la garantie de QoS. Enfin, nous va- lidons notre architecture avec différents scénarios de simulation. Nous considérons dans le cadre de ces simulations des applications de vidéoconférence et de calcul intensif afin de leur fournir une garantie de QoS et de sécurité dans un environnement de gestion au- tonome des ressources du Cloud. Les résultats obtenus montrent que nos contributions permettent de bonnes performances pour ce type d’applications. En particulier, nous ob- servons que l’architecture de type Broker est la plus économique, tout en assurant les exigences de QoS et de sécurité. De plus, nous observons que la gestion autonome des ressources du Cloud permet la réduction des violations, des pénalités et limite l’impact de la sécurité sur la garantie de la QoS.

Mots-clés : Cloud Computing, Cloud Networking, Inter-Cloud, Service Level Agreement, Qualité de Service, Sécurité, Gestion Autonome, Videoconférence, Calcul Intensif.

v

A BSTRACT

Today, Cloud Networking is one of the recent research areas within the Cloud Compu- ting research communities. The main challenges of Cloud Networking concern Quality of Service (QoS) and security guarantee as well as its management in conformance with a corresponding Service Level Agreement (SLA). In this thesis, we propose a framework for resource allocation according to an end-to-end SLA established between a Cloud Service User (CSU) and several Cloud Service Providers (CSPs) within a Cloud Networking envi- ronment (Inter-Cloud Broker and Federation architectures). We focus on NaaS and IaaS Cloud services. Then, we propose the self-establishing of several kinds of SLAs and the self-management of the corresponding Cloud resources in conformance with these SLAs using specific autonomic cloud managers. In addition, we extend the proposed architec- tures and the corresponding SLAs in order to deliver a service level taking into account security guarantee. Moreover, we allow autonomic cloud managers to expand the self- management objectives to security functions (self-protection) while studying the impact of the proposed security on QoS guarantee. Finally, our proposed architecture is validated by different simulation scenarios. We consider, within these simulations, videoconferen- cing and intensive computing applications in order to provide them with QoS and security guarantee in a Cloud self-management environment. The obtained results show that our contributions enable good performances for these applications. In particular, we observe that the Broker architecture is the most economical while ensuring QoS and security re- quirements. In addition, we observe that Cloud self-management enables violations and penalties’ reduction as well as limiting security impact on QoS guarantee.

Keyword : Cloud Computing, Cloud Networking, Inter-Cloud, Service Level Agreement, Quality of Service, Security, Self-management, Videoconferencing, Intensive Computing.

vii

R EMERCIEMENTS

En préambule à ce travail, je tiens tout d’abord à remercier les responsables de cette thèse, Pr. Olivier TOGNI et Dr. Nader MBAREK, pour m’avoir fait confiance malgré les connaissances plutôt légères que j’avais au début de ma thèse en octobre 2012 sur le Cloud, puis pour m’avoir guidé, encouragé, et conseillé pendant les trois ans tout en me laissant une grande liberté et en me faisant l’honneur de me déléguer plusieurs respon- sabilités dont j’espère avoir été à la hauteur. Leur disponibilité et leurs conseils ont été d’une grande qualité. Je ne sais pas comment exprimer ma gratitude à ces deux per- sonnes autrement qu’en leur promettant d’agir comme eux avec des étudiants dans ma situation, si un jour l’occasion m’en est donnée.

Pr. Francine KRIEF et Pr. Djamal BENSLIMANE ont accepté d’être les rapporteurs de cette thèse, et je les en remercie, de même que pour leur participation au Jury.

Je remercie aussi bien mes collèges pour les discussions que j’ai eu la chance d’avoir avec eux.

Pour leurs encouragements et leur assistance aussi bien matérielle que morale qui m’ont permis de faire cette thèse dans de bonnes conditions, mes plus profonds remerciements vont à mes parents. Tout au long de mon cursus, ils m’ont toujours soutenu, encouragé et aidé. Qu’ils trouvent, dans la réalisation de ce travail, l’aboutissement de leurs efforts ainsi que l’expression de ma plus affectueuse gratitude. Je remercie aussi chaudement Ghenwa, ma femme qui m’a soutenu durant les trois ans de ma thèse. Elle a su me donner toutes les chances pour réussir. Je remercie DIEU qui m’a béni avec mon premier fils Ali qui est né à quelques jours de la finalisation de ma thèse. Je souhaiterais remercier également le reste de la famille, mes amis et mes proches pour leur encouragement tout au long de la réalisation de ce mémoire.

Je tiens aussi à mentionner le plaisir que j’ai eu à travailler au sein du laboratoire Le2i, l’école doctorale SPIM et l’université de Bourgogne, et je remercie ici tous les membres de ces institutions.

Merci à tous et à toutes.

ix

S OMMAIRE

Résumé v

Abstract vii

Remerciements ix

Liste des figures xix

Liste des tables xxi

Liste des abréviations xxiii

Chapitre 1 Introduction 1

1.1 Contexte . . . . 1

1.2 Objectifs de la thèse . . . . 3

1.3 Plan de la thèse . . . . 3

Chapitre 2 Cloud Computing, Cloud Networking et Inter-Cloud 5 2.1 Introduction . . . . 5

2.2 Cloud Computing . . . . 5

2.2.1 Historique . . . . 5

2.2.2 Définition . . . . 6

2.2.3 Caractéristiques . . . . 7

2.2.4 Modèles de services . . . . 8

2.2.4.1 Software as a service (SaaS) . . . . 8

2.2.4.2 Platform as a Service (PaaS) . . . . 8

2.2.4.3 Infrastructure as a Service (IaaS) . . . . 9

2.2.4.4 Network as a Service (NaaS) . . . . 9

2.2.5 Modèles de déploiement . . . 10

2.2.5.1 Cloud public . . . 10

2.2.5.2 Cloud privé . . . 10

2.2.5.3 Cloud communauté . . . 10

xi

xii SOMMAIRE

2.2.5.4 Cloud hybride . . . 11

2.2.6 Standardisation . . . 11

2.2.7 Outils d’implémentation et de simulation . . . 13

2.2.8 Produits commerciaux . . . 15

2.3 Cloud Networking . . . 16

2.3.1 Définition . . . 16

2.3.2 Caractéristiques . . . 16

2.3.3 Outils d’implémentation et de simulation . . . 17

2.4 Inter-Cloud . . . 18

2.4.1 Définition . . . 18

2.4.2 Caractéristiques et Modèles d’Inter-Cloud . . . 18

2.4.2.1 Inter-Cloud de type Peering . . . 18

2.4.2.2 Inter-Cloud de type Broker . . . 18

2.4.2.3 Inter-Cloud de type Fédération . . . 20

2.4.3 Outils d’implémentation et de simulation . . . 21

2.4.4 Produits commerciaux . . . 21

2.5 Conclusion . . . 22

Chapitre 3 Niveau de service et gestion autonome dans le Cloud 23 3.1 Introduction . . . 23

3.2 Qualité de service dans un environnement de Cloud . . . 24

3.2.1 Définition . . . 24

3.2.2 Caractéristiques . . . 24

3.2.3 Service Level Agreement . . . 25

3.2.4 Challenges . . . 25

3.2.5 Travaux de standardisation portant sur la QoS dans le Cloud . . . 26

3.2.6 Projets de recherche portant sur la QoS dans le Cloud . . . 26

3.2.7 Travaux de recherche portant sur la QoS dans le Cloud . . . 26

3.3 Sécurité dans un environnement de Cloud . . . 29

3.3.1 Définition . . . 29

3.3.2 Confiance . . . 29

3.3.3 Services de sécurité dans un environnement de Cloud . . . 29

3.3.4 Service Level Agreement de sécurité . . . 30

3.3.5 Challenges . . . 31

3.3.6 Travaux de standardisation portant sur la sécurité dans le Cloud . . . 33

SOMMAIRE xiii

3.3.7 Projets de recherche portant sur la sécurité dans le Cloud . . . 35

3.3.8 Travaux de recherche portant sur la sécurité dans le Cloud . . . 35

3.4 Gestion Autonome . . . 37

3.4.1 Définition . . . 37

3.4.2 Caractéristiques . . . 37

3.4.3 Boucle de contrôle (MAPE-K) . . . 38

3.4.4 Challenges . . . 39

3.4.5 Travaux de standardisation relatifs à la gestion autonome dans le Cloud 40 3.4.6 Projets de recherche portant sur la gestion autonome du Cloud . . . . 41

3.4.7 Travaux de recherche portant sur la gestion autonome du Cloud . . . 42

3.5 Conclusion . . . 43

Chapitre 4 Proposition d’une architecture pour l’offre de QoS dans le Cloud Networking 45 4.1 Introduction . . . 45

4.2 Description de l’architecture . . . 45

4.2.1 Types de CSP et des services offerts . . . 45

4.2.2 Types de SLA . . . 48

4.2.3 GUI . . . 53

4.3 Architecture de type Broker . . . 54

4.3.1 Description de l’architecture . . . 54

4.3.2 Spécification et description des SLA . . . 55

4.3.3 Interactions entre les entités de l’architecture Broker . . . 56

4.4 Architecture de type Fédération . . . 57

4.4.1 Description de l’architecture . . . 57

4.4.2 Spécification et description des SLA . . . 57

4.4.3 Interactions entre les entités de l’architecture de type Fédération . . . 58

4.5 Conclusion . . . 61

Chapitre 5 Garantie de QoS dans un environnement de Cloud Networking 63 5.1 Introduction . . . 63

5.2 Problématique . . . 63

5.3 Algorithmes et contraintes proposés . . . 64

5.3.1 Algorithme et contraintes relatifs à l’offre du service NaaS sans IaaS . 65

5.3.1.1 Algorithme et contraintes pour la sélection des ressources

réseau . . . 66

xiv SOMMAIRE

5.3.2 Algorithme et contraintes relatifs à l’offre du service IaaS avec/sans

NaaS . . . 67

5.3.2.1 Algorithme et contraintes pour la sélection des ressources réseau . . . 68

5.3.2.2 Algorithme et contraintes pour la sélection des ressources de type VM . . . 70

5.3.2.3 Algorithme et contraintes pour la sélection des ressources de stockage . . . 75

5.4 Évaluation du coût relatif à l’offre de QoS . . . 78

5.4.1 Coût relatif au service de type NaaS . . . 79

5.4.2 Coût relatif au service IaaS de type VM . . . 79

5.4.3 Coût relatif au service IaaS de type Stockage . . . 80

5.5 Validation de notre proposition de garantie de QoS dans un environnement de Cloud Networking . . . 80

5.5.1 Environnement de simulation . . . 80

5.5.2 Cloud vidéoconférence . . . 82

5.5.2.1 Scénario de simulation . . . 82

5.5.2.2 Résultats . . . 83

5.5.3 Calculs intensifs . . . 86

5.5.3.1 Scénario de simulation . . . 87

5.5.3.2 Résultats . . . 87

5.6 Conclusion . . . 91

Chapitre 6 Gestion Autonome des architectures de Cloud Networking 93 6.1 Introduction . . . 93

6.2 Problématique . . . 93

6.3 Architecture autonome proposée . . . 94

6.3.1 Présentation de l’architecture . . . 94

6.3.2 Description du gestionnaire autonome proposé . . . 96

6.3.3 Interactions entres les gestionnaires autonomes . . . 97

6.4 Gestion autonome de l’offre de QoS dans le Cloud . . . 98

6.4.1 Gestion autonome du SLA dans l’architecture Broker . . . 98

6.4.2 Gestion autonome du SLA dans l’architecture Fédération . . . 99

6.4.3 Gestionnaires autonomes de bas niveau (AM) . . . 101

6.4.4 Gestionnaires autonomes de haut niveau : iAM d’un CSP (DC/BoD) . 102 6.4.5 Garantie de QoS avec l’iAM du Broker ou du CSP _L . . . 105

6.5 Gestion autonome des violations . . . 107

SOMMAIRE xv

6.5.1 Détection de violation . . . 107

6.5.2 Calcul des pénalités . . . 108

6.5.3 Calcul de la réputation des CSP . . . 109

6.6 Validation de notre architecture de gestion autonome . . . 110

6.6.1 Environnement de simulation . . . 110

6.6.2 Cloud vidéoconférence . . . 110

6.6.2.1 Scénario de simulation . . . 110

6.6.2.2 Résultats . . . 112

6.6.3 Calculs intensifs . . . 114

6.6.3.1 Scénario de simulation . . . 114

6.6.3.2 Résultats . . . 115

6.7 Conclusion . . . 117

Chapitre 7 Sécurité des architectures de Cloud Networking 119 7.1 Introduction . . . 119

7.2 Amélioration de l’architecture proposée avec la sécurité . . . 119

7.2.1 Amélioration du niveau de service avec la sécurité . . . 120

7.2.2 Amélioration de l’interface utilisateur graphique avec la sécurité . . . . 122

7.2.3 Amélioration des SLA avec la garantie de sécurité . . . 122

7.2.4 Amélioration des coûts intégrant la QoS et la sécurité . . . 124

7.3 Amélioration des algorithmes de sélection proposés . . . 125

7.3.1 Contrainte et violation de sécurité . . . 125

7.3.2 Garantie de QoS et de sécurité . . . 126

7.3.3 Garantie de sécurité seulement (c.à.d. sans QoS) . . . 126

7.4 Architecture pour la distribution des certificats de sécurité . . . 127

7.4.1 Tierce partie de confiance (TTP) . . . 127

7.4.2 Architecture de distribution des certificats . . . 128

7.5 Intégration de la sécurité dans l’architecture autonome de Cloud . . . 130

7.5.1 Impact de la sécurité sur la qualité de service . . . 130

7.5.2 Intégration de la sécurité dans les gestionnaires autonomes . . . 130

7.6 Validation de l’offre de sécurité dans l’architecture Cloud Networking . . . 131

7.6.1 Environnement de simulation . . . 131

7.6.2 Cloud vidéoconférence . . . 132

7.6.2.1 Scénario de simulation . . . 132

7.6.2.2 Résultats . . . 134

xvi SOMMAIRE

7.7 Conclusion . . . 135

Chapitre 8 Conclusion générale 137

8.1 Bilan . . . 137 8.2 Perspectives . . . 139 8.3 Publications . . . 139

Bibliographie 141

Annexe 153

Annexe A Unités utilisées dans les représentations des schémas XML . . . 153

L ISTE DES FIGURES

1 Différence entre le modèle de paiement classique et celui du Cloud. . . . . 7

2 Exemple d’organisations de standardisation du Cloud. . . 12

3 Inter-Cloud de type Peering. . . 18

4 Inter-Cloud de type Broker. . . 19

5 Inter-Cloud de type Fédération. . . 20

6 Détails fonctionnels d’un gestionnaire autonome (AM). . . 39

7 Représentation du schéma XML des niveaux de service associés aux res- sources offertes par le CSP (BoD). . . 46

8 Représentation du schéma XML des niveaux de service associés aux res- sources offertes par le CSP (DC). . . . 47

9 Représentation du schéma XML des niveaux de service de VM. . . . 48

10 Représentation du schéma XML des niveaux de service de stockage. . . . 48

11 Représentation du schéma XML de l’attribut période de validité d’un SLA. . 49

12 Représentation du schéma XML de l’attribut identification de service. . . 50

13 Représentation du schéma XML des services de type NaaS et IaaS. . . 50

14 Représentation du schéma XML de l’attribut garanties de performance. . . 51

15 Représentation du schéma XML de l’iSLA. . . . 51

16 Représentation du schéma XML du B_iSLA. . . . 52

17 Représentation du schéma XML du D_iSLA. . . . 53

18 GUI pour les Préférences du CSU. . . 54

19 Architecture Cloud Networking de type Inter-Cloud Broker. . . 55

20 Interactions entre les entités de l’architecture de type Broker. . . 56

21 Architecture Cloud Networking de type Fédération. . . 58

22 Interactions entre des entités de l’architecture de type Fédération (scénario 1). . . 59

23 Interactions entre les entités de l’architecture de type Fédération (scéna- rios 2 et 3). . . 60

24 Représentation schématisée de l’algorithme 1. . . 67

25 Représentation schématisée de l’algorithme 2. . . 70

26 Représentation schématisée de l’algorithme 3. . . 73

xvii

xviii LISTE DES FIGURES

27 Représentation schématisée de l’algorithme 4. . . 76

28 Délai moyen global de bout en bout dans une architecture de type Broker. . 84

29 Délai moyen global de bout en bout dans une architecture de type Fédération. 84 30 Délai moyen global de bout en bout pour une sélection statique. . . . 85

31 Comparaison de la gigue entre les trois scénarios. . . 85

32 Comparaison du coût global de la bande passante entre les trois scénarios. 86 33 Comparaison du coût global de VM entre les trois scénarios. . . 86

34 Délai moyen global pour un service IaaS sans NaaS dans l’architecture Broker. . . 88

35 Délai moyen global pour un service IaaS sans NaaS dans l’architecture Fédération. . . 88

36 Délai moyen global pour un service IaaS avec NaaS dans l’architecture Broker. . . 89

37 Délai moyen global pour un service IaaS avec NaaS dans l’architecture Fédération. . . 89

38 Délai moyen global pour une sélection statique sans garantie de QoS. . . . 90

39 Comparaison du coût global de la bande passante. . . 90

40 Comparaison du coût global des VM. . . 91

41 Architecture Autonome de Cloud Networking. . . 95

42 Gestionnaire Autonome de Cloud (AM). . . 96

43 Interactions des AM pour le scénario Broker. . . 97

44 Interactions des AM pour le scénario Fédération. . . 98

45 Automate du cycle de vie d’établissement autonome du SLA pour l’iAM Broker. . . 99

46 Automate du cycle de vie d’établissement autonome du SLA pour l’iAM CSP _L . . . 100

47 Automate du cycle de vie d’AM de bat niveau (nAM, DnAM et hAM). . . 101

48 Automate du cycle de vie de l’iAM d’un CSP (DC/BoD). . . 103

49 Automate du cycle de vie de l’iAM du Broker ou du CSP L pour la gestion autonome des ressources. . . . 105

50 Fonction proposée pour les pénalités. . . 109

51 Évaluation du coût global de la bande passante. . . 112

52 Évaluation de la latence globale de bout en bout. . . 112

53 Évaluation du coût global du CSU et de la pénalité. . . 113

54 Évaluation de la réputation pour le CSP ₁ (BoD). . . 113

55 Évaluation du coût global de VM. . . 115

56 Évaluation du temps de réponse global de bout en bout. . . 115

LISTE DES FIGURES xix

57 Évaluation du coût global du CSU et de la pénalité. . . 116

58 Évaluation de la réputation pour le CSP ₁ (DC). . . 116

59 Représentation XML des paramètres de sécurité associés aux services NaaS. . . 120

60 Représentation XML des paramètres de sécurité associés aux services IaaS.121 61 Amélioration de l’interface GUI par la sécurité pour les exigences du CSU. . 122

62 Partie garantie de sécurité ajoutée dans l’interface GUI. . . 122

63 Représentation du schéma XML de l’iSLA. . . . 123

64 Représentation XML de l’attribut Service Security Guarantees. . . 124

65 Architecture de distribution des certificats. . . 128

66 Évaluation du coût global de la bande passante. . . 133

67 Évaluation du coût global de VM. . . 133

68 Évaluation de la latence moyenne de bout en bout. . . 134

L ISTE DES TABLES

1 Exemples de plateformes d’implémentation du Cloud. . . 13 2 Exemples de logiciels de simulation du Cloud. . . 14 3 Exemples de produits commerciaux du Cloud. . . . 15 4 Exemples d’outils d’implémentation et de simulation du Cloud Networking. . 17 5 Exemples d’outils d’implémentation et de simulation de l’Inter-Cloud. . . 21 6 Exemples de produits commerciaux de l’Inter-Cloud. . . 22 7 Exemple d’organismes de standardisation de la QoS dans le Cloud. . . 26 8 Exemple de projets de recherche portant sur la QoS dans le Cloud. . . . . 27 9 Exemple d’organisations de standardisation de la sécurité dans le Cloud. . 34 10 Exemple de projets de recherche portant sur la sécurité dans le Cloud. . . 36 11 Exemple d’organismes de standardisation de la gestion autonome dans le

Cloud. . . 41 12 Exemples de projets de recherche portant sur la gestion autonome dans

le Cloud. . . 42 13 Notation des variables. . . 65 14 Niveaux de service pour un service de type IaaS offerts par un CSP (DC). . 81 15 Niveaux de service pour un service de type NaaS offerts par un CSP

(DC/BoD). . . 82 16 Coût des niveaux de service de sécurité offerts par un CSP (DC/BoD). . . . 132

xxi

L ISTE DES ABRÉVIATIONS

AD Autonomic cloud Domain Domaine autonome de Cloud

AM Autonomic cloud Manager Gestionnaire autonome de Cloud

API Application Programming Interface Interface de programmation d’application ASP Application Service Provider Fournisseur de services application ATM Asynchronous Transfer Mode Mode de transfert asynchrone

B_iSLA BoD inter-cloud Service Level Agreement Accord de niveau de service pour la BoD

BoD Bandwidth on Demand bande passante à la demande

CPU Central Processing Unit Unité centrale de traitement CSP Cloud Service Provider Fournisseur de services Cloud

CSU Cloud Service User Utilisateur de services Cloud

DC Data Center Centre de données

D_iSLA DC inter-cloud Service Level Agreement Accord de niveau de service pour le DC DnAM Datacenter network Autonomic Manager Gestionnaire autonome de DC

GUI Graphical User Interface Interface d’utilisateur graphique hAM hypervisor Autonomic Manager Gestionnaire autonome d’hyperviseur IaaS Infrastructure as a Service Infrastructure en tant que service iAM inter-cloud Autonomic Manager Gestionnaire autonome dl’Inter-Cloud iSLA inter-cloud Service Level Agreement Accord de niveau de service d’Inter-Cloud NaaS Network as a Service Réseau en tant que service

nAM network Autonomic Manager Gestionnaire autonome de réseau PaaS Platform as a Service Plateforme en tant que service

QoS Quality of Service Qualité de service

RAM Random Access Memory Mémoire à accès direct

SaaS Software as a Service Logiciel en tant que service SLA Service Level Agreement Accord de niveau de service

TTP Trust Third Party Tierce partie de confiance

VM Virtual Machine Machine virtuelle

VPN Virtual Private Network Réseau Privé Virtuel

XML Extensible Markup Language Langage à balise extensible

xxiii

C HAPITRE 1 I NTRODUCTION

1.1/ C ONTEXTE

De nos jours, l’utilisation d’Internet et des nouvelles technologies, pour satisfaire l’évolu- tion continue des besoins de différents types d’utilisateurs (affaire, particulier), fait partie de la vie quotidienne. Toute information est disponible partout dans le monde à tout mo- ment. Cela n’était pas possible il y a quelques années. Récemment, un nombre important de possibilités d’accès à l’information publique et privée sont apparues. Ainsi, nous avons un accès généralisé à grand débit à Internet grâce au déploiement de dispositifs fixes, mobiles ou encore sans fil qui permettent la connexion à Internet sans presque se soucier de la limitation géographique.

Aujourd’hui, différents types d’utilisateurs consultent leurs courriers en ligne via des Web- mail, rédigent des documents de collaboration en utilisant les navigateurs web, exécutent des applications et stockent des données dans des serveurs situés sur Internet et non dans leurs propres ordinateurs. De plus, ces services ainsi que d’autres sont utilisés d’une façon transparente pour l’utilisateur et sont donc perçus comme étant des services offerts par un nuage (Cloud) sans en connaître les détails. Cela signifie que de nombreux utilisateurs et organisations peuvent éviter l’installation de certaines applications sur leurs infrastructures ou peuvent avoir plus de puissance de calcul en utilisant les ressources de ce Cloud grâce à Internet. De plus, ces différents utilisateurs peuvent construire leurs propres Clouds privés et les administrer selon leurs propres politiques de gestion. Ainsi, la plupart des entreprises essayent de réduire leurs coûts d’exploitation et de traitement grâce à des techniques de virtualisation. Ces techniques et usages ont conduit à l’émer- gence d’un nouveau concept appelé Cloud Computing qui permet d’offrir plusieurs types de services avec une meilleure utilisation des ressources des infrastructures et une ré- duction de leurs coûts d’exploitation.

Le Cloud Computing est un terme utilisé pour décrire à la fois une plateforme et un type d’application. En tant que plateforme, le Cloud Computing fournit, configure et reconfigure les serveurs. Ces serveurs peuvent être peuvent être des machines physiques ou encore des machines virtuelles. D’autre part, le Cloud Computing permet à des applications d’être étendues pour devenir accessible à travers Internet. A cet effet, des grands centres de données et des serveurs puissants sont utilisés pour héberger ces applications qui peuvent être utilisées grâce à des services Web. Le Cloud Computing est devenu l’une des plus importantes technologies ces derniers temps et fait l’objet de plusieurs études dans différents domaines eu égard à la multiplicité des possibilités d’offre de services qu’il propose.

De plus, le système d’information a toujours été considéré comme un composant très important dans différents types d’organisations et ce du point de vue coût d’exploitation

1

2 Chapitre 1. Introduction

(OPEX : Operational Expenditure) et celui de capital (CAPEX : Capital Expenditure). Le Cloud Computing offre à ces organisations plus de flexibilité en ce qui concerne le fonc- tionnement des infrastructures et la réduction de coûts. Il est devenu une partie intégrante des modèles technologiques et commerciaux, et a forcé les entreprises à s’adapter à des nouvelles stratégies. Ainsi, la demande accrue des services du Cloud Computing est à l’origine du développement de nouvelles offres sur le marché, représentant divers modèles de service et de livraison. Cependant, le Cloud Computing reste une techno- logie relativement nouvelle. Par conséquent, la plupart des entreprises ne sont pas très confiantes lors de son adoption à cause de plusieurs défis qui restent à relever. Ainsi, il subsiste beaucoup de doutes concernant la qualité des services offerts, la sécurité des données et la gestion efficace des ressources pour les entreprises.

D’une manière générale, il y a des paramètres critiques de qualité de service (QoS : Quality of Service) à prendre en compte lors du traitement d’une demande de service par le Cloud. Par exemple, il faut garantir un temps de réponse convenable des machines virtuelles (VM) afin de satisfaire les exigences de l’utilisateur de Cloud (CSU : Cloud Service User). De plus, le délai et la gigue sont des paramètres de qualité de services très importants pour les applications interactives temps réel telles que la vidéoconfé- rence dans un environnement de Cloud Computing. Cependant, plusieurs fournisseurs de Cloud (CSP : Cloud Service Provider) proposent dans cet environnement de Cloud Computing des services similaires. Il devient alors difficile à l’utilisateur de choisir le four- nisseur qui convient le mieux à ses besoins. Ainsi, un élément de différenciation entre les différents environnements de Cloud est le niveau de service qui sera garanti par cet environnement. Ce niveau de service peut être établi entre le fournisseur et le client du Cloud par le biais d’un contrat (SLA : Service Level Agreement). Par conséquent, il faut assurer la cohérence entre les exigences de qualité de service (QoS) demandée par le CSU et les SLA proposés par les différents CSP pour permettre à plusieurs CSP sélec- tionnés de collaborer ensemble afin de répondre aux exigences du CSU. Dans le cas où toutes les ressources d’un CSP sont allouées, ce dernier ne peut pas satisfaire de nouvelles demandes des CSU. De plus, il est difficile pour un CSP d’avoir des centres de données (DC) avec une répartition géographique mondiale. Par conséquent, le Cloud de- vrait être conçu comme un environnement multifournisseur, capable d’offrir la possibilité de faire migrer un service d’un CSP à un autre et de localiser la meilleure ressource, non seulement en termes de capacité de calcul ou de stockage, mais aussi de connectivité, de bande passante et de délai d’acheminement. Ainsi, la garantie du niveau de service doit être assurée de bout en bout à travers les différents Clouds concernés par l’offre y compris les réseaux qui relient le CSU et les CSP, les CSP entre eux, ou encore les ressources dans un centre de données (DC) d’un CSP.

Les offres de service doivent être assurées dans le cadre du Cloud avec un minimum d’intervention humaine en termes d’installation, configuration, maintenance et d’une fa- çon générale en termes de fonctions de gestion. Ainsi, les pannes accidentelles causées par les défauts du logiciel, du matériel ou du réseau conduisent à des violations de SLA.

Ce dernier n’est pas respecté lorsque le CSP fournit un service qui ne permet pas de satisfaire les exigences du CSU établies dans le SLA. Par conséquent, il est nécessaire d’assurer l’auto-établissement du SLA et la gestion autonome des ressources du Cloud pour réduire les violations et les pénalités qui en résultent.

La sécurité est l’un des défis à relever les plus importants pour l’adoption du Cloud. En

effet, les données sont des éléments très précieux pour les utilisateurs et les entreprises

veulent toujours s’assurer que ces données sont sécurisées. La confiance des utilisateurs

1.2. Objectifs de la thèse 3

est naturellement plus importante lorsque les données sont traitées, stockées et contrô- lées en interne. L’externalisation du traitement ou encore du stockage de ces données dans un environnement de Cloud Computing s’accompagne d’un risque de sécurité. En effet, les données peuvent être compromises à différentes étapes de leur cycle de vie lorsqu’elles sont stockées ou traitées dans le Cloud. Les risques de sécurité peuvent apparaître lors du transfert de ces données du réseau interne de l’entreprise vers le Cloud pour y être stockées ou traitées, ou encore lors du processus de restauration des données. Ainsi, la transition vers une utilisation massive des services du Cloud s’accom- pagne de plusieurs défis de sécurité et de confidentialité, principalement en raison de la nature dynamique du Cloud et le fait que dans cet environnement les composants logi- ciels et matériels qui permettent d’offrir un service appartiennent à de multiples domaines de confiance. Par conséquent, la garantie des services de sécurité dans un environne- ment de Cloud est beaucoup plus difficile.

1.2/ O BJECTIFS DE LA THÈSE

Dans le cadre de cette thèse nous réalisons un état de l’art afin de relever les défis de recherches dans un environnement de Cloud Computing, Cloud Networking et Inter- Cloud. Cet état de l’art nous permettra de réaliser l’objectif de ce travail de recherche qui est de proposer un Framework pour la garantie de QoS de bout en bout dans un tel environnement grâce à l’établissement autonome d’un accord de niveau de service (SLA) qui répond aux exigences du CSU tout en assurant une optimisation des ressources lors de la sélection des offres de services proposées par les CSP. Ces ressources sont offertes comme un service de type IaaS (Infrastructure as a Service) ou de type NaaS (Network as a Service). De plus, nous envisageons de calculer les différents coûts relatifs à cette garantie de QoS. Ce Framework doit être par la suite géré d’une façon autonome grâce aux concepts innovants de la gestion autonome (Self-Management) qui découlent du paradigme appelé Autonomic Computing afin d’optimiser et automatiser les différentes fonctions de gestion dans un environnement de type Cloud. Ensuite, un autre défi de recherche que nous relevons dans le cadre de cette thèse est d’assurer la confiance nécessaire à la collaboration entre le CSU et les CSP et ce en améliorant le Framework qui sera proposé afin d’offrir un niveau de service intégrant une offre de sécurité grâce à des SLA comportant de nouveaux paramètres de sécurité. De plus, cette offre de sécurité sera gérée d’une façon autonome tout en étudiant l’impact de la sécurité sur la QoS dans un environnement de type Cloud.

1.3/ P LAN DE LA THÈSE

La suite de cette thèse est structurée comme suit.

Tout d’abord, le chapitre 2 présente le contexte dans lequel s’inscrivent les travaux pré-

sentés dans cette thèse. Ce contexte concerne le Cloud Computing, le Cloud Networking

et l’Inter-Cloud avec leurs définitions, leurs caractéristiques, leurs modèles de services

et de déploiement. De plus, ce chapitre aborde la standardisation, les outils d’implémen-

tation et de simulation ainsi que les produits commerciaux dans ces types d’environne-

ments.

4 Chapitre 1. Introduction

Le chapitre 3 présente l’état de l’art relatif à la QoS, la sécurité et la gestion autonome dans un environnement de Cloud Computing. Nous présentons les définitions et les ca- ractéristiques ainsi que les défis les plus importants concernant ces concepts. Ces défis de recherche font l’objet de plusieurs efforts de normalisation au sein de différentes or- ganisations de standardisation et de projets de recherches européens et internationaux.

Le chapitre 4 présente deux types d’architectures, que nous proposons pour un environ- nement de Cloud Networking, basés sur l’approche Inter-Cloud Broker et Fédération pour l’offre des services de type IaaS et NaaS avec une garantie d’un niveau de service dé- crivant la qualité de service requise par le CSU. Le CSU indique ses exigences de QoS par rapport aux services requis en utilisant une interface utilisateur graphique dédiée.

De plus, chaque type d’architecture spécifie différents types de SLA ainsi que différentes interactions nécessaires pour leurs établissements, afin d’assurer le niveau de service demandé par le CSU.

Le chapitre 5 présente la méthodologie d’optimisation lors de la sélection des CSP offrant les meilleures ressources avec une garantie de QoS de bout en bout afin de répondre aux exigences du CSU. Ainsi, nous proposons des algorithmes en tant que solution pour l’optimisation de cette sélection. Ces algorithmes sont relatifs à l’offre du service NaaS, NaaS avec IaaS, IaaS de type VM, et IaaS de type stockage. De plus, nous spécifions les équations nécessaires pour calculer les différents coûts relatifs à cette garantie de QoS. Nous définissons dans ce chapitre l’environnement de simulation pour la valida- tion de cette proposition de garantie de QoS pour deux types d’applications, à savoir la vidéoconférence et les calculs intensifs.

Le chapitre 6 présente notre architecture pour l’établissement autonome des SLA pro- posés ainsi que la gestion autonome des ressources correspondantes en utilisant des gestionnaires autonomes spécifiques de Cloud. Ainsi, nous décrivons les différents auto- mates finis et algorithmes proposés pour l’établissement autonome de ces SLA et pour la gestion autonome de ces ressources pour garantir un niveau de service de bout en bout dans une architecture de type Broker et Fédération. De plus, nous spécifions les équations permettant la détection et le calcul des violations, des pénalités, et des répu- tations des différents CSP. Enfin, nous présentons l’environnement de simulation pour la validation de cette proposition de gestion autonome des SLA et des ressources du Cloud grâce à des scénarios de déploiement de deux types d’applications, à savoir la vidéoconférence et les calculs intensifs.

Le chapitre 7 présente une amélioration de nos architectures de Cloud Networking pour offrir un niveau de service intégrant une offre de sécurité grâce à des SLA comportant des paramètres de sécurité. Ainsi, nous présentons une architecture pour la distribution des certificats aux différentes entités de notre environnement de Cloud Networking afin de permettre aux gestionnaires autonomes d’étendre leurs fonctions de gestion aux aspects liés à la sécurité (Auto-protection) tout en étudiant l’impact de la sécurité sur la QoS. Dans ce contexte, nous spécifions l’environnement de simulation pour la validation de cette proposition d’extension du niveau de service à la sécurité tout en étudiant son impact sur la QoS grâce à un scénario de déploiement d’une application de vidéoconférence.

Enfin, le chapitre 8 conclut cette thèse et présente les perspectives des travaux de re-

cherches réalisés.

C HAPITRE 2 C LOUD C OMPUTING , C LOUD

N ETWORKING ET I NTER -C LOUD

2.1/ I NTRODUCTION

Au cours des dix dernières années, Internet s’est développé très rapidement. Les pe- tites entreprises qui possèdent des ressources limitées ont besoin d’investir à grande échelle avec un budget convenable. Par contre, mettre en place une infrastructure tradi- tionnelle est un processus long et coûteux qui nécessite un investissement initial consé- quent, beaucoup de temps, et des personnes qualifiées pour mettre cette infrastructure en place et la gérer au quotidien. De plus, quand un problème se pose pour les services et les applications, ces entreprises ont besoin de beaucoup de temps et un coût élevé pour le régler. Ainsi, les entreprises qui possèdent leurs infrastructures doivent trouver continuellement les solutions adéquates face à ces problèmes. La question qui s’est alors posée : pourquoi mettre en place une infrastructure complète si nous pouvons louer des ressources à la place ? Cette réflexion a favorisé l’apparition du Cloud Computing.

Bien que dans sa forme actuelle, le Cloud Computing (ou simplement le Cloud) est un phénomène relativement récent, nous sommes probablement dans un monde où nous utilisons le Cloud sans s’en rendre compte. Si nous utilisons par exemple un fournis- seur de messagerie Web comme «Gmail» ou «Hotmail», des appels vidéo avec «Skype»

ou des interfaces vidéo comme «Vimeo» ou «YouTube», et si nous sauvegardons des données sur Internet plutôt que sur un appareil externe, alors nous utilisons le Cloud.

Aujourd’hui, le Cloud est présent partout avec un intérêt croissant grâce à une offre de ressources à la demande.

Dans ce chapitre, nous présentons une description générale du Cloud Computing, du Cloud Networking et de l’Inter-Cloud, avec leurs définitions, leurs caractéristiques, leurs modèles de services et de déploiements. De plus, nous décrivons les propositions re- latives à ces concepts émanant des organismes de standardisation ainsi que les outils d’implémentation et de simulation et les produits commerciaux utilisés dans ces environ- nements.

2.2/ C LOUD C OMPUTING 2.2.1/ H ^ISTORIQUE

Il n’y a pas de date à laquelle nous puissions dire que le Cloud est né. Le concept du Cloud remonte aux années 1950, quand les ordinateurs centraux à grande échelle sont

5

6 Chapitre 2. Cloud Computing, Cloud Networking et Inter-Cloud

devenus disponibles dans les universités et les entreprises, et accessibles via des termi- naux clients et/ou des ordinateurs [1]. John McCarthy a estimé dans les années 1960 que

«le calcul peut un jour être organisé comme un service d’utilité public» [2]. De plus, les ca- ractéristiques d’utilisation des secteurs publics et privés comme le secteur de l’électricité, le gouvernement et les formes communautaires, explorées dans le livre de Douglas Par- khill en 1966 [2] présentent beaucoup de similitudes avec les caractéristiques modernes du Cloud.

Depuis les années 70, la notion de «service bureau» est inventée pour qualifier une entreprise louant des lignes téléphoniques, répondeurs, services informatiques etc. Gé- néralement, les clients des services bureau n’ont ni la capacité ni l’expertise pour intégrer en interne ces services, c’est pourquoi ils passent par un fournisseur. Les «Application Service Providers (ASP)» ont aussi leur part dans l’historique du Cloud. Une entité de type ASP propose une application fournie comme un service, c’est ce que nous dési- gnons maintenant SaaS pour «Software as a Service» dans la terminologie actuelle du Cloud [3]. Ensuite, le terme Cloud a été déjà utilisé en 1990 pour faire référence aux grands réseaux ATM (Asynchronous Transfer Mode) qui s’appuient sur la notion de cir- cuit virtuel et englobent des logiciels, des matériels et des médias de connexion, tout en supportant plusieurs niveaux de qualité de service.

Au 21e siècle, le terme de l’informatique en nuage «Cloud Computing» a commencé à apparaître. En 2002, Amazon, le leader du e-business inventa le concept de Cloud. En effet, ils investirent dans un groupement de machines immenses, dimensionnées pour absorber les charges importantes des commandes faites sur leur site au moment des fêtes de Noël, mais plutôt inutilisées le reste de l’année. Leur idée a donc été d’ouvrir toutes ces ressources inutilisées aux entreprises, pour qu’elles les louent à la demande.

Après, de nombreuses entreprises entrent sur le marché du Cloud telles que IBM, Mi- crosoft ou encore Google. L’année 2007 a vu une augmentation des activités avec ces entreprises (Google, IBM, etc). Ensuite, un certain nombre d’universités s’engageant à grande échelle sur des projets de recherche portant sur le Cloud, et avec le temps, le terme a commencé à gagner en popularité dans la presse [2].

2.2.2/ D ÉFINITION

La notion de Cloud fait référence à un nuage, tel que nous avons l’habitude de l’utili- ser dans des schémas techniques lorsque nous voulons représenter Internet. Un réseau comme Internet est constitué d’une multitude de systèmes fournissant des services. Le Cloud Computing est dans cette lignée : un ensemble de services et de données consom- mables fournis aux utilisateurs [3].

Pour une majorité d’utilisateurs, le Cloud est un nouveau modèle informatique avec une source d’économies. Il permet de répondre facilement aux besoins de développement et permet de se détacher des problèmes de gestion informatique. En effet, les utilisa- teurs appelés «Cloud Service Users (CSU)» ne sont pas généralement propriétaires de l’infrastructure informatique, mais ils possèdent la possibilité d’accéder ou d’allouer des services informatique du Cloud. Ces services sont fournis par des fournisseurs de ser- vices Cloud appelés «Cloud Service Providers (CSP)».

Dans l’industrie et le secteur académique, il existe de nombreuses définitions pour le

Cloud. Vaquero et al. [4] listent 22 définitions du Cloud. Nous avons choisi la définition

fournie par le «National Institute of Standards and Technology (NIST)» [5] couvrant tous

2.2. Cloud Computing 7

les aspects essentiels du Cloud : «Le Cloud Computing est un modèle informatique pra- tique pour établir un accès facile et à la demande, par le réseau, à un réservoir partagé de ressources informatiques configurables (réseau, serveurs, espaces de stockage, applica- tions et services) qui peuvent être rapidement provisionnées et libérées avec un minimum d’efforts de gestion ou d’interaction avec le fournisseur du service».

2.2.3/ C ARACTÉRISTIQUES

Le Cloud possède plusieurs caractéristiques intéressantes qui le rendent attirant pour les CSU et les CSP. Vaquero et al. [4], Buyya et al. [6] et Gong et al. [7] donnent une analyse complète des caractéristiques du Cloud. Nous présentons dans cette section les caractéristiques du Cloud les plus importantes :

— Facilité d’accès : les services hébergés dans le Cloud sont généralement basés sur le Web. Par conséquent, ils sont facilement accessibles grâce à une variété d’appareils connectés à Internet. En outre, pour atteindre une performance éle- vée en termes d’accessibilité, beaucoup de Clouds sont composés de centres de données «Data Center (DC)» situés à plusieurs endroits à travers le monde.

— Faible investissement initial et tarification avantageuse : le Cloud utilise un modèle de paiement de type «payez ce que vous utilisez» (voir figure 1). Les CSU sont facturés en se basant sur l’utilisation plutôt que sur un taux forfaitaire, cela permet des économies considérables pour ces derniers. D’autre part, un CSP n’a pas besoin d’un investissement trop important dans les infrastructures pour offrir ces services et commencer à faire des profits. Il loue simplement des ressources du Cloud en fonction des besoins de l’utilisateur.

F IGURE 1 – Différence entre le modèle de paiement classique et celui du Cloud.

— Groupement des ressources partagées et affectation dynamique et à la demande : le CSP dispose d’un groupement de ressources informatiques qui peuvent être attribuées dynamiquement aux consommateurs de ressources (CSU). Une telle capacité d’affectation dynamique des ressources permet beau- coup de flexibilité aux CSP pour la gestion de leur propre utilisation des ressources et les coûts d’exploitation [5].

— Auto-organisation et mise à l’échelle : les ressources dans un environnement

de Cloud peuvent être rapidement allouées et désallouées à la demande. Dans

certain cas, elles doivent être faites automatiquement. Pour le CSU, les capacités

doivent être disponibles et affectées à n’importe quel moment et avec n’importe

quelle quantité [5]. Un CSP peut facilement étendre son service à grande échelle

afin de gérer l’augmentation rapide de la demande de services.

8 Chapitre 2. Cloud Computing, Cloud Networking et Inter-Cloud

— Réduction des risques d’affaires et des charges de la maintenance : en exter- nalisant l’infrastructure des services vers les Clouds, le CSU déplace les risques d’affaires (tels que les pannes matérielles, etc.) et les charges de la maintenance vers les CSP, qui ont souvent une meilleure expertise et sont mieux équipés pour gérer ces risques.

— Service mesuré : le Cloud contrôle automatiquement et optimise l’utilisation des ressources grâce à une capacité de mesure avec un certain niveau d’abstraction approprié pour les types de service (par exemple, le stockage, le traitement, la bande passante, les comptes d’utilisateurs actifs, etc.). L’utilisation des ressources peut être quantifiée au moyen de mesures appropriées (les heures pour le CPU, la bande passante, etc.), surveillée, contrôlée et rapportée, en assurant la trans- parence pour le CSP et le CSU [5].

— Ressources virtualisées : la virtualisation est une technologie qui fait une abs- traction des matériels physiques et fournit des ressources virtualisées pour les applications de haut niveau. Un serveur virtualisé est communément appelé une machine virtuelle (VM : Virtual Machine) et nous pouvons mettre plusieurs VM sur le même serveur physique. La virtualisation constitue la base du Cloud Compu- ting, car elle offre la possibilité de mettre en commun les ressources informatiques de groupes de serveurs et d’affecter dynamiquement des ressources virtuelles à la demande aux applications. Nous pouvons virtualiser de nombreuses ressources telles que les ressources informatiques, les logiciels, les matériels, les systèmes d’exploitation et les espaces de stockage. De plus, nous pouvons gérer ces res- sources virtualisées d’une manière isolée de l’infrastructure physique.

2.2.4/ M ODÈLES DE SERVICES

Le but principal du Cloud est d’offrir des services à des utilisateurs suivant différents modèles. Nous présentons dans cette section les modèles de services principaux du Cloud.

2.2.4.1/ S OFTWARE AS A SERVICE (S AA S)

Le modèle de services «logiciel en tant que service» (SaaS) permet de fournir des ap- plications à la demande sur Internet. Ces services du Cloud sont fournis à des millions d’utilisateurs et sont accessibles à partir de différents dispositifs clients, par exemple un navigateur Web. Ceci permet de réduire un certain coût relatif aux logiciels et aux ser- veurs. Le CSU n’a pas à se soucier d’effectuer des mises à jour, et il ne gère ni contrôle l’infrastructure Cloud sous-jacente, y compris le réseau, les serveurs, les systèmes d’ex- ploitation, le stockage, à l’exception possible des paramètres relatifs à la configuration de l’application. Gmail est un exemple de service de type SaaS qui offre au CSU un ser- vice de courrier électronique. D’autres exemples d’outils et de produits commerciaux qui fournissent des services du modèle SaaS seront présentés dans la section 2.2.8.

2.2.4.2/ P LATFORM AS A S ERVICE (P AA S)

Le modèle de services «plateforme en tant que service» (PaaS) est situé juste au-

dessous du précédent (SaaS), puisqu’il permet de fournir aux développeurs (CSU) des

2.2. Cloud Computing 9

ressources pour les environnements d’exécution, les cadres de développement de logi- ciels et le soutien du système d’exploitation. Les développeurs (y compris les CSP de service SaaS) ont plusieurs avantages de développer leur application dans les Clouds en tant qu’environnement de programmation. Cet environnement permettra une mise à l’échelle automatique et l’équilibrage de charge, ainsi que l’intégration avec d’autres ser- vices (services d’authentification, services de courrier électronique, interface utilisateur, etc.). Le modèle de service PaaS offre aux développeurs un service qui fournit une ges- tion du cycle de vie complet du développement logiciel, depuis la planification jusqu’à la maintenance [8]. L’infrastructure informatique sous-jacente est abstraite du point de vue des développeurs, c.à.d. le développeur peut exploiter ce modèle de service pour construire ses applications sans avoir la moindre idée de ce qui se passe dans l’infra- structure sous-jacente à ce service. Le coût et la complexité du développement et de déploiement d’applications peuvent être largement réduits lorsque les développeurs uti- lisent ce service de Cloud. Heroku [9] est un service de Cloud de type PaaS créé en 2007 : il s’agit de l’un des tout premiers services Cloud de ce type. D’autres exemples d’outils et produits commerciaux qui fournissent des services du modèle PaaS seront présentés dans la section 2.2.8.

2.2.4.3/ I NFRASTRUCTURE AS A S ERVICE (I AA S)

Le modèle de services «Infrastructure en tant que service» (IaaS) est situé juste au- dessous du précédent (PaaS), puisqu’il permet de créer un pool de ressources virtuelles en divisant les ressources physiques à l’aide des technologies de virtualisation. Ces res- sources virtuelles d’infrastructure seront fournies à la demande, le plus souvent en termes de machines virtuelles, d’espaces de stockage et de ressources réseau. Les machines virtuelles sont utilisées pour la fourniture de ressources CPU pour les CSU (y compris les CSP de service PaaS ou SaaS). Le CSP d’IaaS contrôle l’initiation des VM selon la demande du CSU en lui donnant le contrôle total sur ses VM et il contrôle l’élimination des VM si le CSU n’en a plus besoin. De plus, les espaces de stockage de données permettent aux utilisateurs de stocker leurs données dans des disques distants et d’y accéder à tout moment à partir de n’importe quel endroit. Ce service est connu sous le nom de stockage de données en tant que service (DaaS : Data storage as a Service).

VMware [10] offre un service de Cloud de type IaaS. D’autres exemples d’outils et pro- duits commerciaux qui fournissent des services du modèle IaaS seront présentés dans la section 2.2.8.

2.2.4.4/ N ETWORK AS A S ERVICE (N AA S)

Le modèle de services «réseau en tant que service» (NaaS) permet d’offrir l’ensemble

des ressources réseaux en tant que service. Il existe deux types de service réseau dans

le cadre de ce modèle. Le premier type est formé du réseau qui relie le CSU avec le

CSP ou bien les CSP entre eux. Le deuxième type de réseau est celui du centre de

données du CSP qui relie les différentes VM et les espaces de stockage. De plus, le

service de type NaaS permet aux CSU de personnaliser les services qu’ils reçoivent

à partir du réseau, c.à.d. de contrôler l’exploitation du réseau facilement et de manière

efficace, tout en permettant au CSP de décider comment les ressources sont allouées et

partagés entre les CSU [11]. Le service NaaS est offert dans un environnement de Cloud

Networking (voir Section 2.3).

10 Chapitre 2. Cloud Computing, Cloud Networking et Inter-Cloud

Les CSP peuvent encore optimiser leurs coûts en utilisant les services d’autres types de Cloud. D’une part, certains CSP de SaaS font appel à d’autres CSP de PaaS et IaaS.

Ainsi, ils n’ont besoin de maintenir que l’application, et ils seront alors des CSU pour des services PaaS et IaaS. D’autre part, certains CSP offrent du PaaS et par la suite ils font appel à d’autres CSP d’IaaS, et ils seront alors des CSU pour des services IaaS.

2.2.5/ M ODÈLES DE DÉPLOIEMENT

Il existe différents modèles de déploiement du Cloud, chacun avec ses avantages et ses inconvénients.

2.2.5.1/ C LOUD PUBLIC

Dans un Cloud public les CSP offrent leurs ressources comme services au grand pu- blic. Ce modèle peut être détenu, géré et exploité par une entreprise ou une organisa- tion académique ou gouvernementale, ou une combinaison entre eux. Le Cloud public offre plusieurs avantages aux utilisateurs, y compris l’absence de coûts d’investissement élevés sur les infrastructures et le déplacement des risques vers les fournisseurs d’infra- structure. Mais, ces utilisateurs n’ont pas un contrôle fin sur les données, le réseau et les paramètres de sécurité, ce qui entrave l’efficacité de ce modèle de déploiement.

2.2.5.2/ C LOUD PRIVÉ

Le Cloud privé est conçu pour une utilisation exclusive par une seule organisation. Un Cloud privé peut être construit et géré par l’organisation, une tierce partie, ou une com- binaison des deux. Il offre le plus haut degré de contrôle sur les performances, la fiabilité et la sécurité. Cependant, il est souvent critiqué car il est similaire aux serveurs proprié- taires traditionnels qui ne fournissent pas les avantages du Cloud comme l’absence de coûts d’investissement élevés.

2.2.5.3/ C LOUD COMMUNAUTÉ

C’est un Cloud qui partage des infrastructures entre plusieurs organismes d’une commu-

nauté spécifique avec des préoccupations communes (la mission, les exigences de sé-

curité, la politique, etc.). Ces infrastructures sont gérées par un ou plusieurs organismes

de la communauté, une tierce partie, ou une combinaison de ces entités. Ce modèle de

déploiement offre les avantages d’un Cloud public comme la structure de facturation de

type «payez ce que vous utilisez», mais aussi les avantages d’un Cloud privé en termes

de confidentialité et de sécurité d’une façon générale. Les coûts sont répartis sur moins

d’utilisateurs qu’un Cloud public (mais plus qu’un Cloud privé), de sorte qu’une partie des

économies potentielles de Cloud sont réalisées.

2.2. Cloud Computing 11

2.2.5.4/ C LOUD HYBRIDE

Un Cloud hybride est une combinaison de déploiement des modèles de Cloud (public, privé et communauté) qui tente de remédier aux limitations de chaque approche. Dans un Cloud hybride, une partie du service de l’infrastructure s’exécute dans des Clouds privés tandis que la partie restante est dans des Clouds publics. Un Cloud hybride offre plus de flexibilité qu’un Cloud public ou privé, puisqu’il fournit un meilleur contrôle et une meilleure sécurité pour les données d’application des utilisateurs par rapport aux Clouds publics et une tarification avantageuse par rapport aux Clouds privés. Cependant, la conception d’un Cloud hybride nécessite une étude détaillée afin de déterminer la meilleure répartition entre les composantes de Cloud public et privé.

Pour la plupart des organisations, le choix du modèle de Cloud dépend du cas d’utilisation et des exigences du CSU (sécurité, QoS, etc.).

2.2.6/ S TANDARDISATION

Le Cloud implique un large éventail d’éléments techniques et commerciaux différents, et les infrastructures du Cloud ont commencé par des solutions propriétaires comme Ama- zon, Microsoft ou Google, etc. D’où le besoin de la standardisation pour définir la termi- nologie et les techniques à utiliser et aussi pour assurer l’émergence d’une infrastructure Cloud standard, interopérable et adoptée par la majorité des acteurs du marché.

De nombreuses organisations et des groupes informels travaillant sur les technologies du Cloud se sont spécialisés dans le traitement des problèmes de standardisation en ce qui concerne l’environnement de Cloud. Ces organisations de standardisation aident à main- tenir les normes et les meilleures pratiques pour veiller à ce que les différents CSP et les équipements soient capables de coexister ensemble d’une manière interopérable. Nous présentons dans cette section des différents acteurs dans le domaine de standardisation du Cloud.

La figure 2 [12] montre une classification générale des différentes organisations de stan- dardisations selon leurs rôles dans un environnement de Cloud. Par exemple, l’organi- sation «Distributed Management Task Force (DMTF)» [13] contient différents groupes de travail sur le Cloud. Nous pouvons citer à ce titre le groupe de travail «Open Virtualization Format (OVF)» qui travaille sur un format standard de la machine virtuelle, mais aussi

«Open Cloud Standards Incubator (OCSI)» qui a été établi en Avril 2009 pour étudier les standards qui permettront l’interopérabilité entre les systèmes de Clouds. De plus,

«Cloud Management Working Group (CMWG)» a été créé en Juin 2010 pour travailler sur les politiques, le SLA, la QoS, l’approvisionnement et la surveillance dans le Cloud.

Le groupe de travail «Virtualization Management Initiative (VMAN)» fournit des standards d’interopérabilité et de portabilité, et enfin le groupe «Cloud Infrastructure Management Interface (CIMI)» vise la gestion des ressources au sein du domaine IaaS.

D’autre part, «IEEE Cloud Computing» [14] est une organisation de standardisation qui

contient deux groupes de travail sur le Cloud, «Cloud Computing Standards Study Group

(CCSSG)» et «Inter-Cloud Working Group (ICWG)». Cette organisation a annoncé en

Avril 2011 le lancement de deux nouveaux projets d’élaboration de normes : P2301 [15],

Guide pour la portabilité Cloud et profils d’interopérabilité (CPIP) et P2302 [16], standard

pour l’interopérabilité et la Fédération Inter-Cloud (SIIF). De plus, «International Telecom-

munication Union - Telecommunication Standardization Sector (ITU-T)» [17] est une autre

12 Chapitre 2. Cloud Computing, Cloud Networking et Inter-Cloud

F IGURE 2 – Exemple d’organisations de standardisation du Cloud [12].

organisation de standardisation qui a terminé son étude préliminaire sur l’écosystème de standardisation de Cloud (Architecture de référence) et a sorti son rapport technique composé de 7 parties. Les travaux de standardisation de Cloud se déroulent sous la direction du Groupe d’étude 13 (Future Networks).

Un autre acteur dans la standardisation des environnements Cloud est le «National Ins- titute of Standards and Technology (NIST)» [5]. Il s’agit d’une organisation qui comporte plusieurs groupes de travail ayant pour objectif de fournir une stratégie basée sur les stan- dards pour guider les efforts de mise en œuvre des clouds tout en proposant une archi- tecture de référence pour l’environnement Cloud (Cloud Computing Target Business Use Cases Working Group, Cloud Computing Reference Architecture and Taxonomy Working Group, Cloud Computing Standards Roadmap Working Group, Cloud Computing SA- JACC Working Group, et Cloud Computing Security Working Group). Nous retrouvons aussi une organisation japonaise, «Global Inter-Cloud Technology Forum (GICTF)» [18], qui étudie les interfaces standards d’Inter-Cloud afin d’améliorer la fiabilité des Clouds.

De son côté, «Internet Engineering Task Force (IETF)» [19] a publié des rapports (de type draft) sur le Cloud et le réseau du DC. «European Telecommunications Standards Institute (ETSI)» [20] a fait une description des tests d’interopérabilité, une étude sur le SLA, et une analyse initiale des exigences de standardisation pour les services Cloud.

«Open Grid Forum (OGF)» [21] a créé un groupe de travail appelé «Open Cloud Compu- ting Interface (OCCI) WG» en Avril 2009 qui a défini une spécification «Application Pro- gramming Interface (API) OCCI», pour la gestion du cycle de vie des VM. «Open Cloud Consortium (OCC)» [22] est une organisation créée en Janvier 2009 qui a pour objectif de réaliser l’interopérabilité entre les systèmes de Cloud. D’autres organisations comme

«Object Management Group (OMG)» [23], «Cloud Security Alliance (CSA)» [24], «Cloud

2.2. Cloud Computing 13

Computing Interoperability Forum (CCIF)» [25], et «ISO/IEC JTC1» [26] contribuent aux efforts de standardisation dans le domaine du Cloud.

Les normes qui régissent le Cloud sont tout simplement en train de naître et cela peut prendre du temps pour se développer. De plus, les différentes organisations que nous venons de décrire ne cherchent pas à collaborer ensemble pour remédier aux problèmes posés par la normalisation. Ainsi, l’absence de standards ou encore la lenteur dans le processus de normalisation risquent de retarder l’entrée de certaines entreprises dans un environnement de type Cloud. Une coordination entre les différents acteurs du domaine permettrait aux différents CSP de proposer des offres standardisées avec une garantie d’interopérabilité des services émanant de différents fournisseurs de Cloud.

2.2.7/ O UTILS D ’ IMPLÉMENTATION ET DE SIMULATION

Nom Modèle de

service

Modèle de déploie- ment

Open source

But

OpenNebula [27]

IaaS Cloud privé Oui Construction et gestion de fa- çon centralisée d’une infrastruc- ture IaaS virtuelle hétérogène.

Nimbus [28]

IaaS Cloud

public

Oui Installation sur une grappe de ser- veurs et fourniture d’un service IaaS à son CSU.

Eucalyptus [29]

IaaS Cloud pu-

blic, privé ou hybride

Oui Installation, déploiement et ges- tion de grappe de serveurs comme un seul Cloud.

OpenStack [30]

PaaS, IaaS, NaaS

Cloud pu- blic, privé ou hybride

Oui Déploiement des infrastructures de Cloud et contrôle des diffé- rentes ressources de machines virtuelles, de stockage ou encore de réseau.

CloudStack [31]

IaaS, NaaS Cloud pu- blic, privé ou hybride

Oui Déploiement et gestion avec une interface Web de grands réseaux de machines virtuelles.

Snooze [32]

IaaS Cloud pu-

blic ou

privé

Oui Construction des infrastructures de ressources de calcul virtuali- sées, et gestion des machines vir- tuelles.

T ABLE 1 – Exemples de plateformes d’implémentation du Cloud.

Dans le monde du Cloud, la plupart des outils d’implémentation et de simulation sont axés

sur des expériences et une modélisation simplifiée du Cloud. Ces outils ouvrent la pos-

sibilité d’évaluer les hypothèses dans un environnement contrôlé où l’on peut facilement

reproduire des résultats. De plus, ils permettent de tester les services Cloud dans un

environnement répétitif et contrôlable. Ils peuvent permettre d’adapter le système avant

de le déployer sur un vrai Cloud et de l’expérimenter avec différentes charges de travail

et scénarios de performances.