Cloud computing
La notion de Cloud fait référence à l’allégorie classique d’Internet ,souvent représenté sous forme de nuage.
La métaphore du nuage désigne en réalité un réseau de ressources informatiques (i.e. matérielles et logicielles) virtualisées et mutualisées, accessibles à distance, à la demande et en libre-service via le réseau par le biais des technologies Internet [AFG+10] [ZCB10] [BYV+09] [VRMCL08]. L’informatique en nuage, ou Cloud computing, constitue une nouvelle façon de délivrer les ressources informatiques. On parle aussi d’informatique virtuelle ou encore d’informatique dématérialisée. Il s’agit d’accéder à des ressources informatiques, reposant sur une architecture distante gérée par une tierce partie : le fournisseur de service (i.e. service provider). Celui-ci assure la continuité et la maintenance du service dont il a la charge. Les utilisateurs accèdent à la partie applicative via leur connexion Internet sans se soucier du reste. Les utilisateurs peuvent ainsi louer (i.e. paiement à l’utilisation, pay-per-use) les technologies de l’information et bénéficier d’une flexibilité importante avec un effort minimal de gestion.
Accord de niveau de service- SLA
Qualité de service : La qualité de service (Quality of Service- QoS) est la capacité d’un service à répondre aux besoins des utilisateurs en respectant leurs exigences. Dans le contexte du Cloud, les critères considérés diffèrent selon les modèles de service [ADC10] et les services proposés. Néanmoins, on retrouve deux métriques récurrentes [PSG06] : la disponibilité (availability) et le temps de réponse (response time ou latency). Les principales composantes de la QoS sont fournies par des métriques caractérisées par un type, une unité et une fonction de calcul. Service Level Agreement : Le concept de Service Level Agreement (SLA) a été introduit dans les années 80 par les opérateurs téléphoniques afin de gérer la QoS dans leurs contrats avec les entreprises [WB12].
Un SLA, que l’on peut traduire en français par « accord de niveau de service », est un contrat dans lequel la QoS est formalisée et contractualisée entre le prestataire de service et le(s) utilisateur(s). De nombreuses définitions du terme SLA ont été proposées par la communauté scientifique et industrielle. Celles-ci diffèrent généralement du fait qu’elles adressent des domaines distincts.
Élasticité du Cloud
Environnement dynamique : L’élasticité est une caractéristique cruciale pour les fournisseurs SaaS dont les applications évoluent dans des environnements hautement variables. Il s’agit de répondre aux demandes des utilisateurs en temps normal mais aussi dans les périodes de forte activité avec une réactivité maximale. Les systèmes doivent être capables de supporter une montée en charge puis un retour à la normale, sans interruption de service, et si possible, sans répercussions sur le niveau de service, c’est-à-dire dans le respect des SLAs signés. Il existe d’autres événements imprédictibles bien que récurrents : pannes logicielles, matérielles, coupures de courant, etc. L’élasticité doit là aussi permettre d’amortir ces événements sans impacter le service rendu à l’utilisateur. Du point de vue du fournisseur, l’élasticité est un des rouages nécessaires à l’optimisation des ressources, tout en délivrant aux utilisateurs le niveau de service souhaité, dans un contexte d’exécution de plus en plus dynamique.
Passage à l’échelle : L’élasticité, présentée comme l’une des caractéristiques essentielles du Cloud computing [MG11], peut être corrélée à la notion de « passage à l’échelle » ou « scalabilité (scalability). On parle aussi de « capacité à monter en charge » ou d’ »extensibilité » pour définir la capacité d’un système à s’adapter aux dimensions du problème qu’il a à traiter. Dans le contexte du Cloud computing, la scalabilité correspond à l’aptitude d’une application à répondre à la montée en charge en ajoutant/retirant des ressources afin de maintenir un certain niveau de performance et de QoS. Concrètement, cela signifie que la puissance de calcul, la mémoire ou le stockage utilisés par le système peuvent facilement être augmentés ou diminués en fonction des besoins. Dans leur article, les auteurs de [WHGK14] insistent sur la différence entre le concept de scalabilité et d’élasticité. Comme nous allons le voir par la suite, l’extensibilité est une condition nécessaire à l’informatique élastique mais le terme ne renvoie pas au caractère temporaire de cette augmentation de capacité. Ainsi, l’élasticité inclut la scalabilité, mais une application dite « scalable » n’est pas nécessairement une application élastique.
Gestion de capacité et dimensionnement des ressources
Le dimensionnement désigne le fait de déterminer la quantité de ressources nécessaire pour un système. L’objectif est d’agir sur les ressources du système pour contrôler sa capacité de traitement et indirectement ses performances et sa QoS. Dans l’idéal, le processus de dimensionnement doit être automatisé, on parle alors de dimensionnement automatique (autoscaling). Le dimensionnement automatique peut être qualifié d’implémentation du concept d’élasticité du Cloud computing.
Différentes approches : On distingue trois manières de mettre en œuvre le dimensionnement automatique: Dimensionnement Réactif : dimensionnement automatique basé sur la demande et plus généralement sur l’état courant du système. Un dimensionnement dit réactif réagit aux changements mais ne les prévoit pas. En s’appuyant sur un service de surveillance (moni toring), chargé de mesurer l’utilisation des ressources ou encore la demande courante, le système peut indiquer des situations nécessitant d’augmenter ou de réduire la quantité de ressources.
Dimensionnement Pro-actif (Prédictif) : le dimensionnement pro-actif vise à prévoir les besoins futurs en terme de ressources. Contrairement à l’approche réactive s’intéressant à l’état courant du système, on s’intéresse ici à son état futur. On parle aussi de dimensionnement prédictif pour qualifier le fait d’anticiper la demande en vue de fournir les ressources suffisantes à l’avance. Dimensionnement Hybride : combinaison d’un dimensionnement réactif et pro-actif. Ce type d’approche considère l’état courant et futur du système. Il s’agit d’être à la fois réactif aux changements mais aussi de prévoir à l’avance les besoins du système en termes de ressources ou encore d’anticiper les performances futures.
Informatique autonomique
Afin de faire face à l’environnement hautement dynamique induit par le Cloud (i.e. charge de travail variable, pannes, etc.), il devient indispensable de s’appuyer sur des modèles qui permettent de réagir au contexte d’exécution afin de garantir la performance et la fiabilité du Cloud. De plus, la complexité croissante des systèmes informatiques rend la tâche d’administration impossible pour un être humain. Il devient donc nécessaire de rendre les systèmes informatiques capables de se gérer de façon autonome.
L’informatique autonomique a été introduite en 2001 par IBM [Hor01] comme réponse à la difficulté d’administration des systèmes informatiques. En effet, la complexité croissante des systèmes informatiques (i.e. en termes d’envergure, d’architecture, de technologies, etc.) ainsi que le contexte hautement dynamique dans lequel ils évoluent (i.e. sollicitations variables, pannes logicielles/matérielles, etc.) a rendu la tâche d’administration ardue voir même impossible pour l’Homme. L’objectif principal de l’informatique autonome est de soulager l’opérateur humain en charge de la gestion du système, en l’assistant dans les tâches d’administration. Dans [Hor01], Paul Horn définit les 7 commandements indispensables pour un système informatique autonomique : Apprendre à se connaître lui-même; Détecter les pannes et les éviter; Réparer les pannes et les erreurs commises; Garder la maîtrise des données; S’optimiser en s’auto-éduquant; Comprendre les intentions des humains; Exister et évoluer dans un environnement ouvert et hétérogène.
L’Informatique autonomique a ensuite été définie en 2003 par Jeffrey O. Kephart dans un article fondateur du domaine : A vision for autonomic computing. Dans cet ouvrage, [KC03] dresse un parallèle entre le fonctionnement du système nerveux humain et les systèmes du domaine informatique. Ainsi, un système informatique autonome pourrait se comporter comme le corps humain qui intègre des propriétés autonomiques lui permettant par exemple de réguler le rythme cardiaque en fonction de l’effort qu’il fournit.
Table des matières
1 Introduction
1.1 Contexte et problématique
1.2 Objectif de la thèse
1.3 Contributions
1.4 Plan de thèse
1.5 Diffusion scientifique
I État de l’art
2 Contexte et concepts
2.1 Cloud computing
2.1.1 Définitions
2.1.2 Virtualisation
2.1.3 Modèle économique
2.1.4 Accord de niveau de service-SLA
2.1.5 Enjeux énergétiques
2.2 Élasticité du Cloud
2.2.1 Définitions
2.2.2 Motivations de l’élasticité
2.2.3 Élasticité, la pratique
2.3 Gestion de capacité et dimensionnement des ressources
2.3.1 Différentes approches
2.3.2 Théories et techniques employées :monde scientifique
2.3.3 Règles à base de seuil :monde industriel
2.4 Informatique autonomique
2.4.1 Définitions, motivations et propriétés
2.4.2 Boucle de contrôle autonomique
2.5 Conclusion
3 État de l’art scientifique
3.1 Positionnement des travaux
3.1.1 Problématique
3.1.2 Critères des élection et de classification des travaux
3.2 Élasticité de l’infrastructure
3.2.1 Solutions pro-actives
3.2.2 Solutions réactives
3.2.3 Solutions hybrides
3.3 Élasticité étendue aux autres couches
3.3.1 Adaptation du logiciel
3.3.2 Adaptation multi-couche du Nuage
3.4 Administration de l’élasticité
3.4.1 Compromis induits par l’élasticité
3.4.2 Configuration de l’élasticité
3.4.3 Place de l’administrateur
3.4.4 Langages pour la gestion de l’élasticité
3.5 Conclusion
II Contributions
4 Élasticité multi-couche : motivation par l’exemple
4.1 TUBA : une preuve de concept menée à l’entreprise
4.1.1 Objectif initial
4.1.2 Scénario de motivation concret
4.1.3 Prototypage d’une application élastique
4.1.4 Impact de l’élasticité logicielle
4.1.5 Démonstrateur TUBA
4.2 SCUBA : vers une gestion de l’élasticité multi-couche
4.2.1 Architecture du framework
4.2.2 Expérimentations et validation
4.3 Bilan
4.3.1 Réactivité de l’adaptation
4.3.2 Granularité et précision de l’adaptation
4.3.3 Extension de la capacité du système
4.3.4 Frugalité du passage à l’échelle
4.3.5 Synergie entre l’élasticité des ressources IaaS et SaaS
4.3.6 Pour aller plus loin
5 Modèle d’élasticité multi-couche
5.1 Étendre l’élasticité à la couche SaaS
5.1.1 Élasticité logicielle :définitions et concepts
5.1.2 Nouvelles dimensions d’élasticité et actions associées
5.1.3 Critères d’adaptation et compromis induits
5.1.4 Modélisation
5.2 Gestion autonome de l’élasticité multi-couche
5.2.1 Système administré :modèle des ressources Cloud
5.2.2 Gestionnaire autonomique
6 Outiller le processus de gestion de l’élasticité
6.1 perCEPtion : un framework CEP pour la surveillance d’architecture Cloud
6.1.1 Motivations
6.1.2 Spécifications du framework
6.1.3 Gestion des événements avec Esper
6.1.4 Prise en main du framework perCEPtion : marches à suivre
6.2 ElaScript : un langage dédié à l’élasticité multi-couche
6.2.1 Motivations
6.2.2 Intégration au gestionnaire autonomique
6.2.3 Spécifications du langage
6.2.4 Implémentation et illustration
7 Décision de reconfiguration
7.1 Modèle de décision : la phase d’analyse
7.1.1 Entrées :interface avec la phase de surveillance
7.1.2 Sorties : interface avec la phase de planification
7.1.3 Base de connaissance
7.1.4 Gestionnaire autonomique : cycles de vie
7.1.5 Processus de décision : fonctionnement général
7.2 Mapping symptôme-adaptations : tactiques d’élasticité
7.2.1 Motivations
7.2.2 Spécifications
7.2.3 Implémentation
7.2.4 Exemple
7.3 Prise en compte du contexte : contraintes à l’exécution
7.3.1 Motivations
7.3.2 Spécifications
7.3.3 Implémentation
7.3.4 Exemple
7.3.5 Bilan
7.4 Préférences de l’administrateur : stratégies d’élasticité
7.4.1 Motivations
7.4.2 Spécifications
7.4.3 Implémentation
7.4.4 Exemple
7.4.5 Définition d’un calcul des cores avancé : pistes exploratoires
7.5 Vers la parallélisation de l’analyse
7.5.1 Motivations
7.5.2 Illustration
7.5.3 Pistes exploratoires
III Évaluations et conclusion
8 Évaluations des contributions
8.1 Évaluations : empreinte énergétique
8.1.1 Protocole d’expérimentation
8.1.2 Résultats
8.1.3 Discussion
8.2 Évaluations : tactiques d’élasticité
8.2.1 Protocole d’expérimentation
8.2.2 Résultats
8.2.3 Discussion
8.2.4 Vers des stratégies d’élasticité
8.3 Passage à l’échelle de la solution
9 Conclusion et perspectives
9.1 Conclusion
9.1.1 Contexte et problématique
9.1.2 Contributions
9.2 Perspectives
