Introduction au Grid computing. Introduction au Grid computing. Grid-Computing. 1-Introduction Motivations Différents objectifs Leçons du passé

Transcription

1 Introduction au Grid computing Introduction au Grid computing Stéphane Vialle 1. Introduction 2. Exemple d utilisation d une Grille Une expérience de Grille mondiale pour le CERN 5. Bilan des Grilles 6. Autres exemples de Grilles 7. Acteurs industriels 1 2 Analogie avec distrib. d électricité Ian Foster (Globus 1er middleware de grille) 1-Introduction Motivations Différents objectifs Leçons du passé 3 Infrastructure pour délivrer des capacités de calcul/stockage/ communication de façon transparente à l utilisateur, quand et où il les demande. Plus pragmatique : construire des communautés dynamiques (Virtual Organizations) et fournir à leurs membres l accès aux ressources partagées. 4 Réalité invisible à l utilisateur L utilisateur ne perçoit pas l architecture sous-jacente de la grille (son middleware la masque). Où sont stockées mes données? Ne pas s en soucier!! Où sont lancés mes calculs? GRID 1-Introduction Motivations Différents objectifs Leçons du passé L utilisateur se contente de soumettre des requêtes à la grille! 5 6 1

2 Grille de Super-Ordinateurs Grilles de ressources inutilisées Optimisation de ressources à grande échelle Grids de super-calculateurs Grids de super-clusters de PC Interconnexion par des réseaux rapides Pour supporter des calculs plus importants («size up») Pour exécuter un grand nombres de calculs indépendants : Ex: Seti@Home!! Typiquement des grilles de PC à travers Internet Desktop Grids Grilles hautement dynamiques : les noeuds disparaissent de la grille à tout moment (récupérés par leurs propriétaires) 7 8 Grilles de données Grille collaborative Partage de données à grande échelle : gros volumes et grand nombre de lecteurs distribués Réalité virtuelle Réalité augmentée Ex : les résultats d expérience du CERN! Problématiques : migration/réplications de données? catalogue distribué ou centralisé de réplicas? maintien de la cohérence du catalogue et des réplicas? 9 Usage conjugué de réalité virtuelle et de calcul distribué : Exemple: réseau de caves et de supercalculateurs graphiques Aspects temps-réel dans les transmissions Grosse demande mais très complexe! 10 1-Introduction Motivations Différents objectifs Leçons du passé Analogie avec les grilles de gas/élec. Dans le passé : production, stockage et consommation locales Puis : interconnexion pour ajustement (en cas d imprévu) Aujourd hui: production, stockage et consommation indépendants et réseau d interconnexion à large débit GRID! 11 Plus souple, tolérant aux pannes, 12 2

3 Conditions d émergence d une grille Technologie mature Réseau de ressources Interêt industriel Intérêt du marché Support du gouvernement Grille Observations des grilles passées (gaz, électricité, eau, ): Il faut dépasser les habitudes l évolution technologique ne suffit pas à l émergence! Pour émerger une grille à besoin : d une technologie mature d intérêts (pressions) de l industrie et du marché d une impulsion gouvernementale (politique) 13 Emergence des grilles informatiques Pb technologique plus complexe que les grilles de gaz/elec/eau : - Ressources et besoins plus variées - Quelquefois les nœuds peuvent consommer ou produire - Problème de confidentialité des données et traitements Technologie mature Réseau de ressources Intérêt industriel Intérêt du marché Support du gouvernement Grille Aujourd hui la technologie logicielle n est pas complètement mature! 14 Hypothèses d émergence La technologie de l information évolue très vite : La densité d intégration des circuits intégrés, la puissance des CPUs, la tailles des disques, la vitesse des réseaux évoluent exponentiellement! Evolution plus rapide que celle du gas/électricité/eau En 2002 : Hyp 1: Les grilles informatiques apparaîtront plus vite car leur technologie évolue plus vite Hyp 2: Les grilles informatiques apparaîtront moins? vite car leur technologie est instable! En 2009 : 15 Emergence constatée en 2009 En 2009 : Les «e-science Grids» sont des réalités académiques On a interconnecté et globalisé/virtualisé des super-calculateurs (ou gros clusters). Les applications et les données n ont pas un très haut niveau de confidentialité. Généralement on déploie un calcul sur un seul site. Les «enterprise Grids» sont des réalités industrielles : On a plongé des technologies de «Grid» dans un réseau d entreprise sécurisé. On utilise des ressources fiables. Les «clouds» deviennent une réalité industrielles : Au sein d une entreprise : autre nom des «enterprise Grids» Des gestionnaires de «clouds» ont de nombreux clients qui leur achète des ressources «à la demande». 16 Grid computing: exemple d utilisation Data-Mining distribué 2 Exemple d utilisation d une Grille : data-mining distribué 17 Un utilisateur veut créer une base de données en fouillant des bases de données en ligne, et en utilisant des pgms de fouille optimisés également en ligne. Il va découvrir, accéder et utiliser des ressources distantes (données, espace disque, capacités de calcul). Il va rejoindre le portail d une «organisation virtuelle» (V.O.) et exécuter un pgm de haut-niveau. Utilisateur de la grille Portail de «V.O.» Grille de ressource s 18 3

