Rapport. Stage de 2 ème année

Transcription

1 Institut S Informatique de Modélisation et de leurs Applications Campus des Cézeaux BP Aubière Cedex, FRANCE Organisation Européenne pour la Recherche Nucléaire CERN CH-1211 Genève 23, SUISSE Rapport Stage de 2 ème année Filière CERN-THESIS /08/2014 Présenté par: Driss El MAJDOUBI Responsables CERN: Christophe HAEN, Loïc BRARDA Responsable ISIMA : Emmanuel MESNARD Date de soutenance : Durée du stage : 5 mois

2 Remerciements Je Loïc BRARDA, tout au long du stage. Je remercie également pour avoir porté un intérêt à mon travail. Par la même occasion, je tiens à remercier M. Emmanuel MESNARD A pour son encadrement judicieux. Un grand merci à toutes les personnes de bonne volonté, ayant contribuées de près ou de loin à la réalisation de ce projet. pour avoir accepté de juger mon travail. i

3 Table des figures et illustrations Figure 1: Tunnel LHC [Haen 2013]... 3 Figure 2: Fonctionnement du LHC [Haen 2013]... 4 Figure 3: Quark B... 5 Figure 4: détecteur LHCb... 6 Figure 5: Représentation de la structure du réseau LHCb Online... 7 Figure 6: Principe de fonctionnement de la supervision Figure 7: Infrastructure de supervision Icinga 1.x [Haen, Bonaccorsi et Neufeld 2011] Figure 8: Extrait de l'arbre logique de configuration Icinga 1.x [Haen, Bonaccorsi et Neufeld 2011] 13 Figure 9: Planning prévisionnel du stage Figure 10: Logo Icinga Figure 11: Architecture de Icinga Figure 12: La supervision distribuée basée sur la fonctionnalité cluster Figure 13: Schéma réseau de l'atelier Figure 14: Digramme d'héritage des "Templates" des hôtes Figure 15: Diagramme des "Host Group" fonctionnels Figure 16: Digramme des "Host Group" logique Figure 17: Digramme des services Figure 18: Diagramme des dépendances Figure 19: Mécanisme d'exécution des plugins Figure 20: Page d'authentification Icinga-web Figure 21: Interface des états des hôtes Figure 22: Interface des états des services Figure 23: Interface des groupes des hôtes Figure 24: Dépendance du switch_ux Figure 25: Logo Puppet Figure 26: Architecture client/serveur de Puppet Figure 27: Fonctionnement de Puppet Figure 28: Extrait du diagramme des "Templates" Figure 29: Fonctionnement du NRPE Figure 30: Fonctionnement des vérifications directes Figure 31: Fonctionnement des vérifications indirectes Figure 32: Extrait des hôtes en état "UP" ii

4 Figure 33: Extrait des hôtes en état "DOWN" Figure 34: Extrait des différents états des services Figure 35: Graphe des statistiques Figure 36: Extrait des groupes "hostgroup" Figure 37: Processus de configuration Puppet-Foreman Figure 38: Interface web Foreman Figure 39: Extrait des facts sur Foreman iii

5 Résumé Le présent document constitue le fruit de mon travail dans le cadre du stage de deuxième place une nouvelle infrastructure de Icinga 2 possible à Puppet le nouveau système de gestion de configuration des serveurs. Durant mon stage, remière étape de dialoguer avec les étais amené à bien comprendre les concepts de base 2 ainsi que ceux du Puppet avant de passer à la mise en place de la solution complète de supervision. Mots clés : Supervision, Icinga 2, Puppet, LHCb Online, Gestion de configuration. iv

6 Abstract This document is the result of my work during the second year internship, realized within the European Organization for Nuclear Research (CERN). The goal of this internship is to design and setup a new monitoring infrastructure based on Icinga 2 tool and integrate it as much as possible to a new configuration management tool, Puppet. During this internship, the first step of my mission was to interact with members of the LHCb Online team to have an overview of the system. Then I had to understand the basic concepts of Icinga 2 as well as those of Puppet before proceeding to the implementation of the complete monitoring solution. Keywords: monitoring, configuration management, Icinga2, Puppet, LHCb Online. v

7 Tables des matières Remerciements... i Table des figures et illustrations... ii Résumé...iv Abstract... v Tables des matières...vi Lexique / Liste des abréviations... viii Introduction Présentation du cadre du stage Présentation générale CERN (Organisation Européenne pour la Recherche Nucléaire) LHC (Large Hadron Collider) Système LHCb Online La supervision Etude du système de supervision actuel Solution proposée Cahier des charges Planification prévisionnelle Etude et tests des outils choisis Icinga 2: solution de supervision des réseaux Icinga2: définition Icinga 2: spécificités techniques [Icinga2 2014] vi

8 2.2.1 Installation de Icinga Installation du module DB IDO (Database Icinga Data Output) Installation des interfaces graphiques Les fichiers de configuration de base Atelier de tests Implémentation de la configuration et résultats des tests Puppet : solution de gestion des configurations Puppet : définition Fonctionnement et caractéristiques de Puppet : Installation de Icinga 2 par Puppet e système LHCb Online Présentation du système à superviser Conception de la configuration du système de supervision Implémentation de la configuration Agent NRPE (Nagios Remote Plugin Executor) NAN (Nagios Notifications Daemon) Résultats de supervision du système LHCb Online Discussion des résultats Automatisation de la configuration par Puppet Analyse du problème Solution proposée Conclusion Références bibliographiques... ix Webographie... ix Annexe A... xii Annexe B... xiii vii

9 Lexique / Liste des abréviations Abréviation Désignation ALICE A Large Ion Collider Experiment ATLAS A Toroidal LHC ApparatuS CERN Organisation Européenne pour la Recherche Nucléaire CMS Compact Muon Solenoid DAQ Data AcQuisition DB IDO Database Icinga Data Output DIM Distributed Information Management System DNS Domain Name Server HLT High Level Trigger GPL General Public License LHC Large Hadron Collider LHCb Large Hadron Collider beauty NAN Nagios Notifications Daemon NRPE Nagios Remote Plugin Executor RHEL Red Hat Entreprise Linux SCADA Supervisory Control and Data Acquisition SLC 6 Scientific Linux CERN 6 SQL Structred Query Language SSH Secure Shell XML extensible Markup Language viii

