La Grille EGEE G. Philippon (LAL-Orsay) Tutorial EGEE Utilisateur (Dakar) 14 Avril 2009

Agenda Grilles : promesses et défis Les différents composants et acteurs d’une grille L’histoire des grilles Les principaux composants de gLite Les différentes grilles institutionnelles Les principales applications L’exemple LCG Conclusions

Les Grilles : Pourquoi ? Partage transparent de l’utilisation de ressources massivement distribuées par des utilisateurs de différentes disciplines… “A computational grid is a hardware and software infrastructure that provides dependable, consistent, pervasive, and inexpensive access to high computational capabilities.” (The Grid, I. Foster, C. Kesselman, 1998) … pour permettre une mutualisation des coûts Donner accès à une très grande quantité de ressources par l’agrégation de ressources existantes Optimiser l’utilisation d’infrastructure coûteuse Permettre un accès occasionnel à de grosses ressources Permettre à des communautés à faible moyen d’accéder à des ressources significatives

Les Défis Interfaces standard aux ressources de calcul et aux données dans un contexte de sécurité intégrée Ne doit pas être spécialisée pour une application Définir des APIs pour l’ensemble des services Ressources et utilisateurs appartenant à des domaines « administratifs » différents Pas d’accord bilatéraux directs possibles Gestion de ressources dynamiques et hétérogènes Forte distribution rend impossible des choix homogènes Accounting des ressources mises à disposition ou utilisées par les différents groupes Doit être possible d’exécuter un contrôle a posteriori Valorisation des contributions Grands volumes de données distribuées Contrôle de l’accès aux ressources et aux données Encryptage nécessaire pour certains types de données

Les Grilles : La Vision Grid “Middleware”

Composants de la Grille Les ressources Apportées et mises en oeuvre par certains groupes d’utilisateurs Partagées (ou partageables) entre tous les groupes Middleware (intergiciel) : services standards permettant 1 accès virtualisé aux ressources Sécurité (authentification / autorisation) Soumission de jobs Accès aux données, gestion de méta données Les applications Ne font pas partie de la grille mais l’utilisent Mise en oeuvre par une communauté d’utilisateur Peuvent nécessiter une adaptation pour utiliser les services du middleware

Avantages Techniques Mutualisation des développements et de la gestion des ressources entre communautés d’utilisateurs Beaucoup de problèmes communs Services standardisés de “haut niveau” évitent la duplication des solutions Des utilisateurs concentrés sur leurs “métiers” plutôt que sur les outils Particulièrement important pour les « petites » communautés Des ressources adaptées à la croissance des besoins Possibilité de démarrer avec peu de ressources Possibilité d’accès à plus de ressources pour la production Les APIs de grille facilitent l’identification et l’accès transparent à de nouvelles ressources Accès aux données Un grand volume disponible et “universellement” accessible Facilité de localisation et de partage contrôlé

Les Différents Acteurs Utilisateurs Scientifiques ou personnes souhaitant exécuter des jobs Organisations Virtuelles (VO) Personnes partageant un même but Communauté délimitée se dotant de moyen de certifier l’adhésion d’un membre Possibilités de sous groupe ou statuts différents Sites et administrateurs Ressources dans un domaine d’administration unique Responsable de la gestion cohérente et efficace des ressources Organisations “réelles” : souvent les financeurs… Instituts, agences de financement, gouvernement... Forums et institutions de standardisation OASIS, GGF, W3C, IETF, ... Pas d’accord bi-latéraux (requis) entre ces entités

Grilles : l’Histoire A partir de la fin des années 90 Conséquence des recherches sur le meta scheduling des années 90 // avec le power grid (réseau électrique) Accès consistant et universel aux ressources Permettre la consolidation d’infrastructures entre communautés Au départ, très axé sur la soumission de job (Globus, SETI) Pas d’agrément bilatéral entre sites et utilisateurs Jobs peuvent accéder tous les sites de façon transparente Pas nécessaire que jobs et données soient sur le même site Pas nécessairement des ressources dédiées (desktop grid) Les grilles de données (depuis 2000) Permettre la gestion et l’accès transparent à des grandes masses de données réparties sur la grille. Premier projet : EDG (2001-2003)

