Rapport de Stage de Master M2 INFORMATIQUE Mise en place d

Département de Mathématiques et Informatique
Université de la
Réunion
Le Conseil Général
de la Réunion
Rapport de Stage de Master M2
INFORMATIQUE
Mise en place d'un outil de supervision
et de contrôle distant
réalisé par
Patrick IRSAPOULLE 28000541
Entité Académique : Université de la Réunion
Responsable Pédagogique : Fred Mesnard
Nom de la Société : Le Conseil Général de la Réunion
Tuteur de Stage : François Boyer
Dates du stage : 6 Janvier au 7 Juillet 2014
<[email protected]>
Saint Denis, île de la Réunion, 20 juin 2014
Université de la Réunion
15, avenue René Cassin B.P. 7151 97715 Saint-Denis Messag CEDEX 9
2
Présentation du Stage de M2
Informatique
Contexte
Ce stage se déroule dans le contexte de la n du cycle d'études du Master Informatique au
sein de l'Université de la Réunion. Il s'insère directement à notre cursus pédagogique (à savoir
le second semestre de notre cinquième année d'études supérieures).
Chaque étudiant doit se mettre à la recherche d'une entreprise au plus tôt, rappelons que ce stage
est à temps plein pour une durée de six mois. Un sujet pertinent doit être choisi par l'entreprise
d'accueil, proposé à l'étudiant, puis validé par l'équipe pédagogique. Une convention est alors
signée, liant l'étudiant, l'entreprise d'accueil et l'entité pédagogique.
Objectifs
Son objectif principal est de permettre de bénécier d'une véritable expérience de professionnalisation et ainsi de faciliter notre insertion vers le monde du travail. Découvrir l'univers
professionnel, un secteur d'activité, participer à la vie de l'entreprise et surtout s'adapter à ses
exigences font partie intégrantes de nos objectifs en tant que stagiaire.
Concrétisant les savoirs acquis durant le parcours scolaire, il est nécessaire d'accomplir ce stage
dans une secteur présentant des intérêts personnels, an de se spécialiser dans le domaine souhaité.
3
Résumé
L'architecture représente la structure générale inhérente à un système informatique, et plus
particulièrement l'organisation des diérents éléments, que ceux-ci soient de type matériel ou
logiciel.
Le principe de la supervision est de s'assurer du bon fonctionnement d'un système, sa mise en
place permet d'eectuer des actions pro-actives et ainsi de détecter d'éventuels problèmes, avant
que ceux-ci n'interviennent.
Outre les éléments classiques à superviser, tels que les serveurs, switchs... Un nouveau type
d'élément fait son apparition : L'imprimante (ou Multifonction) en Réseau. La politique actuelle
visant à mutualiser ce type de périphérique, il devient plus qu'essentiel de garder un contrôle
permanent sur celui-ci an d'éviter tout problème au sein des services concernés.
Les postes de travail (environ 3500) sont les éléments les plus sensibles étant donné qu'ils sont
dotés aux utilisateurs. Ils restent donc actuellement le type de matériel qui nécessite le plus
d'interventions de la part des techniciens.
C'est dans ce contexte que se situe l'objectif de ce stage qui est de coupler la puissance d'un
outil de supervision à diérents outils d'administration, au travers d'une interface web simpliée,
an de permettre aux techniciens d'eectuer un Diagnostic de premier niveau à distance, sur les
imprimantes/multifonctions en réseau ainsi que les postes de travail avant toute intervention sur
site.
[Mots-clés : Microsoft, Linux, requêtes, programmation, SNMP, imprimante, poste
de travail, réseau]
Abstract
The architecture represents the overall structure inherent in an IT system, especially the
organization of the dierent elements that they are hardware or software based.
The aim of monitoring is to ensure the correct functioning of a system, its implementation can
perform proactive actions and thus to detect potential problems before these do occur.
In addition to the conventional elements to monitor, such as servers, switches ... A new type of
element is introduced : Network Printer (or Multifunction). The current policy aimed at pooling
this type of device, it's more than essential to keep a permanent check on it to avoid any problems
in the services concerned.
Desktop computers (3500) are the most sensitive since they are elements equipped to users. They
are currently the type of hardware that requires more intervention by technicians.
It's in this context that is located the goal of this internship, which is to combine the power of
a monitoring tool with dierent administration tools, through a simple web interface, to allow
technicians to make a remotely rst-level diagnosis of network printer/multifunction and desktop
computers before proceeding.
[Keywords : Microsoft, Linux, queries, programming, SNMP, printer, desktop computer, network]
4
Remerciements
Merci à toutes les personnes qui ont su contribuer au bon déroulement de ce stage de Master
de deuxième année.
J'adresse mes remerciements à Laurent PRUNELLA, pour m'avoir permis d'eectuer ce stage
au SSU.
J'exprime ma reconnaissance à mon responsable pédagogique, Fred MESNARD, pour sa disponibilité et ses conseils qui m'ont guidé tout au long de mon cursus universitaire.
Je remercie François BOYER, mon tuteur de stage, pour ses qualités en tant qu'encadrant à la
DEMS.
Merci à Vincent Beauval, administrateur systèmes et réseaux du SAR, qui de part son expérience
dans le domaine de la supervision, a réussi à me pousser à toujours eectuer les bons choix, tout
en respectant l'architecture en place.
Merci également à Florent PAYET qui m'a permis de développer mes connaissances dans le
domaine de la virtualisation.
Je tiens à exprimer ma gratitude envers toutes les personnes qui m'ont suivi et soutenu tout le
long de mon parcours, une pensée particulière à mon collègue et ami Kévin TAOCHY, sans qui
ce travail d'équipe n'aurait pas pu aboutir.
5
Table des matières
1 Introduction
1.1
1.2
1.3
1.4
Présentation de l'organisme d'accueil . . . . . . . . . . . . .
1.1.1 Le Conseil Général de la Réunion . . . . . . . . . . .
1.1.2 La Direction de l'E-administration et Modernisation
1.1.2. A Service Ressources et Méthodes . . . . . .
1.1.2. B Service Architecture et Réseaux . . . . . .
1.1.2. C Service APplications . . . . . . . . . . . .
1.1.2. D Service Support Utilisateur . . . . . . . . .
Objectifs du stage . . . . . . . . . . . . . . . . . . . . . . .
Problématique . . . . . . . . . . . . . . . . . . . . . . . . .
Présentation du Rapport . . . . . . . . . . . . . . . . . . . .
2 Analyse des besoins et spécications
2.1
2.2
2.3
2.4
2.5
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . .
Les enjeux du projet . . . . . . . . . . . . . . . . . . . . . .
Les informations pertinentes pour le technicien . . . . . . .
Étude de l'existant . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Architecture du SI . . . . . . . . . . . . . . . . . . .
2.4.1. A Le serveur DNS . . . . . . . . . . . . . . .
2.4.1. B Le serveur DHCP . . . . . . . . . . . . . .
2.4.1. C Le contrôleur de domaine Active Directory
2.4.2 Easy Vista . . . . . . . . . . . . . . . . . . . . . . .
2.4.3 Le parc Imprimantes . . . . . . . . . . . . . . . . . .
2.4.3. A Panel Top Access . . . . . . . . . . . . . . .
2.4.4 Convention de nommage . . . . . . . . . . . . . . . .
Gestion de projet . . . . . . . . . . . . . . . . . . . . . . . .
2.5.1 Équipe Projet . . . . . . . . . . . . . . . . . . . . . .
2.5.2 Planning Prévisionnel . . . . . . . . . . . . . . . . .
2.5.3 Cycle de vie du Projet . . . . . . . . . . . . . . . . .
2.5.4 Spécication des exigences . . . . . . . . . . . . . . .
2.5.5 Exemple d'un scénario et d'un cas d'utilisation . . .
3 État de l'art
3.1
3.2
. . . . . . . .
. . . . . . . .
des Services .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L'aspect Monitoring . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Que peut-on superviser ? . . . . . . . . . . . . . . . . . .
3.2.2 Méthodes de Supervision . . . . . . . . . . . . . . . . . .
3.2.3 Les diérentes solutions . . . . . . . . . . . . . . . . . .
3.2.3. A Les solutions propriétaires . . . . . . . . . . . .
3.2.3. B Les solutions Open Source . . . . . . . . . . .
3.2.3. C Comparatif général des solutions Open Source
3.2.4 La solution retenue : Centreon Enterprise Server . . . .
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
10
10
11
12
12
12
13
13
14
14
14
15
16
16
17
18
18
18
19
20
20
20
21
22
22
23
23
24
24
24
25
25
27
27
28
29
30
3.2.5
Le protocole de supervision . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Le protocole solution pour la supervision en réseau
4.1
4.2
4.3
4.4
4.5
Présentation de Simple Network Management Protocol
Les principaux éléments . . . . . . . . . . . . . . . . .
4.2.1 Le Manager . . . . . . . . . . . . . . . . . . . .
4.2.2 Agent SNMP . . . . . . . . . . . . . . . . . . .
Des informations structurées . . . . . . . . . . . . . . .
4.3.1 Management Information Base . . . . . . . . .
4.3.2 Structure d'une MIB et Object IDentier . . .
Les paramètres d'interrogations . . . . . . . . . . . . .
4.4.1 Les paquets à installer . . . . . . . . . . . . . .
4.4.2 Les diérentes versions de SNMP . . . . . . . .
4.4.3 Les communautés . . . . . . . . . . . . . . . . .
Les requêtes SNMP . . . . . . . . . . . . . . . . . . . .
4.5.1 Les formats de requêtes . . . . . . . . . . . . .
4.5.2 SnmpWalk . . . . . . . . . . . . . . . . . . . .
4.5.3 SnmpGet . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Réalisation
5.1
5.2
5.3
5.4
5.5
5.6
Les outils utilisés . . . . . . . . . . . . . . . . . . . . . . . .
De la supervision des imprimantes... . . . . . . . . . . . . .
5.2.1 Notion d'hôte/de groupe d'hôtes . . . . . . . . . . .
5.2.2 Dénition de commande . . . . . . . . . . . . . . . .
5.2.3 Dénition de service . . . . . . . . . . . . . . . . . .
5.2.4 Installation de plugins pour Nagios . . . . . . . . . .
5.2.5 Architecture de CES . . . . . . . . . . . . . . . . . .
5.2.6 Le combo Nagios et ndOutils . . . . . . . . . . . . .
... Au diagnostic . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 La remontée d'informations dans la base de données
En passant par la découverte réseau . . . . . . . . . . . . .
Du serveur de développement au serveur de Production . .
Les dicultés rencontrées . . . . . . . . . . . . . . . . . . .
5.6.1 Protection du réseau . . . . . . . . . . . . . . . . . .
5.6.2 Respect des conventions de nommage . . . . . . . . .
5.6.3 Livrables . . . . . . . . . . . . . . . . . . . . . . . .
5.6.3. A Architecture générale de l'outil . . . . . . .
5.6.3. B Machines virtuelles . . . . . . . . . . . . . .
5.6.3. C Documentations . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
32
32
33
33
33
34
34
35
36
36
36
37
37
37
37
38
39
39
40
40
40
40
41
41
42
42
42
44
45
46
46
47
47
47
48
48
6 Conclusion
49
A Webographie
54
B Annexes techniques
57
6.1
6.2
6.3
Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Apport personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Perspectives futures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.1 Tableau de Bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.1
B.2
B.3
B.4
Création d'une machine virtuelle . . . . . .
Installation de CES . . . . . . . . . . . . . .
Suite de l'installation de CES via navigateur
Les diérents éléments de Centreon . . . . .
7
. . .
. . .
Web
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
50
50
56
57
61
66
68
TABLE DES MATIÈRES
B.5 Migration de la machine virtuelle . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.6 V1 de l'interface Web de notre application . . . . . . . . . . . . . . . . . . . . . .
8
69
70
Chapitre 1
Introduction
1.1 Présentation de l'organisme d'accueil
Ce premier chapitre est dédié à la présentation globale de l'organisme d'accueil. Des organigrammes illustreront les diérentes hiérarchies établies au sein des directions et services présents.
Suite à la description du service auquel j'ai été aecté, seront introduits les objectifs de mon stage,
la problématique xée et une présentation assez sommaire du rapport en lui-même.
1.1.1 Le Conseil Général de la Réunion
Le Conseil Général est l'Assemblée Délibérante d'un Département, composée d'un ensemble
de conseillers généraux.
Ses membres, les Conseillers Généraux, sont élus au Surage Universel Direct uninominal à deux
tours et chaque Canton dispose de son propre conseiller. Leur mandat est de 6 ans, avec renouvellement par moitié tous les 3 ans.
Le Conseil Général est une collectivité qui agit pour le développement du Département et pour
le bien-être de ses habitants. Il exerce des missions qui touchent tous les aspects de la vie des
habitants de son Département. C'est par exemple, la construction et la rénovation de collèges
publics... Ce sont également les politiques menées en faveur de l'insertion des personnes sans
emploi, l'aide sociale en faveur de l'enfance, de la famille, des personnes âgées et des personnes
handicapées.
Son siège social est situé à l'hôtel du Département (2 Rue de la Source à Saint-Denis), le Conseil
Général de la Réunion est composé de 49 conseillers généraux. Le quotidien et l'organisation des
travaux du Conseil Général sont gérés par la Commission Permanente, qui se réunit chaque semaine. Sont présents : La présidente du Conseil Général, les 14 vice-présidents et les 16 membres
permanents.
Ses principaux domaines de compétence :
Social
Insertion
Santé
Enfance
Éducation
Environnement et Énergie
Culture
Sport
Laboratoires
Aménagement
9
1.1.
PRÉSENTATION DE L'ORGANISME D'ACCUEIL
Coopération
Agriculture
Transports et Routes
Figure 1.1 Organigramme du Conseil Général de la Réunion
1.1.2 La Direction de l'E-administration et Modernisation des Services
La DEMS (anciennement appelée "Direction Informatique") est la Direction dont la mission est d'assurer la maintenance évolutive, préventive et corrective du Système d'information
et Télécommunications des services du Conseil Général, ainsi que de développer l'administration
électronique et l'ouverture du Système d'information aux partenaires et usagers.
En plus de sa Direction (composée du Directeur et de la cellule Animation/Formation), la DEMS
regroupe 4 grands services :
SRM
SAR
SAP
SSU
1.1.2. A
Service Ressources et Méthodes
Le Service Ressources et Méthodes a pour vocation de faciliter le travail des services opérationnels en mettant à leur disposition les moyens nécessaires à la conduite de leurs missions et
en assurant la gestion des ressources transversales.
10
1.1.
PRÉSENTATION DE L'ORGANISME D'ACCUEIL
Figure 1.2 Organigramme DEMS fonctionnel et nominatif
Les principales missions :
assurer le suivi des marchés de la direction
gestion comptable et nancière
gestion logistique : moyens
gestion du courrier de la direction
accueil physique et téléphonique
suivi et coordination des projets transversaux
1.1.2. B
Service Architecture et Réseaux
Le service Architecture Réseaux a pour vocation de construire l'infrastructure du Système
d'information.
Ses missions :
concevoir,maintenir et moderniser l'architecture du SI
administrer et exploiter les équipements
conduire les projets techniques
fournir une assistance technique aux autres services
veille technologique an d'anticiper les évolutions technologiques
11
1.2.
OBJECTIFS DU STAGE
1.1.2. C
Service APplications
Le Service Applications assure la mise en place de solutions ou d'outils informatiques modernes et d'assurer leur fonctionnement et leur évolution. Ce service se décompose en deux parties,
une équipe " Mission Développement", et le service SAPMA.
L'équipe Mission Développement (placée sous la responsabilité d'un chef de projet) participe à
l'analyse fonctionnelle du besoin ainsi qu'à l'élaboration du modèle conceptuel des données. Elle
participe à la mise en oeuvre : paramétrages, formation...
L'équipe Service APplications Maintenance Applicative fait partie de l'unité SAP et est composée de 6 agents. Cette équipe a pour mission première d'assurer la maintenance, l'administration
technique et l'évolution des applications métiers du Département de la Réunion. Cependant elle
a également en charge de développer des applications lorsque la mise en place d'un progiciel ne
s'avère pas nécessaire.
1.1.2. D
Service Support Utilisateur
Le Service Support Utilisateurs (auquel j'ai été aecté) est l'un des plus actifs parmi tous
les Services. En eet de part sa cellule d'interventions, ses diérents membres sont constamment
en action sur le terrain (les diérents sites du Conseil Général) et doivent maintenir un contact
permanent avec les utilisateurs. Pour plus d'ecacité cette équipe d'intervention est répartie
selon des secteurs : Est, Nord, Sud/Ouest plus une équipe placée constamment au niveau du
Palais de la Source.
Passer des marchés publics de matériels, évaluer les besoins, préparer des postes pour les utilisateurs, faire du dépannage sur site...toutes ces tâches rythment le quotidien du SSU.
1.2 Objectifs du stage
Initialement 3 thèmes ont été proposés comme sujet de stage.
1. Un thème principal (celui qui sera développé dans ce rapport, à savoir : "La mise en place
d'un outil de supervision des imprimantes et postes de travail ".
2. Une période d'un mois a été déni pour le second thème "Interventions sur site ", an de
travailler avec l'équipe d'intervention de la zone Nord. Ceci an d'appréhender l'architecture, les contraintes du quotidien du monde professionnel et également de développer la
relation client.
Pendant cette période j'ai également préparé des postes clients (préparation multi-postes
en réseau grâce à un serveur WDS 1 ). Pour nir j'ai été en charge d'une dizaine de stagiaires
qui provenaient de diérents centres de formation, an de faciliter leurs insertions dans le
SSU.
3. Le troisième thème : "Formation " avait pour but une visée nettement plus pédagogique
que technique. En eet suite à la décision de la Présidente du Conseil Général de doter les
travailleurs sociaux d'ordinateurs portables, ceux-ci n'ont malheureusement pas eu d'accompagnements sur les diérents éléments installés sur leurs postes.
1. Windows Deployment Services
12
1.3.
PROBLÉMATIQUE
Un système d'exploitation plus récent (Windows 7), des logiciels de bureautique mis à jour
(Microsoft Oce Word/Excel 2007), ainsi que la modernisation des services(webmail plutôt qu'un client lourd...), tous ces éléments nécessitent un certain suivi avec les utilisateurs.
Qualié par la suite comme étant une "Aide à la prise en mains de l'outil informatique"
plutôt qu'une formation à proprement parlé, tout simplement car aucun document ociel
n'atteste que je suis un formateur.
Pas moins de 90 agents de la Collectivité ont été formés correctement grâce à Kévin TAOCHY et moi-même. Outre l'aspect pédagogique ce mini-projet m'a permis de développer
le côté logistique, à savoir :
Mise en place de groupes
Mise en place de sessions
Coordination des moyens (techniques, humains...)
Un mois entier a été nécessaire pour la réalisation de ce projet qui a été un réel succès,
tellement que les demandes de participations aux sessions se poursuivent actuellement.
1.3 Problématique
An de réaliser correctement ce projet conséquent, un binôme a été formé : mon collègue
Kévin TAOCHY et moi-même. Kévin s'occupant de la partie développement de l'interface web
ainsi que de la partie sécurité informatique.
Quand à moi j'ai été en charge de la mise en place de l'outil de supervision, de l'étude d'un
protocole de communication menant à la rédaction de scripts an de récupérer des informations
sur les imprimantes (et multifonctions) en réseau ainsi que la recherche de diérentes commandes
et outils existants an de réaliser un diagnostic de premier niveau sur les postes de travail.
Notre étude préliminaire a donné naissance à la problématique suivante :
Est-il possible d'intégrer un outil de supervision à la structure déjà en place ? Quel est l'intérêt
de le coupler à des outils d'administration au sein d'une interface web ? Le fait de maximiser
les interventions à distance peut-il inuer sur la réduction des coûts de déplacement liés aux
interventions sur site ?
1.4 Présentation du Rapport
Dans une première partie, ce rapport présente le cahier des charges qui a été établi suite
à la proposition de ce thème de stage. Ainsi seront détaillés l'étude des besoins, les solutions
existantes, puis enn les solutions choisies tout en respectant l'architecture réseau déjà en place.
La seconde étape concerne la présentation des diérents outils, à la fois ceux mis à notre disposition et également ceux mis en place par la suite, sans oublier les dicultés rencontrées.
Enn nous terminerons avec la conclusion qui décrira l'apport personnel à ce stage ainsi que les
perspectives futures pour ce projet.
13
Chapitre 2
Analyse des besoins et spécications
2.1 Introduction
Une fois la problématique posée, l'étape suivante logique, était l'analyse des besoins. Cette
étape qui peut s'avérer assez longue est une phase préparatoire qui va mener à la réussite du
projet. En eet les statistiques ont montré que dans 70 % des cas un échec sur un projet était
dû à une analyse des besoins bâclée ou quasi inexistante et non pas à un mauvais développement
ou une mauvaise conception.
2.2 Les enjeux du projet
Ce projet a été initié par le SSU, et plus particulièrement par notre tuteur qui a lancé l'idée :
François BOYER pour les agents du SSU. Il faut comprendre que les membres du SSU et plus
particulièrement les techniciens d'interventions sont constamment sur le terrain et se doivent de
maintenir un bon relationnel avec les agents du Conseil Général, leur quotidien est très agité et
ils ont un quota d'interventions à respecter par mois.
Chaque intervention est listée et répertoriée via un outil appelé EasyVista (dont la description
sera donnée dans l'étude de l'existant). On comprend tout de suite que chaque intervention doit
être valorisée et la plus eciente possible (rendu vis-à-vis du temps passé à eectuer cette intervention). C'est dans cette optique qu'intervient la mise en place de notre outil de supervision et
de contrôle distant. Dans le respect de ma problématique, ce projet doit inuer sur les paramètres
suivants et donc les améliorer :
Ecience de l'intervention
L'ecience regroupe à la fois la vitesse d'intervention ainsi que
la qualité de l'intervention. Si le technicien bénécie d'informations pertinentes (dès lors se
pose le problème de la dénition d'une information pertinente) il n'aura sans doute pas à
passer autant de temps sur une intervention. S'il sait à quel endroit il devra agir, il devient
évident qu'il pourra alors préparer les outils nécessaires et procéder plus rapidement. Un
outil de diagnostic répond à ce besoin, en fournissant à la demande les informations jugées
nécessaires sur un bien matériel.
L'intervention à distance
Une intervention sur site mobilise des moyens, de type humain (le
technicien doit se rendre sur place), de type matériel (il prend un des véhicules de service
du SSU), un des objectifs du SSU cette année est de maximiser les interventions à distance.
Un outil de contrôle résout en partie ce problème, lorsque l'on peut intervenir à distance
selon la nature du problème évidemment.
14
2.3.
LES INFORMATIONS PERTINENTES POUR LE TECHNICIEN
2.3 Les informations pertinentes pour le technicien
Grâce à l'outil EasyVista évoqué précédemment, les techniciens se voient attribuer des interventions à traiter dans les plus brefs délais. Il faut bien évidemment établir un ordre de priorité
dans ces interventions.
Les problèmes les plus fréquents sont ceux liés aux postes de travail (le type de matériel le plus
nombreux), ils peuvent être d'ordre matériel (écran qui ne s'allume plus par exemple), logiciel
(impossibilité de faire une mise à jour) etc... Lorsque le problème est d'ordre logiciel il est plus
qu'essentiel de procéder à une intervention à distance, soit par téléphone avec l'agent concerné,
soit en prenant le contrôle de son poste et ainsi de corriger la défaillance constatée. En cas
de problème concernant un progiciel 1 , l'intervention sera rapatriée à SAPMA. Dans la section
précédente, j'ai évoqué la notion d'information pertinente pour augmenter l'ecience d'une intervention, voyons à présent comment dénir ces informations.
1. Les postes de travail
Le ping
Le ping permet de déterminer la première information logique, à savoir si le poste
est présent ou non sur le réseau (suivant si le ping est positif ou non)
Stratégie de groupe Windows
Grâce à Active Directory, des stratégies peuvent s'appliquer aux postes clients, celles-ci peuvent aller des restrictions systèmes (impossibilité d'installer des programmes), aux permissions serveurs (accès à tel ou tel serveur
de stockage en fonction de l'appartenance à un service). Ceci permet de garder un
contrôle sur l'utilisateur et son environnement.
DNS
Permet la correspondance entre une adresse ip et un nom plus simple à retenir et
à dénir. Exemple de base si un utilisateur ne peut se connecter à un serveur de
stockage, il est possible que ses paramètres de DNS soient erronés.
Paramètres de proxy
Le proxy installé à la DEMS est "ProxySquid", pour rappel un
proxy permet de faire la liaison entre le réseau interne (intranet) et internet, sans
conguration au préalable de ces informations, il est alors impossible à l'utilisateur
de se connecter à internet, et d'utiliser des services tel que le web par exemple.
2. Les imprimantes/multifonctions en réseaux
Le Ping
Comme pour les postes de travail, ceci nous permettra de vérier si le matériel
est présent ou non sur le réseau
Le niveau d'encre
Sans doute la problème le plus récurent étant donné que les niveaux
d'encre ne sont pas vériés, un état d'alerte (par exemple 15 % d'encre restant) pourra
être installé, pour prévenir ce problème
Absence de papier dans le/les bac(s) concerné(s)
Le technicien pourra déterminer
si l'imprimante/multifonction dispose d'un ou plusieurs bacs et si l'en d'entre eux
voire plusieurs sont vides
Modèle, nom et serial number
Cela peut sembler anodin mais certains modèles disposent de caractéristiques bien spéciques, qu'il faudra peut-être prendre soin de
vérier (dans des ches techniques) au préalable avant d'intervenir
Localisation physique
Pour m'être déjà rendu à plusieurs reprises dans certains locaux
du Conseil Général, il n'est pas chose facile de s'y retrouver, une localisation physique
du matériel avec indication sur le service concerné sera la bienvenue
Statut
Le matériel est-il sous tension, est-il occupé au moment où on l'interroge (en cours
d'impression par exemple)...
1. Contraction de Produit et Logiciel qui fait référence à des applications métiers par exemple
15
2.4.
ÉTUDE DE L'EXISTANT
2.4
Étude de l'existant
Cette section traite de l'architecture réseau en place actuellement au Conseil Général, ainsi
que des serveurs et/ou des diérents outils desquels nous dépendrons (donc pas de la totalité des
serveurs et outils présents) lors de la réalisation de notre projet. Ces éléments sont à prendre en
considérations, c'est à nous de nous adapter et de respecter ce qui est déjà en place, en aucun
cas nous ne pourrons nous permettre d'imposer un choix qui touche aux politiques déjà établies,
que celles-ci soient de sécurité ou autre.
2.4.1 Architecture du SI
L'architecture du Conseil Général est de type réseau maillé hébergé par l'opérateur historique. Il Dispose de plus de 150 sites interconnectés avec des débits variés. Le c÷ur du SI 2 est
un DataCenter sous VMWare. Les principaux OS sont Microsoft Windows Server, Debian et
Ubuntu pour les Serveurs. Les postes de travail ont Microsoft Windows XP à 7.
Figure 2.1 C÷ur de réseau du Conseil Général
Le c÷ur de réseau du Conseil Général est composé de la manière suivante :
Sécurité
Deux rewalls protègent en permanence le système d'information. Un rewall dit "rewall interne" protège les serveurs internes, le second, appelé "rewall internet" sert de
rempart contre les attaques provenant de l'extérieur.
Connexion
Deux connexions 10 Mbits en bre sont utilisées pour avoir accès aux applications
métiers et/ou aux sites hébergés par le Conseil Général. Une connexion de 50 Mbits est
dédié uniquement aux connections avec Internet.
DMZ 3
Pour rappel une DMZ ou zone démilitarisée est un sous réseau distinct du réseau local,
lié à celui-ci et à internet par le biais du rewall, en cas d'attaques externes le pirate n'aura
2. Système d'Information
16
2.4.
ÉTUDE DE L'EXISTANT
accès qu'aux machines placées en DMZ et non au réseau local. Dans la DMZ on retrouve
donc les serveurs et les applications pouvant être accédés depuis l'extérieur, comme le
serveur ftp 4 ou l'application de messagerie.
Figure 2.2 C÷ur de LAN
Connexion
Les diérents sites du Conseil Général sont reliés à la direction informatique par
des liaisons BVPN 5 allants de 2 Mbits à 10 Gbits. Les médias utilisés peuvent être de la
SDSL 6 ou de la bre optique.
Site
Chaque site possède son propre sous-réseau et communique avec les autres sous-réseaux
grâce au switch c÷ur de réseau. Le réseau du Conseil Général est composé donc de VLAN 7
qui correspondent chacun à un site ou une solution technologique (exemple : wi placé sur
le VLAN ***). Enn sur chaque site un serveur de stockage est placé an que les agents
puissent régulièrement eectuer des sauvegardes de leurs documents de travail.
Voici une liste non exhaustive des serveurs qui me paraissent les plus importants (d'autres
tels que les serveurs d'applications etc... n'ont pas été évoqué volontairement) :
2.4.1. A
Le serveur DNS
Un serveur DNS 8 ou serveur de système de nom de domaine est comparable à un annuaire.
En eet lorsque l'on souhaite joindre une machine distante (poste de travail ou serveur) qui se
trouve sur le réseau, notre ordinateur va requêter le serveur DNS pour récupérer l'adresse IP 9 de
4.
5.
6.
7.
8.
9.
File Transfer Protocol
Broadband Virtual Private Network
Symmetric Digital Subscriber Line
Virtual Local Area Network
Domain Name System
Internet Protocol
17
2.4.
ÉTUDE DE L'EXISTANT
la machine à joindre. Tout simplement le serveur DNS permet de faire la relation entre le nom
de la machine et son adresse IP. Ce service a été conguré sous Windows Server 2003 R2.
2.4.1. B
Le serveur DHCP
Un serveur DHCP 10 a pour rôle de distribuer des adresses IP à des clients sur le réseau pour
une durée déterminée (un bail DHCP). Cela permet de délivrer automatique des adresses en
fonction de l'endroit où l'on se connecte. Également ce serveur a été conguré comme l'un des
rôles sous Windows Server 2003 R2.
Par convention, seuls les postes de travail bénécient d'un bail DHCP, et donc d'une durée eective de l'adresse IP aectée à chaque poste, une fois ce bail dépassé, la machine se verra attribuer
une nouvelle adresse IP.
A contrario les autres éléments placés en réseau doivent absolument avoir une adresse IP xe,
notamment les serveurs ainsi que les imprimantes/multifonctions en réseau. En eet pour des
raisons évidents, ces machines sont sollicitées et requêtées régulièrement, il faut donc une adresse
xée. Des plages d'adresses IP sont donc réservées :
Les serveurs sont adressés en 10.2.1.* Les imprimantes et multifonctions en réseaux sont adressés
en 10.*.2.*
2.4.1. C
Le contrôleur de domaine Active Directory
Active Directory est le service d'annuaire de Microsoft. Il faut prendre le terme d'annuaire
au sens large, Les services de domaine Active Directory stockent les données d'annuaire et gèrent
les communications entre les utilisateurs et les domaines, y compris le processus d'ouverture de
session utilisateur, l'authentication et les recherches dans l'annuaire. Le but étant d'orir des
services centralisés. Donc un utilisateur enregistré peut se connecter sur n'importe quel poste
du Conseil Général avec ses propres logins, tant que ce poste est placé correctement sur le domaine. Autre particularité les utilisateurs font partie de groupes que l'on appelle des OU 11 , qui
permettent ainsi d'identier les droits de chacun, et donc les stratégies qui sont appliquées. Un
contrôleur de domaine Active Directory est un serveur qui exécute les services de domaine Active
Directory.
LDAP 12 est le protocole qui permet d'interroger cet annuaire AD.
2.4.2 Easy Vista
EasyVista permet de recenser le matériel actif (gestion de l'inventaire) et de l'associer grâce
à un lien symbolique à des agents et aux services concernés. Le logiciel intègre également la
gestion des logiciels installés sur les équipements informatiques, et surtout les licences associées.
Autre fonctionnalité intéressante et largement exploitée au sein de la DEMS : La gestion des
problèmes, en eet au sein de l'interface se trouve une partie spécialisée dans la création de ches
de signalements d'incidents (chaque che est associée à un ticket unique), qui seront visibles par
les techniciens et seront répertoriées comme étant des interventions.
10. Dynamic Host Conguration Protocol
11. Organizational Unit
12. Lightweight Directory Access Protocol
18
2.4.
ÉTUDE DE L'EXISTANT
Figure 2.3 Exemple de che de signalement d'incident
2.4.3 Le parc Imprimantes
Le parc imprimantes du Conseil Général, se compose d'imprimantes classiques (qui ne disposent pas d'interface réseau, mais elles sont très rares), d'imprimantes monochromes en réseau,
d'imprimantes couleurs en réseau et également de multifonctions en réseau. Suite au dernier recensement du matériel en réseau il s'avère que 448 imprimantes/multifonctions sont placées en
réseau. Elles sont réparties de la sorte :
Figure 2.4 Hétérogénéité du parc d'imprimantes
Ce qui attire tout de suite l'÷il est donc la forte hétérogénéité de ce parc, ceci s'explique tout
simplement car des marchés publics sont établis assez régulièrement lorsqu'une nouvelle demande
est en cours d'exécution, donc il est impossible de privilégier telle ou telle marque de matériel.
Cependant je constate l'énorme pourcentage occupé par la marque HP (une trentaine de modèles diérents tous confondus) qui représente 273 exemplaires, suivi de près par Kyocera (cinq
modèles ) avec ses 104 exemplaires, puis de Toshiba (trois modèles) composé de 59 exemplaires.
19
2.5.
GESTION DE PROJET
Les autres marques ne sont pas vraiment signicatives en terme d'eectifs , à savoir : Lexmark,
Canon et Sharp. Bon nombre des simples imprimantes sont destinées à disparaitre dans un futur
proche, remplacées par des multifonctions au sein des services ( par exemple un service où se
trouvent une imprimante couleurs, une imprimante monochrome et un scanner, se verra attribuer
une multifonction remplaçant tout ce lot de matériels).
2.4.3. A
Panel Top Access
Le Panel Top Access est une application Web, permettant d'administrer, de paramétrer ou de
surveiller à distance l'état de la machine. Ce Panel est disponible sur l'ensemble des imprimantes
et multifonctions en réseau.
2.4.4 Convention de nommage
En informatique une convention de nommage, est une ou plusieurs règles à respecter, en général une suite de caractères qui formalise (dans notre cas d'utilisation) un bien matériel.
En eet chaque bien matériel au Conseil Général possède un identiant unique que l'on appelle
un "code matériel" présent sous la forme d'une étiquette avec un code barre, collée sur chacun
d'entre eux. Lors de la préparation des postes, une étape essentielle est donc le renommage du
matériel pour l'identication sur le réseau (****** représente le code matériel disponible sur
l'étiquette qui est collée) :
PC****** pour les postes de travail
PT****** pour les ordinateurs portables
PR****** pour les imprimantes
En respectant ce nommage, l'inventaire du parc sera facilité et une fois l'ensemble ramené dans
l'outil EasyVista, cela permettra de mieux identier chaque matériel. Des sessions de recensement
sont organisées régulièrement an de maintenir le parc à jour. Kévin et moi-même avons participé
à ses recensements dans le cadre de notre intégration au SSU. Si concernant les postes de travail
et les portables, le renommage est respecté (vis à vis de la procédure à suivre pour la préparation
des postes), pour les imprimantes c'est une toute autre paire de manches, en eet seulement
70 imprimantes/multifonctions en réseau sont nommées correctement à l'aide du Top Access
sur près de 450 matériels. Des mesures seront à prendre très prochainement an de maintenir
l'uniformité du parc des imprimantes.
2.5 Gestion de projet
Figure 2.5 Gestion de Projet
20
2.5.
GESTION DE PROJET
Il est nécessaire de mener une conduite de projet, et donc d'instaurer une certaine trame à
suivre pour le bon déroulement de ce projet. Il faut prendre en compte le contexte (environnement), les fournisseurs (service interne, prestataire...) et l'impact qu'aura notre outil sur les
utilisateurs (référence au besoin).
2.5.1 Équipe Projet
Figure 2.6 Graphe systémique de Patrick IRSAPOULLE
La réussite d'un projet passe par une organisation rigoureuse et ecace de l'équipe projet.
Deux notions sont à identier à présent : la MOA 13 et la MOE 14 .Les techniciens du SSU représentent la MOA, car ils sont à l'origine de l'expression du besoin. Durant ce stage, Kévin
TAOCHY et moi-même avons joué le rôle de chef de projet, nous avons donc formé la MOE,
c'est-à-dire le personnel chargé de prendre connaissance du besoin exprimé et d'y répondre en
y apportant des solutions. Bien entendu, nous avons dû quotidiennement faire appel à nos collègues de la DEMS, qui nous ont apporté leur aide, ou cas inverse, nous-même aider ces personnes.
Ce graphe représente les relations professionnelles entre les diérents acteurs, ces relations sont
exprimées par des èches dont la taille est proportionnelle à l'intensité des interactions entre ces
acteurs.
13. Maîtrise d'ouvrage
14. Maîtrise d'oeuvre
21
2.5.
GESTION DE PROJET
2.5.2 Planning Prévisionnel
Figure 2.7 Planning prévisionnel
2.5.3 Cycle de vie du Projet
Du planning prévisionnel précédent découle le cycle de vie du projet, il a semblé évident que
celui-ci serait un modèle en cascade. Plus simplement à chaque phase d'avancement du projet
une étape de vérication était nécessaire. Chaque n de mois une réunion mensuelle est organisée au SSU, an d'évaluer les tâches du prochain mois, ce qui a été réalisé pendant le mois etc...
Figure 2.8 Modèle en Cascade
Ces mensuelles nous ont permis de résumer notre avancement dans le projet à chacune de ses
phases, une fois que la phase actuelle était validée par notre chef de service, notre tuteur ainsi
que les techniciens, nous avons pu progresser petit à petit. Évidemment ce modèle sous-entend
de terminer à une date précise et de produire les livrables que si ils sont correctement dénis au
préalable.
Figure 2.9 Validation mensuelle de la progression du projet
22
2.5.
GESTION DE PROJET
2.5.4 Spécication des exigences
J'ai dû me consacrer principalement à ces imprimantes et multifonctions pendant que mon
collègue, Kévin, s'occupait des postes de travail. Avant toute étude des technologies à utiliser (le
chapitre suivant) nous avons dû remettre en considération le sujet de stage. En eet si le terme
supervision s'accorde parfaitement avec les imprimantes en réseau, ce n'est pas le cas pour les
postes de travail.
Il faut avouer en eet que superviser près de 3500 postes de travail ne serait pas très judicieux.
En revanche après m'être concerté avec mon collègue Kévin TAOCHY et notre tuteur François
BOYER, il a été convenu que le terme approprié pour les postes de travail serait uniquement
"diagnostic", vu la nature des outils à utiliser. Les états des postes seront achés et les techniciens
pourront se connecter à distance sur ceux-ci grâce à l'interface web uniée.
2.5.5 Exemple d'un scénario et d'un cas d'utilisation
Durant ma période de stage, j'ai pu moi-même assister à un des cas évoqués par notre tuteur
lors de la présentation des thèmes de stage. En eet les agents du CG ne possèdent que peu voire
pas de connaissances concernant la gestion d'un bien matériel telle qu'une imprimante en réseau,
et de toute façon ce n'est pas leur domaine de compétence.
Un scénario classique : Un agent du Conseil Général lance une impression d'un document, rien
ne se passe. Cet agent poste alors une demande d'intervention , en remplissant un formulaire
qui se trouve sur l'intranet. Un des techniciens présents ce jour-là indique sur EasyVista qu'il va
se charger de cette intervention. Il prend donc une des voitures du SSU (le nombre de véhicules
étant assez limité) se rend sur le site concerné an de dépanner cet agent, et une fois sur place,
se rend compte qu'une cartouche couleur était totalement vide et donc empêcher le lancement
de l'impression.
Reprenons dans l'ordre, pour cette intervention superue :
Temps de travail perdu pour une pseudo-intervention
Un technicien mobilisé alors que d'autres interventions n'ont pas pu être résolues
Un véhicule a été mobilisé, ce qui obligera peut-être un autre technicien à attendre le retour
de celui-ci
Du carburant a été consommé lors de ce trajet, et représente donc une dépense non indispensable
Si une application telle que celle que nous allons mettre en place était déjà disponible, le niveau
d'alerte d'encre aurait pu être remonté et un technicien aurait pu prévenir le service concerné
an de changer la cartouche dont il est question.
Cette situation semble exagérée à première vue, mais selon les techniciens ces cas arrivent tellement souvent, que nous ne pouvons les négliger.
Il faut prendre un peu de recul an d'observer la situation actuelle, en anticipant ce genre
de problèmes et donc d'établir un diagnostic de premier niveau (matériel et/ou logiciel), nous
pourrons sur le court terme, augmenter les interventions à distance, et surtout les rendre plus
ecientes. Sur le long terme, le problème des restrictions budgétaires qui est évoqué actuellement,
ne sera certes pas résolu en évitant ces trajets et donc ces dépenses non essentielles, mais il n'y
a pas de petites économies. Ainsi cumulés ces fonds pourront servir à d'autres missions plus
nécessiteuses.
23
Chapitre 3
État de l'art
3.1 Introduction
Une fois l'environnement de travail étudié, il fallait trouver des solution pour répondre à
notre problématique. Intervient alors l'étape de l'état de l'art, c'est-à-dire l'état des techniques
existantes dans le domaine étudié, sans que nous ayons besoin de faire preuve d'une activité
inventive. "Il ne faut pas réinventer la roue." Les sources peuvent être diverses : journaux,
revues et publications scientiques, articles, rapports de recherches... Cette démarche m'a permis
de dénir les technologies à utiliser et à appliquer.
3.2 L'aspect Monitoring
Le terme Monitoring couramment utilisé, provient de l'anglais, il signie supervision. Cependant une précision est à apporter, en eet ceci est un abus de langage, car en vérité le Monitoring
est composé de deux disciplines : la métrologie et la supervision.
La métrologie permet de créer des historiques de données, d'y appliquer un traitement (des ltres
par exemple) an d'extraire les données qui nous intéressent et de les présenter sous forme de
graphiques. Cet historique des données permet si besoin d'apporter des correctifs au niveau des
paramétrages des services, le juste pourcentage des ressources à utiliser... Cet aspect du Monitoring est tout aussi important car il va permettre d'améliorer le service, et donc ainsi le rendu
de l'utilisateur.
Concentrons-nous à présent sur la véritable notion qui est dénie dans ce rapport à savoir la
supervision. Une dénition récurrente sur le Web indique que : "la supervision est une technique
de suivi de pilotage informatique de procédés de fabrication automatisés. La supervision concerne
l'acquisition de données (mesures, alarmes, retour d'état de fonctionnement) et des paramètres
de commande des processus généralement conés à des automates programmables."
En résumé la supervision est la surveillance du bon fonctionnement d'un système ou d'une activité. En eet quel que soit le secteur d'activité, l'informatique est devenue l'épine dorsale de
l'entreprise. Plus particulièrement le système d'information qui est au centre de l'activité de
diérentes entités métiers, doit fonctionner correctement et en permanence an de garantir l'efcacité de l'entreprise.
Les problèmes liés à l'informatique doivent donc être réduits le plus que possible, car l'indisponibilité d'un ou plusieurs éléments, quel que soit son niveau signicatif (réseau, serveurs d'applications, serveurs de données, terminal utilisateur...) inuera sur la qualité de service et donc le
bon fonctionnement de l'entreprise.
24
3.2.
L'ASPECT MONITORING
Deux enjeux majeurs sont à noter :
garantir la disponibilité et les niveaux de service du système en cas de panne ou de baisse
des performances
tenter de prévenir l'administrateur des diérents problèmes et au besoin assurer une remontée des informations an de garantir une durée d'intervention minimale
3.2.1 Que peut-on superviser ?
La supervision est un vaste domaine de l'informatique qui reprend plusieurs activités dont
les principales sont :
Surveiller
Visualiser
Analyser
Piloter
Alerter
La véritable question à se poser serait " est-ce qu'un système d'information peut ne pas avoir de
faille ? "
Concrètement an de maintenir un fonctionnement optimal, tout devrait être supervisé, ou du
moins peut-être supervisé du moment que l'on peut déterminer un état :
réseau
serveurs
périphériques
postes client
applications...
Libre à l'administrateur de placer des niveaux de priorités entre les diérents éléments pour
dénir ce qui doit ou ce qui ne doit pas être supervisé selon diérents critères (charge du réseau,
manque de moyens...).
Actuellement à la DEMS, ne sont supervisés que les switchs, serveurs et tout ce qui touche à
l'état du réseau en lui-même (trac eectif).
Il sera important de rajouter les diérentes imprimantes et multifonctions en réseau parmi les
périphériques à superviser. Concernant les postes de travail, ils sont trop nombreux et les remontées d'informations sur ceux-ci ne seraient pas assez pertinentes pour évaluer les problèmes. Des
outils d'administration plutôt que de supervision seront à adopter pour ce type de matériel.
3.2.2 Méthodes de Supervision
Deux grandes méthodes s'opposent lorsque l'on parle de supervision.
le polling
le heartbeat
Le Polling est un sondage réalisé périodiquement (à intervalle de temps régulier) par un superviseur.
25
3.2.
L'ASPECT MONITORING
Avantages
Polling
A l'initiative du superviseur
Permet un véritable suivi
Inconvénients
Des échanges pour rien
Temps de réaction
Possibilité de ne pas voir certains changements
Figure 3.1 Méthode du Polling
Le HeartBeat est un signal émis par un équipement à chaque changement d'état.
Avantages
HeartBeat
Des échanges si nécessaire
Temps de réaction
Tous les changements d'états sont remontés
Inconvénients
Suivi moins complet
A l'initiative de l'équipement actif
Figure 3.2 Méthode du heartbeat
En conclusion il n'y a pas de meilleure ou de moins bonne solution, mais il faut penser à orienter
le concept en fonction du projet que l'on veut mener.
Suite à une longue réexion an de déterminer lequel des deux concepts était le plus approprié à
notre projet, nous avons ni par conclure que celui-ci se rapprochera le plus du Polling, il faudra
qu'un serveur central interroge régulièrement les périphériques, et stocke les données, cependant
aucune notication particulière ne sera renvoyée.
L'outil sera à utiliser au besoin et donc sur demande, uniquement lorsque les pannes seront référencées et indiquées. C'est pour cela que l'on couple la notion de Supervision à celle de Diagnostic.
26
3.2.
L'ASPECT MONITORING
3.2.3 Les diérentes solutions
Un outil de supervision doit répondre aux critères suivants :
des mécanismes pour déterminer l'état d'une ressource/process
une console de monitoring
des remontées d'alertes
3.2.3. A
Les solutions propriétaires
Commençons par les solutions dites propriétaires. Quatre grosses sociétés se partagent le
marché de la supervision, elles sont appelées le "Big4".
Figure 3.4 HP Openview
Figure 3.3 Ibm Tivoli Software
Figure
3.5 Computer Associates Technologies Unicenter
Figure 3.6 HP Openview
Le but n'était évidemment pas d'acheter une ou plusieurs licences de logiciels propriétaires.
Même si ceux-ci proposent des solutions confortables, avec des atouts tels que le support et la
maintenance. Il faut comprendre qu'à l'heure actuelle, les anciens critères (abilité, support...)
qui opposaient les logiciels propriétaires aux logiciels Open Source ne sont plus valables. En effet aujourd'hui il est tout à fait possible d'avoir un Système d'Information dans une entreprise
composé uniquement de logiciels Open Source.
Leur principal atout ? Non pas la gratuité comme beaucoup le pense, mais bel et bien les réelles
communautés sur lesquelles s'appuient les solutions. Universitaires, développeurs reconnus, professionnels tous s'associent désormais et forment les principaux contributeurs du monde Open
Source. Mieux encore les développeurs de logiciels propriétaires se séparent de leurs précédentes
rmes dans le but d'orir leurs propres solutions libres.
Ces solutions qui ont vu les jour et qui sont testées maintes et maintes fois avec des correctifs réguliers, sont totalement ables, orent une modularité (plugins etc...) et une compatibilité totale.
En eet nit le problème des protocoles propriétaires, les normes sont adoptées et respectées, ce
qui permet d'établir une certaine souplesse et donc cela autorise l'hétérogénéité du matériel à
acheter.
L'administrateur ayant adopté une telle solution ne verra qu'une seule et véritable contrainte,
le besoin constant de rester informé sur la technologie, il faudra régulièrement se rendre sur les
forums, les blogs tout ce qui est capable de rééchir l'aspect communautaire, et ainsi d'orir
des réponses aux questions posées. Cet échange de bon procédé, permettra de mettre à jour
régulièrement les solutions et de les adapter en fonction du besoin utilisateur.
Voyons à présent les solutions disponibles dans le monde de l'Open Source concernant le domaine
de la supervision.
27
3.2.
L'ASPECT MONITORING
Figure 3.7 Métrologie ou Supervision ?
3.2.3. B
Les solutions Open Source
Il faut savoir qu'il existe des dizaines de solutions Open Source dédiées au Monitoring, le
principal critère de choix réside dans les diérents cas d'utilisation.
Dans cette partie sont présentées quatre solutions parmi les grands noms du Monitoring, à savoir :
Zabbix, Cacti,Nagios et Centreon (d'autres solutions telles que "Munin" ont été volontairement
ignorées car elles sont décrites comme présentant uniquement le côté métrologie du Monitoring).
Ainsi un comparatif sera établi an de dénir correctement quelle solution sera la plus appropriée
en terme de supervision et non de métrologie.
1.
Zabbix est une application libre (open source) de supervision des systèmes et des réseaux.
Par sa polyvalence, Zabbix peut superviser et vérier les statuts d'une multitude de services réseaux, ou systèmes, ce qui fait de lui un outil complet proposant des fonctionnalités
relatives à la supervision (alertes, mesures, actions sur conditions...).
Le principal reproche vient de l'aspect graphique où dans certains cas la lisibilité laisse à
désirer. Certains lui reprochent également son interface web dite un peu "vieillotte" et la
prise en main initiale n'est pas forcément intuitive.
2.
Cacti est un outil de monitoring qui a la particularité d'avoir une " Plugin architecture"
qui va lui permettre l'ajout de fonctionnalités grâce à l'importation et à la congurations
de plugins via l'interface web. L'aspect supervision proposé ici ne sera pas aussi développé
que dans les autres logiciels (nagios par exemple), on notera par exemple l'absence de panel
de msesures, de groupes d'utilisateurs...
Donc Cacti reste un outil de métrologie intégrant de nombreuses possibilités grâce aux
plugins, avec la possibilité d'une mise en place de supervision mais uniquement dans les
cas les plus simples.
3.
28
3.2.
L'ASPECT MONITORING
Nagios est ce que l'on appelle un ordonnanceur , c'est-à-dire qu'il va lancer les diérents
tests de supervision, appelés contrôles, sur les hosts et services. Il reste l'outil de supervision le plus utilisé à l'heure actuelle, sa conguration sous forme de chiers, peut s'avérer
vite repoussante mais en fait cependant un candidat idéal pour l'automatisation.
L'inconvénient de Nagios reste son IHM 1 très basique. Il faut avouer que son interface
ne donne pas spécialement envie d'être consultée, en eet au delà de la pertinence de
l'information, il faut de la compréhension et de l'interprétation. C'est sur ce constat que
vient se greer la prochaine solution décrite : Centreon.
4.
Centreon, une interface à Nagios. Première précision à apporter, le coeur de Centreon est
basé sur Nagios. Centreon propose une interface web diérente de celle de Nagios et y
ajoute des fonctionnalités (génération de la conguration de Nagios, stockage des données
de performance, interface ergonomique...).
En résumé, Centreon est considéré comme un outil à part entière même si il est basé sur
Nagios comme ordonnanceur. Il propose donc au sein d'une même interface tout ce qui est
nécessaire à la surveillance de l'infrastructure et donc à faire de la supervision pure et dure.
Malgré tout il ne propose que le minimum concernant la métrologie, on ne pourra pas par
exemple remonter des informations orientées services comme celle d'une base de donnée,
que l'on pourrait avoir sous Cacti ou Munin.
3.2.3. C
Comparatif général des solutions Open Source
Solution
Zabbix
Cacti
Nagios
Centreon
Avantages
- Outil complet
- Polyvalent (supervision + métrologie)
- Outil de métrologie complet
- Multitude de fonctionnalités grâce
aux plugins
- Outil de supervision par excellence
- Automatisation (templates)
- Mesure des ressources
- IHM agréable et intuitive
- Basé sur le c÷ur de Nagios
Inconvénients
- Prise en main complexe
- Manque de lisibilité sur certains
écrans
- Création complexe des templates
- Insusant pour une supervision
d'un grand parc matériel
- IHM à améliorer
- Conguration par chier
- Pas d'exploitation graphique des
mesures
- L'aspect Métrologie est des plus
simples
- Pas de graphes corrélant les performances (utilisation d'un Apache
par exemple)
- Zabbix propose une interface uniée, avec des fonctions avancées, la partie métrologie présente présente vraiment des notions intéressantes (graphes complexes de mesures...), sa prise en
main n'est pas assez intuitive pour compenser son IHM qui est moins agréable que Centreon par
exemple.
- Il s'avère qu'au nal, Cacti soit un outil de métrologie avancée (pas autant que Munin),
même si il présent un aspect de supervision, pas assez développé malheureusement pour conduire
à son choix.
1. Interface Homme Machine
29
3.2.
L'ASPECT MONITORING
- Nagios semble parfait pour l'automatisation des congurations et la gestion centralisée de
l'infrastructure, son gros désavantage est et restera son interface graphique qui repoussera tous
les débutants dans le domaine de la supervision.
Mon choix s'est donc porté sur Centreon, an de bénécier d'une supervision complète, avec également des possibilités de métrologie simple (ceci ne nous intéresse pas
vraiment), les générations de congurations automatiques, et son interface intuitive
en font un outil de choix à mettre en place.
3.2.4 La solution retenue : Centreon Enterprise Server
Centreon est une marque de la société Meréthis. Outre les arguments présentés
précédemment et qui ont conditionné mon choix, il fallait se décider sur la version à installer.
Suite à des recherches plus approfondies et aux conseil de Vincent BEAUVAL, je me suis
penché sur une variante de la solution, à savoir : Centron Entreprise Server.
Finit les installations "brique par brique", rappelons qu'à la base Centreon est une surcouche de
Nagios, et donc logiquement il fallait procéder à une installation complète de Nagios (plugins..)
puis à l'installation de Centreon. Grâce à CES, on retrouve le meilleur de la suite Centreon
dans une solution ecace, complète et maintenue au sein d'un même package. L'intérêt est bien
entendu de déployer rapidement les outils nécessaires à notre supervision vis-à-vis de notre infrastructure.
La solution est présentée sous la forme d'une image ISO, on peut alors la graver pour procéder à
l'installation, ou tout simplement créer une machine virtuelle basée sur celle-ci. Une fois installée
(comptez une vingtaine de minutes), CES est prêt à l'emploi. Il est composé des diérents outils
suivants :
1. Un noyau Linux
CES est basé sur la distribution Centos 6.5, elle-même basée sur RedHat
Enterprise Linux (REHL). Le principal avantage vient de l'outil YUM qui facilite l'exploitation
et la gestion des paquets au format RPM a , toutes les dépendances sont automatiquement
calculées par YUM, il n'est donc pas nécessaire de vérier les versions de chaque paquet. Un
simple "yum update" permet de mettre à jour tous les éléments de CES.
a. Redhat Package Management
2. Un Ordonnanceur (moteur central)
Depuis sa dernière release en date (mars 2014),CES propose le choix de deux
ordonnanceurs, le premier Nagios le plus classique connu de tous, et le second Centreon Engine,
développé par les équipe de Meréthis. Celui-ci ore une alternative au moteur central Nagios,
mais est cependant basé su Nagios 3.2. C'est un véritable challenge que se sont lancés les
équipes de Meréthis, en ne cachant pas qu'ils souhaitent à long terme remplacer Nagios par leur
propre ordonnanceur.
30
3.2.
L'ASPECT MONITORING
3. Un Broker
Un Broker est un module chargé de remonter les informations dans la base de données.
Initialement CES ne proposait que ndOutils, qui allait de pair avec Nagios. Mais depuis
l'arrivée de Centreon Engine, Meréthis a également développé son propre module, à savoir
Centreon Broker.
4. Une IHM intuitive
Ne nous attarderons pas ici, une description a déjà été faite au préalable, il
s'agit bien évidemment de Centreon lui-même, qui fournit une interface simpliée, pour rendre
la consultation de l'état du système accessible aux utilisateurs, également à présent les
informations et l'administration des ordonnanceurs sont inclus dans l'interface (sous le nom de
Monitoring Engine).
5. Un Serveur HTTP
CES propose la version propose la version la plus récente de APACHE (la
version 2) qui est actuellement le serveur HTTP le plus utilisé pour le développement. Son
support Multi-plateformes ainsi que les processus légers UNIX en font un incontournable.
6. Une base de données et son SGBD
Une base de données est installée an de permettre la remontée des
données à l'aide du Broker. An d'innover et de changer du classique Mysql Server, Meréthis
décide d'inclure suite à une conférence sur MySQL et MariaDB, le second à sa suite CES pour
des raisons de qualité et de performances. MariaDB se base sur le code source de MySQL 5.1, il
est donc 100 % compatible avec celui-ci et dispose des mêmes dépendances (par exemple si l'on
veut que PHP5 dialogue avec le serveur MariaDB il faut installer le paquet " php5-mysql").
Diérentes versions du package CES sont ainsi proposées. La version Standard est Open Source,
elle est donc libre et gratuite. Les autres versions quand à elles nécessitent une souscription
annuelle, ces versions proposent un support et donnent également accès à des sondes et des
modèles complémentaires touchant la partie matérielle. Nous nous contenterons de la version
Standard qui semble parfaitement répondre à nos attentes.
3.2.5 Le protocole de supervision
An de superviser des hôtes, il faut bien évidemment un serveur central relié à la totalité des
hôtes. Le véritable problème qui se pose par la suite, comment faire communiquer ecacement
ce serveur central avec les hôtes à superviser ? Entre en jeu la notion de protocole de supervision,
qui indépendamment de la plateforme et/ou du type de matériel devra assurer la communication
entre les acteurs précédents. SNMP nous avait été plus que suggérée lors de la présentation
du sujet de stage par notre tuteur. Le chapitre suivant explique les diérents mécanismes qui
entrent en jeu lors de l'utilisation du protocole SNMP, ainsi que ses avantages qui ont conduit à
son utilisation.
31
Chapitre 4
Le protocole solution pour la
supervision en réseau
4.1 Présentation de Simple Network Management Protocol
Un chapitre entier est dédié à l'étude de ce protocole sur lequel repose l'ensemble des requêtes
eectuées lors de la collecte des informations concernant les imprimantes (et multifonctions) en
réseau.
SNMP est un protocole de gestion de réseaux proposé par l'IETF 1 , un groupe informel et
international, ouvert à tout individu et participant à l'élaboration de standards Internet). Il reste
actuellement le protocole le plus couramment utilisé pour la gestion des équipements en réseaux.
SNMP est écrit en ASN.1 2 , un standard international spéciant une notation qui est destinée
à décrire des structures de données.
Comme son nom l'indique SNMP est un protocole assez simple, mais sa principale force réside
dans le fait de pouvoir gérer des périphériques hétérogènes et complexes sur le réseau. De ce fait
ce protocole peut également être utilisé pour la gestion à distance des applications : bases de
donnée,serveurs, logiciels...
L'environnement de gestion SNMP est constitué de plusieurs composantes :
Le Manager (station de supervision) exécute les applications de gestion qui contrôlent les
éléments réseaux, la plupart du temps le manager est un simple poste de travail
Les éléments actifs du réseau, sont les équipements que l'on cherche à gérer (switchs,
serveurs...)
La MIB (Management Information Base), est une collection d'objets résidant dans une
base d'information virtuelle
Le Protocole, qui eectue la relation entre le Manager et les éléments actifs
Chaque élément actif dispose d'une entité que l'on appelle un "agent", qui répond aux requêtes
du Manager.
32
4.2.
LES PRINCIPAUX ÉLÉMENTS
Figure 4.1 Schéma SNMP de communication de base
4.2 Les principaux éléments
4.2.1 Le Manager
Rappelons que le Manager se trouvera sur un machine d'administration (un poste de travail
en général). Il reste un client avant tout, étant donné que c'est lui qui envoie les diérentes requêtes aux agents. Il devra disposer d'une fonction serveur, car il doit également rester à l'écoute
des alertes que les diérents équipements sont susceptibles d'émettre à tout moment.
Si l'on se base sur le schéma précédent, l'administrateur peut observer correctement le comportement de ses diérents équipements en réseau.
Le Manager dispose d'un serveur qui reste à l'écoute sur le port UDP 162 ainsi que d'éventuels
signaux d'alarme appelés des "traps". Le Manager peut tout autant être installé sur une machine
de type Windows, qu'une machine de type UNIX.
4.2.2 Agent SNMP
L'agent est un programme qui fait partie de l'élément actif du réseau. L'activation de cet
agent permet de recueillir la base de données d'informations et la rend disponible aux interrogations du Manager SNMP. Ces agents peuvent être standards (Net-SNMP par exemple) ou encore
spécique à un fournisseur (HP insight agent par exemple).
1. Internet Engineering Task Force
2. Abstract Syntax Number 1
33
4.3.
DES INFORMATIONS STRUCTURÉES
Cet agent doit rester à l'écoute d'un port particulier, le port UDP 161.
Les principales fonctions d'un agent SNMP :
Collecter des informations de gestion sur son environnement local
Récupérer des informations de gestion tel que déni dans la MIB propriétaire
Signaler un évènement au gestionnaire
Par ailleurs même si la principale fonction de l'agent est de rester à l'écoute des éventuelles
requêtes du Manager et y répondre si il y est autorisé, il doit également être capable d'agir de
sa propre initiative, s'il a été conguré.
Par exemple, il pourra émettre une alerte si le débit d'une interface réseau, atteint une valeur
considérée par l'administrateur comme étant critique. Plusieurs niveaux d'alertes peuvent ainsi
être dénis, selon la complexité de l'agent (température du processeur, occupation disque dur,
utilisation CPU...).
Figure 4.2 Les échanges entre le Manager et l'Agent
4.3 Des informations structurées
4.3.1 Management Information Base
Chaque agent SNMP maintient une base de données décrivant les paramètres de l'appareil
géré. Le Manager SNMP utilise cette base de données pour demander à l'agent des renseignements spéciques. Cette base de données commune partagée entre l'agent et le Manager est
appelée Management Information Base (MIB).
Généralement ces MIB contiennent l'ensemble des valeurs statistiques et de contrôle dénis pour
les éléments actif du réseau. SNMP permet également l'extension de ces valeurs standards avec
des valeurs spéciques à chaque agent, grâce à l'utilisation de MIB privées.
Un chier MIB est écrit en utilisant une syntaxe particulière, cette syntaxe s'appelle SMI 3 ,
basée sur ASN.1 tout comme SNMP lui-même.
En résumé, les chiers MIB sont l'ensemble des requêtes que le Manager peut eectuer vers
l'agent. L'agent collecte ces données localement et les stocke, tel que déni dans la MIB. Ainsi
le Manager doit être conscient de la structure (que celle-ci soit de type standard ou privée)de la
MIB an d'interroger l'agent au bon endroit.
3. Structure of Management Information
34
4.3.
DES INFORMATIONS STRUCTURÉES
4.3.2 Structure d'une MIB et Object IDentier
Rappelons que la MIB est une collection d'informations pour la gestion des éléments du réseau. Sa structure est une arborescence hiérarchique dont chaque noeud est déni par un nombre
ou un Object IDentier (OID). Chaque identiant est unique et représente les caractéristiques
spéciques du périphérique géré. Lorsqu'un OID est interrogé, la valeur de retour n'est pas un
type unique (texte,entier,compteur,tableau...) Un OID est donc une séquence de chires séparés
par des points.
Une MIB est un arbre très dense, il peut y avoir des milliers d'OID dans la MIB.
Figure 4.3 Structure de l'arborescence d'une MIB
Cet exemple illustre d'ailleurs un object typique qui est déclaré dans la RFC1213, à savoir le
"sysDescr" (une description du périphérique interrogé) dont l'OID s'écrit .1.3.6.1.2.1.1.1.
Une petite particularité est à signaler dans la MIB il s'agit de la branche "private" aussi appelée
"private enterprises" (dont l'OID est 1.3.6.1.4.1). Cette branche permet à chaque entreprise
de gérer sa MIB spécique. Chaque entreprise se voit attribuer un OID unique et se retrouve
alors à la charge de la gestion de sa branche. Les diérents OID d'entreprises sont alloués par
l'IANA 4 qui est l'organisation dont le rôle est la gestion de l'espace d'adressage IP d'Internet,
ainsi que d'autres ressources partagées de numérotation qui sont requises par des protocoles de
communication sur Internet.
4. Internet Assigned Numbers Authority
35
4.4.
LES PARAMÈTRES D'INTERROGATIONS
4.4 Les paramètres d'interrogations
4.4.1 Les paquets à installer
Nous avons vu au préalable,quels éléments nous avons besoin an d'eectuer des requêtes
SNMP, il faut s'assurer que notre Manager dispose d'une environnement SNMP, pour se faire
le mieux est d'installer et de congurer un serveur SNMP en utilisant la solution open-source
"net-snmpd".
La suite CES dispose déjà d'un serveur SNMP installé et les congurations sont déjà eectuées
de manière à ce le package puisse être déployé immédiatement, et que les requêtes puissent se
faire sans problème.
4.4.2 Les diérentes versions de SNMP
Depuis la création de SNMP, ce protocole a connu des améliorations importantes. Cependant
les précédentes versions (la V1 et la V2C) sont encore les versions les plus utilisées actuellement.
Un support de SNMP V3 a récemment été lancé car il est plus sécurisé si on le compare à ses
prédécesseurs.
1. SNMP V1 : C'est la première version du protocole. La sécurité de cette version est minimale, car elle basée uniquement sur la chaîne de caractère appelée "communauté". Cette
version du protocole est dénie dans les RFC 1155 et 1157.
2. SNMP V2C : C'est un protocole révisé, qui comprend les améliorations de SNMP V1 dans
diérents domaines tels que :
Les types de paquets
Les éléments de structure MIB
Les requêtes protocolaires MIB
Cependant ce protocole utilise la structure d'administration de SNMP V1 ( à savoir "communauté") d'où le terme SNMP V2C
3. SNMP V3 : Aussi connu sous le nom de version sécurisée de SNMP. SNMP V3 facilite la
conguration à distance des entités SNMP.
Ces trois versions sont les principales, même si des versions intermédiaires ont vu le jour (SNMP
Sec, SNMP V2, SNMP V2U,SNMP V2P), celles-ci ne présentent que des mises à jours mineures
plutôt que de véritables améliorations.
Actuellement les versions les plus utilisées (par ordre d'utilisation) sont : SNMP V1, SNMP V3
puis SNMP V2C.
Malgré tout la version SNMP V1 perdure encore sur les périphériques, plusieurs facteurs explique
ce phénomène :
Les infrastructures déployées en V1 ne sont plus modiées, tout simplement car cela fonctionnait susamment à l'époque, du coup aucune modication n'y est appliquée
Les autres versions de SNMP ont été implémentées tardivement par les diérents constructeurs
SNMP V1 demande très peu de ressources sur des petits équipements tels qu'une imprimante ou un Hub
36
4.5.
LES REQUÊTES SNMP
4.4.3 Les communautés
La notion de communauté est utilisée dans les réseaux administrés à l'aide du protocole
SNMP. Elle réunit à la fois le Manager et les diérents agents. Chaque communauté est identiée par un nom de communauté. Par défaut seules les communautés "public" et "private" sont
dénies, cependant il est possible de nommer sa propre communauté, ceci à des ns évidents de
sécurité et donc de créer son propre domaine d'administration.
Ces dénitions de communautés permettent :
L'authentication : Consiste à envoyer une requête avec comme mot de passe le nom de la
communauté, permettant au récepteur de vérier l'authenticité de ce dernier
La politique d'accès : Pas d'accès, read-only ou read-write
Le service Proxy : Si les périphériques sont gérées par l'intermédiaire d'un proxy, ce dernier
connait les objets utilisés pour gérer la machine mandatée, et gère la politique d'accès
adéquat
4.5 Les requêtes SNMP
4.5.1 Les formats de requêtes
Commande
get-request
get-next-request
set-request
get-reponse
trap
Action
Le Manager SNMP demande une information à un agent
Le Manager SNMP demande l'information suivante à un agent
Le Manager SNMP met à jour une information sur un agent SNMP
L'agent SNMP répond à un get-request ou à un set-request
L'agent SNMP envoie une alerte au Manager
Les commandes get-request, set-request et get-next-request sont toutes émises par le Manager à
destination d'un agent, elles attendent une réponse de type get-response de la part de l'agent.
La commande trap quand à elle est une alerte, c'est-à-dire qu'elle sera toujours émise par l'agent
vers le Manager, cependant elle n'attend aucune réponse.
4.5.2 SnmpWalk
An de tester les requêtes SNMP, le plus simple est de commencer par les requêtes à eectuer
en ligne de commande plutôt que de se lancer dans l'exécution de plugins etc... Deux commandes
standard existent : SnmpWalk et SnmpGet. Commençons par SnmpWalk. Cette commande permet de récupérer toutes les valeurs d'un OID de type n÷ud, rappelons que la structure est une
arborescence donc, si l'OID interrogé n'est pas une feuille, nous allons récupérer toutes les valeurs
du sous-arbre (d'où le terme "walk" qui signie parcourt). SnmpWalk obtient ces informations
car la commande est dénie comme étant une suite de séquences au format "get-next-request"
Pour utiliser cette commande, voici les paramètres à respecter :
Listing 4.1 Format de commande SnmpWalk
1
snmpwalk −v < l a v e r s i o n > −c < lacommunaute > < a d r e s s e i p > < o i d >
37
4.5.
LES REQUÊTES SNMP
Figure 4.4 Exemple de requête SnmpWalk
4.5.3 SnmpGet
SnmpGet quand à lui permet de récupérer la valeur d'un OID feuille spécique, donc nous
obtiendrons une seule et unique valeur. La syntaxe de la commande est identique à celle de
SnmpWalk. Si le SnmpWalk nous permet de trouver les sous-arbres disponibles, la contrainte
évidente avec SnmpGet est qu'il faut impérativement savoir quel OID interroger. Pour cette
raison, nous utiliserons uniquement la commande SnmpWalk dans la suite de ce projet.
Listing 4.2 Exemple d'exécution de la commande SnmpGet
1
2
s n m p g e t −v 2 c −c d e m o p u b l i c t e s t . n e t −snmp . o r g SNMPv2−MIB : : sysUpTime . 0
SNMPv2−MIB : : sysUpTime . 0 = T i m e t i c k s : ( 5 8 6 7 3 1 9 7 7 ) 67 days , 2 1 : 4 8 : 3 9 . 7 7
38
Chapitre 5
Réalisation
5.1 Les outils utilisés
La phase de réalisation et de mise en ÷uvre a nécessité l'installation de plusieurs outils dont
voici un aperçu :
VMware Workstation 10 est ce que l'on appelle un hyperviseur, c'est-à-dire une
1.
plate-forme de virtualisation qui permet de faire cohabiter diérents systèmes d'exploitation
sur une même machine physique. Il intègre une gestion complète des périphériques ainsi que du
son, de la vidéo, la prise en charge réseau...Je me suis servi de cet hyperviseur pour créer ma
machine virtuelle avec comme base l'iso CES 3.0, la procédure est détaillée en annexe technique
à la n de ce rapport. Pourquoi ne pas utiliser le serveur déjà en production ? Pour des raisons
évidentes de sécurité, l'utilisation du serveur existant était à proscrire. De même une
duplication aurait pu être eectuée pour les premiers tests, mais CES a bénécié d'une mise à
jour au cours de cette année. J'ai donc entrepris l'installation de la dernière version en date
tout en m'assurant qu'il serait possible de migrer mon serveur et de le placer en production
sans qu'il n'altère celui déjà en place.
2.
3.
Notepad ++ est l'un des éditeurs de code source les plus connus, sa coloration
syntaxique et sa simplicité en font un outil de choix à garder constamment sous la main.
PuTTY est un émulateur de terminal UNIX qui permet de se connecter à distance à
une machine ou un serveur, en utilisant les protocoles SSH, Telnet ou Rlogin. L'ensemble des
sessions peuvent être automatiquement enregistrées sous forme de rapport an d'être consultées
ultérieurement.
39
5.2.
DE LA SUPERVISION DES IMPRIMANTES...
4.
WinSCP, visuellement il se présente comme un outil de transfert FTP, il
permet de lire le contenu des répertoires, d'éditer ou de supprimer des chiers, et surtout
d'assurer des copies ou des déplacements de chiers entre la machine hôte, et le poste sur lequel
nous sommes connectés, tout cela en se basant sur le protocole SSH.
5.
Nmap est un scanneur de port réseau, disponible sous Unix et Windows. Ce
logiciel a pour but de détecter les ports réseau ouverts sur une machine, ainsi il permet de
détecter si la machine en question est bien présente sur le réseau, et également d'identier les
services qui tournent dessus.
6.
phpMyAdmin est une interface pour gérer les base de données MySQL, il faut
avouer qu'explorer une ou plusieurs base de données dans un terminal n'est pas chose facile.
Cette interface permet de naviguer entre les bases, les tables et même d'eectuer des requêtes
au format SQL.
5.2 De la supervision des imprimantes...
5.2.1 Notion d'hôte/de groupe d'hôtes
Un hôte est un bien matériel que l'on souhaite superviser, dans notre cas une imprimante
ou une multifonction en réseau. Auparavant il fallait impérativement congurer les hôtes par le
biais de chier de conguration en ligne de commande, ces opérations assez fastidieuses ont été
simpliées grâce à Centreon qui à l'aide de champ pré-remplis nous génère le chier de conguration automatiquement. Il sura alors de redémarrer Nagios (par le biais de Centreon également)
an que le nouvel ajout soit pris en compte par le serveur.
Chaque dénition d'hôte se base sur un template (un modèle pré-créé), il est intéressant de
modier un template an de répliquer ses spécications (intervalle de check, notications...) aux
hôtes que l'on dénira plus tard s'appuyant sur celui-ci.
Un groupe d'hôte à présent, considérons nos imprimantes, il est pertinent de dénir un groupe
d'hôte selon chaque marque d'imprimante étant donné que celles-ci partagent des caractéristiques
communes et donc se verront attribuer des services communs (cette notion sera dénie dans la
section suivante). Tout simplement, prenons un peu de recul, il sera plus simple de dénir un
service à un groupe d'hôtes, plutôt que de dénir le même service à chaque hôte. Entre en jeu la
notion de parent et d'enfant.
5.2.2 Dénition de commande
Une commande sous Nagios, est similaire à une commande UNIX que l'on taperait en ligne
de commande an de récupérer des informations. La plupart des commandes s'appuient sur des
scripts déjà en place ou à télécharger.
5.2.3 Dénition de service
Un service est l'application d'une commande, il faut la congurer avec les arguments à prendre
en compte, les intervalles de check et les éventuelles notications à envoyer, si notications il doit
40
5.2.
DE LA SUPERVISION DES IMPRIMANTES...
y avoir. Il sut ensuite d'appliquer une relation entre le service et un groupe d'hôte, an que
tous les hôtes concernés soient check en temps voulu.
5.2.4 Installation de plugins pour Nagios
Comme le dit l'adage, il ne faut pas réinventer la roue, de nombreux plugins existent déjà, un
site communautaire les recense d'ailleurs : http://exchange.nagios.org/directory/Plugins
La majorité des plugins sont écris en Php ou en Perl, des dépendances sont à installer si
Nagios ne reconnait pas ces plugins. L'installation est très simple il sut de placer le plugin dans
le bon répertoire : "usr/lib/nagios/plugins/", de restart Nagios, puis de dénir une nouvelle
commande basée sur le nom du plugin.
5.2.5 Architecture de CES
Figure 5.1 Architecture globale de CES
Ce schéma illustre parfaitement le mode de fonctionnement, ainsi que les interactions entre
les diérents composants de la solution.
Centreon notre interface web permet non seulement d'acher les diérents statuts du matériel
supervisé, mais surtout de congurer et d'administrer Nagios sans avoir à passer par un terminal.
Quelques clics susent à charger une conguration, à rajouter des hôtes, créer des services et
des commandes, et également redémarrer le service Nagios.
41
5.3.
... AU DIAGNOSTIC
Nagios notre serveur central, ici conguré en mode architecture simple RRDtool quand à lui ne
nous intéresse pas vraiment, sa principale fonctionnalité est d'établir des graphes sur les données
de performances (utiles pour des serveurs supervisés par exemple).
5.2.6 Le combo Nagios et ndOutils
Figure 5.2 Nagios et ndOutils
Ndomod et Ndo2db sont deux éléments plus qu'essentiels à la suite CES, leurs rôles principal
est la communication entre l'interface web (Centreon) et notre ordonnanceur (ici Nagios). Ils
sont regroupés au sein de NdOutils.
Ndo2db est un daemon 1 qui permet de récupérer les données remontées par par Ndomod et de
les stocker dans une base de données (notre base MariaDb).
Ndomod est un module qui permet de remonter les informations d'un ou plusieurs ordonnanceur(s) (selon si le modèle choisit est l'architecture simple ou l'architecture distribuée, avec
plusieurs pollers).
Attention seules les données de supervision et l'état de l'ordonnanceur seront remontées, les données de performances et les logs, seront quand à eux récupérés via CentCore, et ramener à la
base de données via CentStorage (qui ne sont pas représentés sur le graphe précédent).
5.3 ... Au diagnostic
5.3.1 La remontée d'informations dans la base de données
Figure 5.3 Base de données Centreon
1. Processus qui s'exécute en arrière-plan
42
5.3.
... AU DIAGNOSTIC
Suite à l'installation de CES, et lors de la conguration de la base de données (voir Annexe
technique) je remarque que celle-ci se décompose en deux sous-bases : Centreon_ status, et Centreon_ storage. Il est conseillé de ne pas renommer ces bases et de laisser les paramètres par
défaut même si les liens symboliques sont correctement établis lors de la conguration. D'ailleurs
en cas de nouvelle installation ou de migration du superviseur il sura de migrer ces deux bases
de données.
La base Centreon_ storage contient les données de performances si le besoin est, d'établir
des graphes de performances par exemple.
Figure 5.4 Centreon status
La base Centreon_ status est celle qui m'intéresse, elle regroupe les dénitions d'hôtes, de
commandes, de services, et surtout les informations de supervisions stockées. 60 tables composent
cette base de données, il m'a fallu un peu de temps pour trouver où étaient stockées précisément
les données recherchées vis-à-vis des plugins utilisés. Il s'avère que les données intéressantes se
trouvent dans trois tables séparées : nagios_ services, nagios_ hosts et nagios_ servicestatus.
Le but était de remonter ces informations en entrant l'adresse IP d'une imprimante, la jointure m'a semblé la plus adaptée. Pour rappel la commande " INNER JOIN" est un type de
jointure commune pour lier des tables entre elles, elle permet de retourner les enregistrements
lorsqu'il y a au moins une ligne de chaque colonne qui correspond à la condition donnée en entrée.
Concrètement dans notre cas si une adresse IP est donnée (10.1.2.14 par exemple)
Listing 5.1 Requête de récupération des données brutes
1
2
3
4
5
s e l e c t output
from n a g i o s _ s e r v i c e s t a t u s
INNER JOIN n a g i o s _ s e r v i c e s
ON ( n a g i o s _ s e r v i c e s t a t u s . s e r v i c e _ o b j e c t _ i d = n a g i o s _ s e r v i c e s . s e r v i c e _ o b j e c t _ i d )
43
5.4.
6
7
8
EN PASSANT PAR LA DÉCOUVERTE RÉSEAU
INNER JOIN n a g i o s _ h o s t s
ON ( n a g i o s _ s e r v i c e s . h o s t _ o b j e c t _ i d = n a g i o s _ h o s t s . h o s t _ o b j e c t _ i d )
where a d d r e s s = ’ 1 0 . 1 . 2 . 1 4 ’
Figure 5.5 Données brutes en sortie
Ces données brutes peuvent à présent être exploitées par mon collègue, une mise en forme sera
à eectuer avant de retranscrire les données au sein de l'interface web.
5.4 En passant par la découverte réseau
Appelé Discover SNMP, le principe est simple, à partir d'une plage d'adresses ip (les sous
réseaux du Conseil Général) le script va lancer un balayage réseau an de déterminer toutes les
imprimantes/multifonctions qui s'y trouvent.
Je ne suis pas l'auteur de ce script, je tiens à remercier Pierre-Louis Corrion qui l'a rédigé, qui
a été un des précurseurs de l'utilisation du protocole SNMP au sein de la DEMS.
En eet ce script couple l'outil NMAP aux OID de descriptions des diérentes marques d'imprimantes et se décompose donc en deux étapes :
1. Scanner les ports avec Nmap an de détecter la présence d'un matériel
2. Si le matériel détecter est une imprimante, interroger l'oid de description an de récupérer
son nom
An d'assurer une certaine cohérence et dans un souci de compréhension, un chier texte
appelé sites.txt (qui regroupe l'ensemble des noms donnés aux sites du Conseil Général, et les ip
correspondantes à ces sites) est requit par le script shell.
Nous avons entrepris d'utiliser ce script comme base d'outil pour eectuer le discover SNMP,
un travail préliminaire a dû être eectué, en associant chaque site (adresse IP) à une variable.
Parallèlement l'interface web devra présenter les diérents sites comme une sorte de ltre par
régions.
Voici un exemple de chier de sortie pou r un discover SNMP eectué à la DEMS :
Listing 5.2 Discover SNMP
1
2
3
4
5
6
10.1.0.0
10.1.0.0
10.1.0.0
10.1.0.0
10.1.0.0
DI
DI
DI
DI
DI
Lan1 ; 1 0 . 1 . 2 . 1 0 ; p r 1 5 6 2 1 0 . i n t r a n e t . cg974 . f r ; HP L a s e r J e t 400 c o l o r M451dw ;
Lan1 ; 1 0 . 1 . 2 . 1 4 ; n p i 1 6 4 2 6 8 . i n t r a n e t . cg974 . f r ; HP L a s e r J e t 400 MFP M425dn ;
Lan1 ; 1 0 . 1 . 2 . 1 5 ; e t 0 0 0 4 0 0 d 1 5 5 7 7 . i n t r a n e t . cg974 . f r ; Lexmark T640 7919 C76 LS
Lan1 ; 1 0 . 1 . 2 . 5 2 ; mfp07678474 . i n t r a n e t . cg974 . f r ; TOSHIBA e−STUDIO356 ;
Lan1 ; 1 0 . 1 . 2 . 7 0 ; km8165d5 . i n t r a n e t . cg974 . f r ;KM−2560;
L'intérêt d'une telle requête est tout simplement de rechercher les imprimantes actives sur un
des sous-réseaux du Conseil Général, placé en paramètre, et également de s'apercevoir si celles-ci
sont correctement nommées ou non. A plus grande échelle on pourrait établir un mapping de ces
imprimantes.
44
5.5.
DU SERVEUR DE DÉVELOPPEMENT AU SERVEUR DE PRODUCTION
5.5 Du serveur de développement au serveur de Production
On appelle serveur de production, le serveur sur lequel sera installé l'application une fois
terminée, donc accessible aux utilisateurs naux. Par opposition, le serveur de développement,
celui sur lequel j'ai eectué mes diérents tests, qui n'était ni plus ni moins que mon poste de
travail personnel. Il faut procéder à la migration de la machine sur Vcenter. Voyons quelques
petites notions avant de procéder :
vSphere est un hyperviseur "bare-metal" c'est-à-dire directement installé sur le serveur physique
qu'il partitionnera en plusieurs machines virtuelles. Sur chaque LAME 2 est installé vSphere. 5
LAME sont présents dans la salle serveur donc 5 vSphere.
VMware vCenter Server est un logiciel de gestion de serveurs et de virtualisation qui ore
une plate-forme centralisée. vCenter regroupe donc la totalité des vSphere au sein d'une même
interface de contrôle et d'administration. Le plus gros avantage est la répartition des charges entre
les vSphere, si un serveur consomme trop de CPU il sera automatiquement basculé sur un autre
vSphere, tout ceci est bien évidemment transparent aux utilisateurs, pour qui les applications
continuent de fonctionner. C'est l'un des principes de la prévention de pannes.
Figure 5.6 Centralisation des serveurs virtuels
La première étape de la migration est la modication de la compatibilité matérielle, rappelons
que le serveur CES était stocké en local sur ma machine personnelle , il fallait donc la migrer
2. serveur physique
45
5.6.
LES DIFFICULTÉS RENCONTRÉES
vers le DataCenter 3 . Le fait d'avoir créé et paramétré cette machine sous Workstation 10 est un
avantage, en eet la migration (upload) est simpliée depuis cette version.
Ne pas oublier de créer un clone de la machine qui possèdera les modications matérielles de
compatibilité, ne surtout pas altérer sa machine existante.
Il faut se rendre ensuite dans la partie upload, et indiquer les informations du serveur sur lequel je
souhaite migrer la machine, une fois que cela est indiqué je peux sélectionner l'emplacement d'hébergement sur le Vcenter, et plus particulièrement un ESX-LUN. L'upload se lance, la migration
s'eectue assez rapidement.
5.6 Les dicultés rencontrées
5.6.1 Protection du réseau
La progression des attaques est en croissance exponentielle sur Internet, peu importe l'échelle
de son entreprise, la protection du réseau est plus que jamais à l'ordre du jour.
Il va de soi qu'avec les services oerts par la DEMS (le serveur de gestion des bourses par
exemple), il faut éviter toutes intrusions ou menaces potentielles , que celles-ci viennent de l'extérieur (DDOS..) ou de l'intérieur (prenons le cas d'une clé usb infectée qui en étant branchée
à un poste de travail, lancerait une contamination et une propagation de malwares sur le réseau).
Des politiques de sécurité ont du être appliquées que cela soit par choix personnel ou par nécessité. Ces règles sont dénies par les administrateurs du SAR et une fois mises en place à appliquer
la tolérance zéro. En eet malgré nos types de comptes sur l'AD (malgré l'OU dans lequel nous
nous trouvons, qui nous attribue un certain nombres de droits sur nos postes par rapport aux
utilisateurs "lambda"), nous devons faire face aux mêmes contraintes que les autres agents du
CG dès lors que l'on touche au réseau.
Je ne peux pas considérer que ces contraintes soient de la sur-protection réseau, elles sont justes.
Vincent Beauval m'a rapporté qu'en eet, il y avait des journées où des centaines d'intrusions
étaient lancées contre le réseau du Conseil Général, j'ai alors pris conscience réellement de la
nécessité d'appliquer ces termes de sécurité.
J'avais commencé à installer mon serveur de supervision sur la même machine virtuelle que Kévin
TAOCHY, en voulant lancer mes premières requêtes, je me suis aperçu que rien ne passait, à
part les requêtes vers Localhost. Rapidement j'ai compris qu'il s'agissait alors d'un problème de
ports UDP qui n'étaient pas ouverts, et comme ce serveur se trouvait sur un réseau isolé, j'ai dû
entreprendre alors l'installation sur ma machine personnelle et d'envisager une migration future
sur un serveur de production (ce qui a été validé et eectué).
Une fois que ma machine a été placée sur le serveur de production, je me suis retrouvé avec
un souci assez particulier, même si la conguration réseau avait été placée sur DHCP, je n'avais
aucune adresse IP, la solution a été de dénir une seconde interface réseau, de la placer en DHCP,
et de forcer le lancement de la conguration au démarrage, il aurait été dommage de perdre la
conguration réseau à chaque reboot serveur (merci à Florent PAYET pour son aide).
De ce fait nous avons dû interagir assez régulièrement avec les membres de SAR dès lors qu'un
problème lié au réseau était soupçonné.
3. Centre de traitement des données où sont regroupés les équipements
46
5.6.
LES DIFFICULTÉS RENCONTRÉES
5.6.2 Respect des conventions de nommage
Si les conventions de nommage ont été établies assez récemment, elles ne sont malheureusement pas respectées.
La première étant le renommage des imprimantes sur le réseau, seule une soixantaine d'imprimantes a été nommée correctement, je me suis concerté avec François BOYER, pour nalement
décider qu'on ne superviserait dans un premier temps que les imprimantes correctement nommées.
De même une communauté SNMP a été dénie par SAR, malheureusement la majorité reste
encore actuellement sur la valeur par défaut à savoir "public", j'ai dû grâce à l'outil Top-Access,
me connecter en session administrateur sur ces périphériques an de changer la communauté par
celle qui était nécessaire pour mes requêtes.
5.6.3 Livrables
Nous avons nommé notre projet DiagMoustik, un petit jeu de mots entre le mot diagnostic
et le petit insecte des tropiques tant détesté.
Les livrables représentent le résultat nal de notre prestation, c'est-à-dire tout ce que nous avons
produit pendant ces 6 mois de stages et qui sera remis entièrement à la DEMS.
5.6.3. A
Architecture générale de l'outil
Regroupons à présent le travail de mon collègue et ce que j'ai produis. Les deux schémas
suivants très explicites ont été réalisé par Kévin TAOCHY, ils illustrent parfaitement la jonction
entre ses travaux et les miens.
Figure 5.7 Architecture de l'application DiagMoustik
47
5.6.
LES DIFFICULTÉS RENCONTRÉES
Figure 5.8 Illustration du principe de fonctionnement
5.6.3. B
Machines virtuelles
Déjà placé sur un serveur en production, la machine virtuelle où est installé le serveur central
CES possède à présent une adresse IP xe, et eectue ses requêtes régulièrement. Le serveur
physique sur lequel elle est placée a largement les ressources nécessaires ainsi que l'espace de
stockage. Cette machine a été fournie avec ses plugins, les paramètres, les hôtes, les diérentes
commandes et services.
La seconde machine virtuelle (celle de mon collègue) été déjà placée sur un sous-réseau (qui
était isolé certes), mais les ports sont à présent ouverts, et les communications avec ma machine
virtuelle ne posent plus aucun problème.
5.6.3. C
Documentations
An de pérenniser l'outil il faut que d'autres que Kévin TAOCHY et moi-même soient capable de l'utiliser lorsque nous serons partis, dans cette optique plusieurs documentations sont
en cours de rédactions. Également des commentaires ont été écris dans les diérents scripts, an
que ceux-ci puissent être modiés au besoin.
Documentation technique, qui reprend l'ensemble des schémas d'architecture ainsi que les
technologies utilisées
Manuel d'utilisation, qui dénit les diérentes vues côté utilisateur (les techniciens) an
que ceux-soient soient parfaitement au courant des fonctionnalités présentes, quels boutons
utiliser pour arriver à tel ou tel résultat...
Procédure d'installation qui détaille pas à pas comment arriver à avoir un serveur stable,
fonctionnel et donc prêt à être déployé
48
Chapitre 6
Conclusion
6.1 Bilan
Ce stage à la DEMS a commencé le 6 janvier 2014 et se terminera le 7 juillet de la même
année (en eet ce rapport sera rendu deux semaines avant la n de mon stage), j'ai été placé
sous la tutelle de François Boyer au sein du Service Support Utilisateurs.
Ce stage de n d'études a été ma première véritable expérience en entreprise, en eet jusqu'à
présent notre cursus universitaire nous avait oert de nombreuses notions dans divers domaines,
que j'ai enn pu mettre en pratique sur le terrain.
Les premiers jours furent assez complexes, le temps de trouver mes marques sans doute, il a fallu
réaménager le bureau de l'assistant de manager de notre chef de service : Laurent Prunella an
de nous attribuer un bureau xe à Kévin TAOCHY et moi-même. Malgré cela, mon intégration
fut très rapide, notamment grâce à Anise FONTAINE et à Marie-Paule CRESCENCE qui se
sont comportées comme de véritables mères pour nous à la DEMS. En l'espace d'une semaine
nous avons visité l'ensemble des services, été présentés aux agents de la DEMS qui étaient présents (une bonne majorité était encore en congé lors de ce début de mois de janvier), et visités
également le Data-Center du Conseil Général.
Une fois intégré, j'ai fait face au quotidien rythmé du SSU, des journées dynamiques avec pleins
d'imprévus, gérées parfaitement par les agents du service, habitués à ce genre de situations.
Nous avons été placés à deux sur ce projet, Kévin TAOCHY et moi-même, j'avais pour ma
part lors de mon entretien mis l'accent sur mes capacités et ma volonté à mettre en pratique
mes notions sur l'administration des systèmes et des réseaux, j'ai donc été ravi lorsque l'on m'a
annoncé que cela serait la partie dont je serais en charge.
J'étais loin de me douter de l'ampleur et surtout de l'échelle de l'architecture que je devais respecter. Pour rappel le Conseil Général est réparti sur environ 150 sites avec près de 5000 agents.
J'avais déjà créé des machines virtuelles (linux pour me parfaire dans les systèmes UNIX) et
Mac-OsX Lion (an de développer des applications pour Ios via Xcode), le projet de mise en
place d'un serveur CES ma permis d'utiliser une autre version de Linux (Centos), diérente de
celle que j'avais l'habitude d'utiliser (Debian).
J'ai appris qu'au sein d'une entreprise on ne peut se permettre de tester une solution dont on
ne connait pas les résultats ni l'ecacité, il faut se baser sur l'existant, et à ce niveau, forts de
leur expérience passée, Vincent BEAUVAL et Florent PAYET ont su me guider. J'ai pu constaté
également que les diérents agents de la DEMS doivent constamment rester à la pointe des technologies qu'ils étudient ou utilisent, forcés dans un monde où l'informatique est en plein essor
d'assurer la qualité de service dont dépend la collectivité.
49
6.2.
APPORT PERSONNEL
Plus qu'un outil, l'informatique fait désormais partie intégrante du quotidien des agents, la
DEMS tend à favoriser son utilisation, an que tous voient le côté ludique et pratique et non une
contrainte.
Concernant le projet en lui-même il a été intéressant de constater que l'intérêt ne venait pas uniquement des techniciens du SSU, mais de toutes les personnes qui nous ont posés des questions
sur l'évolution de ce projet, et qui ont su trouver un côté positif à cette mise en place, je pense
notamment à Chris RAMASSAMY du SRM.
Je n'ai pas à me plaindre des conditions de travail, bien au contraire, en réalité je ne m'attendais
pas à trouver des agents aussi joviaux qui prennent plaisir à travailler et à instaurer une ambiance aussi conviviale, merci à Jean-Pierre JOB et à François BOYER pour leur bonne humeur,
la DEMS est un peu comme une grande famille dont les membres se côtoient et interagissent
chaque jour, et savent qu'ils peuvent compter les uns sur les autres.
Les échanges et partages de connaissances ont favorisé l'entente avec les autres services, une
petite pensée à Jimmy OMERALY, Bertrand CHANE et Maurice REVEL avec qui chaque jour,
un petit débat était lancé concernant les technologies actuelles.
Pour conclure cette partie, je dirais que ce stage a été non seulement une expérience professionnelle, mais également une expérience humanisante.
6.2 Apport personnel
Anticiper les besoins, voilà les maitres-mots que je retiendrais de ce stage. Au fur et à mesure
du cheminement et de l'avancée de ce projet, j'ai commencé à raisonner autrement, étant placé
chef de projet en binôme avec mon collègue, cela a permis de développer notre esprit d'équipe.
Avoir une vision d'ensemble et une prise de recul susante pour aborder une situation concrète,
sont à présent ce que j'estime être non pas des qualités, mais des compétences élémentaires pour
un ingénieur.
Il a été plus qu'enrichissant pour moi de toucher à des technologies et solutions propriétaires,
moi qui étais convaincu que l'open-source remplacerait la plupart des solutions payantes à l'heure
actuelle, je me suis rendu compte que ces logiciels sur mesure facilitaient le travail des administrateurs, surtout en matière de maintenance, en eet une fois mis en place, les débogages sont
très rares, et on peut ainsi se consacrer à la valeur ajoutée et à la qualité de services à apporter.
Ce stage m'a permis de me concilier avec l'idée de devenir administrateur systèmes et réseaux,
la mise en place de serveurs, la gestion de parc informatique, l'établissement de diagnostics, la
mise en oeuvre de sécurité... tant de notions qui permettent de valoriser ce métier à part entière.
Je pense d'ailleurs qu'il serait judicieux que je passe des certications telles que Microsoft, Linux
et Cisco, an d'établir un véritable preuve sur mon niveau et mes aptitudes en plus de mon
bagage technique qui s'est peauné durant mes six mois de stage.
6.3 Perspectives futures
Je pense qu'il faudra compter deux bons mois de test, avec le serveur de supervision et l'application en production, an de s'apercevoir des réels bienfaits de leur mise en place.
Je regrette que nous nous soyons fait rattraper ainsi par le temps, les périodes estimées dans le
planning prévisionnelle étaient plus ou moins correctes, mais les projets secondaires ont été très
50
6.3.
PERSPECTIVES FUTURES
chronophages.
Malheureusement la version web mobile n'a pas pu être abordée, il n'était pas convenu à la base
de développer à la fois une version pour Ios et une version sous Android, mais bien une version
web mobile, basée sur un framework tel que " Jquery mobile" que j'ai déjà eu l'occasion d'utiliser
lors de mon parcours universitaire. Le fait d'utiliser la technologie "responsive design" aurait été
un véritable atout, pour qu'à la fois l'application fonctionne sous postes de travail, smartphones,
voire également les tablettes.
Si les mérites de ce projet sont correctement remontés, il faudra développer cette version.
Autre chose, en prenant un peu de recul vis-à-vis du parc des imprimantes, je me suis rendu
compte que sur le long terme même en mutualisant au maximum les imprimantes pour les remplacer par des multifonctions, il arrivera un moment où le nombre de sites physiques augmentera
considérablement, et il sera alors intéressant d'installer un second serveur poller Nagios, an de
répartir correctement les charges et d'instaurer ainsi une architecture distribuée.
Également si un réel engouement se présente pour le projet, pourquoi ne pas mettre en place
le système de Trap SNMP, an que des alertes soient remontées en cas d'états anormaux ou de
défaillances sur les biens matériels, évidemment il faut se projeter dans l'avenir, cette solution
serait pertinente uniquement si le parc des imprimantes augmenterait de manière signicative,
ne pas oublier la contrainte humaine, si des alertes sont envoyées il faut bien que quelqu'un les
reçoive, serait-il alors judicieux d'associer un agent du SAR, ou plutôt la totalité des techniciens
du SSU ?
51
Table des gures
1.1
1.2
Organigramme du Conseil Général de la Réunion . . . . . . . . . . . . . . . . . .
Organigramme DEMS fonctionnel et nominatif . . . . . . . . . . . . . . . . . . .
10
11
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
C÷ur de réseau du Conseil Général . . . . . . . .
C÷ur de LAN . . . . . . . . . . . . . . . . . . . .
Exemple de che de signalement d'incident . . .
Hétérogénéité du parc d'imprimantes . . . . . .
Gestion de Projet . . . . . . . . . . . . . . . . . .
Graphe systémique de Patrick IRSAPOULLE . .
Planning prévisionnel . . . . . . . . . . . . . . . .
Modèle en Cascade . . . . . . . . . . . . . . . . .
Validation mensuelle de la progression du projet .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
17
19
19
20
21
22
22
22
3.1
3.2
3.3
3.4
3.5
3.6
3.7
Méthode du Polling . . . . . . . . . . . . . . .
Méthode du heartbeat . . . . . . . . . . . . .
Ibm Tivoli Software . . . . . . . . . . . . . .
HP Openview . . . . . . . . . . . . . . . . . .
Computer Associates Technologies Unicenter
HP Openview . . . . . . . . . . . . . . . . . .
Métrologie ou Supervision ? . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
26
27
27
27
27
28
4.1
4.2
4.3
4.4
Schéma SNMP de communication de base
Les échanges entre le Manager et l'Agent .
Structure de l'arborescence d'une MIB . .
Exemple de requête SnmpWalk . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
34
35
38
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
Architecture globale de CES . . . . . . . .
Nagios et ndOutils . . . . . . . . . . . . .
Base de données Centreon . . . . . . . . .
Centreon status . . . . . . . . . . . . . . .
Données brutes en sortie . . . . . . . . . .
Centralisation des serveurs virtuels . . . .
Architecture de l'application DiagMoustik
Illustration du principe de fonctionnement
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
42
42
43
44
45
47
48
A.1 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
B.1
B.2
B.3
B.4
B.5
B.6
57
57
58
58
58
59
Créer une nouvelle machine, sélectionner "avancée" . . . . . . . . . . . . . .
Laisser la compatibilité matériel par défaut . . . . . . . . . . . . . . . . . .
Sélectionner " I will install the operating system later" . . . . . . . . . . .
Congurer le nombre de processeurs : 1 processeur double coeur est susant
Congurer la mémoire vive : 512 Mo sont amplement susant . . . . . . . .
Sélectionner le mode Bridge, an d'avoir une véritable adresse ip à xer . .
52
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
TABLE DES FIGURES
B.7
B.8
B.9
B.10
B.11
B.12
B.13
B.14
B.15
B.16
B.17
B.18
B.19
B.20
B.21
B.22
B.23
B.24
B.25
B.26
B.27
B.28
B.29
B.30
B.31
B.32
B.33
B.34
B.35
B.36
B.37
B.38
B.39
B.40
B.41
B.42
B.43
B.44
B.45
B.46
B.47
B.48
Créer un nouveau disque virtuel . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20 Go sont recommandés pour un CentOs . . . . . . . . . . . . . . . . . . . . . .
Finaliser l'installation, ne pas démarrer la machine . . . . . . . . . . . . . . . . .
Éditer les paramètres de la machine et dans la partie CD/DVD, sélectionner l'iso
de CES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lancer une nouvelle installation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Première interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sélectionner la langue et le clavier du système . . . . . . . . . . . . . . . . . . . .
Sélectionner périphériques de stockage basiques . . . . . . . . . . . . . . . . . . .
Abandonner les données, an de procéder au partitionnement automatique . . . .
Sélectionner le fuseau horaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remplacer le système actuel (même si aucun n'est présent) . . . . . . . . . . . .
Installer un serveur central avec base de données . . . . . . . . . . . . . . . . . .
Choisir le duo Nagios/ndOutils . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L'installation des dépendances commence . . . . . . . . . . . . . . . . . . . . . .
L'installation est enn terminée . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Redémarrer la machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CES est bien basé sur CentOs 6.5 . . . . . . . . . . . . . . . . . . . . . . . . . . .
Une fois connecté à la session, repérer l'adresse ip . . . . . . . . . . . . . . . . . .
Le paramétrage se poursuit dans un navigateur web (taper l'adresse ip dans la
barre d'url) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Les diérents modules se chargent . . . . . . . . . . . . . . . . . . . . . . . . . .
Sélectionner Nagios comme serveur central . . . . . . . . . . . . . . . . . . . . . .
Laisser les répertories par défaut . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vérier que ndOutils est le Broker sélectionné . . . . . . . . . . . . . . . . . . . .
Dénir ses paramètres d'administration . . . . . . . . . . . . . . . . . . . . . . .
Dénir les informations de la base de données . . . . . . . . . . . . . . . . . . . .
Vérication des paramètres entrés . . . . . . . . . . . . . . . . . . . . . . . . . . .
On peut à présent se connecter à Centreon . . . . . . . . . . . . . . . . . . . . . .
Modication d'un hôte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Les diérents groupes d'hôtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple de commande s'appuyant sur un plugin . . . . . . . . . . . . . . . . . .
Modication d'un service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Relation entre un service et un groupe d'hôtes . . . . . . . . . . . . . . . . . . . .
Modication de la compatibilité hardware . . . . . . . . . . . . . . . . . . . . . .
Clone de la machine avec modications . . . . . . . . . . . . . . . . . . . . . . . .
Sélection d'un emplacement sur le DataCenter . . . . . . . . . . . . . . . . . . . .
Sélection d'un ESX-LUN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interface générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagnostic imprimante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagnostic poste de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lancement d'une commande de controle à distance . . . . . . . . . . . . . . . . .
Discover SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Résultat d'un discover à la DEMS . . . . . . . . . . . . . . . . . . . . . . . . . .
53
59
59
60
61
61
61
62
62
62
63
63
63
64
64
64
65
65
65
66
66
66
66
67
67
67
67
67
68
68
68
69
69
69
70
70
70
71
71
72
72
73
73
Annexe A
Webographie
Developpez.com http://caleca.developpez.com/tutoriels/protocole-snmp/
WIKI MONITORING-FR.ORG http://wiki.monitoring-fr.org/zabbix/zabbix-snmp-host
SUGAR.BUG http://eric.coquard.free.fr/atelier/supervision/reseau/supervision_
snmp.html
LoriotPro http://www.loriotpro.com/ServiceAndSupport/How_to/InstallWXPAgent_FR.
php
OCS inventory-ng http://forums.ocsinventory-ng.org
php http://www.php.net/manual/en/function.snmp2-walk.php
Decrypt http://decrypt.ysance.com/
slideshare http://fr.slideshare.net/labynocle/
infoscience http://infoscience.epfl.ch/record/49953/files/Rei02.pdf
debian https://www.debian.org/releases/wheezy/
MEMO-LINUX.COM http://memo-linux.com/
Centreon http://www.centreon.com/Content-products/centreon-entreprise-server
nicolargo http://blog.nicolargo.com/2009/02/utilisation-de-centreon.html
Journal d'un Admin Linux http://journaldunadminlinux.fr/installer-et-configurer-centreon
WEBLOG de CEDRIC TEMPLE http://blog.cedrictemple.net/
ZIONETRIX http://wiki.zionetrix.net/informatique:systeme:monitoring:nagios
linuxpedia.fr http://www.linuxpedia.fr/doku.php/serveurs/nagios_centreon
Nagios Exchange http://exchange.nagios.org/directory/Addons/Database-Backends/NDOUtils/
details
54
PC SOFT http://doc.pcsoft.fr/fr-FR/?2034007
smnet.fr http://www.smnet.fr/ocsglpi/ocs-snmp.html
easeo http://blog.easeo.fr/aides-howto/
HARDWARE.FR http://forum.hardware.fr/hfr/systemereseauxpro/Logiciels-entreprise/
nagios-imprimantes-reseau-sujet_1612_1.html
HACKERS ARE US http://blog.hackersare.us/2011/06/checkhpjdnew-nagios-plugin.
html
ouieuhtoutca.org http://wiki.ouieuhtoutca.org/doku.php?id=nagios-centreon-part1
MG Monitoring http://www.mark-gadi.fr/supervision/
LinuxQuestions.org http://www.linuxquestions.org/questions/linux-networking-3/snmp-snmpwa
doc.monitoring-fr http://doc.monitoring-fr.org/3_0/html/gettingstarted-monitoring-routers.
html
yyovkov http://mwiki.yyovkov.net/index.php/SNMPHelp:SNMP_Mibs_for_%28HP%29_Printers
L'Internet Rapide et Permanent http://irp.nain-t.net/doku.php/215snmp:40_les_mibs
Blog de Victor Héry http://blog.héry.com/article9/
Blog Olivier Delort http://blog.olivierdelort.net/?p=270
ubuntu-fr http://doc.ubuntu-fr.org/installer_un_serveur_debian
StackExchange http://security.stackexchange.com/questions/36198/
Linux-France http://www.linux-france.org/article/gvallee/snmp/snmp.html#ref7
FrameIp http://www.frameip.com/snmp/
mibDepot http://www.mibdepot.com
55
A.1.
TABLEAU DE BORD
A.1 Tableau de Bord
Figure A.1 Diagramme de Gantt
56
Annexe B
Annexes techniques
B.1 Création d'une machine virtuelle
Figure B.1 Créer une nouvelle machine, sélectionner "avancée"
Figure B.2 Laisser la compatibilité matériel par défaut
57
B.1.
CRÉATION D'UNE MACHINE VIRTUELLE
Figure B.3 Sélectionner " I will install the operating system later"
Figure B.4 Congurer le nombre de processeurs : 1 processeur double coeur est susant
Figure B.5 Congurer la mémoire vive : 512 Mo sont amplement susant
58
B.1.
CRÉATION D'UNE MACHINE VIRTUELLE
Figure B.6 Sélectionner le mode Bridge, an d'avoir une véritable adresse ip à xer
Figure B.7 Créer un nouveau disque virtuel
Figure B.8 20 Go sont recommandés pour un CentOs
59
B.1.
CRÉATION D'UNE MACHINE VIRTUELLE
Figure B.9 Finaliser l'installation, ne pas démarrer la machine
60
B.2.
INSTALLATION DE CES
B.2 Installation de CES
Figure B.10 Éditer les paramètres de la machine et dans la partie CD/DVD, sélectionner l'iso
de CES
Figure B.11 Lancer une nouvelle installation
Figure B.12 Première interface
61
B.2.
INSTALLATION DE CES
Figure B.13 Sélectionner la langue et le clavier du système
Figure B.14 Sélectionner périphériques de stockage basiques
Figure B.15 Abandonner les données, an de procéder au partitionnement automatique
62
B.2.
INSTALLATION DE CES
Figure B.16 Sélectionner le fuseau horaire
Figure B.17 Remplacer le système actuel (même si aucun n'est présent)
Figure B.18 Installer un serveur central avec base de données
63
B.2.
INSTALLATION DE CES
Figure B.19 Choisir le duo Nagios/ndOutils
Figure B.20 L'installation des dépendances commence
Figure B.21 L'installation est enn terminée
64
B.2.
INSTALLATION DE CES
Figure B.22 Redémarrer la machine
Figure B.23 CES est bien basé sur CentOs 6.5
Figure B.24 Une fois connecté à la session, repérer l'adresse ip
65
B.3.
SUITE DE L'INSTALLATION DE CES VIA NAVIGATEUR WEB
B.3 Suite de l'installation de CES via navigateur Web
Figure B.25 Le paramétrage se poursuit dans un navigateur web (taper l'adresse ip dans la
barre d'url)
Figure B.26 Les diérents modules se chargent
Figure B.27 Sélectionner Nagios comme serveur central
Figure B.28 Laisser les répertories par défaut
66
B.3.
SUITE DE L'INSTALLATION DE CES VIA NAVIGATEUR WEB
Figure B.29 Vérier que ndOutils est le Broker sélectionné
Figure B.30 Dénir ses paramètres d'administration
Figure B.31 Dénir les informations de la base de données
Figure B.32 Vérication des paramètres entrés
Figure B.33 On peut à présent se connecter à Centreon
67
B.4.
LES DIFFÉRENTS ÉLÉMENTS DE CENTREON
B.4 Les diérents éléments de Centreon
Figure B.34 Modication d'un hôte
Figure B.35 Les diérents groupes d'hôtes
Figure B.36 Exemple de commande s'appuyant sur un plugin
68
B.5.
MIGRATION DE LA MACHINE VIRTUELLE
Figure B.37 Modication d'un service
Figure B.38 Relation entre un service et un groupe d'hôtes
B.5 Migration de la machine virtuelle
Figure B.39 Modication de la compatibilité hardware
69
B.6.
V1 DE L'INTERFACE WEB DE NOTRE APPLICATION
Figure B.40 Clone de la machine avec modications
Figure B.41 Sélection d'un emplacement sur le DataCenter
Figure B.42 Sélection d'un ESX-LUN
B.6 V1 de l'interface Web de notre application
70
B.6.
V1 DE L'INTERFACE WEB DE NOTRE APPLICATION
Figure B.43 Interface générale
Figure B.44 Diagnostic imprimante
71
B.6.
V1 DE L'INTERFACE WEB DE NOTRE APPLICATION
Figure B.45 Diagnostic poste de travail
Figure B.46 Lancement d'une commande de controle à distance
72
B.6.
V1 DE L'INTERFACE WEB DE NOTRE APPLICATION
Figure B.47 Discover SNMP
Figure B.48 Résultat d'un discover à la DEMS
73