Modèles d’exécution parallèles pour les architectures hautes performances et les grands systèmes distribués Franck Cappello Groupe Clusters et Grilles Laboratoire de Recherche en Informatique, Université Paris Sud, Orsay, fci@lri.fr http://www.lri.fr/~fci

Sommaire Introduction aux Modèles d’exécution QUID: programmation efficace architectures parallèles complexes a partir des environnements standards MPI et OpenMP OVM: un modèle d’exécution pour les applications régulières et irrégulières XtremWeb : une plate-forme d’expérimentation des systèmes distribués à grande échelle Conclusion et Perspectives

Applications, architectures, langages et modèles d’exécution De plus en plus d’utilisateurs (industries, laboratoires de recherche) ont recours au calcul haute performance. Les architectures évoluent vers des agrégats avec des niveaux de couplage variables Météorologie Physique des hautes énergies Bio informatique Traitement d’images Synthèses d’images Simulation de Microprocesseurs Etc. Clusters de SMP Langages de programmation et modèles d’exécution sont les pierres angulaires pour atteindre les hautes performances sur les machines parallèles PC Clusters Applications régulières: Sans équilibrage de charge Applications irrégulières: Avec équilibrage de charge Limitée par les performances de calcul (compute bound) d’entrées-sorties (I/O bound) GRID, Calcul Global, P2P

Interface de Program. d’Appli. Place fondamentale du modèle d’exécution Applications Modèle de programmation Ex : dataparallélisme, modèle concurrent, maître-esclave Expression Langages Langages standards : Fortran, C, C++, Java, Matlab, Scilab Modèle d’exécution Passage de Messages : MPI, OVM (RPC), Mémoire Virtuellement partagée : Scach, TreadMarks, Interface de Program. d’Appli. Environ. de résolution de problèmes : Netsolve, Ninf, Environnement d’exécution Système de Calcul Global : Globus, Legion, XtremWeb Passage de messages pour GRID: MPICH-G, Machine virtuelle Mem. virtuellement partagée pour GRID: OmniOpenMP GRID, Calcul Global, P2P Système d’exploitation Matériel d’exécution Architectures Clusters de SMP Clusters

Rôle fondamental pour la portabilité des codes et la virtualisation des architectures Entropia, United Dev Grds sys. dist SETI@home Grilles locales Cluster X86, Alpha, Itanium 500 SIMD Constellation (cluster SMP) Compaq SC Sun HPC cluster NEC SX4 / Earth TOP 500 400 SGI O3000 / 2000 HP Hyperplex Sun HPC 10000 MPP 300 IBM SP3 Hitachi SR8000 CRAY T3E 200 Fujitsu VPP 5000 100 SMP Mono HP superdome Processeur NEC SX 5 93 94 95 96 97 98 99 00

Trois angles de recherche Objectif : Isoler et comprendre les mécanismes fondamentaux de la programmation haute performances des architectures parallèles complexes et des grands systèmes distribués applications régulières avec environnements standards (MPI et OpenMP) un environnement d’exécution pour les applications régulières et irrégulières un environnement d’exécution pour les clusters à couplage très lâche Programmation efficace des architectures complexes avec MPI et OpenMP Out-of-order execution parallel Virtual Machine (une machine parallèle virtuelle à ordonnancement macro dataflow) Une plate-forme expérimentale du Calcul global et Pair à Pair

Le projet Little TiPI du LRI Doctorant : Olivier Richard (co-encadré) Etude des clusters de PC multiprocesseurs Début du projet 1996 Cluster de bi Pentium pro en 1997 Cluster de bi Pentium II 300 en 1998 Cluster de quadri P II Xeon en 1999 Cluster de bi Pentium III 500 en 2000 Sujets de recherche caractérisation de la charge des serveurs et des stations dans un site informatique adaptation de MPI pour cluster de multipro début d’OVM Collaborations : RWCP (Score), Université de Bonn, Labo de math PXI, IBM France Little TiPI en 1998 1997 4x4 Clump en 1999

Sommaire Introduction aux Modèles d’exécution QUID: programmation efficace architectures parallèles complexes a partir des environnements standards MPI et OpenMP OVM: un modèle d’exécution pour les applications régulières et irrégulières XtremWeb : une plate-forme d’expérimentation des systèmes distribués à grande échelle Perspectives

Le projet QUID: Programmer efficacement les architectures parallèles complexes Doctorant : Géraud Krawezik IDRIS, CINES, CEA, ORNL, LLNL, SDSC, Etc. Mémoire partagée Mémoire Processeurs bus E/S Interface Réseau Réseau Noeud Passage de Messages Commutateur NUMA IBM SP3, Compaq SC SGI Origin 2K, IBM Power4 Compaq ev7, SGI Origin 3K Earth Simulator Sujets de recherche : Quel modèle utiliser pour les applications SPMD (appli. MPI existantes) ? Passage de messages ? ou Hybride (PM + Mémoire Partagée) Collaborations : ORNL (accès aux machines), IBM ACTC, Université de Tsukuba, EADS (CIFRE)

Etat de l’art Etude simulation de courant océanique (SDSC) peu de noeuds Produit matrice-vecteur (Karlsruhe) peu de noeuds Prédiction de vague –CGWAVE- (US Major Shared Resource Center) résolution d’un grand système creux par gradient conjugué (solveur de Krylov sur les nœuds) ACTC (IBM) quelques résultats sur peu de noeuds Dynamique des fluides sur grille non structurée (ASCI RED) … 1) Assez peu d’études publiées 2) Peu de comparaisons entre hybride et Pass. de Messages 3) Pas de résultat permettant de comprendre pourquoi un modèle serait meilleur que l’autre dans le cas général

