ORAP128 Mars 2002 Xtremweb : une plateforme de calcul global et pair a pair Franck Cappello CR CNRS Responsable groupe Clusters et Grilles LRI, Université.

Présentation au sujet: "ORAP128 Mars 2002 Xtremweb : une plateforme de calcul global et pair a pair Franck Cappello CR CNRS Responsable groupe Clusters et Grilles LRI, Université."— Transcription de la présentation:

1 ORAP128 Mars 2002 Xtremweb : une plateforme de calcul global et pair a pair Franck Cappello CR CNRS Responsable groupe Clusters et Grilles LRI, Université Paris sud.

2 ORAP228 Mars 2002 LRI (Laboratoire de Recherche en Informatique), Université Paris sud, Orsay (30 Km de Paris) Membres: F. CappelloCNRS C. GermainMaître de conférence V. NériIngénieur A. SelikhovPostDoc G. FedakDoctorant G. BosilcaDoctorant G. KrawesikDoctorant A. DjilaliDoctorant O. LodigenskyDoctorant Info: http://www.lri.fr/~fci fci@lri.fr Tsukuba University, RWCP, EADS, IFP IBM Watson, ORNL, GMD, Toronto, SDSC/UCSD, Argonne IMAG, LIFL, LARIA, Polytechnique, Lab. Math, Physique, bio at Orsay: LAL, IPN (IN2P3), IBBMC Collaborations :

3 ORAP328 Mars 2002 Sommaire Introduction systèmes calcul global et P2P Le système XtremWeb I Le projet d’ACI GRID CGP2P Conclusion Pour en savoir plus

4 ORAP428 Mars 2002 Différents types de GRID 2 types de grands systèmes distribués Les Grilles de calcul ou « GRID » Les systèmes de Calcul Global ou « Mega Computing » ou « Internet Computing » Les systèmes Pair à Pair Les systèmes distribués à grande échelle Grands sites de calcul, Clusters PC Windows, Linux <100 Stable Identification individuelle Confiance ~100 000 Volatile Pas d’ident individuelle Pas de confiance Caractéristiques des nœuds :

5 ORAP528 Mars 2002 Extensibilité : jusqu ’à 100 k voire 1 M machines Hétérogénéité : différents matériels et OS Dynamicité : nombre de clients et de serveurs évoluent constamment Disponibilité : le propriétaire d ’une ressource doit pouvoir définir une politique de partage de sa ressource Tolérance aux pannes : le système (et peut être les applications) doivent supporter l ’existence d ’éléments défaillants Utilisabilité : malgré les propriétés précédentes, le système doit rester facilement programmable et maintenable Sécurité : le système doit être sécurisé 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. Caractéristiques fondamentales des systèmes distribués à grande échelle

6 ORAP628 Mars 2002 Calcul numérique à grande échelle Historique 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

7 ORAP728 Mars 2002 PC Volontaire Télécharge et exécute l’application PC Volontaire Paramètres Application Cliente Params. /résults. Internet PC Volontaire serveur Systèmes de Calcul Global Définition Pragmatique : Calcul Maître-esclave Par vol de cycles sur Internet 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, Un serveur centraliser ordonnance des calcul sur des PC volontaires

8 ORAP828 Mars 2002 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), Volontaire Application Provider Volontaire PC volontaire Participant à la mise en relation entre Pair Internet Client req. Système Pair à Pair (Peer to Peer) Toutes les ressources (PC) sont égales, les opérations se font à parité, de pair à pair.

9 ORAP928 Mars 2002 Rationalisation des systèmes P2P Composants fondamentaux PC Requête PC Ressource Requête Internet, Intranet ou LAN Mécanisme mise en relation Recherche de résultats Recherche de clés. (CAN, PASTRY, TAPESTRY, CHORD, etc.) Ressource PC Ressource Internet, Intranet ou LAN Mécanisme de Transport (transfert de résultats) Ressource Internet Ressource : -fichier -service Firewall Tunnel

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

