HEPix-Rome

Un article de lcgwiki.
Jump to: navigation, search

Résumé des temps forts HEPix - Rome

Site Reports

De nombreux sites font état de problèmes de refroidissement. Parmi les pistes évoquées, l'achat de blades (30 % de dissipation en moins), le refroidissement par eau des racks, l'offre HP Modular Cooling System (MCS).
Les derniers achats sont essentiellement à base de processeurs AMD Opteron 275 dual core. On note que les sites, le CERN en tête, ont tendance à lancer leurs appels d'offre en ne précisant que les SpecInt2000 requises et plus le nombre de machines.
CASPUR est passé de SGE à PBS sur un cluster Opteron pour un meilleur support de MPI. DESY fait état de pbs avec des disques SATA et sont en train d'évoluer vers des disques SATA de "higher quality".

Michel Jouvin a présenté un site report GRIF :

Concernant la robotique, une majorité de gros sites ont en production (ou en test) la nouvelle bibliothèque SL8500 de STK (RAL, CERN, JLab, Nikhef, BNL). Le CERN test aussi du matériel IBM.

CPU Technologies
  • Introduction faite B.Panzer-Steindel du CERN

Intel vient de passer à la techno 65nm et sans doute sera suivi par AMD l'année prochaine. Aujourd'hui les processeurs AMD sont 25 % plus performant. On attend les "4-core"pour 2007 mais pas de 8-core avant 2009 au moins. Attention tout de meme les multi-coeurs ont besoin de plus de mémoire et il faut compter 10 W par Go de mémoire.

  • Compte-rendu des tests de Consommation effectués au CC par Yannick Perret

cf. http://hepix.caspur.it/spring2006/TALKS/3apr.perret.newworkers.pdf
Etude comparative très intéressante sur le rapport Puissance CPU/Consommation électrique.

  • Rapport d'expérience de l'utilisation de noeuds de calcul Dual-Core à GridKa (Karlsruhe)
  • Le retour des coprocesseurs?
    • Les processeurs spécialisés sont beaucoup plus performants que les processeurs génériques (PIV: 12 GFlops, carte vidéo 120 GFlops, PlayStation: 1800 GFlops!).
    • Des fabriquants s'associent à AMD pour proposer des coprocesseurs (ClearSpeed).
  • La fin de la loi de Moore?
    • La fréquence des processeurs stagnent.
    • On augmente la puissance en multipliant les coeurs: il faudra 32 CPU dans une machine en 2016 pour suivre la loi de Moore! (et donc 64 et 2018 et 128 en 2020...).
    • On sort donc inévitablement de la logique "Von Neuman" avec une unité de calcul, une mémoire homogène et un processus dedans. Pour les 10-15 prochaines années, on fera du multithreading, mais après?
    • C'est dommage que la fonction d'inclusion de document ait été désactivée, le plot de René Brun qui montre une cassure nette en 2005 de la montée en puissance des monocoeurs illustre parfaitement ce problème.
Network technologies

ON y compare avantageusement QSnet et Infiniband par rapport à l'ethernet 10Go.

Batch Systems

Les discussions ont principalement tourné autour du passage de l'information vers les CEs pour que les Batch Systems locaux puissent avoir accés aux demandes des jobs (CPU, Mémoire...).

L'outil BLAHP qui sera disponible dans gLite 3.2 (ou grâce à un RPM dans gLite 3.1) offre une solution intéressante à ce problème.

Cet outil extrait les données du GlueSchema pour en générer des variables d'environnement.

BLAHP a déjà été testé avec LSF au CERN et le CC-IN2P3 s'est proposé pour le tester avec BQS. Les expériences ont également présentés la facon dont elles entendaient utiliser les systèmes de batch.

  • ATLAS :
    • 1GB de RAM par job. La question de la nécessité des 2GB/CPU pour la simulation a été posée.
    • Les physiciens veulent voir la grille comme un Scheduler de Batch local
    • Toute la simulation est faite dans les T2s + simulation des 20 % des événements réels
    • L'analyse est partagée entre T1s et T2s - Analysis = user jobs without central coordination (from test algorithms to group coordinated analysis)
    • Sur chaque T2 : activité partagée entre 50% simulation - 50 % Analyse, il faut allouer 50 % des ressources à l'analyse
    • Les T1s cumulent les activités d'analyse, de reconstruction et de calibration.
    • Points essentiels pour ATLAS : support des VOMS et soumission équitable entre jobs longs (simulation env. 10-20h) et jobs courts (analyse 1/2 à 1 h)
    • Estimation du nbre de queues batch nécessaires à 4
    • Modèle d'accès aux données : actuellement copie (lcg-cp) les Input files sur le WN
  • CMS :
    • 3 ou 4 limites CPU différentes
    • Estimation : 2 TB d'AOD dans chaque T2
    • Les sites devront pouvoir gérer plusieurs catégories de jobs : One Batch Queue will not fit all !
    • A l'intérieur de la VO, des priorités (fluctuantes) seront à gérer selon les jobs
    • Demande de flexibilité (pouvoir faire passer des jobs de test rapidemment)
  • LHCb :
    • Ils ne sera pas demandé aux sites de gérer les priorités : utilisation de Pilot Agents tournant sur un worker comme des jobs LCG Normaux
    • Il y aura jusqu'à 5000 jobs de production (Dirac) en parallèle
  • Alice :
    • Utilisation de Job agents
    • L'inefficacité des jobs est aux alentours de 2.5%
    • A terme, tous les calculs Offline se feront par la grille
    • Ils demandent 2GB de RAM par Core et une VOBOX par site