4 Grid computing: exemple d utilisation Data-Mining distribué 1/6 L utilisateur contacte le portail d une communauté de data-mining. C est une registry (annuaire) qui sait quels sites peuvent fournir des fonctionnalités de fouille et des capacités de stockage. Grid computing: exemple d utilisation Data-Mining distribué 2/6 Le portail ( registry ) retourne des références sur des générateurs ( factories ) de pgms de fouille optimisés, et sur des générateurs de bases de données. L utilisateur ou son programme fait un choix Grid computing: exemple d utilisation Data-Mining distribué 3/6 Le programme de l utilisateur fait des requêtes aux générateurs pour qu ils assemblent des services de fouille, et qu ils créent une base de données. Grid computing: exemple d utilisation Data-Mining distribué 4/6 Deux nouveaux services sont créés : un service de fouille et une base de données (principe du tout est service!) Grid computing: exemple d utilisation Data-Mining distribué 5/6 Le service de fouille interroge des bases de données distantes. Il agit comme un client qui aurait l identité de l utilisateur (délégation d autorité ex: Globus-3/OGSA). Grid computing: exemple d utilisation Data-Mining distribué 6/6 Les résultats des interrogations sont retournés directement à la nouvelle base de données. Le pgm utilisateur envoie des msgs keepalive pour maintenir les services créés et les résultats

5 3 Environments de Grille Globus Unicore - EuroGrid XtremWeb Les NES (NetSolve, Diet, Ninf) ProActive JavaSpaces 25 GLOBUS Un middleware et un projet de grille complet Découverte et gestion de ressources Gestion et transfert de données Authentification et sécurité Gusto Recherche Testbeds Data-Grid National Fusion Collaboratory Globus-I, -II, -III, IV: Low-level toolkit Développement Calcul à haute-perf distribué Calcul à haute-perf depuis un PC Télé-immersion High-level Grid services 26 GLOBUS L architecture de Globus évolue et se complexifie : GLOBUS L architecture de Globus évolue et se complexifie : Meta-Computing Toolkit Hourglass model Application Globus services: Adaptive Wide Area Resource Environment Globus toolkit modules: Comms, Resource (al)location Authentication, Data access, Information service, Grid Architecture Application Collective Resource Connectivity Fabric Open Grid Services Architecture Application 27 Open Grid Services Architecture Application OGSA and Web-services OGSA Architected Services OGSI Open Grid Services Infrastructure Messaging Directory Network Web Services Workflow Systems File Security Database Servers Storage Other Services 28 Globus-I : pour comprendre la grille Modèle du «sablier» Globus-I : pour comprendre la grille Exemple d application adaptative (dynamiquement) : adaptative high level services low level modules Ressources distribuées Adaptabilité : maintenir les fonctionnalités quand la grille évolue Services globaux (collectifs) Ex : authentification sur toute la grille Ensemble (minimal) de fonctionnalités standards sur chaque ressource Fonctionnalités locales à chaque ressource avec une interface standard Ex : authentification sur la ressource locale Hétérogénéité et pannes possibles 29 Internet best effort liaison ATM rapide ($$) Measure-performance-comm. if (Internet-not-loaded) use-internet else use-and-pay-atm-link Implantation : - Utilisation d un service (haut niveau) disponible - Implantation d un nouveau service (haut niveau) - Implantation directe dans l application Application adaptative High level services Low level modules Ressources distribuées 30 5

