NAGIOS dans un cluster de la grille EGEE

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

2. 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

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

4. 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

5. 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

6. 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

7. 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

8. OUTILS Utilisés - EGEE • SAM • FCR

9. OUTILS Utilisés - EGEE • SAM • FCR • GSTAT

10. OUTILS Utilisés - EGEE • SAM • FCR • GSTAT • GridMap

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

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

13. 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

14. 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

15. 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)

16. 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

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

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

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

20. 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é »

21. 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

22. 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…

23. Architecture actuelle GRIF web

24. 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

25. Architecture actuelle GRIF • Majorité de tests écris localement • Un des plus utiles : filesystems qui passent readonly • 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 automatiquelors 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

26. 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’eventhandlers • Ex. : problèmes pour drainer WN, problèmes NFS temporaires • Intégration de l’état SMART des disques • Intégration IPMI • …

27. 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

28. Problèmes rencontrés • Lenteur de l’interface web • Interface downtimes • Suppression multiple impossible • Sélection multiple impossible Commandes disponibles (cfinclude/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

29. 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

30. 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

31. 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é