La Grille EGEE M. Louvin (LAL-Orsay) Tutorial EGEE Utilisateur (LAL) 2 février 2007

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 principales applications 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 : RB/CE) Autorisation VOMS directe : utilisée par les 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 : RB + CE 2 générations : LCG RB/CE + gLite WMS/CE Resource Broker : 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 gLite RB s’appelle WMS… Computing Element (CE) : interface à des batch schedulers Condor, LSF, Torque/MAUI, SGE… BLAH : protocole d’interaction avec le batch system Transmission des user requirements, changement de priorité…

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 déjà utilisés 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

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 2 principaux protocoles d’accès actuels : gsiftp et rfio Gsiftp : transfert intégral du fichier à la ftp Rfio : accès direct au contenu du fichier, API Posix like Ajout en cours (D. Jouvenot) du transport http dans DPM Besoin de protocoles hautes performances en lecture : 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

Querelle Push / Pull… 2 modes de propagation des jobs aux workers Push : ordonnanceur envoie les jobs aux workers Pull : worker demande un job à l’ordonnanceur Recouvre en partie la différence grille institutionnelle / desktop grid Push : approche meta-scheduler à la Globus / Condor Pull : desktop grid pour faire face à la volatilité Avantages « push » : match making Sélection des ressources les plus appropriées à partir de critères spécifiés par l’utilisateur Prix à payer : temps de scheduling (# 1-2 mn) Avantage du « pull » : efficacité Job soumis sur un worker seulement si disponible Difficile de prendre en compte les contraintes sur la localisation des données dans un scheduler générique Suppose une queue centrale de tous les jobs

… Querelle Push / Pull Une tendance à la convergence… Intégration du mode « pull » dans gLite Les jobs « pilotes » ou Condor « gliding » Jobs légers en mode « push » qui récupèrent les jobs réels dans une « task database » Vérification de l’environnement requis avant exécution d’un job Problème potentiel d’efficacité si jobs soumis pour rien gLite pre-execution jobs Swallow resubmission si environnement non conforme Une alternative : « bulk submission » Soumission unique d’un grand nombre de jobs identiques dont seul les paramètres d’entrées changent Diminution importante du coût du scheduling « push » tout en gardant les possibilités du match making Implémenté dans gLite CE

Futur : Grilles de Services Evolution des grilles institutionnelles pour plus de flexibilité dans l’implémentation des services Repose sur les technologies SOA standard Web services (WS-* standards) L’utilisation d’un “registry” permet plus de souplesse dans la localisation des services et l’interaction client / service Registry query location Client Service interaction

EGEE : Les Objectifs EGEE - €32 M EGEE-II - €35 M Objectifs 1 Avril 2004 – 31 Mars 2006 71 partenaires dans 27 pays, organisés en « fédération » EGEE-II - €35 M 1 Avril 2006 – 31 Mars 2008 91 partenaires dans 32 pays 13 Fédérations 160 VOs Objectifs Infrastructure de production offrant des ressources à grande échelle pour toutes les communautés e-science Attirer de nouvelles ressources et de nouveaux utilisateurs tant privés que publics Maintenir et améliorer le middleware gLite

EGEE : La Réalité … Size of the infrastructure today: 196 sites in 42 countries ~32 000 CPU ~ 3 PB disk, + tape MSS Sustained load 20 Kjobs/day Data Transfer > 1,5 GB/s http://gridportal.hep.ph.ic.ac.uk/rtm/

OSG Open Science Grid Modèle à la EGEE aux USA Vient d’obtenir un financement de 5 ans (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 croissante avec EGEE Sécurité, support, BDII…

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 S’appuie sur des moteurs de workflow (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…)

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 end of 2007) Generates petabytes of data per year! Intended to run 15-20 years Plus 1-10 times that in simulated data. 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 et première reconstruction. 20% des ressources globales T1 (~15) : une partie des données brutes et reconstruites (duplication). 40% des ressources globales T2 (~100, ex: GRIF) : simulation et analyse, pas de stockage de long terme. 40% des ressources globales Principal challenge est la distribution des données Données organisées en dataset et distribuées avec FTS

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 La pérénisation des structures sur le mode GEANT est posée 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é 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