Modèle à passage de messages « tout MPI » : • communication en espace utilisateur • communication intra SMP à travers la mémoire partagée Noeud Noeud Mémoire Mémoire Communication intra-noeud Communication inter-noeud Processeurs Processeurs Les programmes MPI fonctionnent sans modification

Modèle hybride « grain fin » Passage de messages (SPMD) (Original MPI prog.) Passage de messages + mémoire partagée (OpenMP) Section séquentielle seq part seq Section à 1 thread Initialisation part init MPI init SMP part init // part Calcul. calcul non parall. Section à >=1 (OpenMP) comm. Calcul. Section à plusieurs processus parall.. sync sync Terminaison end // part end SMP part Section à 1 thread seq Section séquentielle part

Un exemple de programme : CG, NAS 2.3 subroutine conj_grad ( colidx,…) do i = 1, l2npcols call mpi_irecv( rho,…) call mpi_send( sum,…) call mpi_wait( request,…) enddo … !$OMP PARALLEL PRIVATE(k,sum) !$OMP DO do j=1,lastrow-firstrow+1 sum = 0.d0 do k=rowstr(j),rowstr(j+1)-1 sum = sum + a(k)*p(colidx(k)) w(j) = sum !$OMP END DO !$OMP END PARALLEL do i = l2npcols, 1, -1 call mpi_irecv(…) call mpi_send(…) return end program cg … call initialize_mpi call setup_proc_info( num_procs, …) call setup_submatrix_info( l2npcols,…) do it = 1, niter call conj_grad ( colidx,…) do i = 1, l2npcols call mpi_irecv( norm_temp2,…) call mpi_send( norm_temp1,…) call mpi_wait( request,…) enddo endo call mpi_finalize(ierr) end

MPI contre MPI+OpenMP NAS 2.3 Classe A, 2 nœuds SP différents (rapport des temps d’exécution) Quadriprocesseur (WH2 375-MHz) Quadriproceseur (NH1 222-MHz) 1 2 4 8 16 32 1 2 4 8 1,4 1.5 1,2 1 1 MPI / MPI+OMP MPI / MPI+OMP 0,8 0.5 0,6 0,4 0,2 cg ft lu mg bt sp cg ft lu mg bt sp Rapport < 1 signifie que MPI est meilleur MPI est le meilleur modèle dans la plupart des cas Résultat contre-intuitif ! Pourquoi ?  décomposition du temps d’exécution

Coût des sections non parallélisées avec OpenMP Pourcentage du temps d’exécution passé dans les régions parallèles OpenMP Nœuds WH2 (avec 1 processeur/noeud) temps exé parall / temps exé global 1 2 4 8 16 32 1 0,8 0,6 0,4 0,2 cg-A cg-B ft - A ft - B lu - A lu - B mg-A mg-B Accélération maximale théorique MPI+OpenMP 1.22 1.65 2.20 2.50 1.56 1.76 1.75 1.71 Les sections non parallélisées sont le facteur limitant principal pour l’approche hybride MPI+OpenMP à grain fin (LU, MG, BT,SP)

speedup superlinéaire Accélération comparée dans les régions purement parallèles Noeuds WH2 4 voies - Class A Efficacité parallèle accélération /nb procs Nombre de noeuds speedup superlinéaire Meilleure utilisation des caches 1 2 4 8 16 32 2,5 2 speedup sub linéaire 1,5 1 0,5 Pénalité mémoire cg cg ft ft lu lu mg mg mpi mpi omp mpi mpi omp mpi mpi omp mpi mpi omp L’efficacité parallèle dans les sections purement parallèles est meilleure avec MPI (résultats similaires avec la classe B) Il y a deux raisons principales Organisation des accès mémoire. OpenMP ne permet pas d’exprimer les distributions multi-dimensionnelles des itérations d’un nid de boucles Surcoût de la gestion et de la synchronisation des threads

Coût du partage du support de communication Noeuds WH2 4 voies - Class A calcul mpi Comm mpi calcul mpi+openmp Comm mpi+openmp 30 150 20 100 temps (sec) temps (sec) CG_A Calcul CG_A Comm. 10 50 1 2 4 8 16 32 MPI a un temps de calcul plus faible. MPI+OpenMP a un temps de communication plus faible N processus contre 4N processus pour N nœuds messages longs (débit de communication) Tendance similaire pour MG et FT. Le temps de communication peut être le facteur limitant le performances globales pour le modèle MPI (CG, MG, FT)

Nouveaux résultats : l’approche « gros grain » Programmer avec OpenMP en suivant le paradigme SPMD Grain fin Gros grain … ! Initialisation MPI !$OMP PARALLEL !$OMP DO do i=1,n end do !$OMP END DO MPI_SEND(…) end … ! Initialisation MPI !$OMP PARALLEL do i=1,n end do MPI_SEND(…) !$OMP END PARALLEL end Distribution du travail par le programmeur (adaptation des limites de boucle)  Parallélisation explicite Coordination des threads très complexe (faux partage, synchro) Un très grand nombre de régions parallèles Surcoût très élevé de la gestion des threads (fork-join, sync)

