Action Concertée Incitative masses de donnees descriptif complet du projet

B.2 Etudes associées au projet de plate-forme

Cette partie présente les études et les équipes de chercheurs associées à “ Data Grid Explorer ”.

Les travaux sont regroupés dans deux catégories : I) Construction de l’instrument et II) Etudes/expériences associées à l’instrument.

B.2.I) Construction de l’instrument
I.1 Grid Explorer : définition de la plate-forme matérielle et logicielle

Franck Cappello, Pascale Primet, Olivier Richard, Kavé Salamatian, Pierre Sens

Concevoir une plate-forme d’émulation multi-disciplinaire qui puisse servir les expériences de Grid/P2P, réseau et système représente la toute première étape du projet. Les acteurs de ce travaille sont les représentants des différentes communautés et les animateurs de thèmes.
De nombreuses questions doivent trouver des réponses concernant l’architecture et la production d’expériences.

Questions relatives à l’architecture de la plate-forme :

-quelle est l’architecture des nœuds de la plateforme (mono ou bi processeurs) ?

-les nœuds doivent ils être uniforme ?

-combien de cartes d’extensions doivent pouvoir être introduites dans les nœuds ?

-tous les nœuds doivent ils comporter les mêmes possibilités d’extension ?

-quelles doivent être les technologies réseau à utiliser ?

-quelles doit être la topologie d’interconnexion.

-la topologie doit-elle être homogène sur toute la plate-forme.

-la topologie doit-elle être configurable et si oui par quel moyen ?

-quel système d’exploitation est souhaitable ?

-doit-on pouvoir dynamiquement modifier de système d’exploitation pour les besoins d’une expérience ?

-doit-on pouvoir ajouter-retirer dynamiquement des packages système pour les besoins d’une expérience ?
Questions relatives à la production d’expériences.

-les expériences doivent-elles être lancées sur la machine de façon interactive et ou Batch ?

-faut-il pouvoir partitionner la machine ?

-doit-on installer un système d’ordonnancement sophistiqué qui déciderai d’optimiser le temps d’exploitation de la plate-forme (minimisation du temps de reconfiguration) au détriment du temps de retour des expériences ?

-des expériences pouvant être composées d’une étude paramétrique, comment garantir l’équité du partage de ressources tout en faisant progresser ces expériences ?

-comment les données relatives aux expériences sont-elles stockées ?

-comment les résultats sont ils stockés ?

-est-il souhaitable (ou peut-on) de mettre en place un pipeline d’exécution d’expérience qui transfèrerai les résultats d’une expériences terminée pendant l’exécution d’une expérience et le transfert des données relatives à l’expérience suivante ?

Définir les principes/méthodes/techniques permettant l’exécution rigoureuse d’expériences sur Data Grid Explorer

* Définir une politique d’exploitation de la plate-forme connectés de sorte que l’expérimentation soit possible et les résultats d’expériences pertinents.

* Définir une méthode et identifier les outils d’administration/maintenance de la plate-forme.

* Définir une politique de sécurité et sa mise en œuvre (firewall, accounting, certificats, etc.), qui permettent la réalisation d’expérience au niveau national.

 

I.1 VGrid : Un émulateur de systèmes à grande échelle

Aurélien Bouteiller, Franck Cappello, LRI, CNRS, INRIA “ Grand Large ”

I.1.1 Objectifs et contexte 

L’étude des Grid et des systèmes repose sur des simulateurs (SimGrid [1], MicroGrid[2]) ou des plates-formes de production (DataGRid, EuroGrid, TeraGrid, J-Grid). Les systèmes qui sont émulés sont généralement trop complexes pour qu'une analyse théorique permette leur étude. Ils sont aussi trop dépendants de paramètres temporels et structurelles fins pour que la simulation puisse rendre compte systématiquement de leur comportement. Leur observation in-situ comporte d'autres limitations (charge, configuration) qui empêchent la généralisation des résultats. Nous proposons de compléter ces moyens pas un émulateur de systèmes à grande échelle : VGird.

