Gestion de données dans les NES

Gestion de donn´ ees dans les NES

E. Caron, F. Desprez, A. Vernois B. Del-Fabbro

LIP/ENS-Lyon LIFC

{Eddy.Caron,Frederic.Desprez}@ens-lyon.fr [email protected] [email protected]

1 Introduction

Les probl`emes de tr`es grande taille issus de la simulation num´erique peuvent d´esormais ˆetre r´esolus via Internet grˆace aux environnements de type Grilles [6]. De nombreuses approches coexistent qui ont chacune leurs avantages et leurs inconv´enients. Par ailleurs, l’approche ASP (Application Service Provider) permet d’acc´eder `a des applications `a distance grˆace `a des intergiciels adapt´es. Dans ce paradigme, un client peut demander l’ex´ecution de requˆetes `a un agent charg´e de trouver le serveur le plus adapt´e en terme de performance ou de fonctionnalit´e. Les requˆetes peuvent alors ˆetre ex´ecut´ees par des serveurs s´equentiels ou parall`eles. Ce paradigme est proche du mod`ele RPC (Remote Procedure Call ou appel de proc´edure `a distance). L’approche GridRPC [8] est la forme “grille” du RPC Unix classique. On appelle g´en´eralement ces environnements qui les r´ealisent des serveurs de calculs ou NES (Network Enabled Servers). Plusieurs outils offrant cette fonctionnalit´e comme NetSolve<sup>1</sup>, NINF<sup>2</sup>, DIET<sup>3</sup>, NEOS<sup>4</sup>, ou RCS [2] sont d´ej`a disponibles.

Le GridRPC implique que les donn´ees sont envoy´ees du client vers le serveur qui r´ealise le calcul et le r´esultat revient du serveur vers le client. Si des d´ependances existent entre les requˆetes, des transferts de donn´ees inutiles sont effectu´es et ce coˆut prohibitif diminue l’int´erˆet d’une telle approche. Il convient donc de g´erer au mieux ces d´ependances en laissant tant que possible les donn´ees sur les serveurs sur lesquels elles ont ´et´e utilis´ees (ou calcul´ees). Ceci n´ecessite une gestion de donn´ees efficace et surtout extensible vu le nombre de serveurs et de clients g´en´eralement trait´es par ce type d’environnement. Cet article pr´esente donc l’architecture de plusieurs NES (NetSolve, Ninf et DIET) ainsi que les probl`emes de gestion de donn´ees qui leurs sont propres.

Dans une premi`ere section, nous pr´esentons l’API GridRPC propos´ee dans le cadre du Global Grid Forum pour permettre de g´erer la persistance des donn´ees au niveau du client. Dans une seconde section, nous pr´esentons l’architecture des trois environnements de type NES disponibles actuellement et qui impl´ementent le standard GridRPC. Enfin, dans la troisi`eme section et avant une conclusion et une description de nos travaux futurs, nous pr´esentons les solutions choisies par Ninf, NetSolve et DIET pour g´erer les donn´ees.

2 L’approche GRID-RPC et la gestion de la persistance

Dans le cadre du Global Grid Forum, les chercheurs des projets NetSolve, Ninf et DIET ont propos´e une interface standard pour l’API client. Cette API permettra d’avoir une bonne portabilit´e entre les diff´erents syst`emes. Nous allons nous focaliser sur la partie “gestion de donn´ees” de cette interface qui est en cours de discussion au sein du GGF. L’interface g´en´erale pour les demandes d’ex´ecution de requˆetes peut ˆetre trouv´ee sur le site du GGF. Un aspect naturellement important de la d´efinition d’une telle interface est la d´efinition

1http://www.cs.utk.edu/netsolve/

2http://ninf.etl.go.jp/

3http://graal.ens-lyon.fr/DIET

4http://www-neos.mcs.anl.gov/

de la possibilit´e de laisser les donn´ees calcul´ees sur les serveurs afin de r´eduire le coˆut des communications.

Il va de soit que ceci doit ˆetre le plus transparent possible pour les clients finaux mais un ordonnanceur

“intelligent” devra ˆetre capable de dire au syst`eme si telle donn´ee doit ˆetre laiss´ee ou pas sur tel ou tel serveur en fonction des d´ependances entre les requˆetes.

Cette proposition part du postulat que chaque donn´ee doit ˆetre identifi´ee au sein de la plate-forme. Nous d´efinissons donc le data handle (DH) comme ´etant une r´ef´erence `a une donn´ee qui peut ˆetre stock´ee `a n’importe quel endroit. Ainsi, cette d´efinition du data handlepermet de g´erer la lecture et l’´ecriture des donn´ees sans avoir `a se pr´eoccuper d’o`u elles proviennent ni d’o`u elles seront stock´ees. L’op´eration de cr´eation dudata handleest r´ealis´ee par la fonctioncreate(data handle t *dh) ;

Une fois que la r´ef´erence `a la donn´ee est cr´e´ee, il est possible de lier ou pas cette r´ef´erence `a une donn´ee.

Si on lie la donn´ee, elle peut ˆetre soit pr´esente chez le client, soit pr´esente sur un serveur de d´epˆot. Sinon cela signifie que la donn´ee est d´ej`a pr´esente dans la plate-forme. L’op´eration de liaison d’une donn´ee `a une r´ef´erence permet aussi de pr´eciser si la donn´ee doit ˆetre conserv´ee ou non. Cette op´eration est r´ealis´ee par la fonctionbind(data handle t dh, data loc t loc, data site t site) ;

– data loc t loc: permet de connaˆıtre la localisation de la donn´ee (machine locale ou serveur de d´epˆot), – data site t site : la localisation de la machine o`u l’on veut stocker la donn´ee, sachant que si cette

valeur est nulle la donn´ee sera stock´ee sur le dernier serveur d’ex´ecution l’ayant utilis´e.

Ainsi, du cot´e du serveur de calcul, si ledata handlecontient unsiteidentique auloc, la donn´ee doit ˆetre retourn´ee au client ou au serveur de stockage r´ef´erenc´e. En revanche, si le data handle contient un site diff´erent duloc, la donn´ee sera d´eplac´ee du locvers le site r´ef´erenc´e par site.

La Figure 1 montre un exemple d’utilisation de l’interface de gestion de donn´ees dans l’API GridRPC.

Dans cette figure, un client ex´ecute un premier calcul sur un serveur capable d’ex´ecuter le service demand´e et un second calcul sur un autre serveur plus performant. Pour ce second calcul, le client n’a pas `a renvoyer sa donn´ee puisqu’elle se trouve d´ej`a sur le r´eseau.

Note : output_DH is unbound call(input_DH, output_DH)

return bound output_DH

call(output_DH, output2_DH)

read output_DH data sent

data sent

write data on output2_DH read input_DH

(output data still available on this server)

CLIENT SERVICE A SERVICE B

bind input_DH to input data bind input_DH to input data

create input data create input_DH create output_DH

EXECUTE SERVICE bind out. data to output_DH

create output2_DH bind output2_DH to client

EXECUTE SERVICE create output data

Fig.1 – Exemple d’utilisation de l’API GridRPC avec gestion de donn´ees int´egr´ee.

3 Architecture de trois environnements de type NES

3.1 Ninf et NetSolve

NetSolve est un NES d´evelopp´e au laboratoire ICL de l’Universit´e du Tennessee. Ninf quant `a lui est d´evelopp´e au Tokyo Institute of Technology. Ces deux NES sont tr`es similaires dans leur conception. Ils sont

bas´es tous deux sur trois composants principaux : les clients, l’agent et les serveurs de calcul.

Clients : Ils sont construits en utilisant des biblioth`eques qui offrent une API (bas´ee sur le GridRPC) permettant d’acc´eder aux ressources de calculs g´er´ees par l’agent. Actuellement, il est possible d’interfacer NetSolve dans du code C, FORTRAN, Matlab et Mathematica et Ninf avec du C, du FORTRAN et du Java.

Agent :Composant central qui maintient `a jour les informations concernant les serveurs, leurs possibilit´es ainsi que les statistiques d’utilisation. C’est lui qui re¸coit les requˆetes des clients et alloue au mieux les ressources de calcul des serveurs `a ces requˆetes pour que celles-ci soient ex´ecut´ees le plus rapidement possible.

Serveurs :Les serveurs de calcul sont la puissance de traitement de NetSolve ou de Ninf. Ils sont g´er´es par l’agent et sont en mesure de r´esoudre un certain nombre de probl`emes. La liste des probl`emes qu’un serveur sait r´esoudre est maintenue par l’agent.

Les communications entre les composants se font via un protocole de communication sp´ecifique au niveau applicatif construit au dessus de TCP/IP.

3.2 DIET

Client

MA

MA MA

MA

LA LA

LA LA LA LA

MA

MA

000000 000000 111111 111111 000000 111111 000000 111111

000000 000000 111111 111111 000000 111111 000000 111111

000000 000000 111111 111111 000000 111111 000000 111111 000000 000000 111111 111111 000000 111111 000000 111111

00 00 00 00 0

11 11 11 11 1

00 00 00 00 0

11 11 11 11 1

00 00 00 00 0

11 11 11 11 0 1 00 00 00 00

11 11 11 11 1

Fig. 2 – Vue g´en´erale de DIET.

Dans cette section, nous donnons des d´etails sur l’architecture de DIET et nous pr´esentons les diff´erents composants impliqu´es dans sa hi´erarchie. Dans [8], les au- teurs donnent un ´etat de l’art des environnements bas´es sur des NES qui permettent d’acc´eder `a des serveurs de calcul via le r´eseau. Si l’on rentre dans les d´etails, de tels environnements sont compos´es de cinq types de composants diff´erents : lesclientsqui soumettent les probl`emes aux serveurs, lesserveursqui r´esolvent les probl`emes soumis par les clients, desmoniteursqui r´ecup`erent des informations sur l’´etat des ressources de calcul et les stockent dans unebase de donn´eesqui contient aussi des informations concernant les ressources mat´erielles et logicielles, et enfin unordonnanceur(appel´e agentdans notre architecture) qui choisit un serveur appropri´e en fonction du probl`eme soumis et des informations contenues dans la base de donn´ees.

Les projets NetSolve ou Ninf suivent cette approche. Malheureusement, il n’est possible de lancer qu’un seul agent charg´e de l’ordonnancement pour un groupe de serveurs de calculs donn´es ⁵. Cela cr´ee un goulot d’´etranglement des performances empˆechant le d´eploiement de NetSolve pour de grands groupes de serveurs, et rend le syst`eme peu r´esistant aux erreurs. En effet, la mort du processus agent rend inutilisable la plate-forme toute enti`ere.

Pour r´esoudre ces probl`emes, DIET se propose de r´epartir le travail de l’agent selon une nouvelle organisation. Il est ainsi remplac´e par un ensemble d’agents organis´es selon deux approches : une approche multi-agents de type pair-`a-pair am´eliorant la robustesse du syst`eme associ´e et une approche hi´erarchique favorisant l’efficacit´e de l’ordonnancement. Cette r´epartition du rˆole de l’agent offre divers avantages. Tout d’abord, on a une meilleure r´epartition de la charge entre les diff´erents agents et une plus grande stabilit´e du syst`eme (si un des ´el´ements venait `a s’arrˆeter, les autres ´el´ements pourraient se r´eorganiser pour le remplacer). Enfin, on obtient ´egalement une gestion simplifi´ee en cas de passage `a l’´echelle (l’administration de chaque groupe de serveurs et des agents associ´es peut ˆetre d´el´egu´ee).

3.2.1 Les composants de DIET

Unclient est une application qui utilise DIET pour r´esoudre des probl`emes. Plusieurs types de clients doivent ˆetre capables de se connecter `a DIET. Un probl`eme peut ˆetre soumis depuis une page web, un environnement de r´esolution de probl`emes tel que Scilab [4] ou Matlab ou depuis un programme compil´e.

Un Master Agent (MA) MA est directement reli´e aux clients. Il re¸coit des requˆetes de calcul des clients et choisit un (ou plusieurs) SeDs qui sont capables de r´esoudre le probl`eme en un temps raisonnable.

