Adaptable

6.1.2.1 Adaptation des comportements

Comme tout logiciel informatique, le projet de d´eveloppement d’un SAA met en relation deux acteurs : (1) les utilisateurs (qui sont les administrateurs dans notre contexte) et (2) l’´equipe de d´eveloppement. Dans la plupart des cas, ces deux ac- teurs sont s´epar´es et ne poss`edent pas les mˆemes comp´etences. Le premier poss`ede des comp´etences sur l’application `a administrer tandis que le second maˆıtrise les techniques de d´eveloppement des SAA. Sur cette base, nous d´efinissons l’adapta- bilit´e des comportements d’un SAA comme sa capacit´e `a ˆetre modifiable par les utilisateurs de type (1) sans l’intervention des utilisateurs de type (2), dans le but d’adresser plusieurs domaines applicatifs. Autrement dit, l’adaptabilit´e des compor- tement du SAA permettra au SAA d’ˆetre g´en´erique. L’adaptabilit´e est une solution parmi plusieurs qui permettent de construire un SAA g´en´erique. La question qui peut ˆetre pos´ee est celle de savoir ”pourquoi notre choix s’est-il port´e sur l’adapta- bilit´e du SAA comme r´eponse `a la g´en´ericit´e”?

Une solution de g´en´ericit´e consiste `a fournir des API de bas niveaux utilisables par les administrateurs pour l’implantation de la prise en compte de nouveaux be- soins. Cette solution est fournie par le syst`eme Jade [26] qui propose les API Fractal. Cette solution s’adresse aux administrateurs avertis, ce qui limite son utilisation ´elar- gie.

La r´eponse aux limites de la solution pr´ec´edente est la fourniture des outils de niveaux d’abstraction proches des administrateurs. Cette solution limite la g´en´eri- cit´e du SAA et entraˆıne la construction de SAA par domaine applicatif sp´ecifique. C’est le cas du syst`eme TUNe qui se limite aux applications clusters de type maˆıtre- esclave.

La derni`ere solution allie la fourniture d’un niveau d’abstraction ´elev´e `a la g´e- n´ericit´e du SAA. Elle repose d’une part sur l’adaptabilit´e du SAA (la modification, l’ajout et le remplacement des services du SAA sans avoir une expertise compl`ete sur son d´eveloppement) et la fourniture des outils d’expressions de besoins d’administra- tion (voir la section 5.5 du chapitre 5). Comme nous le verrons dans la section6.2, cette derni`ere solution implique une architecture `a composants du SAA. Elle est celle pour laquelle nous optons et dont nous justifions son utilit´e dans le SAA en montrant comment elle permettrait au syst`eme TUNe de r´esoudre une partie de ses probl`emes.

Durant nos exp´erimentations avec le syst`eme TUNe (sections 5.4), nous nous sommes heurt´es `a plusieurs probl`emes n´ecessitant son adaptation. Il s’agit des pro- bl`emes : 1.2, 2.2, 2.3, 3.3, 3.4, 3.5, 3.6 et 3.7. A pr´esent, montrons dans quelles mesures l’adaptabilit´e de TUNe lui aurait permis de r´esoudre ces probl`emes. Ces derniers requi`erent deux types d’adaptation : modification/remplacement de com- portements (probl`emes 1.2, 2.2, 3.3) et ajout de nouveaux comportements (probl`emes 2.3, 3.4, 3.5, 3.6 et 3.7).

6.1. CARACT ´ERISTIQUES 58 (probl`eme 1.2) ou le d´eploiement des VM dans les syst`emes virtualis´es et cloud (pro- bl`emes 2.2 et 3.3), le remplacement de la fonction de d´eploiement de base de TUNe permet de prendre en compte les particularit´es de ces applications. Par exemple, le SAA peut ˆetre fourni avec une fonction basique de d´eploiement et permettre `a chaque administrateur de fournir la m´ethode (par surcharge ou red´efinition de m´e- thodes) qui lui est propre en cas de besoin. Ainsi, concernant l’administration des VM, l’administrateur pourra fournir au SAA une m´ethode de d´eploiement incluant les t´el´echargements de binaires via internet, des copies via des serveurs NFS, etc.

Une autre situation n´ecessitant une adaptation par modification comportemen- tale s’observe dans TUNe. Elle concerne le moyen d’ex´ecution de fonction d’admi- nistration `a distance. Par exemple, le syst`eme TUNe utilise un protocole fig´e (RMI) ainsi que des moyens d’introspection et r´eflexion Java pour l’ex´ecution de m´ethodes `

