6.4.1 Installation
Une fois le plan de d´eploiement g´en´er´e, le moniteur de d´eploiement lance sa r´ealisation. S’il y a eu une modification de l’´etat du domaine, une boucle autonomique doit prendre le relais pour adapter le plan de sorte qu’il satisfasse les propri´et´es initiales `a pr´eserver. Lors de cette phase, le syst`eme de d´eploiement utilise les sondes du composant des sondes sp´ecifiques (version 1), ainsi que le composant Probes Supervision (V1) pour analyser les donn´ees obtenues et d´etecter l’insatisfaction de propri´et´es.
La figure6.4 repr´esente l’architecture du support local de d´eploiement `a ce stade. Des agents supportent diff´erentes activit´es (installation et activation du composant, supervision, etc.). Un composant Agent Platform est donc n´ecessaire pour supporter l’ex´ecution de ces agents.
Figure 6.4 – Architecture du support local de d´eploiement avant l’installation
6.4.2 Activation
Une fois install´es sur les diff´erents appareils, les composants du syst`eme r´eparti multi- ´echelle sont activ´es (cf. figure6.5).
`
A partir de l`a, les sondes d´efinies dans le composant des sondes sp´ecifiques (ver- sion 1) ne sont plus toutes n´ecessaires : seules celles concernant les propri´et´es `a pr´eserver `a l’ex´ecution sont `a conserver. Ce composant est donc remplac´e par un autre (version 2). De la mˆeme mani`ere, une seconde version du composant de supervision remplace le premier.
6
Figure 6.5 – ´Etapes de l’installation et l’activation
Figure 6.6 – Architecture du support local de d´eploiement apr`es l’installation
6.4.3 Ex´ecution
Une fois les composants du syst`eme d´eploy´e install´es et activ´es, l’activit´e principale du syst`eme de d´eploiement est la supervision. Un nouveau composant est ´egalement install´e (cf. figure 6.7), appel´e Deployed Software Communication : il offre au syst`eme d´eploy´e un moyen d’interagir avec le support local de d´eploiement (demande de reconfiguration, ´echange d’informations, etc.).
6
6.5
Conclusion
Dans ce chapitre, nous avons propos´e une architecture r´epartie qui supporte le d´eploiement initial de mani`ere automatique, de la constitution du domaine et de l’acqui- sition de son ´etat jusqu’`a la r´ealisation du plan de d´eploiement. Cette phase est contr ˆol´ee par un ´el´ement centralis´e, le moniteur de d´eploiement, qui s’appuie sur un gestionnaire du domaine et sur un support local de d´eploiement sur chaque appareil. Ce support local est un conteneur de composants, initialement minimal, qui s’enrichit dynamiquement de com- posants pour la r´ealisation du d´eploiement. En outre, il int`egre une plateforme d’ex´ecution pour des agents autonomes ; il est ainsi susceptible de supporter les adaptations autono- miques du plan de d´eploiement lors de l’ex´ecution de l’application d´eploy´ee. Par ailleurs, dans ce chapitre, nous avons montr´e comment les propri´et´es exprim´ees au moyen du lan- gage MuScADeL peuvent ˆetre transform´ees afin de pouvoir ˆetre trait´ees par un solveur de contraintes. C’est ce solveur qui produit un plan de d´eploiement initial adapt´e `a l’´etat du domaine et conforme aux sp´ecifications exprim´ees.
Contribution
Afin de supporter le d´eploiement initial, une architecture r´epartie est pro- pos´ee. Elle est compos´ee d’un gestionnaire de domaine qui enregistre les entr´ees et les sorties des appareils, d’un moniteur de d´eploiement et d’un support local de d´eploiement sur chaque appareil. Le moniteur de d´eploiement utilise un solveur de contraintes pour produire le plan de d´eploiement. Pour cela, les propri´et´es sp´ecifi´ees doivent ˆetre transform´ees en contraintes avant d’ˆetre trait´ees par le solveur. C’est aussi le moniteur de d´eploiement qui lance la r´ealisation du plan. Initialement, le support local de d´eploiement est un bootstrap minimal. Il s’enrichit de nouveaux composants au fur et `a mesure de l’avanc´ee du processus, et h´eberge `a la fois les composants du syst`eme de d´eploiement et ceux de l’application d´eploy´ee.
7
D´eploiement autonomique :
architecture et situations
d’adaptation
Probl´ematique
Le d´eploiement initial effectu´e, le syst`eme de d´eploiement doit main- tenir en condition op´erationnelle le syst`eme d´eploy´e. Le domaine de d´eploiement ´etant dynamique, des perturbations vont intervenir lors de l’ex´ecution du syst`eme d´eploy´e. Le syst`eme de d´eploiement doit pouvoir identifier ces situations, les analyser et ex´ecuter la solution si elle existe. De plus, la taille du domaine de d´eploiement ne permet pas une gestion centralis´ee de cette dynamique. Le syst`eme de d´eploiement doit pouvoir prendre en compte ces situations de mani`ere d´ecentralis´ee.
7.1
Introduction
7.1.1 Dynamique du domaine de d´eploiement
Le d´eploiement d’un syst`eme r´eparti multi-´echelle s’effectue en deux ´etapes : le d´eploiement initial (cf. figure4.9), que nous avons expos´e dans les chapitres pr´ec´edents, et le maintien en condition op´erationnelle `a l’ex´ecution du syst`eme. Ceci s’effectue en faisant ´evoluer le plan de d´eploiement en fonction de la dynamique du domaine de d´eploiement.
De par la nature du domaine, le syst`eme d´eploy´e va subir des perturbations. Nous d´enotons trois types de perturbations :
D’une part, l’apparition de nouveaux appareils. Ce cas de figure aura ´et´e pris en compte d`es la sp´ecification du d´eploiement par le concepteur qui aura d´efini des propri´et´es dy- namiques sur certains composants. Le syst`eme de d´eploiement doit pouvoir int´egrer ces nouveaux appareils dans le plan de d´eploiement.
Puis, la variation de l’´etat du domaine menant `a une inconsistance (c’est-`a-dire pro- pri´et´es de d´eploiement insatisfaites). Ce sont les changements de l’´etat d’un appareil qui
7
viole une prori´et´e du composant h´eberg´e ou une exigence de ce composant : la m´emoire vive n’est plus suffisante, le r´eseau exig´e n’est plus actif, etc. Le syst`eme de d´eploiement doit ˆetre `a mˆeme de faire ´evoluer le plan de d´eploiement en trouvant une solution, si elle existe, `a ces violations de propri´et´es.
Enfin, la disparition d’un appareil h´ebergeant un composant n’ayant pas de propri´et´e dynamique sp´ecifi´ee : un composant qui doit ˆetre d´eploy´e sur dix appareils exactement, etc. Le syst`eme de d´eploiement doit d´eployer `a nouveau ce composant sur un appareil qui peut l’h´eberger.
Afin de r´epondre `a cette dynamique, une adaptation doit pouvoir ˆetre effectu´ee au plus pr`es des appareils cibl´es.
7.1.2 D´eploiement autonomique
La taille du domaine de d´eploiement influe sur la mani`ere dont est conc¸u le syst`eme de d´eploiement. Si le syst`eme de d´eploiement ´etait centralis´e, cela aurait pour cons´equences une latence dans les temps de r´eponse, une utilisation massive de la bande passante, et des risques de surcharge du moniteur de d´eploiement. L’h´et´erog´en´eit´e des appareils impliqu´es dans le d´eploiement induit le besoin d’une r´eponse adapt´ee aux appareils dans le domaine de d´eploiement et aux composants d´eploy´es en cas de perturbations. De ce fait, afin d’ˆetre capable de r´epondre efficacement aux perturbations, le syst`eme de d´eploiement doit ˆetre d´ecentralis´e.
Le syst`eme de d´eploiement doit donc avoir deux caract´eristiques principales pour la gestion du d´eploiement `a l’ex´ecution de l’application. D’un c ˆot´e, il faut qu’il soit d´ecentralis´e afin de pouvoir r´eactif, en ayant une r´eponse rapide et locale `a la dynamique du domaine de d´eploiement. D’un autre c ˆot´e, il doit ˆetre autonome afin de pouvoir trouver une solution adapt´ee aux perturbations rencontr´ees au cours de l’ex´ecution du syst`eme d´eploy´e.
En 2001, IBM a soulev´e dans un manifeste [Horn, 2001] le probl`eme que poserait la com- plexit´e des syst`emes informatiques `a venir. Les syst`emes devenant de plus en plus com- plexes, grands en taille et distribu´es, la gestion et l’administration par l’humain de tels syst`emes s’av`ere une tˆache colossale. La r´eponse `a ce probl`eme a ´et´e l’ informatique auto- nomique (autonomic computing).
L’informatique autonomique d´esigne un ensemble de solution pour qu’un syst`eme in- formatique se g`ere lui-mˆeme `a partir de sp´ecifications et d’objectifs de haut-niveau donn´es par un administrateur [Kephart and Chess, 2003]. L’autonomie de ces syst`emes se base sur quatre principes : l’auto-configuration, l’auto-optimisation, l’auto-r´eparation et l’auto- protection. Afin de pouvoir r´ealiser ces tˆaches d’auto-gestion, le syst`eme autonomique a besoin d’avoir des informations sur l’´etat du syst`eme, analyser ces donn´ees, prendre une d´ecision, et l’appliquer. Ce processus est d´efini pas la boucle autonomique introduite par Kephart et Chess dans [Kephart and Chess, 2003]. La figure7.1pr´esente cette boucle de l’in- formatique autonomique. Dans un premier temps, le syst`eme perc¸oit un changement dans l’environnement (Monitor), et analyse ce changement en prenant en compte les informations disponibles (Analyze, Knowledge). Puis, l’action `a appliquer sera planifi´ee (Plan) pour une ex´ecution imm´ediate ou diff´er´ee de la solution (Execute).
L’informatique autonomique est indiqu´ee comme solution `a notre probl`eme de main- tien en condition op´erationnelle de l’application pour r´epondre aux besoins d’adaptation d´ecentralis´ee. La figure7.2illustre les m´ecanismes autonomiques d´ecentralis´es requis pour
7
Figure 7.1 – Boucle autonomique : perception, analyse, planification et ex´ecution [Kephart and Chess, 2003]
le syst`eme de d´eploiement.
Figure 7.2 – M´ecanismes autonomiques d´ecentralis´es
Dans cette th`ese, nous nous sommes concentr´es sur les aspects processus, sp´ecification du d´eploiement avec le langage d´edi´e et d´eploiement initial. Dans ce chapitre, nous commenc¸ons par analyser les situations d’adaptation qui peuvent intervenir `a l’ex´ecution du syst`eme d´eploy´e (section 7.2). Puis, nous apportons quelques ´el´ements de solutions `a ces situations d’adaptation, dans le cadre d’une architecture du syst`eme de d´eploiement (section7.3).