Avec l'émergence de plusieurs CSPs fournissant des services cloud identiques, l'utilisa- teur préfère celui qui garantit la meilleur QoS et qui respecte ses contrats de SLA. Pour cela, la gestion de la QoS dans le cloud gagne de plus en plus d'importance. Ci-dessous, nous discutons certains articles qui montrent bien l'intérêt croissant des chercheurs pour cette gestion de QoS dans le monde du cloud.
Dans [14], les auteurs proposent un fournisseur Cloud@Home qui agrège des res- sources hétérogènes oertes par diérents fournisseurs cloud et les propose d'une ma- nière uniforme à l'utilisateur. Ensuite, il maintient le SLA que signe l'utilisateur avec les fournisseurs de ces ressources. Pour ce faire, le fournisseur Cloud@Home fournit une architecture de services qui contient un ensemble de composants pour négocier, contrô- ler et renforcer la QoS. Cette architecture SOA s'appuie sur trois modules : le Resource Abstraction Module qui relie le fournisseur Cloud@Home aux diérents fournisseurs cloud ; le Resource Management Module qui collecte les ressources cloud, regroupe les requêtes de l'utilisateur et gère les composants de l'architecture Cloud@Home ; et en- n, le SLA Management Module qui orchestre le processus de gestion de QoS. En eet,
le SLA Management Module lance les négociations de QoS entre les utilisateurs du Cloud@Home et les fournisseurs cloud. Une fois le document de SLA est signé, ce mo- dule contrôle les contraintes de QoS. Ainsi, quand il détecte un non respect du contrat, il lance un provisionnement dynamique des ressources qui supportent les préférences de l'utilisateur.
Le principal inconvénient de cette solution est qu'elle est centralisée. En eet, elle s'appuie sur un fournisseur Cloud@Home central qui se charge des négociations et de la maintenance de la QoS. Donc, tous les fournisseurs clouds et tous les utilisateurs doivent être reliés à ce même fournisseur Cloud@Home qui constitue par conséquence un point de défaillance et d'étranglement qui dégrade les performances.
Dans [44], les auteurs proposent à déléguer le contrôle du SLA à un fournisseur tiers, noté SLMA (Service Level Management Authority). Ce dernier est considéré comme un compromis entre les utilisateurs et les fournisseurs des services cloud au niveau de la responsabilité de gérer le SLA. Pour ce faire, le SLMA propose trois types de contrôle : le Synthetic Monitoring, le Customer Monitoring et le Transaction-based Monitoring. Le Synthetic Monitoring consiste à faire le contrôle uniquement au niveau des fournisseurs. Ainsi, le SLMA détecte les non respects des contrats de SLA seulement quand le service cloud est indisponible ou en panne. Le Customer Monitoring consiste à faire le contrôle uniquement au niveau du terminal de l'utilisateur. Ainsi, le SLMA détecte le non respect des contrats de SLA en se basant sur des mesures plus pertinentes et plus complètes de l'environnement cloud selon le point de vue des consommateurs. En n, le Transaction-based Monitoring consiste à utiliser le HP Business Availability Center [36]. Ce dernier permet à un fournisseur de contrôler les services métiers tout en prenant en considération le point de vue des consommateurs de ces services. En eet, il contient un ensemble de composants qui gèrent le SLA, contrôlent les transactions IT, identi ent les problèmes, les résolvent et les empêchent de se répéter.
Le principal inconvénient de cette solution est qu'elle est centralisée. La plate- forme SLMA est centrale, et elle est ainsi considérée comme un point de défaillance et d'étranglement qui dégrade les performances. En outre, la solution de SLMA intervient seulement comme un arbitre entre les fournisseurs cloud et les utilisateurs, a n de résoudre le problème de manque de con ance entre ces deux parties. En eet, le SLMA évalue les performances des services cloud et détecte les défaillances, mais il ne propose aucune solution pour surmonter ces problèmes de SLA.
A n de dépasser ces inconvénients et ces insu sances au niveau de ces solutions discutées, le cloud a besoin d'une solution décentralisée qui ne se limite pas à évaluer les performances et à détecter les défaillances des services cloud, mais à répondre aussi d'une manière dynamique et transparente à ces dégradations de QoS. Pour cette raison, nous assurons que les solutions que nous avons proposées dans cette thèse au niveau de la gestion de la QoS peuvent in uencer positivement les performances du cloud et assurent un grand pas vers un cloud plus e cace. En eet, grâce à notre modèle de QoS à quatre critères (disponibilité, capacité, délai et abilité), nous présentons d'une manière homogène la partie non fonctionnelle des services cloud, ce qui facilite la gestion de QoS et la rend plus rapide et plus exible. En outre, d'après nos solutions, nous favorisons une gestion décentralisée au cours de laquelle, il n'y a pas un point de
défaillance et d'étranglement qui peut causer une dégradation des performances. Notre approche décentralisée se base sur des services autogérés, dont chacun est responsable de sa propre QoS et participe à l'anticipation de la coupure de la session de services. Pour ce faire, un agent de QoS est associé à chaque service, ce qui lui permet de contrôler sa propre QoS et de noti er par un OUT-Contract les autres services concernés, lors d'une dégradation ou d'un mauvais fonctionnement. A n de permettre aux fournisseurs cloud de réagir dynamiquement à ces dégradations et de mieux respecter les préférences de leurs utilisateurs, nous avons proposé un nouveau concept qui consiste à combiner des services ubiquitaires, ayant une même fonctionnalité et une QoS équivalente, dans des communautés virtuelles. Ainsi, ces dernières proposent des services qui sont capables de remplacer le service dégradé d'une manière continue et transparente, ce qui permet de respecter la QoE de l'utilisateur et de garantir ses préférences fonctionnelles et non fonctionnelles.