6 Globus-I : pour comprendre la grille Exemple de relation entre services de haut et de bas niveau : Chaque site et ressource de la grille possède ses outils d authentification - Un utilisateur s authentifie une seule fois, grâce à un service de haut niveau (ayant une interface standard) - Il est automatiquement authentifié auprès des ressources qu il utilise, grâce à des modules de bas niveau adaptative High level services Low level modules Globus-II : décomposition plus fine Architecture en 4 couches (le sablier s épaissit) : Collective: Coordination des différentes ressources Resources: Accès et partage de chaque ressource (indépendamment) Connectivity: Communications sécurisées (avec authentification) Fabric: Interface avec les module propres aux ressources locales High level services Application Collective Resource Ressources distribuées Low level modules Connectivity Fabric Modèle sablier de Globus-I Globus-II : nouvelle décomposition Architecture en 3 groupes de services thématiques transversaux : Basé sur des mécanismes d annuaires (LDAP) Basé sur une extension de FTP (GridFTP) Globus-II Globus-III Globus-II est opérationnel mais complexe à déployer Chaque «service/module» se programme différemment! Conception d une nouvelle architecture plus riche et plus homogène Basé sur des annuaires, «schedulers», et files d attente Basé sur des échanges de «certificats» 33 Globus-III et l architecture OGSA Incluent des concepts provenant des web-services 34 GLOBUS-III : Architecture OGSA Globus-III : Architecture OGSA Principes de base : Un nouveau découpage en couches intégrant des «web services» Software architecture definition «Tout est service.» Rapprochement des web-services Service orientation Virtualization & Service composition Grid-Service template Un début de sémantique de grille! Les services peuvent se composer facilement. (programmation en WSDL SOAP UDDI & XML) 35 Un autre découpage en couches user user Services de haut niveau utilisant des services GT3 et autres Ex: gestion des données, gestion de la charge Services de bas niveau Ex: transfert des données, monitoring Services locaux avec interface standard WSDL, SOAP, UDDI Distributed resources 36 6

7 Globus-III : Architecture OGSA Grid-Service template : Tout service OGSA doit respecter un gabarit standard Un ensemble minimum d interfaces et de fonctionnalités standards Un ensemble minimum d informations normalisées sur le service (fonctionnalités, nature, ) Permet à tout service d analyser un autre service (de le «découvrir»). Permet à deux services de dialoguer plus facilement. début de sémantique de grille! 37 Globus-III : Architecture OGSA Programmation des services de grille : Langages de prog. des web-services : WSDL, SOAP, UDDI et XML Définition de l interface (unique) du service Programmation (multiple) du corps du service Exemple: recherche de l efficacité optimale Exemple: choix de la qualité de comm. HTTP: Protocole pour des opérations distantes Protocole sans détection d erreur Interface unique Interface unique IPC: Protocole pour des opérations locales Protocole garantissant une communication exacte 38 Globus-III Globus-IV Globus-IV : Architecture initiale Globus-III & OGSA : bonnes idées!! Mais ré-inventent une partie des concepts des web-services Grid-services de haut-niveau OGSA Architected Services Conception d une nouvelle architecture plus associée aux web-services Globus-IV et WSRF Convergence/fusion des web-services et des grid-services Mécanismes spécifiques et web-services Grid-services de bas-niveau implantés en technologie web-services OGSI Open Grid Services Infrastructure Web Services Security Workflow Database File Systems Directory Messaging Servers Storage Network Globus-IV : Web/Grid - services Convergence des Grid et Web services Démarrent avec des applications et technologies éloignées Convergence! Web Services Resource Framework : WSRF Globus-IV : architecture finale De (nouveaux) web-services implanteront tous les Grid-services de bas niveau : OGSA Architected Services OGSI Open Grid Services Infrastructure OGSA Architected Services Les deux «communautés» ont identifié des intérêts communs Futurs Grid et Web services : langages et sémantiques communs 41 Web Services Security Workflow Database File Systems Directory Messaging OGSI Open Grid Services Infrastructure Web Services Servers Storage Network Web Services Security Workflow Database File Systems Directory Messaging WSRF Servers Storage Network 42 7

