DIET, tour d horizon

Transcription

1 DIET, tour d horzon Eddy Caron, Frédérc Desprez GRAAL/LIP/ENS-Lyon {Eddy.Caron,Frederc.Desprez}@ens-lyon.fr Résumé L objectf de cet artcle est de fournr une vue d ensemble exhaustve de l ntergcel pour la grlle DIET développé par l équpe du projet GRAAL. DIET (Dstrbuted Interactve Engneerng Toolbox) est un ensemble hérarchque de composants pour l élaboraton d applcatons basées sur des serveurs de calcul. Après avor ntrodut le paradgme de programmaton de cette plate-forme, nous présentons l archtecture générale de la plate-forme DIET et ses prncpaux composants. Nous détallons son mode de fonctonnement, en nsstant sur la mse en œuvre d un clent et d un serveur. Nous aborderons ensute la geston des données en décrvant deux types d approches, une approche hérarchque et une approche par à par. Nous donnons ensute une descrpton des outls fourns pour l ordonnancement de DIET, ans que l archtecture envsagée pour la mse en œuvre d ordonnanceurs. L étape suvante sera alors d ntrodure la geston des ressources de la plate-forme. Une présentaton d une extenson par à par de DIET sera décrte. Enfn, nous présenterons les outls dsponbles afn de smplfer le déploement et la vsualsaton de la plate-forme. Introducton Les problèmes de très grande talle ssus de la smulaton numérque peuvent désormas être résolus va Internet grâce aux envronnements de metacomputng [6]. Pluseurs approches co-exstent telles que les langages orentés objets [25], les envronnements à base de passage de messages [29, 24], les botes àoutls [7], les envronnements de calcul global [26, 5], ceux basés sur le Web [20, 2, 23], etc. Par alleurs, la plupart des applcatons courantes sont numérques et l utlsaton de bblothèques adéquates telles que les BS [4], PACK [], ScaPACK [22] ou PETSc [4] est devenue oblgatore. L ntégraton de telles bblothèques dans des applcatons de haut nveau utlsant des langages comme Fortran ou C est lon d être asée. En effet, l utlsateur dot toujours spécfer une parte du parallélsme pour les utlser et dstrbuer lu-même les structures de données. Enfn, la pussance de calcul (ou la capacté mémore) nécessare à ces applcatons n est malheureusement pas dsponble sur toutes les statons de traval. Notre plate-forme de développement est le réseau rapde connectant les grappes et les machnes parallèles des dfférentes untés de recherche de l INRIA (projet RNRT VTHD 2 ). Cette archtecture est donc fortement hérarchque pusque le réseau VTHD connecte les UR INRIA entre elles, qu elles-mêmes possèdent dans leurs réseaux propres des grappes de machnes connectées par des réseaux plus ou mons rapdes. Les machnes d où sont lancées les calculs sont sot drectement connectées au réseau VTHD ou smplement connectées par les réseaux nternes des laboratores ayant accès à cette plate-forme. Par alleurs, nous envsageons de valder expérmentalement l utlsaton de DIET sur une plate-forme à grande échelle, dans le cadre du projet Grd Grd 5000 est une plateforme ms en place pour la recherche dans le domane des grlles. Dx laboratores sont mplqués afn de fournr une plate-forme dédée, permettant aux développeurs de la communauté grlle de valder les dfférents nveaux logcels acteurs de la mse en œuvre des technologes grlle. L objectf est de fournr une plate-forme de 8 grappes d une centane de nœuds connectés par Renater à Gb/s(étendu à 0 Gb/s par la sute). Dans ces types de plate-forme physque, nous sommes confrontés àtrosproblèmes : trouver de la pussance de calcul et de la capacté destockage,utlser un réseau hérarchque de machnes et enfn per- 2 http :// 3 http ://

2 mettre à l utlsateur de porter son applcaton de manère smple et (relatvement) transparente. L approche RPC [27, 28] est un bon canddat pour élaborer des envronnements de résoluton de problèmes dans un envronnement de metacomputng. On appelle généralement ces envronnements des serveurs de calculs ou NES (Network Enabled Servers). Pluseurs outls offrant cette fonctonnalté comme NetSolve [3], NINF [32], NEOS [30] ourcs[3] sont déjà dsponbles mas aucun d entre eux ne gère pour l nstant spécfquement les réseaux hérarchques de machnes. Cet artcle présente l archtecture de DIET (Dstrbuted Interactve Engneerng Toolbox), un ensemble hérarchque de composants pour l élaboraton d applcatons basées sur des serveurs de calcul. Après avor ntrodut le paradgme de programmaton de cette plate-forme, nous présentons l archtecture générale de la plate-forme DIET et ses prncpaux composants. Nous détallons son mode de fonctonnement, en nsstant sur la mse en œuvre d un clent et d un serveur. Nous aborderons ensute la geston des données en décrvant deux types d approches, une approche hérarchque et une approche par à par.la secton 5 donnera une descrpton des outls fourns pour l ordonnancement de DIET, ans que l archtecture envsagéepour la mse enœuvre d ordonnanceurs pour DIET. L étape suvante sera alors d ntrodure la geston des ressources dans la secton 6. La secton 7, présente l extenson par à par de DIET. Enfn, nous présenterons les outls dsponbles afn de smplfer le déploement et la vsualsaton de la plate-forme. Dans [28], les auteurs donnent un état de l art des envronnements basés sur des NES qu permettent d accéder à des serveurs de calcul va le réseau. D ordnare, de tels envronnements sont composés de cnq types de composants dfférents : les clents qu soumettent les problèmes aux serveurs, les serveurs qu résolvent les problèmes soums par les clents, des monteurs qu récupèrent des nformatons sur l état des ressources de calcul et les stockent dans une base de données qu content auss des nformatons concernant les ressources matérelles et logcelles, et enfn un ordonnanceur qu chost un serveur appropré en foncton du problème soums et des nformatons contenues dans la base de données. Les chercheurs des projets NetSolve, Nnf et DIET ont proposé une nterface standard pour les clents. Cela permet d avor une bonne nteropérablté entre les systèmes. Les envronnements présentés précédemment sont mult-langages (C, Fortran, Java, etc.). L nterface clent dot être la plus smple possble. Une des dffcultés les plus mportantes est certanement la descrpton de problèmes. Il n y a actuellement pas de consensus n de standard permettant cette descrpton. Une proposton d nterface générque est actuellement proposée dans le cadre du Grd Forum 4.Une descrpton détallée du GrdRPC est dsponble dans ces actes. 3 Archtecture de DIET L objectf de DIET est de fournr un ntergcel pour la grlle qu offre une nterface suffsamment smple pour masquer aux applcatons l nfrastructure dstrbuée. Cependant le concept d accès aux ressources de la grlle reste une tâche dffcle. L dée est donc de fournr pluseurs nveaux d ntégraton d une applcaton à la grlle. La Fgure, décrt ces dfférents nveaux. L nterface haut nveau d accès à la grlle est sot une page web, sot un langage de haut nveau comme Sclab [8]. Cette nterface, lorsqu elle est dsponble, repose sur un clent applcatf. Interface haut nveau Page web, Sclab, Matlab,... Clent applcatf Programme C/C++, Fortran, Java,... Clent DIET DIET (C++/CORBA) Nveau utlsateur Nveau applcatf Nveau développeur (DIET) 2 Le GRID-RPC Ordonnanceur DIET DIET (C++/CORBA) Nveau développeur (DIET) Serveur DIET DIET (C++/CORBA) Serveur applcatf Programme C/C++, Fortran, Java,... Applcaton Programme C/C++, Fortran, Java,... Nveau développeur (DIET) Nveau applcatf Nveau développeur (Applcaton) Fg. Archtecture smplfée de DIET. Le clent applcatf est le len entre l nterface haut nveau et le clent DIET. Il dot être écrt par l utlsateur souhatant offrr un nouveau servce de grlle. Les détals de la réalsaton d un tel clent sont 4 page 2