10 Introduction Dans le cadre du stage de ma deux durant la période du stage était de mettre en place un système de supervision et de un système de supervision capable de réagir dans les minutes qui suivent à un incident sur LHCb utilisait une installation particulièrement complexe de Icinga 1.8 pour la supervision du fonctionnement et la gestion des alarmes. inscrivait tte évolution concernait le système de gestion de configuration des serveurs en utilisant Puppet, ainsi qu supervision basée sur Icinga 2.. Ce rapport se propose de découvrir les spécifications de ce stage à travers une présentation générale du contexte du stage, une analyse détaillée du problème ainsi 1

11 1. Présentation du cadre du stage Ce chapitre se focalise sur la présent roblématique de mon sujet et on présentera la solution adoptée pour ce dernier. 1.1 Présentation générale CERN (Organisation Européenne pour la Recherche Nucléaire) En 1952, un ensemble de 11 gouvernements européens décident de créer un Conseil Européen pour la Recherche Nucléaire (CERN) dans le petit village de Meyrin dans le canton de Genève, près de la frontière franco-suisse. Le 29 septembre 1954, la convention du CERN est ratifiée par 12 États européens, le CERN est officiellement créé et se nomme maintenant Organisation Européenne pour la Recherche Nucléaire. e CERN emploie environ 2500 personnes. Le personnel scientifique et technique du laboratoire conçoit et construit les accélérateurs de particules et assure leur bon scientifiques complexes, ainsi qu à l analyse et à l interprétation des résultats. Environ 8000 scientifiques visiteurs, soit la moitié des physiciens des particules du monde, viennent au CERN pour faire des recherches. 580 universités et 85 nationalités sont représentées [CERN_homepage 2014] LHC (Large Hadron Collider) Le Grand Collisionneur de Hadrons au CERN (Figure 1) est un gigantesque instrument scientifique situé près de Genève, sur la frontière franco-suisse, à environ 100 mètres sous nviron 27 kilomètres de circonférence, avec lequel les physiciens étudient les plus petites particules connues : les composants fondamentaux de la matière [LHC 2007]. 2