Un MA poss`ede les mˆemes informations qu’un LA, mais il a une vue globale (et de haut niveau) de tous les probl`emes qui peuvent ˆetre r´esolus et de toutes les donn´ees qui sont distribu´ees dans tous ses sous-arbres.

5A part pour une version de Ninf qui poss`ede plusieurs agents (Metaserver) mais ceux-ci ont une connaissance globale de tout l’environnement grˆace `a des diffusions des informations.

Un Leader Agent (LA)LA compose un niveau hi´erarchique dans les agents DIET. Il peut ˆetre le lien entre un Master Agent et un SeD, entre un autre LA et un SeD ou entre deux LAs. Son but est de diffuser les requˆetes et les informations entre les MAs et les SeDs. Il tient `a jour une liste des requˆetes en cours de traitement et, pour chacun de ses sous-arbres, le nombre de serveurs pouvant r´esoudre un probl`eme donn´e, ainsi que des informations `a propos des donn´ees.

UnServer Daemon (SeD)est le point d’entr´ee d’un serveur de calcul. Il se trouve sous la responsabilit´e d’un LA. Il tient `a jour une liste des donn´ees disponibles sur un serveur (´eventuellement avec leur distribution et le moyen d’y acc´eder), une liste des probl`emes qui peuvent y ˆetre r´esolus, et toutes les informations concernant sa charge. Sur une machine parall`ele, un SeD sera donc install´e sur le frontal de cette machine.

