ACI GRID CGP2P : problématique de la fusion P2P et GRID pour le calcul à grande échelle

1. ACI GRID CGP2P : problématique de la fusion P2P et GRID pour le calcul à grande échelle Franck Cappello Responsable groupe Clusters et Grilles LRI, Université Paris sud. fci@lri.fr www.lri.fr/~fci GRID@Inria

2. Sommaire • Introduction • Rationalisation des systèmes P2P • Le système XtremWeb I • Les axes de recherche dans CGP2P • Pour en savoir plus GRID@Inria

3. AU AU AU AU JP Projets GRID Connecter et fédérer des ressources de calcul/stockage/instruments géographiquement distribuées ACI GRID (Michel Cosnard) Globalisation des Ressources Informatiques et des Données Apples USA Application-Level Scheduling Bricks USA Performance evaluation for analysis and comparison of various scheduling DOCT USA The Distributed Object Computation Testbed (DOCT) is for handling complex documents Entropia.com USA Desktop software that should provide universal and pervasive source of computing power middleware for the data-intensive applications Folding@Home CERN Data Grid EU USA Understanding how proteins self-assemble.   Collaborative, Visualization and Simulation Environment Covise DE Wide-area distributed cluster, parallel and dist. computing DAS NL GLOBUS USA Software to design, implement, and experiments with remote/distributed access to 3D graphic applications Basic software infra. for computations that integrate geo. distributed computational and information resources EROPPA EU HARNESS USA Based on PVM. Parallel plug-ins, Peer-to-peer distributed control, and multiple virtual machines Globe EU Study and implement a unifying paradigm for the large-scale wide area distributed shared objects JaCo3 EU Java and CORBA Collaborative Env. for Coupled Simulations.. HTC USA Develop,deploy, and evaluate mechanisms and policies that support high throughput computing JaWs GR JaWS is an economy-based computing model MetaMPI DE MetaMPI supports the coupling of heterogeneous MPI InfoSpheres USA The Caltech Infospheres Project researches compositional systems, METODIS DE Metacomputing Tools for Distributed Systems - A metacomputing MPI for TCP/IP and ATM Javelin USA Javelin: Internet-Based Parallel Computing Using Java MOL DE Metacomputer OnLine is a toolbox for the coordinated use of WAN/LAN connected systems. LEGION USA Object-based metasystem. Transparent scheduling, data management, fault tolerance, site autonomy, Poznan Metacom. PL Development of tools and methods for metacomputing NASA IPG USA Testbed that provides access to a grid WAMM IT WAMM (Wide Area Metacomputer Manager) is a graphical tool, built on top of PVM. NETSOLVE USA The UNiform Interface to Computer Resources allows users to submit jobs to remote high perf. Comp. resources PSE. RPC based client/agent/server system for remote access both hardware and software components UNICORE DE PARDIS USA DesignDrug Molecular Modelling on Peer-to-Peer Grid Building PARallel DIStributed applications from CORBA to implement application-level interaction DISCWorld An infrastructure for service-based metacomputing WebFlow USA WebFlow can be regarded as a high level, visual user interface and job broker for Globus (GridSim) A Java-based Toolkit for Modeling and Simulation of World Wide Grids. WebSubmit USA GRID@Inria A Web-based Interface to High-Performance Computing Resources Nimrod/G A global scheduler for parametric computing PSE NINF

4. Différents types de GRID :Classification pragmatique Caractéristiques des nœuds : Grands sites de calcul, Clusters • ~100 • Stables • Identification • individuelle • Confiance Les Grilles de calcul ou « GRID » 2 types de grands systèmes distribués Les systèmes distribués à grande échelle PC Windows, Linux • ~100 000 • Volatiles • Pas d’ident • individuelle • Pas de • confiance Les systèmes de Calcul Global ou « Mega Computing » ou « Internet Computing » Les systèmes Pair à Pair GRID@Inria

5. Calcul à grande échelleHistorique • Applications pionnières (connues) : • craquer des clés de cryptage RC5 et DES • trouver des nombres premiers de Mersenne • craquer des codes RSA • Seti@home • Premiers résultats 1996-1997 • SuperWeb, Javelin, Atlas, Charlotte, etc. en 96. • Nombre de stations utilisées : 250, 3500, ~14000 PCs (Ppro 200) en 97 • 35 k personnes dans la mailing list de Seti@home en 97 GRID@Inria