12 Figure 1: Tunnel LHC [Haen 2013] Deux faisceaux de particules (Figure 2) subatomiques de la famille des «hadrons» (des deux faisceaux à une vitesse proche de celle de la lumière et à de très hautes énergies dans le : ALICE, ATLAS, CMS et LHCb, le LHC recrée les conditions qui existaient juste après le Big Bang. Des équipes de physiciens du monde entier analyseront les particules issues de ces collisions en utilisant des détecteurs spéciaux. Les détecteurs peuvent observer seconde, avec les expériences qui trient les données pour analyser des événements extrêm [Haen 2013]. 3

13 Figure 2: Fonctionnement du LHC [Haen 2013] LHCb xpérience LHCb cherche à comprendre pourquoi nous vivons dans un univers qui semble Hadron Collider beauty. Ce dernier mot «beauty» vient du nom de la particule que ce détecteur étudier, le méson B. égales mais ils ne savent pas expliquer ce que serait devenue l La collision entre deux protons permet de produire de nombreuses particules. Les k (les quarks étant les particules élémentaires qui composent la matière). Ainsi, en comprenant comment, lors de la de matière [LHCb 2007]. 4

14 Figure 3: Quark B LHCb utilise une série de sous-détecteurs alignés le long du faisceau afin de traquer principalement les particules à petits angles. Le premier sous-détecteur est installé près du point de collision ; les autres se suivent sur une longueur de 20 m. Une grande variété de types de quarks sera créée par le LHC avant de se désintégrer tion LHCb a mis au point des trajectographes mobiles, installés au plus près de la trajectoire des faisceaux. Tous ces détecteurs envoient les données sur un réseau Ethernet chargé de les prétraiter (filtrer les événements) et de les stocker pour ensuite permettre aux physiciens de les analyser. 5

15 Figure 4: détecteur LHCb Le détecteur LHCb (Figure 4) a les caractéristiques suivantes : Dimensions : 21 mètres de long, 13 mètres de large et 10 mètres de haut. Poids : 5600 tonnes. Configuration : spectromètre à petits angles avec détecteurs planaires Système LHCb Online Le système LHCb Online se charge des aspects informatiques, de contrôle et de également traitement des données reçues du détecteur. Ainsi, Le réseau LHCb se devise en deux réseaux de fonctionnement différent. Le premier est appelé Le réseau de donnée (DAQ) qui a pour but de transporter les données acquises par les détecteurs au disque de stockage. Le second est un système de contrôle qui a pour rôle le contrôle de tous les équipements dans le réseau (Figure 5). LHCb (Figure 5) répartis dans les différents secteurs, que ce soit aussi bien dans la partie SX (au- 6

16 en dessous du sol). Ces équipements produisent un travail constant tous les jours et leur fonctionnement en continue est primordial. Figure 5: Représentation de la structure du réseau LHCb Online (DAQ) Le système DAQ (Data AcQuisition - des données potentiellement intéressantes [LHCb Collaboration 2001]. Tout au long de ce système, les données sont sélectionnées par différents mécanismes pour ne conserver que ce qui est potentiellement pertinent et intéressant. On différencie ainsi LHCb Online, qui regroupe LHCb Offline, qui regroupe donc le traitement effectué sur les données stockées. Le LHC produit des collisions, ou événements, à une fréquence de 40 Mhz. Seulement les 7

17 Beauty. Au final, la fréquence intéressante sera de 15 Hz. Dans ce sens, le LHCb a mis au point conjointement au système DAQ, un système de sélection des données, le Trigger System. Ce système de sélection est permettent de déterminer quels sont les événements à conserver. La première sélection au niveau de L0 trigger. Après L0, les données sont envoyées vers les cartes TELL1. [LHCb Collaboration 2001]. Ces cartes mettent les données en mémoire tampon, puis elles les transfèrent via un réseau IP assez com des données à mémoriser. Cette ferme de calcul correspond au HLT (High Level Trigger) [LHCb Collaboration 2001].. N.B : il existe 6 fermes de calcul chaque ferme contient un nombre précis de sousfermes, chaque sous- disque). sous ferme a01 de la ferme a de la grande ferme hlt. Le système de contrôle: ECS (Experiment System Control) Avec plus de composants, le détecteur complexité. La configuration de tous ses composants devient rapidement une opération matériel, celui-ci pouvant de plus se trouver dans une zone soumise aux radiations. la configuration et la supervision de r. Ce système de contrôle est basé sur un système SCADA (Supervisory Control and Data Acquisition) appelé WinCC Open Architecture. Ce logiciel qui a été développé par la société allemande «Siemens» permet de récupérer des données à partir du matériel afin de surveiller et contrôler son fonctionnement ainsi que de le configurer à distance. Tous les modules contrôlables doivent donc être représentés dans WinCC [LHCb Collaboration 2001]. Le système WinCC est dépendant de plusieurs autres systèmes tels que le storage, le réseau, DNS (Domain N 8

18 expérience à bas niveau système de supervision Mon stage se situait au sein de sa ure matérielle et logicielle du système LHCb Online décrit dans la section Administrativement, cette équipe est rattachée au département PH: département de la physique qui est (Voir Annexe A) La supervision (Figure 6). des entreprises possédant un parc informatique conséquent. La supervision est la surveillance du bon fonctionnement des éléments suivants : Serveurs : CPU, mémoire, processus, fichiers de journalisation, place disque, services. Matériels : Disques, cartes Raid, cartes réseau, température, alimentation, onduleurs, batteries. Réseaux : Bande passante, protocoles, éléments actifs, commutateurs, routeurs, parefeux, accès externes, bornes wifi, etc. Vue globale du système. Détection des pannes. Indicateurs sur la performance d Niveau de supervision (actif ou passif). Actions de correction. 9

19 Il existe deux grandes familles de solutions de supervision : Les logiciels propriétaires : HP Open View, Tivoli d Les logiciels libres : Nagios, Icinga, Zabbix, MRTG, Centreon, etc. Figure 6: Principe de fonctionnement de la supervision Etude du système de supervision actuel superviser le grand réseau LHCb Online, une infrastructure distribuée basée sur un outil appelé Icinga 1.x était mise en place [Haen, Bonaccorsi et Neufeld 2011]. Nagios, Icinga et autres outils de supervision permettent à la fois de superviser des «hosts» (serveurs, switchs, etc) ainsi que des «services» (logiciels, ressources, etc) en utilisant des petits programmes exécutables appelés «plugins». Un plugin est chargé de réaliser les vérifications et de fournir par la suite au moteur un code de retour par exemple : 0 = tout va bien (OK) 1 = avertissement (WARNING) 10

20 2 = alerte (CRITICAL) 3 = inconnu (UNKNOWN) Il peut également retourner des courts messages descriptifs ainsi que des informations de performances. le nombre de vérifications pouvant éventuellement être exé milliers de vérifications dans un intervalle de temps de quelques minutes. Par conséquent, une infrastructure très large telle que celle du LHCb ne peut pas être supervisée par une seule instance du logiciel de supervision sans pour autant provoquer des délais de latence. La distribuée ou encore parallélisée. Dans ce sens, la solution appliquée pour la supervision du système LHCb consistait à la mise nstance centrale Icinga 1.x utres serveurs appelés «workers» [Haen, Bonaccorsi et Neufeld 2011]. En effet, un module appelé «mod-german workers» de les exécuter et de retourner les résultats de ces vérifications (Figure 7). rite est adoptée depuis plus de environnement LHCb Online. Cette architecture a donné des résultats généralement positifs plus particulièrement en terme de performance. En effet, grâce au module «mod-gearman» exécuter approximativement vérifications dans un intervalle de cinq minutes sans délais de latence [Haen, Bonaccorsi et Neufeld 2011].. 11

21 Figure 7: Infrastructure de supervision Icinga 1.x [Haen, Bonaccorsi et Neufeld 2011] Par ailleurs, réécrire la même configuration Icinga pour les différentes machines (hosts) de (temps, performa. : Héritage exactement de la même façon que le principe de la programmation orientée objet. paramètres de supervision et non pas par exemple des services appliqués à la machine parent (parent host). HostGroup : qui désigne un ensemble de machines (hosts). Une machine peut être membre de plusieurs groupes et un groupe peut être groupe. logique implémenté par la suite sous deux formes : (Figure 8) Arbre des «HostGroups» «HostGroup» et jamais à un «host» unique. 12

22 Arbre des «Hosts» machines proprement dit. Figure 8: Extrait de l'arbre logique de configuration Icinga 1.x [Haen, Bonaccorsi et Neufeld 2011] Limites de la solution actuelle : évidence les limites de la solution de supervision basée sur Icinga 1.x dont voilà les principales : - Un problème sur le serveur central icinga signifie une indisponibilité totale de - dépendance entre hôtes et services e fonctionnalités les plus importantes dans le concept de supervision. En effet, si plusieurs qui sera envoyée est seulement celle du problème racine. Toutefois, plusieurs experts ont telle fonctionnalité avec Icinga 1.x. 13

23 - Icinga 1.x nécessite une durée importante pour pouvoir détecter ce genre de pannes, par conséquent les délais de latence sont énormes. - Icinga 1.x offre une configuration très statique : une vérification configurée dans Icinga 1.x utres vérifications). De même, la configuration ne peut pas être modifiée - nstallation entraîne une analyse complète de la configuration après modification ce qui pourrait être très longue : services sont analysés dans environ analyser services Solution proposée Afin de remédier aux différents problèmes cités précédemment un benchmark très détaillé des : [Haen, Bonaccorsi et Neufeld 2013]. cle en question a mis en évidence la po savoir : Icinga2 et Shinken. Finalement, le choix était sur Icinga2 un outil récemment en version stable, simple à installer, logique à configurer et surtout facile à étendre. Icinga2 se distingue notamment par ses performances : une même instance a déjà réussi à effectuer 1 million de vérifications actives par minutes afin de surveiller hôtes, indique le site icinga.org [Icinga2 2014]. alités habituellement des commandes. 14

24 En o étendre la solution grâce à la présence de plusieurs backoffices et à la prise en charge native des livestatus et de graphite pour la représentation graphique des performances en temps réel. la configuration des serveurs du système LHCb Online. contraintes dans un cahier des charges. 1.3 Cahier des charges La mission du stage consiste à concevoir et installer un nouveau système de supervision de réseau. -source Icinga2. Une documentation approfondie de Le travail réalisé doit à la fin assurer les fonctionnalités suivantes : Superviser les différents équipements du réseau LHCb Online. Superviser les différents services réseaux. Superviser les ressources systèmes (CPU, charge mémoire) es alertes et les notifications. Pouvoir installer plusieurs instances d différents de celui qui comporte Icinga2 core. supervision en utilisant 15

25 1.4 Planification prévisionnelle L aidé à prévoir le déroulement du projet dans le temps en adoptant le planning cité dans la figure ci-dessous : Figure 9: Planning prévisionnel du stage Compréhension générale du sujet et planification : consiste à bien comprendre le travail demandé. Elle permet également de définir le bon chemin à suivre pour réaliser les différentes tâches du projet. Documentation et compréhension des outils : il de faire des recherches approfondies sur le sujet. Une documentation initiale, pour découvrir et appréhender les différents points survenir au cours de la réalisation. Réalisation : cette partie se divisera en deux sous parties. La première concernera la mise en déploiement de la solution complète sur le système de production. N.B : voir le planning réel en Annexes : Annexe B. 16

26 2. Etude et tests des outils choisis Ce chapitre décrit la première partie de la réalisation du projet. nnalisé pour les tests. Ainsi, ce chapitre présente de supervision Icinga 2, la. 2.1 Icinga 2: solution de supervision des réseaux Icinga2: définition Icinga 2 est un logiciel de supervision libre et sous license GPL (General Public License Version 2). Destiné à informer les informaticiens des problèmes éventuels du réseau, générer des indicateurs de la performance ainsi que superviser des environnements larges et complexes. Cette version de la solution de surveillance des réseaux développée en parallèle de la branche corrigeant les défauts issus de Nagios, dont Icinga est un fork [Icinga2_doc 2014]. Figure 10: Logo Icinga 2 17

27 2.1.2 Icinga 2: spécificités techniques [Icinga2 2014]. Cette nouvelle mouture actuellement en version stable a les caractéristiques suivantes : Construit à partir de zero, Icinga 2 est basé sur le langage C++ et utilise des bibliothèques Boost. Multi-plate-forme, Icinga 2 fonctionne sous les plates-formes *NIX (les systèmes elles et anciennes, ainsi que Windows. Contrairement à ses prédécesseurs Icinga 2 a une architecture modulaire et flexible (Figure 11). En effet, Icinga 2 est livré avec toutes les fonctionnalités modernes de supervision (IDO, Livestatus, data «icinga-enable-feature» ou «icinga-disable-feature er les fonctionnalités voulues. Par exemple, une fois le module Perfdata est activé, Icinga 2 permettant données de performance remontées. Icinga 2 est compatible avec Icinga 1.x et avec Nagios à travers une couche de compatibilité. Cette nouvelle version intègre en effet des couches de compatibilité avec des interfaces utilisateurs classi des interfaces web (Figure 11). 18

28 Figure 11: Architecture de Icinga 2. Afin de gérer la répartition de charge des tâches de supervision telles que les vérifications, notifications, ainsi que les mises à jour de la base de données, Icinga 2 utilise la fonctionnalité «cluster» «maître DB IDO (Database Icinga Data Output) autre instance est automatiquement élue pour ce rôle. De plus, chaque instance a un identifi données (Figure 12). Par ailleurs, en cas de basculement automatique «failover» les instances du cluster sont conçues de façon à reproduire en temps réel la configuration ainsi que les états des programmes assurant ainsi une intégrité complète des données. En outre, toutes les communications réseau entres ces instances sont assurées par des certificats SSL x509 (Figure 12). 19

29 Figure 12: La supervision distribuée basée sur la fonctionnalité cluster Icinga 2 est conçu pour être rapide. Grace à sa conception multithread, il peut exécuter des milliers de vérifications en une seconde sans aucun problème au niveau du processeur. Contrairement à Icinga 1.x, le processus responsable de recharger une fils est entrain de valider la configuration le processus parent continue les vérifications et les autres tâches de supervision, deux cas de figures se présentent : Si la configuration est valide : le processus fils envoie le signal «STOP» courant dans un fichier appelé icinga 2.state. Ensuite, le processus fils lit le devenir le nouveau leader de la session. pas valide : le processus fils se termine, le processus parent ce qui est essentiel pour assurer la synchronisation en cas du mode cluster). 20

30 La configuration de Icinga est simplifiée dans cette version 2 grâce à nouveau format basé objet et fondé sur les templates (plus de détails sur la configuration et les notions de dépendance, notifications seront vus ultérieurement) Installation de Icinga 2 2 proprement dit. La meilleure façon de faire ceci consiste à utiliser un dépôt officiel (RPM ou Debian) selon le SLC 6 (Scientific Linux CERN 6) tion Linux Open Source, codéveloppée par Fermi National Accelerator Laboratory et par le CERN et basée sur Red Hat Entreprise Linux (RHEL). La majorité des fonctionnalités de Icinga 2 sont disponibles dans les paquets du dépôt : [Icinga2_epel 2014]. our une installation de base de Icinga 2 : La fonctionnalité «checker» : pour exécuter les vérifications. La fonctionnalité «notification» :. La fonctionnalité «mainlog» : pour écrire dans le fichier icinga2.log Installation du module DB IDO (Database Icinga Data Output) La base de données IDO est utilisé par plusieurs projets tels que Icinga Web 1.x et Icinga Web 2. Dans notre cas la base de données utilisée est de type MySQL, une installation du paquet icinga2-ido-mysql est donc nécessaire avant de créer la base de données proprement dit. Après la c utilisant : icinga-enable-feature ido-mysql. 21

31 2.2.3 Installation des interfaces graphiques Icinga 2 est compatible avec les interfaces graphiques 1.x en utilisant quelques fonctionnalités supplémentaires. Ces interfaces sont Icinga Classic UI et Icinga Web. En outre, une interface graphique propre à la version 2 de Icinga est en cours de développement. Icinga Web, son installation passe par les étapes suivantes : -web ou icinga-web-mysql -web. ido-mysql. nées icinga-web. commandes. : [Icinga-web-URL 2014] Les fichiers de configuration de base n est effectuée, plusieurs fichiers de configuration sont créés : icinga2.conf : 2. Il contient notamment la liste globales de fonctionnement de Icinga 2, comme la directive «include» ou encore «include_recursive (ex : include_recursive "conf.d"). constants.conf : les autres fichiers de configuration de Icinga 2. Il permet de définir des constantes globales pour une utilisation simplifiée dans les autres fichiers de configuration. (ex : const PluginDir = " /usr/lib/nagios/plugins "). zones.conf : Ce fichier est utilisé pour configurer les objets «Endpoint» et «Zone» nécessaires 22

32 conf.d : Même si en théorie, il est possible de définir tous les objets de configuration dans le fichier principale icinga2.conf, il est vivement recommandé de créer des répertoires et fichiers séparés dans le dossier conf.d. Tous ces fichiers doivent obligatoirement avoir.conf». 2.3 Atelier de tests Pour tester les différentes fo à mettre en place un petit atelier qui regroupe presque les différents équipements réseau du système LHCb Online (Figure 13). En effet, le système LHCb Online est composé de plusieurs ferm les éléments suivants : Un système de données physiques : à travers lequel transitent les données de collisions, i Switch, S Un système de contrôle : à travers lequel transitent les données autres que les données de collisions notamment : eurs «NFS». «storage». Les données de contrôle proprement dit qui proviennent des contrôleurs. Une ferme de calcul X composé de : : sont des serveurs de calcul permettant de trier les événements qui proviennent du détecteur. Switch-dt-X : ire acheminer les données de collisions. Switch-ctrl-X acheminer les données de contrôle. 23

33 NFS-X Contrôleur X : est un serveur hébergé soit sur une machine virtuelle fournit par viseur soit sur une machine réelle. Ce serveur a pour rôle de données des directives et des ordres de configuration aux Storage : est un grand serveur NFS permettant à tous les composants du réseau ose de deux parties : Une petite partie pour stocker les fichiers des utilisateurs. Une grande partie pour stocker temporairement les données physiques de Store XYZ : est un serveur permettant également de stocker des données physiques de Switch-UX : est un grand commutateur permettant de relier les différents équipements réseau du système. Hyperviseur : est un logiciel installé directement sur la couche matérielle du serveur, permett 24

34 Figure 13: Schéma réseau de l'atelier Icinga 2 est utilisé pour superviser la disponibilité des hôtes et des servic. Icinga 2 offre plusieurs mécanismes et bonnes pratiques. ge des objets en utilisant les «Templates» : Les «Templates» sont utilisés pou plusieurs objets. Les objets et les «Templates» peuvent hériter plusieurs attributs Templates». Si nécessaire, les attributs hérités peuvent être surchargés par les objets fils. 25

35 Dans Templates» est faite selon une approche plate par fonctionnalité afin de regrouper les objets ayant les mêmes propriétés (Figure 14). Cette approche de conception a les avantages suivants : Construire des groupes fonctionnels (groupe des contrôleurs, groupe des par la suite la définition des «Groups» de Icinga 2. Faciliter la définition des objets des hôtes en faisant un simple héritage avec la directive «import», avec la possibilité de faire un héritage multiple. Templates». Faciliter la définition des services et des dépendances en utilisant la notion «apply objects based on rules», en se basant sur la directive conditionnelle «assign» et les attributs dynamiques «Custom attributes» (Figure 14). Figure 14: Digramme d'héritage des "Templates" des hôtes La définition des groupes des hôtes: Dans la configuration de Icinga 2 la définition des groupes sert à regrouper des hôtes ou des services par affinité afin de les visualiser dans les interfaces graphiques. Elle 26

36

37

38 X «ferme X». Figure 16: Digramme des "Host Group" logique La définition des services : ce identifie une ressource sur un hôte. Le terme «service» est très générique. (SSH, HTTP, SMT autre type de mesures Dans notre cas, la définition des services est faite selon la notion «Apply services to hosts» qui consiste à appliquer un service à un ensemble de hôtes en utilisant une sur les attributs «custom attributes» déjà créés dans les «Templates» (Figure 17). 29

39

40 Service-to-Service : entre deux services. Service-to-Host ou Host-to-Service : entre un service et un hôte. des notifications ance. Une dépendance est considérée n service (parent) Avant cas, le contrôle est exécuté ou la notification est envoyée comme en temps chacune de la manière suivante : 1. nt il dépend boucle de vérification des dépendances. 4. Si non, Icinga 2 continuera avec la prochaine dépendance. Compte tenu des spécificités du réseau atelier de test, plusieurs dépendances ont été identifiées (Figure 18). 31

41 Figure 18: Diagramme des dépendances Partant du constat que plusieurs hôtes ou services dépendent du même hôte ou service, il serait judicieux de définir un nouveau attribut «custom attribute» permettant de matérialiser cette dépendance. Ceci, permettra de faciliter la génération des règles de dépendances en mettant la condition sur cet attribut. Prenons par exemple les dépendances contrôle A de la même ferme (Figure 18). Toutes ces dépendances sont définies par une seule règle en se basant sur la notion «apply rules» dépendance (Voir exemple ci-dessous) [Icinga2_doc 2014]. 32

42

43 Shell est utilisé pour Ce script consiste à chercher dans un fichier le nom hôte du réseau CRITICAL» ou «DOWN «OK» ou «UP». Ainsi, ayant fait toute la configuration nécessaire au bon fonctionnement de Icinga 2, le système de supervision commence à récupérer des informations, signaler des problèmes et envoyer des informations. Les figures suivantes donnent une idée sur les résultats des tests -web. permettant de faire entrer le login et le mot de passe (Figure 20). Figure 20: Page d'authentification Icinga-web Une fois que tenant les différents menus proposés. HostSatus», les différents états des hôtes sont visualisés avec les éléments de description associés (Last check, Duration, 34

44 . 7 hôtes sur 10 sont dans un état «UP» en vert, 3 hôtes sur 10 sont dans un état «DOWN» en rouge (Figure 21). Figure 21: Interface des états des hôtes En appuyant cette fois ci sur ServiceStatus» les différents états des services sont affichés (Figure 22). Chaque hôte 10 services sur 13 sont dans un état «OK» en vert, 3 services sont dans un état «CRITICAL» en rouge. 35

45 Figure 22: Interface des états des services Pour afficher les différents groupes des hôtes définis dans la configuration (Section précédente) Hostgroups», chaque groupe est affiché avec les différents états de ses membres (Figure 22). 36

46 Figure 23: Interface des groupes des hôtes La dépendance entre la plus part des hôtes du réseau et le switch_ux a donné les résultats représentés dans la Figure 24. En effet, vu que le switch_ux est dans un état «DOWN» les autres hôtes dépendants apparaissent dans un état «UNREACHABLE» sans pour autant envoyer de notifications ni exécuter un contrôle (Figure 21). 37

47 Figure 24: Dépendance du switch_ux 2.4 Puppet : solution de gestion des configurations Puppet : définition Puppet est une application est industrialisé» (système LHCb Online par exemple). En effet, dans de tels environnements le logiciels sont donc nécessaires à chaque nouveau serveur, en outre, la synchronisation des iture des scripts shell [Puppet 2014]. ion de manière centralisée : 38

48 Configurer de façon homogène un ensemble se serveurs, Contrôler et corriger tout écart de configuration, Faire du déploiement rapide de serveurs, Augmenter le niveau de sécurité : déploiement rapide de patchs, mise à jour de Figure 25: Logo Puppet Fonctionnement et caractéristiques de Puppet Puppet est un outil qui permet de mettre à jour de façon automatisée et selon un scénario prédéfini un ensemble de serveurs clients selon une architecture client /serveur. Sur chaque machine un client va être communication HTTPS (Figure 26). 39

49

50 : 1 package { : 2 Ensure = installed, 3 } Mon client Debian va faire : 1 apt-get install htop Mon client Redhat va faire : 1 yum install htop Facter un système : F clé => valeur» disponible en tant que variable dans les scénarios Puppet. On peut ainsi récupérer par exemple : le hostname, clés => valeurs». Ces informations sont appelées des «Facts». Pour résumer, voici un schéma de Puppet labs (le site officiel de Puppet) qui décrit le fonctionnement et les caractéristiques de Puppet (Figure 27). 41

51 Figure 27: Fonctionnement de Puppet : Installation de Icinga 2 par Puppet Installation de Puppet : de tester les fonctionnalités de Puppet, une in des machines virtuelles SLC 6 a été réalisée selon les étapes suivantes : 1) Au niveau du serveur master : Installer Puppet Master : cette installation nécessite Labs qui contient les différents packages de Puppet. tat «listening» ur que la communication soit autorisée. 2) Au niveau des serveurs clients: Ajouter le dépôt Puppet Labs. Installer Puppet Client. 42

52 Editer le fichier «/etc/hosts client avec leurs noms de domaine. cute au démarrage. Installation 2 par Puppet : regroupées dans des classes (qu un seul module appelé «icinga2». compilées par la suite par le serveur master pour former un «catalogue». Ce dernier est téléchargé en local par le client Puppet (ce qui permettra au client de continuer à icinga2 icinga2» qui comporte à son tour les sous-classes suivantes : icinga2 :: rpm-snapshot : cette sous-classe a pour rôle de configurer tous les icinga2 :: doc : cette sous- documentation de Icinga 2. icinga2 :: nagios-plugins : cette sous- es plugins nagios nécessaire pour les vérification des hôtes et des services. icinga2 :: feature : cette sous- Icinga 2 comme ido-mysql par exemple. icinga2 :: apache : cette sous- «apache» nécessaire icinga2 :: php : cette sous- php» nécessaire pour Icinga2 :: mysql : cette sous- -server et de est démarré. 43

53 Icinga2 :: web -classe permettant -web Icinga2 :: core - qui fait appel à la majorité des sous-classes déjà cités. 44

54 le système LHCb Online Ce chapitre décrit la deuxième et la dernière partie de la réalisation du projet. du déploiement de la solution complète sur le système de production LHCb Online. Il 3.1 Présentation du système à superviser Le système à superviser est le système LHCb Online décrit en détails dans la section du et 200 équipements réseau. 3.2 Conception de la configuration du système de supervision La conception adoptée pour appliquée à un échelon plus grand (section 2.3.2) les «Templates» chaque template désigne une fonctionnalité ou un type de machine. La Figure 28 présente un extrait du diagramme des «Templates» du système de supervision réel. Tous les «Templates Template» générique appelé «tpl-host» qui comprend des attributs génériques valables pour tous les types notamment : max_check_attempts : dési HARD», par défaut cet attribut est à 3. check_interval : cet attribut est utilisé pour les vérifications lorsque le hôte est en état «HARD retry_interval : cet attribut est utilisé pour les vérifications lorsque le hôte est en état «SOFT N.B : «HARD» ou du service 45

55 «SOFT» check_command : cet attribut désigne le nom de la commande utilisée pour vérifier check_ping statut vars.tpl-host : cet attribut sert à identifier un objet «Host». Figure 28: Extrait du diagramme des "Templates" : hlta01» qui désigne le contrôleur de la ferme a01 hérite à la fois du tpl-vm, tpl-linux, ainsi que du tpl-controller. Ce qui signifie que cette machine qui a la fonction de contrôle, hébergée sur une machine virtuelle. Il est à noter que la démarche suivie pour la conception des services, des groupes, ainsi que des dépendances reste la même que celle adoptée lors des tests (voir section 2.3.2). 46

56 3.3 Implémentation de la configuration qui répond aux besoins déjà fixés, plusieurs outils complémentaires ont été ajoutés à Icinga Agent NRPE (Nagios Remote Plugin Executor) Définition Si il est possible pour le serveur écoute sur une machine distante en utilisant les plugins (voir section 2.3.3), il est plus difficile de connaî appel à des petits programmes appelés agents de supervision. NRPE est parmi ces agents de supervision qui permet de récupérer les informations à distance. Son principe de fonctionnement est simple N.B existe un plugin appelé «check_by_ssh toutefois elle provoque des niveaux très élevés de charge CPU surtout avec des milliers de machines à superviser (cas du LHCb Online). Principe de fonctionnement [NRPE 2013] Le fonctionnement est simple particulière depuis Icinga 2, le plugin «check_nrpe» sur le serveur Icinga 2 initie une. 47

57 Figure 29: Fonctionnement du NRPE : Les vérifications directes : NRPE est souvent utilisé pour superviser directement des ressources sur une 30). Figure 30: Fonctionnement des vérifications directes 48

58 Les vérifications indirectes NRPE peut être utilisé également pour vérifier des ressources ou services qui ne sont pas accessibles directement à partir du serveur Icinga 2. Par exemple si un serveur web distant est accessible de la machine distante où le démon NRPE tourne mais pas du serveur Icinga 2, le démon NRPE peut être configuré de telle façon à permettre de superviser le serveur web indirectement. Ainsi Le démon Figure 31: Fonctionnement des vérifications indirectes 2 Dans la machine distante à superviser, une liste de ces commandes a été définie dans le fichier de configuration «nrpe.cfg» de la machine à superviser. Exemple: Command [i2_check_load] = /usr/lib64/nagios/plugins/check_load -w $ARG1$ -c $ARG2$. Cette commande par exemple permet de déterminer la charge CPU. Les arguments sont passés dynamiquement. Elle est appelée depuis le serveur Icinga 2 par son nom indiqué entre crochets [ ] de la manière suivante : Check_nrpe -H <@machine_distante> -c <i2_nom_de_la_commande>. 49

59

60

61 Figure 32: Extrait des hôtes en état "UP" La Figure 33 présente les hôtes en état «DOWN». 8 hôtes sont dans un état «DOWN». Figure 33: Extrait des hôtes en état "DOWN" 52

62 34 présente un extrait des services du système LHCb Online avec leurs états (OK, WARNING, CRITICAL, UNKNOWN) services sont en état «OK», 498 en état «WARNING», 810 en état «CRITICAL» et 6478 en état «UNKNOWN». Figure 34: Extrait des différents états des services avoir des statistiques sur les vérifications sous forme de graphes, la figure 35 services. 53

63 Figure 35: Graphe des statistiques Afin de faciliter la lecture des résultats des vérifications, Icinga 2 permet de configurer des groupes de machines «Hostgroup». La Figure 36 présente les résultats des vérifications par groupe. Figure 36: Extrait des groupes "hostgroup" 54

64 3.3.4 Discussion des résultats Si les résultats de supervision du système LHCb Online illustrent parfaitement les avantages En effet, la solution de supervision basée sur Icinga 2 a permis de pallier les limites de la solution actuelle (basée sur Icinga 1.x) : 1) Les résultats obtenus ont démontré les bonnes performances de Icinga 2 afin de surveiller plus de 1500 hôtes. De plus, les délais de latences ne sont plus énormes. 2) par rapport aux switchs) a permis de diminuer davantage le nombre de notifications envoyées. 3) flexible. 4) Templates sation de configurations tel que Puppet (la dernière section traitera ce point). Toutefois, pendant les tests de la configuration, quelques problèmes ont été soulevés plusieurs fois : 1) Selon la documentation officielle de Icinga 2, il existe une dépendance implicite entre un hôte et ses services, toutefois les résultats obtenus ont démontrés le contraire : même si un hôte est «DOWN» les vérifications de ses services seront exécutés. Ce s solutions. 2) Dans certains cas, PENDING» ce qui signifie en attente. Ce comportement est étrange du fait que le même service tourne sur plusieurs machines et il est correctement vérifié. Ce bug a été également soumis aux développeurs icinga 2. 55