La plate-forme cible actuelle de DIET est le r´eseau rapide connectant les grappes et les machines parall`eles des diff´erentes unit´es de recherche de l’INRIA (projet RNRT VTHD<sup>6</sup>). Cette architecture est donc fortement hi´erarchique puisque le r´eseau VTHD connecte les UR INRIA entre elles, qui elles-mˆemes poss`edent dans leurs r´eseaux propres des grappes de machines connect´ees par des r´eseaux plus ou moins rapides. Les machines d’o`u sont lanc´ees les calculs sont soit directement connect´ees au r´eseau VTHD ou simplement connect´ees par les r´eseaux internes des laboratoires ayant acc`es `a cette plate-forme.

3.2.2 Mode de fonctionnement

Un nouveau client de DIET doit d’abord contacter un Master Agent (le plus appropri´e : en distance r´eseau par exemple) et lui soumettre un probl`eme. Pour choisir le serveur le plus appropri´e pour r´esoudre ce probl`eme, le Master Agent propage une requˆete dans ses sous-arbres⁷ afin de trouver `a la fois les donn´ees impliqu´ees (parfois issues de calculs pr´ec´edents et donc d´ej`a pr´esentes sur certains serveurs lorsque la per- sistance est activ´ee) et les serveurs capables de r´esoudre l’op´eration demand´ee. Lorsque la requˆete arrive au niveau des LAs, ces derniers interrogent les SeD capables de r´esoudre le probl`eme afin de r´ecup´erer l’´evaluation des temps de calcul et de communication via notre outil de pr´ediction de performance FAST [9].

Si le serveur, dispose d’une donn´ee utile au calcul il en informe ´egalement le LA.

Les choix d’ordonnancement se font alors `a chaque niveau de l’arbre lors de la remont´ee de la r´eponse au MA. Lors de cette remont´ee, notons que les agents attendent les r´eponses de leurs fils pendant un certain laps de temps au del`a duquel elles sont ignor´ees. Cet ´etat de fait ne permet pas de tirer des cons´equences quant `a une panne ´eventuelle d’un agent qui ne r´epond pas ou pas assez vite.

Lorsque la r´eponse revient au Master Agent, il renvoie l’adresse du serveur choisi au client (il est ´egalement possible de renvoyer une liste born´ee des meilleurs serveurs au client). Le MA envoie ensuite l’ordre de migrer les donn´ees. Le transfert des donn´ees s’effectue alors en deux phases pouvant ˆetre ex´ecut´ees en parall`ele : transfert des donn´ees issues du client et ´eventuellement le transfert des donn´ees persistantes localis´ees sur un autre serveur. Une fois les donn´ees r´ecup´er´ees la r´esolution du calcul peut ˆetre effectu´ee. Les r´esultats pourront ˆetre renvoy´es au client. Pour des questions de performances, DIET essaye autant que possible de laisser les donn´ees sur place.

4 Gestion de donn´ ees dans les NES

4.1 NetSolve et Ninf

Plusieurs approches ont ´et´e utilis´ees pour la gestion de donn´ees dans NetSolve. Dans un premier temps, en collaboration avec E. Jeannot, nous avons int´egr´e un certain nombre de fonctions permettant de laisser les donn´ees sur place puis de les d´eplacer [7]. Ces fonctions, appelables depuis le client permettaient d’envoyer une ou plusieurs donn´ees depuis un serveur vers un client ou de redistribuer les donn´ees entre des serveurs s´equentiels. Dans le cas d’une s´equence de requˆetes [3] (comprises entre deux appels de fonctions sp´eciales), les donn´ees en entr´ees seront toutes envoy´ees au serveur qui effectuera la premi`ere requˆete. Ensuite, ne seront

6http ://www.vthd.org

7Une extension dans le cadre du multi-MA est possible en diffusant les requˆetes de calcul aux autres MAs et en les traitant comme des LAs

transf´er´ees aux serveurs qui auront la charge des requˆetes suivantes, que les donn´ees dont ils auront besoin, sans repasser par le client. Cette technique permet d’´eviter des transferts redondant d’une mˆeme donn´ee entre le client et le syst`eme. Dans la mˆeme optique, l’utilisateur pourra pr´eciser que certaines donn´ees de sortie des requˆetes ne sont que des donn´ees interm´ediaires. Dans ce cas, celles-ci ne seront pas rapatri´ees sur le client en fin de s´equence.

Dans une derni`ere version de NetSolve, les donn´ees utilis´ees peuvent soit ˆetre locales au client (sur disque ou en m´emoire), soit ˆetre pr´esentes dans une infrastructure de stockage distribu´e (Distributed Storage Infrastructure ou DSI). Pour pouvoir ˆetre utilis´ee dans NetSolve, une donn´ee pr´esente dans une DSI aura dˆu y ˆetre ins´er´ee via l’API fournie. Cette API est pr´evue pour pouvoir acc´eder `a diff´erents DSI de la mˆeme fa¸con, mˆeme si, actuellement, seul IBP (Internet Backplane Protocol ou IBP) est support´e. Pour une donn´ee DSI, c’est `a l’utilisateur (client) qu’incombe la tˆache de connaˆıtre et choisir le serveur qui va h´eberger sa donn´ee. Dans tous les cas, la localit´e des donn´ees n’est pas prise en compte dans le choix du serveur qui ex´ecutera la requˆete. NetSolve maintient une table d’allocation des fichiers qui recense le statut de tous les fichiers pr´esents dans les DSI, ce qui impose l’utilisation de l’API NetSolve pour g´erer les donn´ees distantes.

Lors de la r´eception d’une requˆete, le serveur NetSolve r´ecup`ere les informations concernant les donn´ees en entr´ees et regarde dans sa table d’allocation s’il y est fait r´ef´erence. Si c’est le cas, alors il s’agit d’une donn´ee pr´esente dans un DSI, sinon, la donn´ee est suppos´ee locale au client et devra ˆetre r´ecup´er´ee par le serveur en charge de l’ex´ecution de la requˆete. Ninf ne poss`ede pas de m´ecanisme sophistiqu´e de gestion de donn´ees.

Il utilise juste une technique de gestion des s´equences de requˆetes comme NetSolve.

4.2 L’approche DIET

La gestion des donn´ees dans DIET a ´et´e pens´ee de mani`ere modulaire. Cette particularit´e permet d’envi- sager de connecter plusieurs types de syst`emes de gestion de donn´ees. Dans cette section nous allons d´ecrire deux infrastructures ayant des fonctionnalit´es compl´ementaires et pouvant ˆetre utilis´ees dans une mˆeme plate-forme. Le DTM (Data Tree Manager) pour une gestion des donn´ees adapt´ee `a l’architecture de DIET et JUXMEM pour une gestion de donn´ees de tr`es grande taille.

4.2.1 Gestion des donn´ees dans un environnement hi´erarchique : DTM

L’id´ee de g´erer des donn´ees sur une plate-forme hi´erarchique est soumise `a deux contraintes fortes. ˆEtre capable de d´efinir quelles sont les donn´ees que l’on veut conserver dans la plate-forme, et ˆetre capable d’identifier de mani`ere unique cette donn´ee en son sein. Nous avons donc d´efini le mode de persistance et l’identifiantde la donn´ee.

Le mode de persistance Afin de rendre la plate-forme persistante, il a ´et´e d´efini une API cliente per- mettant au client de soumettre les donn´ees avec certaines caract´eristiques. Lors de la premi`ere ´emission de la donn´ee, le client (ou unproxy “intelligent”) fournit la donn´ee, son rˆole (in, in out, out) au sein de l’in- frastructure ainsi que son mode (volatile, sticky, sticky return pour la session courante etpersistent, persistent return valide entre session).

– Une donn´eevolatile ne sera pas conserv´ee sur le serveur apr`es son utilisation, elle sera d´etruite, – Une donn´eesticky est conserv´ee sur le serveur mais non d´epla¸cable. Ce mode est utile dans le cas de

donn´ees de tr`es grande taille pour lesquelles le coˆut de d´eplacement est trop p´enalisant,

– Une donn´eesticky return est une donn´eesticky pour laquelle l’utilisateur d´esire obtenir une copie, – Une donn´eepersistentest conserv´ee dans l’infrastructure pendant une session ou `a travers plusieurs

sessions, elle est d´epla¸cable et susceptible d’ˆetre copi´ee,

– Une donn´ee persistent return est une donn´eepersistent pour laquelle l’utilisateur d´esire obtenir une copie (c’est le mode le plus adapt´e pour les donn´eesin out).

La gestion de la persistance que nous proposons est `a mettre en corr´elation avec la proposition de standard faite dans le cadre du GridRPC Working Group du GGF. NotreDTM g`ere de mani`ere explicite le mode de persistance des donn´ees alors qu’il est implicitement d´etermin´e dans l’API GridRPC propos´ee. Cette diff´erence s’explique par la standardisation et le fait que les autres plates-formesNinf, NetSolvene g`erent

pas explicitement ce mode. Cependant, `a partir de la d´efinition et de l’utilisation des fonctions de l’API, nous constatons une relation directe avec le GridRPC. En effet, les modesvolatile, sticky, sticky return persistent, persistent returnsont g´er´es par l’utilisation de la m´ethodebind().

Architecture L’id´ee est donc que l’architecture DIET puisse conserver les donn´ees ´eventuellement r´eutilisables et les d´eplacer d’un serveur `a un autre suivant les besoins de calcul. De plus, afin de ne pas alourdir la gestion des calculs en entrela¸cant des messages li´es aux calculs et des messages li´es `a la gestion des donn´ees, le choix a ´et´e fait de dissocier la partie calcul de la partie gestion des donn´ees en agr´egeant deux objets : leDataManageret leLocManagerrespectivement li´es aux SeD et LA/MA, comme pr´esent´e figure 3.

LocMgr1

Cli1

LA1 LocMgr2

LA2 LocMgr3

SeD1 SeD2 SeD3

F() F()

A B

idA, DataMgr1

idB, LocMgr2 idA, LocMgr2

idB, DataMgr2

DataMgr1

MA

DataMgr2 DataMgr3

F(B,C)=D

Fig.3 – Les ObjetsDataManager et LocManager

La structure des objetsLocManager (respectivement Data- Manager) est initialis´ee parall`element `a celle des objets LA et MA (respectivement des SeD). Les fonctionnalit´es des objetsDataMa- nageret LocManagersont les suivantes :

L’objet LocManager est situ´e sur chaque agent avec le- quel il communique localement. L’objet LocManager g`ere une liste de r´ef´erences aux donn´ees pr´esentes dans sa branche (couple identifiant donn´ee/possesseur). Sur l’exemple pr´esent´e en Figure 3, l’objet LocMgr2 poss`ede les couples ((idA,DataMrg1),(idB,DataMrg2)) et l’objet LocMgr1 poss`ede les couples((idA,LocMrg2),(idB,LocMgr2)). Ainsi, la hi´erarchie des objets LocManagerpermet de connaˆıtre la locali- sation d’une donn´ee. Les objetsDataManagerayant uniquement la connaissance des donn´ees qu’ils poss`edent localement.

L’objet DataManagerest situ´e sur chaque SeD avec lequel il communique localement. Il contient la liste des donn´ees de mode sticky, sticky return, persistent ou persistent return. Il est par ailleurs charg´e des op´erations de d´eplacement ou de copie de donn´ees et ´egalement de fournir les donn´ees n´ecessaires au ser-

veur pour ses calculs. Enfin, il informe son objetLocManager p`ere, de mises `a jour (ajout, suppression) concernant sa liste de donn´ees. La mise `a jour des branches concern´ees au sein de l’architecture se faisant hi´erarchiquement. Qui plus est, afin de g´erer simplement, dans un premier temps, la coh´erence des donn´ees, si une donn´ee est copi´ee d’un serveur `a un autre, la copie obtenue est de type volatile et par cons´equent d´etruite apr`es son utilisation. Ceci implique que la hi´erarchie n’est pas inform´ee de l’existence et de la localisation de cette copie.

Exemple Consid´erons l’architecture DIET pr´esent´ee Figure 3. Supposons qu’un client cli1 sollicite le produit matriciel D =B ×C. Supposons de plus que seuls les serveurs SeD1 et SeD2 offrent le service de produit matriciel. Soient X =tpsCalcSeD²+tpsCommC et Y =tpsCalcSeD¹+P

i=B,CtpsComi o`u tpsCalcSeDi repr´esente le temps de calcul du produit matriciel sur un serveur SeDi (pour i = 1,2) et tpsCommi repr´esente le temps de communication d’une donn´eei (pour i=B, C). Ces temps proviennent d’estimations fournies par le service de pr´ediction de performances [9]. Deux cas sont alors possibles :

LeCas 1 : X < Y. Dans ce cas le serveurSeD2est choisi. Le client envoie la donn´eeC et l’identifiant de la donn´eeB car celle-ci est d´ej`a pr´esente au sein de l’infrastructure. L’objetDataMgr2 met `a jour sa liste de donn´ees avec la donn´ee C et propage cette mise `a jour sur sa branche p`ere. Le serveur demande ensuite `a l’objetDataMgr2de lui fournir les donn´eesB etCpuis calcule le produitB×C. Si la donn´eeD est de typepersistentoupersistent return, elle est conserv´ee sur leSeD2et DataMgr2propage cette mise `a jour sur sa branche p`ere (une copie est ´egalement retourn´ee au client). SiD est de type sticky, elle est enregistr´ee sur l’objetDataMgr2qui ne propage pas cette mise `a jour. SiD est de typevolatile,D est retourn´e au client puis imm´ediatement d´etruite sur le serveur.

LeCas 2 : X > Y. Dans ce cas le serveurSeD1est choisi. Le client envoie la donn´eeC et l’identifiant

de B (car B est pr´esente au sein de l’architecture). L’objet DataMgr1 met `a jour sa liste de donn´ees avec la donn´ee C et propage cette mise `a jour sur sa branche p`ere. Le serveur demande ensuite `a l’objet DataMgr1de lui fournir les donn´eesBetC.Bn’´etant pas pr´esente localement, l’objetDataMgr1interroge sa hi´erarchie. Une fois l’objetDataManagerg´erantB trouv´e (iciDataMgr2), celui-ci transmet la donn´ee

`a l’objet requ´erant (iciDataMgr1). L’ensemble des branches, pour lesquelles la localisation de la donn´ee est connue, est mise `a jour. Le serveurSeD1 peut maintenant calculer le produit B×C. Si la donn´eeD est de typepersistentoupersistent return, elle est ´emise au client, conserv´ee sur l’objetDataMgr1qui propage cette mise `a jour sur sa branche p`ere.

R´esultats exp´erimentaux Afin de valider notre mod`ele, nous avons men´e deux s´eries de tests sur une plate-forme compos´ee d’un client distant, d’un Master Agent, de deux Leader Agents et de quatre SeDs.

Le client et le Master Agent sont connect´es via un r´eseau de d´ebit 16Mbits/s alors que le r´eseau local a un d´ebit de 100Mbits/s. Nous avons ainsi une arborescence LA-SeD locale, un serveur ´etant plus proche d’un autre serveur que du client. La plate-forme est compos´ee de serveurs (de 0.5 Ghz `a 1.8 Ghz) h´et´erog`enes, fonctionnant sous Linux.

Dans la premi`ere s´erie de tests, un client soumet un produit de matrices selon les trois sc´enarios suivants : – les donn´ees ne sont pas persistantes et sont pr´esentes uniquement chez le client (without persistency), – les donn´ees sont persistantes et sont pr´esentes sur le serveur choisi pour r´ealiser le calcul (local data), – les donn´ees sont pr´esentes et stock´ees quelque part sur la plate-forme mais pas sur le serveur choisi