3 décrts en 3.3. Afn de faclter le traval une API smple est fourne. Le clent DIET, a pour foncton de soumettre les requêtes aux ordonnanceurs (appelés agents), pus de récupérer le serveur chos par les agents afn de communquer les données aux serveurs afn d effectuer le calcul. Les agents ont la charge de localser le ou les serveurs les plus adaptés à la requête (type de problème, capacté des ressources, dsponblté duserveur,etc.) et de retourner cette nformaton au clent DIET. L utlsateur ayant écrt le clent applcatf dot écrre la parte duale appelée serveur applcatf. Une API smple est également fourne afn de réalser le len entre le serveur DIET et l applcaton en elle-même. La concepton de ce serveur est explcté secton 3.4. Cette archtecture smplfée de DIET peut s applquer à toute archtecture de type GrdRPC comme les projets NetSolve [3] ounnf[32]. Cependant, dans ces ntergcels l n y a qu un seul agent chargé de l ordonnancement pour un groupe de serveurs de calculs donnés. Cela crée un goulot d étranglement lmtant le déploement de l ntergcel pour de grands groupes de serveurs, et rend le système peu résstant aux erreurs. De plus, la mort du processus agent rend nutlsable la plate-forme toute entère. Pour résoudre ces problèmes, DIET se propose de répartr le traval de l agent selon une nouvelle organsaton. Il est ans remplacé par un ensemble d agents organsés selon deux approches : une approche mult-agents de type par àpar(peer to peer )amélorant la robustesse du système assocé et une approche hérarchque favorsant l effcacté de l ordonnancement. Cette répartton du rôle de l agent offre dvers avantages : une melleure répartton de la charge entre les dfférents agents, une plus grande stablté du système (s un des éléments venat à s arrêter, les autres éléments pourraent se réorganser pour le remplacer), une geston smplfée en cas de passageà l échelle (l admnstraton de chaque groupe de serveurs et des agents assocés peut être déléguée). Un serveur DIET est également appelé SeD(Server Daemon). Nous avons ensute une hérarche (organsée de manère arborescente) d agents dont les (Leader Agents)etles(Master Agents). Pluseurs hérarches pourront co-exster au sen de DIET, dfférents seront alors connectés sot en CORBA, sot va un système par à par (cf. secton 7). 3. Les composants de DIET Clent. Lorsque l on évoque le clent, l s agt Clent Fg. 2 Vuegénérale de DIET. du clent applcatf qu utlse DIET pour résoudre des problèmes. Pluseurs clents peuvent se connecter àdiet.unproblème peut être soums de manère synchrone (le clent reste en attente du résultat) ou de manère asynchrone (le contrôle est rendu au programme après la soumsson). Master Agent (). Un est drectement relé aux clents. Il reçot des requêtes de calcul des clents et chost un (ou pluseurs) SeD qu sont capables de résoudre le problème en un temps rasonnable. Un possède les mêmes nformatons qu un, mas l a une vue globale (et de haut nveau) de tous les problèmes qu peuvent être résolus et de toutes les données qu sont dstrbuées dans tous ses sous-arbres afn d accélérer la recherche d un SeD capable de résoudre une requête. Leader Agent (). Un compose un nveau hérarchque dans les agents DIET. Il peut être le len entre un et un SeD, deux ou un et SeD. Son but est de dffuser les requêtes et les nformatons entre les et les SeD. Il tent à jour une lste des requêtes en cours de tratement et, pour chacun de ses sous-arbres, le nombre de serveurs pouvant résoudre un problème donné, ans que des nformatons à propos des données. Server Daemon (SeD). Un SeD est le pont d entrée d un serveur de calcul. Il gère l ensemble des respage 3

4 sources qu lu sont allouées. Il peut s agr d un processeur, comme d un cluster (dans le cas d applcatons parallèles). Il tent à jour une lste des données dsponbles sur un serveur (éventuellement avec leur dstrbuton et le moyen d y accéder), une lste des problèmes qu peuvent y être résolus, et toutes les nformatons concernant sa charge (charge CPU, mémore dsponble, talle du dsque, etc.). 3.2 Fonctonnement général Un nouveau clent de DIET dot d abord contacter le Master Agent le plus appropré (suvantsaproxmté dansleréseau). Une fos que son Master Agent est dentfé, le clent peut lu soumettre un problème. Pour chosr le serveur le plus approprépour résoudre ce problème, le Master Agent propage une requête dans ses sous-arbres afn de trouver à la fos les données mplquées (parfos ssues de calculs précédents et ans déjà présentes sur certans serveurs) et les serveurs capables de résoudre l opératon demandée. Ensute, le Master Agent renvoe l adresse du serveur chos au clent et effectue le transfert des données persstantes mplquées dans le calcul. Le clent communque ses données locales au serveur et alors la résoluton du calcul peut être effectuée. Les résultats pourront être renvoyés au clent en foncton du problème. En général, nous essayons autant que possble de lasser les données sur place Phase d ntalsaton La Fgure 3 décrt chaque étapedelamseenœuvre d une archtecture DIET smple. La plate-forme est construte en suvant la hérarche, chaque composant étant connecté àsonpère. Le est le premer composant qu est démarré (fgure 3 ()). Il est alors en attente de la connexon d un agent ou de requêtes en provenance des clents. peuvent alors connectés à ce : sot un SeD (fgure 3 étape (3)) sot un autre pour ajouter un nveau de hérarche àlabranche(fgure3 étape (4)). Lorsque le SeD s enregstre à un, la lste des servces qu l fournt est publée, c est-à-dreque la lste des servces dsponbles est dffusée dans la hérarche du jusqu au. Fnalement, lorsqu un clent souhate accéder à une ressource de la plate-forme, l contacte un (fgure 3 étape (5)) afn de récupérer la référence (ou une lste de référence) du melleur serveur (ou des melleurs serveurs) et se connecte ensute drectement à ce SeD pour effectuer le transfert des données et le calcul. L archtecture de la hérarche est décrte au travers des fchers de confguraton de chacun des composants. En effet, chaque composant a dans son fcher le nom de son parent (excepton fate pour les ).Afndedonnerunordred dée nous envsageons le déploement d une hérarche à l échelle d un domane tel qu une unversté, les clents de ce domane auront de fat les drots nécessares pour l accès aux ressources. Les peuvent quant àeuxêtre déployés au nveau des laboratores de cette unversté. Chaque laboratore pouvant alors admnstrer les ressources qu lu sont propres et les déclarer au. Cette admnstraton hérarchque de la plate-forme faclte le déploement à l échelle de la grlle, pusque chaque modfcaton locale ne provoque pas de perturbaton à l ensemble de la plate-forme Tratement des requêtes Dans cette secton nous consdérons que l archtecture décrte dans la secton 3 comprend pluseurs serveurs capables de résoudre le même problème (ce qu est souvent le cas) et que ce problème peut être résolu sur un seul serveur. L exemple présenté Fgure4 correspond à la soumsson d un problème F() utlsant les données A et B. F(A,B) CLIENT Clent S2 S3 F() S32 () (2) (3) (4) (5) Fg. 3 Intalsaton d une plate-forme DIET. Lors de son ntalsaton le vent s nscrre auprès du (étape (2)). Deux types de composants S S2 S2 S22 S23 A B F() Fg. 4 Exemple de soumsson de problème L algorthme présenté cdécrt la procédure réapage 4

5 lsée par le afn de sélectonner le serveur pour répondre à la requête. Cette décson se déroule en quatre étapes : Le propagela requête du clent dans les sousarbres où des serveurs dsposent du servce. Dans la verson actuelle chaque agent sat dans quelles branches l peut-être ntéressant de fare suvre la requête. Cette méthode à l avantage de lmter les communcatons mas pose quelques problèmes de cohérence dans le cas de hérarche profonde (dans la secton 6. nous proposons une soluton sans mse à jour de la lste des servces dans la hérarche). chaque serveur qu dspose du servce et qu reçot cette requête va exécuter Fast pour estmer le temps de calcul nécessare et transmet cette estmaton à son père (le ). encasdesuccès, chaque de l arbre reçot une ou pluseurs estmatons des serveurs. A chaque nveau de la hérarche un ordonnancement des serveurs est effectué jusqu au. une fos au, ce derner effectue la décson fnale et communque au clent le serveur sélectonné (ou une lste de serveurs). Pour la résoluton du problème en lu-même, le clent se connecte au serveur chos, l envoe les données locales et spécfe s le résultat dot être gardésur le serveur pour un futur calcul ou s l dot revenr au clent. Le transfert des données persstantes est réalsé à ce moment. La secton 4 donne plus de détals sur la geston des données dans DIET. 3.3 Le clent DIET 3.3. Mse en œuvre du clent Comme nous l avons vu dans la secton 3, l utlsaton de la grlle pour une applcaton mplque la mse en place d une descrpton de l applcaton à deux nveaux de l ntergcel. Lors de la soumsson côté clent et pour l exécuton côté serveur,onyretrouve le nom de l applcaton, les paramètresd entrée et les paramètres de sorte. La réalsaton du clent DIET passe par l utlsaton d une lbrare qu l est possble d nterfacer avec dfférents types de clents (langage C, C++, PHP, Fortran ou JAVA). L objectf est d écrre un programme effectuant les appels aux fonctons DIET. L API clente est dsponble dans DIET_clent.h et peut être nvoquée ndfféremment selon deux syntaxes : syntaxe DIET : det_nom_de_foncton syntaxe GrdRPC : grpc_nom_de_foncton Avant tout appel DIET, le programme clent dot ouvrr une sesson va l appel det_ntalze (ou grpc_ntalze). Cette ntalsaton a pour effet de prendre en compte le fcher de confguraton et ans de postonner les optons (FAST, LogServce, etc.) et de récupérer la référence au Master Agent à qu la requête va être soumse. La sesson est fnalsée par l appel à det_fnalze (ou grpc_fnalze). Lors de cet appel les ressources de cette sesson sont lbérées auss ben sur le clent que sur les serveurs et les agents à l excepton de la mémore allouée pour les arguments de type IN et INOUT qu n ont pas été retournés au clent et qu peuvent être accédés (et lbérés) après la fermeture de la sesson en rason des appels asynchrones. #nclude <stdo.h> #nclude <stdlb.h> #nclude "DIET_clent.h" nt man(nt argc, char *argv[]) { det ntalze(confguraton fle, argc, argv); // Successve DIET calls... det fnalze() ; } API clent L API clent sut la défnton du GrdRPC [36] : toutes les fonctons det_ sont duplquées avec des fonctons grpc_. Ans on retrouve les fonctons d ntalsaton et de fn dans les deux syntaxes : det_ntalze/grpc_ntalze det_fnalze/grpc_fnalze Un problème est géré par le bas d une functon_handle, qu assoce un serveur à un nom de problème. La functon_handle retournée est assocée à la descrpton d un problème au moment de l ntalsaton, sute à l appel du det_call. Unexemple complet de code clent est fourn à la fn de cet artcle fgure Le serveur DIET 3.4. Mse en œuvre du serveur Un programme serveur DIET est le len entre le SeD et la lbrare qu mplémente le servce offert. Comme nous l avons vu pour le clent, le SeD DIET est également une lbrare. Ans les développeurs de servces dovent défnr une foncton man. À l ntéreur de cette foncton man, leserveurdietsera chargé par l appel à det_sed qu n aura pas de repage 5

