Utilisateur:Junior Burleon/Brouillon

Les différentes techniques de gestion de l'élasticité du Cloud.

Le Cloud permet d'externaliser une grande partie des fonctionnalités que les ordinateurs personnels peuvent nous fournir. Bien que le Cloud externalise et rend disponible ces fonctionnalités, appelées services, depuis n'importe quel ordinateur connecté à internet, il centralise tous ces services pour les utilisateurs.

Dû à la centralisation des données et des services de nombreux utilisateurs, la capacité de traitement du Cloud doit être conséquente. Néanmoins, le Cloud n'est pas sollicité en permanence de la même manière et le volume de sollicitation des services peut donc varier.

De ce fait, différents moyens de gestion des Cloud sont mis en place par les fournisseurs de Cloud afin que la puissance de traitement de ceux-ci puissent s'adapter à la demande. Ce procédé est défini comme la gestion de l'élasticité du Cloud.

Définition

Le Cloud est une grande infrastructure matérielle privée, qui rend accessible de nombreux services. L’élasticité du Cloud signifie rendre cette infrastructure facilement et dynamiquement adaptable et flexible. Elle se traduit par la capacité de cette infrastructure à se mettre à l’échelle. Le Cloud est architecturé selon différents niveaux d’abstraction. Ceux-ci peuvent être au niveau géographique, au niveau hardware, ainsi qu'au niveau software. Le besoin d’élasticité du Cloud se traduit par le fait que le Cloud n’est pas sollicité continuellement avec la même intensité sur chacun des points de son architecture. Pour cette raison, une logique économique s’est développée.

Celle-ci est le “Pay as you use”, qui signifie "Paie ce que tu utilises", ni plus ni moins. Cela permet aux utilisateurs des services Cloud comme aux fournisseurs, de gagner en performance économique et technique. Pour répondre à cette demande économique il est primordial de permettre aux serveurs composant le Cloud une auto-organisation et une gestion au regard de la demande subie par le service d’un client. Autrement dit, il s'agit de fournir plus de puissance de traitement ou de mémoire et mieux localiser un service qui est actuellement fortement sollicité. En contrepartie, un service peu sollicité se verra allouer moins de ressources. Pour permettre cela, il est nécessaire d’avoir un grand nombre d'indicateurs et ce à différents niveaux de l’architecture du Cloud. Il faut également avoir un algorithme ou un ensemble de techniques qui va se charger de faire varier les ressources allouées à chaque service ou client en fonction de leur requête.

La gestion élastique du Cloud signifie que le fournisseur de Cloud va instaurer des moyens qui permettront l'adaptation du Cloud aux besoins selon différents critères, telles que :

• Économie (Prix de l’électricité)
• Localisation/Géographie
• Disponibilité des services
• Capacité de traitement

SchemaCloud

SaaS : software as a service se définit comme un modèle dans lequel les logiciels sont loués comme des services.

PaaS : platform as a service est un modèle dans lequel des plateformes sont loués comme des services. Il s’agit d’un serveur installé dans un système d'exploitation et quelquefois installé avec d’autres programmes. Parfois, ils sont appelés DaaS pour desktop as a service.

IaaS : infrastructure as a service est un modèle où le matériel, c’est à dire des serveurs, sont loués comme des services. Cela permet au client de ne pas devoir s’occuper du matériel tout en ayant la possibilité d’y déployer l'environnement logiciel et le système d’exploitation qu’il souhaite.

Historique

Le Cloud est un ensemble de serveurs que l’on fait communiquer et travailler ensemble pour délivrer divers services. Le terme Cloud Computing, n’est donc que des mots mis sur un concept qui existe depuis le début de l’informatique. Toutefois, “Cloud computing” ou “Informatique dans les nuages” permet de mieux faire comprendre la notion de serveurs distants qui se gèrent eux-même et sur lesquels nous avons peu d’emprise.

Avec l’apparition du Cloud et donc d’une manière plus général des services distants, s’est révélée la problématique d’avoir une infrastructure qui puisse délivrer ces services sans interruption et avec un niveau de qualité garanti quelque soit la situation rencontrée par les services.

C’est ainsi qu’est né le besoin de rendre élastique l’infrastructure du Cloud de façon qu’elle s’adapte à la demande et plus implicitement à l’économie.

Economie

Utiliser le Cloud permet d’économiser sur un bon nombre de points, principalement le matériel. Cependant, le Cloud élastique, apporte avec lui le “Paie ce que tu utilises”, ce qui est très bénéfique d’un point de vue économique pour les clients de ces services.

Ainsi, il est possible de payer un montant qui varie en fonction de l’utilisation et de ne pas devoir payer en continu (pour le pire des cas un prix forfaitaire fixe).