65 3.4 Automatisation de la configuration par Puppet Analyse du problème Dans une infrastructure à grande échelle comme celle du LHCb Online, le nombre de serveurs à superviser tend à augmenter rapidement. La configuration du serveur Icinga 2 est donc Shell. Ainsi, concevoir et implém configuration du serveur de supervision constitue sans nul doute un apport considérable en terme de temps et de performance. Scénario escompté : ajoutés au système à superviser, mettre à jour dynamiquement les fichiers de configuration du serveur Icinga Solution proposée La solution retenue consiste appelé Foreman permettant entre autres la gestion de la configuration des serveurs en collectant les «facts et les rapports générés par puppet [Foreman 2014]. La Figure 37 présente les principales étapes du processus de génération de la configuration du serveur Icinga 2 à savoir : 1) Demande de configuration du client au serveur Puppet master et envoi des «facts» en même temps. Dans ce cas, le serveur Icinga 2 est également un agent de Puppet. 2) Stockage des «facts» au niveau de la base de données du serveur Foreman. 3) En fonction des informations de chaque agent, les ressources sont interprétées et compilées. Envoi de la configuration compilée à chaque client. du fait que la configuration du serveur Icinga 2 utilise les «facts» des autres agents, il est 56

66 nécessaire donc de récupérer les «facts» déjà stockés pour générer le catalogue du serveur Icinga 2. 4) Mise en place de cette configuration par le client. Figure 37: Processus de configuration Puppet-Foreman Dans ce processus de génération chaque outil à un rôle particulier : Puppet : Plutôt que diffuser la configuration du serveur au client, ce sont les clients qui viennent réclamer cette configuration. Cela peut porter sur un fichier, un package, un service, etc. Il est possible de spécifier les intervalles entre les différentes demandes de chaque client. Une fois la demande autorisé par le serveur Puppet, ce dernier envoi la - : si la configuration du serveur est 57

