Grid-Computing et gestion massive de données Yves Denneulin Laboratoire ID, Grenoble Jean-François Méhaut Laboratoire GRIMAAG, Pointe-à-Pitre et Schoelcher.

Présentation au sujet: "Grid-Computing et gestion massive de données Yves Denneulin Laboratoire ID, Grenoble Jean-François Méhaut Laboratoire GRIMAAG, Pointe-à-Pitre et Schoelcher."— Transcription de la présentation:

1 Grid-Computing et gestion massive de données Yves Denneulin Laboratoire ID, Grenoble Jean-François Méhaut Laboratoire GRIMAAG, Pointe-à-Pitre et Schoelcher Les travaux du projet DataGrid

2 The Beginning of DataGRID The DataGRID project evolved from the conjunction of uthe search for a practical solution to building the computing system for CERN’s next accelerator – the Large Hadron Collider (LHC) uand the appearance of Ian Foster and Carl Kesselman’s book – The GRID – Blueprint for a New Computing Infrastructure

3 Enabling Worldwide Scientific Collaboration

4 Considérations techniques… u Applications à gros volumes de données u Enormes besoins de calcul u Utilisateurs répartis sur les différents continents

5 The Large Hadron Collider Project 4 detectors CMS ATLAS LHCb Capacité de stockage – Raw recording rate 0.1 – 1 GBytes/sec Accumulating at 5-8 PetaBytes/year 10 PetaBytes of disk Puissance de calcul – 200,000 of today’s fastest PCs CERN

6 Utilisateurs du CERN Europe: 267 institutes, 4603 users Elsewhere: 208 institutes, 1632 users

7 Observation de la terre u Satellite data u ENVISAT for Ozone Monitoring u Etc.

8 Biology Applications u Grid-aware bio-informatic platform u Large Scale Comparative Sequence Analysis u Medical imaging u Etc.

9 DataGrid: objectifs uPartager de grandes quantités de données en utilisant les réseaux actuellement disponibles  Construire une architecture logicielle utilisable  Tester sur des applications réelles Ù Physique des hautes énergies Ù Biol-sciences Ù Observation et étude de la terre

10 The Data Grid Project - Summary uEuropean dimension  EC funding 3 years, ~10M Euro  Closely coupled to several national initiatives uMulti-science uTechnology leverage –  Globus, Condor, HEP farming  Rapid deployment of working prototypes - production quality  Collaboration with other European and US projects uStatus –  Started 1 January 2001 uOpen –  Open-source and communication  Global GRID Forum  Industry and Research Forum

11 DataGRID Partners (1) Managing partners UK PPARCItaly INFN France CNRSHolland NIKHEF Italy ESA/ESRIN CERN proj.mgt. - Fabrizio Gagliardi Industry IBM (UK), Communications & Systems (F), Datamat (I)

12 DataGRID Partners (2) Associate partners Finland- Helsinki Institute of Physics & CSC, Swedish Natural Science Research Council (Parallelldatorcentrum–KTH, Karolinska Institute), Istituto Trentino di Cultura, Zuse Institut Berlin, University of Heidelberg, CEA/DAPNIA (F), IFAE Barcelona, CNR (I), CESNET (CZ), KNMI (NL), SARA (NL), SZTAKI (HU)

13 Projet Datagrid : les Work Packages

14 DataGrid Work Packages WP8-10 Applications Grid Services GRAM Grid Fabric CondorPBSInternetLinux Application Toolkits MPICH-G2Condor-G GridFTPMDS SUN WP1& 8-10 sw WP2,3,5,(7) WP4,7

15 Architecture Globus Applications Core Services Metacomputing Directory Service GRAM Globus Security Interface Heartbeat Monitor Nexus Gloperf Local Services LSF CondorMPI NQEEasy TCP SolarisIrixAIX UDP High-level Services and Tools DUROCglobusrunMPINimrod/GMPI-IOCC++ GlobusViewTestbed Status GASS

16 Construction du testbed DataGrid u Basé sur Globus u Utilise et étend les services Globus standards u Processus d’intégration, validation et déploiement u Architectures en couches à 2 niveaux  Niveau Fabric : composants pour le middleware seulement, non accessibles par les applications  Niveau « Grid » : composants du middleware Grid Services GRAM Grid Fabric CondorPBSInternetLinux GridFTPMDS SUN

17 Installation du testbed u Installation automatisée et gestion des nœuds  Serveur de configuration et d’installation (local à chaque site)  Séquence d’installation Ù Boot + DHCP Ù Montage (par NFS) d’un filesystem root distant Ù Installation à partir de ce FS

18 Testbed Sites Dubna Moscow RAL Lund Lisboa Santander Madrid Valencia Barcelona Paris Berlin Lyon Grenoble Marseille Brno Prague Torino Milano BO-CNAF PD-LNL Pisa Roma Catania ESRIN CERN HEP sites ESA sites IPSL Estec KNMI (>40) Francois.Etienne@in2p3.frFrancois.Etienne@in2p3.fr - Antonia.Ghiselli@cnaf.infn.itAntonia.Ghiselli@cnaf.infn.it

19 Groupe middleware u 5 work packages  Gestion de la charge de travail  Gestion des données  Monitoring de la grille  Stockage massif des données  Gestion de la structure

