Analyse et perspectives du passage `a grande ´echelle

Dans les sections pr´ec´edentes, nous avons pr´esent´e une impl´ementation de DREAMqui fournit la possibilit´e d’ex´ecuter des applications respectant l’API Agent A3. Nous avons d´emontr´e la faisabilit´e d’un intergiciel asynchrone adaptable avec notre mod`ele. Mais nous n’avons pas abord´e la notion de d´eploiement et de configuration distribu´ee `a grande ´echelle. En effet, le processus propos´e dans la section 5.6 n’a pas pu ˆetre mis en oeuvre par manque de temps. Et bien que les concepts propos´es soient tr`es prometteurs, ils nous semblent incomplets et m´eriteraient d’ˆetre plus approfondis.

Cette section tente donc de dresser une ´etude qualitative de notre proposition de processus. Nous abordons les points qui m´eriteraient d’ˆetre plus aboutis et nous proposons des pistes pour le futur.

6.6.1 Initialisation (bootstrap)

Dans notre proposition, nous partons d’une hypoth`ese simple qui est l’omnipr´esence des LA.

Ainsi, il est n´ecessaire que tous les sites qui veulent recevoir un«bout»d’intergiciel poss`edent un LA.

Minimalit´e Cette hypoth`ese peut paraˆıtre tr`es restrictive car elle impose la pr´esence d’un«bout de code»avant tout d´eploiement. Cela pose deux probl`emes :

1. Comment le LA est-t-il lui-mˆeme mis en place sur ce site ?

2. La complexit´e du processus rend le LA relativement coˆuteux en termes de place m´emoire et de temps processeur.

Le premier point est clairement un probl`eme r´ecurrent qui n’a pas de solution ´evidente et id´eale.

On pourrait, par exemple, imaginer qu’il y a un processus l´eger pr´esent comme service syst`eme qui permettrait de charger en m´emoire des LA. Mais se pose alors la question du d´eploiement des LA qui n´ecessiterait un processus de d´eploiement, etc. ! Il est ´evident que l’on peut toujours aller plus loin dans la minimalit´e des m´ecanismes pr´esents mais cela ne fait que reporter le probl`eme. C’est pourquoi nous pensons que notre solution `a base de LA sur chaque site est un bon compromis entre minimalit´e de service de d´eploiement (c’est-`a-dire un service permettant, au moins, d’instancier un

6 Des travaux sur la hi´erarchisation du nommage, en corr´elation avec les domaines de configuration, sont en cours d’´elaboration mais ne sont pas assez aboutis pour ˆetre expos´es ici.

6.6. ANALYSE ET PERSPECTIVES DU PASSAGE `A GRANDE ´ECHELLE 133 intergiciel localement) et support scalable de d´eploiement (c’est-`a-dire un service qui peut r´epondre aux probl`emes de grande ´echelle, de gestion de pannes, etc.).

Le deuxi`eme point soulev´e est le coˆut d’un tel processus sur les performances du site de d´eploiement. La r´eponse la plus simple `a cette question est qu’il n’est pas possible de fournir une solution qui soit `a la fois fiable, performante et«l´eg`ere». Il est donc n´ecessaire de faire un choix sur l’importance d’un processus de d´eploiement de l’intergiciel et ce choix doit ˆetre fait par l’administra-teur du syst`eme.

LA, domaines et connaissance globale L’initialisation des LA est r´ealis´ee avec l’hypoth`ese qu’ils se connaissent tous, c’est-`a-dire que chaque LA est capable d’envoyer un message `a n’importe quel LA. Il est ´evident que cette hypoth`ese nuit grandement `a la dynamicit´e du processus de d´eploiement.

Il est en effet impossible de rajouter un site, dans l’ensemble des sites d´ej`a pr´esents, qui n’aurait pas

´et´e pr´ealablement d´eclar´es.

La solution pourrait ˆetre d’utiliser les domaines comme groupes de sites dynamiques. Au lieu de d´ecouper arbitrairement les domaines comme c’est le cas actuellement, il serait plus pertinent d’utiliser la topologie du r´eseau en d´el´eguant la connaissance `a une tˆete de pont par exemple. Il serait int´eressant de r´ealiser ce d´ecoupage `a l’aide d’un algorithme automatis´e qui prendrait en param`etre la r´epartition g´eographique des sites ou les propri´et´es des sites par exemple. De la mˆeme mani`ere, le LA-maˆıtre est choisi de fac¸on arbitraire, il s’agit du premier LA rencontr´e dans la description globale.

Mais le choix du LA-maˆıtre pourrait tout `a fait ˆetre dict´e par des choix topologiques (architecture du r´eseau par exemple), physiques (puissance de la machine par exemple) ou logiques (en fonction des applications par exemple) et d´efinis par l’initiateur.

6.6.2 Liaisons

Dans notre processus, les liaisons sont d´ecrites dans un fichier MDL global d´efini (et donn´e) par l’initiateur. Cette description permet au LA maˆıtre de chaque domaine de connaˆıtre pr´ecis´ement quel site communique avec quel autre. L’information permet un meilleur traitement des pannes car il est possible de savoir quelles sont les liaisons manquantes en cas de probl`eme et laisse la d´ecision `a l’ini-tiateur de prendre une d´ecision (activation avec des liaisons partielles, activation locale de certains domaines, etc.). De plus, il est possible d’envoyer un ordre d’activation mˆeme si toutes les liaisons n’ont pas ´et´e r´ealis´ees, permettant une disponibilit´e rapide de l’intergiciel. Mais cette fonctionna-lit´e peut cr´eer des probl`emes de coh´erence de l’intergiciel, si une liaison est manquante alors que l’intergiciel en avait absolument besoin pour fonctionner correctement.