Grilles Institutionnelles Ensemble de ressources généralistes dédiées Interconnexion de « cluster » Possibilité d’applications arbitraires 1 père commun (pour la plupart) : Globus Administration fortement coordonnée Y compris prise en compte de la problématique de support 1 infrastructure de sécurité permettant l’identification des utilisateurs Autorisation principalement sur la base des VOs Autorisation grain fin basée sur les groupes et les rôles 1 système d’information reflétant l’état des ressources en « temps réels » Les principales infrastructures : EGEE, OSG D’autres architectures comme le « desktop grid » Opposé : peu de coordination, pas d’authentification…

gLite : Core Services… gLite : middleware développé par EGEE Successeur du MW initial EDG/LCG De nombreux services (nom usurpé !) VOMS (VO Membership Service) : décrit les membres d’une VO et leur rôles ou groupes spécifiques Pierre angulaire pour l’identification des droits des utilisateurs Utilisé par tous les grids (OSG, NDG…) Permet une vue cohérente des VOs dans tous les grids Sécurité (authentification) : GSI Vient de Globus, utilisée par toutes les grilles institutionnelles GSI basé sur PKI (certificat) , utilisateur identifié par 1 DN /0=GRID-FR/C=FR/O=CNRS/OU=UMR8607/CN=Michel Jouvin Sécurité (autorisation) : 2 services LCAS/LCMAPS : mapping d’un DN sur un compte Unix. Utilisé par la plupart des services (ex : WMS/CE) Autorisation VOMS directe : utilisée par certains Storage Elements pour les ACLs (garantie de cohérence et de permanence)

… gLite : Core Services Système d’information (BDII) : description des resources et de leur état Mise à jour en permanence, fréquence ~2-15mn Basé sur LDAP et un schéma d’information (GlueSchema) Organisation hiérarchique de l’information et des serveurs collectant les données sur les ressources « Top level » BDII sont les seuls utilisés directement par les utilisateurs User Interface (UI) Pas 1 GUI…!!! Ensemble d’API (bibliothèques, modules Perl/Python…) Doit permettre d’écrire des frameworks spécialisés pour 1 besoin particulier API / composant, pas (peu) d’API globales pour un besoin utilisateur Outils ligne de commande pour les fonctions les plus courantes Interface “utilisateur” intégrant plusieurs API de base Ex : lcg utils (copie de fichiers) utilisent BDII, SRM, LFC, GSIFTP…

gLite : Computing Services… 2 composants principaux : WMS + CE Ancienne génération de WMS : LCG RB WMS : meta-scheduler permettant un « match making » entre requirements et ressources Sélectionne un site (CE) en s’appuyant sur le Système d’Information contenant l’état réel des ressources Intégre des contraintes sur la localisation des données Fonctionnalités avancées : bulk submission, shallow resubmission, pre- execution jobs, DAG… Basé sur Condor-G Computing Element (CE) : interface à des batch schedulers Condor, LSF, Torque/MAUI, SGE… Génération actuelle : LCG CE, nouvelle génération CREAM CE CREAM CE permettra plus d’interaction avec le scheduler (BLAHP)

… gLite : Computing Services Des services complémentaires ou alternatifs… GridWay : RB plus “léger”, permettant de faibles latences de soumission Utilise l’interface “standard” DRMAA pour gestion de jobs Moteurs de workflow : TAVERNA et MOTEUR Demandeur d’une interface Web Service GANGA/DIANE (ARDA) : framework de gestion de jobs orientés sur les grosses productions Interface de plus haut niveau que le RB, s’interface avec le RB Utilisé par les expériences LHC Atlas et LHCb mais fondamentalement générique Gestionnaire de pilot jobs (ex: Atlas/PanDA, LHCb/DIRAC) Gère une queue centrale de jobs à effectuer pour la VO Soumet un job « générique » qui vérifie l’environnement et lance l’exécution d’un job utile uniquement si les prérequis sont réunis Augmente l’efficacité dans les grosses productions Forte diminution des jobs en erreurs

gLite : Data Management … 2 composants : Storage Element (SE) + File Catalog Unité de base est le fichier nom modifiable (MSS) File Catalog : équivalent d’un directory traditionnel Non distribué, éventuellement réplicable (Oracle) Peut associer plusieurs replicas à un nom logique Permet le déplacement transparent des données physiques Storage Element : basé sur l’interface SRM Distinction entre localisation (SURL : Site URL) et protocole d’accès (TURL : Transport URL) Permet de répartir les fichiers sur un grand nombre de serveurs qui apparaissent comme un seul Peut intégrer un MSS backend Plusieurs protocoles d’accès actuels Gsiftp : transfert intégral du fichier à la ftp Rfio : accès direct au contenu du fichier, API Posix like https : accès aux données depuis un browser Web (pas besoin d’UI) Posix transparent file access : NFS4 ?