Authentication technologies
Optimisation and bottlenecks
Tape and disk hardware, storage interconnects and protocols

Le CERN a présenté une comparaison des FileSystems locaux pour GNU/Linux.

L'étude a comparé : Ext3, XFS, JFS et ReiserFS

  • Ext3 : Soutenu par RH, stable, trés utilisé
  • XFS : Soutenu par SGI, fonctionnalités riches, full 64 bits, complexe pour les gros fichiers
  • JFS : Soutenu par IBM, lent, peu utilisé
  • ReiserFS (v3) : Soutenu par personne, trés utilisé, son successeur ReiserFS v4 est en cours de finalisation

Le CERN a choisi XFS, qui n'est pas inclus dans RHEL mais dans SLC.

Des problèmes sont apparus concernant des allocations de 4 GO ainsi que le log replay (dans la v2)

Storage Models

Castor: "Database centric" En production avec le scheduller LSF (test en cours avec Maui). Utilisation de gsiftp (rfio en interne). Pas de port de SRM V2 pour CASTOR 1. Ils ont repris les ACLs développés pour DPM. Déconseillé aux petits sites.

dCache : équipe de développement conséquente (à DESY principalement). On découple les "read polls" des "write pools". Ils ont un support de xrootd (mais avec perte des performances).

HPSS : introduction dans la nouvelle version d'un second niveau de bande. xrootd peux utiliser directement dCache à Lyon. 6 à 7 personnes pour la gestion sur site. Abandon des movers sur Solaris. gridftp bientôt supporté en natif ... HPSS est encore un service IBM il pourrait devenir un produit ...

TSM backend for dCache : GRIDKa utilise TSM comme backend pour dCache. Ils l'utilisent pour le SC4 sur des machines Linux et un SAN pour les bandes. Ils envisagent une solution du même type pour xrootd.

The High Energy Data Pump

Il s'agit de hardware dédié pour une majorité de site. FTS de gLite semble plus fiable et performant que Globus 4 RFT. Les services ne sont pas fiables.

Backup Technology

TSM (Tivoli Storage Manager) d'IBM a été porté sous GNU/Linux et supporte maintenant les versions récentes d'ACSLS (STK).

Présentation d'AMANDA, outil de BACKUP Open-Source utilisé à TRIUMF. Attention ce n'est pas une solution de backup pour T1 !

Storage Task Force

Le document est disponible sur le site web HEPiX. Il y a une recommendation de revoir les prix CPU et stockage. Attention aux échanges d'info ("Non disclosure agreement")

0S news (Linux and Windows)

Gestion de Windows au CERN : passage aux serveurs 64 bits, installation standard aussi pour "controls community"

Virtual server at CERN: prototype de service de création de serveurs à la demande (Linux et Windows). Démonstration intéressante.

Scientific Linux: SL 3.0.6 skipped. Travail en cours sur SL 4.3 et SL 3.0.7. Arrêt support itanium.

SLC : Ils n'avaient pas prévu qu'il y aurait autant de download en dehors du CERN. Kerberos V. Kernel spécifique (XFS, OpenAFS, ...). SGI ne semble pas très actif pour porter XFS sur RHEL 4 et 5 ...

Sécurité : Les attaques ont changé de nature. Le but est maintenant l'argent et les attaques sont plus ciblées et précises.

Conclusion : Il y a beaucoup de travail au niveau des infrastructures. Les benchmarks devraient être mis sur le site HEPiX. Les prochaines réunions sont prévues du 9 au 13 octobre à JLAB (Virginie), DESY au printemps 2007 et FNAL en automne 2007.

Récupérée de « http://lcg.in2p3.fr/wiki/index.php?title=HEPix-Rome&oldid=1600 »