Patrice: introduction Le CPU n'est trop un probleme, le stockage est plus problematique. Il faut quand meme prevoir longtemps a l'avance les productions importantes. Selon les common funds, l'IN2P3 devrait investir $200k au CC. Tibor sera paye pour un an pour le computing D0 au CC. Philippe Gaillardon: etat des demandes 2003/2004 - le budget ne peut assurer toutes les demandes, pb d'infrastructure (clim de la salle machine) - en 2003, on a consomme essentiellement depuis Novembre -> credibilite - evolution du CPU en 2004: recommende de ne pas acheter de machines avant les travaux de clim -> ete 2004 Philippe Gaillardon: le stockage a l'IN2P3 transparents de la session utilisateur du CC http://cc.in2p3.fr/article.php3?id_article=164 http://cc.in2p3.fr/IMG/pdf/stockage.pdf - AFS : espace limite, partitions 8Go, performances evolution OpenAFS et kerberos v5, nouveaux serveurs demande augmenter taille des caches AFS pour tenir une release du code --> plusieurs Go nouveaux serveurs -> on va pouvoir avoir plus de GROUP_DIR Michel, Smain -> beaucoup de GROUP_DIR ! ridicule wrt FNAL - HPSS : COS important, definit les ressources (serveurs disque & rfio) avoir une base de donnee pour gerer les fichiers dans HPSS, les commandes type rfdir sont tres lentes SAM connait des fichiers officiels dans HPSS SRB voir presentation http://cc.in2p3.fr/article.php3?id_article=172&var_recherche=SRB, le CERN a choisi SRM pour le LHC 400To dans HPSS Juin 2003 151To 58Mo/s jour pic 10To 120Mo/s essentiellement du read, sauf D0 cout important, serveurs disque et bande changement du serveur central en cours ressource D0 2 serveurs disques dont un serveur RFIO, 4To 2 serveurs disques ... sans disque ! commande pas encore lancee COS 0 58k files 3.9 To COS 21 73k 5.1 <70Mo/file> COS 22 143k 58.0 <405Mo/file> ~ 3000 bandes 20Go 55euros/bande --> migration vers bandes 50Go COS 10 45k 0.8 | 11 13k 1.8 | == COS 0 12 1k 1.1 | optimisation de la lecture par la creation de familles de fichier HPSS v5.1 meilleur perf en DB, java SRB, fonctions speciales (purge cache, liste cache), besoin de kerberos v5 - espace de stockage semi-permanent stockage temporaire de petit fichiers <100 Mo acces courts et aleatoires a un ensemble de fichiers acces transparent aux donnees (interactif et batch) 10 experiences SNOVAE, AUGER, BaBar, biometrie 7To 5 serveurs disques, NFS, RFIO gestion de l'espace par l'experience etudes de solutions plus globales - xrootd: http://cc.in2p3.fr/article.php3?id_article=175 Patrice : etat actuel GROUP : 136 Go 66% THRONG 8 Go 68% SPS 20 Go 39% HPSS 64 To 2 serveurs avec 2.5To CPU 15MUI demande en 2003 tres peu utilise demandes 2004 3 serveurs HPSS avec 2 To THRONG 32 Go GROUP 184 Go SPS 1 To machine proxy DB Jean-Yves Nief : xrootd permet la repartition de charge entre serveurs, la tolerance panne interface avec le stockage de masse (HPSS pour le CC) configuration dynamique des serveurs en cours de deploiement au CC (BaBar), encore en test sera integre a root dans les prochains mois Tibor Kurca: SAM-Grid global distributed computing for D0 (and CDF) SAM + JIM (Jobs and information management) JIM construit sur outils grid (Condor-G & Globus) SAM station ccin2p3-analysis SAM grid installe : client, submission, monitoring, execution site tests en cours avec winsconsin + manchester en Mars : soumission de jobs MC, production MC a grande echelle problemes de SAM @ Lyon: . probleme dans les protocoles de communication interne a SAM, conduit a des "oublis" de fichier dans l'analyse framework . tous les fichiers jamais transfere se retrouve dans HPSS, comment faire le menage ? Q: comment sont gerees les priorites entre la grille et les utilisateurs du CC Patrice: les job grid apparaissent sous un account dont on pourrait gerer les priorites Bernard Andrieu: Point de vue des utilisateurs du LPNHE tests de reconstruction, environement D0, TMB officiels, petits volumes analyse root-tuples prives hors SAM / D0 les + facilite d'acces, TMB, environment D0, utilisation HPSS espace / scratch suffisant pour des petits volumes tourner en interactif ? quelle est la limite ? les - apprentissage du CC (1 semaine) espace AFS tres limite pas de DB locale des TMB (ne veut pas utiliser SAM) SRB ? utilisation du batch penible pour la mise au point des jobs (classe batch ultra rapide ?) absence de soutien (root, C++) au labo bbftp, amelioration du manuel, plus d'exemples manque d'information du CC en cas de problemes (AFS, batch) sauvegarde sous Linux et apres traitment de gros volumes de donnees database locale maintenance de la page web introduction a l'analyse ? (peu de reactions, effort a poursuivre ?) oui dit la salle Patrice Verdier: point de vue de l'utilisateur utilisation intensive: selection run jet/met + analyses du LAL tres satisfait (puissance CPU) e.g. 100M evts en 5 jours 500 jobs run selection: 1 fichier histo par run, petits 10-20MB utilisation de sps, NFS /sps/d0 mais utiliser plutot en rfio Frederic Deliot: utilisation recente, assez content espace group tres limite Patrice Lebrun: reprocessing fin novembre - debut janvier 7To de DST trasnfere 7.3 To produit et stocke de facon permanente 35M evts (15s/evt 1GHz) ~ 1 MUI ou 10% du CC Patrice Lebrun: production MC privee, utilisation privee possible, a tester catalogue des fichiers prives dans la DB de Lyon faire revivre le comite analyse, quelqu'un pour prendre ca en main optimisation des acces HPSS avec la liste de fichiers dans le cache / par bande