pour le calcul (data inside the platform).

0 50 100 150 200 250 300 350 400 450 500

0 5 10 15 20 25 30 35

Computation time (s)

Matrix size (MO) without persistency

local data data inside the platform

(a)C=A∗B.

0 100 200 300 400 500 600 700 800 900 1000

0 10 20 30 40 50 60 70

Computation time (s)

Matrix size (MO) without persistency

first call further calls

(b)C=A∗B,D=E+C,A=^tA.

Fig. 4 – Comparaison donn´ees persistantes avec donn´ees non persistantes

Les r´esultats pr´esent´es Figure 4(a) confirment la faisabilit´e de notre approche. Logiquement, nous notons que la meilleure solution apparaˆıt lorsque la donn´ee est proche du serveur choisi pour les calculs. Quand les donn´ees sont pr´esentes dans l’infrastructure mais pas sur le serveur choisi, les temps d’ex´ecution sont toujours meilleurs que lorsque la donn´ee est ´emise par le client. En consid´erant la bande passante des r´eseaux locaux et distants, il est ais´e de conclure que plus les donn´ees sont pr`es des serveurs, plus les temps de calculs sont bons. Quel est le coˆut de l’ajout de notre service `a la plate-forme DIET ? CORBA permet la non recopie de donn´ees m´emoire, nous pouvons donc r´ecup´erer des valeurs sans faire de copie. De plus, nous soulignons que la mise `a jour de la hi´erarchie est r´ealis´ee de mani`ere asynchrone, son coˆut est donc faible et n’influe pas sur le temps de calcul global.

