Construction du SR

Une fois les ´el´ements `a administrer soumis au SAA, celui-ci doit construire en son sein une repr´esentation de ces ´el´ements : c’est le rˆole du SR Manager dans notre mod`ele. Il s’appuie sur trois sous composants : le Parser , le Wrapper et le

8.1. MOD `ELE D ´ETAILL ´E DE TUNEENGINE 88 SR.

Le Parser a pour rˆole d’identifier `a partir de la soumission de l’administrateur : la liste des ´el´ements `a administrer par le SAA, leurs propri´et´es, ainsi que les relations entre eux. Il peut ˆetre organis´e en plusieurs Parser s afin de prendre ´egalement en compte les ´el´ements comme les programmes d’administration. Pour chaque ´el´ement identifi´e, le Parser demande au Wrapper de construire le repr´esentant de cet ´el´e- ment dans le SAA.

Construire le repr´esentant d’un ´el´ement dans le SAA signifie encapsuler son comportement dans une structure de donn´ees qui facilitera son administration par le SAA. Nous appelons ´egalement wrapper ce repr´esentant. Pour le construire, le Wrapper utilise les informations fournies par le Parser . Les ´el´ements construits peuvent ˆetre des logiciels, des machines, des liaisons, des ´el´ements constituant un programme de reconfiguration, etc. Nous proposons dans notre mod`ele, l’utilisa- tion du formalisme `a composants Fractal pour la construction des wrappers. Comme nous le verrons ci-dessous, ce choix de Fractal ne remet pas en cause l’adaptabilit´e du Wrapper . En effet, construire un repr´esentant dans le SAA revient `a construire `

a terme une architecture logiciel. Cette fonctionnalit´e est parfaitement remplie par Fractal. Utiliser un formalisme ou un moyen autre que Fractal revient `a utiliser/im- planter un formalisme ´equivalent. En r´ealit´e, le choix port´e sur Fractal est favoris´e par ses API qui r´epondent parfaitement `a nos attentes dans la construction des re- pr´esentants. Notons que l’implantation du Wrapper d´ecidera du cˆablage ou non des types d’´el´ements dans le SAA (voir le crit`ere d’uniformisation de la section 6.1.1

du chapitre6). Dans le cadre du syst`eme TUNeEngine, nous utilisons (comme nous l’avons pr´econis´ee) une unique structure de donn´ees pour l’encapsulation de tout type d’´el´ements.

Pour finir, le SR dans notre mod`ele joue deux rˆoles. Il repr´esente d’une part la structure de donn´ees contenant l’ensemble des repr´esentants des ´el´ements admi- nistr´es et programmes de reconfiguration dans le SAA. Nous reprenons l’expression de ”Syst`eme de Repr´esentation” introduit par le syst`eme TUNe pour le d´esigner. D’autre part, il fournit le moyen d’introspection des wrappers et du syst`eme de repr´esentation. Il sera sollicit´e par les autres composants du SAA lorsqu’ils vou- dront avoir des propri´et´es, des fonctions ou autres informations du repr´esentant. Par exemple, le Wrapper fera appel `a lui pour l’obtention de la r´ef´erence Fractal des wrappers de deux ´el´ements lors de la construction d’une liaison ces deux ´el´ements.

Adaptabilit´e

L’adaptation du Parser permet au SAA de prendre en compte de nouveaux langages de description des besoins d’administration (´el´ements et programmes de re- configuration). On pourra par exemple prendre en compte l’ADL du syst`eme TUNe qui est bas´e sur les diagrammes de classe UML.

En ce qui concerne le Wrapper , son adaptation permet par exemple `a l’adminis- trateur d’exprimer un nouveau moyen d’encapsulation dans le SAA ou d’associer un comportement particulier `a un repr´esentant d’un ´el´ement administr´e. Pour illustrer le premier cas, prenons un exemple dans lequel l’administrateur d´esire encapsuler ses ´el´ements dans une base de donn´ees. Compte tenu du fait que nous adoptons Fractal Syst`eme d’administration autonome adaptable : application au Cloud

