NAGIOS dans un cluster de la grille EGEE Frédéric Schaer, CEA, IRFU

Définitions GRILLE Proxy : certificat x509 court sans mot de passe CE : passerelle pour jobs SE : passerelle de stockage ROC : Regional Operations Center GOC : Grid Operations Center WN : Worker Node, serveur de calcul

Limitations de la présentation Point de vue « en partie » opérations Point de vue « officieux » Site de grille spécifique : GRIF/CEA IRFU

Limitations de la présentation GRIF : Site « réparti », besoins spécifiques GRIF = Grille pour la Recherche en Ile de France CEA IRFU (Saclay) LLR (Polytechnique – Palaiseau) LAL (Orsay) IPNO (Orsay) APC (Paris 7, Bibliothèque François Mitterrand) LPNHE (Paris 5, Jussieu) Administration répartie Gestion/Installation « locale » des machines Accès root/sudo limité en commandes et en machines (notamment CEA) Monitoring global du site VLAN Grif, firewalls CNRS/CEA VLAN CEA (datagrid), VLANS d’administration CEA/CNRS

Besoins Spécifiques Grille Soumission de job Présence de « proxy » Environnement grille Système(s) d’Information Ldap – inventaire des nœuds et capacités XML (SSL) – downtimes Lien downtimes/LDAP

Besoins Spécifiques Grille Soumission de jobs : Output jusqu’à plusieurs heures après Scalabilité : Nombre de sites en production : 304 Nœuds monitorés centralement par site : environ 5 Requis : (CE|cream CE)/SE/sBDII Optionnels : MON/LFC/WMS/VOBOX Nombre de nœuds (y compris WN) par site : 1 à X000 Jobs monitoring envoyés : 1 par heure, pour environ 100KO d’output (évaluation) 152MO de données stockées par heure en BDD, disponibles en ligne, accédés par tous, gardés des semaines

Besoins Spécifiques Grille (Site) Monitoring views Status DES sites pour les VOs ? Status DU site pour les VOs ? Status des sites pour le projet ? Production monitoring Reporting

OUTILS Utilisés - EGEE SAM FCR

OUTILS Utilisés - EGEE SAM FCR GSTAT

OUTILS Utilisés - EGEE SAM FCR GSTAT GridMap

OUTILS Utilisés - EGEE SAM FCR GSTAT GridMap Dashboard …

OUTILS Utilisés - EGEE SAM FCR GSTAT GridMap Dashboard … NAGIOS !

Nagios EGEE Nagios standard recompilé 3 utilisations Affichage passif de tests  SAM/GSTAT/NETWORK Scheduling de tests Remontée de résulats Dépendances multiples Système d’autoconfiguration LDAP, config locale, accès SSL x509 Autoconfiguration nœuds, services MySQL Apache ActiveMQ (non activé) Librairies projet Manipulation/Synchronisation downtimes Wrapping de sondes

Nagios EGEE – ce qui est possible Tests actifs : services exposés évidents (serveurs) Cohérence du système d’information (GOC DB) Logs accessibles via gridftp Tests passifs Couches cachées via soumission d’un job – teste 1 nœud par site Soumission d’un transfert – teste 1 serveur de stockage par site

Nagios EGEE – la lente évolution Evolution forcée Départ du développeur SAM (scripts difficilement maintenables) Utilisation d’outils standards (enfin !) Lente et difficile il n’aura fallu que ~6 ans! Pas de contribution au logiciel libre PIRE : duplication Difficile pour cause de complexité surcouche Nagios CERN… Migration depuis plus d’un an, et pour encore… Un an? Difficile pour cause d’interopérabilité Intégration couche GRILLE à un nagios existant (cf 2 points ci-dessus) Dépendances exagérées Manque de documentation Aucune explication sur qui monitore quoi, comment, ou pourquoi. Surcouche opaque (cf 4 points ci-dessus)

Stratégie de monitoring EGEE EGEE3 aims at reducing the effort required to operate the infrastructure fully distribute responsibility for the daily operations to the ROC and the sites themselves effective monitoring of site services directed alarms to the responsible site and service site monitoring is one of the operational tools that have been identified to move to a regional distributed infrastructure With increased distribution of tools, interoperation becomes a challenge: it is proposed to use enterprise messaging technologies as a common mechanism for the interoperation of the various operational tools

Stratégie de monitoring EGEE Messaging as an integration paradigm (program-to-program communication with reliable delivery) A multilevel Monitoring Framework services are monitored at the site services are monitored from the ROC results are published at site, at regional and project level.

Résumé stratégie de monitoring EGEE (1)

Résumé stratégie de monitoring EGEE (2) NCG (Nagios Configuration Generator): generates a nagios configuration for a grid site using GOCDB and BDII

Historique – GRIF 2005-2006 : Lemon 2006-2007 : Lemon + Nagios Lemon pour les graphes système Nagios pour tous les nouveaux tests Nagios pour les notifications Nagios pour la « simplicité »

Historique - GRIF 2007-2008 : Nagios + Ganglia Ganglia, complément de nagios graphes système Disparition totale de Lemon trop dur à maintenir dépendances, backports CERN,… mises à jour problématiques Trop gourmand en ressources Trop dur à adapter aux nouveaux besoins

Historique - GRIF 2008-2009 : Nagios + nagiosgraph Regroupement des fonctionnalités NAGIOS+Ganglia --> Nagios Tests, compilation et mise en place (douloureuse) de nagiosgraph Dépendances RRD indisponibles dans Scientific Linux 4 Dépendances PHP indisponibles…

