Cécile Barbier David Bouvet Christine Leroy L'exploitation de la grille au quotidien

Plan Introduction Surveillance, "accounting", tickets et suivi des incidents, opérateurs de la grille Questions

Introduction Les outils Opérationnels pour la grille et leurs intéractions Information sur les ressources: GOCDB Monitoring: SAM/gstat/Nagios Accounting: Apel, accounting portal User support: GGUS Suivi de tickets: Dashboard EGI impose une régionalisation de ces outils: quelles implications?

Surveillance,

Actuellement surveiller son site = collectionner les onglets Plusieurs outils/sources de monitoring Local: nagios ou script VO: Dashboard Grille: SAM,gstat 1) Surveiller son site grille aujourd’hui

La présentation / l’échange/ la corrélation des données de monitoring restent les challenges majeurs du monitoring d’une grille  Liés aux opérations: Qui à la charge de surveiller?  Ne pas oublier les utilisateurs  Solutions choisies par EGEE:  Nagios: site monitoring; regional monitoring; gStat; and project and regional Metric Stores  MSG (Messaging System for Grids) :  ActiveMQ (Messaging System)  WLCG Format (Format des données)  Django (Django, a python based development framework, is used in the Metric Description DB, Aggregated Topology Provider, Worker Node configuration system, Metric Results Store and the WLCG Topology Provider) 2) Surveiller son site demain, vue OAT

"accounting",

Portail hébergé à CESGA : En France : mise à jour de la base APEL via la couche de transport R-GMA puis envoi des données au GOC (quelques soucis) envoi des données nominatives autorisé suite à la déclaration CNIL n° du 20/08/09 Wiki LCG-FR/SA1-FR Accounting WG Wiki LCG-FR/SA1-FR Accounting WG 1) L’accounting de la grille aujourd’hui

European Middleware Initiative (EMI) : Standardization efforts (RUS, UR) et harmonisation du logiciel à partir de ARC, gLite et UNICORE Usage Record (UR) WG Objectif : définir un format commun (basé sur l’actuel) pour les enregistrements pour que les sites puissent partager leur données d’accounting Resource Usage Service (RUS) WG Objectif : définir et développer une interface pour comptabiliser l’usage des ressources mais sans se préoccuper de l’aspect facturation ActiveMQ va remplacer Relational Grid Monitoring Architecture (R-GMA) d’ici fin 2009 pour les 1ers sites Nouvelle architecture pour le GOCDB L’acronyme ADC (Accounting Data Center) remplace GOC (Grid Operations Centre) dans les documents du Joint Security Policy Group (JSPG) Main Challenges for EGI: Storage Accounting Local job Accounting NGI Accounting Portal (nouvelles fonctionnalités au niveau du portail EGEE) 2) L’accounting demain dans EGI

Suite aux soucis de publication des derniers mois avec R-GMA, le CC va envoyer des résumés de consommation directement dans la GOCDB. Quand ActiveMQ sera opérationnel, un client fera de même. Quelle solution en France dans le futur ? Type 3 : Repository régional (avec portail web) au CC extensible à toute la France Type 2 : Les sites autres que le CC ne changent rien à leur fonctionnement actuel 3) L’accounting demain en France

tickets et suivi des incidents, opérateurs de la grille

1) Opération de la grille Actuellement : mode régional avec une fine couche centrale qui fait le lien avec le projet surveillance des sites via le dashboard régional pour les test de la VO OPS suivi des tickets opérations avec procédure d’escalation pas de surveillance des tests spécifiques des VO probablement à venir mais uniquement pour les VO LHC Transition vers EGI : fin 2009/début 2010 : mise à disposition d’un package du dashboard régional basé pour les tests Nagios pour les NGI

2) La NGI française et les opérations ? Les opérations pour les VO LHC oui, mais et les autres ? La NGI française aura besoin d'indicateur opérationnel pour toutes les VO Besoin de discussion avec les sites et les VO régionales sur les procédures opérationnelles à mettre en œuvre modèle des procédures WLCG ou autre ? Nécessité de créer des sondes spécifiques aux VO régionales intégrer les VO au groupe monitoring Mise en place d’un dashboard national spécifique nécessité de récupérer les alarmes en provenance du Nagios régional pour la soumission et le suivi des tickets ⇒ besoin d’un système de ticket national

3) Les incidents et leur suivi Besoin d’un système de ticket (pas seulement pour les opérations) point d’entrée unique pour la soumission d’incident de la grille française assignation site, VO interfaçage avec GGUS (ticket VO LHC) interfaçage avec le système de tickets global à EGI (si ≠ de GGUS) pour les core services transNGI Utilisation de GGUS en tant qu’helpdesk national probablement difficile ⇒ système de ticket national : définition du workflow des tickets, qui héberge/gère le service ? Manpower ? équipe pour les opérations équipe pour la gestion des tickets utilisateur  intégrée à l’équipe monitoring ?

Questions

Quelle est la suite de l’OAT dans EGI: un nouveau projet européen pour le développement d’outils d'exploitation? Qui participera à ces développements (à la fois sonde nagios et outils d'exploitation gocdb/dashboard…), sur quel fond? Comment se coordonner avec ce nouveau projet: est-ce que le groupe monitoring répond à ces attentes? La gestion de l'infrastructure de monitoring sous jacente ainsi que l'interopérabilité sont aussi des challenges auxquels nous devons répondre: Combien de serveurs mettra-t-on en France, qui les gèrera ? nos serveurs de messagerie Français seront-ils interopérables avec les serveurs d'autres NGI? Problème de manpower: Aujourd’hui les membres du groupe monitoring ont N tâches en plus du monitoring: des embauches sont elles prévues? En plus de nouvelles embauches nécessaires, on peut peut-être optimiser les choses: Aujourd’hui sur chacun des sites une personne doit régulièrement regarder les différentes sources de monitoring pour connaitre l’état de son site et régler les problèmes; est-ce que demain on peut envisager une équipe monitoring pour surveiller l’état de tous les sites: spécialiser les personnes, plutôt que de les rendre multitâche? Est-ce souhaitable? Exemple du GRIF: ou il y a un monitoring local commun et possibilité de régler les problèmes via des connexion par gsissh Exemple du RCOD: ou David et Cyril Gère les tickets pour la France. D’autres idées? Quelle solution d’accounting en France dans le futur ? Type 3 : Repository régional (avec portail web) au CC extensible à toute la France Type 2 : Les sites autres que le CC ne changent rien à leur fonctionnement actuel définir les opérations dans la NGI française quel outil et quelle procédure pour ces opérations ? quel système de tickets pour la NGI ? Manpower ? équipe pour les opérations équipe pour la gestion des tickets utilisateur => intégrée à l’équipe monitoring ? Questions / débats