Gestion de données dans les NES

Gestion de données dans les NES E. Caron, F. Desprez, A. Vernois B. Del-Fabbro LIP/ENS-Lyon LIFC {Eddy.Caron,Frederic.Desprez}@ens-lyon.fr delfabbro@lifc.univ-fcomte.fr Antoine.Vernois@ens-lyon.fr Introduction Les problèmes de très grande taille issus de la simulation numérique peuvent désormais être résolus via Internet grâce aux environnements de type Grilles [6]. De nombreuses approches coexistent qui ont chacune leurs avantages et leurs inconvénients. Par ailleurs, l approche ASP (Application Service Provider) permet d accéder à des applications à distance grâce à des intergiciels adaptés. Dans ce paradigme, un client peut demander l exécution de requêtes à un agent chargé de trouver le serveur le plus adapté en terme de performance ou de fonctionnalité. Les requêtes peuvent alors être exécutées par des serveurs séquentiels ou parallèles. Ce paradigme est proche du modèle RPC (Remote Procedure Call ou appel de procédure à distance). L approche GridRPC [8] est la forme grille du RPC Unix classique. On appelle généralement ces environnements qui les réalisent des serveurs de calculs ou NES (Network Enabled Servers). Plusieurs outils offrant cette fonctionnalité comme NetSolve, NINF 2, DIET 3, NEOS 4, ou RCS [2] sont déjà disponibles. Le GridRPC implique que les données sont envoyées du client vers le serveur qui réalise le calcul et le résultat revient du serveur vers le client. Si des dépendances existent entre les requêtes, des transferts de données inutiles sont effectués et ce coût prohibitif diminue l intérêt d une telle approche. Il convient donc de gérer au mieux ces dépendances en laissant tant que possible les données sur les serveurs sur lesquels elles ont été utilisées (ou calculées). Ceci nécessite une gestion de données efficace et surtout extensible vu le nombre de serveurs et de clients généralement traités par ce type d environnement. Cet article présente donc l architecture de plusieurs NES (NetSolve, Ninf et DIET) ainsi que les problèmes de gestion de données qui leurs sont propres. Dans une première section, nous présentons l API GridRPC proposée dans le cadre du Global Grid Forum pour permettre de gérer la persistance des données au niveau du client. Dans une seconde section, nous présentons l architecture des trois environnements de type NES disponibles actuellement et qui implémentent le standard GridRPC. Enfin, dans la troisième section et avant une conclusion et une description de nos travaux futurs, nous présentons les solutions choisies par Ninf, NetSolve et DIET pour gérer les données. 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é une interface standard pour l API client. Cette API permettra d avoir une bonne portabilité entre les différents systèmes. Nous allons nous focaliser sur la partie gestion de données de cette interface qui est en cours de discussion au sein du GGF. L interface générale pour les demandes d exécution de requêtes peut être trouvée sur le site du GGF. Un aspect naturellement important de la définition d une telle interface est la définition http://www.cs.utk.edu/netsolve/ 2 http://ninf.etl.go.jp/ 3 http://graal.ens-lyon.fr/diet 4 http://www-neos.mcs.anl.gov/