6 tour 5 sauf en cas d erreur. L nterface complète du serveur est décrte dans le fcher DIET_data.h et DIET_server.h. Il faut donc nclure ces deux fchers au début du code du serveur. #nclude <stdo.h> #nclude <stdlb.h> #nclude "DIET_server.h" #nclude "DIET_data.h" La seconde étape est de défnr une foncton dont le prototype est normalsé DIET et qu sera capable de convertr la foncton en sa foncton correspondante au sen de la lbrare. Consdérons une foncton de la lbrare qu a le prototype suvant. nt servce(nt arg, char *arg2, double *arg3); Cette foncton ne peut être appelé drectement par DIET, du fat qu un tel prototype est dffcle à manpuler dynamquement. Le concepteur d un servce dot défnr une foncton solve dont le prototypage consste smplement en un profl det (det_profle_t) : nt solve servce(det profle t *pb) { nt arg ; char *arg2 ; double arg3 ; } det scalar get(det parameter(pb,0), &arg, NULL); det strng get(det parameter(pb,), &arg2, NULL, NULL); 0 det scalar get(det parameter(pb,2), &arg3, NULL); return servce(arg, arg2, arg3); Cette foncton dot être appelée par un SeD DIET. Pluseurs fonctons de l API sont dsponbles afn d ader le concepteur de servces. Afn de défnr les arguments INOUT (arguments en entrée et en sorte) et OUT (argument en sorte), on utlse les fonctons det_*_desc_set 6 défns dans DIET_server.h. En utlsant ces fonctons, le développeur du serveur peut garder à l esprt le fat qu l ne peut modfer l espace mémore ponté par ses données sur le serveur. 5 Dans la verson.0 de DIET. 6 Le caractère * est à remplacer par le type (scalar, strng, etc.) API du serveur Défnton des servces Dans un premer temps, l faut déclarer les servces qu seront offerts. Il est possble de déclarer pluseurs servces sur un unque SeD. Chaque servce est décrt par un profl appelé det_profle_desc_t. Il n est alors pas nécessare de défnr la talle des données. Chaque profl peut être alloué par la foncton det_profle_desc_alloc. Chaque argument du profl sera défnt par la foncton det_generc_desc_set. Déclaraton de servces Chaque servce défn dot être ajouté àlatabledes servces avant que le serveur ne sot chargé. L API de la geston de la table des servces est la suvante : typedef nt (* det solve t)(det profle t *) ; nt det servce table nt(nt max sze); nt det servce table add( det profle desc t *profle, det convertor t *cvt, det solve tsolvefunc); vod det prnt servce table() ; 0 Le paramètre det_solve_t solve_func est le type de la foncton solve_servce :unponteurde foncton utlsé par DIET pour lancer le calcul. Pour nformaton, le paramètre det_convertor_t *cvt est utlsé avec FAST (vor secton 5.), et permet de convertr le profl (par exemple lorsqu l y a une dfférence entre le profl de DIET et le profl nterne de FAST). 4 La geston des données La geston des données dans DIET a été pensée de manère modulare. Cette partcularté permet d envsager de connecter pluseurs types de systèmes de geston de données. Dans cette secton nous allons décrre deux nfrastructures ayant des fonctonnaltés complémentares et pouvant être utlsées dans une même plate-forme. Le DTM (Data Tree Manager) pour une geston des données adaptée à l archtecture de DIET et JUXMEM pour une geston de données de très grande talle. page 6

7 4. Geston des données dans un envronnement hérarchque : DTM L dée de gérer des données sur une plate-forme hérarchque est soumse à deux contrantes fortes. Être capable de défnr quelles sont les données que l on veut conserver dans la plate-forme, et pouvor dentfer de manère unque cette donnée en son sen. Nous avons donc défn le mode de persstance et l dentfant de la donnée. 4.. Le mode de persstance Afn de rendre la plate-forme persstante, nous avons défn une API clente permettant au clent de soumettre les données avec certanes caractérstques. Lors de la premère émsson de la donnée, le clent fournt la donnée, son rôle (n, n_out, out), son mode pour la sesson courante (volatle, stcky, stcky_return) et son mode nter-sesson (persstent, persstent_return). Une donnée volatle ne sera pas conservée sur le serveur après son utlsaton, elle sera détrute. Une donnée stcky est conservée sur le serveur mas non déplaçable. Ce mode est utle dans le cas de données de très grande talle pour lesquelles le coût de déplacement est trop pénalsant. Une donnée stcky_return est une donnée stcky pour laquelle l utlsateur désre obtenr une cope. Une donnée persstent est conservée dans l nfrastructure pendant une sesson ou à travers pluseurs sessons, elle est déplaçable et susceptble d être copée. Une donnée persstent_return est une donnée persstent pour laquelle l utlsateur désre obtenr une cope (c est le mode le plus adapté pour les données n_out). La geston de la persstance que nous proposons est à mettre en corrélaton avec la proposton de standard fate dans le cadre du GrdRPC Workng Group du GGF. Notre DTM gère de manère explctelemodedepersstancedesdonnées alors qu l est mplctement détermné dans l API GrdRPC ntalement proposée. Cette dfférence s explque par la standardsaton et le fat que les autres platesformes Nnf et NetSolve ne gèrent pas explctement ce mode. Cependant, à partr de la défnton et de l utlsaton des fonctons de l API, nous constatons une relaton drecte avec le GrdRPC. En effet, les modes volatle, stcky, stcky_return, persstent, persstent_return sont gérés par l utlsaton de la méthode bnd() Archtecture L dée est donc que l archtecture DIET pusse conserver les données éventuellement réutlsables et les déplacer d un serveur àunautresuvantlesbesons de calcul. De plus, afn de ne pas alourdr la geston des calculs en entrelaçant des messages lés aux calculs et des messages lés àlagestondesdonnées, le chox a été fat de dssocer la parte calcul de la parte geston des données en agrégeant deux objets : le DataManager et le LocManager (formant le DTM) respectvement lés aux SeD et /, comme présenté Fgure5. Clent db, DataMgr2 da, DataMgr LocMgr2 DataMgr A F(B,C)=D LocMgr SeD SeD2 SeD3 F() da, LocMgr2 db, LocMgr2 DataMgr2 B F() DataMgr3 Fg. 5 LesObjetsdeDTM 2 LocMgr3 Les objets du DTM sont ntalsés conjontement à celle des objets et (respectvement des SeD). Les fonctonnaltés des objets sont les suvantes : L objet LocManager est stué sur chaque agent avec lequel l communque localement. L objet LocManager gère une lste de références aux données présentes dans sa branche (couple dentfant donnée/possesseur). Sur l exemple présenté en Fgure 5, l objet LocMgr2 possède les couples ((da,datamrg),(db,datamrg2)) et l objet LocMgr possède les couples ((da,locmrg2),(db,locmgr2)). Ans, la hérarche des objets LocManager permet de localser une donnée. Les objets DataManager quant à eux ont unquement la connassance des données qu ls possèdent localement. L objet DataManager est stué sur chaque SeD avec lequel l communque localement. Il content la lste des données déclarées avec le mode stcky, stcky_return, persstent ou persstent_return. Il est par alleurs chargé des opératons de déplacement ou de cope de données et également de fournr les données nécessares au serveur pour ses calculs. Enfn, l nforme son LocManager père des mses à jour (ajout, suppresson) concernant sa lste de données. La mse à jour des branches concernées au sen de l archtecture se fasant hérarchquement. Qu plus page 7

8 est, afn de gérer smplement, dans un premer temps, la cohérence des données, s une donnée est copée d un serveur à un autre, la cope obtenue est de type volatle et par conséquent détrute après son utlsaton. Cec mplque que la hérarche n est pas nformée de l exstence et de la localsaton de cette cope Résultats expérmentaux Afn de valder notre modèle, nous avons mené deux séres de tests sur une plate-forme composée d un clent dstant, d un Master Agent, de deux Leader Agents et de quatre SeD. Le clent et le Master Agent sont connectés va un réseau à 6Mbts/s alors que le réseau local a un débt de 00Mbts/s. Nous avons ans une arborescence -SeD locale, un serveur étant plus proche d un autre serveur que du clent. La plate-forme est composée de serveurs (de 0.5 Ghz à.8ghz)hétérogènes, fonctonnant sous Lnux. Dans la premère sére de tests, un clent soumet un produt de matrces selon les tros scénaros suvants :. les données ne sont pas persstantes et sont présentes unquement chez le clent (sans persstance), 2. les données sont persstantes et sont présentes sur le serveur chos pour réalser le calcul (données locales), 3. les données sont présentes et stockées quelque part sur la plate-forme mas pas sur le serveur chos pour le calcul (données dsponbles dans la plate-forme). Les résultats présentés Fgure 6(a) confrment la fasablté de notre approche. Logquement, nous notons que la melleure soluton apparaît lorsque la donnée est proche du serveur chos pour les calculs. Quand les données sont présentes dans l nfrastructure mas pas sur le serveur chos, les temps d exécuton sont toujours melleurs que lorsque la donnée est émse par le clent. En consdérant la bande passante des réseaux locaux et dstants, l est asé deconclure que plus les données sont près des serveurs, plus les temps de calcul (calcul plus transfert des données) sontbons.ilresteàdétermner le coût de l ajout de notre servce àlaplate-formediet.corbapermet la non recope de données mémore, nous pouvons donc récupérer des valeurs sans fare de cope. De plus, nous soulgnons que la mse àjourdelahérarche est réalsée de manère asynchrone, son coût est donc fable et n nflue pas sur le temps de calcul global. Temps de calcul (s) Temps de calcul (s) sans persstance donnee locale donnee dsponble dans la plate-forme Talle de matrce (MO) (a) C = A B. sans persstance premer appel appels suvants Talle de matrce (MO) (b) C = A B, D = E + C, A = t A. Fg. 6 Comparason données persstantes avec données non persstantes La deuxème expérence 7 (Fgure 6(b)) est une séquence d appels à l ntéreur d une sesson : C = A B pus D = C + E pus A = t A (A, B, C, D, E étant des matrces). Là encoretrosscénaros sont étudés :. Données non persstantes : chaque donnée est envoyée chaque fos que cela est nécessare (par exemple la matrce A est transmse deux fos), 2. Données persstantes (premer appel) : chaque donnée est envoyée unquement au premer appel, pour les autres appels seul son dentfant est envoyé. Dans ce cas, A, B et C sont défnes comme étant persstantes. C dot être persstante 7 Les temps de calcul des dfférentes courbes dovent être comparées dans la même Fgure car les condtons d expérmentatons ont changé. page 8