Revenir à un problème plus simple : CG (NAS 2.3) sur 1 nœud SMP Objectif : fournir une version OpenMP de CG produisant les mêmes performances que la version MPI sur une machine SMP Buts : Inclure le plus de code possible dans une seule région parallèle Conserver les nids de boucles de la version MPI (Seq, MPI) Utiliser la meilleure technique de réduction possible Schéma de calcul de CG: init part // Calc. Réduction Sync. Résultats : Une seule région parallèle Nids de boucles identiques à MPI Choix de la technique de réduction parmi 5 possibles (et intuitivement intéressantes) fin part //

Choix de la technique de réduction Techniques : Barrière Atomic Do Reduction Barrière (en arbre binaire) Verrous (en arbre binaire) Barrier atomic DO reduction Barrier tree Lock tree Réduction de 32 valeurs SP3 NH2 Réduction de 32 valeurs SGI O3.8K 1 10 100 1000 2 4 8 16 32 Temps ms 10000 1000 Temps ms 100 10 1 Nb proc. 1 2 4 8 16

Temps de communication MPI contre OpenMP sur CG NAS 2.3 Temps passé dans la partie calcul de CG mpi relativement à la version MPI 2,5 OpenMP grain fin (statique) 2 OpenMP gros grain 1,5 OpenMP gros grain + attachement 1 ref MPI OMP gros grain OMP grain fin 0,5 1 2 4 8 16 nb processeurs perf NAS CG A - IBM NH2 (1 noeud) 2500 Temps de communication et synchronisation 2000 0,4 0,35 1500 Mflops 0,3 0,25 1000 Temps (s) 0,2 0,15 500 0,1 MPI OMP gros grain 0,05 1 2 4 8 16 1 2 4 8 16 nb processeurs nb processeurs

Résumé L’approche MPI unifiée est la plus performante dans le cas général comparativement à l’approche hybride grain fin Il existe des raisons fondamentales à ce résultat L’approche gros grain (SPMD, ou à parallélisme explicite) permet d’augmenter significativement les performances d’OpenMP pour les nœuds SMP La programmation « données non partagées » implique l’utilisation d’opérations globales (et peut être d’échanges point à point) Les meilleures performances intranoeud et internoeud permettent-elles à l’approche hybride gros grain de dépasser le passage de messages dans le cas général ?

Perspectives Evaluer différentes approches pour les opérations globales : Bibliothèque d’opérations globales pour threads (HPC++) Une bibliothèque d’opérations globales pour l’approche OpenMP gros grain sur les machines à mémoire partagée Approche hybride gros grain pour grappes de multiprocesseurs 1) avec réseau à passage de messages 2) avec réseau NUMA – SGI O3000, IBM SP4 Placement/migration automatique/contrôlé de pages et/ou utilisation des directives de placement proposées pour OpenMP Cluster de NUMA et Cluster de NUMA cluster de SMP Programmation efficace des architectures parallèles complexes

Sommaire Introduction aux Modèles d’exécution QUID: programmation efficace architectures parallèles complexes a partir des environnements standards MPI et OpenMP OVM: un modèle d’exécution pour les applications régulières et irrégulières XtremWeb : une plate-forme d’expérimentation des systèmes distribués à grande échelle Conclusion et Perspectives

Nécessité d’un environnement unique pour les applications régulières et irrégulières Régulières, Irrégulières (équilibrage de charge), Certaines Applications irrégulières s’expriment « naturellement » dans le mode Maître-esclave ou fonctionnel récursif Modèle SPMD synchrone et applications réelles sur les architectures // complexes sync comm. Calc. Attente Pénalité de cache ou Déséquilibrage de charge Maître Point de départ Esclaves 1) Importante dégradation de performance en cas de déséquilibrage de charge Emuler le mode maître-esclave ou fonctionnel Modèle SPMD synchrone

Une sélection d’environnements pour équilibrage de charge Equilibrage de charge dans les environnements multi-flots : Athapascan (graphe dataflow + évaluation distribuée), lab ID, ENSIMAG PM2 (migration de threads), LIFL, ENS Lyon Cilk (vol de travail dans une pile de récursions), MIT Equilibrage de charge à partir de langages objets (95, 96) : Dome (c++ et PVM), SPMD, check point et migration Charm, Charm++, Urbana Chanpaign Equilibrage de charge à partir de PVM/MPI (93-94-95 ; 01) : MPVM (migration de processus unix) Oregon Graduate Institute of S & T. UPVM (migration de threads) Oregon Graduate Institute of S & T. Dynamic PVM (condor checkpoint), University of Amsterdam MPI TM (migration de tâches – core dump) Mississippi State University AMPI (migration de threads par dessus Charm++) Urbana Champaign Dynamite PVM (migration de tâches)

Nécessité d’un environnement unique pour une grande variété d’architecture Clusters, SMP, NUMA, Cluster de SMP,Cluster NUMA de SMP, … Cluster de SMP pseudo-vectorielles Clusters NUMA de SMPs Cluster de Machines vectorielles SMP                 GRID, Calcul Global, P2P Clusters de SMP Cluster de PC Proposer aux programmeurs des environnements portables permettant de pérenniser sinon leurs applications au moins leurs outils/environnements de programmation                       