Un émulateur permet d’exécuter des expériences en utilisant une application réelle, dans des conditions reproductibles et un environnement contrôlé. Plusieurs initiatives récentes visent à mettre à la disposition des chercheurs en informatique (réseau et systèmes répartis) des grands émulateurs. C’est le cas notamment pour le projet Emulab [3] qui permet l’émulation de réseaux (www.emulab.net). Il n’existe pas actuellement d’émulateur de systèmes à grande échelle.
I.1.2 Description du projet

L’objectif est de concevoir des mécanismes systèmes permettant de reproduire, sur n nœuds de la plate-forme d’émulation, le comportement de m nœuds de la grille ou d’un système P2P (m>>n) avec une précision de reproduction connue. La dilatation temporelle devra être maîtrisée et contrôlée de sorte que les événements inter nœuds interviennent à des instants compatibles avec un fonctionnement réel.

Les systèmes à émuler seront des systèmes distribués à grande échelle comme Gnutella[4], Freenet[4], XtremWeb[5], ou des parties de ce type de systèmes, comme les mécanismes de recherche de ressource Pastry[6], Tapestry[7], CAN[8], Chord[9]. Ce thème comporte deux aspects : 1) étudier les mécanismes nécessaires à la reproduction de conditions et 2) la virtualisation.
Les conditions à reproduire concernent les caractéristiques matérielles, de volatilité et de charge des nœuds qui composent le système à émuler et le réseau. Il faut être capable de reproduire certains paramètres d’un environnement existant avec une précision connue. Ceci suppose la conception de sondes capables d’extraire ces caractéristiques et de mécanismes d’émulation capables d’appliquer ces caractéristiques sur des ressources génériques. Les sondes de volatilité et de charge existent déjà pour les noeuds du système dans XtremWeb. Les sondes concernant le réseau sont à étudier. Le système NWS [10] pourra être pris comme référence pour cette partie. Les mécanismes d’émulation sont à étudier. Il s’agit de reproduire les caractéristiques des nœuds (taille mémoire – inférieure à celle de la machine d’émulation, vitesse CPU – inférieure à celle de la machine d’émulation) et du réseau (débit, latence, contention, etc.) de façon logicielle et d’être capable connaître la précision de reproduction.
La virtualisation maîtrisée consiste à émuler sur un nombre de ressources limité (100 noeuds), un système composé de plusieurs milliers de noeuds. Comme il s’agit d’exécuter l’application complète, la virtualisation se traduit par une dilatation temporelle : la durée d’exécution est supérieure à celle du système dans un environnement réel. La virtualisation maîtrisée consiste à contrôler de façon précise le temps des événements dans l’environnement virtuelle (temps virtuel).
I.1.3 L’échéancier des résultats et réalisations

Le projet comporte 3 étapes.

De T0 à T0+12 : La première année consistera à construire les mécanismes permettant la virtualisation. Il s’agira de mettre en œuvre des mécanismes de checkpoint et de loggs de message pour permettre la virtualisation de m nœuds sur n PC (avec n<De T13 à T0+24 : La deuxième année sera consacrée au mécanisme d’injection de traces dans l’émulateur et à la mise en œuvre un ensemble de sondes réseau et d’activité CPU. Le système de sondes sera basé soit sur NWS, soit sur XtremWeb (associé à une application de mesure de performance réseau), soit encore sur l’environnement La Grenouille qui mesure les performances de l’ADSL en France.
De T15 à T0+36 : La troisième année sera consacrée au test de systèmes existants à grande échelle et à la comparaison des résultats obtenus par émulation et ceux obtenus sur les plates-formes réelles (par exemple la plate-forme XtremWeb sur le Campus d’Orsay).
I.1.4 Références

[1] H. Casanova, Simgrid: A Toolkit for the Simulation of Application Scheduling, Proceedings of the First IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGrid 2001), IEEE Press, May 15-18, 2001, Brisbane, Australia.

[2] Song, Liu, Jakobsen, Bhagwan, Zhang, Taura and Chien, The MicroGrid: a Scientific Tool for Modeling Computational Grids , in Proceedings of SC2000.