9 parce qu elle est utlsée dans le deuxème appel. D peut être non persstante parce qu elle n est pas utlsée alleurs. Dans ce cas, A, B, E sont émses une fos, C n est pas émse, 3. Données persstantes (appels suvants) : seulement les dentfants des données sont éms car les données sont déjà présentes dans l nfrastructure. Les résultats de cette sére de tests sont exposés Fgure 6(b). Comme nous l avons précédemment explqué, s nous pouvons évter les transmssons multples d une même donnée, le temps de calcul global est égal à la sommaton des temps de transfert de la donnée (en entrée depus le clent vers le serveur, en sorte depus le serveur vers le clent) avec le temps d exécuton du problème. Comme attendu, le derner scénaro apparaît comme étant le melleur et confrme la fasablté etlefablecoût de notre approche dans le cas de séquences d appels. Une autre approche pour la geston des données de grande talle àété envsagé pour DIET et est présenté dans la secton suvante. 4.2 Geston des données de grande talle dans un envronnement parà-par : JUXMEM JUXMEM [2] (Juxtaposed Memory) est une archtecture par-à-par de servce de partage de données en mémore. Pour DIET, cette archtecture se présente comme un système de geston de données àla fos alternatf à DTM et complémentare. En effet, l peut être ntégré afn d offrr une soluton adaptée à la geston des données de grande talle. Dans cette secton, nous allons décrre l archtecture que propose JUXMEM, pus nous proposerons deux types d ntégratons à DIET, une verson en mode partagé et une verson en mode concurrent. L archtecture de JUXMEM Les données stockées dans la plate-forme par-à-par JUXMEM sont partagées et modfables. Le systèmeoffrelapersstance ans que la localsaton transparente des données, l assure la cohérence et prend en compte la volatlté de la plate-forme. Tout comme DIET, l archtecture mse en place se base sur un modèle hérarchque afn de trer parte de la plate-forme sous-jacente. Il exste tros types de pars, les pars fournsseurs (PF) qu stockent les données, les pars gestonnares (PG) qugèrent l espace mémore, les pars clents (PC) qu représentent l nterface d accès au servce. L nfrastructure par-à-parpermet àchaquenœudde fournr et d utlser un servce. La structure hérarchque est mse en place par la geston de groupes. En effet, un groupe a pour objectf de rassembler un ensemble de pars. Il exste tros types de groupe. Le groupe juxmem contenant l ensemble des pars et deux sous-groupes : le groupe cluster et le groupe data. Le premer regroupe un ensemble de pars fournsseurs, en général appartenant àlamême grappe mas l peut également s agr d une fédératon de grappes. Le second groupe fédère les pars fournsseurs partageant un même bloc de données. DIET et JUXMEM sont deux outls utlsant les ressources de la grlle, l un pour les calculs l autre pour la geston des données. Cependant leur mécansme d allocaton mémore est dstnct. Une premère approche consste à fare cohabter les deux systèmes, cette soluton mplque alors des recopes mémore entre les deux systèmes. Lors du calcul DIET nécesste d avor une localté des données, contrante qu n affecte pas JUXMEM, la dstrbuton des données n est donc pas équvalente. Inévtablement une recope mémore des données, et donc une consommaton mémore mportante est à prendre en compte dans la mse en place de cette cohabtaton. Dans cette optque, nous donnons c deux types de cohabtaton : le mode partagé et le mode concurrent. Cohabtaton DIET/JUXMEM : mode partagé La premère soluton évoquée part du prncpe que la grlle offre un grand nombre de ressources, ces ressources sont alors attrbuées sot àuncomposant DIET sot à un composant JUXMEM. Cette verson a l avantage de lmter les nterférences entre les deux systèmes lées à l utlsaton de la mémore l un pour le stockage l autre pour le calcul. Par contre le nombre de ressourcespour chaquesystème est dmnué. Le déploement des dfférents composants devent alors crucal pour les performances globales de la plate-forme. Ce déploement n est plus lmté audéploement de la plate-forme DIET [9] mas dot également prendre en compte le déploement de JUXMEM. Cohabtaton DIET/JUXMEM : mode concurrent Dans cette cohabtaton les composants DIET et les pars JUXMEM partagent les mêmes ressources en étant déployés sur les mêmes nœuds. Dans cette archtecture chaque nœud de calcul (c assmlé à un SeD) dspose d un par clent afn de récupérer les données en contactant le par gestonnare correspondant à son groupe. De la même façon la mémore de ces nœuds peut être utlsée pour stocker les données. Cette approche sgnfe qu une parte de la mémore dot être allouée page 9

10 à JUXMEM pour le stockage des données et une autre parte de la mémore dot être réservée pour les données utlsées pour le calcul. Pour fare cohabter physquement les composants des deux logcels, deux gestons mémores sont possbles. Sot va un espace d adressage mémore protégé pour chaque composant, ce qu mplque une allocaton statque de la mémore. Sot par un espace d adressage partagé qu demande alors une geston dynamque de la mémore. Cette soluton demande alors un suv en temps réel de l état de la mémore dsponble. 5 Ordonnancement Comme nous venons de le vor la geston des données, quelle que sot la stratége chose, va avor un mpact sur le chox du serveur. Il va être ndspensable de coupler la geston des données avec l ordonnancement des calculs qu dans les ntergcels grlles ont tendance ànesefocalserquesurlesressourcesdsponbles (pussance des serveurs, dsponblté mémore et/ou dsques, servces dsponbles, etc.). Ce qu nous amène à nous ntéresser aux outls fourns par DIET afn de réalser l ordonnancement des requêtes de calcul. Afn de pouvor fournr aux ordonnanceurs une métrquedecomparasonfast[3] s avère un outl effcace et dédé àlaprédcton de performance. Nous décrrons donc ce logcel qu a été ntégré àdiet. Nous évoquerons ensute l archtecture d ordonnanceur à la carte que propose DIET afn de s adapter de manère effcace aux applcatons. Enfn nous étendrons cette parte sur l ordonnancement avec la secton 6 qu est de fat étrotement lée. 5. FAST : un outl de prédcton de performance Connassances Ordnateurs Mémore exstante Vtesse processeur Système Batch Réseau Bande passante Latence Topologe Protocoles Calculs Fasablté Espace nécessare Temps nécessare Acquston de données statques Applcaton Clente 2 FAST FAST API Acquston de données dynamques LDAP NWS Logcels de bas nveau Fg. 7 Vuegénérale de Fast. 3 4 Connassances Ordnateurs Etat (en/hors servce) Charge processeur Charge mémore Etat du Batch Réseau Bande passante Latence Fast [3, 34] estunoutldemodélsaton des performances dynamques dans un envronnement de metacomputng. Comme l ndque la Fgure 7, Fast est composé de pluseurs couches et s appue sur des logcels de bas nveau. Tout d abord, l utlse un logcel de survellance réseau et d actvté processeur pour gérer les ressources changeant au cours du temps comme la bande passante et la charge du processeur. Fast utlse le Network Weather Servce (NWS [37]), un outl développé à l Unversté du Tennessee, Knoxvlle. C est un système dstrbué qu scrute pérodquement dverses ressources réseau et de calcul et prédt dynamquement leur comportement. Pour acquérr les données statques, Fast nclut des routnes de modélsaton du temps et de l espace nécessares pour chaque trplet {problème; machne; jeu de paramètres}. Elles sont basées sur l étalonnage à l nstallaton de chaque routne sur chaque machne pour un jeu de paramètres représentatfs (benchmarks pus approxmaton polynomale). Cependant, pour certanes routnes comme celles qu tratent des matrces creuses, l utlsateur peut fournr lu-même une estmaton du temps de calcul en foncton des paramètres en entrée et du nombre de processeurs utlsés. S cette foncton ne peut être donnée, l ordonnanceur de DIET chosra tout smplement le serveur le plus rapde (et/ou le mons chargé) capable de résoudre le problème demandé. Pour stocker ces données statques, Fast utlse un arbre LDAP. Le stockage des données dynamques est géré par NWS. L nterface de programmaton de Fast est composée d un pett ensemble de fonctons qu combnent les données statques et dynamques acquses grâce au nveau nféreur pour produre des valeurs prêtes à l emplo pour l ordonnanceur de DIET. Le module d acquston des données dynamques de Fast amélore NWS. En effet, s l n y a pas de mesure drecte de NWS entre deux machnes, Fast recherche automatquement le plus court chemn entre elles dans le graphe des lens scrutés. Dans ce cas, la bande passante estmée est la plus pette observée sur ce chemn. Pour la latence, Fast prend la somme des latences mesurées. De plus, Fast mplémente un système de cache des résultats pour rédure le nombre d nterrogatons de NWS et amélorer les temps de réponse du système. 5.2 Structure des ordonnanceurs dans DIET La fgure 8 donne une verson smplfée de la structure de l ordonnanceur de DIET. Notons qu à chaque nveau de la hérarche une foncton d agrégaton des résultats est ms en œuvre. Dans l exemple cette foncton est dépendante d une foncton mn(), l est cependant possble pour l utlsateur de défnr sa propre foncton d agrégaton effectuant son ordonpage 0