Exemple : un client a besoin en moyenne de 3 serveurs qui lui coûteraient 500€ par serveur, soit 1500€. Néanmoins, parfois, il y a un pic de demandes et le client a besoin de 6 serveurs pour répondre au besoin de ce pic. Dans le cas où cette notion d’élasticité n’existe pas, il est nécessaire pour le client de payer tout le temps pour 6 serveurs, soit 3000€. Si cette notion d’élastique est appliquée, le client peut payer 1500€, et un surplus uniquement lorsqu'un pic survient. Cet aspect économique émerge du développement de différentes techniques.

Les techniques

Virtualisation & Ressources dynamiques

Utiliser des machines virtuelles ou Docker permet d’ajouter une couche d’abstraction qui isole le matériel. De cette façon, il devient possible de créer des machines virtuelles ou des conteneurs Docker instantanément lorsque cela est essentiel. De plus, cela permet de supprimer ces conteneurs ou de diminuer les ressources qui leur sont allouées quand elles ne sont plus nécessaires.

La gestion dynamique des ressources rend possible le load balancing. Le load balancing équilibre la charge de travail que chaque serveur doit gérer. Il existe de nombreux algorithmes qui optimisent la gestion de la charge de travail des serveurs. Pour cela, ces algorithmes ont besoin de diverses informations pour être exécutés. Ces informations peuvent être fournies par différents systèmes d’analyse. Ceux-ci analysent en continu ce qu’il se passe dans l’infrastructure. Il faut de nombreux capteurs capables de donner des informations sur l’état de l’infrastructure, afin que l’infrastructure réagisse en fonction de ce qui s’y passe.

La virtualisation ainsi que la gestion dynamique des ressources ne sont qu’une partie de l’ensemble des points qui rendent possible la réalisation d’un cloud élastique.

Réaction rapide au changement de la charge

Le Cloudfarm est une architecture PaaS avec un mécanisme d’adaptation des ressources. Il introduit un nouveau FLA (Field Level Agreement) flexible avec une interface de management pour les services des clients finaux. Avec ce FLA, une baisse du niveau de qualité des services peut être appliquée et adaptée pour surmonter les pics à court-terme.

Le SLO (Service Level Objectives) s’appuie sur un nouveau management de ressources pour les plateformes Cloud. Selon le pays des locataires, un nouvel ensemble de SLOs autorise les applications et les services à fonctionner moins bien durant une période de temps restreinte. Pour les clients, ces SLOs sont moins cher. Les fournisseurs ont la possibilité de surmonter des pics à court-terme ou de préparer un approvisionnement supplémentaire. Un nouveau modèle d’application est proposé reposant sur divers modes. Chaque mode apporte un niveau de QoS différent et utilise un nombre distinct de ressources. L’ordonnanceur de ressources qui est intégré, régit les applications selon leurs modes. Cela permet d'utiliser pleinement les nœuds de calcul. Ainsi, il empêche également des cas de sur-chargement. Il fournit les ressources selon les SLAs (Service Level Agreement) que les clients ont souscrit. Les clients ayant un contrat cher sont rarement inquiétés par les pics alors que ceux ayant un contrat moins cher doivent les équilibrer.

OSGi est un modèle d’application de composants de base. Il est utilisé et élargi avec le management de ressources et les caractéristiques du cloud. De plus, COSCA est une plateforme PaaS basée sur du Java qui peut accueillir des applications sur un matériel tiers-partagé. Du fait que le déploiement d’applications indépendantes sur un seul nœud nécessite une séparation, la plateforme COSCA fournit des environnements isolés pour chaque application, appelés Frameworks virtuels. COSCA peut accueillir plusieurs applications dans un seul hébergement sans utiliser une couche IaaS supplémentaire. L’aspect premier d’Artos est qu’il supporte divers modes d’opération prédéfinis. Pour rendre possible cela, il utilise un manifest de mode d’application qui est une configuration de modes de tâches qui peuvent être changées dynamiquement.

Cloudfarm utilise des frameworks virtuels pour chaque application. Quand la plateforme détecte un bouchon, elle peut utiliser deux stratégies pour régler les pics à court-terme. Soit l’approche de composants de base qui active le re-câblage des composants et qui sélectionne le composant avec la plus faible consommation de ressources. Soit elle peut changer de mode d’exécution engendré par l’application toute entière.

Les SLOs font parties des SLAs et des conditions de mesure tels que la disponibilité et le temps de réponse des systèmes. Les plateformes Cloud utilisent les mesures du système d’exploitation pour déterminer la charge de travail d’un nœud. Ce sont des valeurs moyennes pour une période de temps donné où le fournisseur ne peut plus garantir à la non-violation des pics durant les pics. Une simple augmentation des ressources ne permet pas forcément d’améliorer la performance et la conformité SLO des applications. L’approche de management de ressources pour le Cloudfarm donne aux fournisseurs de Cloud l’opportunité de réagir et de contrôler les violations SLO. Un fournisseur est donc capable d’optimiser son utilisation des ressources et le coût des nœuds de calcul individuels.