6. Systèmes de Calcul Global Définition Pragmatique : Calcul Maître-esclave Par vol de cycles sur Internet Un serveur centraliser ordonnance des calcul sur des PC volontaires • Applications dédiées • SETI@Home, distributed.net, • Décrypthon • Projet de production • Folding@home, Genome@home, • Xpulsar@home,Folderol, • Exodus, Peer review, • Plates-formes de recherche • Javelin, Bayanihan, JET, • Charlotte (based on Java), • Ninf (ECL), XtremWeb (LRI), • Plates-formes commerciales • Entropia, Parabon, • United Devices, Application Cliente Params. /résults. serveur Paramètres Internet PC Volontaire PC Volontaire PC Volontaire Télécharge et exécute l’application GRID@Inria

7. Système Pair à Pair (Peer to Peer) Toutes les ressources (PC) sont égales, les opérations se font à parité, de pair à pair. • Applications dédiées • Napster, Gnutella, Freenet, • KaZaA, Music-city, • Jabber, • Projets de recherche • Globe (Tann.), Cx (Javalin), Farsite, • OceanStore (USA), XtremWeb (LRI), • Pastry, Tapestry/Plaxton, CAN, Chord, • Autres projets • Cosm, Wos, peer2peer.org, • JXTA (sun), PtPTL (intel), PC volontaire Participant à la mise en relation entre Pair Volontaire Internet req. Client Volontaire Application Provider GRID@Inria

8. un PC accepte PC Mon PC Communications Potentielles pour les Applications parallèles PC requête PC fournit PC PC System CGP2P accepte PC résultat PC PC Un autre PC PC fournit Une plate-forme de rechercher opensource pour étudier : • Le Calcul Global (extensibilité ,organisation des serveur,…) • Le Calcul Pair à Pair (volatilité, communication inter noeud, sécurité) • Fusion des systèmes de Calcul Global et Pair à Pair  Plate-forme de Recherche (étudier de nouveaux mécanismes)  Plate-forme de Production (identifier les problèmes des utilisateurs) Accepte concerne des Calculs ou des données Les requêtes peuvent être relatives à des données ou des calculs GRID@Inria

9. Goals of a PRC platform Distributed computing platforms Goals of BOINC(Berkeley Open Infrastructure for Network Computing) applications Research lab X University Y Public project Z • Academic and open-source • Globus • Cosm • XtremWeb • Jxta • Commercial • Entropia • United Devices • Parabon • Public-resource computing/storage • Multi-project, multi-application • Participants can apportion resources • Handle fairly diverse applications • Work with legacy apps • Support many participant platforms • Small, simple projects resource pool • Participants install one program, select projects, specify constraints; • all else is automatic • Projects are autonomous • Advantages of a shared platform: • Better instantaneous resource utilization • Better resource utilization over time • Faster/cheaper for projects, software is better • Easier for projects to get participants • Participants learn more The Software Infrastructureof SETI@home II David P. Anderson Space Sciences Laboratory U.C. Berkeley GRID@Inria

10. Sommaire • Introduction • Rationalisation des systèmes P2P • Le système XtremWeb I • Les axes de recherche dans CGP2P • Pour en savoir plus GRID@Inria

11. Rationalisation des syst. P2P Caractéristiques fondament. • Rôles multiples des ressources : toutes les ressources peuvent être jouer le rôle de client, serveur et/ou de composante structurelle • Appariement des ressources : les clients ne connaissent pas les serveurs à priori. • Grande échelle : jusqu ’à 100 k voire 1 M machines • Hétérogénéité : différents matériels et OS • Dynamicité / Volatilité : nombre de clients et de serveurs évoluent constamment, le système (et peut être les applications) doivent supporter l ’existence d’éléments volatiles • Utilisabilité : malgré les propriétés précédentes, le système doit rester facilement programmable et maintenable • Sécurité : le système doit fonctionner même en présence de firewall. Sécurité pour les participants, les serveurs et l ’applications. Un comportement malicieux ne doit pas pouvoir corrompre l ’application. Un agent externe ne doit pas pouvoir se faire passer pour un serveur. GRID@Inria