11 nancement avec des crtères dfférents. On vot alors apparaître cette noton d ordonnanceur à la carte (ou ordonnanceur plug-n ). aggregate() { mn(...); } SeD estmate() { predexectme(...); } aggregate() { mn(...); } Fg. 8 Vue smplfée de l ordonnancement dans DIET Dans cet esprt, nous avons ramené la foncton predexectme() ntalement nterne au SeD au nveau utlsateur (dans le sens développeur de servces). La nouvelle foncton myperfmetrc() permet alors de précser quel est la métrque que l on souhate consdérer lors des décsons de l ordonnanceur. Par métrque on entend c capactémémore, espace dsques, espace mémore etc. Pour l nstant, le contrôle de l ordonnanceur est réservé audéveloppeur de servces qu connassent leur applcaton, et qu par conséquent ont peut être des contrantes sur leur ordonnancement. On peut également envsager de pouvor fare remonter ce contrôle sur l ordonnanceur au nveau du clent (par exemple pour le chox d une métrque). Cependant cela nécesstera la modfcaton du profl des requêtes. 6 Geston des ressources Afn de proposer des améloratons pour la geston des requêtes, nous avons étudé pluseurs approches. Une méthode de réservaton basée sur l algorthme ssu des systèmes dstrbués appelé PIF (Propagate Informaton Feedback) [7, 2, 35] une seconde méthode basée sur l utlsaton de contrat. 6. Réservaton par l algorthme de PIF Le PIF fonctonne en deux étapes. La premère étape est appelée phase de dffuson. La racne de l arbre ntalse la phase de dffuson en communquant un message m à ses descendants. De cette façon, ses descendants (excepté les feulles) partcpent à cette phase en transmettant le message aux descendants. Le message m est donc propagé dans l ensemble de l arbre. Une fos les feulles attentes par la phase de dffuson, elles notfent la termnason de la dffuson par l envo d un message de retour (feedback ) à ses parents. Cette étape nte la seconde phase, la phase de retour. Lorsqu un parent reçot un message de retour de tous ses descendants, l envoe un message de retour àsonpère et ans de sute. Lorsque la racne récupère le message de retour depus chacun de ses fls, la phase de retour est termnée. Tous les noeuds ont alors reçu le message m. Cet algorthme peut être utlsé dans le cas de DIET, dans [0] nous avons démontré son effcacté par smulaton. 6.. Applcaton du PIF dans DIET Chaque clent est assgnéà un unque. Le clent envoe sa requête à cet qu va nter la phase de dffuson en propageant la requête à ses fls. Chaque agent fat suvre cette requête jusqu au qu transmet alors la requête au SeD. Sur chaque serveur, le module Fast du SeD évalue les ressources dsponbles et fournt une prédcton de performance lorsque cela est possble. S un serveur est capable de répondre àlarequête, le SeD réserve les ressources nécessares. Dans tous les cas, le serveur nte la phase de retour en retournant un message au, qu est sot le temps d exécuton prédt, sot l nformaton de non dsponblté du serveur. Afn d assurer la synchronsaton nécessare à la phase de retour, le attend les réponses de chacun de ses SeD, pus l ordonnanceur du détermne le serveur le plus appropré (ou une lste de serveurs), par exemple le plus rapde ou le mons cher. Ensute, le résultatdecechoxestenvoyéàsonpère et les serveurs qu ne sont pas sélectonnés sont alors lbérés (en utlsant le paradgme du PIF dans le sous arbre correspondant). Àchaquenveaudelahérarche on applque le même prncpe jusqu à ce que le récupère l dentfant du serveur chos. Cet dentfant est alors communqué au clent, qu va conformément au fonctonnement de DIET, nter le calcul après transfert des données. Le serveur est capable de répondre au calcul pusque les ressources ont été réservées lors de la localsaton du serveur. Lorsque le calcul est termné les ressources sont lbérées. Deux problèmes peuvent apparaître avec cet algorthme. Comme chaque agent se place en attente de page

12 réponse jusqu à ce que tous les nœuds aent répondu, cela condut à une attente nfne dans le cas de non réponse dans la hérarche. De plus, avec un mécansme de réservaton de ressource, DIET dot pouvor prendre en compte des requêtes crosées, c est-à-dre des requêtes envoyées par dfférents clents mas qu tentent d accéder aux mêmes ressources Mécansmes de tolérance aux pannes En cas de panne d un serveur : Afn de prendre en compte une panne de serveur ou un temps de réponse trop long provoqué par une surcharge d un serveur, nous avons ajoutéuntme-out au nveau des (cf. Algorthme ) tmer = 0 tme out = α current server=0 response=0 whle (tmer<tme out OR response! =nb server) do f Mem response[current server]!= TRUE then f Ireceve(FAST INFO, S current server) ==OK then tmer = 0 tme out = β response++ Mem response[current server] = TRUE current server++ f current server == nb server+ then current server = 0 Algorthme : Pseudo-code pour le avec prse en compte du tme-out La valeur du tmer α correspond au temps pendant lequel DIET dot attendre la premère réponse de l un des serveurs. S aucun serveur n a répondu passé ce déla, une réponse est envoyée au père du précsant qu aucun serveur ne peut satsfare la demande. S au mons un serveur àrépondu, un second tmer égal à β est démarré. L objectf de ce tmer est d offrr un comproms entre le temps de réponse de l ordonnanceur et l agrégaton des réponses des dfférents serveurs. Sans ce tmer, on peut obtenr le serveur qu répond le plus vte et non le serveur qu offre la prédcton Fast la plus ntéressante. α et β dépendent du nombre de serveurs. Ces valeurs peuvent être dynamques et optmser le temps de réponse en dmnuant le temps du tmer β lorsquelenombrederéponses des serveurs augmente. Remarquons que l appel Ireceve représente une foncton de communcaton asynchrone. S un serveur n est pas prêt àrépondre, le second est sollcté et ans de sute en suvant un anneau. En cas de panne d un agent : La panne d un agent de la hérarche peut entraîner une attente nfne et la perte d une branche de l arbre d ordonnancement. Pour évter cela, nous proposons de mettre en place un second tmer σ qu est dépendant de la profondeur de l arbre (cf. Algorthm 2). tmer = 0 tme out = σ for all leaf of the current agent do whle (Ireceve(SCHEDULER INFORTION, Agent leaf ) == OK) OR (tmer<tme out) do nothng Algorthme 2: Agent algorthm usng a tme-out Dans ces condtons, la foncton asynchrone Ireceve peut être nterrompue par le tme-out σ. Notons également, que contrarement aux, les agents ne connassent pas le nombre de serveurs. Il est alors dffcle de détermner la valeur du tme-out mas elle reste dépendante des tmers défns précédemment mas auss de la hauteur de l arbre. 6.2 Geston des requêtes crosées Pour la geston des requêtes, un élément dot être prs en compte lors de la prse de décson. Lorsque Fast calcule l évaluaton du temps de calcul sur un serveur, l ne tent compte que de la charge de ce serveur à cet nstant. Dans le cas où un serveur n est pas entèrement dédé àlarésoluton de problèmes depus la plate-forme DIET, nous ne pouvons garantr un nveau élevé dequalté de servce en terme de performance. Dans l hypothèse selon laquelle la plate-forme DIET ne dspose que de serveurs dédés, s une requête soumse à l nstant t reçot une réponse à l nstant t + t et condut au chox d un serveur S, alors toutes les réponses de S à une requête soumse entre les dates t et t + t seront erronées. Dans ce cas de Fgure, la charge de S utlsée pour l évaluaton du temps de calcul du deuxème problème soums ne tent pas compte du premer calcul qu s exécutera sur S lors du lancement du deuxème calcul. La Fgure 9 llustre cet exemple. Nous proposons tros solutons afn de prendre en compte ce rsque : Journalsaton au nveau du : Il faut mantenr un journal des requêtes au nveau du dans lequel sont consgnés la date de soumsson du problème résolu par S, letemps t utle àlarecherche et au chox de ce serveur et l estmaton du temps de page 2