Architecture actuelle GRIF NRPE Check_XXX Check_YYY HOST1 LAL NRPE Check_XXX Check_YYY HOST2 LAL Routeur LAL VM 2 CPU 512 MB RAM 1 GB Ethernet HTTP Nagios IRFU Routeur IPNO Routeur LPNHE NRPE Check_XXX Check_YYY HOST1 LLR NRPE Check_XXX Check_YYY HOST2 LLR Routeur APC Routeur LLR NRPE Check_XXX Check_YYY HOST1 IRFU NRPE Check_XXX Check_YYY HOST2 IRFU web

Architecture actuelle GRIF Statistiques : 584 hôtes 8725 services actifs (34 services distincts) 27410 dépendances de service (nrpe…) Latence moyenne/max : 1.203s / 77.47s Charge de la machine virtuelle : Mémoire : 450MO (512MO physiques) CPU: 30% (2 CPU virtuels) Disque : 655MB, dont 597MB nagiosgraph (RRD) Réseau : 50kb/s en entrée, 45kb/s en sortie En 6jours : 27GB en entrée, 23 GB en sortie

Architecture actuelle GRIF Majorité de tests écris localement Un des plus utiles : filesystems qui passent read only Intégrés et déployés via RPM noarch Configuration générée et contrôlée : Base de configuration hardware « quattor » Langage de programmation descritif PAN Mise à jour NAGIOS automatique lors d’ajouts de machines Downtimes automatiques Déclarées dans une base de données grille (GOC) Récupérées par un test nagios Utilisation de downtimes « propagées » Une downtime sur un CE entraîne une downtime sur tous ses workers Complément de la logique réseau nagios

Architecture actuelle GRIF Nagios/NRPE/Nagios plugins recompilés et SPEFCILE patchés Pour autoriser déploiement sur SELinux Pour créer des comptes/groupes systèmes au lieux de comptes standard (collisions avec notre outil de déploiement) Patches envoyés sur listes nagios (mais ignorés :’( ) OS Supportés: SL4 32/64 SL5 64 Manque encore : Utilisation intelligente ET sécurisée d’event handlers Ex. : problèmes pour drainer WN, problèmes NFS temporaires Intégration de l’état SMART des disques Intégration IPMI …

Problèmes rencontrés Lenteur de l’interface web Interface downtimes Suppression multiple impossible Sélection multiple impossible # for down_id in `seq 1041 1725`; do echo "[`date +%s`] DEL_HOST_DOWNTIME;$down_id" >>/var/spool/nagios/nagios.cmd ; done Downtimes flexibles : # dt_start=`date -d "2009/11/09 16:50:00" +%s` ; dt_end=`date -d "2009/11/13 19:00:00" +%s` ; dt_long=$[$dt_end - $dt_start] ; for i in WN CE SE_DISK SE_DPM ; do echo "[`date +%s`] SCHEDULE_HOSTGROUP_HOST_DOWNTIME;$i;$dt_start;$dt_end;0;0;$dt_long;fred;reboot pour errata" >> /var/spool/nagios/nagios.cmd ; done

Problèmes rencontrés Lenteur de l’interface web Interface downtimes Suppression multiple impossible Sélection multiple impossible Commandes disponibles (cf include/common.h et cgi/cmd.c) : CMD_SCHEDULE_HOST_DOWNTIME CMD_SCHEDULE_SVC_DOWNTIME CMD_DEL_HOST_DOWNTIME CMD_DEL_SVC_DOWNTIME CMD_SCHEDULE_HOSTGROUP_HOST_DOWNTIME CMD_SCHEDULE_HOSTGROUP_SVC_DOWNTIME CMD_SCHEDULE_HOST_SVC_DOWNTIME CMD_SCHEDULE_SERVICEGROUP_HOST_DOWNTIME CMD_SCHEDULE_SERVICEGROUP_SVC_DOWNTIME CMD_SCHEDULE_AND_PROPAGATE_TRIGGERED_HOST_DOWNTIME CMD_SCHEDULE_AND_PROPAGATE_HOST_DOWNTIME # for down_id in `seq 1041 1725`; do echo "[`date +%s`] DEL_HOST_DOWNTIME;$down_id" >>/var/spool/nagios/nagios.cmd ; done # dt_start=`date -d "2009/11/09 16:50:00" +%s` ; dt_end=`date -d "2009/11/13 19:00:00" +%s` ; dt_long=$[$dt_end - $dt_start] ; for i in WN CE SE_DISK SE_DPM ; do echo "[`date +%s`] SCHEDULE_HOSTGROUP_HOST_DOWNTIME;$i;$dt_start;$dt_end;0;0;$dt_long;fred;reboot pour errata" >> /var/spool/nagios/nagios.cmd ; done

Problèmes rencontrés Salves de mails Atténuées via relations parents/enfants Mais tests réseau et/ou perte partielle de paquets… Lorsque des admins redémarrent des serveurs sans downtime Downtime électrique/réseau sur site hébergeur Pas de redondance Perte des VM (crash disks) Peu d’incidence, grâce à la config générée Temps requis !! Ecrire un (bon) test prend du temps Déterminer quoi monitorer et comment prend du temps

Avenir de Nagios dans GRIF Serveurs multiples Redondance Répartition de charge système/réseau pnp4nagios + ninja ? Nagiosgraph n’est pas « admin-friendly » Pnp4nagios utilisé dans le nagios EGEE

Conclusion Ce que permet nagios dans GRIF et la grille : (parfois) détecter des crashs imprévus Une erreur peut en cacher une autre Détecter et pérenniser les connaissances sur les erreurs que nous ne pouvons empêcher Chaque crash requiert une analyse autant éviter de renouveler ces analyses Avoir un point de vue global sur la santé de l’infrastructure Gagner du temps !!! Ce que ne permet pas Nagios La haute disponibilité