Incidents et problèmes des VOs (CC, sites français, autres sites)

• Tous

Room: 322 Sujets Stockage: ------------------- HPSS ==== * Point sur la reconfiguration suite au démontage d'un robot : - Toute les bandes 9840 on été transférés dans le 3eme SL8500 - 12 lecteurs sont disponibles pour les bandes 9840 - Toute les bandes 9940 on été transférés dans un seul silo 9310 - 19 lecteurs sont disponibles pour les bandes 9940 * Les bandes 9940 restantes (principalement Babar ) sont en cours de migration vers les T10K * Le gros de l'activité de montage bande se fait sur les bandes T10k, hors il n'y a que 33 lecteurs disponibles. Lors de forte activité, il est courant que HPSS ne dispose pas d'assez de lecteurs pour servir toutes les requêtes. Cette situation ne s'arrangera pas tant que l'on n'aura pas migré en version 6.2 (pour utiliser les T10K b) * Du cache disque à été rajouté afin de palier le manque de lecteur - Subsystem 1 (non grille) + 4 To dans le COS 11 (64-512Mo) - Subsystem 2 (atlas , alice) + 4 To dans le COS 11 (64-512Mo) + 8 To dans le COS 12 (512Mo-8Go) - Subsystem 2 (cms, lhcb) + 4 To dans le COS 11 (64-512Mo) + 8 To dans le COS 12 (512Mo-8Go) Sujets Exploitation: ------------------------ - mise en production de la 3eme SL le 10/12 avec deplacement de ~19700 volumes 9840. Tout s'est bien (vite) passé, HPSS a redemarré en fin d'apres-midi. - beaucoup de problemes dCache (voir mail de Lionel) - mise en place des "Shares" pour lhcb vendredi dernier, pas de distinction T1/T2 : admin:lhcb@anastasie 1 COMMON:lhcb@anastasie 5 pilot:lhcb@anastasie 90 prod:lhcb@anastasie 4 bqsprod:lhcb.usage lhcb050.lhcb@- lhcb100.lhcb@- bqspilot:lhcb.usage lhcb049.lhcb@- lhcb099.lhcb@- bqsadmin:lhcb.usage lhcbgrid.lhcb@- lhcbgrid : jobs avec priorite de groupe=11 et limité a 10 jobs en execution. Sujets Support: ------------------- - ATLAS: * Les problèmes de dcache ont impacté fortement l'activité, d'autant plus que depuis le mercredi 10 décembre, il y a des test de transferts en cours: (Transferts de tous les T1 vers tous les T1). Au niveau de Atlas, le T1 est vu comme pratiquement down du point de vue de ces tests. Les tests se sont arrêtés dans la matinée car 3 T1 posaient problème: Lyon, Ral et Taïwan. * Des tests de jobs d'analyse d'utilisateurs sont en cours pour evaluer l'efficacité avec laquelle un utilisateur peut faire son analyse. Analyse du test en cours. CMS report ********** The dCache/SRM issues since this week causes the following problems: * Stop almost of all down and up data to CCINEP3. * High impact on the re-processing jobs. We have been chosen to run a very high number of reprocessing jobs that was expected to finish this week, but unfortunately due to the dcache issues (+ some cleanup issue on prod pools) and their persist since this weekend the goal will be difficult to achieve. LHCb === L'état de dCache a impacté égalment LHCb, car les fichiers dans ccdcatsn020 ne sont pas accessibles depuis vendredi soir. Par conséquence, il n'y a pas de jobs qui tournent sur notre T1. Malgré ça, la situation n'est pas trop critique, car la plupart de l'activité de LHCb tourne actuellement sur le T2. AT Grille généralement: ---------------------------- - CE, BDII, VOMS... * Disparition du topBDII - SE, FTS, LFC, SRM, dCache * Incidents: ******* - Depuis le 13/12 au matin, les CEs du CC sont régulièrement, si ce n'est continuellement, en erreur sur des tests critiques (CE-sft-lcg-rm). Majoritairement, c'est dû aux difficultés rencontrées sur le SE Dcache ccsrm. Et durant la nuit de lundi à mardi, au pb de Top BDII (Cf. ci-dessous). - Le 15/12 à 17h, un sysadmin a "takeouté" les Top BDII load-balancés, l'alias ne répondait donc plus au ping. Ca a été rétabli ce matin à 6:30. Pendnat tout ce temps, une partie des sites français étaient en erreur, et les jobs sur ces sites devaient planter sur les commandes lcg-* - Le 15/12 vers 19:00, le CE cclcgceli06 a planté. La panne a été détecté ce matin. Le CE a été redémarré dans la foulée. - Le LFC de Biomed continue a avoir des problèmes à cause de "mauvaises requêtes" (mauvaise version de GFAL sur certains sites). Passage du problème à SA1 Management. * Bilan de l'arrêt du 2 décembre *********************** - Arrêt du "2 décembre": * durée effective pour la grille: du 01/12 8:00 au 3/12 18:00 * déroulement: - un "Mic-Mat" dans l'arrêt électrique des machines. Entre autres, le Top BDII régional a été out qques heures, le LFC central de Biomed, etc. - Upgrade firmware de toutes les x3550 (avec reboot). - Renommage des logins et réutilisation d'autres pour déploiement de VOs Erreur de syntaxe dans le fichier (Pierre). Correction au dernier moment et repropagation par les sysadmins. => Réduction du login à 8 caractères: biomed[001-100] -> biome[001-100] egeode[001-100] -> egeod[001-100] votmpgrid -> votmpgrd => Réutilisation de comptes/groupes dapnia -> irfu (Dapnia devient Irfu) planck -> training (Déploiement de la VO vo.formation.idgrilles.fr) => Split du pool de dteam entre dteam and ops dteam[001-100] -> dteam[001-050] + ops[001-050] - Redémarrage des CEs le 3/12 à 16:00 * SAM tests dans le rouge à cause d'un pb dans le LDIF dans l'information provider => Bug corrigé à la volée (pas d'impact) * Puis SAM tests dans le rouge qd soumis depuis la SAM admin page car ccsrm attendait le rôle VOMS lcgadmin. => Reconfiguration par Lionel pour autoriser tout OPS => Contact de Rafal Lichwala pour qu'il mette le rôle lcgadmin à son niveau (c'était en fait un bug dans son code) * La soumission ne marchait pas sur certains CEs car le bqsd était "anormalement" arrêté. * Bilan: (en bref, un peu chaotique) - Le travail de préparation (planning et liste des machines à ne pas arrêter) n'a pas été très fructueux. Effort vain en partie donc. - Sous-dimenssionnement du SD => Prévoir d'emblée un SD 24h avant l'arrêt et au moins jusqu'au midi le lendemain, car la grille dépend du redémarrage de tous. Il vaut mieux raccourcir un SD plutôt que l'augmenter. - Prévoir le monitoring de bqsd/danmonitor, et un script de redémarrage si besoin, notamment lors de la réouverture des CEs. - Il est peut-être mieux d'utiliser systématiquement une infrastructure de failover (machines virtuelles) pour les machines critiques lorsque des arrêts importants sont prévus. Mais ça suppose un travail avant, et demande donc du temps. * Autres: ***** - Autre déploiement (en fin de semaine dernière) * Validation du déploiement de la VO vo.irfu.cea.fr par C. Leroy. * A la demande LHCB, mise en place d'un mapping pour /lhcb/Role=pilot avec un share de 90%. Sur T1 (lhcb049) et T2 (lhcb099). - Pb de monitoring CMS sur le T2 lié à l'expiration de proxy * trop de jobs avec le rôle production en queue, du coup les jobs de monitoring restaient trop longtemps en queue. Le share pour ce rôle sur le T2 a été augmenté. - Discussion à prévoir avec le support pour la politique du rootacc sur les VO Boxes. => proposition de simplifier la politique actuelle => autoriser le rootacc sur toutes les VO Boxes pour tout le support (ou sous-groupe)

Charge et événements prévisibles pour la fin d'année

• Tous

Room: 322 Demandes de production, annonces de transfert, data challenges, arrêts, installations, ... Tout cela uniquement s'il y a un intérêt général. Aussi: des nouvelles des projets Grille, encore uniquement s'il y a un intérêt général.

Nouvelles des équipes du CC

• Un membre de chaque équipe

Room: 322 Sujets par équipe, avec un impact potentiel sur l'exploitation. Nouvel arrivant Marcos Lins à partir du 15/1/2009 (équipe Développement) Nouvelles des embauches

Etat des projets Grille Room: 322 - EGEE (Pierre) - EGI-DS (Rolf) - IdG (Rolf, Virginie, Yonny) - LCG (Pierre) - Grille régionale (Yonny) et projets en préparation, le cas échéant.

Nouvelles des coopérations Room: 322

Affaires administratives Room: 322 - Missions et absences jusqu'au début janvier

Divers Room: 322