13 SeD t t t + t Req Req Rep Rep Ordre Ordre probleme 2 probleme Fg. 9 Détecton des effets de requêtes crosées. résoluton de ce problème. Ans, pour toute requête émse entre les dates t et t+ t ayant condut au chox du même serveur S, nous devons prendre en compte la décson de résoluton du premer problème par S. Nous proposons alors de remettre en cause le chox de S en ajoutant le temps de résoluton du premer problème au temps estmé de la résoluton du deuxème problème. On se place ans dans le pre des cas selon lequel le serveur S est mono-utlsateur. Dans ce cas, une autre décson est prse, pouvant condure à chosr malgré toutleserveurs. Séquentalsaton au nveau du SeD : Une autre soluton consste à mettre en place un tmestamp dans les appels à Fast afn de rendre la procédurederéservaton séquentelle. La capacté d unserveur peut être sous estmée lorsque les ressources ne sont pas sélectonnées au fnal. Nous perdons en précson au proft d une stablté accrue pour le clent. Cette soluton s applque parfatement dans le cas de l utlsaton du PIF. charge processeur Sans transton, s ce n est la poursute de notre exploraton du projet DIET, nous allons àprésent développer les travaux fat dans le cadre de l extensblté de la plate-forme. Outre le fat de dsposer d une hérarche propce àgérer les problèmes de plate-forme à grande échelle, l peut nous rester un goulot d étranglement dans le cas d une archtecture mono-. Cependant, des solutons exstent au travers de deux mplémentatons de DIET qu offre un nveau mult- (mult-hérarche). Une approche statque écrte en CORBA et une approche dynamque réalsée en JXTA [33]. Nous développerons dans ce rapport cette seconde approche au travers de notre premer prototype. 7. DIET JXTA archtecture Le prototype llustréfgure0 est composédedeux partes : Parte JXTA : composée d un clent JXTA, de JXTA et de SeD JXTA. Le clent est écrt en java et peut se connecter au JXTA. Le clent qu reçot la référence d un serveur se connecte àce derner en utlsant JXTA. Parte nterface DIET : cette parte consste àper- mettre la coopératon de java (langage natf de jxta) et du C++ (langage natf de DIET). La technologe utlsée est JNI 8 qu permet àjava d appeler des fonctons écrtes en C++. JNI est présent dans le code du jxta et dans le code du SeD JXTA. Ans, le jxta est exécuté et communque avec le DIET écrt en C++. JXTA JXTA SeD JXTA DIET SeD DIET Approche par contrat au nveau du clent : Enfn, on peut envsager la mse place d un mécansme de contrat entre les clents et les SeD. Avant de soumettre les données et le calcul le Clent DIET va vérfer que les ressources qu lu sont attrbuées sont encore dsponbles (sans conflt de requêtes crosées), s tel est le cas l peut soumettre dans le cas contrare l utlse le SeD suvant de la lste ou soumet ànouveau la requête àson. Clent JXTA Communcaton CORBA Interface JNI Ppe JXTA JXTA JXTA DIET SeD JXTA DIET SeD DIET 7 Extenson par à par de DIET Fg. 0 Archtecture générale de DIET JXTA. 7.2 Le Clent JXTA Le clent est le seul composant qu est écrt unquement en java. Il communque donc unquement avec des composants JXTA et n utlse donc pas l API clent de DIET. Il communque avec le JXTA et le 8 Java Natve Interface page 3

14 SeD JXTA. Le prncpe de fonctonnement est le suvant : le Clent JXTA est actvé par chargement d un nouveau par. Il récupère la référence àun JXTA en envoyant une requête de découverte afn de retrouver une annonce appelée DIET_.On récupère la premère référence reçue, afn de créer un tube bdrectonnel de communcaton JXTA. On envoe ensute va ce canal de communcaton la descrpton du problème et on attend une réponse du JXTA avec la référence d un serveur. Un déla du temps de réponse est fxé en attendant la verson asynchrone. Une fos la référence du serveur obtenue, on ouvre un tube bdrectonnel de communcaton entre le Clent JXTA et le SeD JXTA. On envoe ensute le problème et les données qu sont encapsulés dans un message JXTA pour l exécuton. Le Clent JXTA dans ce prototype est en verson synchrone et attend donc le résultat. 7.3 Le SeD JXTA Le rôle du SeD JXTA est de permettre au clent d envoyer son problème et surtout ces données en utlsant le protocole de communcaton JXTA. Cette fonctonnalté estégalement une soluton permettant de franchr les pare-feux. Le SeD JXTA réalse également le transfert de ces nformatons aux SeD en utlsant JNI. Le mode de fonctonnement du SeD JXTA est le suvant : on exécute sur le serveur un par JXTA. On crée un tube en entrée qu se met en attente des requêtes clents. Le SeD JXTA lance le SeD DIET avec JNI et se place en attente d un message depus le clent. Lorsque les données arrvent par le tube de communcaton JXTA, elles sont échangées par JNI avec le DIET. Ce derner retranscrt alors les données selon les structures DIET. Pus un processus smlare est ms en place pour le retour du résultat. 7.4 Le JXTA Le JXTA est drectement connecté aux Clent JXTA et aux autres JXTA.Les JXTA publent une annonce avec une durée de ve afn de mnmser les tentatves de connectons nfructueuses. Lorsque le JXTA reçot une requête, l la fat suvre au DIET et bénéfce alors des mécansmes de détecton de serveur et d ordonnancement que fourn DIET. S la hérarche du DIET nterrogé ne peut répondre àlarequête (pas de serveur dsponble, problème nconnu, etc.), la requête est alors envoyée àunautre JXTA et ans de sute. Le prototype est basé sur une verson séquentalsémasdes algorthmes plus effcaces sont en cours d mplémentatons. Le résultat de la recherche est alors renvoyé au clent. Le mode de fonctonnement du JXTA consste à charger un par JXTA qu construt un tube de communcaton et se met en attente de requêtes du Clent JXTA ou de requêtes propagées par un autre JXTA. Il crée une annonce (appelée DIET_)) avec la référence du tube en entrée permettant de se connecter àce JXTA, de plus un thread puble une annonce qu a une durée de ve lmtée. Le JXTA est alors en attente d un message en provenance d un clent ou d un agent. A l arrvée d une requête en provenance d un clent ou d un JXTA,dansle DIET le message JXTA est convert selon les types DIET et est soums au DIET. S aucun SeD DIET ne peut répondre àla requête, elle est envoyée àunautre JXTA s la requête venat d un clent. S la requête provenat d un autre JXTA une réponse négatve est envoyée au JXTA qu avat fat suvre la requête. Cet algorthme utlsé pour le prototype correspond donc à l exploraton d un graphe en étole. 7.5 Concluson La dsponblté duprototypediet JXTA dans la verson courante de DIET est planfée pour l été Des algorthmes plus élaborés de recherche de servces basés sur les travaux ntés dans [0] pour amélorer le parcours des hérarches DIET afn d accélérer le temps de réponse pour le clent sont en cours de valdaton. 8 Déploement et vsualsaton de la plate-forme 8. Étude pour le déploement automatque De nombreux travaux exstent sur le déploement mas dans la plupart des cas l s agt d outls facltant la procédure de déploement logcel à dstance [8, 9]. Mas ces outls ne fournssent aucun support pour un déploement automatque effcace sachant tenr compte des besons de la plate-forme à déployer. Le projet WebCom-G propose un redéploement par reconfguraton des composants, ce qu est une vson plus proche de ce que nous souhatons dans le cadre de DIET. Dans [9] nous avons nté destravaux permettant de fournr une modélsaton adant à la mse en place d un déploement automatque. Nous allons décrre c les grands prncpes de cette modélsaton. page 4