[3] White, Lepreau, Stoller, Ricci, Guruprasad, Newbold, Hibler, Barb, and Joglekar, An Integrated Experimental Environment for Distributed Systems and Networks, Proceedings of OSDI 2002, December 2002

[4] A. Oram, “Peer-to-Peer: harnessing the power of disruptive technologies”, edition O’Reilly, Mars 2001.

[5] F. Cappello et al., XtremWeb : une plate-forme de recherche sur le calcul global et pair à pair, chapitre 6 du livre Calcul réparti à grande échelle, metacomputing, sous la direction de Françoise Baude, lavoisier, 2002.

[6] A. Rowstron and P. Druschel, Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems,  IFIP/ACM International Conference on Distributed Systems Platforms (Middleware), Heidelberg, Germany, pages 329-350, November, 2001.

[7] B. Y. Zhao, J. D. Kubiatowicz, and A. D. Joseph, Tapestry: An Infrastructure for Fault-tolerant Wide-area Location and Routing, U. C. Berkeley Technical Report UCB//CSD-01-1141, April 2000.

[8] S. Ratnasamy, P. Francis, M. Handley, R. Karp, S. Shenker, “A Scalable Content-Addressable Network”, Proceedings of ACM SIGCOMM 2001

[9] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan, “Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications”, ACM SIGCOMM 2001, San Deigo, CA, Aug. 2001.

[10] R. Wolski, N. Spring, J. Hayes, The Network Weather Service: A Distributed Resource Performance Forecasting Service for Metacomputing, Journal of Future Generation Computing Systems,Volume 15, Numbers 5-6, pp. 757-768, October, 1999

 

I.3 GRIGrid : Gestion des Ressources Internes à la Grid

Raymond Namyst, Pierre-André Wacrenier, Vincent Danjean, Guillaume Mercier, LaBRI,

UMR 5800 CNRS, action INRIA “ Runtime ”

I.3.1 Objectifs et contexte

L’exploitation d’une plate-forme de grande taille pour l’émulation requiert la mise au point d’un support exécutif capable à la fois d’exploiter efficacement la configuration matérielle sous-jacente (grappe de 1000 PC potentiellement interconnectée à d’autres grappes) et d’offrir l’ensemble des fonctionnalités nécessaires à la mise en œuvre des simulations (virtualisation, paramétrage et mesures). Nous proposons de participer à la définition et la mise au point d’un support réalisant des communications performantes et autorisant un contrôle fin du déroulement des applications. Ce support exécutif servira de fondation pour la construction de l’émulateur VGrid. Pour ce faire, nous nous appuierons sur les compétences de l’équipe en matière de communications hautes performances (interface de communication Madeleine) et de techniques d’ordonnancement multithread sur machines multiprocesseurs (Marcel, LinuxActivations).

1.3.2 – Description du projet

En ce qui concerne les communications, il s’agit d’abord d’être capable d’assurer le multiplexage d’un grand nombre de canaux de communications simultanées sous des contraintes dictées par le matériel et par les paramètres de l’émulation : outre les problèmes de performances (que nous maîtrisons pour les configurations de taille moyenne), il s’agit résoudre un problème de qualité de service dans les réseaux hautes performances, afin d’assurer une progression des communications qui soit compatible avec les contraintes du “ temps émulé ” sur chaque canal. Il s’agira aussi de simuler des configurations hétérogènes, requérant la mise en place de techniques de communication multi protocoles (routage). Ce travail requiert une bonne connaissance du fonctionnement des passerelles hautes performances que nous étudions actuellement au sein de notre équipe.

Pour la maîtrise de l’ordonnancement des différents processeurs virtuels de la configuration, nous proposons d’adapter et d’enrichir nos techniques d’ordonnancement multi-niveaux afin de pouvoir programmer / contrôler l’ordonnancement aux niveaux inter et intra processus et de faciliter la prise de mesures précises du temps d’exécution consommée par une application sur des architectures complexes (par exemple, mesurer et contrôler finement la consommation d’un thread sur un processeur hyperthreadé).
1.3.3 Résultats attendus

1 année : livraison des prototypes d’ordonnanceur multi-niveaux  et du multiplexeur de communication haute performance ;