de la possibilité de laisser les données calculées sur les serveurs afin de réduire le coût des communications. Il va de soit que ceci doit être le plus transparent possible pour les clients finaux mais un ordonnanceur intelligent devra être capable de dire au système si telle donnée doit être laissée ou pas sur tel ou tel serveur en fonction des dépendances entre les requêtes. Cette proposition part du postulat que chaque donnée doit être identifiée au sein de la plate-forme. Nous définissons donc le data handle (DH) comme étant une référence à une donnée qui peut être stockée à n importe quel endroit. Ainsi, cette définition du data handle permet de gérer la lecture et l écriture des données sans avoir à se préoccuper d où elles proviennent ni d où elles seront stockées. L opération de création du data handle est réalisée par la fonction create(data handle t *dh); Une fois que la référence à la donnée est créée, il est possible de lier ou pas cette référence à une donnée. Si on lie la donnée, elle peut être soit présente chez le client, soit présente sur un serveur de dépôt. Sinon cela signifie que la donnée est déjà présente dans la plate-forme. L opération de liaison d une donnée à une référence permet aussi de préciser si la donnée doit être conservée ou non. Cette opération est réalisée par la fonction bind(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ée (machine locale ou serveur de dépôt), data site t site : la localisation de la machine où l on veut stocker la donnée, sachant que si cette valeur est nulle la donnée sera stockée sur le dernier serveur d exécution l ayant utilisé. Ainsi, du coté du serveur de calcul, si le data handle contient un site identique au loc, la donnée doit être retournée au client ou au serveur de stockage référencé. En revanche, si le data handle contient un site différent du loc, la donnée sera déplacée du loc vers le site référencé par site. La Figure montre un exemple d utilisation de l interface de gestion de données dans l API GridRPC. Dans cette figure, un client exécute un premier calcul sur un serveur capable d exécuter le service demandé et un second calcul sur un autre serveur plus performant. Pour ce second calcul, le client n a pas à renvoyer sa donnée puisqu elle se trouve déjà sur le réseau. CLIENT SERVICE A SERVICE B create input data create input_dh bind input_dh to input data create output_dh call(input_dh, output_dh) Note : output_dh is unbound read input_dh create output2_dh bind output2_dh to client data sent return bound output_dh call(output_dh, output2_dh) EXECUTE SERVICE create output data bind out. data to output_dh (output data still available on this server) read output_dh data sent write data on output2_dh EXECUTE SERVICE Fig. Exemple d utilisation de l API GridRPC avec gestion de données intégrée. 3 Architecture de trois environnements de type NES 3. Ninf et NetSolve NetSolve est un NES développé au laboratoire ICL de l Université du Tennessee. Ninf quant à lui est développé au Tokyo Institute of Technology. Ces deux NES sont très similaires dans leur conception. Ils sont

basés tous deux sur trois composants principaux : les clients, l agent et les serveurs de calcul. Clients : Ils sont construits en utilisant des bibliothèques qui offrent une API (basée sur le GridRPC) permettant d accéder aux ressources de calculs gérées 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 à jour les informations concernant les serveurs, leurs possibilités ainsi que les statistiques d utilisation. C est lui qui reçoit les requêtes des clients et alloue au mieux les ressources de calcul des serveurs à ces requêtes pour que celles-ci soient exécutées le plus rapidement possible. Serveurs : Les serveurs de calcul sont la puissance de traitement de NetSolve ou de Ninf. Ils sont gérés par l agent et sont en mesure de résoudre un certain nombre de problèmes. La liste des problèmes qu un serveur sait résoudre est maintenue par l agent. Les communications entre les composants se font via un protocole de communication spécifique au niveau applicatif construit au dessus de TCP/IP. 3.2 DIET 0 0 0 000 0 0 0 Client 0 0 0 0 0 0 Fig. 2 Vue générale de DIET. Dans cette section, nous donnons des détails sur l architecture de DIET et nous présentons les différents composants impliqués dans sa hiérarchie. Dans [8], les auteurs donnent un état de l art des environnements basés sur des NES qui permettent d accéder à des serveurs de calcul via le réseau. Si l on rentre dans les détails, de tels environnements sont composés de cinq types de composants différents : les clients qui soumettent les problèmes aux serveurs, les serveurs qui résolvent les problèmes soumis par les clients, des moniteurs qui récupèrent des informations sur l état des ressources de calcul et les stockent dans une base de données qui contient aussi des informations concernant les ressources matérielles et logicielles, et enfin un ordonnanceur (appelé agent dans notre architecture) qui choisit un serveur approprié en fonction du problème soumis et des informations contenues dans la base de données. Les projets NetSolve ou Ninf suivent cette approche. Malheureusement, il n est possible de lancer qu un seul agent chargé de l ordonnancement pour un groupe de serveurs de calculs donnés 5. Cela crée un goulot d étranglement des performances empêchant le déploiement de NetSolve pour de grands groupes de serveurs, et rend le système peu résistant aux erreurs. En effet, la mort du processus agent rend inutilisable la plate-forme toute entière. Pour résoudre ces problèmes, DIET se propose de répartir le travail de l agent selon une nouvelle organisation. Il est ainsi remplacé par un ensemble d agents organisés selon deux approches : une approche multi-agents de type pair-à-pair améliorant la robustesse du système associé et une approche hiérarchique favorisant l efficacité de l ordonnancement. Cette répartition du rôle de l agent offre divers avantages. Tout d abord, on a une meilleure répartition de la charge entre les différents agents et une plus grande stabilité du système (si un des éléments venait à s arrêter, les autres éléments pourraient se réorganiser pour le remplacer). Enfin, on obtient également une gestion simplifiée en cas de passage à l échelle (l administration de chaque groupe de serveurs et des agents associés peut être déléguée). 3.2. Les composants de DIET Un client est une application qui utilise DIET pour résoudre des problèmes. Plusieurs types de clients doivent être capables de se connecter à DIET. Un problème peut être soumis depuis une page web, un environnement de résolution de problèmes tel que Scilab [4] ou Matlab ou depuis un programme compilé. Un Master Agent () est directement relié aux clients. Il reçoit des requêtes de calcul des clients et choisit un (ou plusieurs) s qui sont capables de résoudre le problème en un temps raisonnable. Un possède les mêmes informations qu un, mais il a une vue globale (et de haut niveau) de tous les problèmes qui peuvent être résolus et de toutes les données qui sont distribuées dans tous ses sous-arbres. 5 A part pour une version de Ninf qui possède plusieurs agents (Metaserver) mais ceux-ci ont une connaissance globale de tout l environnement grâce à des diffusions des informations.

Un Leader Agent () compose un niveau hiérarchique dans les agents DIET. Il peut être le lien entre un Master Agent et un, entre un autre et un ou entre deux s. Son but est de diffuser les requêtes et les informations entre les s et les s. Il tient à jour une liste des requêtes en cours de traitement et, pour chacun de ses sous-arbres, le nombre de serveurs pouvant résoudre un problème donné, ainsi que des informations à propos des données. Un Server Daemon () est le point d entrée d un serveur de calcul. Il se trouve sous la responsabilité d un. Il tient à jour une liste des données disponibles sur un serveur (éventuellement avec leur distribution et le moyen d y accéder), une liste des problèmes qui peuvent y être résolus, et toutes les informations concernant sa charge. Sur une machine parallèle, un sera donc installé sur le frontal de cette machine. La plate-forme cible actuelle de DIET est le réseau rapide connectant les grappes et les machines parallèles des différentes unités de recherche de l INRIA (projet RNRT VTHD 6 ). Cette architecture est donc fortement hiérarchique puisque le réseau VTHD connecte les UR INRIA entre elles, qui elles-mêmes possèdent dans leurs réseaux propres des grappes de machines connectées par des réseaux plus ou moins rapides. Les machines d où sont lancées les calculs sont soit directement connectées au réseau VTHD ou simplement connectées par les réseaux internes des laboratoires ayant accès à cette plate-forme. 3.2.2 Mode de fonctionnement Un nouveau client de DIET doit d abord contacter un Master Agent (le plus approprié : en distance réseau par exemple) et lui soumettre un problème. Pour choisir le serveur le plus approprié pour résoudre ce problème, le Master Agent propage une requête dans ses sous-arbres 7 afin de trouver à la fois les données impliquées (parfois issues de calculs précédents et donc déjà présentes sur certains serveurs lorsque la persistance est activée) et les serveurs capables de résoudre l opération demandée. Lorsque la requête arrive au niveau des s, ces derniers interrogent les capables de résoudre le problème afin de récupérer l évaluation des temps de calcul et de communication via notre outil de prédiction de performance FAST [9]. Si le serveur, dispose d une donnée utile au calcul il en informe également le. Les choix d ordonnancement se font alors à chaque niveau de l arbre lors de la remontée de la réponse au. Lors de cette remontée, notons que les agents attendent les réponses de leurs fils pendant un certain laps de temps au delà duquel elles sont ignorées. Cet état de fait ne permet pas de tirer des conséquences quant à une panne éventuelle d un agent qui ne répond pas ou pas assez vite. Lorsque la réponse revient au Master Agent, il renvoie l adresse du serveur choisi au client (il est également possible de renvoyer une liste bornée des meilleurs serveurs au client). Le envoie ensuite l ordre de migrer les données. Le transfert des données s effectue alors en deux phases pouvant être exécutées en parallèle : transfert des données issues du client et éventuellement le transfert des données persistantes localisées sur un autre serveur. Une fois les données récupérées la résolution du calcul peut être effectuée. Les résultats pourront être renvoyés au client. Pour des questions de performances, DIET essaye autant que possible de laisser les données sur place. 4 Gestion de données dans les NES 4. NetSolve et Ninf Plusieurs approches ont été utilisées pour la gestion de données dans NetSolve. Dans un premier temps, en collaboration avec E. Jeannot, nous avons intégré un certain nombre de fonctions permettant de laisser les données sur place puis de les déplacer [7]. Ces fonctions, appelables depuis le client permettaient d envoyer une ou plusieurs données depuis un serveur vers un client ou de redistribuer les données entre des serveurs séquentiels. Dans le cas d une séquence de requêtes [3] (comprises entre deux appels de fonctions spéciales), les données en entrées seront toutes envoyées au serveur qui effectuera la première requête. Ensuite, ne seront 6 http ://www.vthd.org 7 Une extension dans le cadre du multi- est possible en diffusant les requêtes de calcul aux autres s et en les traitant comme des s

transférées aux serveurs qui auront la charge des requêtes suivantes, que les données dont ils auront besoin, sans repasser par le client. Cette technique permet d éviter des transferts redondant d une même donnée entre le client et le système. Dans la même optique, l utilisateur pourra préciser que certaines données de sortie des requêtes ne sont que des données intermédiaires. Dans ce cas, celles-ci ne seront pas rapatriées sur le client en fin de séquence. Dans une dernière version de NetSolve, les données utilisées peuvent soit être locales au client (sur disque ou en mémoire), soit être présentes dans une infrastructure de stockage distribué (Distributed Storage Infrastructure ou DSI). Pour pouvoir être utilisée dans NetSolve, une donnée présente dans une DSI aura dû y être insérée via l API fournie. Cette API est prévue pour pouvoir accéder à différents DSI de la même façon, même si, actuellement, seul IBP (Internet Backplane Protocol ou IBP) est supporté. Pour une donnée DSI, c est à l utilisateur (client) qu incombe la tâche de connaître et choisir le serveur qui va héberger sa donnée. Dans tous les cas, la localité des données n est pas prise en compte dans le choix du serveur qui exécutera la requête. NetSolve maintient une table d allocation des fichiers qui recense le statut de tous les fichiers présents dans les DSI, ce qui impose l utilisation de l API NetSolve pour gérer les données distantes. Lors de la réception d une requête, le serveur NetSolve récupère les informations concernant les données en entrées et regarde dans sa table d allocation s il y est fait référence. Si c est le cas, alors il s agit d une donnée présente dans un DSI, sinon, la donnée est supposée locale au client et devra être récupérée par le serveur en charge de l exécution de la requête. Ninf ne possède pas de mécanisme sophistiqué de gestion de données. Il utilise juste une technique de gestion des séquences de requêtes comme NetSolve. 4.2 L approche DIET La gestion des données dans DIET a été pensée de manière modulaire. Cette particularité permet d envisager de connecter plusieurs types de systèmes de gestion de données. Dans cette section nous allons décrire deux infrastructures ayant des fonctionnalités complémentaires et pouvant être utilisées dans une même plate-forme. Le DTM (Data Tree Manager) pour une gestion des données adaptée à l architecture de DIET et JUXMEM pour une gestion de données de très grande taille. 4.2. Gestion des données dans un environnement hiérarchique : DTM L idée de gérer des données sur une plate-forme hiérarchique est soumise à deux contraintes fortes. Être capable de définir quelles sont les données que l on veut conserver dans la plate-forme, et être capable d identifier de manière unique cette donnée en son sein. Nous avons donc défini le mode de persistance et l identifiant de la donnée. Le mode de persistance Afin de rendre la plate-forme persistante, il a été défini une API cliente permettant au client de soumettre les données avec certaines caractéristiques. Lors de la première émission de la donnée, le client (ou un proxy intelligent ) fournit la donnée, son rôle (in, in out, out) au sein de l infrastructure ainsi que son mode (volatile, sticky, sticky return pour la session courante et persistent, persistent return valide entre session). Une donnée volatile ne sera pas conservée sur le serveur après son utilisation, elle sera détruite, Une donnée sticky est conservée sur le serveur mais non déplaçable. Ce mode est utile dans le cas de données de très grande taille pour lesquelles le coût de déplacement est trop pénalisant, Une donnée sticky return est une donnée sticky pour laquelle l utilisateur désire obtenir une copie, Une donnée persistent est conservée dans l infrastructure pendant une session ou à travers plusieurs sessions, elle est déplaçable et susceptible d être copiée, Une donnée persistent return est une donnée persistent pour laquelle l utilisateur désire obtenir une copie (c est le mode le plus adapté pour les données in out). La gestion de la persistance que nous proposons est à mettre en corrélation avec la proposition de standard faite dans le cadre du GridRPC Working Group du GGF. Notre DTM gère de manière explicite le mode de persistance des données alors qu il est implicitement déterminé dans l API GridRPC proposée. Cette différence s explique par la standardisation et le fait que les autres plates-formes Ninf, NetSolve ne gèrent

pas explicitement ce mode. Cependant, à partir de la définition et de l utilisation des fonctions de l API, nous constatons une relation directe avec le GridRPC. En effet, les modes volatile, sticky, sticky return persistent, persistent return sont gérés par l utilisation de la méthode bind(). Architecture L idée est donc que l architecture DIET puisse conserver les données éventuellement réutilisables et les déplacer d un serveur à un autre suivant les besoins de calcul. De plus, afin de ne pas alourdir la gestion des calculs en entrelaçant des messages liés aux calculs et des messages liés à la gestion des données, le choix a été fait de dissocier la partie calcul de la partie gestion des données en agrégeant deux objets : le DataManager et le LocManager respectivement liés aux et /, comme présenté figure 3. F(B,C)=D Cli idb, DataMgr2 ida, DataMgr LocMgr2 DataMgr A LocMgr 2 3 F() ida, LocMgr2 idb, LocMgr2 DataMgr2 B F() DataMgr3 Fig. 3 Les Objets DataManager et LocManager La structure des objets LocManager (respectivement Data- Manager) est initialisée parallèlement à celle des objets et (respectivement des ). Les fonctionnalités des objets DataManager et LocManager sont les suivantes : L objet LocManager est situé sur chaque agent avec lequel il communique localement. L objet LocManager gère une liste de références aux données présentes dans sa branche (couple identifiant donnée/possesseur). Sur l exemple présenté en Figure 3, l objet LocMgr2 possède les couples ((ida,datamrg),(idb,datamrg2)) et l objet LocMgr possède les couples ((ida,locmrg2),(idb,locmgr2)). Ainsi, la hiérarchie des objets LocManager permet de connaître la localisation d une donnée. Les objets DataManager ayant uniquement la connaissance des données qu ils possèdent localement. L objet DataManager est situé sur chaque avec lequel il communique localement. Il contient la liste des données de mode sticky, sticky return, persistent ou persistent return. Il est par ailleurs chargé des opérations de déplacement ou de copie de données et également de fournir les données nécessaires au serveur pour ses calculs. Enfin, il informe son objet LocManager père, de mises à jour (ajout, suppression) concernant sa liste de données. La mise à jour des branches concernées au sein de l architecture se faisant hiérarchiquement. Qui plus est, afin de gérer simplement, dans un premier temps, la cohérence des données, si une donnée est copiée d un serveur à un autre, la copie obtenue est de type volatile et par conséquent détruite après son utilisation. Ceci implique que la hiérarchie n est pas informée de l existence et de la localisation de cette copie. Exemple Considérons l architecture DIET présentée Figure 3. Supposons qu un client cli sollicite le produit matriciel D = B C. Supposons de plus que seuls les serveurs et 2 offrent le service de produit matriciel. Soient X = tpscalc 2 + tpscomm C et Y = tpscalc + i=b,c tpscom i où tpscalc i représente le temps de calcul du produit matriciel sur un serveur i (pour i =, 2) et tpscomm i représente le temps de communication d une donnée i (pour i = B, C). Ces temps proviennent d estimations fournies par le service de prédiction de performances [9]. Deux cas sont alors possibles : Le Cas : X < Y. Dans ce cas le serveur 2 est choisi. Le client envoie la donnée C et l identifiant de la donnée B car celle-ci est déjà présente au sein de l infrastructure. L objet DataMgr2 met à jour sa liste de données avec la donnée C et propage cette mise à jour sur sa branche père. Le serveur demande ensuite à l objet DataMgr2 de lui fournir les données B et C puis calcule le produit B C. Si la donnée D est de type persistent ou persistent return, elle est conservée sur le 2 et DataMgr2 propage cette mise à jour sur sa branche père (une copie est également retournée au client). Si D est de type sticky, elle est enregistrée sur l objet DataMgr2 qui ne propage pas cette mise à jour. Si D est de type volatile, D est retourné au client puis immédiatement détruite sur le serveur. Le Cas 2 : X > Y. Dans ce cas le serveur est choisi. Le client envoie la donnée C et l identifiant 2 LocMgr3

de B (car B est présente au sein de l architecture). L objet DataMgr met à jour sa liste de données avec la donnée C et propage cette mise à jour sur sa branche père. Le serveur demande ensuite à l objet DataMgr de lui fournir les données B et C. B n étant pas présente localement, l objet DataMgr interroge sa hiérarchie. Une fois l objet DataManager gérant B trouvé (ici DataMgr2), celui-ci transmet la donnée à l objet requérant (ici DataMgr). L ensemble des branches, pour lesquelles la localisation de la donnée est connue, est mise à jour. Le serveur peut maintenant calculer le produit B C. Si la donnée D est de type persistent ou persistent return, elle est émise au client, conservée sur l objet DataMgr qui propage cette mise à jour sur sa branche père. Résultats expérimentaux Afin de valider notre modèle, nous avons mené deux séries de tests sur une plate-forme composée d un client distant, d un Master Agent, de deux Leader Agents et de quatre s. Le client et le Master Agent sont connectés via un réseau de débit 6Mbits/s alors que le réseau local a un débit de 00Mbits/s. Nous avons ainsi une arborescence - locale, un serveur étant plus proche d un autre serveur que du client. La plate-forme est composée de serveurs (de 0.5 Ghz à.8 Ghz) hétérogènes, fonctionnant sous Linux. Dans la première série de tests, un client soumet un produit de matrices selon les trois scénarios suivants : les données ne sont pas persistantes et sont présentes uniquement chez le client (without persistency), les données sont persistantes et sont présentes sur le serveur choisi pour réaliser le calcul (local data), les données sont présentes et stockées quelque part sur la plate-forme mais pas sur le serveur choisi pour le calcul (data inside the platform). 500 450 400 without persistency local data data inside the platform 000 900 800 without persistency first call further calls Computation time (s) 350 300 250 200 50 00 Computation time (s) 700 600 500 400 300 200 50 00 0 0 5 0 5 20 25 30 35 Matrix size (MO) (a) C = A B. 0 0 0 20 30 40 50 60 70 Matrix size (MO) (b) C = A B, D = E + C, A = t A. Fig. 4 Comparaison données persistantes avec données non persistantes Les résultats présentés Figure 4(a) confirment la faisabilité de notre approche. Logiquement, nous notons que la meilleure solution apparaît lorsque la donnée est proche du serveur choisi pour les calculs. Quand les données sont présentes dans l infrastructure mais pas sur le serveur choisi, les temps d exécution sont toujours meilleurs que lorsque la donnée est émise par le client. En considérant la bande passante des réseaux locaux et distants, il est aisé de conclure que plus les données sont près des serveurs, plus les temps de calculs sont bons. Quel est le coût de l ajout de notre service à la plate-forme DIET? CORBA permet la non recopie de données mémoire, nous pouvons donc récupérer des valeurs sans faire de copie. De plus, nous soulignons que la mise à jour de la hiérarchie est réalisée de manière asynchrone, son coût est donc faible et n influe pas sur le temps de calcul global. La deuxième expérience 8 (Figure 4(b)) est une séquence d appels à l intérieur d une session : C = A B puis D = C + E puis A = t A, A, B, C, D, E étant des matrices. Là encore trois scénarios sont étudiés : 8 Les temps de calcul des différentes courbes doivent être comparées dans la même figure car les conditions d expérimentations ont changé.

données non persistantes Chaque donnée est envoyée chaque fois que cela est nécessaire (par exemple la matrice A est transmise deux fois), données persistantes (premier appel) Chaque donnée est envoyée uniquement au premier appel, pour les autres appels seul son identifiant est envoyé. Dans ce cas, A, B et C sont définies comme étant persistantes. C doit être persistante parce qu elle est utilisée dans le deuxième appel. D peut être non persistante parce qu elle n est pas utilisée ailleurs. Dans ce cas, A, B, E sont émises une fois, C n est pas émise, données persistantes (appels suivants) seulement les identifiants des données sont émis car les données sont déjà présentes dans l infrastructure. Les résultats de cette série de tests sont exposés Figure 4(b). Comme nous l avons déjà expliqué, si nous pouvons éviter les transmissions multiples d une même donnée, le temps de calcul global est égal à la sommation des temps de transfert de la donnée (en entrée depuis le client vers le serveur, en sortie depuis le serveur vers le client) avec le temps d exécution du problème. Logiquement encore, le dernier scénario apparaît comme étant le meilleur et confirme la faisabilité et le faible coût de notre approche dans le cas de séquence d appels. 4.2.2 Gestion des données de grande taille dans un environnement pair-à-pair : JUXMEM JUXMEM [] (Juxtaposed Memory) est une architecture pair-à-pair de service de partage de données en mémoire. Pour DIET, cette architecture se présente comme un système de gestion de données à la fois alternatif à DTM et complémentaire. En effet, il peut être intégré afin d offrir une solution adaptée à la gestion des données de grande taille. Dans cette section, nous allons décrire l architecture que propose JUXMEM, puis nous proposerons deux types d intégrations à DIET, une version en mode partagé et une version en mode concurrent. L architecture de JUXMEM Les données stockées dans la plate-forme pair-à-pair JUXMEM sont partagées et modifiables. Le système offre la persistance ainsi que la localisation transparente des données, il assure la cohérence et prend en compte la volatilité de la plate-forme. Tout comme DIET, l architecture mise en place se base sur un modèle hiérarchique afin de tirer partie de la plate-forme sous-jacente. Il existe trois types de pairs, les pairs fournisseurs (PF) qui stockent les données, les pairs gestionnaires () qui gèrent l espace mémoire, les pairs clients (PC) qui représentent l interface d accès au service. L infrastructure pair-à-pair permet à chaque nœud de fournir et d utiliser un service. La structure hiérarchique 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 groupe juxmem contenant l ensemble des pairs et deux sous-groupes : le groupe cluster et le groupe data. Le premier regroupe un ensemble de pairs fournisseurs, en général appartenant à la même grappe mais il peut également s agir d une fédération de grappes. Le second groupe fédère les pairs fournisseurs partageant un même bloc de données. DIET et JUXMEM sont deux outils utilisant les ressources de la grille, l un pour les calculs l autre pour la gestion des données. Cependant leur mécanisme d allocation mémoire est distinct. Une première approche consiste à faire cohabiter les deux systèmes, cette solution implique alors des recopies mémoires entre les deux systèmes. Lors du calcul DIET nécessite d avoir une localité des données, contrainte qui n affecte pas JUXMEM, la distribution des données n est donc pas équivalente. Inévitablement une recopie mémoire des données, et donc une consommation mémoire importante est à prendre en compte dans la mise en place de cette cohabitation. Dans cette optique, nous donnons ici deux types de cohabitation : le mode partagé et le mode concurrent. Cohabitation DIET/JUXMEM : mode partagé La première solution évoquée part du principe que la grille offre un grand nombre de ressources, ces ressources sont alors attribuées soit à un composant DIET (Figure 5 cadre du haut) soit à 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ésentant la dépendance entre les pairs gestionnaires et les pairs clients-fournisseurs dans JUXMEM (il ne s agit pas des liens réseaux puisque chaque pair