Une sélection d’environnements pour une grande variété d’architectures Bibliothèques de communication : MPI (MPICH-LAM), PVM Environnement pour la mémoire partagée : OpenMP (OmniOpenMP du RWCP-Université de Tsukuba) Environnements programmation objets : Jade - Université de Stanford Amber - Université de Washinton Environnements programmation objets + macrodataflow : SMARTS pour machines à hiérarchie mémoire profonde - LANL Mentat (langage objet + environnement d’exéction) - Université de Virginie Concert - Université de l’Illinois Bibliothèques de communications pour les Grilles : MPICH-G MPI par dessus Nexus (Globus) - Argonne MPICH-G2 MPI par dessus Globus – Argonne PACX-MPI – Stuttgart (Allemagne) Meta-MPICH -Lehrstuhl für Betriebssysteme  (Allemagne)  Madeleine (PM2) – ENS Lyon 

Projet OVM : Un environnement d’exécution bas niveau pour une large variété d’architectures et d’applications Doctorants : George Bosilca, Abderhamane Djilali Sujet de recherche : Une machine virtuelle à ordonnancement macro-dataflow  Continuum entre le modèle SPMD synchrone et le modèle client-serveur Courtier (Broker) Serveurs Client Dataflow Programme Client API OVM Mém. Bib. Fonct. RPCs Ressource Programmeur Ordonnanceur OVM Mém. Bib. Fonct. Collaborations : RWCP, Université de Tsukuba,

Différents mode de RPCs 1) RPC classique Programme client Broker Serveurs Equilibre De charge RPC Fonction données Donnée volatile 2) RPC découplé Broker Serveurs RPC Gestion données Fonction id Donnée persistante Programme client

Nécessité et intérêt d’un Moteur macro-dataflow Transfère D2 Transfère D1 Programme Client Modifie D1 Serveurs RPC RPC Broker D1 F1 RPC id Gestion données RPC id id RPC Dépendance de données RPC RPC D2 F2 Nécessité : le lancement des fonctions sur les serveurs doit être conditionné par la disponibilité des variables paramètres Intérêt : seules les dépendances de données vraies limitent le parallélisme

Le moteur macro-dataflow d’OVM Broker Serveurs Tâche Construction du graphe Terminaison Client Tâche RPCs Evaluation des dépendances Lancement Requêtes prêtes Contrôle De flot Tâche Requêtes terminées Destruction du graphe Tâche

OVM sur des applications SPMD Objectif : un flot d’exécution serveurs identique au flot MPI Problèmes : masquer le coût de la gestion du macro-ordonnancement Placement cyclique des données persistantes Données persistantes Serveurs données données données données Fonctions de bibliothèques Funct 1 Funct 1 Funct 1 Funct 1 Funct 2 Funct 2 Funct 2 Funct 2 Funct 3 Funct 3 Funct 3 Funct 3 Données du macro ordonnancement données Client + broker données persistantes ordonnancement statique Opérations globales Programme du macro ordonnanceur

OVM sur des applications irrégulières Objectif : pas de migrations, nombre de tâches concurrentes Ordonnancement premier arrivé – premier servi Serveurs Fonct * Fonctions de bibliothèques Fonct X Fonct Z Fonct Y données données données Données volatiles données Données du macro ordonnancement données Client + broker données volatiles Ordonnancement dynamique Pas d’opérations globales Programme du macro ordonnanceur

Optimisations OVM pour les hautes performances RPC classique multi-protocoles : transport des paramètres dans le RPC si taille < 4 Ko collection asynchrone des paramètres sur le client si données >= 4 Ko modes bloquant ou non pour le client Opérations globales non bloquantes : un serveur passe à la suite du calcul après avoir contribué à l’opération globale Opérations globales asynchrones : les opérations globales ne terminent pas forcément dans l’ordre de lancement (permet d’exécuter simultanément des opérations globales indépendantes) Pré-lancement de tâches en cas de dépendances sur le même serveur (données persistantes) – dataflow hiérarchique Pré-lancement de tâches en mode RPC (données volatiles), sans vérification de dépendance de ressource pour permettre un recouvrement entre la collection des paramètres du service suivant et l’exécution du service courant. Cache de données volatiles sur les serveurs Utilisation simultanée des RPC classiques et découplés,

Performance de CG, FT et EP classe A Evaluation de performance sur des applications régulières OVM et MPI pour 3 noyaux du benchmark NAS NPB 2.3 : CG, FT, EP CG : communication de type réduction (petits messages) très fréquentes FT : communication de type all-to-all (grands messages) fréquentes EP : pratiquement pas de communication Cluster de PentiumPro 200 + Myrinet, environnement Score (RWCP) Opérations globales MPI optimisées Performance de CG, FT et EP classe A sur un cluster de PC 1000 EP MPI EP OVM CG MPI CG OVM FT MPI FT OVM 100 Temps (s) 10 1 2 4 8 16 32 nb procs

Evaluation de performance sur des applications irrégulières OVM pour une version parallèle d’AIRES Code de simulation de particules à très haute énergie Sur-découpage de la pile Blocs iso-énergies Perf de AIRES sur un cluster de PC 100 56,1 26,9 15,4 Accélération 10 7,66 3,96 36,8 20,8 Avec l’initialisation 13,5 7,2 Sans initialisation 3,72 1 nb procs 4 8 16 32 64

Evaluation de perf. sur des applications irrégulières Lancer de rayons temps réel avec OVM Code PovRay parallélisé Temps de calcul pour 50 scènes PovRay sur un cluster de PC Distribution de la scène à tous les processeurs Découpage en bandes Calcul pour chaque image des bornes de bandes pour tous les processeurs

