Infrastructure LCG-France et Analyse de données Frédérique Chollet Fabio Hernandez Fairouz Malek Réunion CMS-France, IPHC Starsbourg, 27-28 mai 2009.

Présentation au sujet: "Infrastructure LCG-France et Analyse de données Frédérique Chollet Fabio Hernandez Fairouz Malek Réunion CMS-France, IPHC Starsbourg, 27-28 mai 2009."— Transcription de la présentation:

1 Infrastructure LCG-France et Analyse de données Frédérique Chollet Fabio Hernandez Fairouz Malek Réunion CMS-France, IPHC Starsbourg, 27-28 mai 2009

2 2 Sommaire LCG-France : état d’avancement  Introduction : Projet, Infrastructure, Collaboration  Contribution au W-LCG  Travaux en cours Réunion des sites, 18-19 mai au LAPP  Temps forts  Analyse de données ○La problématique ○Où en sommes-nous ?

3 3 Introduction LCG-France : composante française de la collaboration W-LCG (Worldwide LHC Computing Grid) Infrastructure dédiée au calcul LHC, organisée en grille : Hiérarchie de sites à l’échelle mondiale (44 pays)  Environ 250 centres de calcul  12 grands centres (Tier0, Tier1)  38 fédérations de plus petits centres dits “Tier2” Protocole d’accord (MoU) :  Déploiement de ressources CPU, disques, MSS sur 5 ans  Qualité service - Disponibilté des sites

4 4 Projet CNRS-IN2P3/CEA-IRFU initié en 2004  Responsables scientifique (F.Malek) et technique (F.Hernandez) Objectifs 1.conformité du CC-IN2P3 aux exigences d’un Tier-1 et d’une facilité d’Analyse pour les 4 expériences LHC 2.Contribution des sites Tier-2 et Tier-3 Financement au titre des TGE du CNRS avec soutien aux sites Tier-2 et Tier-2 depuis cette année Organisation  Comité de pilotage annuel (représentants instituts, projet, expériences, CC- IN2P3)  Comité de direction mensuel (représentants sites, calcul des expériences)  Protocole d’accord entre les partenaires : 4 groupes français LHC, le CC- IN2P3, 11 laboratoires de l’IN2P3 et l’Irfu Collaboration à l’échelle nationale - création d’une communauté d’experts grille, calcul…  Groupe technique T2-T3  Réunion des sites  Groupes de travail : Monitoring et Accounting Projet LCG-France http://lcg.in2p3.fr http://lcg.in2p3.fr

5 5 Infrastructure LCG-France Importance des collaborations à l’échelle locale ou régionale (universités, régions…) Infrastructure EGEE (support communautés non-LHC, utilisation opportuniste des ressources LHC non utilisées) A l’exception de Subatech, au moins 2 expériences LHC Co-location des composantes Tier-1 / Tier-2, Tier-2 / Tier-3

6 6 Sites CMS

7 7 Infrastructure LCG-France Importance de l’infrastructure réseau et de la collaboration RENATER - Suivi : J.Bernier (CC- IN2P3) – effort soutenu en 2008 Renater 5 : maillage en fibre noire amélioré, généralisation WDM (multiplexage longueur d’onde) pour la mise en place de réseau projet (LHCOPN, GRIFOPN…) Généralisation en cours des liens à 10Gbps (dédiés ou mutualisés) pour le trafic LHC  IPHC : 1Gb/S dédié, 10 Gb/s partagé fin 2009 (lien OSIRIS) Conservation des liens « généralistes » (via les réseaux régionaux et RENATER)

8 8 Contribution LCG-France 44 countries contributed CPU resources to the LHC experiments Source: EGEE Accounting PortalEGEE Accounting Portal Top 10 countries crontribute 85% of CPU

9 9 Contribution LCG-France Source: EGEE Accounting PortalEGEE Accounting Portal 9 du site Tier-1 (CC-IN2P3) des sites Tier-2 français

10 10 Contribution CPU par site Source: EGEE Accounting PortalEGEE Accounting Portal T1 contribution : 30 % T2 contribution : 65 % included IN2P3-CC-T2 T3 contribution : 5 % 45 % outside CC-IN2P3 T1 contribution : 30 % T2 contribution : 65 % included IN2P3-CC-T2 T3 contribution : 5 % 45 % outside CC-IN2P3

11 11 WLCG Tier-2 Accounting monthly reports Tier-2 used CPU [% 2008 pledge] by LHC VOs April. 08-Mar.09 Sites not equally used Source : EGEE accounting portal WLCG Tier-2 reportsEGEE accounting portal WLCG Tier-2 reports Pledges fully used inc. 60% efficiency