8 3 Environments de Grille Globus Unicore - EuroGrid XtremWeb Les NES (NetSolve, Diet, Ninf) ProActive JavaSpaces EuroGrid-Unicore ( ) Unicore : un middleware de grille Européen très orienté sécurité EuroGrid : une plate-forme de test Européenne (testbed) Un projet de Grille complet (comme Globus) Biologie moleculaire Prédictions météorologiques Recherche Testbeds Quatre domaines d application et d évaluation : CAO/CFAO (EADS) Développement Calcul intensif EuroGrid-Unicore : le middleware Architecture d Unicore : Architecture classique en 3 parties pour interconnecter des sites de calcul intensif Une forte proportion de couches de sécurité 1 - Interface client : fonction de soumission et de contrôle de tâches 2 - Passerelle : point d entrée d un site de calcul intensif 3 Environments de Grille Globus Unicore - EuroGrid XtremWeb Les NES (NetSolve, Diet, Ninf) ProActive JavaSpaces 3 - Serveur Unicore : scheduling et exécution sur un site de calcul XtremWeb : principes de base Un middleware de grille pour la distribution de calculs indépendants et la récupération de puissances de calcul inutilisées embarrassingly parallel (client) Serveur XtremWeb Cluster de PC (worker) Internet Desktop PC (client ou worker) XtremWeb : principes de base Un serveur de tâches (le «scheduler») Des serveurs de calcul dédiés Des «desktop PC» qui peuvent être à tout moment : utilisés à d autres tâches (mode «user») utilisés pour soumettre des tâches à XtremWeb (mode «client») utilisés pour traiter des tâches XtremWeb (mode «worker») Poste «client» Poste «user» Serveurs de tâches XtremWeb «Worker» : Serveur (de calculs) dédié 47 Poste «worker» Poste «client» 48 8

9 XtremWeb : communications Exige peu des firewalls des sites clients/workers (stateless firewall): Communications initiées par le client Données du serveur envoyées en réponse aux requêtes du client User/Worker Devient inutilisé Attend une tâche Traite une tâche Tâche terminée Rq : hostregister Contacte le dernier serveur XtremWeb contacté ou bien le serveur root Rq : workrequest Envoie ses caractéristiques, et demande une tâche Rq : workalive Signale son activité a son serveur de tâche Rq : workresult Envoie le résultat au serveur désigné et à son serveur de tâche Serveur de tâches Enregistre le nouveau worker Retourne une tâche : - code binaire, - données serveur à qui répondre Re-planifie la tâche si aucun signal d activité reçu 49 3 Environments de Grille Globus Unicore - EuroGrid XtremWeb Les NES (NetSolve, Diet, Ninf) ProActive JavaSpaces 50 Principes des NES Principes des NES //GridRPC grpc_call Programme utilisateur NES : Network Enabled Servers Appel de serveurs et de codes de calculs distants Poste utilisateur Interface de programmation standard : GridRPC Allocateur de ressources et équilibreur de charge («brooker» ou «agent») Middleware spécifique + + (NetSolve, Ninf, Diet) Serveurs de puissance de calcul et de codes de calcul («solvers») Ressources distribuées 51 5 composants conceptuels : Analyse et ordonnancement sur demande du client 1 Client Scheduler 2 3 Data- base Monitor Monitor Monitor 5 Server Server Server Server Server Server Server Server Server 4 Constituants de l agent ou du «brooker» Mesure de performances permanente 52 Principes des NES Fonctionnement type du middleware : 1 Le client soumet une requête à l agent 2 L agent retourne une liste de serveurs adéquats 3 Le client contacte les serveurs indiqués jusqu à ce que l un d eux réponde, puis lui envoie les données et le calcul démarre 4 Le serveur retourne ses résultats au client 3- données Client 1-requête de calcul 2-liste de serveurs 4- résultat Agent info Serveur Serveur Serveur L utilisateur ne voit qu un simple RPC 53 Principes des NES L agent : un élément critique Traite toutes les requêtes client Doit connaître les caractéristiques de tous les composants de la grille (solveurs, serveurs et réseau) Utilise des outils de mesure et de prédiction de performances (temps de calcul, charge des serveurs, trafic réseau) Les performances de la grille dépendent de celles de l agent. L agent est un point d engorgement potentiel du NES!! Agent Etat Charge Caractéristiques 54 9

