Figure 5.4 – Principes de TUNe
chaque apparition d’un ´ev´enement dans l’environnement administr´e. Chaque ´etat de l’automate d´efinit une action `a ex´ecuter. Deux types d’actions sont possibles : la modification de param`etres et l’appel de fonctions d´ecrites lors du wrapping. En plus des fonctions de wrapping, TUNe met `a la disposition de l’administrateur deux fonc-tions particuli`eres pour l’ajout et le retrait d’instances logicielles de l’architecture.
Apr`es l’ex´ecution de ces fonctions, il assure la coh´erence entre : (1) les patterns ar-chitecturaux d´efinis auparavant par ADL, (2) la repr´esentation interne qu’il dispose (de l’environnement) et (3) l’environnement d’ex´ecution r´eelle (sur les machines).
En effet, l’ajout et le retrait d’instances modifient l’architecture courante de l’appli-cation.
Comme son pr´ed´ecesseur Jade, la description des programmes (cas de Jade) ou automates (cas de TUNe) de (re)configuration d´epend des logiciels administr´es et des ´ev´enements attendus par l’administrateur. Ainsi, le nombre de ces politiques d´epend des besoins de l’application administr´ee. Par contre, deux automates parti-culiers sont requis par TUNe pour l’administration de toute application : l’automate de d´emarrage et l’automate d’arrˆet des logiciels administr´es. La figure5.4montre un exemple d’automate d´ecrivant `a la fois la configuration et le d´emarrage des serveurs de l’application J2EE. On constate par exemple que les serveurs J2EE peuvent ˆetre configur´es parall`element alors que le d´emarrage par contre doit respecter un ordre (MySQL, MySQL-Proxy, Tomcat et enfin Apache).
De la mˆeme fa¸con qu’avec le WDL, la navigation `a travers l’architecture (par notation point´ee) est utilisable dans la d´efinition des actions.
5.3 Choix d’implantation
L’administration bas´ee composants fournit une couche d’abstraction pour un en-semble d’´el´ements mat´eriels ou logiciels. S’appuyant sur le mod`ele `a composants Fractal, TUNe construit une architecture `a composants interne repr´esentant
l’en-5.3. CHOIX D’IMPLANTATION 44 vironnement administr´e. Cette architecture est conforme `a la description par ADL faite de l’application par l’administrateur. Cette structure interne se nommeSyst`eme de Repr´esentation (SR) dans TUNe. Elle contient `a la fois les ´el´ements logiciels et mat´eriels. Chaque instance logicielle est encapsul´ee5 dans un composant Fractal. Ce dernier impl´emente les fonctions de base de l’administration `a savoir : le d´eploie-ment, le wrapping et l’ex´ecution `a distance de fonctions. Les interconnexions entre les instances sont repr´esent´ees par des liaisons (binding) bidirectionnelles entre les composants Fractal correspondants. Cette bidirectionnalit´e facilite la navigation par notation point´ee (navigation dans deux sens entre deux instances li´ees). Dans la fi-gure 5.5 les fl`eches bleues en pointill´e (de l’environnement d’´edition vers le syst`eme de repr´esentation) repr´esentent la relation d’encapsulation entre les types de logiciels et les composants Fractal. Notons que conform´ement `a la valeur de l’attribut ” ini-tial”, l’´el´ement Tomcat g´en`ere deux composants Fractal (deux instances du logiciel Tomcat).
Contrairement aux composants logiciels, les machines de chaque cluster ne sont pas repr´esent´ees par un seul composant Fractal. TUNe repr´esente le cluster par un composant Fractal. Ce composant impl´emente les fonctions d’allocation et de lib´e-ration de machines. Les liaisons d’h´eritage ne sont pas maintenues dans le SR. Le d´eploiement d’un logiciel dans le cluster entraˆıne une liaison Fractal entre le compo-sant logiciel repr´esentant ce logiciel et le compocompo-sant Fractal repr´esentant le cluster.
Cette liaison (composant logiciel-composant cluster ; fl`eches rouges sur la figure5.5) permet de r´ecup´erer les propri´et´es des machines h´ebergeant un logiciel.
Afin d’accomplir les tˆaches d’administration qui lui sont confi´ees, TUNe ex´ecute sur les machines distantes deux types de serveurs. Le premier serveur (Remote-Launcher) permet d’effectuer des actions g´en´erales non li´ees `a un logiciel particulier de l’application administr´ee. C’est notamment lui qui initialise la machine distante avant le d´eploiement des logiciels. Il d´emarre ´egalement, `a la demande de TUNe, les serveurs de second type. C’est (RemoteLauncher) le repr´esentant de TUNe sur la machine distante. Contrairement au premier (qui est unique sur la machine), TUNe associe `a chaque instance logicielle un repr´esentant (serveurs de second type) sur la machine distante. Ce serveur de second type (RemoteWrapper) est charg´e de l’ex´e-cution des op´erations d’administration li´ees `a l’instance logicielle `a laquelle il est associ´e. Il entre en action suite `a l’invocation d’une fonction de wrapping issue de l’ex´ecution d’un automate de reconfiguration. C’est `a lui que revient par exemple la charge d’ex´ecuter la fonction ”Apache.start” (de l’automate de d´emarrage de la figure5.4) sur une instance du serveur Apache. D’autre part, ce serveur joue le rˆole de communicant d’´ev´enements. C’est par son biais que les ´ev´enements rep´er´es par des logiciels de monitoring sont communiqu´es `a TUNe (mat´erialis´es par les fl`eches vertes de la figure 5.5).
Depuis sa mise en œuvre, cette conception de TUNe a fait l’objet de plusieurs 5. Contrairement `a sa signification habituelle dans la litt´erature (implantation compl`ete du comportement d’un logiciel), l’expression ”encapsuler un logiciel” dans ce document signifie : implanter les contrˆoleurs permettant de manipuler un logiciel existant (consid´er´e comme une boˆıte noire). Afin d’´eviter l’ambigu¨ıt´e avec le terme ”contrˆoleur” d´ej`a pr´esent dans les mod`eles `a composants, nous utilisons le terme ”encapsuler”.
Syst`eme d’administration autonome adaptable : application au Cloud
5.3. CHOIX D’IMPLANTATION 45
Figure 5.5 – Vue globale de TUNe
5.4. EXP ´ERIMENTATIONS ET PROBL ´EMATIQUES 46