12 12 Disponibilité & Fiabilité par régions EGEE F. Hernandez/F.Chollet/F.Malek 12 Jan 09 Feb 09 Mar 09 Apr 09 Source: https://edms.cern.ch/document/963325https://edms.cern.ch/document/963325 Evaluées à partir des résultats de test fonctionnels réguliers exécutés sur les sites

13 13 Site availability for OPS (feb. 09) IPHC : 96 % GRIF : 100 % CC-T2 : 97 % SUBATECH : 96 % LPC : 93 % LAPP : 100 % LPSC IPNL CPPM Target 95% since jan.09

14 14 Disponibilité des sites CMS http://dashb-cms-sam.cern.ch/dashboard/ évaluée à partir des résultats de test spécifiques exécutés sur les sites à CMS

15 15 Temps forts LCG-France Réunion des sites 18-19 mai au LAPP http://indico.in2p3.fr/conferenceDisplay.py?confId=1660 Sessions : modèles de calcul activités expériences, compte-rendus sites  STEP09 : 1 er au 15 juin derniers tests fonctionnels et de performances simultanées par les 4 expériences  Exposé I.Fisk pour CMS  Nouvelles du Tier-1 – Infrastructure du CC-IN2P3 (Talks Ghita Rahal et Dominique Boutigny) Organisation et Support des grilles de production  Assuré actuellement par le projet européen EGEE (fin en avril 2010)  Transition vers une organisation nationale pérenne NGI (National Grid Initiative) dans le cadre de l’EGI (European Grid Initiative). Analyse de données  Comprendre les problématiques, différents cas d’utilisation, besoins des expériences  Processus d’optimisation de bout en bout : infrastructure site jusqu’aux applications

16 16 STEP 09 Derniers tests fonctionnels et de performances simultanés par les 4 expériences prévus en juin Priorité et charge simultanée des différentes activités :  Production MC, Analyse, Reprocessing, Distribution de données Points «critiques » pour les 4 expériences :  Reprocessing : Accès aux bandes – localisation des données et pre- stagging  Test simplifié dans le cas d’ATLAS lors de STEP09  Fonctionnement à 50 % du taux nominal pour CMS  Analyse : Performances I/O disque en lecture Support simultané des 4 expériences notamment ATLAS et CMS Accès écriture/lecture sur bande : jamais testé même au CERN par les 4 expériences

17 17 CMS computing I.Fisk Distribution des données :  Modèle « full mesh » passe à l’échelle en dépit d’un gros effort de commissionning  Avec de bonnes performances même par delà l’atlantique  transfert Phedex FNAL ->IPHC 100 Mo/s Analyse de données principalement aux Tier-2s :  Share CPU : 50 % simulation – 50 % analyse (idem ATLAS)  Jobs exécutés là où se trouvent les données  Politique de gestion de l’espace disque :  40 % centrallement (par Data Ops), 40 % groupes de physique, 20 % usage local  La France est considérée comme la communauté CMS la plus importante (9 canaux de physique) Test intensif de l’analyse des données dans les Tier-2s pendant STEP09  50 k jobs / jour actuellement – Estimation du modèle de calcul 100-200 k/jour  3 Tier-2 français dans le top 25 des sites les plus utilisés  Taux d’erreur de la soumission actuel (via CRAB): 10 – 20 %  Objectif : maintenir 50 % CPU actif pour l’analyse Recouvrement avec l’activité ATLAS du 1 er au 15 juin

18 18 Nouvelles du Tier-1 G.Rahal Aujourd’hui, 50 % des jobs du CC-IN2P3 soumis via la grille Amélioration de la stabilité et de la disponibilité des services : LFC, bases de données, FTS, SRM/dCache, job management, …  Consolidation matérielle par ajout de serveurs  Redondance par «load balancing » entre serveurs  Amélioration du stockage disque dCache depuis début 2009  33 M de fichiers et répertoire  1.5 Po de disque  Débit moyen : 150 Mo/s en entrée – 500 Mo/s en sortie « Cloisonnement » de la partie Tier-1  Séparation ou redistribution des activités LHC, non LHC  Restriction d’accès aux ressources CPU Tier-1 vs Tier-2 Stockage de masse HPSS : améliorations importantes planifiées  Amélioration de l’infrastructure matérielle  Migration HPSS - Intervention majeure du 1er au 5 juin  Performances du staging bande disque (400 GB/heure) insuffisantes pour ATLAS et CMS  Optimisation de l’interface HPSS – dCache (Ordonnanceur de requêtes)  Point critique pour STEP09 Amélioration service AFS (accès aux logiciels expérimentaux)