a distance. Ainsi, l’utilisation de TUNe n´ecessite la pr´esence d’une machine virtuelle Java sur toutes les machines ex´ecutant les ´el´ements administr´es. L’utilisation d’un protocole comme ssh en remplacement RMI dans un environnement non Java est impossible.

6.1.2.2 Extensibilit´e

Ne pouvant pr´edire toutes les op´erations r´ealisables dans toute administration, l’adaptabilit´e du SAA doit le pr´edisposer `a int´egrer de nouveaux modules permettant par exemple de prendre en compte de nouveaux op´erateurs (probl`emes 2.3 et 3.7) ou de nouveaux besoins comme l’extension de l’environnement (probl`emes 3.4, 3.5 et 3.6). La prise en compte de l’op´eration de migration dans les environnements virtualis´es se traduit par l’int´egration d’un nouvel op´erateur move, tel que nous l’avons pr´esent´e dans les sections 5.4.3 et 5.4.4. Ce qui permettra de r´ealiser des politiques de r´econfiguration bas´ees sur la migration dans l’administration de l’IaaS. Quant aux probl`emes 3.4, 3.5 et 3.6, ils font ressortir trois types d’extensions de l’administration n´ecessitant l’adaptation du SAA :

– l’extension de l’environnement mat´eriel (probl`eme 3.4) : Ce probl`eme est no- tamment rencontr´e dans les SAA tels que Jade [26], TUNe [29], ADAGE [68], SmartFrog [57], ORYA[43] ou Kadeploy [kad]. En effet, ils exigent que la liste des supports d’ex´ecution (machines) soit d´efinie avant leur d´emarrage. De ce fait, les SE restent fig´es pendant l’ex´ecution enti`ere du SAA. Un module per- mettant leur extension dynamique permettrait de faire ´evoluer cet environne- ment.

– l’extension de l’environnement logiciel (probl`eme 3.5) : En ce qui concerne l’extension de l’environnement logiciel, nous distinguons deux types d’exten- sions. La premi`ere est celle qu’offre le syst`eme TUNe, c-`a-d l’ajout/retrait d’instances de logiciels dont la description ´etait connue de TUNe au d´emar- rage. Elle permet par exemple de r´ealiser la scalabilit´e des applications J2EE. La deuxi`eme est l’ajout de nouveaux logiciels non existant initialement dans TUNe. La modification du comportement de TUNe aurait permis de prendre en compte ce type d’extension. Ce probl`eme se pose une fois de plus dans les applications J2EE. Prenons par exemple une application J2EE ne dispo- Syst`eme d’administration autonome adaptable : application au Cloud

6.1. CARACT ´ERISTIQUES 59 sant pas initialement de distributeur de charges devant le serveur web Apache (Ha-Proxy [hap] par exemple). Apr`es constatation de l’incapacit´e d’un unique serveur web `a r´epondre `a toutes les requˆetes, l’administrateur peut d´ecider d’introduire en cours de route d’autres instances afin de partager les charges. Pour cela, il doit ajouter dans l’architecture initiale un nouveau logiciel (Ha- proxy), inexistant initialement, pour la distribution de charges aux diff´erentes instances d’Apache.

– l’extension des politiques de reconfiguration (probl`eme 3.4) : Comme nous l’avons pr´esent´e dans la section5.4.4, il s’agit de la facult´e du SAA `a int´egrer de nouvelles politiques d’administration pendant son ex´ecution.