Cette section présente un modèle de coordination de plusieurs gestionnaires autonomes, qui est composé d’un protocole de coordination et d’une base de connaissance publique qui nécessite un mécanisme de synchronisation. Tout d’abord, nous présentons le modèle architectural en mettant en évidence les principales exigences imposées par des modèles de services de l’informatique en nuage et comparons avec les modèles de l’état de l’art. Ensuite, nous décrivons le modèle de base de connaissance et le mécanisme de synchronisation sur lesquelles nous nous appuyons. Enfin, nous décrivons le protocole de coordination qui est basé sur un ensemble d’actions et d’événements inter-gestionnaires.
A.3.1 Modèle architectural
Les services en nuage permettent un accès facile aux ressources de calcul (par exemple des appli- cations logicielles ou de l’infrastructure) d’une manière encapsulée et transparente, ce qui signifie que les détails internes sur l’état ou le comportement de ces ressources sont cachés aux consom- mateurs de services. C’est pourquoi, nous nous intéressons à des modèles architecturaux pour l’interaction entre gestionnaires autonomes qui répondent aux contraintes inhérentes des modèles de services en nuage à l’égard du partage d’information et le couplage lâche.
Selon l’état de l’art sur les architectures auto-adaptatives [Lem13], l’interaction entre gestion- naire autonomes peut suivre un ensemble de patrons, comme il est illustré dans la figureA.2.
Dans le patron hiérarchique, des boucles de contrôle MAPE-K [KC03] (de l’anglais monitor- ing, analysis, planning, execution et knowledge) complètes sont organisées dans une hiérarchie, dans laquelle les boucles (ou gestionnaires) à des niveaux inférieurs fonctionnent à des échelles de temps courts pour résoudre des problèmes locaux, alors que celles des niveaux supérieurs travail- lent à des échelles de temps longs et possèdent une vision globale des problèmes grâce à des mes- sages passés depuis les boucles aux nivaux inférieurs. Cette vision globale n’est pas souhaitable dans l’informatique en nuage en raison de limites organisationnelles, c’est à dire que les gestion-
Travaux Adaptation F onctionnelle Adaptation Non-F onctionnelle D VFS /Arrêt de PM Multi-application Gestion Lâchement Couplée Année A pplication [MFKP09] - X n/a - n/a 2009 [PDPBG09] X X n/a - n/a 2009
MoKa [AB10] - X n/a - n/a 2010
[PPMM11] - X n/a - n/a 2011
[Fer11] - X n/a - n/a 2011
[YT12] X X n/a X n/a 2012
Infra
EnaCloud [LLH+09] n/a n/a On-off X n/a 2009
Entropy [HLM+09] n/a n/a On-off X n/a 2009
[BB10] n/a n/a On-off / DVFS X n/a 2010 Snooze [FRM12] n/a n/a On-off X n/a 2012
T ransv ersale Gest. unique [VTM10] - X On-off / DVFS X - 2010
SAFDIS [GDA10,DAB11] X X - X - 2010/2011
[PCL+11] - X On-off / DVFS X - 2011
[APTZ12] - X On-off / DVFS - - 2012
CloudPack [ISBA12] - X On-off X - 2012
Multi-gest. [KCD+07] - X DVFS - - 2007 [RRT+08] - - Both - - 2008 [KLS+10] X X DVFS X X 2010 [CPMK12] - X - X X 2011 Co-Con [WW11] - X DVFS X X 2011 [CFF+11] X X On-off / DVFS - - 2011 [MKGdPR12] - X DVFS - - 2012
Table A.1: Sommaire des travaux connexes.
naires risquent être déployés pour gérer les systèmes appartenant à différents fournisseurs (par exemple dans les nuages hybrides / public).
Les patrons maître / esclave ou régionaux nécessitent un module de décision unique (analyse et/ou planification) pour toutes les boucles, c’est à dire pour toutes les applications et l’infrastructure. Ce modèle implique un manque de flexibilité dans l’autonomie de chaque gestionnaire (par exem- ple, les applications qui sont gérées des échelles de temps différentes) car tous les gestionnaires sont créés par / déployé par le même fournisseur, ce qui n’est souvent pas le cas dans les environ- nements en nuage.
Le patron décentralisé exige que chaque tâche autonome d’un gestionnaire soit coordonnées avec son homologue dans le gestionnaire paire. Alors qu’il peut être très intéressant pour faire face avec des comportements contradictoires, ce modèle ne parvient pas à fournir un couplage lâche, car le nombre de points de communication entre les gestionnaires est plus grand que dans les autres patrons, ce qui rend par conséquent les gestionnaires plus enchevêtrés.
Le patron partage d’information améliore l’absence de dissimulation d’information observée dans le modèle décentralisé, car il permet la communication entre gestionnaires seulement via les
M A P E M A P E M A P E
...
M E M A P E M A P E M A P E Système Système Système Système Système Système Système Système SystèmeDécentralisé
Hiérarchique
Maître/esclave or Régional
Partage d’information
Figure A.2: Patrons de coordination de gestionnaires autonomes.
moniteurs et les exécuteurs. Cependant, il permet un partage des données de surveillance parmi toutes les tâches de surveillance, ce qui peut ne pas être applicables dans des environnements en nuage. Par exemple, il n’est pas concevable que les applications soient au courant des détails de la mise en place des VMs dans les PM.
Compte tenu de ces limitations, nous proposons un modèle d’architecture autonome (cf. figure
A.3) pour la coordination des multiples gestionnaires qui répond aux contraintes architecturales de l’informatique en nuage en termes de couplage lâche et la dissimulation de l’information. Dans ce modèle, les gestionnaires communiquent strictement via leurs interfaces naturelles (tâches de surveillance et d’exécution), ce qui permet de restreindre les points d’interaction (inter-gestionnaires) et d’augmenter ainsi le couplage lâche entre les tâches autonomes. En ce qui concerne le dissimu- lation d’information, contrairement aux modèles précédents dans lesquels les données de surveil- lance sont partagées entre les moniteurs de tous les gestionnaires, dans le modèle proposé, la visi- bilité sur le contexte d’exécution d’un système administré quelconque est limitée au gestionnaire autonome correspondant. En effet, un gestionnaire peut partager une partie de sa connaissance avec d’autres gestionnaires afin qu’ils puissent prendre des décisions qui sont plus adéquates à l’état actuel des gestionnaires impliqués. Par exemple, les fournisseurs des IaaS peuvent s’appuyer sur une approche axée sur les prix afin d’influencer le comportement des consommateurs (par ex- emple, les fournisseurs de SaaS ou PaaS), c’est à dire que des promotions (soldes) peuvent être créées pour stimuler les consommateurs à occuper une certaine zone de l’infrastructure et ainsi améliorer le taux d’utilisation. Cette information dynamique quant aux changement de prix de locations de ressources doit être partagée entre les gestionnaires impliqués, notamment ceux qui contrôlent les IaaS/PaaS et ceux qui contrôlent les SaaS/PaaS.
A.3.2 Protocole de synchronisation pour l’accès à la base de connaissance publique
La dissimulation d’information est une caractéristique importante des modèles à base de services, et plus particulièrement des modèles de services dans le nuage. Néanmoins, le manque visibil- ité globale du contexte d’exécution des services peut conduire les gestionnaires à prendre des
M A P E M A P E Système Système K K K
•
•
Figure A.3: Modèle architectural proposé pour la coordination des multiples gestionnaires au- tonomes.
décisions qui en quelque sorte impactent négativement les systèmes administrés par d’autres ges- tionnaires.
Afin d’avoir une analyse mieux contextualisée et à respecter le principe de dissimulation d’information, la base de connaissance de chaque gestionnaire est divisé en deux parties: la connaissance privé (private knowledge), qui stocke les informations internes nécessaires pour les tâches autonomes, et la connaissance du publique (public knowledge), qui est partagée avec d’autres gestionnaires. La base de connaissance publique peut être synchronisée si les actions exé- cutées par les gestionnaires nécessitent de modifier (directement ou indirectement) l’information partagée. En effet, les actions simultanées de multiples gestionnaires peuvent conduire à des changements dans la base de connaissance en même temps (problème de concurrence) et peut conduire à des résultats globaux non-logiques (problème de cohérence). Dans notre approche, nous considérons que le gestionnaire ayant une base de connaissance publique est le seul qui a le droit de la modifier directement, ce qui évite les problèmes de concurrence.
La base de connaissance publique est composée de sections critiques et non critiques. Le pre- miers correspondent à des éléments d’informations qui sont rarement modifiées et ne qui ne com- promettent pas la cohérence du système, tandis que l’autre se réfère à des éléments d’information qui peuvent être changés fréquemment, donc qui peuvent interférer dans la cohérence du système. Ainsi, alors que la synchronisation est facultative pour accéder aux sections non critiques, elle est obligatoire pour accéder à celles qui sont critiques.
Pour cette raison, nous introduisons un protocole à base de jetons afin de synchroniser l’accès aux sections critiques entre plusieurs gestionnaires. Comme pour les transactions dans les bases de données, ce protocole de synchronisation assure que seul un gestionnaire peut accéder à une section critique à la fois. Chaque section critique est associé à un jeton, ce qui signifie que, pour accéder à une section critique donnée, les gestionnaires doivent demander le jeton correspondant. Un gestionnaire peut obtenir le jeton soit en demandant explicitement via un message TOKEN REQUEST (demande active de jeton), soit via un message de transfert de jeton (TOKEN TRANS- FERT) d’un gestionnaire vers un autre (réception passive de jeton). Chaque fois qu’un gestion- naire n’a plus besoin de jeton, il le libère via un message TOKEN RELEASE. Chaque fois qu’un jeton est demandé, le demandeur doit attendre un message de jeton acquis TOKEN ACQUIRED. Chaque gestionnaire autonome ayant une connaissance publique avec des sections critiques met en œuvre un gestionnaire de jetons qui est en charge de la gestion du protocole de jeton.
A.3.3 Protocole de coordination dirigé par des évènements
L’objectif du protocole de coordination est de fournir des moyens pour les gestionnaires autonomes de communiquer afin que les actions soient exécutées de façon coordonnée et de mettre en place une synergie entre les gestionnaires. Dans le modèle architectural proposée, la communication entre les gestionnaires est achevée à travers des tâches de surveillance et d’exécution, qui sont déjà utilisées comme interfaces avec le système administré. Par conséquent, ces gestionnaires sont moins enchevêtrés les uns avec les autres et donc plus faiblement couplés.
Afin de clarifier les interactions entre plusieurs gestionnaires, il est important de différencier les actions et les événements qui font partie du système administré et ceux qui font partie du modèle architectural multi gestionnaires. La figureA.4illustre la hiérarchie des différents types d’événements et d’actions.
Actions
On the
Managed System Intraloop Interloop
Change Public Knowledge
Events
Endogenous Exogenous
Interloop Public Knowlege Changed Schedule
Handler Fire Event
Figure A.4: Hiérarchie d’actions et d’évènements autonomes.
Les actions peuvent être exécutées sur le système administré (Action on the managed system), dans la boucle de contrôle MAPE-K (intraloop) ou sur une autre boucle de contrôle MAPE-K (interloop). Les actions sur le système administré et les actions interloop sont toujours exécutées par la tâche d’exécution de la boucle de contrôle MAPE-K. Une action interloop peut notifier un autre gestionnaire autonome comme s’il demandait un service et attendait la réponse. Toutefois, afin d’éviter les états de blocage, les gestionnaires doivent communiquer de manière asynchrone. Dans ce cas, la tâche de planification crée un conteneur (handler) avec toutes les autres actions qui doivent être exécutées en réponse à cette action interloop. Cette action interloop est donc une action de notification, qui est considéré comme un événement inter-boucle (interloop) pour la boucle de contrôle destinataire.
Enfin, les actions intraloop peuvent être pour modifier le contenu de la base de connaissance publique ( Changer Public Knowledge), pour programmer les actions d’un conteneur (Schedule Handler) qui dépend d’un ou plusieurs objets futurs [EFGK03], ou pour déclencher un événement endogène (Fire Event) sur le même gestionnaire autonome. Cette action peut être instantanée ou temporisée (soit déclenchée après un intervalle de temps donné).
Comme il est illustré dans la figureA.4, un événement peut être soit endogène ou exogène. La source d’événements endogènes est toujours le système administré. Alors que la source d’événements exogènes est un autre gestionnaire autonome. Pour les événements exogènes, il y a les événe- ments inter-boucle (interloop) - créés par les actions inter-boucle (interloop) - et les évènements qui indique qu’une base de connaissance publique a été modifiée (Public Knowledge Changed) - déclenché suite à une action Change Public Knowledge.