Nouveaux Résultats : Radiosité avec OVM 1 10 100 2 4 8 16 32 64 128 Bohn/Garmann Singh Carter Benavides OVM Garmann 2000 2000 2001 1994 Nombre de Procs Accélération Maître-esclave avec maître participant au calcul Chargement scène Envoi scène au serveurs Tand qu’il reste des FF à calculer Calcul d’échange d’énergie Parcours des hiérarchies Raffinement (création de liens) Attente résultats Fin Initialisation Calcul continu de facteurs de forme  Client Serveurs

Résumé Il est possible d’écrire des applications parallèles régulières et irrégulières avec OVM L’environnement OVM est fonctionnel sur les clusters OVM obtient des performances comparables à MPI sur des applications régulières (test pour différents rapports opérations/communications) OVM permet d’atteindre des accélérations linéaires sur des applications irrégulières (AIRES, lancé de rayons, radiosité) en conservant une expression « Maître-esclave »

Perspectives Un environnement bas niveau unique pour une large variété Comparaison de performance avec les environnements d’équilibrage de charge comme Athapascan et AMPI. Adaptation d’OVM pour les architectures à mémoire partagée (Partage des données de l’application et partage des données d’OVM) Optimisation de la localité des références et comparaison de performance avec SMARTS Hiérarchisation / extensibilité d’OVM (cluster de multiprocesseurs) Test sur des applications de tri (PSOP), optimisation combinatoire (branch & bound), calcul creux (Cholesky) Adaptation OVM-XtremWeb Un environnement bas niveau unique pour une large variété d’applications et d’architectures parallèles

Sommaire Introduction aux Modèles d’exécution QUID: programmation efficace architectures parallèles complexes a partir des environnements standards MPI et OpenMP OVM: un modèle d’exécution pour les applications régulières et irrégulières XtremWeb : une plate-forme d’expérimentation des systèmes distribués à grande échelle Conclusion et Perspectives

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

Pourquoi d’intéresser aux grands systèmes distribués Systèmes de Calcul Global Systèmes pair à pair (entre pair)                    1 Un très grand nombre de PCs sont connectés sur Internet + Stabilité et performance d’Internet 2 Aspects sociologiques (Partage gratuit de ressources) 3 Maturité des logiciels : langages (Java, Perl, PHP) + Disponibilité en tant que logiciel libre d’applications clés : base de données, serveur web, sécurité (authentification, cryptographie) 4 Démonstration de faisabilité (SETI@home, Napster)

Calcul Global Global Computing Définition Pragmatique : Calcul Maître-esclave Par vol de cycles sur Internet Client : Lanceur de tâches, ordonnanceur + collect. de résultats Requête Résultat Internet Ou réseau propriétaire Requête Résultat Application(s) Application(s) PC serveur PC serveur Modèle Client-Serveur inversé : 1 client et n serveurs L’application exécutée sur les serveurs est fournie par le client Type de services : principalement calcul distribué (SETI@home)

Calcul Global Global Computing Applications massivement distribuées Définition Pragmatique : Calcul Maître-esclave Par vol de cycles sur Internet Applications massivement distribuées SETI@Home, distributed.net, GIMP Plus de 3 Millions d’utilisateurs, 30 TFLOPS Projets de Recherche (plate-formes) Javelin, Bayanihan, JET, Charlotte (fondés sur Java) XtremWeb (LRI), AppLeS (UCSD) Projets en cours Entropia, Parabon, Process Tree, United Devices Folding@Home, Genome@Home, Xpulsar@Home, Folderol, Gamma Flux, Exodus, Peer review Site Web de K. Pearson : http://www.nyx.net/~kpearson/distrib.html