19 19 Infrastructure du CC-IN2P3 D.Boutigny (CC-IN2P3) Des travaux de mise à jour de l’infrastructure électrique et de climatisation sont en cours  Consommation électrique : actuellement proche de la limite actuelle de disjonction (1550 kW)  Climatisation : en limite des groupes froids actuels (2x 600 kW).  Réduction de la capacité pour rester dans des limites raisonnables Limites seront atteintes en 2010 Stratégie  Programme de renouvellement accéléré du matériel (serveurs de disque et de CPU)  Généralisation des armoires refroidis à eau Nouvelle salle informatique : gros progrès depuis l'attribution de financement dans le cadre du plan de relance  Objectif : mise en service progressive à partir de 2011  Timing très serré

20 20 Support des grilles de production D.Boutigny (IdG) Ce que LCG-France ne fournit pas mais dont le calcul LHC dépend  Middleware (composants génériques) de grille  Support utilisateur  Opérations quotidiennes de l’infrastructure de grille Opérateur de l’infrastructure de grille à l’horizon 2010…  EGI : opérateur d’une grille de production pérenne commune à toutes les disciplines scientifique au niveau européen  NGI-France: au niveau national (Structure juridique en cours de définition) Préoccupations  Continuité de service pour LCG  Devenir des ressources humaines et experts (CDDs EGEE)  Vers une nouvelle structure pour le support de la communauté HEP (SSC) Contribution française? Rôle, mode de fonctionnement ?

21 21 Analyse de données un problème d’optimisation de bout en bout… La problématique  Large spectre d’activités  Différents niveaux d’organisation: collaboration, groupe et individu  Différents besoins  Tâches interactives (analyse finale d’un lot restreint de données, fit, visualisation)  Tâches demandant beaucoup I/O (reduction de données)  Tâches demandant beaucoup de CPU (études des systématiques) Quels outils pour supporter ces activités ? Faut-il spécialiser des ressources et infrastructures ? Où en sommes-nous ?

22 22 Analyse de données un problème d’optimisation de bout en bout…  Point de vue des expériences  Fermes d’analyse basée sur PROOF G.Ganis (CERN)  Déploiement d’un prototype de ferme d’analyse interactive basé sur PROOF par Y.Calas (CC-IN2P3)  Utilisation xrootd par les expériences LHC par F.Furano (CERN)  Point de vue des sites  Evolution amorcée du LAN vers le 10 gbE par J.Bernier (CC), M.Jouvin (LAL), E.Fede (LAPP)  Mesure de performances d’accès aux données en lecture par G.Rospabe (LAPP)  Point de vue utilisateur :  Retour d’expérience d’un utilisateur typique ATLAS par O. Arnaez (LAPP)  1 ière utilisation du prototype de ferme d’analyse du CC-IN2P3 par L.Aphecetche (Subatech)

23 23 Problématique Processus itératifs, typiquement :  Sélection d'évènements  Etude statistiques : Calcul de probabilités ou d’erreurs  pouvant inclure un processus de reconstruction A chaque étape, à chaque analyse, un besoin spécifique ?  Utilisation intensive CPU: Etudes systématiques, Calcul de masse : Tier-2  Utilisation intesive I/O : Réduction de données : Tier-3  Interactivité : Développement d’algorithmes ou Analyse finale d’un lot restreint : poste de travail, cluster interactif Problème de localisation des données en entrée et en sortie, politique d’affectation des jobs dirigée par les données  Les jobs vont là où sont les données pour ATLAS et CMS  Les jobs vont là où le CPU est disponible dans le cas LHCb (Analyse aux T0 et T1) Stratégie « Analysis train » mise en place par Alice et LHCb  Grouper les analyses de données moyennant une certaine discipline

24 24 Fermes d’analyse basées sur PROOF G.Ganis (CERN) Infrastructures existantes  CAF (CERN Analysis Facility : 112 cœurs – 5 à 10 utilisateurs simultanés  GSIAF (GSI, Darmstad) : 160 cœurs – 5 à 10 utilisateurs simultanés  Fermes ATLAS (BNL, Wisconsin, Munich), NAF à DESY  Prototype de la ferme d’analyse au CC-IN2P3 disponible pour des tests avant la LAF ( 8 WNs – 8 cœurs) Utilisation :  Analyse finale  Calibration, prompt reconstruction sur un jeu limité de données  Simulation rapide : Fast/Toy MC PROOF : coordination de sessions ROOT distribuées  Composant standard de ROOT  Possibilité d'examiner en temps réel les outputs  Requiert XROOTD pour l'accès aux données  Configuration identique/mutualisable avec XROOTD standard mais port spécifique Réponse aux besoins de l'Analyse très io-bound (tâche fortement parallélisable)  Volume de donnée : O(1-10) TB  Throughput : 10h @ 150-250 MB/s  Performance : le hard-disk du WN devient le goulet d’étranglement (2 à 3 jobs par disque SATA max) - Utilisation de SSD permet de prendre en charge 8 jobs par WN sans pb – Connexion Gb/s suffisante

25 25 Utilisation xrootd F.Furano (CERN) Réponse au problème de l’accès direct aux données Pas de copie inutile des données sur le WN  Ce mode d’accès ne « scale » pas avec l’augmentation du nombres de cœurs) Meilleure utilisation du CPU (ratio CPUtime/Walltime) Xrootd est adapté à la lecture chaotique de nombreux petits fichiers par un grand nombre de clients  Principalement du aux performances côté client fault-tolerant  65k requêtes I/O en // niveau client - 32k file open par client  Mécanisme de cache sophistiqué  Développé en C++, intégré à root  Pas un protocol miracle non plus en cas d’infrastructure stockage ou réseau sous- dimensionnée Utilisé de différentes façons selon les sites et les expériences  Extension de systèmes de fichiers  Interfacé à SRM  Natif  Devant Castor (en mode redirection)  Alice : accès distant aux données possibles via xrootd redirector