10 NetSolve : une implantation de NES Application: C, Fortran, Matlab Mathematica University of Tennessee Netsolve Proxy Bus Corba Netsolve Agent Netsolve Servers & Solvers: C, Fortran + Netsolve Problem Description File Un bus Corba pour gerer les (objets) solveurs et les communications Des «proxy» pour éviter les engorgements sur l agent Des fichiers de description des interfaces et de la complexité des solveurs, pour prédire les temps de calculs 55 NetSolve : une implantation de NES Fonctionnement du middleware : Un processus séparé appelé «proxy» réside sur chaque poste client Il s informe de l état de la grille auprès de l Agent quand celui-ci est disponible Il traite les requête de son client à la place de l Agent («cache») diminue les engorgements Un PC NetSolve Client données & résultats NetSolve Serveur requête liste info NetSolve Proxy NetSolve Agent rq 56 DIET : une implantation de NES Distributed Interactive Engineering Toolbox Un bus Corba pour gerer les (objets) solveurs et les communications Une hiérarchie d agents pour éviter les engorgements Des outils de mesure et de prévision des performances Architecture conçue pour la gestion de grandes grilles (pour le «passage à l échelle») Master Agents: scheduling Local Agents & Server Daemons: monitoring Serveurs de calcul MA LA SeD MA Client LA MA LA MA SeD SeD SeD MA LDAP LDAP LDAP B u s C o r b a 57 Persistance des données dans les NES Pb : On réutilise des données dans des séquences d opérations Ne router qu une fois ces données du client vers le serveur Conserver les résultats intermédiaires sur le serveur de calcul client client AB A,B R 1 A,R 1 R serveur serveur Sans persistance R = ((A B) A) R 1 = AB R = R 1 A client client AB A,B R serveur serveur Avec persistance NetSolve : regroupement des opérations en «séquences» DIET : définition de données «persistante» ou «volatile» 58 3 Environments de Grille Globus Unicore - EuroGrid XtremWeb Les NES (NetSolve, Diet, Ninf) ProActive JavaSpaces ProActive Un environnement de programmation des systèmes distribués pour l exploitation de clusters, de Grilles ou de systèmes P2P. Basé sur des JavaRMI, mais plus simple que les JavaRMI : Les «stubs» des objets distants sont masqués à l utilisateur Objets locaux ou distants : identiques Composition : Un ensemble de classes Java Des fichiers XML de définition du système distribué : Clients/serveurs et Parallélisme sur cluster, Grille ou système P2P