Pas de consensus autour d’une définition. Pair à Pair (entre pair) Pas de consensus autour d’une définition. Un système dans lequel toutes les ressources peuvent agir comme des clients, des serveurs et/ou maintiennent le système lui même Gnutella Servent: SERveur et cliENT PC client/serveur Répertoire de services PC client/serveur Internet ou réseau propriétaire Répertoire de services Le service exécuté par le serveur est proposé par le serveur Type de services : partage de documents, calcul délocalisé Requête En principe : X clients, Y serveurs, X=Y Résultat PC client/serveur Systèmes Pair à Pair XtremWeb Mode d’interaction inter-ressource : Toutes les ressources sont à la fois client et serveur (elles peuvent demander et/ou offrir des services) Mode d’organisation du système : Système sans serveur centralisé. Système auto-organisé (découverte de ressources, routage,

Pas de consensus autour d’une définition. Pair à Pair (entre pair) Pas de consensus autour d’une définition. Un système dans lequel toutes les ressources peuvent agir comme des clients, des serveurs et/ou maintiennent le système lui même Applications massivement distribuées Napster, Gnutella, Freenet, FastTrack, etc. Nombre d’utilisateurs potentiel ~x Millions, espace de stockage de l’ordre du TeraOctet (beaucoup de redondance) Projets de recherche (plate-formes) Globe (Tann.), Cx (Javalin), OceanStore (USA), XtremWeb (LRI), AppLeS (UCSD), Projets actuels (définition de protocoles) Cosm, Wos, peer2peer.org, JXTA (sun), PtPTL (intel), Conférence : O’Reilly, Livre Peer to Peer, «Harnessing the Power of Disruptive Technologies » Andy Oram, O’Reilly, Intel ?

Projet XtremWeb : Une plate-forme d’expérimentation du calcul global pair à pair Permanents : Cécile Germain, Vincent Néri Doctorants : Gilles Fedak, Oleg Lodygensky (co-encadrés) Sujet de recherche : Un environnement de recherche offrant une image système unique à partir de l’agrégation de ressources faiblement couplées un PC accepte Mon PC PC communications potentielles pour les applications parallèles PC requête PC fournit PC PC System CGP2P accepte résultat PC PC PC PC Un autre PC fournit Collaborations : LAL, INP (IN2P3), IEF, EADS, Université de Tsukuba, IMAG, IRISA, Université de Toronto

Centralisé ou distribuée ? Architecture Choix de conception 1 Infrastructure Centralisé ou distribuée ? Implémentation actuelle  infrastructure centralisée Global Computing et Pair à Pair (modèles d’interaction) 3 entités : client/serveur/worker (volontaire) Serveur XW hiérarchique Cluster de PC Serveur Pair à Pair PC Serveur Calcul global (client) Architecture centralisée/hiérachisée. centralisée signifie que que tout le contrôle se fait sur les serveurs. Par exemple les workers ne peuvent directement lancer un calcul sur un autre worker. Hiérarchisée signifie que le contrôle est distribué sur un ensemble de serveur organisé de manière hiérarchique. Nous distinguons trois entités CSW. client soumet des requetes de calcul, le serveur les assigne à des worker, et les worker les exécutent. CG on a un serveur qui se comporte comme un client et qui contient une très grosse somme de calcul et qui les soumet aux worker. en mode pair à pair, des clients soumettent à un serveur des calculs qui les répartie sur l ’ensemble des workers. PC Client/worker Internet ou LAN PC Worker PC Worker PC Client/Worker

Architecture Choix de conception 2 Protocole de Communication La plupart des systèmes sont protégés par des coupes-feu (firewall). Les requêtes doivent provenir des Workers et NON du serveur de tâches. Bien sur le serveur de tâches doit autoriser les requêtes des Workers et des Clients à traverser son coupe feu. Ressource maîtrisée par XW hostRegister Serveur Calcul Global Worker WorkRequest workResult XML RPC et SSL authentification et cryptage workAlive Un worker s’enregistre auprès du serveur par hostRegister. Losqu’il est disponible, le worker émet getWork (+ les applis localement dispo.). Le serveur envoie les paramêtres de tâches (ou un code+ des paramêtres). Lors du calcul, le worker émet workAlive Le serveur gère un dépassement de délai (timeout) sur le signal workAlive A la fin du calcul, le worker envoie ses résultats par workResult

Architecture Choix de conception 3 Exécution de code natif ou de byte code? 62,6 SUN 1.2 SUN 1.3 SUN 1.4 IBM 1.3 Natif Bytecode vs Natif 1) Performance 1311,84 1000 322,78 291,82 Conditions du test : Pentium 4 1,7 Ghz 256Mo. Linux 2.4.2 SciMark2.0: 5 noyaux numériques. 187,98 100 82,46 56,17 151,8 18,48 20,78 17,04 16,69 15,09 12,77 12,92 3 Générations de JVM: Sun Jdk 1.2.1 =>compilation à la volée Sun Jdk 1.3.1 => hotspot Sun Jdk 1.4 IBM Jdk 1.3 => -JIT Sélectif 10 6,36 Temps (sec) 6,55 5,98 5,55 5,87 4,63 5,51 5,5 4,74 3,69 3,64 3,32 3,76 3,85 3,41 bbbbbb 5,55 4,55 3,86 1,87 1,44 2,87 2,8 1 0,78 1,35 0,62 0,1 CG EP FFT SOR MC MatMul LU Linpack Avec le byte code, les performances dépendent fortement de la machine virtuelle disponible sur le Worker Meilleures performances du code natif (écart peu significatif pour qq benchs) 2) Compatibilité avec les codes existants Beaucoup de codes (et surtout en numérique) existent en Fortran et C Beaucoup d’applications propriétaires ne sont disponibles qu’en exécutable

Architecture du serveur Ensemble de bases de données Sélecteur de tâches Gestionnaire de priorités Tâches Applications Tâches Résultats Statistiques résultats Ordonnanceur Collecteur Niveau Communication XML-RPC TCP SSL Serveur Http Requêtes entrantes Worker Requêtes entrantes Client

Observatoire Pierre Auger Projet AUGER: Comprendre les rayons cosmiques à très haute énergie (1020 ev) Deux champs de détecteurs en Amérique (nord et sud) mesure au sol Simulations de collisions en en cascade de particules de l’atmosphère (air shower). Comparaison des détections au sol avec avec les résultats de simulation  estimation avec probabilité des caractéristiques de la particule initiale Prototype réalisé au LRI Installé au LAL en test Production au LAL envisagée début 2002 1600 détecteurs comme celui-ci

Observatoire Pierre Auger Aires: Simulation de douches atmosphériques Approche Monte Carlo, Séquentielle, Multi-paramètres 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

Observatoire Pierre Auger Capture d’écran du prototype fait au LRI : Hôtes :

Observatoire Pierre Auger Capture d’écran du prototype : Page résultats client

Observatoire Pierre Auger Capture d’écran du prototype : Statistiques pour l’administration : Activité des ressources Performance générale du système Nombre d’heures de calcul par jour (combien de ressources participent) Nombre de tâches terminées/stoppées (état des ressources, efficacité de l’ordonnancement)

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