67 : un logiciel déjà installé sur le client ne sera pas réinstallé). Utilisation des facts : : il retourne des «facts» : des variables globales de chaque agent Puppet telle que son adresse IP, son hostname, son OS et sa version etc. Ces «facts» sont utilisés par Puppet master afin de servir de variables nécessaires à la génération des catalogues (configuration compilée). En plus des facts par défaut, Il est Agent Icinga 2 : le serveur Icinga 2 est un agent de Puppet, toutefois sa configuration est particulière, car elle consiste à générer des fichiers contenant l. Foreman. Foreman : [Foreman 2014] Foreman est un projet open source qui aide les administrateurs systèmes à gérer les serveurs tout au long de leur cycle de vie, de la configuration à la supervision. En interface web (Figure 38) Restful permettant de construire une logique métier sur une base solide. Figure 38: Interface web Foreman 58

68 Parmi les fonctionnalités offertes par Foreman est celle de pouvoir ajouter les hôtes et leurs facts dans la base de données Foreman [Foreman 2014], La figure 39 illustre cette possibilité. Figure 39: Extrait des facts sur Foreman Afin de récupérer les facts depuis foreman, il existe une fonction appelée foreman( ), il retourne le résultat sous forme de flux JSON (Javascript Object Notation). : Un fichier de configuration Icinga 2 est un fichier permettant de définir un objet «host» ainsi que ses dépendances si elles existent. Ce fichier peut être décomposé en plusieurs fragments, chaque fragment vient du fait que le hôte en question a une fonctionnalité ou une caractéristique particulière. Exemple : le fichier de définition du hôte «hlta0208» est la concaténation des fragments suivants : 59

