Choisissez le fuseau horaire
Le fuseau horaire de votre profil:
Réunion jointe Opération + AT Grille
→
Europe/Paris
322 (IN2P3)
322
IN2P3
Description
Réunion en deux parties:
1. Opération site CCIN2P3
Participants: représentants de l'exploitation, du support et d'autres selon ordre du jour,
plus ceux de la réunion AT Grille habituelle.
2. AT Grille
Participants: ceux de la réunion AT Grille habituelle.
SP, PG, YC, AG, HC
Faire un point la semaine prochaine sur
- Les utilisateurs des groupes Antares et km3net, ne peuvent plus passer d'un groupe à l'autre.
La commande newgroup doit être désactivée pour Antares et pas pour les autres. SP doit voir avec Loïc.
- PG note que le daemon du LFC des VO regionales (dont cta) est redémarré régulièrement doit doit voir avec DB et OA.
-le compte xrdmgr ne semble plus avoir les droits nécessaires pour lire les fichiers de certains groupes du style babar, hess etc... qui ont leurs fichiers protégés en lecture pour les utilisateurs qui ne font pas partie de leur groupe (xrdmgr qui tourne les démons xrootd est membre d'un certains nbre de groupes dans HPSS). SP doit voir avec JYN d'où peut provenir le problème d'accès.
- PG doit voir avec CB si le symptome de proxy renewal sur cclcgatlas04 provient du server Myproxy.
Sujets Exploitation+Stockage:
----------------------------------
- Suite aux travaux d'installation des racks réfrigérés, nous sommes toujours a 61% de notre capacité de calcul, j'attends des informations sur le retour éventuel de machines.
SP precise que 240 machines DELL nouvelle génération dans les racks réfrigérés+ idataplex = 60% de la capacité de calcul.
+ 3 racks (100 machines) et 1 rack (SL5) à partir du 22/07/09
- hpss : beaucoup d'incidents sur les lecteurs (surtout les T10KB).
les serveurs rfio sont toujours très instables.
ras
- incident en cours pour l'accès aux fichiers dans hpss via xrootd :
le compte xrdmgr ne semble plus avoir les droits nécessaires pour lire les fichiers de certains groupes du style babar, hess etc... qui ont leurs fichiers protégés en lecture pour les utilisateurs qui ne font pas partie de leur groupe (xrdmgr qui tourne les démons xrootd est membre d'un certains nbre de groupes dans HPSS).
affaire à suivre...
semblerait être réglé : incident ponctuel sauf que les problèmes de changements de droits semblent obscur. SP doit relancer JYves Nief et HC doit l'enregistrer dans les pbs récurrents des VOs.
- beaucoup de jobs "slow" pour cmsf le 17/07 : problème de soft cmsf
- beaucoup de jobs "slow" pour atlas ce weekend : utilisation d'une nouvelle version de soft, version non répliquée. Apparemment atlas ne respecte pas la procédure mise en place par Xavier (cf mail de Fabien).
en cours dans une réunion entre afsmaster, l'exploitation et le support atlas prévue le 22/07/09.
- un rack de worker en SL5 est accessible dans la ferme anastasie. Pierre travaille sur la mise a disposition d'un CE poursoumettre des jobs grille sur ces machines.
Sujets Support:
-------------------
ATLAS
-------
* VO box cclcgatlas04 jobs unsubmitted - RESOLU
- problemes pour envoyer des pilotes a partir de cclcgatlas04 : les jobs restent dans l'etat unsubmitted indefiniement
- probleme resolu avec l'addition d'un parametre de configuration qui permet d'envoyer plus de jobs aux CEs
GRIDMANAGER_MAX_SUBMITTED_JOBS_PER_RESOURCE=5000
pour plus de details : http://cctools2.in2p3.fr/elog/support-atlas/70
Problemes-VO#94 : PG pense que même si la VO box d'Atlas redevient centralisée au CERN; en attendant, les particularités que demande Atlas requiert de l'expertise spécifique(condor). Il faut clarifier le mécanisme "générique" de la VO Box et s'assurer de la disponibilité d'experts en cas de personnalisation.
Est-ce que le fait de ne plus avoir de VO Box en France sera validé ? Atlas a une "vieille" VO Box (SL3, glite3.0). Il faudrait une seconde nouvelle "VO Box", à valider mid-septembre : modalités d'installation, de maintenance, d'utilisation de ces prototypes selon une demande de précision à Atlas-FR sur la politique des VO box, si non confirmation de la centralisation des VO Box à ce moment là (PG doit poser le pb au CAF de Septembre selon le retour d'Atlas-FR).
* installation automatique des releases - EN COURS
- des incidents de surcharge afs par des jobs attaquant des volumes non repliques sont reccurents
- non replication car pas de demande explicite du cote de ATLAS et la procedure automatique d'installation des releases pas en production.
réunion du 22/07/09 à 14:00.
* reprocessing de donnees cosmiques (mercredi 8 juillet -> jeudi 16 juillet) - FINI
- ce reprocessing n'etait pas un exercice;
- nous avons fait un assez mauvais reprocessing (nous avons processe moins de la moitie des jobs qui nous etaient attribues au total, le reste des jobs ayant ete redistribues au fur et a mesure a d'autres T1s car nous etions lents)
- analyse succinte de la lenteur : nous avons eu un probleme avec TReqS des le debut du reprocessing, celui-ci ainsi
sans doute que d'autres problemes (pools pleins avec fichiers sticky) ont engorges le systeme et tres peu de lots de
fichiers ont ete prestages les premieres jours du reprocessing. ATLAS a en quelque sorte recommence les staging de zero le dimanche soir et cela a desengorge le systeme petit a petit. Mais cette action a pu avoir des effets de bord dont nous ne sommes par certains. A ne pas prendre donc comme une recette miracle.
- un probleme moins impactant mais embetant : des bandes contenant des fichiers pour le reprocessing etaient "bloquees"
et les fichiers ont ete demandes jusqu'a plus de 20 fois sans warning.
pour plus de details : http://cctools2.in2p3.fr/elog/support-atlas/74
Vu le nombre de blocages débloqués par l'exploitation, l'exploitation se demande si hpss a un mécanisme de blocage automatique ( 30 bandes bloquées). La commande qui liste les bandes bloquées est récente. la liste de bandes bloquées sera sous surveillance à partir de maintenant. Andres rajoute les logs d'HPSS de lock bandes et lecteurs automatiquement.
TyReqs ne semble pas être en cause.
* VO box cclcgatlas04 renewal de proxy - EN COURS
- probleme d'instabilite dans le mecanisme de renewal de proxy rapporte la semaine derniere par les utilisateurs de cette VO box
- probleme remonte a Pierre Girard
PG doit voir avec CB si le symptome provient du server Myproxy.
CMS:
------
- No issue to report, everything run smoothly last week
- Excellent site readiness and availability (please see attached plots)
- More than 1300 slow jobs appeared at CCIN2P3. It turn out that the slowness of the jobs is due to the use of the CMSSW release 3_X_X.
CMS investigue.
-Dashboard shows more than 15000 failed jobs at CCIN2P3 due to the application problem.
cf les jobs slow cmsf -- la ressource est bloquée. doit être débloquée.
- To prepare for importing from CERN, the pool buffer was increased to 60TB to accommodate the 142TB of the incoming custodial data of Cosmic.
- For the current backfill test, Treqs was integrated into the disk pools from where the jobs get their output. So, once the job ask for it input Treqs take care of staging it from PHSS. Treqs is used automatically to pre-stage the files to serve them to the jobs. This activity is overlapping with many other LHC VOs activities, that use Treqs too integrated to thier hosting data disk pools.
Il y a moins de montage de bande grâce à TyReqs. Mais le server TyReqs semble redémarrer régulièrement. Yvan doit le signaler à Jonathan via l'elog dcache.
- The exporting data to T2 and T1 is suffering from the known Timeout issue. This issue will be fixed by integration of Treqs into the disk pools that host the data that will be exported our of CCIN2P3. The activation of the Treqs will be done via Phedex stager agent. We will test this scenario in September.
Le pre-staging doit être éffectué par srm-bring-online d'où les timeout puique la commande n'est pas utilisée dans les jobs.
Problèmes récurrents:
-------------------------
LhCB ras.
Alice ras
AT Grille généralement:
----------------------------
- CE, BDII, VOMS...
PG a déclaré le nouveau celi08 - sl5 - en prod le 20/0. Atlas a lancé des jobs d'installation de façon systématique. SP note que les Sam tests sur le celi08 sont toujours en erreur malgré le decomissioning de 9h20. erreur sur le dashboard à remonter mais il apparaît que c'est l'affaire de SAM ( ticket GGUS ouvert).
- SE, FTS, LFC, SRM, dCache
PG note que le daemon du LFC des VO regionales (dont cta) est redémarré régulièrement, PG doit voir avec DB et OA.
Il y a un compte-rendu associé à cet événement.
Les afficher.