Problèmes et questions scientifiques Sécurité des ressources Certification de résultats Communication inter ressources Sauvegarde/redémarrage - Migration Distribution des tâches/Ordonnancement Evaluation de performances Prédiction de Disponibilité/Performance Modèles d’exécution Interopérabilité avec les systèmes de Grid Ressources mobiles Modèles économiques

Projets autour d’XtremWeb CGP2P (Calcul Global Pair à Pair) financement ACI GRID Plus de 20 chercheurs (XW comme plate-forme expérimentale de base) XW + stockage + ordonnancement + exécutions parallèles, ASP, PSE à grande échelle, financement RNTL XW + Composants numériques Corba (dans un contexte industriel : EADS) AIRCAST financement BQR XW + Pocket PC + Réseau sans fil (réseau adaptatif, algorithme de diffusion). AUGER (application) financements Actions Spécifiques, BQR, Quadriennal projet IRIS : serveur distribué XtremWeb IFP (Institut Français du Pétrole) évaluation d’XtremWeb XtremWeb Toronto : Simulation de microprocesseurs (Simple Scalar) XtremWeb Genève : Calcul Parallèle avec XW en utilisant Soap XtremWeb CCP (Japon) : Agrégation Ninf/Omni RPC et XW XtremWeb AIST (Japon) : Migration d’images système C@sper

Résumé XtremWeb est une plate-forme d’expérimentation du calcul global et pair à pair. Le premier prototype est opérationnel (après deux ans d’efforts) Les systèmes de CG et P2P posent de nombreux problèmes scientifiques Des collaborations ont été lancées pour aborder certains de ces problèmes

Perspectives Sécurité des ressources (priorité XW) (CGP2P) Certification de résultats (priorité XW) (Auger, CGP2P) Communication inter ressources (priorité XW) (CGP2P) Sauvegarde/redémarrage - Migration Distribution des tâches/Ordonnancement (CGP2P) Evaluation de performances Prédiction de Disponibilité/Performance Modèles d’exécution (CGP2P) Interopérabilité avec les systèmes de Grid (Auger, CGP2P) Ressources mobiles (Aircast) Etude des mécanismes essentiels pour l’exploitation efficace et en sécurité des ressources des grands systèmes distribués

Sommaire Introduction aux Modèles d’exécution QUID: programmation efficace architectures parallèles complexes a partir des environnements standards MPI et OpenMP OVM: un modèle d’exécution pour les applications régulières et irrégulières XtremWeb : une plate-forme d’expérimentation des systèmes distribués à grande échelle Conclusion

Conclusion Les trois projets QUID, OVM et XtremWeb abordent le problème des modèles d’exécution pour les Architectures Parallèles Complexes (APC) et les Grands Systèmes Distribués (GSD) Les trois projets ont obtenus des résultats significatifs : scientifiques, prototypes, publications, collaborations, thèse Globalement les mécanismes étudiés concernent : L’hybridation de modèle mémoire L’équilibrage de charge dynamique L’exploitation du parallélisme à travers un moteur macro-dataflow La tolérance à la volatilité/indisponibilité des ressources La sécurisation des ressources et des applications Ces mécanismes peuvent/doivent ils être combinés pour former un modèle d’exécution commun aux APC et aux GSD ?

Calcul sur technologie embarquée : Ressources légères mobiles dans XW PC collecteur de résultats Pocket PC : Caractéristiques actuelles : -processeur ARM à 206 Mhz -64 Mo de mémoire -microdisque IBM Toshiba 1Go – 5Go -port extension SD (512 Mo) -carte réseau sans fil Prochaines générations : -processeur Xscale jusqu’à 1 Ghz -accélérateur graphique 3D (flottant) Internet ou LAN                              Pourquoi s’intéresser aux ressources légères : Les systèmes embarqués sont de plus en plus puissants (microprocesseur, systèmes d’exploitation complexes), économiques et très largement diffusés (apparition de standards : processeur Xscale, Windows Pocket-PC, Linux) Questions scientifiques : Très grand nombre de ressources Extrême volatilité Consommation  Optimisation de performance

Ressources légères mobiles dans XW : l’expérience en cours Synthèse d’images par lancer de rayons avec PovRay : PC serveur de tâches & collecteur de résultats LAN LRI Paramètres scène  Scène calculée Paramètres scène  Scène calculée Le prototype est fonctionnel (construit à partir d’XtremWeb) Une plate-forme complète (prototype) d’expérimentation du calcul global et Pair à Pair (mode d’interaction) sur ressources légères mobiles : diffusion d’informations, collecte d’informations, calcul distribué, échange de documents, etc.

Questions / discussion

Comment un client soumet une tâche jobs? Soumission de tâches Comment un client soumet une tâche jobs? Soumission de tâches client : pas de système de fichiers partagé !  envoi d’un message au serveur ident appli. + params (ou code application + params) ident appli. + clonage de l’environnement immédiat de l’application (ligne de commande, répertoire, entrée standard). PC Client PC Worker Clonage SSL Internet Diffs SSL Répertoire de travail Nouveau fichiers

Deux exemples de protocoles P2P Gnutella, peer GET file Search query Peer ID peer Super peer GET file Search query Peer ID Pas de serveur centralisé Protocole de découverte par inondation Clip2, BearShare, élection de Super peer Fasttrack Serveur centralisé peer peer peer peer peer Enregistrement, Login Distribution des adresses de supernodes Catalogue, (local search hub) élection possible des Supernodes

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

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