La description de configuration pourrait donc ˆetre ´etoff´ee d’une notion de liaisons requises,

c’est-`a-dire des liaisons qui sont indispensables au bon fonctionnement de l’intergiciel. Cette notion permet d’ajouter une sorte de connaissance s´emantique de l’intergiciel en imposant des liaisons qui sont s´emantiquement indispensables `a l’ex´ecution globale.

Liaisons complexes Une restriction qui serait int´eressante de lever est la liaison entre les diff´erents intergiciels. Actuellement, notre processus se limite `a l’utilisation du protocole TCP pour lier deux sites. Cela a l’avantage de simplifier la gestion des liaisons car il suffit de donner le port de connexion TCP auNetworkclient pour qu’il se lie auNetworkserveur.

L’utilisation de liaisons ´elabor´ees comme celles fournies par le canevas logiciel Jonathan [88]

permettrait de d´ecrire non seulement les liens entre les participants mais aussi le type de protocole de communication utilis´e. Par exemple, on pourrait signifier que la liaison entre deux sites est s´ecuris´ee par tel ou tel protocole. Cela est r´ealis´e dans les descriptions d’applications comme nous l’avons

vu dans le chapitre 3 et mis en oeuvre dans le d´eploiement applicatif de la soci´et´e Scalagent (voir section 2.3.2.1).

6.6.3 Gestion des pannes

Le processus de d´eploiement `a grande ´echelle est une tˆache complexe qui est sujette `a des pannes,

`a des sites d´econnect´es, des blocages, etc. Il est donc essentiel de pouvoir d´etecter les pannes et de pouvoir y r´eagir pour ´eviter un blocage total et complet de l’ensemble des sites. Dans cette section nous pr´esentons des d´ebuts de r´eponses `a la gestion des pannes en nous basant sur les travaux r´ealis´es par la soci´et´e Scalagent.

D´etection Dans le processus propos´e par Scalagent, la d´etection des pannes agit comme un contrˆole de workflow qui traite les ´eventuelles erreurs durant le processus de d´eploiement. Ces erreurs sont alors notifi´ees `a l’initiateur du d´eploiement.

Nous consid´erons qu’il existe deux pannes possibles. Soit une activit´e est bloqu´ee comme par exemple lorsqu’une cr´eation ne se r´ealise pas ou lorsqu’une liaison ne parvient pas `a son terme. Soit un LA tombe en panne, parce que son site d’ex´ecution a subi une panne fatale par exemple.

Il existe deux possibilit´es de d´etection de pannes. La premi`ere consiste `a borner le temps d’ex´ecution d’une activit´e et `a d´eclencher des erreurs lorsque le temps s’est ´ecoul´e. Il est ´evident que cette solution n’est pas viable dans le cadre de d´eploiement `a tr`es grande ´echelle. Le nombre d’activit´es `a surveiller, les temps de latence des r´eseaux, la coh´erence du bornage, etc. autant de param`etres qui rendent cette solution non applicable `a grande ´echelle.

Une autre solution consiste `a se baser sur une strat´egie optimiste. Elle consiste `a ne pas remonter de messages d’erreur mais `a agr´eger et `a remonter les ´ev´enements d’observation permettant d’avoir, au niveau de l’initiateur, une connaissance d´etaill´ee de l’´etat du d´eploiement. Cette connaissance peut ˆetre utilis´ee par l’initiateur pour traiter ces pannes.

Traitement des pannes Le traitement des pannes par l’initiateur consiste `a r´ealiser des reconfigura-tions de la configuration d’intergiciels d´eploy´ee. L’initiateur peut prendre la d´ecision d’arrˆeter certains groupes de sites afin de leur envoyer une nouvelle configuration. De plus, les possibilit´es de reconfi-guration partielle de DREAMpermettraient de mettre `a jour le MOM sans pour autant empˆecher les services de s’ex´ecuter. La possibilit´e d’activation des sites avant configuration compl`ete favorise la disponibilit´e des services.

Perspectives Nous pensons que la configuration et le d´eploiement `a grande ´echelle doit se tourner vers une hi´erarchisation, non seulement des m´ecanismes comme c’est le cas dans notre solution, mais aussi de« l’intelligence ». Ainsi, il serait plus rapide et plus efficace que les LA-maˆıtres de domaine prennent des d´ecisions de reconfiguration sans pour autant faire n´ecessairement remonter des informations et attendre une d´ecision « d’en haut ». N´eanmoins, de nombreux probl`emes se posent quant `a la reconfiguration des sites, car un changement sur un site peut avoir des cons´equences tout un ensemble de sites et les d´ecisions locales peuvent se r´ev´eler catastrophiques pour l’ensemble des sites. Cette hi´erarchisation de l’intelligence de traitement nous semble donc une des grandes voies

`a suivre dans la continuit´e de ce travail.

Conclusion