2^èreème année : livraison de l’ordonnanceur multi-niveaux, du multiplexeur de communications hautes performances et des outils de profilage des programmes multi-threadés ;

3^ème année : intégration d’éléments de qualité de service dans la communication haute performance.

I.5 Construction d’un émulateur “ nuage réseau ” de grille et calibrage des outils de mesures de performance réseau.

Pascale Vicat-Blanc Primet, Brice Goglin (doctorant), Faycal Bouhaf (DEA)(INRIA LIP RESO)

 

I.5.1 Objectifs et contexte

On précisera, en particulier, les verrous scientifiques et technologiques à dépasser, l’état de l’art ainsi que les projets concurrents ou similaires connus dans le contexte national et international, en particulier ceux auxquels les équipes du projet participent.

Au cours des dix dernières années, avec la généralisation de la fibre optique, l'infrastructure de coeur des réseaux a évolué très rapidement en débit et en fiabilité. On envisage pour un futur très proche l'utilisation de liens de capacité de plusieurs dizaines voire centaines de Gbits/s. Des capacités d'accès à 10Gb/s sont aussi déjà en cours d'expérimentation. Ces progrès dans la technologie réseau ont rendu possible la construction de systèmes répartis haute-performance dont certains des constituants sont des grappes de PC ou des calculateurs parallèles et que l'on nomme "grilles" de calcul.
Un des importants défis de ces grilles est de concilier deux opposés : d'un côté un “ nuage réseau ” étendu qui exhibe une extrême hétérogénéité de performance et de fiabilité et de l'autre des mouvements de données, qui sont des déterminants critiques des performances des applications.
Ainsi, bien que les grilles offrent un potentiel considérable par l'agrégation de ressources, la performance d'exécution des applications peut être délicate à obtenir en pratique à cause de l'inadéquation des protocoles et des logiciels de transfert de données. Le volume de données acquises, générées et transportées par les applications scientifiques changeant d'ordre de grandeur et en passe d'atteindre l'échelle du teraoctet amène des problématiques nouvelles liées principalement au facteur d'échelle, à l'hétérogénéité et la dynamicité à de multiples niveaux. Ces problématiques appellent de nouveaux paradigmes de programmation, des logiciels de contrôle appropriés mais aussi des protocoles de communication efficaces et spécifiques. En effet l'instabilité et la nature imprévisible de la charge et de la disponibilité des liens réseau utilisés pendant les transferts de données peut handicaper un ordonnanceur de travaux en charge de déterminer l'enchaînement efficace des programmes. Une plus grande maîtrise des paramètres débit et délai au niveau transport de bout en bout est donc nécessaire.
Plusieurs projets de déploiement de plate-formes expérimentales à grande échelle ont été initiés ces dernières années. Nous pouvons citer en particulier VTHD++ et le projet RNTL eToile en France, les projets européens DataGRID basé sur les infrastructures des réseaux de la recherche européen et DataTAG basé un lien expérimental cofinancé par la NSF entre le CERN et Chicago, projets dans lesquels l’équipe RESO est impliquée. Ces projets de construction d'infrastructures lourdes sont particulièrement coûteux et long à mettre en oeuvre. Par exemple, dans eToile, il a fallu plus d'un an pour raccorder 5 sites à l'infrastructure haut-débit VTHD. Le déploiement et les évaluations de logiciels et de protocoles sur ce type d’infrastructures sont aussi extrêmement complexes et lourds. Les résultats sont quant à eux souvent peu significatifs car issues d’expériences dont les conditions sont mal maîtrisées.
La problématique des grilles et du calcul distribué à large échelle a fait émergé de nouveaux travaux dans la communauté réseau, principalement au niveau des protocoles de transport très haute performances et de la mesure de performances. La validation de ces travaux requiert une évaluation expérimentale basé sur des implantations réelles de protocoles car l'analyse et la simulation atteignent leurs limites lorsque l'on est à ces échelles de performance.
L’objectif de cette étude sera, pour la communauté réseau de construire un émulateur de réseau se comportant comme un environnement réseau longue distance de type réseau multigigabit IP pour les applications de grille. L’objectif sera essentiellement de pouvoir disposer d’un “ nuage réseau ” contrôlable en terme de performances réseau (débit, délai et taux de perte de paquets), de pouvoir y intégré des équipements réseaux offrant des services avancés (sondes de mesure, services différenciés et traitements actifs et programmables) et de pouvoir définir un nombre potentiellement très grand d’entités communicantes aux extrémités.
1.5.2 Description du projet