Nouveaux Résultats : Performance comparée de JVM et de codes natifs sandboxés 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 Getpit ~ coût s’un syscall Surcoût de l'interposition getPid read write open/close 1000 489 251 249 214 126 146 100 51 51 52 36 Temps en micosecondes 10 7 7,2 1,7 1,9 1,76 1,9 1,3 1,2 1,3 1,2 1 1 1 Natif LSM Subterfugue UML Java sans secu Java+ SecurityManager Java plus performant pour les read/write Coût d’interposition LSM nul (mais actuellement sans vérification)

Certification de résultats PC client normal PC corrupteur Résultats PC collecteur de résultat Internet ou Intranet Ex : Problème du calcul De la FFT de SETI@home Cas de corruptions : -Volontaire sur PC client -Involontaire sur PC client Comment détecter les corruptions : -le collecteur de résultats ne peut pas se fonder sur l’authentification et le cryptage des communications -Il doit pouvoir détecter les erreurs en utilisant seulement l’analyse du résultat une fois reçu

Certification de résultats Approches pour la détection de corruption (aussi appelées: tolérance au sabotage) Utilisateur (ou application) Système -Analyse statistique (application Monté-Carlo ), -Résultats vérifiables avec une complexité << calcul (ex: solution d’un systèmes d’équations) -Exécution redondante + vote à la majorité -Vérification ponctuelle (choix aléatoire d’un serveur et exécution d’une tâche au résultat connu et vérifiable) -Combinaison du vote à la majorité et de la vérification ponctuelle : Approche fondé sur la crédibilité: Crédibilité du Worker (augmente avec le nombre de VP positives), Crédibilité du résultat (augmente avec le nombre de résultats concordants)

Modèles d’exécution / communications inter-worker Client serveur (Napster, Gnutella, etc.) Multi-paramètres (Distributed.net, SETI, Entropia) Maître-esclaves (Mars) Parallèle peu communiquant (Apples  NAS EP) Parallèle communiquant (Javelin-Linda) PC client Get PC client PC client Internet ou Intranet Internet ou Intranet Get Get Put Put PC Tuple space PC Tuple space PC client PC client Exécuter une application parallèle communicante sur des ressources volatiles  Linda + Tuple space tolérant aux pannes

Interopérabilité avec les systèmes de GRID (Globus) Les systèmes de Calcul Global et Pair à Pair comme ressources d’un système de GRID Interopérabilité avec : les systèmes de sécurité (GSI), d’enregistrement de ressources (MDS/LDAP-GRIS), placement ordonnancement de tâches (RSL/GRAM/DUROC), communication (MPI-G2, Globus I/O) stockage (GASS, GSIFTP) Détection de pannes (Heartbeat Monitor) Paramètres de performances pour les systèmes de placement/ordonnancement (valeurs moyennes ?) Les systèmes de GRID comme ressources d’un système Calcul Global et Pair à Pair Interopérabilité des logiciels d’infrastructure des systèmes de GRID, de Calcul Global et Pair à Pair (peut-on, doit-on réécrire XW sur Globus ?) GSI (Grid Security Infrastructure), MDS (Metacomputing Directory Service), LDAP (Lightweight Directory Access Protocol), GRIS (Grid Resource Information Service), RSL (Resource Specification Langage), GRAM (Grid Resource Allocation Manager), DUROC (co-allocation service), GASS (Globus Access to Secondary storage), GSIFTP (Secure FTP),

Sauvegarde/reprise et Migration PC collecteur de résultat Internet ou Intranet Ex : Les tâches à exécuter Durent > 10 heures Forte probabilité de Disparition de la ressource PC Client PC Serveur Sauvegarder le contexte de l’exécution pour la redémarrer plus tard Où stocker le contexte de l’exécution ? (sur le PC client, sur un serveur de contextes, sur un autre client) Où redémarrer l’exécution ? (le client : checkpoint, un autre client : migration) Qu’est ce que le contexte d’une exécution ? (le contexte du processus, des résultats intermédiaires, autre chose ?) Quelle est la taille raisonnable du contexte ? (Faibles performances d’Internet) Migration de la tâche : réallocation (prédiction de disponibilité)

Placement/Ordonnancement Internet ou Intranet La couleur et la largeur de trait indiquent la performance (un critère ou une fonction d’un ensemble de critères) PC Serveur ? PC Client PC Client Problèmes : exécuter un sac de tâches de durées variables Quels objectifs -temps de réponse, QOS (assurer un temps de réponse en présence de volatilité) Quelles actions -placement/ordonnancement sur les clients -choix de la machine serveur (H. Casanova) 3) Quels paramètres -vitesse du processeur, taille mémoire, vitesse du disque, capacité disque -performance du réseau (débit, latence, stabilité) -statistique de disponibilité,

Evaluation des performances PCs Serveur Evaluation de performance Client Serveurs -en cluster -géographiquement distribués Internet ou Intranet PC Client PC Client Problèmes général de la mesure de performance Identification des critères de performance (temps de rep., débit, QOS) Identification des facteurs de la performance (CPU, Réseau, Utilisateur?) Etablissement de méthodes de mesure (synchronisme) Etablissement de benchmarks (portables, discriminant) Interprétation des résultats de mesure (approche statistique?)