12. 1) Gateway (@IP, Web pages, etc.) -Give the @ of other nodes -Choose a community, -Contact a community manager Gateway ? P2P @IP d’un node P2P System P2P PC Basic components of P2P systems: starting the system 2) Connection/Transport protocol for requests, results and control -Bypass firewalls, -Build a virtual address space (naming the participants: NAT) (Tunnel, push-pull protocols) Firewall Internet, Intranet or LAN PC Firewall PC Resource Resource Resource Internet Tunnel Resource GRID@Inria

13. Internet, Intranet or LAN 4) Resource discovery (establish connection between client and service providers) (Centralized directory, hierarchical directory, flooding, search in topology) PC PC Resource Request Request Request Resource : -file -service Resource PC Basic components of P2P systems: discovering resources 3) Publishing services (or resources) Allows the user to specify -what resources could be shared -what roles could be played -what protocol to use (WSDL, etc.) Internet, Intranet or LAN PC File CPU Disc space PC GRID@Inria

14. Basic components of P2P systems: coordination The role of the 4 previous components was A) to setup the system and B) to discover a set of resources for a client 5) Coordination sys.: - Receives Client computing request (virtual cluster - Configures/Manages a platform (collect manager) service proposals and attribute roles) - Schedules tasks / data distribution-transfers - Detects/recovers Faults Internet, Intranet or LAN Coordination system Centralized or Distributed Request PC Resource Request PC Request PC Resource PC GRID@Inria

15. Peer ID Search query peer peer Peer ID GET file Search query peer peer Search query Classification des systèmes P2PC) Architecture du MMR Architecture du Mécanisme de Mise en Relation : recherche centralisée, distribuée ou hybride ? Central server Gnutella, Fasttrack Mécanisme de découverte de ressources totalement distribué Indexation par catalogues hiérarchiques Distribué Centralisé Hybride Chord CAN PASTRY Farsite Tapestry Gnutella Freenet, OceanStore Napster, SETI@home, Décrypthon Fasttrack, BearShare GRID@Inria

16. Sommaire • Introduction • Rationalisation des systèmes P2P • Le système XtremWeb I • Les axes de recherche dans CGP2P • Pour en savoir plus GRID@Inria

17. hierarchical XW coordinator Peer to Peer Coordinator PC coordinator Global Computing (client) PC Worker XtremWeb 1Architecture General • XtremWeb 1 implements a subset of the 5 P2P components • 3 entities : client/coordinator/worker (diff protect. domains) • Current implementation: centralized coordinator PC Client/worker Internet or LAN PC Worker PC Client/Worker GRID@Inria

18. XtremWeb 1Worker Architecture Multithread (the application is embedded in one thread) Applications  Binary (HPC codes - Fortran or C)  Java (recent codes, object codes) Operating system Linux, Windows Security  Sandbox (traps & checks system calls) Control  Screen saver (cycle stealing) Information  static (CPU, Speed, Mem., Disc, etc.)  dynamic (inst. workload, volatility stat, net.) Protocol: firewalls bypass hostRegister Coordinator Worker WorkRequest XML RPC and SSL authentication and cryptography workResult workAlive GRID@Inria

19. Communication Layer XML-RPC SSL TCP XW1 Coordinator ArchitectureFirst version: centralized Data base set Task selector Priority manager Tasks Applications Tasks Results Statistics Results Scheduler Result Collector Volatility Detect. Request Collector Worker Requests Client Requests GRID@Inria

20. XtremWeb 1Client Architecture A Java API  task submission  result collection  coordinator control Applications  Multi-parameters, bag of tasks  Master-Worker (iterative), EP Coordinator control  platform configuration (number of Workers, Worker type, etc.) Coordinator Configure experiment Client Worker Get work Launch experiment Put result Collect result GRID@Inria

