05-fevrier-2007Eric Lancon1 ATLAS Bilan 2006 - Planning 2007.

Présentation au sujet: "05-fevrier-2007Eric Lancon1 ATLAS Bilan 2006 - Planning 2007."— Transcription de la présentation:

1 05-fevrier-2007Eric Lancon1 ATLAS Bilan 2006 - Planning 2007

2 05-fevrier-2007 Eric Lancon 2 ATLAS : Grid organisation CERN LYON NG BNL FZK RAL CNAF PIC TRIUMF SARA ASGC LPC Tokyo Romania GRIF T3 SWT2 GLT2 NET2 WT2 MWT2 T1 T2 T3 VO box, dedicated computer to run DDM services All Tier-1s have predefined (software) channel with CERN and with each other Tier-1. Tier-2s are associated with one Tier-1 and form the cloud Tier-2s have predefined channel with the parent Tier-1 only. LYON Cloud BNL Cloud TWT2 Melbourne ASGC Cloud “Tier Cloud Model” Pékin

3 05-fevrier-2007 Eric Lancon 3 T1 de Lyon associé à BNL & FZK BNL LYON FZK Tier-1 associations And relative sizes

4 05-fevrier-2007 Eric Lancon 4 Tier-2 associés à Lyon Clermont GRIF Romanie Pekin Tokyo

5 05-fevrier-2007 Eric Lancon 5 DDM : Data Distribution Management T1 T0 T2 LFC T1 …. VO box FTS Server T1 FTS Server T0 LFC: local within ‘cloud’ All SEs SRM Catalogues généraux centralisés (LFC): Contenus des datasets Localisation des datasets dans les T0-T1-T2 Liste des requêtes de transferts des datasets Catalogues locaux (LFC) Localisation dans le centre des fichiers de chaque dataset Catalogues généraux centralisés (LFC): Contenus des datasets Localisation des datasets dans les T0-T1-T2 Liste des requêtes de transferts des datasets Catalogues locaux (LFC) Localisation dans le centre des fichiers de chaque dataset Demande au catalogue central : liste des datasets a répliquer Gestion transfert Enregistrement informations dans catalogues locaux et centraux Demande au catalogue central : liste des datasets a répliquer Gestion transfert Enregistrement informations dans catalogues locaux et centraux

6 05-fevrier-2007 Eric Lancon 6 Réalisations en 2006 Tests de transferts :  T0  T1  T1  T1, T2 Reprocessing pas encore testé Production MC :  Au Tier-1 Tant qu’il n’y a pas de données réelles Et pas de tests T0->T1  Aux Tier-2 du nuage Données produites transférées et enregistrées a Lyon

7 05-fevrier-2007 Eric Lancon 7 BADOK

8 05-fevrier-2007 Eric Lancon 8 Consommation CPU - 2006 65.000.000 UI demandées 27.358.506 UI consommées  42% des demandes 65.000.000 UI demandées 27.358.506 UI consommées  42% des demandes

9 05-fevrier-2007 Eric Lancon 9 LHC au CC Nouveaux CPU % LHC No increase Nombre de Jobs LHC Jobs, ALL Jobs CC, Fraction LHC

10 05-fevrier-2007 Eric Lancon 10 Production ATLAS 2006

11 05-fevrier-2007 Eric Lancon 11 Production 2006 ATLAS : Répartition par pays

12 05-fevrier-2007 Eric Lancon 12 Répartition entre sites français - I

13 05-fevrier-2007 Eric Lancon 13 Répartition entre sites français - II

14 05-fevrier-2007 Eric Lancon 14 % CPU par site fct. temps Pbs a Clermont à partir d'août GRIF sites come and go Pbs a Clermont à partir d'août GRIF sites come and go

15 05-fevrier-2007 Eric Lancon 15 Production MC en France Début 2006 : Exécuteur installé a Saclay  Afin de ‘remplir’ la grille française Automne : exécuteur installé au CC  Mise en place de shifts de production et DDM Au CC : sélection du rôle de production dans BQS (VOMS)  80% des ressources allouées pour production MC Efficacité globale : ~40%  30% input failed (pas de CPU consommé) Problèmes FTS, SRM, sites input non disponibles…  20% output failed (CPU consommé) Crash (peu), pb enregistrements, SRM, etc…  Architecture fragile, manque d’outils de diagnostiques Production, all jobs, % Production

16 05-fevrier-2007 Eric Lancon 16 FR fraction of all Grids vs time Arrêt de l'exécuteur de Saclay en août Redémarrage a Lyon en novembre Arrêt de l'exécuteur de Saclay en août Redémarrage a Lyon en novembre

17 05-fevrier-2007 Eric Lancon 17 Job & Wall-time efficiencies <>=80% <>=39% 20% of wasted CPU, ~ independent of sites 60% of jobs do not finish, large variation with sites French

18 05-fevrier-2007 Eric Lancon 18 Efficacité par site fct. temps ClermontCC Pbs du CC en octobre affecte tous les sites Cependant aucun site n’est stable… Pbs du CC en octobre affecte tous les sites Cependant aucun site n’est stable…