15 8.. Modèle de déploement hérarchque L archtecture cble est représentée par un graphe valué G =(V,E,w,c). Chaque P V représente une ressource de calcul de pussance w,cequsgnfe quelenœudp exécute w MFlops par seconde (ans plus w est grand, plus P est une ressource de calcul rapde). Il y a un nœud clent, c est-à-dre un nœud P c,qugénère les requêtes 9. Chaque len P P j est étqueté par la valeur de la bande passante c,j qu représente la talle des données envoyées par seconde entre P et P j. L unté utlsée pour la bande passante d un len est le Mb/second. La talle de la requête générée par le clent est de et la talle des requêtes de réponse créées par chaque nœud est de talle S (out). L unté utlsée pour ces quanttés est en Mb/requête. La quantté decalculnécessare à P pour trater une requête entrante est noté W (n) et la quantté decalculnécessare à P pour agréger les réponses aux requêtes provenant des fls est noté W (out). Nous consdérons que W (DGEMM ) correspond àlaquanttédecalculnécessare à P pour trater un problème générque (par exemple la foncton DGEMM ssue des BS [4] et qu correspond à la multplcaton matrcelle). Nous avons sélectonné cette foncton, car nous savons avor une bonne prédcton de performance [] etpeutse modélser faclement selon des contrantes lnéares. Le modèle archtectural que nous avons défn dans [9] ne prend pas en compte la geston des données, nous nous focalsons sur les applcatons dont les données sont déjà présentes sur le serveur (pour des rasons de sécurté, ou selon la contrante du modèle de programmaton). Par alleurs, l peut être facle d ajouter la geston des données comme un nouveau nveau du modèle. Pour cela, le gestonnare de données dot être capable de fournr des nformatons sur les temps de transfert des données. Dans le même ordre d dée et pour les mêmes rasons, sgnalons que nous consdérons comme néglgeable la geston du résultat. talle S (n) 8..2 Opératons en régme permanent Notreobjectfestdecomparerlenombrederequêtes maxmum que l archtecture déployée peut gérer par seconde. Cette valeur nous sert ensute à comparer et détermner quelle est la melleure arch- correspond au nombre de requêtes entrantes (c est-à-dre les requêtes provenant du clent) gérées par P durant une unté de temps. Notons, que tecture. α (n) 9 Par smplfcaton, nous ne consdérons c qu un seul clent. La modélsaton étendue à pluseurs clents avec dfférents problèmes que l on sat estmer est facle cette valeur, n est pas forcément une valeur entère mas peut être un ratonel. De la même façon, α (out) correspond au nombre de requêtes sortantes (chox du melleur serveur basé sur l ensemble des réponses) calculées pendant une unté de temps par le nœud P. α (DGEMM ) représente le nombre de problèmes qu peuvent être résolus par le nœud P,sP est un serveur. Le nombre de requêtes tratées pendant une unté de temps est dépendant de la bande passante du len, de la talle de la requête, de la fracton de requête qu peut être calculée pendant cette unté de temps et de la pussance du processeur. Par conséquent nous avons les contrantes suvantes : Ressources de calcul pour les agents : P : α(n) W (n) + α (out) W (out) w Notons qu l est nécessare pour chaque requête entrante d avor une réponse correspondante et, chaque requête est dffusée sur l ensemble de la hérarche (notre servce étant dsponble sur l ensemble de nos nœuds), ans l n y a pas de dfférence entre α (n) et α (out) qu sont tous les deux égaux au débt maxmum de la plate-forme ρ. L équaton précédente peut alors être smplfée comme sut : P : ρ W (n) + W (out) w () Ressources de communcaton : Il y a ρ requêtes pour le calcul et ρ réponses à ces requêtes qu sont transmses par unté de temps sur chaque len P P j. Nous avons donc : P P j : ρ S (n) + S (out) j (2) c,j Contrantes de calcul des serveurs : Chaque serveur P calcule α (DGEMM ) problèmes par unté de temps. Nous avons alors : P P est un serveur : α(dgemm ) W (DGEMM ) w Toutes ces valeurs sont lées à ρ par l équaton ρ =. Nous avons alors : P P est un serveur ρ P P est un serveur α (DGEMM ) w W (DGEMM ) (3) page 5