11 ProActive Concept d Objets Actifs Simples à créer Permettent du parallélisme sur des clusters ou à travers Internet 3 Environments de Grille Appels d objets actifs : toujours asynchrones Pas de partage des objets passifs (entre objets actifs) Objets passifs passés par valeur (par recopie) aux objets actifs Concept de variables futures synchronisation «par nécessité» Tous les appels d O. actifs 61 Globus Unicore - EuroGrid XtremWeb Les NES (NetSolve, Diet, Ninf) ProActive JavaSpaces 62 JavaSpaces/Jini Le modèle JavaSpaces Une mémoire partagée virtuelle entre processus distribués Les processus n interagissent pas directement Les processus interagissent par le biais d un ou plusieurs JavaSpaces JavaSpaces/Jini Composants d un JavaSpaces Services Jini supportant un JavaSpace : Tolérance aux pannes D après des documents de Robert Gérin-Lajoie, CIRANO63 Peuvent être lancé en mode : Tolérance «persistant» : objets stockés dans le JavaSpace et sur disque aux «activable» : services redémarrés automatiquement en cas pannes de panne du service. 64 JavaSpaces/Jini Qu est-ce qu un JavaSpaces Un très petit nombre d opérations sont définies sur un Space Lire Prendre Écrire ReadIfExists() // Lire sans bloquer TakeIfExists() // Prendre sans bloquer + un mécanisme de notification d évènements à travers le réseau JavaSpaces/Jini Qu est-ce qu un JavaSpaces Les objets déposés (les «Entry») sont des objets typés qui peuvent contenir du code exécutable. La lecture et récupération d objets se fait par appariement (patternmatching) avec des patrons d objets : Les champs non assignés sont des «jokers» Basé sur les «tuple-spaces» (voir David Gelernter s avec le système Linda ) Les opérations sont transactionnelles si souhaité (contribue à la résistance aux pannes) Les clients peuvent s enregistrer sur les opérations d écriture avec la méthode «notify»

12 JavaSpaces/Jini Bilan des JavaSpaces Points forts : Simple d utilisation (peu de primitives) Plusieurs implantation Open-Source et Industrielles existent Traitent beaucoup de problèmes (outil générique) Possèdent un mode transactionnel (op réversibles jusqu au commit) : aide à la tolérance aux pannes. 4 Une expérience de Grille mondiale pour le CERN Les implantations à stockage réparti ont de grandes capacités d extension (passage à l échelle). Ex : Un point clé de leur réalisation est l indexeur des données Expérience de Grille mondiale pour le CERN DATA-Grid pour le LEP Next generation of scientific exploration, with intensivecomputing and analysis of shared large scale datasets, across widely distributed scientific communities Projet Européen (FP ) : 15 pays 21 institutions 200 personnes 100 TBytes 1 PBytes Physique, Biologie, Environnement Basé sur Globus-II 69 Expérience de Grille mondiale pour le CERN DATA-Grid pour le LEP Extension de l architecture de Globus-II : Besoin d un transfert automatique de fichiers Modèle en sablier de Globus-II Ajout de 16 nouveaux services Utilisation de OpenLDAP PC local Input files Output files Ressource distante Application layer VO common application layer High level Grid middleware (high level Grid services) Basic services (Globus-II toolkit) OS & Net services 70 Expérience de Grille mondiale pour le CERN DATA-Grid pour le LEP Exemple de nouveau service de gestion de données : Les gros fichiers accédés depuis de nombreux points de la grille sont «répliqués» par morceaux, pour éviter un engorgement et utiliser au mieux la bande passante du réseau. Le «replica manager» et le «replica catalogue service» gèrent la création des réplicas et leur accès automatique. Expérience de Grille mondiale pour le CERN DATA-Grid pour le LEP Exemple de constitution et de publication d un annuaire global : Chaque ressource lance un service Globus GRIS (local monitoring) et publie les résultats dans un annuaire local (LDAP). Certaines ressources lancent des services «Globus GIIS» qui collectent les résultats et les re-publient dans de nouveaux annuaires. Une hiérarchie de «GIIS» est créée et un annuaire global lest publié. logical file name replica manager replica catalogue service physical file name physical file name replicas physical file name 71 local LDAP local info GRIS Resource GIIS new LDAP local LDAP local info GRIS Resource Global LDAP GIIS GIIS GIIS GIIS GIIS GIIS 72 12