La construction d'un émulateur de réseau haut débit longue distance devra permettre par exemple l'analyse du comportement et une comparaison correcte de protocoles de transport haute performance. Pour l'analyse et la comparaison des performances il est indispensable de pouvoir reproduire exactement les conditions de l'expérience et de travailler dans un environnement homogène (ou à hétérogénéïté connue) et contrôlé.

L'étude fine de l'influence des paramètres impactant les performances des connexions de transport pour les débits d'accès supérieurs au gigabit est nécessaire. Pour celà, il faut pouvoir manipuler précisément les paramètres de délai, débit et fiabilité des liens réseaux. Les liens composant ce “ nuage réseau émulé” seront vus par les protocoles d’extrémités comme des canaux offrant des services paquets à performances différenciés mais aussi à traitements programmables.
L'équipe RESO du LIP possède une très forte expérience et expertise dans les technologies gigabit (Myrinet, Gigabit Ethernet) ainsi que dans la construction et l'expérimentation de plate-forme haut débit dans un contexte national et international (VTHD, eToile, DataGRID/GEANT, DataTAG). Par ailleurs, RESO dispose d'un émulateur Gigabit pour l'étude de monoflux gigabit basé sur NistNet et travaille à la conception d'architectures de routeurs actifs distribués. Nous apporterons donc toutes ces compétences dans la construction de l’émulateur.
1.5.3 Résultats attendus

De T0 à T6, une réflexion sur les fonctionnalités précises de l’émulateur réseau sera menée. En parallèle, un état de l’art et une évaluation des solutions existantes seront menés.

La période de T6 à T12, sera consacrée à la construction de la première version de l’émulateur afin de permettre les premières études expérimentales à partir de T12.

De T12 à T24, Observation de l’utilisation de l’émulateur et améliorations pour préparer la deuxième phase d’expérimentations.

T6 : Document de spécification et de conception de l’émulateur réseau multigigabit. Etat de l’art des émulateurs réseau et des instruments de mesure de performance bout en bout existants.

T12 : Version1 de l’émulateur et documentation utilisateur.

T24 : Version2 de l’émulateur et documentation utilisateur.
I.7 Émulation de l’hétérogénéité pour la gestion des ressources

Emmanuel Jeannot et Johanne Cohen, Loria

I.7.1 Objectifs et contexte 

Une grille de calcul est formée de ressources distribuées et de réseaux reliés à celles-ci. Une grille de calcul est donc par essence hétérogène puisque la puissance de calcul des ressources peut varier du simple PC de bureau à la dernière machine parallèle. La quantité de mémoire disponible sur chacune des ressources peut aller aux Teras Octets. Le débit des réseaux qui connectent toutes ces ressources (dépendant du médium de communications) peut varier du MBits/s à plusieurs Gbits/s.

Effectuer des expériences reproductibles sur une grille de calcul de grande taille est impossible car l’ensemble des composants de celle-ci est partagé par d’autres utilisateurs. Or, réaliser des expériences reproductibles est un paradigme auquel il faut absolument se conformer pour pouvoir effectivement déduire des conclusions pertinentes sur celles-ci.

GRID explorer se propose de fournir un environnement pour l’instant homogène dédié aux expériences de l’informatique. Il s’agit d’un cadre permettant de réaliser naturellement des expériences reproductibles. Cependant, sa nature homogène ne permet pas, de mener des expériences en environnement hétérogène qui soit une modélisation fidèle d’une grille.