11 ORAP1128 Mars 2002 Sommaire Introduction systèmes calcul global et P2P Le système XtremWeb I Le projet d’ACI GRID CGP2P Conclusion Pour en savoir plus

12 ORAP1228 Mars 2002 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) Les requêtes peuvent être relatives à des données ou des calculs Accepte concerne des Calculs ou des données Une plate-forme de rechercher opensource pour étudier : System CGP2P Mon PC requête résultat un PC accepte fournit PC Un autre PC accepte fournit Communications Potentielles pour les Applications parallèles

13 ORAP1328 Mars 2002 Objectifs XtremWeb : Entropia : Plate-forme de GC complète : Entropia platform (Entreprise) Gros projets (Internet) United Devices : Plate-forme de GC complète : Metaprocessor (Entreprise) Global Metaprocessor (Internet) XtremWeb ne vise pas à construire une plate-forme avec des millions d’utilisateurs (SETI, Napster, Gnutella, Freenet, etc.) XtremWeb est beaucoup plus un environnement pour construire des clusters par dessus Internet ou à l’intérieur d’un réseau propriétaire multi-sites. Cosm: Un ensemble de fonctions (sdk) pour construire des applications de Global Computing (P2P?) Active Cluster de Platform : LSF + vol de cycles sur PC windows (LAN, WAN)

14 ORAP1428 Mars 2002 Architecture Générale XtremWeb 1 L’architecture actuelle est centralisée Global Computing et Peer to Peer (modèles d’interaction) 3 entités : client/server/worker PC Client/Worker Internet ou LAN PC Serveur Global Computing (client) PC Worker PC Serveur Peer to Peer PC Client/worker PC Worker XW Serveur hiérarchique

15 ORAP1528 Mars 2002 Worker Server WorkRequest workResult hostRegister workAlive Architecture du Worker Protocol: traverser les pares feux (firewalls) XML RPC et SSL authentification and cryptage Applications  Binaire (codes CHP en Fortran ou C)  Java (codes récents, codes objet) Systèmes d’exploitation  Linux  Windows Mode d’opération  Screen saver  contrôle à distance du serveur (on/off)

16 ORAP1628 Mars 2002 Architecture des Servers Requêtes WorkerRequêtes Client Serveur Http Ensemble de base de données Applications Tâches Résultats Statistiques Sélecteur de tâches Gestionnaire de priorités Scheduler Communication Layer XML-RPC TCP SSL Tâches Collecteur Résultats

17 ORAP1728 Mars 2002 Client Server Configure experiment Architecture du Client Une API Java  soumission de tâches  collection de résultats  contrôle du serveur Applications  Multi-paramêtres, sac de tâches  Maître-esclave (iteratif), EP Contrôle du serveur  configuration de la plate-forme (nombre de Workers, type de Workers, etc.) Launch experiment Collect result Worker Get work Put result

18 ORAP1828 Mars 2002 Technologies de réalisation Prérequis pour l’installation: dase de données (Mysql), serveur web (apache), PHP, JAVA jdk1.2. Base de données SQL PerlDBI Java JDBC Serveur Java Communication XML-RPC SSL Serveur Http PHP3-4 Installation GNU autotool Worker Client Java

19 ORAP1928 Mars 2002 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) Worker Aires PC worker paramètres Server Internet ou LAN PC Worker PC Client Base de données de paramètres (Lyon, France) XtremWeb Centres de calcul traditionnels CINES (Fr) Fermi Lab (USA) Nombre de PC estimé ~ 5000 Observatoire Pierre Auger

20 ORAP2028 Mars 2002 Lancer de rayons Pair à Pair Image originale : Film calculé avec Xtrem RayTracing Caméra Scène Source Produire un film à partir d’une scène PovRay. Prototype réalisé au LRI Worker