La deuxi`eme exp´erience<sup>8</sup> (Figure 4(b)) est une s´equence d’appels `a l’int´erieur d’une session :C=A∗B puisD=C+E puisA=^tA, A, B, C, D, E ´etant des matrices. L`a encore trois sc´enarios sont ´etudi´es :

8Les temps de calcul des diff´erentes courbes doivent ˆetre compar´ees dans la mˆeme figure car les conditions d’exp´erimentations ont chang´e.

– donn´ees non persistantesChaque donn´ee est envoy´ee chaque fois que cela est n´ecessaire (par exemple la matriceAest transmise deux fois),

– donn´ees persistantes (premier appel)Chaque donn´ee est envoy´ee uniquement au premier appel, pour les autres appels seul son identifiant est envoy´e. Dans ce cas,A,BetCsont d´efinies comme ´etant persistantes.Cdoit ˆetre persistante parce qu’elle est utilis´ee dans le deuxi`eme appel.D peut ˆetre non persistante parce qu’elle n’est pas utilis´ee ailleurs. Dans ce cas, A, B, E sont ´emises une fois,C n’est pas ´emise,

– donn´ees persistantes (appels suivants) seulement les identifiants des donn´ees sont ´emis car les donn´ees sont d´ej`a pr´esentes dans l’infrastructure.

Les r´esultats de cette s´erie de tests sont expos´es Figure 4(b). Comme nous l’avons d´ej`a expliqu´e, si nous pouvons ´eviter les transmissions multiples d’une mˆeme donn´ee, le temps de calcul global est ´egal `a la sommation des temps de transfert de la donn´ee (en entr´ee depuis le client vers le serveur, en sortie depuis le serveur vers le client) avec le temps d’ex´ecution du probl`eme. Logiquement encore, le dernier sc´enario apparaˆıt comme ´etant le meilleur et confirme la faisabilit´e et le faible coˆut de notre approche dans le cas de s´equence d’appels.