Utilisation de critères utilisateur & fournisseur

Dans un environnement de Cloud-computing, de nombreux Web services sont préservés par une plateforme Cloud, qui joue le rôle de “supermarché” de services. Par conséquent, quand une requête d’un utilisateur final arrive, la plateforme est responsable de la réception de la requête et de la sélection du service le plus qualifié selon les besoins de l’utilisateur final. Cette situation se produit quand il n’y a pas de méthode de compensation pour coordonner l’exécution de la composition de services. De plus, même la plateforme possède une majorité de services recrutés par un ordonnancement de composition de service.

Une plateforme Cloud est considéré comme élastique si un processus externe de service peut être provoqué automatiquement . Dans notre contexte, le processus externe de service est essentiellement un processus de matching QoS, entre la plateforme Cloud élastique et les fournisseurs de services qui pourraient prendre le contrôle du besoin extérieur pour élire le fournisseur de services idéal.

Avant tout, de multiples niveaux de qualité peuvent être annoncés, en pratique, par un fournisseur de services, dans le but d’attirer de potentiels clients finaux avec différents préférences de qualité. (Par exemple, un service pourrait fournir un temps d’exécution de 5s à 10s avec différentes charges…). La relation de mapping entre ces domaines de valeurs montre un processus d’invocation de service flexible dans une manière d’échanger. A partir d’un autre point de vue, pour un utilisateur final, c’est plus judicieux de spécifier son besoin de QoS avec une série de valeurs plutôt qu’une valeur fixe. (Par exemple, un utilisateur final peut indiquer son attente en terme de prix sous forme d’un domaine de valeur [$10,$20], plutôt qu’un prix fixe, pour choisir un web service).

Pour analyser ces domaines de valeurs, plusieurs fonctions sont mises en place. Une fonction de dépendance exprime les échanges flexibles parmi un certain nombre de critères de QoS. Elle est spécifiée par le fournisseur de services. Par exemple, elle contraint à prendre en considération deux critères, le prix et le temps d’exécution. Dep-f (p, t) est une fonction de dépendance, avec p et t les critères de prix et de temps d’exécution. En vue d’une préférence de plateforme de Cloud pour un critère de qualité, une fonction de satisfaction est définie comme qui suit, pour montrer certaine préférence dans une sélection de service. Pour un web service, on suppose qu’il y a m critères QoS espérés par ses utilisateurs finaux. Pour un critère QoS concrete c, une fonction de satisfaction Sat-f(c) montre la règle de préférence d’un utilisateur final imposée par le domaine de valeur de c où [c(low), c(upp)] est le domaine de valeur de c. Par exemple pour un critère de prix, si la plateforme de Cloud affirme que sa fonction de satisfaction Sat-f(p) = 1 - 0.25 * p (avec p appartient à [0, 4]) est démontrée, alors les degrés de satisfaction minimal et maximal sont 0 (p=4) et 1 (p=0, avec charge offerte). En pratique, la fonction de satisfaction est définie par les utilisateurs finaux par rapport à leur préférence et la recommandation du fournisseur de service s’appuyant sur leurs historiques d’invocation.

Pour un groupe de critères associé à un web service, un utilisateur final pourrait procurer différents poids de façon à mettre en avant l’importance de chaque critère par une évaluation du service. Dans ce contexte, les poids sont pris en compte pour évaluer le QoS d’un service candidat. En outre, il faut considérer que si les poids ne sont pas définis, tous les critères auront le même poids. Alors ils seront traités de la même manière par le service d’évaluation. Par exemple, pour un web service, si la valeur poids du prix est 0,7 et celle du temps d’exécution est 0,3, alors le prix joue un rôle plus important que le temps d’exécution.

Pour orchestrer ces facteurs d’une manière collaborative, un framework intégré à la plateforme de Cloud élastique est formalisé comme qui suit. Il y a deux domaines de valeur associés à un web service, celui du fournisseur et celui de l’utilisateur final. Le chevauchement de ces deux domaines est considéré par la méthode. Il est considéré comme un domaine de valeur efficace associé à une fonction de satisfaction. La méthode d’évaluation d’un service externe peut être finalement résumée ainsi: Pour chaque service externe candidat, on calcule le degré de satisfaction maximale d’un utilisateur final. Un service qui accomplit le plus grand degré de satisfaction est sélectionné par l’utilisateur final.

Une plateforme de Cloud-computing élastique permet d’optimiser la robustesse et la capacité de compétitivité de la plateforme. D'ailleurs, un processus externe de service peut être déclenché quand un service obligatoire est absent de la plateforme de Cloud. La méthode d’évaluation de service est portée par une sélection de services activés par les fonctions de dépendance et de satisfaction.

Bibliographie

[[Catégorie:Informatique]] [[Catégorie:Cloud computing]]