21. Database SQL PerlDBI Java JDBC XML-RPC SSL PHP3-4 GNU autotool Software Technologies Java Server Communication http server Worker Client Java Installation Installationprerequisites : database (Mysql), web server (apache), PHP, JAVA jdk1.2. GRID@Inria

22. ObservatoirePierre Auger Aires: Simulation de douches atmosphériques : • Temps d’exécution de 5 à 10 heures (dépend de la machine et des paramètres de simulation) Base de données de paramètres (Lyon, France) Centres de calcul traditionnels XtremWeb Server CINES (Fr) Nombre de PC estimé ~ 5000 paramètres PC worker Internet ou LAN Fermi Lab (USA) PC Client PC Worker Worker Aires GRID@Inria

23. C@sper Autres projets utilisant XW • 1 CGP2P (Calcul Global et Pair à Pair) stockage + ordo + applications parallèles, • 2 ASP, mutualisation, simulation numérique, Guillaume Alléon • XW + composants numériques CORBA • 3 IRIS project: multi-server XtremWeb • 4 IFP stage de DEA en cours avec installation d’XW + applications IFP • 5 EADS stage de DEA en cours avec installation d’XW et application EADS • 6 University of Applied Sciences, Genève, • 7 Université de Antille-Guyanne, classification bacilles tuberculeux en collaboration avec l'institut Pasteur de Guadeloupe • 8 XW UCSD: collection et analyse de traces d’activité et SW parallèle. • 9 XW Math (laboratoire de mathématiques – Université Paris sud) • 10 XW ASCI/LIFL (langage de contrôle, aide à la décision) • 11 XW ENS Lyon (stockage fiable de données par stripping à grande échelle) GRID@Inria

24. Sommaire • Introduction • Rationalisation des systèmes P2P • Le système XtremWeb I • Les axes de recherche dans CGP2P • Pour en savoir plus GRID@Inria

25. Fusion des concepts de • Calcul Global et de système Pair à Pair • 26 chercheurs, 7 laboratoires • (ASCI, IMAG-ID, LAL, LARIA/LIP, LIFL, LRI, LIX-Polytechnique) • + UCSD (USA) + EADS • Approche : augmenter les fonctionnalité des systèmes de calcul global • stockage • communications entre les participants • possibilité à n’importe quel participants de soumettre des requêtes • Résultats visés : • Trouver des réponses aux problèmes scientifiques posés • Produire des logiciels interopérants qui assemblés forment une plate-forme CGP2P GRID@Inria

26. Les thèmes de recherche CGP2P • Architecture générale du système distribué • Interface utilisateur / aide à la décision (Sous projet I) • Sécurité (Sous projet II) • Stockage/Fouille (Sous projet III) • Communications inter-nœuds : MPICH-V (Sous projet IV) •  SuperComputing (SC), Baltimore, Nov 2002 • Ordonnancement (Sous projet IV) • Vérification théorique des protocoles (Sous projet V) • Interopérabilité / fusion avec les GRID (Sous projet V) • Validation sur des applications réelles GRID@Inria

27. Ouvertures sur les collaborations internationales Collaborations internationales et pluridisciplinaires: • Equipe de Ian Foster (Université de Chicago) • Equipe de Mitsuhisa Sato (Université de Tsukuba) • LAL, projet Auger (IN2P3) • RWCP, Université de Tsukuba, de Melbourne, de Toronto, • IBM Watson, SDSC, ORNL, GMD, IMAG, • Laboratoire de Math, Stratégie basée sur l’échange/visite de chercheurs: Séjour de 3 mois de George Bosilca au RWVP (Tsukuba, Japon) Séjour de Franck Cappello de 3 mois à l’Université de Tsukuba (Japon) Séjour de Mitsuhisa Sato (Univ Tsukuba) de 1 mois Thèse d’Oleg Lodygensky (LAL) au LRI pour 3 ans Détachement de Cécile Germain (LRI) au LAL pour 1 an Postdoc de Gilles Fedak dans l’équipe de Ian Foster (U. Chic, USA) Postdoc d’Adriana Ianmitchi (équipe I Foster, USA) au LRI Visite d’Henri Casanova (SDSC) au LRI le 8 Mars Visite de Miron Livny (Condor) au LRI le 29 et 30 Juillet GRID@Inria