Au sein de notre équipe Algorille, nous étudions des protocoles qui permettent de gérer des ressources dans la grille (par exemple de la bande passante lors de la redistribution ds données ou lors d’une diffusion). Dans une première étape, nous effectuons une modélisation des ressources et des contraintes, Dans une deuxième étapes, nous proposons des protocoles et des algorithmes que nous validons soit de facon théoriques, soit en utilisant des simulateurs de réseaux (comme ns, Glomosim, omnet++), soit en créant nos propres simulateurs adaptés à nos problèmes (ce fut notamment le cas pour valider nos protocoles de diffusion au niveau application pour un projet IST PROXiTV). Malheureusement, ces études ne peuvent pas être vérifié sur des cas réels par manque de moyen de matériels informatiques. GRID explorer nous donnerait cette opportunité.

Plus particulièrement, dans le cadre de nos recherches sur l’ordonnancement dans le modèle agent-client-serveur, nous mettons au point des algorithmes d’ordonnancement de tâches et d’applications s’exécutant sur un ensemble de serveurs hétérogènes, distribués et reliés par des réseaux à débit et latence variables. Nous avons mené des expériences sur les machines du laboratoire mais celles-ci sont difficilement reproductibles, car il est impossible de maîtriser complètement les conditions expérimentales. Nous avons aussi utilisé simGRID pour simuler l’environnement du laboratoire, mais les résultats obtenus sont différents de ceux obtenus sur l’environnement réel. Compte tenu du peu de contrôle que nous avons sur l’environnement il est difficile de conclure de manière tranchée sur les résultats des expériences et sur la pertinence et la précision de simGRID.

I.7.2 Description du projet

Dans le cadre de cette ACI, nous souhaitons mettre au point des techniques permettant d’émuler l’hétérogénéité sur l’environnement homogène que constitue Grid Explorer. L’objectif est d’obtenir un environnement hétérogène permettant de réaliser des expériences reproductibles afin de valider nos algorithmes et de comparer les résultats à ceux obtenus par simulation.

Une première approche pour atteindre cet objectif (i.e. transformer un environnement homogène en environnement hétérogène) sera d’ajouter une charge constante à un processeur, à la mémoire ou au réseau, pour les rendre moins efficace. Ceci nécessite de bien calibrer les processus chargés d’ajouter de la charge.

Pour cette approche nous proposons l’échéancier suivant : 1) étude théorique du problème en attendant la réalisation de grid explorer, 2) écriture d’un prototype permettant d’émuler l’hétérogénéité sur les nœuds, 3) mise en œuvre sur grid-explorer prototype, 4) test du prototype en exécutant un middleware de grille dans l’environnement émulé, 5) validation de l’expérience, comparaison avec simGRID, amélioration du prototype, publication.

D’autres approches pourront ensuite être envisagées comme l’utilisation d’émulateur de réseaux (ce qui permettrait de tester de nouveau protocole sans les installer : Ad-Hoc, IPV6, etc..) , ou des modifications du noyau (en particulier de l’ordonnanceur).
I.7.3 L’échéancier des résultats et réalisations

Nous souhaitons tout d’abord montrer la faisabilité de l’émulation de l’hétérogénéité sur une plate-forme homogène distribuée.

T0 -> T0+12 : Etude théorique du problème en attendant la réalisation de grid explorer.

T0+12 -> T0+18 : Ecriture d’un prototype permettant d’émuler l’hétérogénéité sur les nœuds.

T0+18 -> T0+24 : Mise en œuvre sur grid-explorer prototype

T0+24 -> T0+30 : Test du prototype en exécutant un middleware de grille dans l’environnement émulé.

T0+30 -> T0+36 : Validation de l’expérience, comparaison avec simGRID, amélioration du prototype, publication.
A terme émuler de manière efficace l’hétérogénéité permettra de tester des algorithmes conçus pour fonctionner en milieu hétérogène et de valider les simulateurs
B.2.II) Etudes associées à l’instrument
II.1 Mécanismes, protocoles et ingénierie des systèmes à grande échelle

Samir Djilali, Franck Cappello, Gilles Fedak, George Bosilca, Oleg Lodygensky, Pierre Lemarini, Géraud Krawezik, Vincent Néri, LRI, CNRS, équipe Grand-Large, INRIA Futurs.

II.1.1 Objectifs et contexte :

