1 / 31

NAGIOS dans un cluster de la grille EGEE

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

gaura
Download Presentation

NAGIOS dans un cluster de la grille EGEE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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é

More Related