28. Communication inter nœuds :MPICH-V (Volatile) Objectif : exécuter des applications parallèles prévues pour des machines parallèles à passage de messages (ratio cal/com très grand) Problèmes : 1) les noeuds sont volatiles (X peuvent disparaître à tous moments) 2) les nœuds sont protégés par des firewalls. Vue du programmeur : PC client MPI_send() PC client MPI_recv() Objectif : 1) Exécuter les programmes MPI sans modif 2) Ne pas modifier MPICH 3) Accepter n fautes 4) Passer les firewall (tunnel) 5) Infrastructure/protocole extensible 6) Reprise locale (pas de reprise globale) 7) Vérification théorique des protocoles GRID@Inria

29. MPICH-V:Related work A classification of fault tolerant message passing librariesconsidering A) level in the software stack where fault tolerance is managed and B) fault tolerance techniques. MPVM FT-MPI CLIP MPI-FT MPICH-V Provide to MPICH a virtual stable cluster GRID@Inria

30. PC client Get PC client Internet ou LAN Get PC client Put PC Mémoire de canal Communication inter nœuds :MPICH-V Proposition pour résoudre le problème PC client Utiliser une mémoire de canal : qui stocke tous les messages, est fiable, qui accepte les communications XW Internet Ou LAN Firewall Get Put Mémoire de canal PC client Que se passe-t-il en cas de défaillance ? Un nouveau PC reprend le calcul depuis le début* et rejoue toutes ses Communications *dernier checkpoint Intérêt  reprendre uniquement la (les) tâche(s) défaillante(s) GRID@Inria

31. Communication inter nœuds :MPICH-V Vérification théorique : Dans le cas général, il faut reproduire les com. à l’identique !!  Problème du recv(any,…) Ordre initial : t1 mc1 t2 mc2 t3 • À cause de l’asynchronisme des mémoires de canal, les ordres peuvent être inversés les nœuds numérotent tous les messages qu’ils envoient et avertissent les mémoires de l’ordre local de leurs réceptions GRID@Inria

32. Communication inter nœuds :MPICH-V MPICH-V : • Communications : un device MPICH avec mémoire de canal • Run-time : une virtualisation des processus MPICH en tâches XW avec checkpoint • Link de l’application avec libxwmpi au lieu de libmpich Mémoires de canal Serveurs de checkpoint Serveur de tâches «ordonnanceur » worker Internet ou LAN Worker Firewall Worker GRID@Inria

33. MPICH-V:Checkpoint without global sync. Uncoordinated checkpoint : • Workers may checkpoint at any time (independently of the others) • Workers may follow different checkpoint policies according to their network performance and own volatility characteristic Coordinated (Chandy/Lamport) Uncoordinated restart detection/ global stop restart detection failure failure Ckpt Ckpt Workers Workers GRID@Inria

34. ADI _xwbsend - blocking send _xwbrecv - blocking receive Channel Interface _xwprobe - check for any message avail. Chameleon Interface Communication inter nœuds :MPICH-V • Device ‘ch_xw’ en remplacement du ‘ch_p4’ • Réalisation des fonctions principales par-dessus les sockets MPI_Send MPID_SendControl MPID_SendChannel PIbsend _xwfrom - get the src of the last message _xwInit - initialize the client XW device Interface _xwbsend _xwFinalize - finalize the client GRID@Inria

35. PC client Internet Or LAN Get Put Channel Memory PC client Communication inter nœuds :MPICH-V (Volatile) RTT Ping-Pong : 2 PIII 500, une mémoire de canal, 100baseT Seuil Eager/rendez-vous Temps, sec 2,6 Mo/s ch_xw, mean 1 ch_xw, min 1 ch_p4, mean ch_p4, min X ~2 Le facteur 2 par rapport à P4 est raisonnable puisque chaque message traverse de réseau 2 fois. 5,4 Mo/s X ~2,33 GRID@Inria Taille de message (Octets)

36. PC client Internet Or LAN Get Put Channel Memory PC client Communication inter nœuds :MPICH-V (Volatile) Impact du nombre de nœuds gérés par 1 CM Sur le temps de communication individuel Icluster (Imag) GRID@Inria