8.1. MOD `ELE D ´ETAILL ´E DE TUNEENGINE 89 comme la base de construction de wrappers dans le SAA (ce qui n’empˆeche l’utilisa- tion d’autres moyens), l’adaptation du Wrapper construira donc deux wrappers : un composant Fractal et une entr´ee dans la base de donn´ees. Associ´e `a cette adapta- tion du Wrapper , le composant SR devra ˆetre ´egalement adapt´e. En effet, il devra associer aux API d’introspection des composants Fractal (ce que permet Fractal) le moyen d’acc´eder aux informations concernant `a la fois le composant Fractal lui mˆeme (le wrapper de base), mais ´egalement l’entr´ee correspondant `a ce composant dans la base de donn´ees (nouvelle structure d’encapsulation). En somme, l’utilisation de Fractal dans notre mod`ele sert d’interfa¸cage lorsque que la m´ethode d’encapsulation est adapt´ee.

Quant au second cas (l’adaptation du Wrapper pour l’association d’un com- portement particulier `a un ´el´ement), il permet par exemple de reproduire le choix d’implantation du syst`eme TUNe dans lequel il associe aux supports d’ex´ecution (machines physiques), un comportement diff´erent de celui des ´el´ements logiciels. La seul diff´erence ici est le non cˆablage de cette diff´erence dans le SAA.

Pour finir, l’adaptation du SR permet, comme nous l’avons ´evoqu´e dans l’adap- tation du Wrapper , d’enrichir les API d’introspection de Fractal.

8.1.3

D´eploiement

Apr`es la repr´esentation interne des ´el´ements administr´es, la phase de d´eploiement marque le d´ebut du processus d’administration proprement dit. Il est assur´e par le composant Deployment Manager . Ce dernier r´ealise le d´eploiement en plusieurs phases internes `a savoir :

– le choix du support d’ex´ecution (SE) : r´ealis´e par le composant NodeAlloca- tor . Il d´etermine le lieu d’ex´ecution de l’´el´ement en cours de d´eploiement. Il se sert du SR afin d’avoir les informations sur les SE disponibles et retourne ensuite un ou plusieurs SE en fonction des besoins de l’´el´ement d´eploy´e. – initialisation du SE : `a l’aide d’un moyen (ssh, rsh, etc.) et des informations

(nom de connexion, mot de passe, etc.) de connexion fourni par le repr´esentant du SE dans le SR, le composant Deployer initialise le SE. Cette initialisation permet au SAA d’avoir acc`es et main mise sur le SE distant.

– L’obtention et l’installation des binaires : r´ealis´ees par le composant Binary Manager , il rend disponible les binaires et fichiers n´ecessaires pour l’ex´ecution de l’´el´ement d´eploy´e sur le SE distant (exemple de l’installation des packages sous Linux dans le r´epertoire /var/cache/apt/archives/ ). Il dispose ensuite les fichiers selon l’arborescence requise par l’installation de l’´el´ement en cours de d´eploiement (dans l’exemple des packages Linux, il s’agit du d´esarchivage des fichiers vers les r´epertoires requis).

A l’inverse, notons que les composants pr´ec´edemment pr´esent´es r´ealisent ´egalement l’op´eration de d´esinstallation. Le NodeAllocator lib`ere le SE apr`es son nettoyage par le Binary Manager .

8.1. MOD `ELE D ´ETAILL ´E DE TUNEENGINE 90 L’adaptation du NodeAllocator permet d’implanter plusieurs politiques d’al- location ou de lib´eration de SE dans le SAA. Par exemple, on pourra implanter l’allocation par tourniquet ou round-robin utilis´ee par le syst`eme TUNe.

Quant au Deployer , prenons l’exemple de l’administration des ´equipements r´eseaux comme les imprimantes. L’adaptation du Deployer permettra de ne pas d´eployer le repr´esentant du SAA sur l’´equipement r´eseau (car impossible) comme on le fera dans le cadre de l’administration d’une machine physique. Dans ce cas, le Deployer pourra par exemple se contenter d’un d´eploiement de ce repr´esentant sur la machine d’administration, qui fera par la suite un contrˆole distant selon le protocole de communication fourni par l’´equipement.

Pour finir, l’adaptation du Binary Manager permettra au SAA de prendre en compte diff´erentes m´ethodes d’obtention de binaires : par copie distant, par t´e- l´echargement web comme c’est le cas avec l’installation des syst`eme d’exploitation, etc.