26 26 Point de vue des sites M.Jouvin (LAL), G.Rospabe (LAPP) Evolution LAN vers le 10 GbE (sites en phase d’acquisition)  Contexte de l’analyse de données (min. 5 MB/s/job)  Connexion 1 Gb/s : suffisant pour un WN 8 cores, pas pour un disk server  Connexion 10 GbE des serveurs de disque au cœur de réseau  Combinable avec le LAG (Link Aggregation) : combinaison de plusieurs liens physiques pour offrir un lien « virtuel » offrant la somme du débit de chaque lien  Effet de cascade avec l’augmentation du nombre de serveur (WNs) à 1 Gb/s : switch de concentration (34 à 42 serveurs) et uplink 10 Gb + Cœur de réseau 10 Gbps non bloquant  Importance de mettre en place une infrastructure extensible, même si l’utilisation actuelle ne reflète par forcement ce qui sera nécessaire à l’avenir  Coûts et délais des améliorations du réseau local à ne pas négliger  Impact sur le réseau du passage aux workers N-cœurs Utilisation CPU et réseau avec une analyse de n-tuples basé sur ROOT  Capable de saturer la connexion réseau du nœud de calcul ou WN (lien Gbs)  Intérêt à « merger » les fichiers (500 Mo mergé en 1 seul fichier au lieu de 200)  Comparé à un accès direct, la parallélisation copie sur WN/analyse devient moins performante avec l’augmentation du nombre de jobs et du nombre de coeurs  Compétition entre jobs  Le disque du WN devient un goulot d’etranglement Stress de la zone software des expériences (souci général des sites)  BitTorrent : Nouvelle perspective étudiée par Alice (installation à la volée)

27 27 Point de vue utilisateur Cas d’un utilisateur typique ? (bien choisi!) ATLAS Activités sur la grille :  Analyse de données : cosmiques, MC  Validation de la physique des nouvelles releases Atlas Activité hors grille  Analyse des n-tuples (production d’histogrammes) avec du code C++/ROOT Problèmes d’outils :  Pas d’uniformité au sein d’ATLAS (alternative Ganga/PanDA), pas vraiment de critères de choix  Change rarement de méthode de soumission pour une activité donnée Support : n’utilise pas le support centralisé GGUS, choix du contact et de l’interface à solliciter jugé complexe Principales difficultés :  problème dans le code... mais aussi des causes externes  Accès aux BDs (condition DB) : pas d'accès uniforme indépendant du type de Tier  Manque un service à la CMS FronTIER  Pb de version périmée installée sur les T2s dans le cadre des releases  Problème d'accès aux données : de plus en plus rare  Problème WMS : temps de retour trop long si pb de match making

28 28 Résumé A chaque type analyse, un besoin spécifique ?  Utilisation intensive CPU: Etudes systématiques, Calcul de masse : Tier-2  Utilisation intesive I/O : Réduction de données : Tier-3  Interactivité : Développement d’algorithmes ou Analyse finale d’un lot restreint : poste de travail, cluster interactif Adaptation aux besoins et aux performances : va-t-on vers une spécialisation des infrastructures ?  ferme PRROF, partie T3, serveur xrootd natif recommandé par Alice Cohérence des composants – Convergence entre les 4 expériences  intérêt de tous mais difficile à assurer Optimisation à tous les niveaux va se poursuivre  Infrastructures stockage et réseau des sites  Software des expériences, accès aux données, taille des fichiers… Test intensif de l’analyse des données dans les Tier-2s pendant STEP09 pour ATLAS et CMS - Objectif : maintenir 50 % CPU actif pour l’analyse Priorité LCG-France  mise en place de la LAF, ferme d’analyse interactive à Lyon (Lyon Analysis Facility)  Implication des expériences requise Le nombre d’utilisateurs va décupler : est-ce un problème ?  Complexité de l’infrastructure réelle et perçue par les utilisateurs finaux  Représentation au sein de LCG-France faible aujourd’hui  Support assuré par les expériences, Rôle d’un SSC HEP…