37. PC client Internet Or LAN Get Put Channel Memory PC client Communication inter nœuds :MPICH-V (Volatile) MPI all-to-all pour 9 nœuds (1CM) Icluster (Imag) 2,1 x3 1 0,7 0,3 GRID@Inria

38. Communication inter nœuds :MPICH-V (Volatile) Checkpoint/restart RTT pour 1 nœud (Little Tipi) Temps pour checpoint+restart (s) Applications GRID@Inria

39. Communication inter nœuds :MPICH-V (Volatile) Dégradation de performance pour NAS BT.A.4 en fonction du nombre de checkpoint (Little-Tipi) Un seul serveur de checkpoint pour 4 tâches (driver P4) Pourcentage de perte De performance Taille de messages (Octets) GRID@Inria

40. Communication inter nœuds :MPICH-V (Volatile) SPMD : NAS BT.A (Icluster-Imag, PGI Fortran77) Une seule mémoire de canal Pourcentage de perte De performance Performance par rapport à P4 Topologie du cluster non régulière Nombre de Mémoire de Canal GRID@Inria

41. Nécessité d’un environnement expérimental complet • Besoin d’outils théoriques : • Modèles de performance, modèles de défaillance • Mais aussibesoin d’outils expérimentaux (Grands instruments au sens des physiciens) pour l’étude des systèmes à grande échelle • Proposition : GRID Explorer : • Observations / mesures (sondes, traces): • Plate-forme de tests en grandeur nature TestBed (CGP2P) • Un collecteur de Traces de paramètres de ressources (XW-trace) • Un ensemble de benchmarks et de sondes Expériences avec conditions expérimentales contrôlés (expériences/résultats reproductibles) : • Un(des) Emulateur(s) reproduisant avec des degrés de fidélité variable le système et les conditions expérimentales (XW-emulator) GRID@Inria

42. Conclusion • Les systèmes distribués à grande échelle sont étudiés par de nombreux chercheurs en particulier pour le calcul. • XtremWeb constitue l’une des première plate-forme complète de recherche et de production. WWW. XTREMWEB.NET • Le projet CGP2P a pour objectif d’étudier la prochaine génération de systèmes P2P fusionnant calcul et stockage. • MPICH-V est la première bibliothèque de passage de messages pour les systèmes P2P (les performances sont raisonnables). • La recherche dans ce domaine doit nécessairement inclure les composantes théoriques et expérimentales. • GRID Explorer GRID@Inria

43. Pour en savoir plus [1] « MPICH-V: toward a Scalable Fault Tolerant MPI for Volatile Nodes“, in ACM/IEEE International Conference on Supercomputing SC 2002. [2] « Calcul Global Pair à Pair : extension des systèmes Pair à Pair au calcul », lettre de l’IDRIS, 12 pages, Février 2002. www.lri.fr/~fci [3] Projet ACI GRID CGP2P, www.lri.fr/~fci/CGP2P.html [4] Projet XtremWeb, www.xtremweb.net [5] Troisième Workshop International « Global P2P Computing », avec IEEE/ACM CCGRID 2003, Tokyo, Mai 2003, www.lri.fr/~fci/GP2PC.htm [6] « Peer-to-Peer Computing », D. Barkai, Intel press, 2001, Octobre 2001. [7] « Harnessing the power of disruptive technologies”, A. Oram éditeur, edition O’Reilly, Mars 2001 [8] « The Grid : Blueprint for a new Computing Infrastructure », I. Foster et C. Kesselman, Morgan-Kaufmann, 1998. GRID@Inria

44. 3nd International Scientific Workshop on IEEE International Symposium on Cluster Computing and the Grid (CCGrid'2003)Toshi Center Hotel May 12-15, 2003 Tokyo, Japan GP2PC 2002 received 30 submissions from around the world The workshop span over 2 days in parallel of CCGRID GP2PC 2003 will include a new topic: Merging GRID and P2P Submissions due: November 24 2002Notification of acceptance: January 10 2003 Camera ready papers due: February 21 2003 www.lri.fr/~fci/GP2PC GRID@Inria