Difference between revisions of "HEPix-Rome"
(→Batch Systems: + Expériences LHC) |
(→Tape and disk hardware, storage interconnects and protocols: + FS Linux) |
||
| Ligne 63: | Ligne 63: | ||
=====Optimisation and bottlenecks===== | =====Optimisation and bottlenecks===== | ||
=====Tape and disk hardware, storage interconnects and protocols===== | =====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===== | =====Storage Models===== | ||
=====The High Energy Data Pump===== | =====The High Energy Data Pump===== | ||
=====Storage Task Force===== | =====Storage Task Force===== | ||
=====0S news (Linux and Windows)===== | =====0S news (Linux and Windows)===== | ||
Version du 08:00, 20 avril 2006
Résumé des temps forts HEPix - Rome
- Agenda : http://hepix.caspur.it/spring2006/agenda.php
- Résumé de conclusions A.Silverman / A.Silverman report : http://hepix.caspur.it/spring2006/TALKS/18apr.silverman.hepixconcl.pdf
- Contributions : F.Chollet, J. Devémy
Sommaire
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 SpecInt200 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 :
- Sites : http://hepix.caspur.it/spring2006/TALKS/3apr.jouvin.lal-siterep.ppt
- Dernier achat : 12 Opteron (dual CPU, dual core) avec lesquels il rencontre des problèmes de driver réseau pour permettre le boot réseau - Carte PCI express BCM 5700 non supportée.
- Cible 2008
- CPU : 3000 kSI2K (opteron 2.2 GHz 1,5 kSI2K)
- Disque : 700 TB
- Maintenant: CPUs 130 CPUs soit 200 kiSI2K
- Storage 50 TB
- Site Quattor : http://trac.lal.in2p3.fr/LCGQWG
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).
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-ceours 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)
Network technologies
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.
- ATLAS :
- 1GB de RAM par job
- Les physiciens veulent voir la grille comme un Scheduler de Batch local
- CMS :
- 3 ou 4 limites CPU différentes
- 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)