20 Gestion de la charge de travail u Contexte de la grille  Charge de travail non prévisible  Chaotique Ù Un grand nombre d’utilisateurs indépendants u Thème d’étude  Ordonnancement distribué  Allocation de ressources u Eléments de solution  Disponibilité des données, charge CPU, réseaux  Co-allocation

21 Solutions mises en oeuvre u Allocation des ressources (CERN)  Gestionnaires de batchs  Scripts de jobs  Système d’informations u Gestion de configuration (CERN)  Stocke toutes les informations de configuration (au sens « système» du terme)  Tout est exprimé en XML  Configuration automatique des machines

22 Ordonnanceur de grilles uResponsable des choix de placement et d’exploitation des ressources (INFN, Italie) uDeux éléments clés :  Resource broker : choisit un élément (nœud de stockage, de calcul, réseau pour communiquer, etc.) répondant à une requête  Job submission service : exécute (soumission, annulation, surveillance) les décisions prises par le resource broker

23 Ordonnanceur de grilles (2) uCommunication par le biais de :  Job Description Language (JDL) décrit les jobs ÙMême langage pour la description des besoins (clients) et des ressources (serveur) ÙLangage ClassAds (issue du projet Condor)  Services d’enregistrement (logging) et bookkeeping (persistance) des jobs et de leur status uResource Broker  Développement interne à DataGrid  Fonctionne en distribué ÙUn resource broker par site ÙCoopération entre les brokers

24 Gestion des données u Granularité  Unité de partage: fichiers  Bientôt : collection de fichiers u Dispositif de réplication  Améliorer l’efficacité des accès  Transparent pour les utilisateurs u Types de fichiers  Physiques  Logiques (un ou plusieurs fichiers physiques,…) u Métadonnées  Statistiques d’accès, monitoring,…

25 Réplication des fichiers u Deux types de fichiers  Fichier maître (original) créé par le propriétaire  Fichier réplicat (copies) créés par le middleware u Gestionnaire de réplicats et catalogue de réplicats u Service de consistence des réplicats  Répercuter les mises-à-jour sur les réplicats u Mécanisme de synchronisation  Destruction du maître et des réplicats

26 Système de Gestion des Replicats u Décide de la politique de replication des ensembles de fichiers u Utilise :  Catalogue des replicats  Transfert de fichiers des GSE pour performances u Inclut un module d’optimisation pour minimiser les mouvements de données  Estimation des coûts de duplication, bande passante u Prévue pour la prochaine version, l’outil actuellement utilisée pour cela est manuel : GDMP

27 Catalogue des réplicats (UK) u Fonctionnement  Fait la correspondance entre un nom logique et un (ou un ensemble) de fichiers physiques  Gère également des métadonnées (taille, heure de modification, propriétaire, …)  S’appuie sur un annuaire LDAP u SQL  Composant d’interface avec des SGDR

28 Système de gestion du stockage u Gestion du stockage (CERN, RAL/UK)  Interface entre les services grid et les systèmes de stockage sous-jacent  Utilisation des outils globus Ù GSI pour authentification Ù Globus-url-copy Ù GridFTP u Monitoring  En cours de développement

29 GridFTP uUniversal high-performance file transfer uExtends the FTP protocol with:  Single sign-on ( GSI, GSSAPI, RFC2228 )  Parallel streams for speed-up  Striped access (ftp from multiple sites to be faster)  Clients: gsincftp, globus-url-copy.

30 Service de stockage (CERN) u Fonctionnement  Gère les GSE (Grid Storage Element) : tout composant permettant de stocker des données  Produit : GDMP (Grid Data Mirroring Package) Ù Développement spécifique à Datagrid Ù Mirroring automatique entre GSE Ù Existence d’un catalogue local pouvant être recopié Ù Commandes : -Put_local, get_local : mise de fichiers dans la base locale -Publish_catalog, get_catalog : exportation, importation de base locale -Replicate_get, replicate_put : push/pull de fichiers vers/de un hôte distant

31 Service commun d’interfaçage uFonctionnement:  Permet de communiquer avec n’importe quel composant de niveau structure  Exemples : Ù Soumission de jobs  Utilise les composants globus : Ù Gatekeeper Ù Job manager

32 Autres services uAuthentification et accounting (CERN)  Utilisation complète du GSI  Quelques mécanismes d’automatisation ont été ajoutés ÙOutil de configuration LDAP ÙRegénération périodique des listes d’autorisation ÙOutils visuels de manipulation d’arborescence uIndex des services  Découverte automatique des services fournis par la grille  Pas encore développé, fera partie du prochain testbed

33 Autres services (2) uInformation et monitoring  Gère toute la connaissance de l’architecture distribuée  Gestion répartie  3 implantations coexistent Ù MDS de Globus Ù Ftree Ù R-GMA implantation du GMA (Grid Monitoring Architecture) proposé par le Global Grid Forum

34 Conclusion u Expérience en vraie grandeur d’une infrastructure pour le stockage distribué de grandes quantités de données u Ça marche!  Plateforme de test avec plus de 30 sites  Tout n’est pas fini mais des expériences tournent u RPM d’installation/intégration disponible  Supporte RH 6.2 seulement  Validation par le CERN