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