Les systèmes à grande échelle comme les GRID et les systèmes P2P requièrent des mécanismes de contrôle, de coordination, de sécurité et des protocoles de communication dont il est difficile de définir le comportement précis en dehors d’exécution réelle. Les déploiements spécifiques ne permettant pas de tester une large variété de configurations, le recours à l’émulation s’avère nécessaire. Avant le déploiement d’une Grille ou d’un système P2P, il serait préférable de disposer d’outils d’ingénierie permettant de valider, de dimensionner et d’optimiser les applications et l’infrastructure cibles.

II.1.2 Description du projet

Le groupe Clusters et Grilles du LRI développe plusieurs mécanismes pour les GRID et les systèmes P2P : XtremWeb[1], MPICH-V[2], RPC-V[3], ordonnancement à grande échelle. Les évolutions des mécanismes d’XtremWeb et les protocoles MPICH-V et RPC-V doivent être étudiées, optimisées et validées sur un émulateur. Ces mécanismes concernent le calcul distribué tolérant aux pannes (mécanisme de checkpoint distant dans XtremWeb) et des mécanismes de mouvement de données massives tolérant aux pannes (les communications d’une application parallèle exécutée sur 2000 processeurs, le transfert de résultats obtenus à partir d’un calcul sur grille suivant le protocole RPC). Les expériences sur l’émulateurs concernent le dimensionnement, l’évaluation des performances, la résistance aux pannes des mécanismes et des protocoles.

Plusieurs déploiements des systèmes développés dans le groupe sont en cours notamment avec le projet Auger d’astroparticules et l’IBBMC (l’Institut de Biologie et de Biochimie Moléculaire et Cellulaire), l’Université des sciences appliquées de Genève, l’Université de Gouadeloupe, l’IRISA, etc. A chaque fois, le déploiement a pour but de tester les systèmes développés. Ces tests rencontrent systématiquement le problème de l’installation d’une plate-forme expérimentale dans un site en utilisation ou en production. Les problèmes à résoudre sont identifiés sur le site. L’utilisation d’un émulateur, permettrait de configurer le cluster de façon similaire au site visé et d’anticiper les problèmes de déploiement d’abord et ensuite les goulots d’étranglement. L’émulation des sites cibles permettrait d’optimiser la position des ressources sans affecter l’utilisation ou la production lors de la phase préalable au déploiement.
II.1.3 L’échéancier des résultats et réalisations

Le premier résultat attendu est élaboration (ou l’intégration à partir de logiciels existants) d’un outil permettant de configurer le système d’exploitation, les performances CPU et les performances réseau des nœuds d’une grille ou d’un système P2P virtuel. La configuration visée pourra correspondre à des environnements existants (par exemple, le campus d’Orsay).

Le deuxième résultat attendu est l’utilisation de ce système pour l’étude de mécanismes de XtremWeb, MPICH-V et RPC-V. On étudiera par exemple la problématique de l’ordonnancement multi-utilisateurs/multi-applications dans un environnement de Desktop Grid.
Le troisième résultat attendu est la capacité d’étudier l’optimisation d’une Grille dont le déploiement est envisagé ou déjà réalisé. En exécutant en émulation la charge applicative prévue et en faisant varier la configuration du déploiement (modification des performances de certains éléments, modification de la topologie, modifications systèmes), il devra être possible de découvrir des goulots d’étrangement et d’optimiser le déploiement (dimensionnement, configuration système).
II.1.4 Références

[1] F. Cappello et al., XtremWeb : une plate-forme de recherche sur le calcul global et pair à pair, chapitre 6 du livre Calcul réparti à grande échelle, metacomputing, sous la direction de Françoise Baude, lavoisier, 2002.

[2] G. Bosilca, A. Bouteillier, F. Cappello, S. Djilali, G. Fedak, C. Germain, T. Herault, P. Lemarinier, O. Lodygensky, F. Magniette, V. Neri, A. Selhikov, "MPICH-V: Parallel Computing on P2P Systems", IEEE/ACM High Performance Networking and Computing, SC2002, baltimore, 2003.