4.2.2 Gestion des donn´ees de grande taille dans un environnement pair-`a-pair : JUXMEM JUXMEM [1] (Juxtaposed Memory) est une architecture pair-`a-pair de service de partage de donn´ees en m´emoire. Pour DIET, cette architecture se pr´esente comme un syst`eme de gestion de donn´ees `a la fois alternatif `a DTM et compl´ementaire. En effet, il peut ˆetre int´egr´e afin d’offrir une solution adapt´ee `a la gestion des donn´ees de grande taille. Dans cette section, nous allons d´ecrire l’architecture que propose JUXMEM, puis nous proposerons deux types d’int´egrations `a DIET, une version en mode partag´e et une version en mode concurrent.

L’architecture de JUXMEM Les donn´ees stock´ees dans la plate-forme pair-`a-pair JUXMEM sont par- tag´ees et modifiables. Le syst`eme offre la persistance ainsi que la localisation transparente des donn´ees, il assure la coh´erence et prend en compte la volatilit´e de la plate-forme. Tout comme DIET, l’architecture mise en place se base sur un mod`ele hi´erarchique afin de tirer partie de la plate-forme sous-jacente.

Il existe trois types de pairs, les pairs fournisseurs (PF) qui stockent les donn´ees, les pairs gestionnaires (PG) qui g`erent l’espace m´emoire, les pairs clients (PC) qui repr´esentent l’interface d’acc`es au service.