gLite : Autres Services… FTS : File Transfer Services “Batch system” pour le transfert de data, s’appuye sur SRM Optimise l’utilisation des resources : Nombre de transferts concurrents… Gestion des reprises en cas d’erreur Metadata Management : AMGA Associe des meta-données à des fichiers (ou des objets) Approche type base de donnée Permet la réplication et la distribution des serveurs Service standard dans la prochaine version de gLite Encryption : HYDRA Serveur de clé pour l’encryption de données au vol Utilisé principalement par Biomed

… gLite : Autres Services Database Access : OGSA DAI Interface grille, y compris sécurité GSI, aux DBs Encore embryonnaire, peu utilisé, problème de performance et de scalabilité Accounting Service critique pour la grille pour vérifier le “fairness” de la mutualisation Utilise les informations de monitoring stocké dans R-GMA R-GMA : base de donnée de monitoring distribué basé sur un modèle producteur/consommateur APEL : collecte et publication des informations relatives aux computing services (CE) Service actuellement en production DGAS : framework générique de collecte d’information d’accounting Devrait à terme remplacer APEL

Job Execution Workflow User Interface Resource Broker Information System Replica Catalogs 1. submit 2. query 3. query 4. submit 5. retrieve 6. retrieve publish status User Interface Catalog Storage Element Computing Site 1 Site 2

EGEE : Les Objectifs EGEE - €32 M EGEE-II - €35 M EGEE-III - €31 M 1 Avril 2004 – 31 Mars 2006 71 partenaires dans 27 pays, organisés en « fédération » EGEE-II - €35 M 1 Avril 2006 – 30 Avril 2008 120 partenaires dans 48 pays 160 VOs EGEE-III - €31 M 1 Mai 2008 – 30 Avril 2010 Objectifs Infrastructure de production offrant des ressources à grande échelle pour toutes les communautés e-science privées et publiques Assurer la transition vers 1 infrastructure pérenne basée sur des infrastructures nationales (NGI)

EGEE : La Réalité … Size of the infrastructure today: 250 sites in 50 countries ~70 000 CPU ~ 20 PB disk + tape MSS Sustained load 150 Kjobs/day Data Transfer > 2 GB/s http://gridportal.hep.ph.ic.ac.uk/rtm/

Ressources fournis Les sites décident qui peut utiliser leur ressources. Les sites du EGEE supportent des disciplines variées Les sites souvent déploient plus d’un CE ou SE. Nombre pas taille des ressources! # CEs # SEs HEP 292 299 LS 113 123 CC 25 41 AA 57 83 Fusion 19 21 ES 42 65 Others 143 149 Unknown 288 327 Infra. 282 306 Total 366 334

Forte Croissance de l’Utilisation Nombre d’heures délivrés en 1 an : x2 #30000 cœurs dernière génération utilisés en permanence 1/3 hors LCG

VOs « actives » Nombre des VOs « actives » augmente ainsi que les ressources consommées par VO Nombre de VO multiplié par 2 en 2 ans Total VOs : 104 enregistrées, 258 visibles La croissance concerne surtout les VOs consommant beaucoup de ressources

OSG Open Science Grid Modèle à la EGEE aux USA Financement de 5 ans (2007-2011) Ouvert à toutes les communautés utilisateurs Comme en Europe, HEP est la communauté la plus active Les gros centres de calcul + des universités Centres de calcul DOE 96 sites, 15 000 CPU, 4 PB disque, 6 PB bande Produit un middleware Basé sur VDT (Globus+Condor), comme EGEE Pas de resource broker spécifique : utilisation de Condor Plusieurs composants importés d’EGEE : VOMS, SRM… Des développements propres : authz (SAZ/GUMS) Intégration opérationnelle et interopérabilité croissante avec EGEE Sécurité, support, BDII, monitoring…

Les Principaux Utilisateurs Astrophysics Planck, MAGIC Computational Chemistry Earth Science Hydrology, Pollution, Climate, Geophysics, … Fusion High-Energy Physics LHC/LCG, Tevatron, HERA, … Life Sciences Medical Images, Bioinformatics, Drug Discovery Related Projects Finance, Digital Libraries, … And more…

