Ministère de l’Enseignement Supérieur, de la Recherche Scientifique et de l’Innovation (MESRSI) -------------------Secrétariat Général --------------------Université NAZI BONI (U.N.B) -------------------École Supérieure d’Informatique (E.S.I) --------------------- Option : Ingénierie Réseaux et Systèmes (IRS) RAPPORT DE STAGE DE FIN DE CYCLE THEME : « Étude et mise en place d'un outil de supervision du système d’information de SOFTNET » Période de stage : du 20 Août 2018 au 18 Novembre 2018 Auteurs : PAMOUSSO Djibril Pierre Clavair & NIKIEMA Amadou Superviseur Maître de Stage Manager du département Réseaux et télécom à SOFTNET Année académique : 2017-2018 M. ZOUGMORE TéegWendé, Enseignant à l’ESI I AVANT-PROPOS L’université NAZI BONI (UNB) auparavant Université Polytechnique de Bobo-Dioulasso (UPB) a été créée le 23 mai 1997 par le décret n°97-254/PRES/PN/MESSRS. C’est un établissement public de l’État à caractère scientifique, culturel et technique, chargé de l’enseignement supérieur et de la recherche scientifique. Située à une dizaine de kilomètres de Bobo-Dioulasso, elle est constituée de nos jours de : • L’École Supérieur d’Informatique (ESI) ; • Institut de Développement Rural (IDR) ; • Institut Universitaire de Technologie (IUT) ; • Institut des Sciences de la santé (INSSA) ; • L’UFR des Sciences et Technologie (UFR/ST) ; • L’Unité de Formation et de Recherche en Lettre Moderne, Sociologie et Histoire (UFR/LSH) ; • L’Institut des Médias ; • L’UFR des Sciences Juridiques, Politique, Économiques et de Gestion (SJPEG) • Le Centre Universitaire Polytechnique de Gaoua et de Banfora L’École Supérieure d’Informatique (ESI) créée en 1991 comprend deux (02) cycles à savoir le cycle des Ingénieurs de Travaux en Informatique (CITI) et le Cycle des Ingénieurs de Conception en Informatique (CICI). Le premier cycle comprend deux (02) filières qui sont L’Analyse et Programmation (AP) et Réseaux et Maintenance Informatique (RéMI). Ces deux filières sont devenues de nos jours Ingénierie des Systèmes d’Information (ISI) et Ingénierie des Réseaux et Systèmes (IRS). La formation pour chacune de ces filières s’étend sur trois (03) ans à la fin de laquelle un stage d’au moins trois (03) mois est obligatoire en entreprise. Pour l’IRS, le stage consiste à réaliser un rapport avec la maintenance et le réseau informatique. C’est à cet effet que nous avons été reçus à SOFTNET pour notre stage de fin de cycle tenu du 20 Août 2018 au 18 Novembre 2018. A l’issu de ce stage, nous avons élaboré ce présent rapport qui englobe le déroulement du projet. I II REMERCIEMENTS Au terme de ce stage qui s’achève sur une note de satisfaction de notre part, et nous l’espérons aussi de la part de la structure d’accueil. Il est important de remercier un certain nombre d’acteurs qui ont contribué à l’aboutissement du travail. • Nous remercions M. BORO Issa grâce à qui nous avons obtenu ce stage à SOFTNET ; • De l’administration de l’Université NAZI BONI (UNB) en particulier celle de l’École Supérieure d’Informatique (ESI) ; • De tout le corps enseignant de l’ESI, pour avoir assuré notre formation ; • La grande Famille ZERBO à Gounghin ; • De tous ceux ou toutes celles qui ont contribué d’une manière ou d’une autre à la réalisation de ce stage. • De tous les agents de SOFTNET pour l’encadrement, les conseils, le partage d’expériences et de ressources divers durant ces trois (03) mois au sein de l’Agence particulièrement à M. NAKOULMA et M. TRAORE qui nous amenais fréquemment sur le terrain pour nous apprendre bien de chose dans la maintenance des équipements et aussi M. SAGA qui nous aidais dans notre travail. Nous adressons tout particulièrement nos sincères remerciements à : M. OUEDRAOGO Maxime, Manager du département Réseaux et télécom à SOFTNET qui ont été notre encadrant et part son expérience dans le domaine nous a pousser à toujours effectuer le meilleur choix. M. ZOUGMORE Téeg-Wendé, enseignant à l’ESI, notre superviseur pour ses encouragements, sa disponibilité ; ses remarques pertinentes et enrichissantes. II III RESUME Pour assurer la disponibilité permanente de leur infrastructure informatique, les entreprises ont rapidement compris que la supervision était devenue une ressource-clé. Reçus le 20 août 2018, SOFTNET nous a confié la mise en place d’un outil de supervision de son système d’information à travers un stage de 03 mois, une solution qui va permettre la supervision complète de son parc informatique. Ainsi la solution SHINKEN a été retenue. Nous l’avons choisi après une étude comparative des outils de supervision qu’on trouve sur internet. Certains critères qui ont été considérés sont : logiciel libre, grandes performances, adaptabilité et fonctionnalités. L’outil déployé permet de contrôler tout type de système d’information. Cette solution peut se voir améliorée par l’ajout d’un système d’alerte et aussi une jointure avec le serveur asterisk afin d’avoir un système de notification très performante. En somme, l'objectif de ce stage est de coupler la puissance de SHINKEN au système d’information de SOFTNET que ces derniers pourront proposer à ses clients. III IV ABSTRACT To ensure the continued availability of their IT infrastructure, businesses quickly realized that supervision had become a key resource. Received on August 20, 2018, SOFTNET entrusted us with the implementation of a monitoring tool for its information system through an internship of 03 months, a solution that will allow the complete supervision of its computer park. So, the SHINKEN solution was chosen. We chose it after a comparative study of the supervision tools found on the internet. Some criteria that have been considered are: free software, great performance, adaptability and features. In short, the aim of this internship is to combine the power of SHINKEN with the SOFTNET information system that they can offer to their clients. IV V TABLE DES MATIERES AVANT-PROPOS ............................................................................................................................................ I REMERCIEMENTS ...................................................................................................................................... II RESUME ....................................................................................................................................................... III ABSTRACT .................................................................................................................................................... IV LISTE DES FIGURES ................................................................................................................................. VII LISTE DES TABLEAUX ............................................................................................................................ VIII SIGLES ET ABBREVIATIONS .................................................................................................................... IX INTRODUCTION GÉNÉRALE................................................................................................................... 1 CHAPITRE 1 .................................................................................................................................................. 2 PRESENTATION DU CONTEXTE DE STAGE ............................................................................................. 2 1.1. Introduction .......................................................................................................................................... 2 1.2. Présentation de l’ESI ........................................................................................................................... 2 1.3. Présentation de SOFTNET-BURKINA............................................................................................. 5 1.4. Présentation du projet ........................................................................................................................ 12 1.5. Conclusion .......................................................................................................................................... 14 CHAPITRE 2 ................................................................................................................................................ 16 ANALYSE DE L’EXISTANT ET DEMARCHE DE RESOLUTION........................................................... 16 1.1. Introduction ........................................................................................................................................ 16 1.2. Présentation de l’existant................................................................................................................... 16 1.3. Diagnostique de l’existant ................................................................................................................. 17 1.4. Démarche de résolution du problème .............................................................................................. 19 1.5. Conclusion .......................................................................................................................................... 20 CHAPITRE 3 ................................................................................................................................................ 22 GENERALITES SUR LES SOLUTIONS EXISTANTES .............................................................................. 22 3.1. Introduction ........................................................................................................................................ 22 3.2. Concepts généraux ............................................................................................................................. 22 3.3. Présentation des différentes solutions .............................................................................................. 31 3.4. Conclusion .......................................................................................................................................... 45 V VI CHAPITRE 4 ................................................................................................................................................ 46 PRESENTATION DETAILLEE DE LA SOLUTION RETENUE ............................................................... 46 1.1. Introduction ........................................................................................................................................ 46 1.2. Présentation de Shinken .................................................................................................................... 46 1.3. Conclusion .......................................................................................................................................... 55 CHAPITRE 5 ................................................................................................................................................ 57 IMPLEMENTATION TECHNIQUE .............................................................................................................. 57 5.1. Introduction ........................................................................................................................................ 57 5.2. Différentes installations ..................................................................................................................... 57 5.3. Configurations nécessaires ................................................................................................................ 62 5.4. Présentation des tests de fonctionnements ...................................................................................... 76 5.5. Bilan .................................................................................................................................................... 78 5.6. Conclusion .......................................................................................................................................... 79 CONCLUSION GENERALE ...................................................................................................................... 80 Références Bibliographique et webographie .................................................................................................. 81 ANNEXE A .................................................................................................................................................. 83 ANNEXE B .................................................................................................................................................. 84 VI VII LISTE DES FIGURES Figure 2 : Organigramme de SOFTNET .................................................................................................... 7 Figure 3 : Effectif en fonction des pays ................................................................................................... 8 Figure 4 : Planning prévisionnel ............................................................................................................ 14 Figure 5 : Principe de supervision ......................................................................................................... 24 Figure 8: Dashboard Cacti ..................................................................................................................... 34 Figure 9: Zabbix Dashboard.................................................................................................................. 36 Figure 10: Nagios Dashboard ................................................................................................................ 39 Figure 11: Centreon Dashboard ............................................................................................................. 41 Figure 12: EON Dashboard .................................................................................................................. 42 Figure 13 : Représentation de la supervision de SHINKEN .................................................................. 49 Figure 14: Architecture Interne de Shinken............................................................................................ 51 Figure 15 : Architecture de déploiement ................................................................................................ 54 Figure 16 : Résultat commande de vérification de l'état du serveur shinken............................................ 60 Figure 17 : Résultat commande sur l'état du service mongodb ............................................................... 61 Figure 18 : Contenue du fichier brokers-master.cfg................................................................................ 64 Figure 19 : Contenu du fichier admin.cfg .............................................................................................. 65 Figure 20 : Contenu fichier 1 snmpd.conf ............................................................................................. 67 Figure 21 : Contenu fichier 2 snmpd.conf ............................................................................................. 67 Figure 22 : Contenu fichier server_debian.cfg ...................................................................................... 68 Figure 23 : Contenu du fichier de groupe linux.cfg ............................................................................... 68 Figure 24 : Contenu du fichier linux_service.cfg ................................................................................... 69 Figure 25 : Installation de NSClient++ ................................................................................................... 70 Figure 26 : Contenu du fichier host srv-wind.cfg .................................................................................. 71 Figure 27 : Contenu fichier de groupe windows.cfg ............................................................................. 71 Figure 28 : Contenu fichier commande check_nt.cfg ........................................................................... 72 Figure 29 : Contenu fichier service windows_services.cfg .................................................................... 72 Figure 30 : Contenu fichier host imprimante_hp.cfg ............................................................................ 73 Figure 31: Contenu fichier groupe imprimante.cfg............................................................................... 73 Figure 32 : Contenue fichier de service imprimante_service.cfg .......................................................... 74 Figure 33 : Contenu fichier hosts switch.cfg ......................................................................................... 75 Figure 34 : Contenu fichier hosts router-one.cfg .................................................................................. 75 Figure 35: Contenu fichier service router_service.cfg .......................................................................... 76 Figure 36 : Shinken WebUI Login page.................................................................................................. 76 Figure 37 : Supervision Serveur Debian ................................................................................................ 77 Figure 38 : Supervision de Windows ..................................................................................................... 77 Figure 39 : Planning réel........................................................................................................................ 78 Figure 40 : Contenue fichier de notification email.cfg .......................................................................... 83 Figure 41 : Contenu fichier servicegroup bddservice.cfg ...................................................................... 83 Figure 42 : GNS3 VM preferences ......................................................................................................... 84 Figure 43 : Démarrage gns3 VM dans gns3 ........................................................................................... 85 Figure 44 : Machines virtuelles installer dans GNS3 ............................................................................. 85 Figure 45 : Architecture final chap5 ...................................................................................................... 86 VII VIII LISTE DES TABLEAUX Tableau 1 : Tableau des sigles et d'abréviations --------------------------------------------------------------------- IX Tableau 2 : Ressources matérielles ------------------------------------------------------------------------------------ 17 Tableau 3 : Ressources matérielles ------------------------------------------------------------------------------------ 20 Tableau 4 : Ressources logicielles -------------------------------------------------------------------------------------- 20 Tableau 5: Datagramme IP ----------------------------------------------------------------------------------------------- 29 Tableau 6 : Tableau comparatif des différentes solutions ------------------------------------------------------- 44 Tableau 7 : Coût de réalisation du projet ----------------------------------------------------------------------------- 55 Tableau 8 : Adressage des équipements------------------------------------------------------------------------------ 63 VIII IX SIGLES ET ABBREVIATIONS Le tableau 1 suivant fait référence aux sigles et abréviations que vous rencontrerez tout au long de la lecture du rapport. Tableau 1 : Tableau des sigles et d'abréviations 3D AGPL ANPTIC ANSSI API ASP BD CAR CEDEAO CGI Config(s) CPAN CPU DNS DT EON ESI FTP Gbic GPL HDD HP http HTTPS ICMP IP IRC IRS ISI ISO IT ITIL LDAP MIB M.TG NCSA NNTP 3 Dimensions Affero General Public License Agence Nationale de Promotion des TIC Agence Nationale de Sécurité des Systèmes d’Information Application Programming Interface Application Service Provider Base de Données Conception et Architecture des Réseaux Communauté Économique des États de l'Afrique de l'Ouest Computer Generate Images Configuration(s) Comprehensive Perl Archive Network Central Processing Unit Domaine Name Service Direction Technique Eyes Of Network École Supérieure d'Informatique File Transfert Protocol Gigabit Interface Converter General Public License Hard Disk Drive Hewlett-Packard HyperText Tranfert Protocol HyperText Tranfert Protocol Secure Internet Control Message Protocol Internet Protocol Internet Relay Chat Ingénierie des Réseaux et Systèmes Ingénierie de Système d'Information International Standard Organization Information Technology Information Technology Infrastructure Library Lightweight Directory Access Protocol Management Information Base Multi Router Traffic Grapher National Center for Supercomputing Applictions Network News Transfer Protocol IX X NRPE ONG OSI PERL PHP PNG PNP POP QoS RAID RAM RFC RRDTOOL SA SAD SGBD SMART SMS SMTP SNMP SSH SSL SSO TB TCP TLS UDP UML UNB VPN XML Nagios Remote Plugin Executor Organisation Non Gouvernementale Open Systems Interconection Practical Extraction and Report Language Hypertext Preprocessor Portable Network Grapics Plug-and-play Post Office Protocol Quality of Service Redundant Arraf of Inexpensive Disks Random Access Memory Request For Comment Round Robin Data Tool Société Anonyme Système d'Aide à la prise de Décision Système de Gestion de Base de Données Self-Monitoring, Analysis and Reporting Technologique Short Message Service Simple Mail Transfert Protocol Simple Network Management Protocol Secure Shell Secure Socket Layer Single Sign-On Tera Bytes Transmission Contrôle Protocole Transport Layer Security User Datagram Potocole Unified Modeling Langage Université NAZI BONI Virtual Private Network eXtensible Markup Language X 1 INTRODUCTION GÉNÉRALE Les notions de science et de technique se transforment à un rythme rapide depuis la grande révolution scientifique du 18ème siècle. Ces changements ont apporté une autonomie renouvelée et une forte dose d'innovation. Mais de nos jours, on parle plutôt des nouvelles technologies de communication et de l'information avec l'informatique qui devient de plus en plus incontournable. Science du traitement rationnel de l'information, l'informatique s'impose plus que jamais, comme un outil précieux dont a besoin toute entreprise qui veut accroître sa productivité et rester compétitive sur le plan international. Ainsi dans le domaine des entreprises modernes, l'adoption d'un système d’information facilite énormément les processus d'administration (personnelle et matérielle) et de productivité. Ce qui est le cas de notre structure d’accueil SOFTNET. En effet elle est équipée d’un vaste réseau dans lequel fonctionne un système d’information assez complexe. Cela implique la surveillance de ce système d’information est une opération indispensable afin de minimiser la perte d'exploitation et garantir le bon fonctionnement des équipements de chaque collaborateur de SOFTNET. La maîtrise du système d’information devient primordiale vu qu’il est au cœur des activités de SOFTNET et qu’il doit fonctionner pleinement et en permanence pour garantir la fiabilité et l'efficacité exigées, d'une part. D'autre part, les problèmes liés au système d’information tels que les défaillances, les pannes, les coupures et les différents problèmes techniques doivent être réduits, du fait qu'une indisponibilité du système ou du réseau peut causer des pertes considérables (image de SOFTNET vis-à-vis de ses clients, l’interruption de services…). Afin de palier à certains risques comme la perte d’une base de données, Il faut assurer la disponibilité, la pérennité et la proactivité des maintenances à travers la mise en place des mécanismes de supervision du SI. Ainsi le lien étroit existant entre la supervision du système d’information d'une entreprise et sa productivité suscite notre curiosité et justifie certainement le choix du thème d’étude : « Étude et mise en place d'un outil de supervision du système d’information de SOFTNET ». Ce document est un résumé de toutes les recherches et travaux effectués sur ce thème. Il est structuré en cinq (05) chapitres. Le premier chapitre présente le contexte du stage. Le second porte sur l’analyse de l’existant et la démarche de résolution. Le troisième expose les généralités des solutions de supervision et leur étude comparative. Le quatrième chapitre traite des détails de la solution retenue et enfin le cinquième porte sur l’implémentation technique de la solution. Finalement, nous terminons par une conclusion générale qui récapitule les principales observations concernant le travail réalisé 1 2 CHAPITRE 1 PRESENTATION DU CONTEXTE DE STAGE 1.1. Introduction Dans ce chapitre, nous présentons d’abord l’École Supérieure d’Informatique (ESI), notre école de formation et SOFTNET, la structure d’accueil et initiatrice du projet. Ensuite, nous mettrons en évidence la problématique liée à la supervision tout en évoquant les objectifs et les résultats attendus. Enfin, les acteurs du projet et le planning prévisionnel sont présents. 1.2. Présentation de l’ESI 1.2.1. Présentation générale L’École Supérieure d’Informatique (ESI) fait partie des huit (08) établissements d’enseignement et de recherche de l’Université NAZI BONI (Ex Université Polytechnique de Bobo Dioulasso). Elle est née en 1991 du besoin exprimé par le Premier Plan Directeur Informatique (1991-1995) « édification de compétences nationales par la formation de spécialistes (analystes et ingénieurs) concepteurs de système d’information ». D’abord implantée à Ouagadougou, l’ESI a ensuite été installée au sein de l’Université Polytechnique de Bobo-Dioulasso en septembre 1995. La première promotion de diplômes est sortie en juin 1993. On retrouve désormais des anciens élèves de l’ESI dans tous les secteurs de la vie économique. Autant les banques que les entreprises industrielles ou les prestataires de services informatiques, aussi que les mairies, ONG et administrations diverses. L’ESI délivre les diplômes de : Licence en informatique (BAC+3) • Option Système d’Information (SI) • Option Réseaux et Systèmes (RS) 2 3 Master en informatique (BAC+5) • Option Système d’Information parcours Système d’Aide à la Décision (SAD) • Option RS parcours Conception et Architecture des Réseaux (CAR) [1] 1.2.2. La licence en informatique 1.2.2.1. Objectifs Ce cycle a pour objectif de former des cadres moyens opérationnels et évolutifs dans une diversité de domaines d’application de l’informatique. La culture générale de ces ingénieurs de travaux informatiques est telle qu’elle leur permet de : ▪ dialoguer avec des utilisateurs d’horizons divers : concepteurs, gestionnaires, spécialistes de différents domaines techniques et scientifiques ; ▪ participer efficacement à la conception, la réalisation et la maintenance d’applications informatiques ; ▪ assurer la formation des utilisateurs ; ▪ gérer des centres informatiques ; ▪ etc. 1.2.2.2. Programme d’études Le programme d’études se déroule sur trois années académiques de trente semaines. Les enseignements se répartissent en trois pôles : ▪ Matériels et logiciels de base (23% du volume horaire total). Il concerne les enseignements portant sur l’architecture des ordinateurs, les principes de base qui régissent leur fonctionnement interne ainsi que les logiciels qui les accompagnent ▪ Formation générale (45% du volume horaire total). Il regroupe quatre disciplines : les mathématiques, l’anglais, les techniques d’expression française et la gestion/comptabilité/économie ; 3 4 ▪ Ingénierie des logiciels d’application (32% du volume horaire total). Il donne aux élèves les fondements de la programmation et les techniques d’ingénierie des logiciels d’application. Il se compose de trois groupes de matière : l’algorithmique, les outils de productivité (bureautique, SGBD etc.), les méthodes et outils d’aide à l’ingénierie des applications informatiques (UML, Java, Visual Basic, C…). [2] 1.2.2.3. Stages et projets en entreprise Le programme d’études est ponctué d’un stage de programmation en entreprise (8 semaines) à la fin de la deuxième année de formation et d’un projet de fin d’études (5 mois) portant sur des applications réelles proposées par des entreprises et administrations de la place en troisième et dernière année de ce cycle. 1.2.3. Le master en informatique Le Master de l’ESI offre aux étudiants la possibilité de se spécialiser en Système d’Information option aide à la prise de décision ou RS option architecture des réseaux. Ce cycle est ouvert aux titulaires d’une Licence en Informatique et la durée de la formation s’étend sur deux ans. 1.2.4. Mission de l’ESI L’ESI a pour mission : ▪ La formation fondamentale, appliquée et/ou professionnelle dans les domaines de l’informatique ; ▪ La recherche scientifique et technologique ainsi que la valorisation des résultats de la recherche ; ▪ La diffusion de la culture et de l’information dans les domaines relevant de sa compétence ; 4 5 ▪ La collaboration avec d’autres structures de formation et/ou de recherche pour la préparation des diplômes ; ▪ Et la participation à des programmes internationaux de formation et de recherche. L’ESI bénéficie pour la réalisation de ses enseignements du soutien des partenaires tels que : ▪ Université Ouaga 1 Pr Joseph KI -ZERBO ; ▪ Université Ouaga 2 ; ▪ Université de Norbert ZONGO ; ▪ Université Gaston BERGER (Sénégal) ; ▪ Agence Universitaire de la Francophonie ; ▪ Université Paris Dauphine (France) ; ▪ Université de Poitiers (France) ; ▪ Université Polytechnique de Catalogne (Espagne) ; ▪ Agence Nationale de Promotion des TICs (ANPTIC) ▪ Agence Nationale de Sécurité des Systèmes d’Information (ANSSI) 1.3. Présentation de SOFTNET-BURKINA SOFTNET-BURKINA SA est une société anonyme de droit Burkinabé inscrite au registre du commerce sous le N° RCCM BFOUA 2003 B1798. C’est une société d’Intégration de solutions informatiques disposant de filiales dans quatre (04) pays d’Afrique de l’Ouest à savoir le Burkina Faso, le Mali, le Niger et la Côte d’Ivoire mais s’adressant à une clientèle répartie dans la région Ouest et centre de l’Afrique. Elle est située à Ouagadougou sur 1017, l’avenue Kwamé Nkrumah et a un détachement à Bobo-Dioulasso. 1.3.1. Présentation 5 6 Créé en 2003, SOFTNET GROUP a capitalisé une somme d’expériences et de compétences reconnues qui l’ont positionné comme l’un des acteurs majeurs des solutions intégrées IT en Afrique de l’Ouest et du centre. SOFTNET intervient principalement dans les domaines des Infrastructures Réseaux et Télécommunications, de l’ingénierie Logicielle, des infrastructures Systèmes et Sécurité, des Services à valeur Ajoutée ainsi que dans celui des Formations et du Consulting. Pour maintenir sa croissance tout en continuant de fournir des services de qualité, elle s’est dotée d’une organisation à l’échelle du groupe avec des ressources humaines et techniques de haut niveau (Confère organigramme). SOFTNET Group a participé à l’amélioration des performances et de la compétitivité des organisations publiques et des entreprises de l’Afrique en offrant l’ensemble de ses capacités et de ses services pour accompagner l’essor des pays où elle opère afin de devenir l’un des acteurs majeurs de leurs dynamiques de croissance. La vision globale de SOFTNET GROUP est de devenir leader dans son domaine d’activité afin d’être l’interlocuteur sûr et fiable dans implémentation de solutions informatiques ainsi que dans la conception d’application spécifique conforme à l’esprit des chefs d’états de la CEDEAO pour le rayonnement de l’Afrique. Ses efforts soutenus, engagés pour répondre aux attentes de ses clients et partenaires lui ont d’ailleurs valus de recevoir de nombreuses distinctions parmi lesquelles le prix HP Fastest Growing WCA Partner 2010 et les prix Microsoft WECA et COUNTRY Partner of the Year 2012, 2014, 2015 & 2016 En permanence disponible pour assurer un suivi technique de haut niveau et anticiper vos attentes fait partie intégrante de nos engagements. SOFTNET GROUP travaille chaque jour pour maintenir ses engagements vis-à-vis de sa clientèle. [3] 1.3.2. Organisation de SOFTNET 6 7 L’organigramme de SOFTNET représenté ci-dessous par la figure 2 Softnet Busness Solution (SBS) SOFTNET Network et Systeme Infrastructure(SNSI) Business Unit SOFTNET Training Center (STC) President Directeur General Directeur de Filiale SOFTNET Support Et Managment Services (SSMS) DGA SOFTNET Business Analystis et Bid Center(SBABC) Direction Commerciale SOFTNET product et Cloud Services(SPCS) SOFTNET Business Account Manager(SBAM) Finance/ Comptabilité DFC Administration et Finances Achat/Logistique DRH Figure 1 : Organigramme de SOFTNET 1.3.3. Les effectifs La figure 3 illustre les effectifs par pays 7 8 Effectifs Par pays 9% 4% SOFTNET BF 10% SOFTNET CI SOFTNET MALI SOFTNET NIGER 77% Figure 2 : Effectif en fonction des pays SOFTNET Burkina compte à elle seule 62 travailleurs qui sont basés au Burkina soit 77% de l’effectif total des travailleurs du groupe ; cela s’explique essentiellement par le fait que SOFTNET Burkina est également le siège du groupe SOFTNET et aussi elle est la première filiale créée en 2003. 1.3.4. Présentation des activités des différentes directions Nous distinguons cinq directions dont nous allons essayer de présenter leurs activités. 1.3.4.1. La direction technique Elle est chargée de l’exécution de tous les projets obtenus. Pour ce faire elle dispose de techniciens qualifiés dans les différents domaines tels que le Génie Logiciel, les infrastructures réseaux et télécom, les infrastructures systèmes et sécurité ainsi que la maintenance. Pour l’exécution de chaque projet, une équipe projet est définie mais il n’est pas exclu de voir des personnes travailler sur plusieurs projets à la fois. 8 9 La Direction technique fournit également des formateurs dans le cadre des activités des différents centres de formations du groupe. La DT en collaboration avec le Chef de Département Avant-vente fait des propositions de solutions adaptées aux besoins des clients. La Direction technique participe à la présentation et aux démos de nouvelles solutions auprès des clients pour susciter de nouveaux besoins. La DT assiste la Direction Financière, comptable et du budget dans le sens que ce sont les techniciens qui communiquent les taux d’exécution des projets pour pouvoir demander des comptes à la fin du projet, ils doivent veiller à la signature des différentes attestations pour la clôture du projet. Nous avions effectué notre stage au niveau de la DT durant tous les 03 mois de stage. 1.3.4.2. La direction des opérations commerciale Elle est chargée de la définition et de la mise en œuvre de la stratégie commerciale et Marketing de la société. Elle est le garant de l’atteinte des objectifs chiffrés de la société. La Direction des Opérations commerciales coordonne les activités de réponses aux appels d’offres. Elle est dotée d’un département Gestion des Offres et d’un département avant-vente qui veillent au bon déroulement du montage des dossiers. Elle dispose également d’une équipe de commerciaux chargée de conquérir le marché auprès des certains clients particuliers et aussi de faire la promotion des produits et services offerts par SOFTNET. La Direction commerciale s’occupe également de la négociation et du renforcement des partenariats entre SOFTNET et d’autres sociétés. 9 10 1.3.4.3. La direction financières, comptable et du budget Elle est chargée de l’élaboration et du contrôle de l’exécution du Budget de la société ; elle s’occupe également de la gestion financière et comptable de la société par la disponibilité des ressources financières et l’utilisation adéquate de ces ressources par la planification des activités. Elle s’assure du recouvrement auprès des clients pour permettre à la société de faire face à ses engagements vis-à-vis des fournisseurs et des banques. Elle dispose d’une équipe composée du chef de département, le chef comptable, un comptable, un agent de recouvrement et une caissière. 1.3.4.4. La direction administrative et des ressources humaines Elle est chargée de la gestion administrative de la société notamment le traitement de l’information, la réponse aux courriers, la gestion administrative quotidienne, la représentation de la société, la gestion des polices d’assurances, la gestion du parc roulant ainsi que l’organisation administrative de la société. Elle connait des questions du personnel notamment le recrutement, la formation, la gestion carrières, les avancements, la paie, la relation entre la société les institutions de prévoyance sociales. 1.3.4.5. Le département des achats et logistique Il est chargé de satisfaire tous les besoins en équipe de la société et pour l’exécution des projets. Il est le principal interlocuteur des fournisseurs nationaux comme étrangers. Il veille au bon acheminement des pièces depuis la commande jusqu’à l’arrivée. Il s’occupe des formalités de transit et de douanes. C’est le département achat et logistique qui s’occupe également de la facturation des clients ainsi que le suivi du stock de matériel de la société. Pour la réalisation de ses attributions le 10 11 département est composé d’un chef de Département, d’une Administratrice des ventes, d’un agent de transit et d’un magasinier. 1.3.5. Services offerts SOFTNET propose une prestati1on de services professionnels de haut niveau en matière de systèmes d’information informatisée. La mise en place de solutions informatiques nécessite une expertise dans chacun des services proposés. De l’Ingénierie à la Maintenance des Systèmes et Réseaux, sans oublier Internet et les services connexes, SOFTNET offre l’ensemble des prestations associées à l’informatique distribuée : ➢ Conseils et conception en architectures systèmes et réseaux : Rédaction de Cahier de Charges, conduite de projets ▪ Support technique matériel, logiciel et réseaux ; ▪ Assistance informatique sur site ; ▪ Formation (Centre de Formation) ; ▪ Formation et délégation de personnel en régie. ➢ Systèmes d’Information ▪ Test et validation de connaissances métiers (centre de Test) ; ▪ Assistance (Centre de Maintenance agréé HP) ; ▪ Développement d’applications informatiques sur mesure ; ▪ Audit et Sécurité des systèmes et réseaux ; ▪ Câblage réseaux en cuivre et fibre optique. SOFTNET assiste ses clients dans leur choix d’organisation et d’implémentation. Elle assure également la mise en œuvre des produits choisis, avec une gamme complète de services de bout en bout autour de chaque produit. Il ne faut pas non plus oublier que SOFTNET est également partenaire avec de grandes firmes comme : HP, Microsoft, CISCO, APC, Symantec… qui lui permet de bien se positionner pour couvrir les besoins en équipements de hautes technologies et en 11 12 solutions de pointe mais aussi de former et de délivrer des certifications de compétence des éditeurs, des leaders de logiciels, des leaders de réseaux etc. [4] 1.4. Présentation du projet 1.4.1. Problématique Dans le monde de l’entreprise, il existe une multitude de système d’information à surveiller. Pour autant, l’activité de supervision de ce système d’information n’est pas toujours remplie efficacement et on préfère souvent se consacrer à des tâches plus urgentes liées à la production. Tout utilisateur veut pouvoir constamment accéder à internet, lire ses mails ou encore imprimer. Il faut donc que les éléments du système d’information communiquent entre eux à l’intérieur de l’entreprise comme à l’extérieur, avec le client comme entre collègues. Toutes pertes de données ou interruptions de service peut avoir de graves conséquences qui vont de la simple perte de temps au lourd impact financier, que ce soit une perte réseau ou un disque dur plein, on ne peut pas échapper aux erreurs. De plus l’administrateur système n’a pas la capacité physique de vérifier tous les ordinateurs de tous ses clients. La supervision des systèmes d’informations est devenue, de par l’importance croissante des entreprises, un besoin stratégique. Si on se rappelle qu’un système d’information est un ensemble d’éléments participant à la gestion, au traitement, au transport et à la diffusion de l’information au sein de l’organisation et qu’il s’appuie très souvent sur un système d’informatique et toute une infrastructure réseau. SOFTNET veut tester des solutions de supervision pour les proposer à ses clients si elles sont concluantes, cela dans le but de permettre à leur client un meilleur suivi de leurs parc informatique afin de prévenir des pannes et même des attaques sur leur réseau. C’est ainsi qu’il nous a été confié le travail de mettre en place un outil de supervision. 1.4.2. Objectif et résultats attendus 12 13 L’objectif de notre étude est la supervision. Il en suit aussi de pouvoir conserver le contrôle du point de vue technique et applicatif. Les attentes pour cette étude sont : ➢ Supervision générale des équipements; ➢ Visibilité en temps réel du réseau et des ressources dont dispose un équipement, ce qui permettra d’avoir des informations rapidement, de connaitre l’état du réseau et ses performances ; ➢ Garantie de la disponibilité des services ; ➢ Remontées d’alertes en cas de détection d’incidents ; ➢ Proactivité et réaction en cas de panne ; 1.4.3. Gestion du projet Pour bien mener ce projet tout en respectant l’engagement contracté en tenant compte des délais impartis et en produisant les résultats escomptés, le projet a été organisé en fonction des points suivants. 1.4.3.1. Acteurs du projet Un projet associe un ensemble d’acteurs qui influencent directement ou indirectement le déroulement de celui-ci. Ils peuvent être moteurs, décideurs mais aussi opposants. Ils sont répartis en deux groupes dont le groupe de pilotage et le groupe de projet. 1.4.3.1.1. Groupe de pilotage Il assure la coordination technique et contrôle la pertinence des solutions proposées et est composé de : ➢ M. Ouédraogo Maxime, Consultant Ingénieur Télécommunication à SOFTNET et notre maitre de stage. 13 Réseaux et 14 ➢ M. Zougmoré Téeg-Wendé G, enseignant à l’ESI, notre superviseur. 1.4.3.1.2. Groupe de projet C’est la cheville ouvrière du projet. Il est chargé : ➢ De mener à bien les travaux dans les délais impartis ; ➢ D’assurer la cohérence et la faisabilité de la solution retenue ; ➢ Et de rendre compte au comité de pilotage en présentant les rapports d’évolution. 1.4.3.2. Le planning prévisionnel Le planning prévisionnel est un outil de communication qui permet d’illustrer de façon synthétique le planning des travaux et l’affectation des ressources aux différentes tâches. Nous avons adopté dans les premiers instants de notre projet, le planning figurant dans le diagramme de Gantt : Figure 3 : Planning prévisionnel 1.5. Conclusion Dans ce chapitre, nous avons présenté l’ESI notre école de formation, ensuite la structure d’accueil et pour finir nous avons fait une présentation de notre projet. 14 15 Dans le chapitre prochain, nous ferons une analyse de l’existant et une présentation de la démarche de résolution du problème qui a été posé ainsi que les moyens mis à notre disposition pour la réalisation du projet. 15 16 CHAPITRE 2 ANALYSE DE L’EXISTANT ET DEMARCHE DE RESOLUTION 1.1. Introduction L’étude de l’existant a eu comme résultat la connaissance du système d’information actuel de SOFTNET au travers le recensement de ces aspects positifs et aspects négatifs. Ainsi ce chapitre mettra en exergue d’abord l’évaluation des ressources (logicielles et matérielles) entrant dans le cadre de notre étude afin de mener une analyse critique de la situation actuelle. Il s’agira ensuite de faire un diagnostic du réseau afin de faire ressortir ces atouts et ses faiblesses. Enfin nous présenterons les démarches suivies afin de résoudre aux problèmes qui seront énumérés. 1.2. Présentation de l’existant 1.2.1. Les ressources logicielles Les ressources logicielles de SOFTNET se présentent comme suit : • Les systèmes d’exploitation constituer de : Linux, Windows, MAC • Les différents services installés sur les serveurs sont : la messagerie, le DNS, les applications métiers, la téléphonie sur IP. 16 17 1.2.2. Les ressources matérielles Les éléments qui composent les ressources matérielles de la structure se présentent comme suit dans le tableau 2 : Tableau 2 : Ressources matérielles Désignation Tâche Nombre Permettre aux utilisateurs d’accéder aux Poste de travail Serveur Téléphonie IP Imprimantes, scanner et photocopieuses Pour les centres de formations. 30 Assure la disponibilité des services locaux. 10 Permettre de faire des appels au sein de l’intranet de l’entreprise. 1 NR Permettent l’impression, le scannage et la photocopie de tout fichier format numérique NR ou papier. Switch, routeur, hub, Permet antennes équipements du parc informatique. l’interconnexion Protection Onduleur 15 ressources de l’entreprise. des des équipements différents contre NR les microcoupures, les surtensions et les sous- NR tensions. 1.3. Diagnostique de l’existant 1.3.1. Les aspects positifs Le système d’information de SOFTNET a une protection physique sur ses équipements que l’on peut apprécier positivement sur les points suivants : ➢ L’existence d’un locale approprié pour les serveurs ; 11 NR : Non Renseigné 17 18 ➢ L’existence d’un système de climatisation permettant de maintenir chaque salle dans la température ambiante ; ➢ Des caméras de surveillance dans la salle serveur ; ➢ Un capteur de température permettant de notifier l’administrateur réseau d’une éventuelle surchauffe de la salle serveur ; ➢ L’absence de tout produits ou matières facilement inflammables ; ➢ L’installation électrique composé d’éléments comme des onduleurs, groupe électrogènes, parafoudre, paratonnerre, fusible. Tous ces éléments protègent les équipements informatiques contre d’éventuels accidents liés au courant électrique ; ➢ Les sauvegardes : très primordiales surtout pour leurs clients car ils peuvent à n’importe quel moment faire des restaurations de ces données en cas d’incidents comme les attaques contre le système et ou le crash d’un de leur disque dur. Sur le plan logique nous avons pu relever : ➢ La mise en place de pare-feu pour la protection du réseau et des données qui y transitent ; ➢ Les antivirus contre les attaques à l’interne du réseau. L’accès au réseau internet est soumis à une restriction de l’accès à certains site web distractif ou malveillants lors des heures de travail afin d’éviter des déconcentrations chez les employés et d’évité les intrusions ou attaques des sites web malveillants. 1.3.2. Les aspects perfectibles Le système informatif de SOFTNET regorge un certain nombre de faille que l’on a peut recenser : ➢ Le manque de panneau interdisant l’accès à certains locaux ; ➢ L’absence d’un registre de renseignement papier ou numérique des entrées et sortie de chaque personne en entreprise ; 18 19 ➢ Une meilleure solution d’outil de supervisions du système d’information de SOFTNET. 1.3.3. Suggestion de solutions Pour mieux gérer les équipements informatiques de la structure, les mesures suivantes peuvent être envisagées : ✓ Sensibiliser tout le personnel administratif sur la supervision des équipements informatique afin de faciliter leur collaboration ; ✓ Mettre en place un canal de connexion pour l’échange de donné entre SOFTNET et ses clients ; ✓ La mise en place d’un meilleur outil de supervision du système d’information. 1.4. Démarche de résolution du problème 1.4.1. Méthode utilisée Dans le but de pouvoir régler le problème de supervision du parc informatique de la structure, nous avions suivi une étude comparative ayant pour objet de choisir l’outil de supervision adéquat pour nos besoins. L’outil choisi, nous sommes passés à son étude et son implémentation sur un environnement de test avant de la tester sur l’environnement de production. 1.4.2. Moyens technique nécessaires Afin de mener à bien notre étude, nous avions eu besoin d’un environnement de travail assez convivial. Ainsi les ressources qui étaient présente sont les suivantes : Ressources matérielles 19 20 Ci-contre le tableau 3 regroupant les ressources matérielles mises à notre disposition tout au long du déroulement du stage. Tableau 3 : Ressources matérielles Désignation Caractéristiques HP Laptop Intel Dual core, 4Go de RAM, 500 HDD HP laptop Core i7, 4Go de RAM, 500 HDD Ressources logicielles Ci-dessous le tableau 4 regroupant les ressources logicielles Tableau 4 : Ressources logicielles Nom du Logiciel Éditeur Licence VMware Workstation VMware Gratuite Gns3 Plan C Technologies Gratuit Mozilla Firefox Mozilla Foundation Gratuit Fonction Outil de virtualisation de poste de travail, utilisé pour mettre en place un environnement de test pour développer de nouveaux logiciels, ou pour tester l'architecture complexe d’un système d’exploitation Émulateur permettant la virtualisation des équipements réseaux et la mise en place d’un réseau physique en milieu virtuel Navigateur web libre permettant d’effectuer des recherches sur internet [5] 1.5. Conclusion Nous pouvons conclure en mettant en exergue le fait que l’étude de l’existant a permis de connaitre la structure SOFTNET dans la plupart de ses aspects. Quant à la phase du diagnostic de l’existant, elle a permis de faire ressortir les forces et les insuffisances de la structure afin de pouvoir éventuellement proposer des solutions pour la bonne gestion des équipements de système informatiques. 20 21 21 22 CHAPITRE 3 GENERALITES SUR LES SOLUTIONS EXISTANTES 3.1. Introduction Ce chapitre est rédigé en trois parties et fournit les clés de compréhension du projet. La première partie expose les concepts généraux entrant dans le cadre de notre étude. Le second présente les différentes solutions que nous avons trouvées. Enfin, la troisième partie présente une étude comparative effectuée dans le but de trouver une solution répondant aux attentes exprimées par SOFTNET. 3.2. Concepts généraux 3.2.1. Définition La supervision informatique est une technique de surveillance, d’analyses et d’alertes permettant de palier les problèmes liés à tous les niveaux de fonctionnement informatique d’une entreprise. Elle rend l’entreprise plus performante et surtout proactive. Elle doit répondre aux préoccupations suivantes : • Technique : surveillance du réseau informatique, de l’infrastructure de l’entreprise ; • Fonctionnelle : surveillance des machines informatiques et de production ; • Applications : suivis des applications dans le cadre d’un processus métier. 3.2.2. Principes de fonctionnement de la supervision 3.2.2.1. Fonctionnalités de la supervision 3.2.2.1.1. La surveillance La surveillance informatique résulte de ce que l’on appelle monitoring qui est une activité de mesure d’une activité informatique. La surveillance des équipements d’une infrastructure est la fonctionnalité de base, proposée par les différents outils de supervision du marché. Ils permettent de surveiller : 22 23 • Les ressources d’un équipement informatique • Le trafic réseaux ; • Les attaques liées au réseau ; • Les flux de donnée entre application. [6] 3.2.2.1.2. Les notifications La notification est employée pour décrire des fonctions d’alerte automatisées entre processus. Mais lorsqu’un incident est détecté, il faut autoriser la réception des notifications informant ainsi qu’un changement d’état vient d’avoir lieu. Ce genre d’évènements est généralement distribué par messagerie, ou par SMS et/ou 2IRC. Il est même possible de distribuer sélectivement les notifications à un autre groupe d’utilisateurs bien défini, en fonction des plages horaires programmées et de répéter cet envoi plusieurs fois lorsque la réparation, ou l’acquittement, n’est pas réalisé au bout d’un certain laps de temps. [7] 3.2.2.1.3. Les sondes Généralement, les outils de supervision n’effectuent pas eux-mêmes la surveillance de certains composantes : mémoire, CPU, disques… Ces composantes sont, la plupart du temps, constitutives de scheduler (ou ordonnanceurs) déléguant cette tâche à des sondes. Concrètement, les sondes sont des scripts, des programmes ou plus généralement du code, appelés par le scheduler, qui effectuent l’ensemble des traitements de vérification et envoient leurs résultats afin de centraliser les informations récoltées. On doit donc pouvoir ajouter facilement des sondes en s’appuyant sur les différentes extensions (ou plugins) disponibles. 3.2.2.1.4. 2 Les dépendances IRC : Internet Relay Chat, Serveur permettant de dialoguer en direct avec plusieurs personnes 23 24 Il est primordial que les différents équipements conservent leur interdépendance au sein de l’outil de supervision. Si l’on prend l’exemple des bases de données, des switchs et des serveurs : le mode opérationnel est vérifié lorsque les bases de données hébergées sur les serveurs sont opérationnelles et que les switches interconnectant les serveurs sont également en fonction. Ainsi, en précisant la dépendance des serveurs vis-à-vis des bases de données et des switches vis-à-vis des serveurs, on peut alors notifier les cas de pannes. Et cela facilite la détection d’incidents en se concentrant sur l’essentiel de l’information, la panne de l’équipement interdépendant, plutôt que sur l’ensemble des machines en alerte. Cela permet de mieux mettre en évidence l’équipement ou le service en défaut et de faciliter le troubleshooting et la maintenance. 3.2.2.2. Principe de la supervision Le principe de la supervision est de s'assurer du bon fonctionnement d'un système. En sommes, superviser n’est pas seulement surveiller, encore faut-il pouvoir alerter et analyser les données collectées sur les équipements afin d’être proactif et plus uniquement réactif. On peut résumer la supervision par le graphe de la figure 5 suivante : Surveiller Visualiser Alerter Analyser Figure 4 : Principe de supervision [5] 3.2.2.2.1. Supervision système 24 25 Ce type de supervision s’applique à surveiller essentiellement l’ensemble des ressources des différents systèmes d’exploitation : mémoire RAM, stockage de masse, type de RAID. 3.2.2.2.2. Supervision réseau Ici, on cherche essentiellement à surveiller les équipements réseau tels que les commutateurs, les routeurs… L’idée est de s’assurer que ces équipements sont opérationnels, qu’aucun port ou GBic (Gigabit interface Converter) n’est défectueux et que les interconnexions sont effectives. En outre, elle porte sur la surveillance de manière continue de la disponibilité des services du fonctionnement, des débits, de la sécurité mais également du contrôle des flux. 3.2.2.2.3. Supervision sécurité On peut également aller jusqu’à surveiller les attaques contre le système d’information de l’entreprise. C’est généralement dans ce cadre qu’intervient ce type d’activité, mettant en place l’ensemble des contre-mesures, scrutant et analysant les différents accès et permettant de détecter les tentatives d’intrusions. 3.2.2.2.4. Supervision applicative La supervision des applications (ou supervision applicative) permet de connaître la disponibilité des machines en termes de services rendus en testant les applications hébergées par les serveurs. La supervision applicative passe par des mesures faites aussi sur le flux de service. On parle alors de validation fonctionnelle. On utilise souvent un sous-ensemble des tests ayant permis la recette d'une application pour n'en prendre que les tests qui sont représentatifs de l'activité sans pour autant générer une charge trop importante ou modifier les données applicatives. La supervision applicative ne peut se faire sans considérer la sécurité applicative 25 26 3.2.2.2.5. Supervision métier De façon plus générique, on s’intéresse ici à la supervision des différents processus métier. En effet, un métier peut dépendre de plusieurs applications. Il faut donc s’assurer que celles-ci sont bien toutes actives et en bon état de fonctionnement. 3.2.3. La norme ISO ISO s'intéresse de près à la supervision. Dès 1988, l'organisme a publié la norme ISO7498/4 définissant les principales fonctions que doivent implémenter les systèmes de supervision et d'administration. Ces fonctions sont : ➢ Gestion des performances ; ➢ Gestion des configurations (Management configuration) ; ➢ Gestion de la comptabilité (Accounting Management) ; ➢ Gestion des anomalies (Fault Management) ; ➢ Gestion de la sécurité (Security Management). 3.2.3.1. Gestion des performances Un système de supervision répondant aux normes doit analyser de manière continue les performances du réseau comme l’état des ports d’un switchs. Il doit pouvoir évaluer les performances des ressources du système ainsi que leur efficacité. Le système doit comporter des procédures de collecte de données et de statistiques qui aboutiront à l’établissement de tableaux de bord. Les informations recueillies doivent aussi permettre de planifier les évolutions du réseau. 3.2.3.2. Gestion des configurations 26 27 La gestion de configuration doit permettre d’identifier, de paramétrer et de contrôler les différents objets du réseau. Les procédures requises pour gérer une bonne configuration sont : ➢ La collecte d’information ; ➢ Le contrôle d’état ; ➢ La sauvegarde historique de configurations de l’état du système. 3.2.3.3. Gestion de la comptabilité La gestion de la comptabilité mesure l'utilisation des ressources afin de réguler les accès et d'instaurer une certaine équité entre les utilisateurs du réseau. Ainsi des quotas d'utilisation peuvent être fixés temporairement ou non sur chacune des ressources réseaux. 3.2.3.4. Gestion des anomalies La gestion des anomalies détecte les problèmes réseaux (logiciels ou matériels). Elle essaie d'isoler le plus précisément le problème en effectuant divers tests. Quand cela est possible, elle règle elle-même automatiquement l'anomalie. Sinon, elle alerte les personnes concernées du type de problème afin de solliciter leur intervention. La gestion des anomalies garde dans une base de données l'ensemble des problèmes survenus ainsi que leur solution, de manière à être encore plus efficace face à un incident récurrent. La gestion des anomalies permet donc la détection, la localisation et la correction d’anomalies passagères ou persistantes. 3.2.3.5. Gestion de la sécurité 27 28 La gestion de la sécurité contrôle l'accès aux ressources en fonction des politiques de droits d'utilisation établies. Elle veille à ce que les utilisateurs non autorisés ne puissent pas accéder à certaines ressources protégées. La gestion de la sécurité met donc en application les politiques de sécurité. [8] 3.2.4. Les protocoles utilisés [9] 3.2.4.1. Protocole TCP/IP La suite TCP/IP (Transmission Contrôle Protocole/ Internet Protocol) est l'ensemble des protocoles utilisés pour le transfert des données sur Internet. Elle a été créée pour palier à certains problèmes du modèle OSI qui n'offre pas une richesse suffisante au niveau des couches basses pour représenter la réalité ; il est nécessaire d'ajouter une couche supplémentaire d'interconnexion de réseaux (Internet working) entre les couches Transport et Réseau. Afin de superviser les équipements du parc informatique qui rentre fréquemment sur internet, il faut en réalité surveiller le bon fonctionnement des ports de services TCP/IP. Comme on l’a mentionné plus haut, l’art de la supervision consiste non seulement à surveiller les équipements et leur bon fonctionnement, mais également l’ensemble des services connus ainsi que leurs ports de communication. Il est donc essentiel de les connaître et de comprendre le fonctionnement des différentes fonctions utilisées par les applications pour remonter les notifications en temps voulu. L’intérêt du protocole dans la supervision n’est pas vraiment mis en exergue. Je vois juste une définition de TCP/IP [10] 28 29 3.2.4.2. Protocole ICMP Une des commandes les plus utilisées lors de l’exercice de supervision est la commande ping. Il s’agit d’un petit programme s’appuyant sur le protocole ICMP (Internet Control Message Protocol) décrit dans la RFC 792, permettant de déterminer l’accessibilité d’un équipement en analysant ses messages de contrôle et d’erreur. ICMP est un protocole de niveau 3 sur le modèle OSI, qui permet le contrôle des erreurs de transmission. En effet, comme le protocole IP ne gère que le transport des paquets et ne permet pas l'envoi de messages d'erreur, c'est grâce à ce protocole qu'une machine émettrice peut savoir qu'il y a eu un incident de réseau. Bien qu'il soit à un niveau équivalent au protocole IP (si l'on tente de rapprocher le modèle OSI au modèle TCP/IP), un paquet ICMP est néanmoins encapsulé dans un datagramme IP. Dans le cadre de l'IPv4, la forme générale d'un tel paquet est représentée par le tableau 4 suivante : Tableau 5: Datagramme IP Bit 0 - 7 Bit 8 - 15 Bit 16 - 23 Version/IHL Type de service Identification (fragmentation) Bit 24 - 31 Longueur totale flags et offset (fragmentation) Durée de vie Protocole Somme de contrôle de l'en-tête (TTL) Adresse IP source Adresse IP destination Type de message Code Somme de contrôle Bourrage ou données 29 30 Données (optionnel et de longueur variable) Un tel datagramme est composé : • D'un en-tête IP (en bleu), avec Protocole valant 1 et Type de Service valant 0. • Du type de message ICMP (8 bits) • Du code de l'erreur (8 bits) • D'une somme de contrôle (16 bits), calculée sur la partie spécifique à ICMP (sans l'en-tête IP) • D'une partie aménagée pour des données relatives aux différents types de réponses (32 bits), Si elle n'est pas utilisée, on procède à un bourrage (cette partie peut correspondre aux Identifiant et Numéro de séquence pour un paquet de type Ping par exemple) • Du message [11] 3.2.4.3. Protocole SNMP Le protocole SNMP (Simple Network Management Protocol) décrit dans la RFC 1157 est également essentiel à la surveillance d’infrastructure. Il s’agit d’un protocole de communication permettant aux administrateurs du réseau de gérer l’ensemble des équipements, de les superviser et de diagnostiquer d’éventuels problèmes à distance. Les systèmes de gestion de réseau sont basés sur trois éléments principaux : un superviseur (manager), des nœuds (nodes) et des agents. Ce protocole permet donc de savoir si un équipement est joignable ou non depuis le réseau d’entreprise. Commutateurs, concentrateurs, routeurs, postes de travail et serveurs (physiques ou virtuels) sont des exemples d'équipements contenant des objets gérables. Ces objets gérables peuvent être des informations matérielles, des paramètres de configuration, des statistiques de performance et autres objets qui sont directement liés au comportement en cours de l'équipement en question. Ces équipements sont alors classés dans une espèce de base de données arborescente 30 31 appelée MIB (Management Information Base). Le protocole SNMP autorise ainsi le dialogue entre le manager et les agents afin de recueillir les objets à gérer au travers la MIB. [12] 3.3. Présentation des différentes solutions 3.3.1. Critère de comparaison Nous allons donc étudier sept (07) solutions open-source en matière de supervision qui se veulent assez complètes. Cette étude ressemble à un banc d'essai puisque pour chacun des logiciels nous allons : • Faire une courte présentation et expliquer son fonctionnement ; • Faire le tour des fonctionnalités puis finir sur les avantages et inconvénients. 3.3.1.1. NetMRG 3.3.1.1.1. Présentation Créé en 2001, NetMRG veut se distinguer des autres en proposant des petites améliorations : Visualisation des graphiques avec historiques et "auto-scroll", utilisation de modèles (Templates) pour plus facilement ajouter de nouveaux graphiques, mise à jour du logiciel simplifiée, Gestion des jours de travail. L'architecture logicielle est découpée en composants : • Un moteur C++ chargé de récolter les données. Conçu dans le but de supporter une charge conséquente. Ce moteur est au cœur de l'application, il ordonnance les tâches et gère les interactions en plus de son rôle de "récolteur". • RRDTOOL composant vu précédemment qui apporte sa puissante gestion des données ainsi que ses atouts indéniables en matière de génération de graphique. • Une base de données MySQL permettant de sauvegarder la configuration. 31 32 • Une interface réalisée grâce à PHP, qui permet de modifier la configuration et d'afficher les graphiques au format PNG générés par RRDTOOL. Pour retrouver les graphiques on doit tout d'abord passer par un arbre qui organise les différentes machines et statistiques associées. Ce "Device Tree" affiche tout d'abord des groupes (Group) lesquels contiennent des machines (Device), puis on accède aux différents services ou valeurs monitorées (Sub device) avant de trouver à l'intérieur les graphiques (Monitors). Des "events" sont également visibles en cas de problème. 3.3.1.1.2. Avantages ✓ Performances : L'application semble pouvoir tenir la charge avec énormément de machines surveillées grâce au moteur multi-threadé ; ✓ Alarmes : Il est possible de configurer des évènements qui avertissent l'administrateur d'un fonctionnement anormal ; ✓ Gestion des utilisateurs dans la surveillance de leurs activités. 3.3.1.1.3. Inconvénients o Interface : L'interface n'est pas très accueillante et est déroutante au début ; o Configuration : Il n'est pas très aisé d'ajouter de nouveaux équipements à surveiller si l'on sort du cadre du Template prédéfinie ; o Un développement lent, peu de versions et très espacées dans le temps ; o Aucune gestion de carte de réseau, et aspect rudimentaire des alarmes. Aucune gestion de panne. 3.3.1.2. Cacti 3.3.1.2.1. Présentation 32 33 Tout comme NetMRG, Cacti se base sur RRDTOOL et se présente lui-même comme étant l'interface la plus complète à celui-ci. Cacti utilise également une base MySQL pour stocker la configuration. Depuis la version 0.8.6, Cacti propose un moteur de récolte des données en C, nommé Cactid, utilisant avantageusement les Threads POSIX. Une stratégie qui ressemble étrangement à celle réalisée par NetMRG sauf que Cacti propose de l'utiliser seulement si vous avez réellement besoin de performances (dans le cas contraire c'est le moteur PHP qui prend le relais). On retrouve les mêmes fonctionnalités que NetMRG : Sources de données multiples via scripts dans de multiples langages, gestion des utilisateurs et ajout d'équipement à partir de modèles (templates)de configuration. L'interface est divisée en deux, une partie nommée "Console" permettant de tout configurer et une autre nommée "Graphs" permettant d'afficher les graphiques. L'originalité réside dans le fait que la partie affichage de graphiques possède trois modes d'affichages : • Tree mode : Ressemble à l'interface de NetMRG, classement en arbre des différentes machines par groupes. Utile pour gérer un grand nombre de machines ou équipements ; • List mode : Permet de lister les graphiques présents sur une machine sélectionnée dans la liste ; • Preview mode : Ressemble à List Mode excepté que les graphiques sont affichés directement au lieu d'un lien vers celui-ci. Utile pour avoir un aperçu rapide de l'état d'une machine et de ses services. La figure 8 illustre la page d’accueil de Cacti 33 34 Figure 5: Dashboard Cacti 3.3.1.2.2. Avantages ✓ Interface : Beaucoup plus claire que celle de NetMRG elle permet également beaucoup plus de choses ; ✓ Configuration : Avec l'utilisation des templates pour les machines, les graphiques, et la récupération des données tout se configure aisément et entièrement via l'interface web. Import/ Export très simple des templates au format XML. ✓ Performance : Avec le choix du moteur de récolte des données, On peut opter pour la performance ou la simplicité ; ✓ Communauté sur le web, présence d'une dizaine de plugins 3.3.1.2.3. Inconvénients o Pas de gestion d'alarmes, sauf avec un plugin nommé Thold ; o Pas de gestion de panne et absence d'une cartographie de réseau ; o Un développement lent tout comme NetMRG. 34 35 3.3.1.3. Zabbix 3.3.1.3.1. Présentation Créé en 2001, puis donnant naissance à une entreprise nommée Zabbix SIA en 2005, Zabbix est une solution de supervision open-source de plus en plus prisée. L'entreprise vise à faire de Zabbix un logiciel reconnu dans le milieu de la supervision et créer une communauté autour de lui pour permettre une évolution plus rapide. A côté de cela, cette société propose un service de maintenance commercial. Zabbix permet plusieurs moyens d'acquérir les données : • Via SNMP : comme tous ses concurrents ; • Via test de service : Il n'y a rien à installer sur l'équipement surveillé, mais les tests sont limités à des ping ou test de protocoles (SMTP, HTTP...) ; • Via l'agent Zabbix local : C'est une originalité, installer un agent permet d'obtenir toute information sur l'équipement sans utiliser le protocole SNMP. L'architecture logicielle est découpée en composants dans le but de faciliter le monitoring distribué : • Serveur : Le serveur est le cœur de l'application Zabbix. Il centralise les données et permet de les attendre (trapping) ou d'aller les chercher (polling). Il centralise aussi toutes les informations de configuration et permet d'alerter les administrateurs en cas de problème ; • Le proxy : Élément optionnel de l'architecture, il permet de bufferiser les données reçus des différents sites dans le but d'alléger les traitements pour le serveur ; • L'agent : Une fois installé sur un système, l'agent va collecter les données locales et les envoyer au serveur ; 35 36 • L'interface Web : Celle-ci est une partie du serveur bien qu'il ne soit pas obligatoire qu'elle se trouve sur la même machine que le serveur. L'interface permet de configurer entièrement Zabbix, d'accéder aux statistiques ainsi qu'à d'autres informations. Tous ces composants sont écrits en C afin de garder de hautes performances, hormis bien évidemment l'interface Web développée en PHP. L'interface est divisée en cinq parties : • Monitoring : La partie affichage des statistiques, graphiques, alertes, cartographie, etc… ; • Report : Statistiques sur le serveur Zabbix et rapport de disponibilité des services sur les machines supervisées ; • Administration : Permet de gérer les moyens d'alertes (SMS, Jabber, Email, ...) et les utilisateurs. La figure 9 illustre le tableau de bord de Zabbix • Figure 6: Zabbix Dashboard 36 37 3.3.1.3.2. Avantages ✓ Une solution très complète : cartographie de réseaux, gestion poussée d'alarmes via SMS, Jabber ou Email, gestion des utilisateurs, gestion de pannes, statistiques et reporting ; ✓ Une entreprise qui pousse le développement, et une communauté croissante ; ✓ Une interface vaste mais claire ; ✓ Une gestion des templates poussée, avec import/export xml, modifications via l'interface ✓ Des performances au rendez-vous : l'application a été testée avec succès avec 10000 équipements supervisés ; ✓ Compatible avec MySQL, PostgreSQL, Oracle, SQLite. 3.3.1.3.3. Inconvénients o Interface est un peu vaste, la mise en place des templates n'est pas évidente au début : petit temps de formation nécessaire ; o L'agent Zabbix communique par défaut en clair les informations, nécessité de sécuriser ces données (via VPN par exemple) ; o Commence à être connu, mais pas encore auprès des entreprises : Peu d'interfaçage avec d'autres solutions commerciales. 3.3.1.4. Nagios 3.3.1.4.1. Présentation Successeur de NetSaint, Nagios est certainement le logiciel libre le plus connu dans le milieu de la supervision réseau. Appréciée des entreprises ainsi que des particuliers, cette application possède une très grande communauté qui participent 37 38 activement au développement. L'architecture logicielle est modulaire comme chez ses concurrents : • Le moteur qui gère l'ordonnancement de la supervision, écrit en C ; • L'interface Web réalisé à l'aide des CGI ; • Des greffons, ou plugins qui étendent les possibilités de Nagios. Il existe notamment des plugins Nagios nommée NRPE et NCSA qui fonctionnent un peu sur le même principe que ceux de Zabbix. NRPE est un agent esclave qui attend les ordres du moteur Nagios (polling) et NCSA envoi de lui-même les données (trapping). L'interface est divisée en trois : • Partie monitoring, qui permet plusieurs vues : vue globale, vue précise, vue de la carte du réseau, vue des problèmes, ... même une vue "3D" ; • Partie reporting regroupant les tendances des statistiques, les alertes et évènements ainsi qu'un rapport de disponibilités des services ; • Partie configuration classique permettant de tout configurer. Ci-dessous le tableau de bord de Nagios par la figure 10. 38 39 Figure 7: Nagios Dashboard 3.3.1.4.2. Avantages ✓ Reconnu auprès des entreprises, grande communauté ; ✓ Pléthore de plugins qui permettent d'étendre les possibilités (agents comme Zabbix, reporting amélioré, etc.…) ; ✓ Une solution complète permettant le reporting, la gestion de panne et d'alarmes, gestion utilisateurs, ainsi que la cartographie du réseau ; ✓ Beaucoup de documentations sur le web ; ✓ Performances du moteur. 3.3.1.4.3. Inconvénients • Interface non ergonomique et peu intuitive ; • Configuration fastidieuse via beaucoup de fichiers ; 39 40 • Pour avoir toutes les fonctionnalités il faut installer des plugins, de base c'est assez limité. 3.3.1.5. Centreon 3.3.1.5.1. Présentation Centreon, basé sur Nagios, se présente comme une évolution de celui-ci pour tout d'abord son interface mais aussi ses fonctionnalités. Créé en 2003 par des français souhaitant améliorer Nagios et son interface très austère, Centreon (anciennement Oréon) a été repris par une nouvelle entreprise nommée Merethis. Centreon reprend donc les avantages du moteur de Nagios et permet ainsi d'être entièrement compatible avec des solutions existantes. Son interface reprend un découpage classique : • Home : Page d'accueil avec Le "Tactical Overview" de Nagios permettant un coup d'œil rapide aux problèmes survenus et accès aux statistiques des performances du moteur et de ses composants ; • Monitoring : Possède plusieurs vues, mais reprend la grande idée de l'arbre des groupes d'équipements. Reprend également la vue Nagios ; • Views : Permet d'accéder à tous les graphiques avec un menu arborescent. Accès à une cartographie du réseau en applet Java ; • Reporting : Un Dashboard ressemblant à celui de Zabbix en ajoutant une frise chronologique de la disponibilité de l'équipement ; • Configuration : Pour tout configurer de A à Z ; • Administration : Configuration des accès utilisateurs. Toujours visibles en haut à gauche, un tableau récapitulatif du nombre de machines actives et des éventuelles machines ne répondant plus pour toujours garder un œil sur l'ensemble du réseau. 40 41 La figure 11 montre le tableau de bord de centreon Figure 8: Centreon Dashboard 3.3.1.5.2. Avantages ✓ La robustesse et la renommée de Nagios ; ✓ Une interface beaucoup plus sympathique, permettant de tout configurer, de garder un œil sur tout le réseau en permanence ; ✓ Les utilisateurs de Nagios ne seront pas perdus pour autant, l'interface reprenant avantageusement certaines vues Nagios ; ✓ Une solution complète permettant le reporting, la gestion de panne et d'alarmes, gestion utilisateurs, ainsi que la cartographie du réseau ; ✓ Une entreprise qui pousse le développement ; ✓ Peut-être décorrélé du serveur Nagios et tourner tout seul sur un autre serveur. 3.3.1.5.3. Inconvénients 41 42 • L'interface peut paraître complexe car il existe beaucoup d'options, de vues…cela nécessite une petite formation ; • Un développement qui n'est pas encore en phase avec celui de Nagios : Parfois des problèmes de compatibilité ; • Un peu plus lourd que du Nagios pur. 3.3.1.6. Eyes Of Network 3.3.1.6.1. Présentation Eyes Of Network (EON) est la solution Open Source réunissant de manière pragmatique les processus ITIL (Information Technology Infrastructure Library) avec l’interface technologique permettant leur application. La solution EON est une solution complète de supervision. C’est est une distribution Linux basée sur CentOS. Elle est actuellement distribuée sous licence GPL, sa version actuelle est la 5.1. Le tableau de bord de Eyes Of Network par la figure 12 Figure 9: EON Dashboard 42 43 3.3.1.6.2. Avantages Les fonctionnalités d’EON sont nombreuses. Elle Permet de regrouper tous les outils ITIL et de supervision dans une même distribution, d’ajouter un gestionnaire de performance et une interface de configuration web qui facilite sa configuration. En plus EON permet de faciliter le déploiement des outils de supervision et dispose d’un SSO (Single Sign-On) permettant de se loguer une seule fois et d’accéder à tous les outils d’administration. Enfin EON dispose de la fonctionnalité Auto-Discovery qui permet d’ajouter des hôtes automatiquement et une possibilité d’administrer ses périphériques via SSH/Telnet depuis son interface web. 3.3.1.6.3. Inconvénients L’inconvénient d’EON est lié à son outil Wheathermap nécessitant une cartographie sur papier au préalable avant d’établir la cartographie de notre réseau et d’une interface qui déborde d’onglet. [13] 3.3.1.7. Shinken 3.3.1.7.1. Présentation Shinken est une solution libre open source présenter comme le petit frère de Nagios. Elle est sous licence AGPL et est beaucoup oriente « distribuer » que son prédécesseur. En effet l’auteur de shinken a fait le constat que Nagios était très performant uniquement sur de petite infrastructure d’où l’idée de créer un outil de supervision assez complet qui palliera aux problèmes de NAGIOS. 43 44 3.3.1.7.2. Avantages ➢ Confrontation du trinôme corrélation, règles applicatives, importance métier, facilitant la tâche des administrateurs et rendant un service apprécié des utilisateurs ; ➢ Application installable et opérationnelle sous Microsoft Windows : permettant de couvrir tout le spectre fonctionnel, du plus petit parc au plus gros ; ➢ Apte à fonctionner sur des équipements GSM Android. 3.3.1.7.3. Inconvénients • Méconnue du monde de l’entreprise 3.3.2. Tableau comparatif des solutions et choix de la solution Les solutions présentées ci-dessus, dressons le tableau 6 qui est un tableau comparatif Tableau 6 : Tableau comparatif des différentes solutions Besoins Authentifications et rôles Graphes complexes NetM.G Proactive et réaction en cas de ✓ ✓ Vue en temps réel ✓ Simplicité du Paramétrage ✓ Multiplateforme ✓ Modularité ✓ Adaptabilité ✓ Cacti Zabbix Nagios Centreon EON Shinken ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ 44 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ 45 panne Supervision distribué Solution libre ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Parmi ces solutions libres, SHINKEN est la solution la plus adaptée permettant de satisfaire pratiquement tous nos besoins, par les différentes fonctionnalités qu’elle offre. 3.4. Conclusion Ce chapitre vient de receler des points touchants des exemples de solutions en évoquant leurs caractéristiques d’abord, en sus elle a mis en évidence un tableau comparatif en fonction de nos besoins et cela nous a permis de choisir l’outil de supervision SHINKEN. Le prochain chapitre donne une étude approfondie afin de facilité sa mise en œuvre. 45 46 CHAPITRE 4 PRESENTATION DETAILLEE DE LA SOLUTION RETENUE 1.1. Introduction Dans ce chapitre, nous mettrons en évidence une présentation assez exhaustif de l’outil de supervision SHINKEN tout en donnant beaucoup plus ample informations sur sa mise en œuvre sur dans l’environnement de teste et sur l’environnement de distribution de SOFTNET. A la fin du chapitre nous ferons un récapitulatif des différents coûts de déploiement. 1.2. Présentation de Shinken 1.2.1. Définitions Shinken est une application permettant d’effectuer de la supervision complète. Elle surveille les hôtes et services spécifiés. C'est un logiciel libre sous licence GNU AGPL Elle a pour but d'apporter une supervision distribuée et hautement disponible facile à mettre en place. Démarrée comme une preuve de concept pour Nagios sur les architectures distribuées, le programme a rapidement démontré des performances et une flexibilité bien plus importante que son aîné Nagios. Son auteur est Jeans GABES et sa première version est apparue le 1er décembre 2009 en tant que simple outil de monitoring. Sa version actuelle est le 2.4.3. Il assure les fonctionnalités de supervisions principales suivantes : • La surveillance des équipements du système d’information ; • Les notifications informatives en cas d’incident détecter sur un équipement. Les protocoles utilisés sont les suivants : • Le protocoles TCP/IP ; • Le protocole ICMP ; 46 47 • Le protocole SNMP. 1.2.2. Caractéristiques et architecture de Shinken L’outil SHINKEN fonctionne sur les systèmes d’exploitation UNIX sur la plupart des distribution linux et sur WINDOWS. Les interfaces graphiques comme WEBUI, LIVESTATUS ou THURK permette d’accéder de façon visuelle à SHINKEN et cela à travers une interfaces web. L’objectif de ce type d’accès à SHINKEN permet de réunir les différents acteurs du par cet d’obtenir tout type d’information de chacun d’eux et de stocker ces informations sur une base de données. Shinken possède une architecture novatrice : • Architecture distribuée, hautement disponible avec répartition de charge automatique. • Supporte la notion de multi-sites/clients grâce aux realms (royaumes). • Peut être exécuté sous Windows, Linux et Android. Shinken permet d'effectuer de l'acquisition active de données de façon parallèle et balancé sur plusieurs processus et plusieurs hôtes. Les méthodes actives suivantes sont supportées : • • Superviser des services réseaux : SMTP, POP3, HTTP, NNTP, ICMP, SNMP, LDAP, etc. Superviser les ressources des serveurs (charge du processeur, occupation des disque durs, utilisation de la mémoire paginée) et ceci sur les systèmes d'exploitation les plus répandus. • Interface avec le protocole SNMP par l'intermédiaire des sondes. • La supervision à distance peut utiliser SSH ou un tunnel SSL (notamment via un agent NRPE). Shinken possède aussi des caractéristiques de traitement puissantes : 47 48 • Possibilité de définir une hiérarchie dans le réseau pour pouvoir faire la différence entre un serveur en panne et un serveur injoignable. • Possibilité de définir des dépendances entre des services. • Capacité de gestion des oscillations (nombreux passages d'un état normal à un état d'erreur dans un temps court). • Recherche native des problèmes sources et suppression très efficace de faux positifs. • Associer un impact d'affaire à un équipement ou service. • Association automatique de l'impact d'affaire à des éléments parents ayant fait défaut. • Règles métiers pour les états, afin d'associer des règles logiques pour un ensemble d'états. Shinken permet de rendre disponibles les données de performance et d'état à des tiers : • Shinken possède une interface graphique native afin d'interagir avec le système. • Exportation de données de performance vers la BD de métrologie Graphite ou PNP4Nagios (RRDtool). • Intégration native à même l'interface graphique Shinken WebUI, Thruk ou Multisite de la visualisation des données de performance de PNP ou Graphite. • API interactif Livestatus afin de rendre disponibles les états. • Acquittement des alertes par les administrateurs. • La remontée des alertes est entièrement paramétrable grâce à l'utilisation de plugins. Shinken permet de créer ses propres plugins, dans le langage désiré. Il suffit de respecter la norme Nagios des codes retour : • 0 OK (tout va bien) ; • 1 WARNING (le seuil d'alerte est dépassé) ; 48 49 • 2 CRITICAL (le service a un problème) ; • 3 UNKNOWN (impossible de connaître l'état du service). La création de nouveaux plugins permet de répondre de façon personnalisée à tout besoin. Shinken possède aussi un mécanisme simple de « Pack » de supervision qui simplifie beaucoup sa mise en place. Ils sont disponibles sur le site communautaire de Shinken, sont gérés par le gestionnaire graphique SkonfUI en même temps que la découverte, sont inclus de base dans Shinken et peuvent être dynamiquement mis à jour par le gestionnaire Graphite de Shinken SkonfUI. Nous pouvions donc représenter la supervision de SHINKEN avec la figure 13 suivante : Supervision de SHINKEN Interface graphique (WEBUI, LIVESTATUS, THURK) Systèmes de surveillances (systèmes, réseaux, applicatif, métier) et plugins Système de gestion de Base de Donnée (MySQL, MongoDB) Système d’exploitation (UNIX, Windows) Figure 10 : Représentation de la supervision de SHINKEN [14] La différence entre Shinken et Nagios réside plus dans son architecture que le langage de programmation utilisé. En effet son architecture suit le principe d’UNIX : à une tâche un outil. Et donc Shinken est hétérogène différemment de Nagios qui est monolithique. Shinken utiliser six (06) processus différent travaillant ensemble et permettant d’obtenir une flexibilité bien supérieure au Nagios original. C'est cette architecture qui permet d'obtenir la mise en place facile d'une supervision distribuée : un processus s'occupe de lire la configuration de l'utilisateur et la découpe intelligemment (en respectant les relations entre les éléments) afin de 49 50 distribuer les morceaux vers des processus chargés d'absorber la charge de supervision. De cette manière, en cas de nouvelle charge, l'utilisateur peut rajouter des processus sans avoir à modifier sa configuration en profondeur. C'est de ce choix architectural que vient le nom de logiciel. Shinken, un nom de katana très tranchant à savoir de découper la configuration pour la renvoyer sur des daemons. Les six (06) modules se présente donc ainsi : • L’arbiter : le chef d’orchestre de tous les processus de supervision, c’est lui qui distribue le travail à réaliser et gère les configurations. Il est responsable de la validation et du chargement de la configuration, la découpe en différentes parties (N ordonnanceurs = N parties), et l’envoie aux autres éléments. Il gère également la haute disponibilité : si un élément devient injoignable, il redirige la configuration sur un autre. • Le scheduler (planificateur) : en charges des fils de traitements qui doit interagir avec les autres éléments. Ce n’est pas lui qui lance les checks ou les notifications, il ne fait que rediriger les informations. Il garde juste dans une file d’attente les checks en attente (pending) et notification pour les autres éléments (collecteurs ou "Réactionneur). • Le collecteur (Poller) : Son rôle est de lancer les plugins en fonction des requêtes des ordonnanceurs. Ces plugins vont aller interroger le système surveillé et retourner un résultat indiquant l'état. Lorsqu’un plugin renvoie un résultat, il le transmet à l’ordonnanceur. • Le reactionner : il est aussi appelé l’exécutant vue qu’il interroge le planificateur afin de connaitre les tâches à exécuter en fonction des résultats de contrôles. Il est chargé de l'envoi des notifications et de lancer les « event_handlers » (action automatique programmable). 50 51 • Le broker : est en charge de stocker tout résultats dans une base de données ou fichier de stockage. Son rôle est de prendre des données sur les scheduler (comme les statuts par exemple) et de les rendre disponibles à l'externe de Shinken. Il fonctionne avec des modules • Le receiver :il est un service optionnel, Son rôle est de recevoir les données d'acquisition passive et de les acheminer vers le bon scheduler responsable de faire la corrélation et le traitement des statuts On peut avoir une illustration de l’architecture final suivant avec la figure 14 Figure 11: Architecture Interne de Shinken [15] 1.2.3. Prérequis Pour répondre aux différents objectifs lors du déploiement de la solution, il faut au préalable avoir une certaine connaissance sur la supervision et aussi les outils de 51 52 supervision tel que NAGIOS, CACTI ou mieux SHINKEN. Il faut aussi avoir des notions sur l’administration réseaux sur UNIX. Pour commencer l’installations il est primordial d’avoir ces utilitaires ou services avant de lancer l’installation : • Python (par préférence une version ≥ 2.7) et certaines de ses branches comme : o Python-pycurl primordial pour les daemons de SHINKEN o Python-cherrypy3 beaucoup recommander o Python-pip permet d’installer SHINKEN avec la commande pip install o Python-setuptools o Python-paramik • Les Monitorings Plugins qui sont des programmes externes au serveur, des exécutables qui peuvent se lancer en ligne de commande afin de tester une station ou service. Sans eux, SHINKEN est totalement incapable de superviser et se résume en un simple noyau. 1.2.4. Répertoire et sous-répertoires de configuration SHINKEN s’appuie sur un certain nombre de répertoire qui contienne des fichiers textes de configuration pour construire son infrastructure de supervision. Parmi ces répertoires nous avons : • Le répertoire shinken est le répertoire principal et contient le fichier shinken.cfg qui est le fichier dans lequel on établit toutes les règles de supervision d’un système informatique, il est considéré comme le tronc sur lequel gisent les branches tel que : 52 53 ◦ Le sous répertoire brokers qui contient le fichier brokers-master.cfg, ce fichier permet de donner certaines spécificités au daemons brokers. ◦ Le sous répertoire modules qui contient les différents modules permettant la bonne supervision des équipements. Comme les modules sont chargés par les démons, les fichiers de modules sont référencés dans des fichiers de démons. ◦ Le sous répertoire commands dans lequel nous pouvions créer nos fichiers xxx.cfg pour pouvoir contrôler les éléments surveiller par shinken à travers un module et de ses arguments ; ◦ Le sous répertoire contactgroups permets de créer un groupe contacte que l’on peut répertorier dans un fichier contact_groupe_name.cfg, ce fichier permettra d’envoyer des notifications au contacts répertorier dans le fichier de manière simultanément. ◦ Le sous répertoire contacts permet de crée des contacts grâce au nom_de_contact.cfg ; ◦ Le sous répertoire hostgroup a les mêmes fonctionnalités que le sous répertoire contactgroup mais ici il gère les équipements ; ◦ Le sous répertoire hosts permet d’enregistrer un équipement et de le paramétré nom_dequipemtent.cfg ; ◦ Le sous répertoire notificationway est ce répertoire permettant d’envoyer des messages de notifications électroniques ; ◦ Le sous répertoire services enregistre un service d’un équipement, les différents services peuvent être le SSH SNMP NTP CPU PING. 53 54 1.2.5. Architecture de déploiement Dans le cadre de notre étude, le déploiement de la solution se fera sur le serveur de supervision installer sur un système d’exploitation linux la distribution Ubuntu version 18.04.01LTS. La figure 15 suivante présente l’architecture du système d’information dans l’environnement de test du système d’information de SOFTNET. Figure 12 : Architecture de déploiement L’architecture est constituée de : • 6 Serveurs (Shinken, SMTP, Hyper-V, BD, Linux, Windows) ; • 2 imprimantes ; • 1 commutateurs ; • 2 Switch ; • 5 postes utilisateurs. 54 55 1.2.6. Estimation du coût de déploiement La solution que nous avons proposée, peut être déployée en une semaines minimum en fonction des ressources disponible. Ces ressources se compose d’un apport en ressource humaine, matérielle et financière consigne dans le tableau suivant : Couts de réalisation du projet Le tableau 7 contient les données des coûts de réalisation Tableau 7 : Coût de réalisation du projet Désignation 1 Processeur Intel Xeon X5670, 12 Mo cache, 2,93 GHz, Intel QPI à 6,4GT/s Formation de l’administrateur pour le transfert de compétences Installation et Configuration du serveur de supervision par 2 ingénieures en réseau et système Total Cout en Franc CFA 85 137 046 300 000 1 500 000 86 937 046 Ces coûts de réalisations sont des estimations au cours des prestation d'installation chez les particuliers car ici en entreprise toutes les ressources sont déjà disponibles. La formation de l’administrateur réseau se fera sur trois (03) jours à raison de 100 000 franc CFA/jr. 1.3. Conclusion En sommes, dans ce chapitre nous avions présenté l’outil de supervision Shinken de fond en comble, tout en passant par un aperçue approfondie sur ses caractéristiques et de son architectures internes, ensuite nous avions montré l’architecture de l’environnement de teste sur lequel la solution a été déployé et 55 56 enfin nous avions estimé les coûts de déploiement. Le chapitre prochain présentera les détails sur la mise en place de l’implémentation de l’outil shinken. 56 57 CHAPITRE 5 IMPLEMENTATION TECHNIQUE 5.1. Introduction Le chapitre présent est dédié aux différentes étapes de déploiement de la solution. Elle partira d’une présentation des différents prérequis à installer, ensuite les configurations nécessaires de supervisions d’un hôte sur Unix et sur un Windows puis nous allons présenter des tests de fonctionnement sur l’outil et enfin faire un bilan général sur le déploiement de la solution. 5.2. Différentes installations 5.2.1. Prérequis Avant tout début d’installation, il faudrait rappeler qu’il faut avoir une certaine base en administration réseau et aussi des notions en supervision, ce qui est primordial dans la suite de la lecture de ce rapport. La plupart des utilitaires pour la réalisation de la phase de réalisation et de mise en œuvre ont été énumérer dans la partie 2.4.2 Moyens technique nécessaires mais à cela s’ajoute aussi : • PuTTY : un émulateur de terminal UNIX qui permet de se connecter à distance à une machine ou un serveur, en utilisant les protocoles SSH, Telnet ou Rlogin. • Python : est un langage portable, dynamique, extensible, gratuit, qui permet une approche modulaire et orientée objet de la programmation. Elle sera primordiale pour l’installation de l’outil de supervision shinken. 57 58 5.2.2. Installation de la solution Les différentes installations suivantes se font sur une machine virtuelle installer sur VMWare. Dès le démarrage de la machine virtuelle il faut se mettre en super utilisateur et mettre à jours les paquets de votre distribution avec les commandes suivantes : $sudo su #apt-get update Ensuite Il faut télécharger python (version ≥2.7) avec la commande #apt-get install python Python installer il faut installer toutes ses dépendances afin que l’installation de shinken n’ai pas de problème. #apt-get install python-setuptools python-pip python-pycurl • python-setuptools : permettant de régler ou installer certains paramètres de python ; • python-pip :permet de télécharger les paquets affiler a python comme shinken avec les commande pip ; • python-pycurl : idem à python-pip, mais le téléchargement se fait ici avec le commande curl. On crée un nouvel utilisateur et on l’alloue un Shell de connexion avec la commande : #useradd -m -s /bin/bash shinken A la fin de cette commande nous pourrions opérer des actions sur l’interface shinken. Une commande permettant de gérer des paquets sur la communauté GitHub est l’utilitaire git qu’il faut prendre le soin de télécharger. 58 59 Après juste la création de l’utilisateur shinken on peut passer au téléchargement de la source de shinken sur GitHub avec la commande : #git clone https://github.com/naparuba/shinken.git Après s’être placé dans le répertoire principal shinken avec la commande cd shinken/ on va chercher à mettre à jour les fichiers de l'arborescence de travail pour qu'ils correspondent à la version actuelle de shinken : #cd shinken/ #git checkout 2.4.3 On installe et on configure dès à présent shinken avec la commande : #python setup.py install Comme recommandation après son installation, nous allons installer un autre utilitaire de python pour avoir de meilleure performance de shinken : #apt-get install python-cherrypy3 • CherryPy est un cadriciel de développement web pythonien et orienté objet. Il fournit l’assise sur laquelle des applications complexes basées sur le web peuvent être écrites, sans ou avec peu de connaissances des protocoles sous-jacents. [16] Après que l’installation ait réussi on permet au serveur de shinken de pouvoir démarrer à chaque démarrage de son système d’exploitation, il faut démarrer les daemons et vérifier si le serveur est actif #update-rc.d shinken defaults #systemctl start shinken La capture suivante représenté par la figure 16 montre l’état actif du serveur shinken prouvant qu’elle a été bien installée 59 60 Figure 13 : Résultat commande de vérification de l'état du serveur shinken L’installation terminer, on passera à l’installation d’une interface graphique ici qui est webui2. Tout d’abord on se log en tant que shinken et on initialise la configuration de shinken pour pouvoir installer le module de l’interface graphique webui2 grâce aux commandes suivantes : #su – shinken $shinken --init $shinken install webui2 L’avant dernière étape de l’installation de l’outil shinken est l’installation sa base de données. Cette base de données est MongoDB, Webui2 l’utilise pour la gestion de ses données. Nous devons installer MongoDB et un autre paquet python avec pip 60 61 #apt-get install mongodb #pip install pymongo>=3.0.3 requests arrow bottle==0.12.8 La figure 17 montre l’état du service mongodb après son installation Figure 14 : Résultat commande sur l'état du service mongodb Pour rendre assez complet l’installation de shinken il faut y ajouter un élément important qui est les modules de monitoring de Nagios. A cela on ajoute certain modules Perl qui ont pour but d’améliorer les performances de la supervision de ces modules. Perl est un langage interprété optimisé pour le traitement du texte et le développement de scripts. La commande suivante permet d’installer les plugins de Nagios et cpanminus ce qui est requis pour la configuration et l’installation des modules de Perl #apt-get install nagios-plugins* cpanminus Il en suivra l’installation de ces modules de Perl avec la commande cpanm. Installation des module Perl avec la commande cpanm 61 62 #cpanm Net::SNMP #cpanm Time::HiRes #cpanm DBI cpanm est un client qui tente de rendre la puissance de CPAN accessible à tous les utilisateurs, en particulier ceux qui ne sont pas des développeurs Perl, mais qui ont une expérience du Shell CPAN. En effet, CPAN, le réseau d'archives complet Perl, est la principale source de publication et de récupération des derniers modules et bibliothèques pour le langage de programmation Perl. Les installations terminées il faut maintenant crée un lien entre ces modules télécharger et shinken. Pour cela il faut exécuter ces commandes suivantes séquentiellement #chmod u+s /usr/lib/nagios/plugins/check_icmp #ln -s /usr/lib/nagios/plugins/utils.pm /var/lib/shinken/libexec/ #mkdir -p /var/log/rhosts/ #touch /var/log/rhosts/remote-hosts.log Enfin il faut installer des packages ssh et linux-snmp pour la supervision des service SSH et SNMP sui seront télécharger depuis le site de shinken.io. #su – shinken $shinken install ssh $shinken install linux-smmp Cette méthode d’installation énumérer ci-dessus n’est pas la seule méthode d’installation de shinken. En effet il existe d’autres méthodes mais celle-ci est la plus simple. Vous pouviez vous référer au site web shinken.io pour une installation complète de l’outil. [17] 5.3. Configurations nécessaires Dans cette partie nous montrerons comment configurer à travers les fichiers de configs. Elle commencera par une configuration globale, ensuite nous montrerons les configs pour des types de supervision que l’on a pu étudier. 62 63 5.3.1. Prérequis Les partie supervisions d’équipements ont de titres en commun : ajout d’hôte, ajout de groupe et ajout de service. Et donc il faut savoir que pour la partie Ajout d’hôte il faut se rendre dans le répertoire /etc/shinken/hosts/, pour Ajout de groupe il faut se rendre dans le répertoire /etc/shinken/hostsgroup et enfin pour Ajout de services il faut se rendre au niveau du répertoire /etc/shinken/services. Le redémarrage du service de shinken se fait de plusieurs manières parmi lesquels : • • • #service shinken restart #/etc/init.d/shinken restart #systemctl restart shinken Tous les équipements auront une adresse IP du réseau 192.168.6.0/24 et sont énumérer dans le tableau 8 suivant Tableau 8 : Adressage des équipements Nom équipement Adresse IP Serveur Shinken 192.168.6.3/24 Serveur Debian 192.168.6.2/24 Windows 192.168.6.4/24 Imprimante 192.168.6.5/24 Switch Cisco 192.168.6.6/24 Routeur 192.168.6.1/24 5.3.2. Configurations de supervision 5.3.2.1. Configurations de Webui2 La première config à réaliser est celle de la gestion d’une interface graphique juste après son installation. Nous avions installé Webui2 et donc c’est elle que l’on choisira comme interface par défaut. 63 64 Le fichier de configuration à éditer pour cela est le fichier broker-master.cfg que l’on retrouve en suivant ce chemin absolu /etc/shinken/brokers/. Pour l’éditer nous allons utiliser nano qui est un petit éditeur gratuit et convivial qui vise à remplacer Pico, un autre éditeur non libre. Ci-dessous les pour atteindre le fichier : #cd /etc/shinken/brokers/ #nano -c broker-master.cfg L’option -c permet d’ouvrir le fichier et d’afficher les numéros de lignes Vous pouviez défiler le fichier jusqu’à la ligne 40 et y ajouter cette ligne : Modules webui2 La figure 18 montre le contenu du fichier broker-master.cfg Figure 15 : Contenue du fichier brokers-master.cfg En orange la ligne là ou doit être insérer le nom du module à être utilisé La flèche en bleu indique le ruban contenant le numéro de ligne. Vous enregistrer le fichier avec le raccourcie clavier ctrl+o et vous quittez avec le raccourcie ctrl+x. Il faut aller maintenant dans le répertoire contacts auquel on accède par le chemin absolu /etc/shinken/contacts/ pour éditer le fichier admin.cfg et cela de la même manière que l’on a faite précédemment. 64 65 Là-bas il faut juste changer les valeurs par défaut et y mettre les valeurs de notre choix. Les valeurs à changer pour le moment sont souligner en orange. La figure 19 montre le contenu du fichier Figure 16 : Contenu du fichier admin.cfg Enregistrer le fichier, puis redémarrons le service Shinken. Si tout marche bien vous pouvez maintenant accéder à l’interface web de Shinken avec l’adresse : http://adresse_ip_serveur_shinken:7767 5.3.2.2. Supervision d’un serveur Debian Maintenant que les plugins Nagios sont installés, nous allons pouvoir superviser notre premier appareil, c’est-à-dire un serveur Debian. Pour cela nous allons installer le plugins NRPE (Nagios Remote PluginExecutor) qui permet de superviser les serveurs Linux/Unix ou Windows à distance. Sur le serveur shinken on va faire ceci : #apt-get install nagios-nrpe-plugin Puis sur celui du serveur Debian #apt-get install nagios-plugins #apt-get install nagios-nrpe-server 65 66 Nous pouvons maintenant modifier le fichier de configure de NRPE pour ajouter l’IP du serveur Shinken et autoriser les commandes de supervision. #nano /etc/nagios/nrpe.cfg Le fichier ouvert il faut : • Modifier la ligne du « allowed_hosts=127.0.0.1 » en « allowed_hosts=address_ip_server_shinken » • Décommenter les lignes contenant « command[check_disk] =/usr/lib/nagios/plugins/check_disk » ce qui permettra de récupérer les informations d’espace disque. Après cela il faut rendre automatique le démarrage du service NRPE et juste apres redémarrer le service avec les commandes : #chkconfig -add nagios-nrpe-server #/etc/init.d/nagios-nrpe-server restart Parallèlement il ne faut pas oublier le SNMP sinon vous aurez des erreurs après. #apt-get install snmp snmpd Les services snmp installer, nous devons éditer le fichier snmp.conf #nano /etc/snmp/snmpd.conf Commenter la ligne 15 et décommenté la ligne 17 comme le montre la figure 20 suivante 66 67 Figure 17 : Contenu fichier 1 snmpd.conf Commente la ligne 51 et 53, puis ajouter une nouvelle ligne juste après comme la figure 21 suivante Figure 18 : Contenu fichier 2 snmpd.conf [17] 5.3.2.2.1. Ajout d’hôte Nous allons ajouter l’hôte du serveur Debian sur le serveur shinken et pour cela il faut créer un fichier nommer srv-debian.cfg dans le répertoire des hôtes #nano /etc/shinken/hosts/srv-debian.cfg La figure 22 suivante montre la config qui soit être faite dans le fichier srvdebian.cfg 67 68 Figure 19 : Contenu fichier server_debian.cfg 5.3.2.2.2. Ajout de groupe de Serveur Linux Nous allons créer un groupe pour ces serveurs linux qui nous permettra d’attribuer directement des services identiques pour éviter les redondances. Un fichier linux.cfg est déjà créer dans le répertoire /etc/shinken/hostgroups. Ouvrer le et faite la config de la figure 23 suivante : Figure 20 : Contenu du fichier de groupe linux.cfg 5.3.2.2.3. Ajout de services Nous allons maintenant ajouter des services. Créez un fichier linux_service.cfg et appliquer les configs de la figure 24 suivante : 68 69 Figure 21 : Contenu du fichier linux_service.cfg Cela terminer il faut redémarrer le serveur shinken. 5.3.2.3. Supervision d’un serveur Windows Pour faire la supervision d’un serveur Windows il faut installer le clients NSClient++. A l’avant dernière fenêtre du début de l’installation il y a une configuration à effectuer et c’est celle de la figure 25 suivante : 69 70 Figure 22 : Installation de NSClient++ Il faut mettre l’adresse IP du serveur shinken au niveau de Allowed Hosts avec le port NRPE qui est 5666 et mettre le mot de passe que vous vouliez au niveau de Password. Cocher la partie Enable nsclient server (check_nt) et Enable Web server. 5.3.2.3.1. Ajout de l’hôte Il suffit de créer un autre fichier nommer srv-wind.cfg et y appliquer la config de la figure 26 suivante : 70 71 Figure 23 : Contenu du fichier host srv-wind.cfg 5.3.2.3.2. Ajout du groupe Serveur Windows Créer le fichier windows.cfg dans le dossier de groupe et appliquer la config de la figure 27 suivante : Figure 24 : Contenu fichier de groupe windows.cfg 5.3.2.3.3. Ajout des services Au préalable il faut vérifier que la connexion se fait entre notre serveur Windows et notre serveur shinken. Pour cela il faut taper la commande suivante : #/usr/lib/nagios/plugins/check_nt -H 192.168.6.4 -v CLIENTVERS ION -p 12489 -s passe Si tout va bien cette commande doit vous retourner la version de nsclient installer 71 72 Nous allons maintenant créer une nouvelle commande « check_nt » dans Shinken au niveau du dossier /etc/shinken/commands en mettant le mot de passe du serveur Windows et le port utilisé. Ci-dessous la figure 28 montrant le contenue du fichier check_nt.cfg Figure 25 : Contenu fichier commande check_nt.cfg Puis nous créons les services Windows à superviser à travers le fichier windows_services.cfg à créer. Ci-dessous la figure 29 montrant le contenue du fichier Figure 26 : Contenu fichier service windows_services.cfg Les configs terminer il faut redémarrer le serveur shinken 72 73 5.3.2.4. Supervision d’une imprimante 5.3.2.4.1. Ajout d’un hôte La supervision d’une imprimante consistera à savoir si est bien allumée et accessible sur le réseau. Pour cela nous allons créer un nouvel hôte appelé imprime-hp.cfg La figure 30 montre la config à réaliser pour l’imprimante Figure 27 : Contenu fichier host imprimante_hp.cfg 5.3.2.4.2. Ajout d’un groupe Pour cela il faut juste créer un groupe imprimante HP dans le dossier des groupes, la config est dans le fichier imprimante.cfg et son contenue se trouve dans la figure 31 suivante : Figure 28: Contenu fichier groupe imprimante.cfg 73 74 5.3.2.4.3. Ajout de service Il suffit juste de créer un fichier pour tester sa connectivité dans le réseau, cidessous la figure 32 montrant le contenue du fichier de service. Figure 29 : Contenue fichier de service imprimante_service.cfg Puis redémarrez le service shinken. 5.3.2.5. Supervision d’un Switch Cisco Le switch cisco à superviser est celui de la serie 3750, il faut donc installer les packs « cisco » et « switch » sur le serveur shinken en se logan sous l’utilisateur shinken. #su – shinken $shinken install cisco $sinken install switch Pour configurer le plugin du switch il faut installer la commande « check_nwc_health » téléchargeable de la manière suivante : #cd /var/lib/shinken #wget https://labs.consol.de/assets/downloads/nagios/check_nwc _health-7.0.1.1.tar.gz #tar -xvf check_nwc_health-7.0.1.1.tar.gz #cd check_nwc_health-7.0.1.1 #./configure --prefix=/var/lib/shinken/ --with-nagios-user=shi nken --with-nagios-group=shinken --withperl=/usr/bin/perl 74 75 #make #make install Nous devons configurer le SNMP sur le switch et pour cela il faut vous connecter grâce à PuTTY sur le switch et tapez les commandes suivantes : Switch>en Switch# conf t Switch(config)#snmp-server community public RO Il faut ajouter le nouvel hôte en créant un nouveau fichier nommé switch.cfg et on y applique la config suivante de la figure 33 : Figure 30 : Contenu fichier hosts switch.cfg 5.3.2.6. Supervision d’un routeur 5.3.2.6.1. Ajout de l’hôte On crée un fichier nommer router-one.cfg dans le répertoire des hosts et la figure 34 montre la config à Figure 31 : Contenu fichier hosts router-one.cfg 75 y mettre 76 5.3.2.6.2. Ajout du service On crée un fichier nommer router_service.cfg dans le répertoire des services et la figure 35 montre la config à mettre dans le fichier Figure 32: Contenu fichier service router_service.cfg Et enfin il faut redémarrer le service de shinken. 5.4. Présentation des tests de fonctionnements Ce point sera beaucoup axé au niveau des commande que l’on a pu effectuer, elle fera office uniquement que de figure. La figure 36 suivante montre l’interface de Webui2 Figure 33 : Shinken WebUI Login page 76 77 La supervision de l’hôte et des services du serveur Debian à travers la figure 37 Figure 34 : Supervision Serveur Debian Supervision de l’hôte et des services de Windows avec la figure 38 Figure 35 : Supervision de Windows [18] 77 78 5.5. Bilan 5.5.1. Points des réalisations Au niveau de ce point, nous pouvions affirmer que la solution shinken a été bien étudier. L’installation a été bien faite et la solution répond aux attentes de notre structure d’accueil. Au moment de la rédaction du rapport, la solution était toujours en phase de déploiements virtuel. Malheureusement un retard a été accusé dans la réalisation du projet. Le prochain point évoquera la question de cet écart. 5.5.2. Explication des écarts La comparaison entre le planning prévisionnel et le planning réel a évoqué un écart très remarquable lors de l’étude et de l’implémentation de l’outils de supervision. Cette remarque se fait au niveau des dates de fin de chaque figure, en effet le projet devant finir le 19/09/2018 se voit finir jusqu’au 08/03/2019 ce qui a pour conséquence le bouleversement total sur le planning prévisionnel. Ce décalage temporel se justifie essentiellement par la difficulté d’implémentation de l’outil, de son installation, de son maniement et de nombreuses dépendances insatisfaites et aussi à nos capacités matérielles qui ne supportais pas le déploiement de l’outil en virtuel. Il y a aussi l’ajout de plusieurs tâches de l’entreprise auxquelles nous étions partie prenante. Le planning réel est représenté dans la figure à l’aide d’un diagramme de GANTT : Figure 36 : Planning réel 78 79 5.5.3. Présentation des limites des solutions La solution que l’on a étudiée est une solution de supervision complète cependant nous avions recensé 03 limites lors de son déploiement, la première est qu’elle consomme beaucoup en CPU, cela s’explique par le fait qu’elle duplique 06 du processus père et chaque processus récupère de la ressource pour exécuter sa tâche. La seconde se trouve au niveau de l’installation du produit, elle a beaucoup de dépendances et un élément important mal installer revient à reprendre toute l’installation de shinken voir au pire du système d’exploitation. La troisième faiblesse réside au niveau de la sécurité, elle ne permet pas de faire des configurations en interface web rn utilisant le HTTPS. Comme suggestions pour les deux dernières limites, il ne faut pas lancer des mises a jours des paquets du système de sa propre initiative car elle pourrait causer des problèmes d’incompatibilités et des dépendances non satisfaite avec les autres rendant le système inutilisable. Le mieux sera d’installer que les mises à jour officielles. 5.6. Conclusion Dans ce chapitre, nous avons présenté les principales parties de la solution à mettre en place, des exemples de configurations de supervision d’équipement ont été démontrer pas-à-pas pour démontrer la réussite du déploiement de la solution. Un bilan a été établi dans le but de mettre en exergue les points sur la réalisation du projet des limites de la solution et des perspectives en cours de réflexions. 79 80 CONCLUSION GENERALE En sommes, ce stage de trois mois se termine par ce rapport de stage, ayant pour thème : « Etude et mise en place d’une solution de supervision pour le système d’information de SOFTNET » , qui nous a permis de nous exprimer à travers cinq grands chapitres qui sont les suivantes : le premier donne une présentation du contexte de stage à travers la présentation de notre cher Ecole, la structure d’accueil SOFTNET ou nous avions été placés sous la tutelle de M. Maxime OUEDRAOGO. Le second chapitre parle de l’Analyse de l’existant qui a été présenté par la présentation des différentes ressources de l’existant d’abord, ensuite nous avions effectué le diagnostic de ses ressources énumérer et enfin nous avons élaborer une démarche à suivre pour résoudre les problèmes énumérer. Le troisième chapitre met beaucoup l’accent sur les généralité des solutions, elle n’a parler que de deux point à savoir les concepts généraux et la présentation des différentes solutions qui s’est terminée par un tableau de comparaison :Le quatrième chapitre parle de la présentation détailler de la solution choisie qui est SHINKEN : Enfin le chapitre cinq déroule l’implémentation technique de la solution à travers une méthode d’installation de la solutions shinken en plus de ses prérequis d’abord, ensuite des exemples de configurations de supervision système et réseaux ont été montré avec des captures des tests à l’appui, et enfin un reporting a été réaliser pour l’ensemble de l’étude. Cette étude fut très intéressante surtout coacher par notre maitre de stage et le personnel de la structure qui nous ont aidés de leur mieux avec de petits apports et des astuces afin que nous puissions apprendre beaucoup dans le domaine de la supervision et surtout avec l’outils shinken l’outil de supervision complet aux vues de ses nombreuses capacité de pouvoir répondre aux différents besoins d’un administrateur réseau. A l’instar de cela, nous pouvions dire que ce stage de fin d’étude de licence fut une première véritable expérience en entreprise car la formation théorique reçu au cursus universitaire a été complète par les formations pratique reçu à SOFTNET. 80 81 Références Bibliographique et webographie [1] «Historique | Ecole Supérieure d'Informatique,» 2018. [En ligne]. Available: http://www.esiupb.bf/. [Accès le 10 Novembre 2019]. [2] «Licence en Informatique | Ecole Supérieure d'Informatique,» 2018. [En ligne]. Available: http://www.esi-upb.bf/?page_id=23. [Accès le 10 Novembre 2018]. [3] «Présentation | SOFTNET GROUP SOLUTION INFORMATIQUE,» 2019. [En ligne]. Available: http://softnet-group.com/presentation/. [Accès le 26 Fevrier 2019]. [4] O. Sararé, Mise en place par simulation d'une conexion VPN entre agences d'une entreprise, OUAGADOUGOU: SOFTNET, 2018, pp. 10-32. [5] P. IRSAPOULLE, Mise en place d'un outil de supervision et de contrôle distant, Saint Denis: Université de la Reunion, 2014, pp. 24-48. [6] «Surveillance (informatique),» 13 Décembre 2018. [En ligne]. Available: https://fr.wikipedia.org/wiki/Surveillance_(informatique). [Accès le 18 Septembre 2018]. [7] «Notification,» 27 Decembre 2018. [En ligne]. Available: https://fr.wikipedia.org/wiki/Notification#Informatique. [Accès le 26 Fevrier 2019]. [8] R. G. CISSE, Mise en place d'un système de supervisionet de reprise de service dans un point d'échange Internet, Bobo-Dioulasso: Ecole Superieur d'Informatique, 2017, pp. 1-65. [9] «Suite des protocoles Internet,» 20 Janvier 2019. [En ligne]. Available: https://fr.wikipedia.org/wiki/Suite_des_protocoles_Internet. [Accès le 26 Fevrier 2019]. [10] «Les différences entre le modèle OSI et TCP/IP,» 26 Février 2016. [En ligne]. Available: http://albertoalvarez95.wixsite.com/prblog/single-post/2016/02/25/Les-diff%C3%A9rencesentre-le-mod%C3%A8le-OSI-et-TCPIP. [Accès le 06 Mars 2019]. [11] «Internet Control Message Protocol,» 01 Février 2019. [En ligne]. Available: https://fr.wikipedia.org/wiki/Internet_Control_Message_Protocol. [Accès le 06 Mars 2019]. [12] «Simple Network Management Protocol,» 30 Novembre 2018. [En ligne]. Available: https://fr.wikipedia.org/wiki/Simple_Network_Management_Protocol. [Accès le 06 Mars 2019]. [13] «Etude des outils de surveillance (monitoring) réseau,» 2008-2009. [En ligne]. Available: http://www.o00o.org/monitoring/solutions.html. [Accès le 14 Novembre 2018]. [14] «Shinken (logiciel),» 21 Février 2019. [En ligne]. Available: https://fr.wikipedia.org/wiki/Shinken_(logiciel). [Accès le 24 Fevrier 2019]. [15] Stella, Shinken, vol. I, Source ENI Edition, 2018, pp. 1-210. [16] «Debian -- Détails du paquet python-cherrypy3 dans sid,» 2019. [En ligne]. Available: https://packages.debian.org/fr/sid/python-cherrypy3. [Accès le 26 Février 2019]. 81 82 [17] «Server Monitoring with Shinken on Ubuntu 16.04,» 2017. [En ligne]. Available: https://www.howtoforge.com/tutorial/server-monitoring-with-shinken-on-ubuntu-16-04/. [Accès le Octobre 2018]. [18] R. Andrieu, Supervision de matériel informatique avec Shinken, ARCONIC, 2017, pp. 1-18. [19] A. Coleman, «GNS3 Setup Wizard - Local server - GNS3,» 29 Juin 2018. [En ligne]. Available: https://docs.gns3.com/. [Accès le 01 Octobre 2018]. [20] «Cisco Call manager SNMP Overview » snmp architecture,» 02 Mai 2011. [En ligne]. Available: https://smbitsolutions.wordpress.com/2011/05/02/2-may-2011-1341/snmp-architecture/. [Accès le 01 Mars 2019]. 82 83 ANNEXE A CONFIGURATIONS SUPPLEMENTAIRES Configuration d’une notification Pour pouvoir envoyer des e-mails, messages ou alertes, il faut préciser quelles plages d’horaire et a quelle commande cette opération se rapport. Pour configurer l’envoie d’une notification il faut prendre en compte un certain nombre de champ obligatoire comme dans l’exemple de la figure 40 suivante : Figure 37 : Contenue fichier de notification email.cfg Configuration pour les groupes de services Selon un ou plusieurs critères identiques comme la fonctionnalité ou un realm, il est possible de définir un groupe de services qui obéi à un certain nombre de règles comme le montre la figure 41 suivante : Figure 38 : Contenu fichier servicegroup bddservice.cfg 83 84 ANNEXE B CONFIGURATION DE GNS3 D’UNE ARCHITECTURE RESEAU Cette annexe montre comment utiliser GN3 pour concevoir une architecture réseau avec le logiciel de virtualisation VMware. Tout d’abord il faut se munir de la machine virtuelle GNS3 VM téléchargeable sur le site web www.gns3.com et exporter le sur VMware. L’importation terminer vous deviez vous rendre sur le logiciel gns3 et déclarer le en suivant le chemin suivant : Edit>preferences>GNS3 VM. De là-bas appliquez les modifications nécessaires pour avoir la capture suivante : Figure 39 : GNS3 VM preferences Appliquer la modification et normalement votre serveur gns3 doit démarrer dans gns3 et VMware et se mettre en vert comme les figures 43 et 44 suivantes : 84 85 Figure 40 : Démarrage gns3 VM dans gns3 Figure 41 : Machines virtuelles installer dans GNS3 85 86 La prochaine étape est d’ajouter une machine virtuelle sur gns3. La méthode est pareille que pour gns3VM à la différence qu’il faut suivre ce lien : Edit>preferences> VMware VM templates> New>Next et choisissez votre machine virtuelle à être importer et appliquer. Si elle est bien importée vous la verrez afficher au niveau des périphérique finaux comme la montrer la figure 44 cidessus suivante avec l’importation de la machine U_shinken : Clique et glisser le sur l’espace vide juste au milieu. Vous pouviez le faire avec d’autre équipements et vous les interconnecter à l’aide de votre machine hôte qui fera office de switch dans votre architecture. Les routeurs sont installables en suivant ce chemin : Icone routeur>new appliance template>, cocher add an IOS routeur using a real Ios image, >ok>, cocher new image>browse, allez chercher votre ISO qui doit avoir l’extension .bin>YES>Next, indiquer le nom de votre routeur au niveau de name, valider avec Next*2 et votre routeur est installer. [19] La figure 45 suivante montre l’architecture de configurations des équipements dans le chapitre 5. Les points en rouge montrent que leurs interfaces réseaux ne sont pas connecter ou que l’équipement est hors tension. Pour le premier cas il suffit juste de faire un bon adressage IP et les équipements communiquerons et vous pourriez faire vos tests. Figure 42 : Architecture final chap5 86