L’infrastructure pair-`a-pair permet `a chaque nœud de fournir et d’utiliser un service.

La structure hi´erarchique est mise en place par la gestion de groupes. En effet, un groupe a pour objectif de rassembler un ensemble de pairs. Il existe trois types de groupe. Le groupejuxmemcontenant l’ensemble des pairs et deux sous-groupes : le groupe clusteret le groupe data. Le premier regroupe un ensemble de pairs fournisseurs, en g´en´eral appartenant `a la mˆeme grappe mais il peut ´egalement s’agir d’une f´ed´eration de grappes. Le second groupe f´ed`ere les pairs fournisseurs partageant un mˆeme bloc de donn´ees.

DIET et JUXMEM sont deux outils utilisant les ressources de la grille, l’un pour les calculs l’autre pour la gestion des donn´ees. Cependant leur m´ecanisme d’allocation m´emoire est distinct. Une premi`ere approche consiste `a faire cohabiter les deux syst`emes, cette solution implique alors des recopies m´emoires entre les deux syst`emes. Lors du calcul DIET n´ecessite d’avoir une localit´e des donn´ees, contrainte qui n’affecte pas JUXMEM, la distribution des donn´ees n’est donc pas ´equivalente. In´evitablement une recopie m´emoire des donn´ees, et donc une consommation m´emoire importante est `a prendre en compte dans la mise en place de cette cohabitation. Dans cette optique, nous donnons ici deux types de cohabitation : le mode partag´e et le mode concurrent.

Cohabitation DIET/JUXMEM : mode partag´e La premi`ere solution ´evoqu´ee part du principe que la grille offre un grand nombre de ressources, ces ressources sont alors attribu´ees soit `a un composant DIET (Figure 5 cadre du haut) soit `a un composant JUXMEM (Figure 5 cadre du bas).

La Figure 5, montre un exemple de cette cohabitation. La Figure 5(a) montre les liens de communications de l’architecture DIET et la Figure 5(b) illustre les liens repr´esentant la d´ependance entre les pairs gestion- naires et les pairs clients-fournisseurs dans JUXMEM (il ne s’agit pas des liens r´eseaux puisque chaque pair

PC/PF

PC/PF

MA

SeD SeD SeD SeD

Client

LA

SeD SeD SeD PG

PG

PG

PG PC/PF

PC/PF

PC/PF

PC/PF

(a)Connectivit´es DIET

PC/PF

PC/PF

PC/PF

PC/PF PC/PF

PC/PF

MA

SeD SeD SeD SeD

Client

LA

SeD SeD SeD PG

PG

PG

PG

PC PC PC

(b)Connectivit´es JUXMEM

Fig. 5 – Int´egration DIET/JUXMEM version partag´ee.

peut communiquer avec un autre pair). Ainsi dans l’exemple fourni on identifie clairement les grappes DIET et les grappes JUXMEM. La connectivit´e entre les deux s’effectuant via les pairs MA/PG ou LA/PG.

Cette version a l’avantage de limiter les interf´erences entre les deux syst`emes li´ees `a l’utilisation de la m´emoire l’un pour le stockage l’autre pour le calcul. Par contre le nombre de ressources pour chaque syst`eme est diminu´e. Le d´eploiement des diff´erents composants devient alors crucial pour les performances globales de la plate-forme. Ce d´eploiement n’est plus limit´e au d´eploiement de la plate-forme DIET [5] mais doit

´egalement prendre en compte le d´eploiement de JUXMEM.

Cohabitation DIET/JUXMEM : mode concurrent Dans cette cohabitation les composants DIET et les pairs JUXMEM partagent les mˆemes ressources en ´etant d´eploy´es sur les mˆemes nœuds (Figure 6). Dans cette architecture chaque nœud de calcul (ici assimil´e `a un SeD) dispose d’un pair client afin de r´ecup´erer les donn´ees en contactant le pair gestionnaire correspondant `a son groupe. De la mˆeme fa¸con la m´emoire de ces nœuds peut ˆetre utilis´ee pour stocker les donn´ees. Cette approche signifie qu’une partie de la m´emoire doit ˆetre allou´ee `a JUXMEM pour le stockage des donn´ees et une autre partie de la m´emoire doit ˆetre r´eserv´ee pour les donn´ees utilis´ees pour le calcul.