Type d’Applications… EGEE : support de différents types d’application simultanément sur la même infrastructure Différence avec les desktop grids Simulation : batch, pas de gestion de donnée CPU intensif, jobs « longs » Pas (peu) de données en entrée, gros fichiers de sortie Beaucoup de job indépendants, peu d’utilisateurs S’appuie sur des gestionnaires de jobs tels GANGA ou DIANE Analyse de données : batch + gestion de données Beaucoup de données distribuées en entrée, gros fichiers en sortie Requirements de la simulation + outils sophistiqués de transferts de données (ex : FTS) Peut nécessiter aussi une gestion de meta-données (AMGA) ou l’intégration avec des bases de données

… Type d’Applications Pseudo-interactif : temps de réponse court Application hors grille qui soumet un grand nombre de jobs courts et consolide les résultats Généralement GUI ou portail Web Peu de données en entrée et en sortie Besoin d’un scheduling immédiat des jobs Problématique de standing reservation, préemption… Workflow : enchainement de tâches complexes Même problématique que l’analyse de données mais avec des tâches complexes et interdépendantes Utilisation de plusieurs infrastructures : super-calculateurs, grille… S’appuie sur des moteurs de workflow hors grille (e.g. TAVERNA) Applications parallèles : MPI Actuellement 1 job confiné dans 1 site (idem DEISA) Utilisation croissante d’applications commerciales Problématique du licensing (ex : WISDOM, EGEODE, MatLab…)

LHC : How Large is Large ? 9 km © CERN Geneva

L’expérience Atlas 40 m de long, 7000 tonnes…

Données du LHC : Le Challenge Data Rate: 40 MHz interaction rate 100 Hz of filtered events 1-10 megabytes per filtered event 0.1-1 gigabytes/second Data Volume: LHC runs 24/7 (starting mid-2008) Generates 15 petabytes of data per year! Intended to run 15-20 years Simulated data about the same size Data management is the real challenge for LHC. Recording and retrieval. Metadata management for locating interesting data. Chaotic analysis and large productions.

LCG : LHC Computing Grid Organisation mondiale regroupant les expériences LHC et les sites leur offrant des ressources Appartenance définie par 1 MoU Chaque expérience (4) est 1 VO Besoin global estimé à 100 MSI2K en 2008 LCG utilisent les infrastructures de grille existante Principalement EGEE et OSG Sites répartis en 3 Tiers suivant leur taille/responsabilité T0 (CERN) : toutes les données brutes. 20% des ressources globales T1 (~15) : une partie des données brutes et reconstruites (duplication). 35% des ressources globales T2 (~100, ex: GRIF) : simulation et analyse, pas de stockage de long terme. 45% des ressources globales Principal challenge est la distribution des données Données organisées en dataset et distribuées avec FTS

Avantages de la grille La science se fait avec un mélange de coopération et de compétition. Partage des ressources : Meilleur utilisation des ressources Permet d’obtenir (et publier) des résultats plus rapidement Fédération des ressources (et données) : Utilisations de données plus variées Production de résultats plus précis Collaboration Infrastructure permet de mettre ensemble les gens avec des compétences différentes. Moyen pour publier, re-utiliser, et combiner les résultats précédents.

Conclusions… Les grilles sont une réalité 2 infrastructures (EGEE, OSG) en phase de production La communauté HEP n’a pas de plan B pour le LHC Première démonstration de bout en bout par Atlas en Aout 08 La pérénisation des structures sur le mode GEANT (EGI) est en cours Les grilles attirent des communautés d’utilisateurs et des applications de plus en plus variées Moyen sans équivalent de partage des ressources Réduction des coût hardware Meilleur temps de réponse Augmentation (potentielle !) de la fiabilité

… Conclusions Des APIs standard de haut niveau disponibles Permet l’intéropérabilité de différentes implémentations pour un même service Intégration des différents types de grille Permet aux utilisateurs de se concentrer sur leurs métiers Le « middleware » continue évoluer pour mieux servir ses utilisateurs. Le base est plus stable, plus « scalable », … Plus des services complémentaires disponible

Liens utiles Site web de l’activité NA4 : Informations gLite : http://egeena4.lal.in2p3.fr/ Informations gLite : http://glite.web.cern.ch/glite/ « Use Cases » : http://egee-uig.web.cern.ch/egee- uig/production_pages/UIGindex.htm Matériel formation de l’activité NA3 : http://www.egee.nesc.ac.uk/trgmat/index.html