21 ORAP2128 Mars 2002 XW I sur ressources légères Personal multi-Computer (PmC)

22 ORAP2228 Mars 2002 - CGP2P (Calcul Global et Pair à Pair) XW + stockage + ordonnancement + applications parallèles, – ASP, mutualisation, simulation numérique, Guillaume Alléon XW + composants numériques CORBA –AIRCAST XW + Pocket PC + Wireless for news casting inside Paris-Sud University. – IRIS project: multi-server XtremWeb –IFP stage de DEA en cours avec installation d’XW + applications IFP –EADS stage de DEA en cours avec installation d’XW et application EADS –XtremWeb Toronto (education and research) Education (Global Computing) and parallel processing with XW. –XW Math (Mathematics lab – Paris south University) Autres projets utilisant XW

23 ORAP2328 Mars 2002 Sommaire Introduction systèmes calcul global et P2P Le système XtremWeb I Le projet d’ACI GRID CGP2P et MPICH-V Conclusion Pour en savoir plus

24 ORAP2428 Mars 2002 Fusion des concepts de Calcul Global et de système Pair à Pair (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

25 ORAP2528 Mars 2002 Guillaume Alléon EADS Joffroy Beauquier LRI Jacques Briat IMAG-ID Franck Cappello LRI Henri Casanova SDSC (USA) Christophe Cérin LARIA Bernadette Charron Bost LIX Alain Cordier LAL Cécile Germain LRI Michel Jouvin LAL Oleg Lodygensky LAL/LRI Vincent Néri LRI Franck Petit LARIA Serge Petiton LIFL/ASCI Cyril Randriamo LARIA Olivier Richard IMAG-ID Brigitte Rozoy LRI Gil Utard LIP Vincent Villain LARIA George Bosilca LRI Adberhamanne Djilali LRI Gilles Fedak LRI Oleg Lodygensky LAL/LRI Aton Selikov LRI Marta Gonzalez LIFL/ASCI Thomas Hérauet LRI Laboratoires : ASCI, IMAG-ID LAL, LARIA/LIP, LIFL, LRI, LIX-Polytechnique, 26 chercheurs, 7 Laboratoires

26 ORAP2628 Mars 2002 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) Ordonnancement (Sous projet IV) Vérification théorique des protocoles (Sous projet V) Interopérabilité avec les GRID (Sous projet V) Validation sur des applications réelles (EADS) Les thèmes de recherche CGP2P

27 ORAP2728 Mars 2002 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. PC client Get Internet Ou LAN Mémoire de canal Put PC client MPI_send()PC client MPI_recv() Vue du programmeur : Proposition pour résoudre le problème Utiliser une mémoire de canal : qui stocke tous les messages, est fiable, qui accepte les communications XW

28 ORAP2828 Mars 2002 PC client Get Internet ou LAN PC Mémoire de canal Put PC client Get 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 Communication inter nœuds : MPICH-V Est ce que ça fonctionne vraiment ? théorique : modélisation, étude des cas limites Collaborations avec l’équipe Paral du LRI Expérimentale : réalisation, expérimentation, performance Vérification Intérêt  reprendre uniquement la (les) tâche(s) défaillante(s)

29 ORAP2928 Mars 2002 Communication inter nœuds : MPICH-V Vérification théorique : t1 t2 t3 mc1 mc2 Ordre initial : Dans le cas général, il faut reproduire les com. à l’identique !!  Problème du MPI_recv(any,…)  À 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

30 ORAP3028 Mars 2002 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 Worker Internet ou LAN Worker Serveur de tâches «ordonnanceur » worker Mémoires de canal Serveurs de checkpoint

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