PC/PF

PC/PF

PC/PF

PC/PF PC/PF PC/PF

PC/PF PC/PF

PC/PF

PC/PF

PC/PF PC/PF PC/PF MA

SeD SeD SeD SeD

Client

SeD

SeD

SeD

SeD

LA

SeD SeD SeD LA SeD

SeD PG

PG

PG

PG MA

(a)Connectivit´es DIET

PC/PF

PC/PF

PC/PF

PC/PF PC/PF PC/PF

PC/PF PC/PF

PC/PF

PC/PF

PC/PF PC/PF PC/PF MA

SeD SeD SeD SeD

Client

SeD

SeD

SeD

SeD LA

LA

SeD SeD SeD LA SeD

SeD PG

PG

PG

PG

(b)Connectivit´es JUXMEM

Fig. 6 – Int´egration DIET/JUXMEM version concurrente.

Pour faire cohabiter physiquement les composants des deux logiciels, deux gestions m´emoires sont pos-

sibles. Soit via un espace d’adressage m´emoire prot´eg´e pour chaque composant, ce qui implique une allocation statique de la m´emoire. Soit par un espace d’adressage partag´e qui demande alors une gestion dynamique de la m´emoire. Cette solution demande alors un suivi en temps r´eel de l’´etat de la m´emoire disponible.

5 Conclusion

Dans cet article, nous avons pr´esent´e les diff´erents probl`emes li´es `a la gestion de donn´ees dans lesNetwork Enabled Servers. Plusieurs approches sont possibles avec plus ou moins de transparence et des performances diff´erentes selon les applications et les architectures cibles. Une bonne gestion des donn´ees est indispensable si l’on veut obtenir les meilleurs performances et tirer partie au mieux des bandes-passantes et des latences r´eseau. Nous avons d´etaill´e les approches compl´ementaires choisies dans le cadre du d´eveloppement de notre boˆıte-`a-outils pour la mise en place d’applications utilisant le paradigme du GridRPC, DIET. Ces approches g´en´eriques nous permettront d’offrir aux applicatifs les meilleures performances et des niveaux de transpa- rence adapt´es aux besoins. De nombreux travaux sont en cours et notamment autour de l’ordonnancement conjoint des calculs et de la gestion des communications. Par ailleurs, nous travaillons ´egalement sur la gestion de r´eplicas pour une application de bioinformatique. Enfin, des d´eveloppements sont en cours de finalisation autour de la connexion dynamique des agents d’ordonnancement dans DIET grˆace `a l’environnement JXTA de Sun Microsystems.

R´ ef´ erences

[1] Gabriel Antoniu, Luc Boug´e, and Mathieu Jan. JuxMem : An Adaptive Supportive Platform for Data Sharing on the Grid. InIEEE/ACM Workshop on Adaptive Grid Middleware, held in conjunction with 12th Intl. Conf.

on Parallel Architectures and Compilation Techniques (PACT 2003), New Orleans, September 2003.

[2] P. Arbenz, W. Gander, and J. Mori. The Remote Computational System.Parallel Computing, 23(10) :1421–1428, 1997.

[3] D.C. Arnold, D. Bachmann, and J. Dongarra. Request Sequencing : Optimizing Communication for the Grid. In Euro-Par 2000 Parallel Processing, 6th International Euro-Par Conference, volume volume 1900 of Lecture Notes in Computer Science, pages 1213–1222. Springer Verlag, August 2000.

[4] E. Caron, S. Chaumette, S. Contassot-Vivier, F. Desprez, E. Fleury, C. Gomez, M. Goursat, E. Jeannot, D. Lazure, F. Lombard, J.-M. Nicod, L. Philippe, M. Quinson, P. Ramet, J. Roman, F. Rubi, S. Steer, F. Suter, and G. Utard.

Scilab to Scilab//, the OURAGAN Project. Parallel Computing, 11(27) :1497–1519, OCT 2001.

[5] Eddy Caron, Pushpinder Kaur Chouhan, and Arnaud Legrand. Automatic Deployment for Hierarchical Network Enabled Server. In The 13th Heterogeneous Computing Workshop (HCW 2004), Santa Fe. New Mexico, April 2004.

[6] I. Foster and C. Kesselman (Eds.). The Grid : Blueprint for a New Computing Infrastructure, 2nd Edition.

Morgan-Kaufmann, 2004.

[7] E. Jeannot and F. Desprez. Adding Data Persistence and Redistribution to NetSolve. Technical Report RR2001- 39, LIP ENS Lyon, December 2001.

[8] S. Matsuoka, H. Nakada, M. Sato, , and S. Sekiguchi. Design Issues of Network Enabled Server Systems for the Grid. http://www.eece.unm.edu/^∼dbader/grid/WhitePapers/satoshi.pdf, 2000. Grid Forum, Advanced Programming Models Working Group whitepaper.

[9] Martin Quinson. Dynamic performance forecasting for network-enabled servers in a metacomputing environment.

InInternational Workshop on Performance Modeling, Evaluation, and Optimization of Parallel and Distributed Systems (PMEO-PDS’02), in conjunction with IPDPS’02, April 15-19 2002.