13 Expérience de Grille mondiale pour le CERN Data & Computing Grid pour le LHC Expérience de Grille mondiale pour le CERN Data & Computing Grid pour le LHC 15 PetaOctets/an Enormément de calculs Une grille de calcul & Du calcul volontaire (réaliste?) LCG : LHC Computing Grid 73 LCG : the LHC Computing Grid Une grille de grilles avec plusieurs environnements interconnectés Des Virtual Organizations selon les thématiques de travail 74 Expérience de Grille mondiale pour le CERN Data & Computing Grid pour le LHC LCG : the LHC Computing Grid Un système hiérarchique de nœuds T-tiers pour produire, stocker, cacher et calculer, inspiré de l expérience DATA-GRID LEP 5 Bilan des Grilles Nœuds T-0 : CERN production de données Nœuds T-1 : Sites de stockage dans le monde Nœuds T2 : nœuds de stockage partiel dans le monde (cache de BdD) Nœuds T3 : nœuds de calcul (ex : clusters) MPI-G Globus Bilan des Grilles Bilan de l architecture logicielle Env. de dev. Middleware générique de Grille Application distribuée Environnement de développement Middleware de Grille Routage, contrôle, supervision réseau Infrastructure réseau rsrc rsrc rsrc rsrc ProActive Env. de dev. GridRPC ProActive middl. Middleware spécifique DIET middl. JavaRMI + JVM Middleware générique Corba + VPN Deux stratégies : ambitieux middleware générique de Grille (ex : Globus) middleware générique traditionnel + complément spécifique 77 Bilan des Grilles Bilan de l architecture logicielle Application distribuée Environnement de développement Middleware de Grille Routage, contrôle, supervision réseau Infrastructure réseau rsrc rsrc rsrc rsrc ProActive XtremWeb MPI GridRPC Différents objectifs : des langages de programmation de bas niveau - pour les clients/serveurs : GridRPC - pour le parallélisme : MPI des langages de plus haut niveau - générique : ProActive - pour l exploration multi-paramètres : XtremWeb 78 13

14 Projets génériques internationaux EGEE 6 Autres exemples de Grilles 70 participants p 27 pays (en augmentation) The Enabling Grids for E-sciencE (EGEE) project is funded by the European Commission and aims to build on recent advances in grid technology and develop a service grid infrastructure which is available to scientists 24 hours-a-day 79 «Une Grille de production pour la recherche scientifique (e-science Grid)» Basé sur un middleware de grille conçu pour la grille EGEE (Open-Source) 80 Projets génériques internationaux EGEE Projets génériques internationaux EGEE Utilisateurs en 2008 : Bilan en 2008 : 259 sites connectés, provenant de 52 pays CPUs utilisables 24/7 : Espace disque : 20 PetaOctets VO : 150 à 200 Users : 7500 à Nombre de jobs : /jour LHC? Projet «Egee actuel» : Durée : 2 ans Budget : 47MEuros (dont Commission Européenne : 32MEuros) + 50MEuros de matériel apporté par les membres. Une grille de production scientifique bien utilisée! Projets génériques internationaux DEISA Projets génériques internationaux DEISA Global Parallel File System (technologie IBM) : The fundamental integration concept in this area is transparent access to remote data files via a global distributed file system. Processes can be executed on any node (they can access their data). «Une grille de production ou un ensemble (?) de supercalculateurs, pour la recherche scientifique» S appuie sur des technologies propriétaires

15 Projet Français actuel Grid clusters sur 9 sites Réseau privé RENATER : 2,5 Gbit/s à 10 Gbit/s Processeurs AMD Opteron de 2 Ghz à 2,4 Ghz Environ 5000 coeurs en Acteurs industriels Point fort : déploiement d OS à la demande! Grid 5000 est une grille d expérimentation Produits industriels Acteurs industriels Développeurs de produits: IBM Oracle Sun Microsystems Amazon Data Synapse Platform Computing Vendeurs de ressources: Amazon Salesforce.com Google Utilisateurs de «clouds» ou «d enterprise Grid»: BNP-Paribas Société Générale PSA Introduction au Grid computing FIN