32 ORAP3228 Mars 2002 Inter-node communication: MPICH-V (Volatile) Very first experiment results (RTT Ping-Pong) : 2 PIII 500, one Channel Memory, 100base T Message size (bytes) Time, sec ch_p4, mean ch_p4, min ch_xw, min 1 ch_xw, mean 1 X ~2 X ~2,33 5,4 Mo/s 2,6 Mo/s Eager/rendez-vous threshold PC client Get Internet Or LAN Channel Memory Put The X2 factor compared to P4 is reasonable since each message crosses the network twice

33 ORAP3328 Mars 2002 Communication inter nœuds : MPICH-V Checkpoint : bibliothèque existante  Condor 6 minutes 3 minutes Temps checkpoint (sec)Temps réseau TCP (min) 3 minutes PIII 500

34 ORAP3428 Mars 2002 Performances pour une application parallèle sur ressources Volatile ? n tâches, m > n machines, c checkpoints (période), un temps séquentiel ts et une accélération linéaire, p % de restarts, d minutes pour un checkpoint Tparv= (ts/n) + p *n * ((ts/n)/c) + c * d  Plus le nombre de checkpoints est grand, moins le temps perdu par une tache non terminée est important.  Plus le nombre de checkpoints est grand, plus le temps perdu pour La sauvegarde est important Communication inter nœuds : MPICH-V

35 ORAP3528 Mars 2002 Communication inter nœuds : MPICH-V Tparv= (ts/n) + p *n * ((ts/n)/c) + c * d Accélération Nombre de checkpoints (c) n=1000 ts= 144000 min (100 jours) tcom négligeable 0 100 200 300 400 500 600 700 0100200300 P=0,01, d=1min P=0,1, d=1min P=0,1 d=10min P=0,01, d=10min 0 100 200 300 400 1101001000 Minutes 500 600 700 800 900 1000 1100 1200 Une nuit

36 ORAP3628 Mars 2002 Sommaire Introduction systèmes calcul global et P2P Le système XtremWeb I Le projet d’ACI GRID CGP2P Conclusion Pour en savoir plus

37 ORAP3728 Mars 2002 Besoin d’outils théoriques : Modèles de performance, modèles de défaillance Mais aussi besoin d’outils expérimentaux (instruments) pour l’étude des systèmes complexes à grande échelle Observations / mesures : Plate-forme de tests en grandeur nature TestBed (CGP2P) l Un collecteur de Traces de paramètres de ressources (XW-trace) l Un ensemble de benchmarks et de sondes Expériences en environnement contrôlé (reproduire les conditions expérimentales) : l Un(des) Emulateur(s) reproduisant avec des degrés de fidélité variable le système et les conditions expérimentales (XW-emulator) l Des simulateurs (ex : ordonnancement totalement distribué) Nécessité d’un environnement expérimental complet

38 ORAP3828 Mars 2002 Conclusion Les études sur les systèmes de calcul global et P2P pour le calcul haute performance sont très récentes (XtremWeb, IRISA projet Paris) XtremWeb constitue l’une des premières plate-forme complète de recherche et de production. WWW. XTREMWEB.NET XtremWeb 1 est en phase de mise en production au LAL (IN2P3) Le projet d’ACI GRID CGP2P étudie la prochaine génération de systèmes P2P fusionnant calcul et stockage. Il existe de nombreux problèmes scientifiques et techniques MPICH-V est vérifié fonctionnellement et théoriquement et en cours d’optimisation La recherche dans ce domaine doit nécessairement inclure les composantes théoriques et expérimentales.

39 ORAP3928 Mars 2002 Pour en savoir plus [1] « 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 [2] Projet ACI GRID CGP2P, www.lri.fr/~fci/CGP2P.html [3] Projet XtremWeb, www.xtremweb.net [4] Deuxième Workshop International « Global P2P Computing », avec IEEE/ACM CCGRID 2002, Berlin, Mai 2002, www.lri.fr/~fci/GP2PC.htm [5] « Peer-to-Peer Computing », D. Barkai, Intel press, 2001, Octobre 2001. [6] « Harnessing the power of disruptive technologies”, A. Oram éditeur, edition O’Reilly, Mars 2001 [7] « Search in power-law networks », L. A. Adamic et al. Physical Review, E Volume 64, 2001 [8] « The Grid : Blueprint for a new Computing Infrastructure », I. Foster et C. Kesselman, Morgan-Kaufmann, 1998.