69

70

71 Conclusion Mon travail consistait à mettre en place une nouvelle infrastructure de supervision basée sur les outils Icinga 2 et Puppet. Afin de réaliser les objectifs réunions. Au cour comprendre le fonctionnement complexe du système LHCb de gestion de la configuration des serveurs Puppet. nécessaire. Icinga 2 est conçu pour s choisir une conception adaptée aux contraintes du système LHCb Online. utomatisation de la configuration du serveur Icinga 2 en utilisant Puppet était un réel défi, dans ce sens, un système de génération des fichiers de configuration Icinga 2 a été ion des infrastructures informatiques de grande taille. supervision Icinga 2 récemment en version stable, ce qui a entrainé certains problèmes plus particulièrement le manque e second de rapidité et de performance. en août Plusieurs améliorations pourraient être envisageables de développement, (au lieu de NRPE) xécution des vérifications à distance, le renforcement des aspects de sécurité des communications au sein du système de supervision, ainsi que cluster disponibilité tructure de supervision. 62

72 Références bibliographiques [CERN 2014], CERN, Rapport annuel 2013, Genève, Suisse, [Haen 2013], Christophe Haen, OPhronsis a diagnosis and recovery tool for system administrators, Thèse de doctorat, Université Blaise Pascal-Clermont II, 24 octobre [Haen, Bonaccorsi et Neufeld 2011], C.Haen, E.Bonaccorsi, N.Neufeld, Distributed monitoring system based on Icinga, In Proceedings of WEPMU035 ICALEPCS 2011, Grenoble, France, [LHCb Collaboration 2001], LHCb Collaboration, TDR LHCb Online System Data Acquisition & Experiment Control, Technical Design Report, CERN/LHCC LHCb TDR 7, 19 décembre Webographie [CERN_homepage 2014], About CERN, 2014, [Ressource électronique], [Réf. du 30 juin 2014 à 23:26]. Disponible sur : [Haen, Bonaccorsi et Neufeld 2013], C.Haen, E.Bonaccorsi, N.Neufeld, Evolution of the monitoring in the LHCb Online System [Ressource électronique], 2013, USA. Disponible sur : [Icinga2 2014], Icinga2, Icinga2 redesigns Open Source Monitoring, 2014, [En ligne], Disponible sur : [Icinga2_doc 2014], Icinga2, Icinga2 documentation, 2014, [En ligne], Disponible sur : [Icinga2_epel 2014], Icinga2, Icinga EPEL Repository, 2014, [En ligne], Disponible sur : ix

73 [Icinga-web-URL 2014], Icinga, Icinga-web URL, 2014, [En ligne], Disponible sur : [Puppet 2014], Icinga2,?, 2014, [En ligne], Disponible sur : [LHC 2007], Large Hadron Collider, 2007, [Ressource électronique], [Réf. du 12 mai 2014 à 08:48]. Disponible sur : [LHCb 2007], Large Hadron Collider beauty experiment, 2007, [Ressource électronique], [Réf. du 15 mars 2013 à 16:49]. Disponible sur : [Puppet_doc 2014], Icinga2, learning Puppet, 2014, [En ligne], Disponible sur : [NRPE 2013], Icinga2, Protocole NRPE, 2013, [En ligne], Disponible sur : [Nicodemus 2005], Nicodemus, PNAN-Nagios Notification Daemon, 2005, Dernière date de modification : , [En ligne], Disponible sur : Projects/Notifications/NAN---Nagios-Notification-Daemon [Foreman 2014], Foreman, Foreman 1.5 Manual, 2014, [En ligne], Disponible sur : x

74 Annexes xi

75 Annexe A Organigramme du CERN :[CERN 2014] xii

76 Annexe B Planning réel : xiii