16 Pas de parallélsme nterne : Dans ce modèle, le calcul et les autres opératons sont effectués par chaque nœud séquentellement, ans la somme de toutes ces opératons réalsées par un agent pour une unté de temps dot être nféreur à l unté de temps. C est pour cette rason que pour tout P nous pouvons écrre : ρ S (n) parent() + S (out) + c parent(), c parent(), } {{ } Communcatons avec son père ρ (n) S + S (out) j + P P j c,j } {{ } Communcatons avec son fls ( ) ρ W (n) + W (out). w } {{ } Calcul local (4) NotonsqueslecalculsurP peut être effectuéen parallèle avec les communcatons, la contrante précédente dot être modfée ans : ρ S (n) parent() + S (out) + c parent(), c parent(), } {{ } Communcatons avec son père ρ (n) + S (out) j. P P j S c,j } {{ } Communcatons avec son fls (5) Théorème. Le nombre maxmum de requêtes qu peuvent être tratées par la plate-forme en régme permanent est donné par l équaton (6). Théorème 2. Lorsqu on souhate maxmser le débt, au mons une des contrantes (), (2), (3), (4) et (5) est à sa lmte. Cette contrante représente alors le goulot d étranglement de la plate-forme Déploement automatque et redéploement Même s nous néglgeons les contrantes des serveurs, trouver la melleure topologe est un problème dffcle pusqu l s agt de trouver le melleur arbre de dffuson dans un graphe générque, problème connu comme étant NP-complet [6]. Notons également que même s nous néglgeons le mécansme des requêtes, en ne prenant pas en compte les communcatons ndutes par la geston des données, le problème de trouver le melleur est également NP-complet [5]. Cependant, dans la pratque, le chox de la topologe pour le déploement est fortement nfluencé par la plate-forme physque sous-jacente. C est pour cette rason que nous suggérons d amélorer le débt d une plate-forme donnée (on parle alors de redéploement) en localsant et en supprmant le goulot d étranglement. A l ade des théorèmes et 2 nous pouvons trouver le goulot d étranglement et le supprmer le cas échéant en ajoutant par exemple plus de à un agent parent qu est trop chargé afn de dvser sa charge. L algorthme 3 est un algorthme glouton qu réalsecetypedeprocédure. La lgne 3 de cet algorthme vérfe s l est possble ou non de dvser la charge d un nœud. Il y a pluseurs rasons pour laquelle cette condton ne peut être vérfée, par exemple un nœud P ne dspose que d un serveur de calcul, on ne peut donc pas dvser sa charge. S un nœud supplémentare est dsponble l peut alors être ajouté pourévter le goulot d étranglement (cf. lgne 7). Les nformatons nécessares au déploement de ce supplémentare seront automatquement récupérées dans le fcher XML de descrpton de la plate-forme (vor secton 8.2). La charge du responsable du goulot d étranglement sera alors dvsé avec ce nouvel. Une autre stratége pour l ajout d un composant afn de supprmer le goulot d étranglement est de modfer le rôle d un composant. On peut par exemple sacrfer une ressource SeD en ressource. Un prochane étape dans le déploement automatque sur laquelle nous travallons concerne justement la confguraton automatque des composants de la plate-forme. Enfn, nous comptons trer parte de cette étude théorque afn d amélorer notre outl de déploement. : whle (Nombre de nœuds dsponbles > 0) do 2: Calculer le débt ρ de la structure. 3: Trouver un nœud pour lequel les contrantes sont lmtes et qu peut être dvsé 4: f un tel nœud n exste pas then 5: Le deploement ne peut être amélroré. 6: Sorte endf 7: Dvser la charge par l ajout d un nouveau nœud comme parents 8: Dmnuer le nombre de serveurs dsponbles endwhle Algorthme 3: Algorthme pour ajouter un page 6

17 ρ =mn W (n) w + W (out), S (n) S (n) parent() c parent(), + S (out) c,j + S (out) j c parent(), + S (n) P P j, w P P est un serveur W (DGEMM ) +S (out) j c,j + W (n) +W (out) w, (6) 8.2 GoDIET : un outl de déploement L objectf de GoDIET est de fournr un outl facltant le déploement de plate-formes DIET sur la grlle. Comme le montre la fgure, l admnstrateur d une plate-forme DIET va fournr un fcher XML contenant les nformatons nécessares au déploement : descrpton de la hérarche des composants, machnes physques, espace dsque où seront déposés ces composants et leurs données, localsaton des bnares pour le lancement des composants, etc. Fg. Archtecture de GoDIET. Le prototype de GoDIET est écrt en java, et fonctonne avec une console offrant des fonctonnaltés tel que le déploement de la plate-forme conformément au fcher XML, l affchage du statut des nœuds (Exemple : machne est ) ou encore la possblté de stopper la plate-forme. Pour charger la plate-forme présentée fgure 2 (comprenant 25 SeD, 6 et ) sur VTHD, l a fallu à GoDIET mnute et 42 secondes. Ce temps comprend le temps d ntalsaton de DIET (sans FAST), de VzDIET, de GoDIET et de Log- Servce. L arrêt de la plate-forme prend 53 secondes. L objectf vsé àprésent est d avor une melleur ntégraton de l ensemble de ces outls. Notamment que VzDIET ne sot plus un smple outl de vsualsaton mas qu l offre des fonctonnaltés permettant d nteragr sur GoDIET, et donc d admnstrer la plateforme. 8.3 LogServce : un outl de geston de traces LogServce est un logcel de génératon de fcher de traces (fcher de log) développé pour un envronnement dstrbué tel que DIET. Ce logcel permet de suvre, par échange de fchers texte, les traces d exécuton des dfférents agents DIET. LogServce est composé de deux modules : le Log- Central et LogManager. Le LogManager est stué sur chaque agent et permet de collecter les nformatons et de les envoyer au LogCentral. Celu-c collecte tous les messages des LogManager et met àjourunfcher de logs. Ce logcel permet une synchronsaton des messages de traces entre les agents et le LogCentral. En effet, l peut y avor des horloges dfférentes entre les dfférents agents et la machne sur laquelle tourne LogCentral. Cette synchronsaton se fat grâce àdes estmatons réalsées régulèrement à l ade de FAST et de NWS. Cet outl a été développé en C++ et s appue, tout comme DIET, sur CORBA pour réalser les communcatons entre les LogManager et le LogCentral. Notons que l ntégraton du LogServce dans DIET sera dsponble dès la verson VzDIET : un outl de vsualsaton VzDIET est un outl graphque écrt en Java capable de représenter les traces générées par LogServce. Basé sur la lbrare Java OpenJGraph 0. Cette lbrare permet de dessner des graphes orentés ou non, des hypergraphes, etc. La représentaton est en deux dmensons ce qu permet d ajouter ou de retrer des nœuds avec une certane souplesse. VzDIET peut sot lre un fcher de traces en temps réel (cf. fgure 2) ou en post-mortem. Il ne supporte que le format de LogServce et trate les messages dans 0 page 7

18 l ordre d apparton dans le fcher de log tout en générant l archtecture et les nformatons correspondantes. L outl permet une réorgansaton spatale automatque à l ajout ou la suppresson de noeuds. Son rôle est de permettre de suvre les connectons entre les agents, ou avec le clent. VzDIET a pour vocaton à long terme de servr d nterface graphque àlafos pour DIET, GoDIET et LogServce. Ce qu offrra à l outl une nteractvté plus mportante. 9 Concluson Cet artcle a pour objectf de synthétser les recherches et les développements réalsés dans le cadre du projet DIET. Tout comme NetSolve et NINF, cet ntergcel pour la grlle offre une alternatve ntéressante aux outls de grlle ssus de Globus. L objectf commun de ces tros ntergcels outre le fat qu ls dsposent du même paradgme de programmaton (le GrdRPC) est d obtenr de bonnes performances. Pour cela une ntégraton plus forte des applcatons (notamment au nveau des ordonnanceurs) est possble. DIET vse également l extensblté. Les tests menés jusqu à ce jour sont encourageants, un déploement sur Grd 5000 nous permettra de valder expérmentalement, l effcacté de DIET sur une plate-forme à grande échelle. Nos travaux sur le déploement seront par la-même ms àl épreuve. DIET se veut une plate-forme stable et facltant l ntégraton effcace d applcatons sur la grlle. 0 Remercements Les auteurs tennent à remercer toutes les personnes qu ont contrbué au développement de DIET tant au pont de vue théorque que pratque. Un merc tout partculer à Raphaël Bolze, Marc Boury, Phlppe Combe, Pushpnder Kaur Chouhan, Cédrc Tedsch, Holly Dal, Bruno DelFabbro, Georg Hoesh, Arnaud Legrand, Frédérc Lombard, Jean-Marc Ncod, Franck Pett, Laurent Phlppe, Chrstophe Pera, Cyrlle Pontveux, Martn Qunson, Alan Su et Frédérc Suter pusque sans leurs travaux, ce tour d horzon ne pourrat exster. Références []E.Anderson,Z.Ba,C.Bschof,S.Blackford, J. Demmel, J. Dongarra, J. Du Croz, A. Greenbaum, S. Hammarlng, A. McKenney, and D. Sorensen. PACK Users Gude, Thrd Edton. SIAM, Phladelpha, PA, 999. ISBN [2] Gabrel Antonu, Luc Bougé, and Matheu Jan. JuxMem : An Adaptve Supportve Platform for Data Sharng on the Grd. In IEEE/ACM Workshop on Adaptve Grd Mddleware, held n conjuncton wth 2th Intl. Conf. on Parallel Archtectures and Complaton Technques (PACT 2003), New Orleans, September [3] P. Arbenz, W. Gander, and J. Mor. The Remote Computatonal System. Parallel Computng, 23(0) :42 428, 997. [4] Satsh Balay, Wllam D. Gropp, Los Curfman McInnes, and Barry F. Smth. PETSc home page. http :// [5] Cyrl Banno, Olver Beaumont, Arnaud Legrand, and Yves Robert. Schedulng strateges for master-slave taskng on heterogeneous processor grds. In PARA 02 : Internatonal Conference on Appled Parallel Computng, LNCS Sprnger Verlag, [6] Olver Beaumont, Arnaud Legrand, Lors Marchal, and Yves Robert. Optmzng the steadystate throughput of broadcasts on heterogeneous platforms. Techncal Report , LIP, June [7] A Bu, AK Datta, F Pett, and V Vllan. Optmal PIF n tree networks. In Proceedngs of DI- CS Workshop on Dstrbuted Data and Structures, pages 6. Carleton Unverty Press, 999. [8] E. Caron, S. Chaumette, S. Contassot-Vver, F. Desprez, E. Fleury, C. Gomez, M. Goursat, E. Jeannot, D. Lazure, F. Lombard, J.-M. Ncod, L. Phlppe, M. Qunson, P. Ramet, J. Roman, F. Rub, S. Steer, F. Suter, and G. Utard. Sclab to Sclab//, the OURAGAN Project. Parallel Computng, (27) :497 59, OCT 20. [9] Eddy Caron, Pushpnder Kaur Chouhan, and Arnaud Legrand. Automatc Deployment for Herarchcal Network Enabled Server. In The 3th Heterogeneous Computng Workshop (HCW 2004), Santa Fe. New Mexco, Aprl [0] Eddy Caron, FrédércDesprez, FranckPett, and Vncent Vllan. A Herarchcal Resource Reservaton Algorthm for Network Enabled Servers. In IPDPS 03. The 7th Internatonal Parallel and Dstrbuted Processng Symposum, Nce - France, Aprl [] Eddy Caron and Frédérc Suter. Parallel Extenson of a Dynamc Performance Forecastng page 8

19 Fg. 2 Cope d écran de VzDIET Tool. In Proceedngs of the Internatonal Symposum on Parallel and Dstrbuted Computng, pages 80 93, Ias, Romana, Jul [2] E.J.H. Chang. Echo algorthms : depth parallel operatons on general graphs. IEEE Transactons on Software Engneerng, SE-8 :39 4, 982. [3] F. Desprez, M. Qunson, and F. Suter. Dynamc Performance Forecastng for Network Enabled Servers n a Metacomputng Envronment. In Proceedngs of the Internatonal Conference on Parallel and Dstrbuted Processng Technques and Applcatons (PDPTA 20), 20. [4] J.J. Dongarra, J. Du Croz, I. Duff, and S. Hammarlng. A Set of Level 3 Basc Lnear Algebra Subprograms. ACMTMS, 6() : 7, 990. [5] Glles Fedak, Cecle German, Vncent Ner, and Franck Cappello. XtremWeb : A Generc Global Computng Platform. In CCGRID 20 Specal Sesson Global Computng on Personal Devces. IEEE press, May 20. [6] I. Foster and C. Kesselman (Eds.). The Grd : Blueprnt for a New Computng Infrastructure. Morgan-Kaufmann, 998. [7] I. Foster and C. Kesselman. The Globus project : A status report. In Proceedngs of the Heterogeneous Computng Workshop, pages 4 8, 998. [8] JXTA Dstrbuted Framework. [9] N.Furmento,W.Lee,S.Newhouse,andJ.Darlngton. Test and Deployment of ICENI, an Integrated Grd Mddleware on the UK e-scence Grd. In AHM 2003, Nottngham, Aprl [20] M. Good and J.-P. Goux. MW : A web-based problem solvng envronment for grd computng applcatons. Techncal report, Department of Electrcal and Computer Engneerng, Northwestern Unversty, [2] Tomasz Haupt, Erol Akarsu, and Geoffrey Fox. WebFlow : a framework for Web based metacomputng. Future Generaton Computer Systems, 6(5) :445 45, March [22] J.Cho, J. Demmel, I. Dhllon, J. Dongarra, S. Ostrouchov, A. Pettet, K. Stanley, D. Walker, and R.C. Whaley. PACK Workng Note : Sca- PACK : A Portable Lnear Algebra Lbrary for Dstrbuted Memory Computers - Desgn Issues and Performances. Techncal Report 95, UT, 995. [23] N. Kapada, J. Robertson, and J. Fortes. Interfaces Issues n Runnng Computer Archtecture Tools va the World Wde Web. In Workshop on Computer Archtecture Educaton at ISCA 998, Barcelona, [24] Raner Keller, Bettna Krammer, Matthas S. Mueller, Mchael M. Resch, and Edgar Gabrel. MPI Development Tools and Applcatons for the Grd. In Workshop on Grd Applcatons and page 9

20 Programmng Tools, held n conjuncton wth the GGF8 meetngs, Seattle, June [25] Legon. [26] Andrew Lews, Davd Abramson, Ian Foster, Jon Gddy, Nel Whte, Robert Sutherst, and Rok Sosc. The Nmrod Computatonal Workbench : A Case Study n Desktop Metacomputng. In Macquare Unversty, edtor, Australan Computer Scence Conference (ACSC 97), Sydney, Feb 997. [27] S. Matsuoka and H. Casanova. Network-Enabled Server Systems and the Computatonal Grd, July Grd Forum, Advanced Programmng Models Workng Group whtepaper (draft). [28] S. Matsuoka, H. Nakada, M. Sato,, and S. Sekguch. Desgn Issues of Network Enabled Server Systems for the Grd, Grd Forum, Advanced Programmng Models Workng Group whtepaper. [29] MPICH-G. [30] NEOS. [3] NetSolve. [32] NINF. [33] Scott Oaks, L Gong, and Bernard Traversat. JXTA n a Nutshell. O Relly & Assocates, Inc., 98 Chestnut Street, Newton, 0264, USA, [34] Martn Qunson. Dynamc performance forecastng for network-enabled servers n a metacomputng envronment. In To appear n Internatonal Workshop on Performance Modelng, Evaluaton, and Optmzaton of Parallel and Dstrbuted Systems (PMEO-PDS 02), Apr [35] A. Segall. Dstrbuted network protocols. IEEE Transactons on Informaton Theory, IT-29 :23 35, 983. [36] Keth Seymour, Hdemoto Nakada, Satosh Matsuoka, Jack Dongarra, Crag Lee, and Henr Casanova. Overvew of GrdRPC : A Remote Procedure Call API for Grd Computng. In Mansh Parashar, edtor, Grd Computng - GRID 2002, Thrd Internatonal Workshop, Baltmore, MD, USA, November 8, 2002, Proceedngs, volume 2536 of LNCS, pages Sprnger, [37] R. Wolsk, N. T. Sprng, and J. Hayes. The Network Weather Servce : A Dstrbuted Resource Performance Forecastng Servce for Metacomputng. Future Generaton Computng Systems, Metacomputng Issue, 5(5 6) : , Oct page 20