40 ORAP4028 Mars 2002 2nd International Scientific Workshop on IEEE International Symposium on Cluster Computing and the Grid (CCGrid'2002) Berlin-Brandenburg Academy of Sciences and Humanities May 23 - 24, 2002 Berlin, Germany http://www.ccgrid.org/| http://ccgrid2002.zib.de/ A Framework for Classifying Peer to Peer Technologies, Krishna Kant, Ravi Iyer (Enterprise Architecture Lab, Intel Corporation), Vijay Tewari (E-Business Solutions Lab, Intel Corporation) Improving Data Availability through Dynamic Model-Driven Replication in Large Peer-to-Peer Communities, Adriana Iamnitchi, Kavitha Ranganathan, Ian Foster (Department of Computer Science, Chicago) NEVRLATE: Scalable Resouce Discovery, Ajay Chander (Computer Science Department, Stanford University) Steven Dawson, Patrick Lincoln, David Stringer-Calvert Maintaining Connectivity in a Scalable and Robust Distributed Environment, Mark Jelasity (Department of Artificial Intelligence, Free University of Amterdam), Mike Preuss (Department of Computer Science, University of Dortmund), Marten van Seen (Free University of Amsterdam), Den Paechter (Napier University) Motivating Computational Grids, D. Skillicorn (Computer Science Department, Queens University) JM: A Jini Framework for Global Computing, Zoltan Juhasz (Department of Information Systems, University of Veszprem and Department of Computer Science, University of Exeter), Arpad Andics, Szabolcs Pote (Department of Information Systems, University of Veszprem) …

41 ORAP4128 Mars 2002 Sécurité des ressources Ressource d’exécution PC agressif code agressive Internet ou LAN Sans authentification utilisateur, garantir la sécurité des ressources ? (le code utilisateur ne doit pas pouvoir corrompre une ressource ) Exécution de codes natifs : Application Interception Exécution Appel système “Sandboxing” du code natif (fondé sur ptrace): Janus, Subterfugue, Processus Père contrôleur Vérification des arguments (pile) Autorisation Fork (ptracé) Proc ptracé Noyau Zone Susceptible d’attaques par « race condition »

42 ORAP4228 Mars 2002 Sécurité des ressources Application « exécution » Noyau natif Appel système vérifié par le système émulé Appel système Application Système virtuel avec contrôle fondé sur ptrace : UML Fork (ptracé) Linux Security Modules (LSM) : Noyau … Write(…) … Setparams nop jmp @ nop nop … Application Appel système Hook Module sécurité Modifications Code de vérification Autorisation

43 ORAP4328 Mars 2002 Sécurité des ressources : Performance comparée des natifs et des natifs sandboxés 1 51 101 151 201 251 getpid read write stat open/close fork+ /bin/sh Sans sandbox LSM en us Subtergugue en us UML en us Ralentissement par rapport au natif Pentium 4 1,7 Ghz, 256 Mo, Linux 2.2.4 Performance d’opérations systèmes : Getpid, open/close, read, write Performance sur applications : 0 0,5 1 1,5 2 2,5 gzipgunzipgcc Ralentissement par rapport au natif LSM est + rapide car le patch du noyau enlève les « capabilities » Sub est + rapide qu’UML parce qu’il effectue moins de changements de contexte

44 ORAP4428 Mars 2002 Sécurité des ressources : Les limites de l’approche Ptrace Pentium 4 1,7 Ghz, 256 Mo, Linux 2.2.4 Caractéristiques des applications : 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% gzipgunzipgcc autre read/write open/close fork Répartition des appels systèmes dans le temps d’exécution Ptrace intercepte tous les appels systèmes (malloc, mmap, etc.)

45 ORAP4528 Mars 2002 Sécurité des ressources : Performance comparée de JVM et de codes natifs Performance sur des codes : Pentium 4 1,7 Ghz, 256 Mo, Linux 2.2.4 Sun JVM 1.2.0 Sun JVM 1.3 Sun JVM 1.4 IBM 1.3 CG, EP,FT (NAS), SOR, MC, Matmul, LU, Linpack Natif plus performant mais dernière JVM proches 0 0,2 0,4 0,6 0,8 1 1,2 "CG" "EP" "FFT" "SOR" "MC" "MatMul" "LU" "Linpack" SUN 1.2 SUN 1.3 SUN 1.4 IBM 1.3 Natif Performance relative au natif

46 ORAP4628 Mars 2002 Sécurité des ressources : Performance comparée de JVM et de codes natifs sandboxés Surcoût de l'interposition 11 214 51 1,3 249 52 1,71,76 1,2 251 51 1,9 7 7,2 489 126 36 146 1 10 100 1000 LSMSubterfugueUMLJava sans secuJava+ SecurityManager Temps en micosecondes getPid Read (1B) Write (1B) open/close Natif Performance d’opérations systèmes : Getpid, open/close, read, write. Pentium 4 1,7 Ghz, 256 Mo, Linux 2.2.4 Sun JVM 1.4.0 Java plus performant pour les read/write Coût d’interposition LSM nul (mais actuellement sans vérification) Getpit ~ coût s’un syscall -Signal (Ptrace), -changement de contexte -interprétation Python (Subterfugue)

47 ORAP4728 Mars 2002 0 50 100 150 200 250 256128643216842 1 Java sans sécu Java avec sécu natif sans sécu natif avec sécu 16 workers Sécurité des ressources : Performance comparée Java, Java+ sec, natif, natif+sec Exécution du benchmark EP classe A sur 16 Pentium III 500 Mhz dans un système complet (XW 1.0) Temps (s) Nombre de tâches Natif + performant (15%) Pas de ralentissement notable de la sécurité (Subterfugue et Java) Saturation : l’overhead du système atteint le temps d’exécution de l’application

48 ORAP4828 Mars 2002 Un nouveau type d’architectures parallèles : Un très grand nombre de ressources (>> machines parallèles) Des capacités de communication très faibles Un nouveau type de systèmes distribués (répartis ?) : Un très grand nombre de ressources (>> machines parallèles) La volatilité comme caractéristique Nouveaux Problèmes : Comment programmer ces architectures ? Domaine d ’applications (EP, multi-paramètres, parallèles) Evaluation de Performance (benchmark, mesures, paramètres) Modèles de performance (orienté programmation « à la BSP », orienté performance « à la LogP) Nouvelle algorithmique Modèle économique Motivations pour le calcul à grande échelle

49 ORAP4928 Mars 2002 CASPER: Community based Application Service ProvidER Pc ou Station Client Gestion des utilisateurs Portail (pages web) Soumission Ordre de calcul Transfer donnees Gestion des donnees Cluster Calculateurs // Ordre de calcul Transfer donnees Ordre de calcul Transfer donnees Java Execution Composant Execution Composant Corba Html SSL Donnes ASP XtremWeb Execution distribuee sur Internet Execution Composant Donnes Scheduler ASP (Application Service Provider) fournisseur de calculs et gestionnaire/distributeur d’informations (param. / res.) pour les industriels utilisant la simulation numérique

50 ORAP5028 Mars 2002 CASPER Applets signées Navigateur Web Service client Casper Serveur Web authentifie signe RMI/TLS HTTP/TLS Visualisation JSP Gestion des données Sécurité (JSSE) Ressources grappes Ressources distribuées Gestion des utilisateurs Gestion des ressources XtremWeb LSF Organisme de certification GridEngine