[3] S. Djilali, P2P-RPC: Programming Scientific Applications on Peer-to-Peer Systems with Remote Procedure Call, Third Workshop on Global and Peer to Peer Computing, IEEE/ACM CCGRID2003, Tokyo, JAPAN, May 12-15, 2003.

[4] O. Lodygensky, G. Fedak, F. Cappello, V. Neri, A. Cordier, Augernome & XtremWeb: Monte Carlos computation on a global computing platform, CHEP (Conference on High Energy Physics) 2003, La Jolla, California, USA, March 24-28, 2003.

[5] O. Lodygensky, G. Fedak, F. Cappello, V. Neri, M. Livny, D. Thain, XtremWeb & Condor: sharing resources between Internet connected Condor pools, Third Workshop on Global and Peer to Peer Computing, IEEE/ACM CCGRID2003, Tokyo, JAPAN, May 12-15, 2003.

II.2 Protocoles de localisation d'objets mobiles dans les systèmes à grande échelle

Françoise Baude, Laurent Baduel, Denis Caromel, Arnaud Contes, Alexandre Genoud, Fabrice Huet, Projet OASIS, INRIA Sophia Antipolis, UNSA, I3S-CNRS.

II.2.1 Objectifs et contexte 

La bibliothèque ProActive, 100% Java, fournit des threads transparents, des objets distants et mobiles, des appels (bi-point, multi-point, et hiérarchiques) asynchrones avec futurs transparents, et des mécanismes de synchronisation de haut niveau (futurs), de la résistance aux pannes et de la sécurité.

L'objectif est de permettre l'exécution d'une même application sur une architecture multi-processeurs à mémoire partagée, sur un réseau de stations de travail, sur Internet ou encore sur n'importe quelle combinaison hiérarchique. Différents protocoles sont utilisés (transmissions en mode asynchrone avec et sans rendez-vous, contrôle de flux, déploiement par descripteurs hiérarchiques, etc.), il sera important de simuler efficacement des configurations à plusieurs milliers de nœuds.

La migration jouera un rôle important dans les applications utilisant des milliers de nœuds. Elle pourra etre utilisee pour assurer de la répartition de charge, tenir compte des changements dans les ressources disponibles ou tout simplement gerer la panne ou l’arrêt de certains nœuds.

II.2.2 Description du projet

Les travaux récents autour des mécanismes de localisation d'objets mobiles menés dans l'équipe Oasis ont permis de mettre en évidence leur dynamique complexe. Nous avons étudié formellement un mécanisme à base de répéteurs et un autre utilisant un serveur de localisation et montré qu'ils ne donnent de bonnes performances que sous certaines conditions [2]. La latence importante observée dans le cas de nœuds très repartis influe ainsi sur la duree d’une communication entre deux objets mais aussi sur la durée de migration. Suivant le protocole de localisation utilise, ces deux parametres auront une influence plus ou moins importante sur les performances générales. De meme, le tres grand nombre de participants rend problématique le passage a l’échelle.

Il est difficile voire impossible de connaître le comportement de ces protocoles sans étude théorique ni teste grandeur nature. Cependant, l’étude théorique seule ne suffit pas car il faut vérifier que les necessaires simplifications mathématique n’introduisent pas une déviation importante entre les prédictions des modèles et les valeurs expérimentale sur une application réelle. Il est donc indispensable d’avoir un outil permettant de simuler ou d’émuler ces protocoles dans diverses conditions (latence, taux de panne…).
Ce travail passera par les points suivants :

• 
  Développer de nouveaux protocoles de communications
  
• 
  Décrire formellement ces protocoles à l'aide d'outils d'évaluation de performance (Chaînes de Markov) afin de prévoir leur comportement
  
• 
  vérifier ces modèles par simulation et enfin procéder à des expérimentations.
  

Cette approche permettra d’avoir une base théorique pour les protocoles mais aussi d’étudier leur dynamique dans des conditions réelles.

II.2.3 L’échéancier des résultats et réalisations
T0+6 : Conception de protocole de localisation/communication

T0+ 18: Formalisation des modèles

T0+ 24: Simulation

T0+ 32: Expérimentation et Evaluation de performances

T0+36: retour d’expérience, diffusion des résultats