19 05-fevrier-2007 Eric Lancon 19 Période 21/12 – 08/01 (19 jours) 81526 jobs, 64657 OK  eff = 79% En France, faits par lyonDQ:  44092 jobs (54 % des jobs de l’exécuteur)  35138 OK  eff = 80% Par site (1) :  Lyon: 67% eff = 87%  Auvergne: 22%eff = 71%  GRIF: 9%eff = 47% Erreurs par type:  Lyon: 62% stagein  Auvergne: 68% jobs ne démarrent pas (2)  GRIF: erreurs variées (2) (1) Marseille et Saclay arrêtés la plus grande partie du temps (2) Disques WN pleins, droits écriture, pbs ssh

20 05-fevrier-2007 Eric Lancon 20 Conclusion provisoire Le Tier-1 influence l'efficacité des Tier-2 mais pas toujours  Problèmes récurrents de srm au CC Chaque Tier-2 a des problèmes spécifiques Il faut améliorer :  Le monitoring,  Plus de checks systématiques,  L’implication des sites,  Les relations avec les sites Cependant…  L'efficacité du nuage français est reconnu!

21 05-fevrier-2007 Eric Lancon 21 Bilan DDM Evolution de dCache vers 1.7.0  Depuis pas de situation stable plus que qcq jours consécutifs Problèmes de l'accès aux disques :  serveur SRM «buggé» et surchargé  Problèmes de dimensionnement?

22 05-fevrier-2007 Eric Lancon 22 2007 CDR : Computing Dress Rehearsal  Processing T0  Distribution T1 et T2 Validation de l’analyse distribuée  Sur la Ferme d’Analyse et les Tier-2 Très forte montée en puissance malgré le changement du planning du LHC

23 05-fevrier-2007 Eric Lancon 23 Ressources 2007 : demandes Tiennent en compte la révision des ressources ATLAS CPU :  206,000,000 UI  C.a.d. 1175 KSI2k  Tier-1 (~1/3) & Tier-2/AF (~2/3) DISK :  265 TB de disk sous srm2  10TB sur /sps  300 GB AFS stockage des versions de développement du software Tape :  222 TB

24 05-fevrier-2007 Eric Lancon 24 Besoins pour 2007 Un environnement de travail stable au CC  afs, hpss, BQS, srm, …  Opérations de maintenances coordonnées 2GB de mémoire virtuelle par job  Sous utilisation du CC Mise en place du T2 contenant la ferme d’analyse  Réseau CC assez rapide pour la ferme d’analyse?  Prise en compte des VOMS (Rôles et groupes) DDM :  Système stable  SRM v2.2, FTS 2.0  Seconde Vobox pour séparer développement / production ORACLE  ATLAS séparé des autres expériences (demande d’ATLAS)

25 05-fevrier-2007 Eric Lancon 25 CC 2007 Tier-1 cclcgxx.in2p3.fr Tier-1 cclcgxx.in2p3.fr Production Reprocessing Real DATA Production Reprocessing Real DATA User /atlas/fr User /atlas/fr User  BQS Ferme Analyse / Tier-2 cclcgxx.in2p3.fr Ferme Analyse / Tier-2 cclcgxx.in2p3.fr Production MC DATA Production MC DATA Tier-1 Allocation MoU Tier-1 Allocation MoU Tier-2 Allocation MoU Tier-2 Allocation MoU Ferme Analyse Ferme Analyse

26 05-fevrier-2007 Eric Lancon 26 CC 2007 Production Reprocessing Real DATA Production Reprocessing Real DATA User /atlas/fr User /atlas/fr User  BQS Production MC DATA Production MC DATA Tier-1 Allocation MoU Tier-1 Allocation MoU Tier-2 Allocation MoU Tier-2 Allocation MoU Ferme Analyse Ferme Analyse Accounting trimestriel LCG du Tier-1 et du Tier- 2 (CC redevable a atlas) Variation au cours du temps  Allocation Tier-1 vs Tier- 2  Priorités dans le Tier-2 (production vs utilisateurs) Ferme d’Analyse  Réservée au Français  Entrée rapide en machine (analyse)

27 05-fevrier-2007 Eric Lancon 27 CC 2007 Production Reprocessing Real DATA Production Reprocessing Real DATA User /atlas/fr User /atlas/fr User  BQS Production MC DATA Production MC DATA Tier-1 Allocation MoU Tier-1 Allocation MoU Tier-2 Allocation MoU Tier-2 Allocation MoU Ferme Analyse Ferme Analyse Le système doit être flexible :  Changement de priorités  Des quotas (par groupe de physique, …) Doit pouvoir être configurable en fonction  Des demandes d’ATLAS (production, reprocessing,…) pour les Tier-1 et Tier-2  Des besoins des physiciens français (conférences etc…) pour la Ferme d’Analyse Possibilité que ATLAS- France puisse gérer les priorités