Gestion des configurations d'un datacenter basée sur Puppet et Foreman

Septembre 2016

ECOLE SUPERIEURE D'INFORMATIQUE SALAMA
République Démocratique du Congo
Province du Haut-Katanga
Lubumbashi
www.esisalama.org

GESTION DES CONFIGURATIONS D'UN DATACENTER BASEE SUR PUPPET ET FOREMAN

« Cas de Katanga Networking Academy (KANACAD) »

Travail présenté et défendu en vue de l'obtention du grade d'ingénieur en réseaux

Par MUKEYA KIONGO Israël

Option : Administration systèmes et réseaux

Septembre 2016

ECOLE SUPERIEURE D'INFORMATIQUE SALAMA
République Démocratique du Congo
Province du Haut-Katanga
Lubumbashi
www.esisalama.org

GESTION DES CONFIGURATIONS D'UN DATACENTER BASEE SUR PUPPET ET FOREMAN

« Cas de Katanga Networking Academy (KANACAD) »

Travail présenté et défendu en vue de l'obtention du grade d'ingénieur en réseaux

Par MUKEYA KIONGO Israël

Option : Administration systèmes et réseaux Directeur : Bertin POLOMBWE Co-directeur : Michée KALONDA

EPIGRAPHE

« En gestion, ce que l'on contrôle à outrance nous contrôle et ce que nous ne gérons pas nous gère ».

Sylvain Tourangeau

II

DEDICACE

A notre père MUKEYA TSHIBANGU Joseph, qui a fait preuve d'un parent responsable, se débattant çà et là pour que l'Ecole Supérieure d'Informatique Salama ne soit pas pour nous une aventure.

A notre mère MBAYO KIONGO ILUNGA Germaine, pour tant d'exonération et dont l'attention soutenue ainsi que les conseils ont marqués notre itinéraire, qui au-jourd'hui se révèle être le fruit d'une éducation distinguée. Vous êtes pour nous le modèle parfait d'une bonne mère.

MUKEYA KIONGO Israël

III

REMERCIEMENTS

Ce travail de fin d'études supérieures, résultat de longue haleine, de la patience soutenue, fruit des connaissances acquises, n'est pas l'affaire d'une seule personne.

Par ce biais, nous exprimons notre profonde gratitude à l'égard de notre Dieu, qui n'a pas cessé de nous donner le souffle de vie durant toute la période de notre formation jusqu'à ce jour où nous avons le privilège de présenter ce travail.

Nous remercions notre directeur et codirecteur, monsieur Bertin POLOMBWE et monsieur Michée KALONDA, qui malgré leurs multiples occupations, ont toujours su prendre soin de nous et nous montrer le chemin à suivre.

Nos remerciements s'adressent une fois de plus à toute les autorités académiques de l'Ecole Supérieure d'Informatique Salama et plus particulièrement à notre coordonnateur de filière, le master Patient KASONGO pour l'esprit de recherche inculqué en nous.

Nous disons merci à nos très chers parents ainsi qu'à nos frères et soeurs : Joseph MUKEYA et Germaine MBAYO KIONGO, Simon Pierre et Claudia MUZAZA, Trésor et Péguy MAKANDA, Patrick MUKEYA, Dan MUKEYA et Nathan MUKEYA pour toutes les dimensions des soutiens manifestées en notre faveur.

Nous remercions également nos grand parents, oncles et tantes : Baudouin et Céline MBAYO, Jeannette et Mike KYONY, Gisèle et Louis LOSHITA, Michel et Yolande MBAYO, Jerry et Promesse MBAYO pour leur assistance dans toutes les situations.

Nous remercions vivement Deborah KABILA, Lauraine KISULA, David MUYUMBA, Léon BITULU et Franck ZALI, grâce à leur soutien, amour et encouragements durant notre parcours, nous avons pu nous accomplir pleinement dans nos études.

Nos remerciements s'adressent également à toute l'équipe d'intercession de la Jeunesse Bonne Semence : frère Alain, soeur Clarisse, papa Désiré, frère Aubin, frère Cédron, frères Yannick et Patrick KISULA, frères Mike et Durck pour tous les moments intenses de prières et de partage sans oublié leur soutien.

Nous remercions vivement de tout coeur les ingénieurs : Derick KHON, Luc KA-NIKI, Sam MWIMBI, Ferdos KAHENGA, Herbert KALONJI et Christopher BAHUKA.

Du reste nous remercions nos amis et compagnons de lutte avec qui nous avons passé des moments forts d'études : Elie KABUNDA, Joël KAZADI, Chris KAHOZI, Chris MWEMBO, Ray's BUKASA, Job KAVU, Baudouin BBK, Mira MBU, Yves MU-LOLWA, Samuel NUMBI, Jenny Gracia, Gloria KASH, LUNA, Dan MUKOKA, Julie MULASI, Cyrille MPINGO, Yan NGUSU, Monique MPWETO et Marianne KARUMB.

Et pour clore cette page nous adressons nos remerciements à tous ceux, qui de près ou de loin ont contribué d'une manière ou d'une autre à l'élaboration de ce travail et qui n'ont pas vu leurs noms mentionnés ici, nous vous en supplions de ne pas nous en tenir rigueur, nous vous portons à coeur.

IV

LISTE DES FIGURES

Figure 1.1 structure des académies Cisco 6

Figure 1.2 architecture générale de Katanga Networking Academy 8

Figure 2.1 niveaux d'abstraction appliqués à la conception [13, p. 6] 26

Figure 2.2 architecture générale du futur système 29

Figure 2.3 interaction entre un client et le serveur DNS 32

Figure 2.4 processus d'acquisition d'une adresse IP via le serveur DHCP 33

Figure 2.5 processus de signature du certificat d'un client 35

Figure 2.6 interaction entre le gestionnaire des configurations et les clients 36

Figure 2.7 processus de gestion des configurations 37

Figure 3.1 niveau d'abstraction de la conception technique 26

Figure 3.2 diagramme en bâtons 41

Figure 3.3 diagramme en courbes 41

Figure 3.4 principe d'utilisation de puppet 42

Figure 3.5 fonctions principales de puppet 43

Figure 3.6 fonctionnement de Foreman avec Puppet 46

Figure 3.7 architecture générale du système au niveau physique 47

Figure 3.8 fixation de l'adresse IP du serveur 49

Figure 3.9 configuration du fichier hosts du serveur 50

Figure 3.10 configuration du fichier hostname du serveur 50

Figure 3.11 configuration du fichier puppet.conf du serveur 50

Figure 3.12 création du domaine 51

Figure 3.13 création du proxy intelligent 51

Figure 3.14 fixation de l'adresse IP du client Ubuntu 51

Figure 3.15 configuration du fichier hosts du client Ubuntu 52

Figure 3.16 configuration du fichier hostname du client Ubuntu 52

Figure 3.17 configuration du fichier puppet.conf du client Ubuntu 52

Figure 3.18 fixation de l'adresse IP du client CentOS 53

Figure 3.19 configuration du fichier hosts du client CentOS 53

Figure 3.20 configuration du fichier network du client CentOS 53

Figure 3.21 configuration du fichier puppet.conf du client CentOS 54

Figure 3.22 résultat attendu après test de l'hostname 54

Figure 3.23 configuration du fichier init.pp du module MySQL 55

Figure 3.24 configurations du fichier install.pp du module MySQL 55

Figure 3.25 configuration du fichier config.pp du module MySQL 56

Figure 3.26 configuration du fichier service.pp du module MySQL 56

V

VI

Figure 3.27 configuration du fichier site.pp du module MySQL 56

Figure 3.28 configuration du fichier node.pp du module MySQL 56

Figure 3.29 configurations du fichier init.pp du module DHCP 57

Figure 3.30 configuration du fichier install.pp du module DHCP 57

Figure 3.31 configuration du fichier config.pp du module DHCP 57

Figure 3.32 configuration du fichier service du module DHCP 58

Figure 3.33 configuration du fichier node.pp du module DHCP 58

Figure 3.34 configuration du fichier node.pp du module DHCP 58

Figure 3.35 configuration du fichier init.pp du module Apache 59

Figure 3.36 configuration du fichier install.pp du module Apache 59

Figure 3.37 configuration du fichier service.pp du module Apache 59

Figure 3.38 configuration du fichier site.pp du module Apache 59

Figure 3.39 configuration du fichier nodee.pp du module Apache 60

Figure 3.40 importation des classes puppet 60

Figure 3.41 résultat du test de connectivité avec le serveur 61

Figure 3.42 extrait du diagramme de GANTT pour la planification de l'implémentation

65

Figure 4.1 test d'installation de puppet et foreman 67

Figure 4.2 résultat du test après exécution de foreman-installer 67

Figure 4.3 résultat du test des paramètres IP du serveur 68

Figure 4.4 résultat du test de vérification de l'hostname du serveur 68

Figure 4.5 connexion à l'interface web de foreman 68

Figure 4.6 interface d'accueil de foreman 69

Figure 4.7 informations du proxy intelligent 69

Figure 4.8 résultat après création du proxy intelligent 70

Figure 4.9 création du domaine kanacad.org 70

Figure 4.10 importation des classes 70

Figure 4.11 mise à jour des classes puppet 71

Figure 4.12 tableau des classes importées depuis puppet 72

Figure 4.13 résultat du test de configurations des paramètres IP du client kan-node1 73

Figure 4.14 résultat du test de vérification de l'hostname du client kan-node1 73

Figure 4.15 résultat de test de configuration des paramètres IP du client kan-node2 73

Figure 4.16 résultat du test de l'hostname du client kan-node2 74

Figure 4.17 résultat du test de connectivité entre le client kan-node1 et le serveur 74

Figure 4.18 résultat du test de connectivité entre le client kan-node2 et le serveur 74

Figure 4.19 création du certificat sur le client kan-node1 75

Figure 4.20 création du certificat sur le client kan-node2 75

Figure 4.21 liste des certificats en attente de signature sur le serveur 75

Figure 4.22 procédure de signature des certificats 76

Figure 4.23 signature de certificat du client kan-node1 76

Figure 4.24 signature de certificat du client kan-node2 76

Figure 4.25 inclusion des classes dhcp et dhcp :: service 77

Figure 4.26 inclusion des classes du module Apache 77

Figure 4.27 résultat du test de synchronisation du serveur kan-srvlub-foreman 77

Figure 4.28 modification du fichier init.pp du module dhcp 78

Figure 4.29 résultat du test de synchronisation du client kan-node1 78

Figure 4.30 résultat du test de synchronisation du client kan-node2 78

Figure 4.31 résultat de test pour la visualisation des noeuds gérés 79

Figure 4.32 résultat du test pour la visualisation du tableau de bord 80

Figure 4.33 résultat du test de visualisation du rapport global 81

Figure 4.34 résultat du test de visualisation du rapport d'un noeud 82

Figure 4.35 résultat du test de monitoring d'un hôte 83

Figure 4.36 résultat du test de visualisation des statistiques 84

Figure 4.37 résultat du test de visualisation de l'audit sur l'ensemble du système 85

Figure 4.38 résultat du test de visualisation de l'audit sur un noeud 86

Figure 4.39 graphique d'évaluation des besoins fonctionnels 89

Figure 4.40 graphique d'évaluation des besoins non fonctionnels 89

VII

LISTE DES TABLEAUX

Tableau 1.1 plan d'adressage 9

Tableau 1.2 plan de nommage 9

Tableau 1.3 supports de transmission utilisés dans le LAN 10

Tableau 1.4 inventaire des équipements 14

Tableau 3.1 cotations des gestionnaires des configurations 40

Tableau 4.1 évaluation des besoins fonctionnels 87

Tableau 4.2 évaluation des besoins non fonctionnels 88

VIII

TABLE DES MATIERES

EPIGRAPHE I

DEDICACE II

REMERCIEMENTS III

LISTE DES FIGURES IV

LISTE DES TABLEAUX VII

TABLE DES MATIERES VIII

AVANT-PROPOS X

CHAPITRE 0: INTRODUCTION GENERALE 1

0.1. Problématique 1

0.2. Hypothèse 1

0.3. Choix et intérêt du sujet 2

0.4. Méthodologie 2

0.5. Etat de l'art 3

0.6. Délimitation du travail 4

0.7. Subdivision du travail 4

0.8. Outils logiciels et équipements utilisés 4

CHAPITRE 1: SPECIFICATIONS FONCTIONNELLES DU FUTUR

SYSTEME 5

1.1. Introduction 5

1.2. Présentation de l'association 5

1.3. Etude de l'existant 7

1.4. Spécification des besoins 22

1.5. Conclusion partielle 24

CHAPITRE 2: CONCEPTION GENERALE ET DETAILLEE LOGIQUE 25

2.1. Introduction 25

2.2. Conception générale 26

2.3. Conception détaillée logique 30

2.4. Conclusion partielle 38

CHAPITRE 3: CONCEPTION TECHNIQUE 26

3.1. Introduction 26

3.2. Choix technologiques 26

IX

3.3. Procédures et planification 47

3.4. Conclusion Partielle 66

CHAPITRE 4: IMPLEMENTATION 66

4.1. Introduction 66

4.2. Installation et configuration 66

4.3. Tests et résultats 74

4.4. Conclusion partielle 87

CONCLUSION GENERALE 90

Perspectives d'avenir 90

REFERENCES 92

X

AVANT-PROPOS

L'Ecole Supérieure d'Informatique Salama régie par le programme national des institutions supérieures techniques, prévoit des défenses des travaux ou projets à la fin des cursus académiques des ingénieurs techniciens en informatique, c'est dans cet ordre d'idée que s'inscrit ce travail de fin d'études en administration systèmes et réseaux intitulé « GESTION DES CONFIGURATIONS D'UN DATACENTER BASEE SUR PUPPET ET FOREMAN ».

L'automatisation des tâches d'administration a toujours été une des préoccupations majeures des administrateurs systèmes, en plus de permettre un gain de temps, la reproductibilité du processus de déploiement et une garantie du résultat.

Avec l'arrivée de la virtualisation et l'augmentation des services proposés aux utilisateurs, les parcs des serveurs sont en forte expansion. Pour répondre à l'accroisse-ment du nombre des plates-formes gérées, des nouveaux outils d'administration sont apparus. Les logiciels de gestion des configurations et de déploiement automatisé sont maintenant une alternative aux installations manuelles ou réalisées à l'aide de scripts faits maisons.

Dans ce travail, nous faisons la conception d'un système de gestion des configurations du parc des serveurs de Katanga Networking Academy en partant des spécifications fonctionnelles du futur système, de la conception logique générale et détaillée du système, du choix des différentes solutions technologiques et de la planification jusqu'à la mise en place du dit système, composé de Puppet comme gestionnaire des configurations et de Foreman comme gestionnaire de cycle de vie des serveurs.

La compréhension de ce travail exige la lecture globale de tous les quatre chapitres étant donné que la fin ou la sortie de chaque chapitre constitue une entrée du prochain chapitre, chaque cause placée dans le travail produit un effet dans le système.

TFE_ESIS_AS 2016

CHAPITRE 0: INTRODUCTION GENERALE

0.1. Problématique

L'augmentation du nombre d'étudiants, d'équipements IP et des services (messagerie, web, stockage, etc..) au sein des académies de formation de Katanga Networking Academy conduit à la croissance de la taille de son centre de données, ce qui fait que plus le réseau grandit, plus la gestion des configurations des composants de ce dernier devient difficile. Ceci dit, nous nous sommes posé deux questions en vue de pallier à ce problème :

1. Les taches de configuration étant pénibles pour les administrateurs systèmes devant intervenir sur différents serveurs du centre de données, que faire pour permettre une configuration aisée de ces serveurs afin de réduire le nombre d'erreurs ainsi que celui des tâches répétitives ?

2. Comment arriver à gérer le cycle de vie des différents serveurs du centre de données tout en ayant une vue globale sur ces derniers ?

0.2. Hypothèse

L'hypothèse est une réponse provisoire aux questions posées dans la problématique. Eu égard aux problèmes posés ci-haut, voici ce que nous proposons et optons comme solutions provisoires :

1. Nous mettrions en place un outil qui nous permettra de centraliser les configurations des systèmes, ce qui nous permettra :

? D'automatiser l'administration ainsi que de diminuer le nombre d'erreur ;

? D'harmoniser et homogénéiser les configurations pour gagner du temps, de la flexibilité ainsi que les performances ;

? D'appliquer les nouvelles configurations au fil du temps ;

? De s'assurer de manière régulière que les configurations des différents noeuds correspondent bien à la configuration voulue.

2. Nous mettrions en place un outil qui nous permettra de gérer le cycle de vie des serveurs tout en générant des rapports, statistiques, audits ainsi qu'effectuer des tâches d'administration plus complexes et faire du monitoring de tous ces serveurs.

TFE_ESIS_AS 2016

2

INTRODUCTION GENERALE

0.3. Choix et intérêt du sujet

L'administration système et réseau est une discipline en pleine croissance, responsable de la gestion des parcs informatiques, de la maintenance logicielle et matérielle, de la mise en place, du déploiement des systèmes et des configurations. Étant étudiant dans ce domaine, à la fin de notre cycle, nous devons proposer des solutions d'administration aux organisations, partant de connaissances acquises tout au long de notre cursus académique, l'intérêt que nous portons à ce sujet est subdivisé en trois points, à savoir :

? L'intérêt personnel

Etant étudiant chercheur, nous nous sentons attiré de manière consciente sur ce sujet et nous aimerions travailler dessus pour approfondir nos connaissances ;

? L'intérêt scientifique

Ce travail n'est pas fait uniquement pour l'obtention du diplôme d'ingénieur technicien en administration systèmes et réseaux mais il se veut plutôt être une référence sûre, fiable et satisfaisante pour les chercheurs qui viendront après nous ;

? L'intérêt social

Après avoir constaté une nécessité continuelle en matière de gestion des configurations dans le centre de données de Katanga Networking Academy, croissant en étendue et en nombre d'équipements réseaux, ce présent travail permettra de réduire le temps de travail des administrateurs, ce qui leur permettra de consacrer le temps restant vers d'autres tâches.

0.4. Méthodologie 0.4.1. Méthodes

Une méthode est une démarche organisée et rationnelle de l'esprit pour arriver à un certain résultat.

Pour permettre de garder le contrôle sur la suite de notre travail, nous avons utilisé les méthodes suivantes :

? Top down design

Méthode procédant par décomposition du problème, ce dernier ainsi divisé en un certain nombre des sous problèmes, chacun de complexité moindre. Cette division est ensuite appliquée aux sous problèmes générés, et ainsi de suite, jusqu'à ce que la résolution de chacun des sous problèmes soit triviale ;

TFE_ESIS_AS 2016

3

INTRODUCTION GENERALE

? L'implémentation

Méthode fondée sur l'expérience scientifique et sur l'expérimentation, elle nous a permis d'implémenter la solution, de vérifier et de tester l'hypo-thèse ;

? L'interprétation

Méthode fondée sur l'interprétation des résultats obtenus lors des différents tests ;

? Traitement des résultats

Méthode basée sur les interprétations des résultats obtenus lors de tests, si ces derniers ne correspondent pas, chercher des solutions à mettre en place pour qu'ils correspondent à nos attentes.

0.4.2. Techniques

? La documentation

Technique se basant sur l'ensemble des documents relatifs à une question, elle nous a permis d'utiliser des livres, des sites internet, des rapports ainsi que des revues, ces derniers nous ont permis d'avoir de données relatives au sujet sur lequel nous travaillons.

? L'interview

Elle nous a permis d'avoir des échanges avec quelques personnes susceptibles de nous apporter plus d'éclaircissement dans le domaine qui concerne notre sujet, entre autre : les ainés scientifiques, les administrateurs systèmes de Katanga Networking Academy et ceux utilisant nos solutions sous d'autres cieux.

0.5. Etat de l'art

La science évolue du jour au lendemain, toutes les nouvelles technologies font objets d'études dans le milieu scientifique, nous ne prétendons pas en un seul instant être le premier à traiter ce sujet et moins encore le dernier à travailler dessus. Quelques personnes ont abordé des sujets similaires au nôtre, c'est le cas de :

Ingénieur Christopher BAHUKA LENGE dans « Etude et mise en oeuvre d'une administration système automatisée et centralisée autour d'un gestionnaire de configuration », 2010-2011.[1, p. 4]

Dans son travail il était question d'implémenter un gestionnaire des configurations en vue de déployer en masse les configurations sur les serveurs DNS LINUX dans les environnements de production de l'office congolais de contrôle (OCC).

Ce présent travail se démarque de celui de l'ingénieur Christopher BAHUKA dans ce sens que lui, en plus de se baser sur un gestionnaire des configurations, il implémente

TFE_ESIS_AS 2016

4

INTRODUCTION GENERALE

un outil faisant office d'une interface web pour le gestionnaire des configurations et qui, en même temps nous permet d'effectuer des tâches d'administration compliquées et avoir une vue globale sur tout le parc de nos serveurs.

0.6. Délimitation du travail

Dans le temps, il sied de noter que ce travail couvre la période allant du mois d'octobre 2015 au mois de septembre 2016.

Dans l'espace, ce travail se focalise sur Katanga Networking Academy comme cas d'application et se limite aux seules réalités de cette dernière dont 99% des serveurs tournent sur Linux.

Nous nous sommes limités au déploiement en masse des configurations sur les serveurs et gérer le cycle de vie de ces derniers (approvisionnement, monitoring, visualisation des noeuds et la génération des rapports, audits, statistiques pour toute l'infrastruc-ture).

0.7. Subdivision du travail

Mise à part l'introduction et la conclusion générale, notre travail s'articule sur quatre chapitres, qui sont :

1. Le chapitre premier qui traite des spécifications fonctionnelles du futur système que nous aurons à mettre en place. Dans ce chapitre nous aurons à faire la description de notre cas d'application, critiquer l'existant et enfin y ressortir les besoins fonctionnels et non fonctionnels du futur système.

2. Le chapitre deuxième traite de la conception logique du futur système, c'est-à-dire la conception générale et détaillée logique du système à partir des besoins recueillis dans la première partie, nous allons résoudre le problème logiquement.

3. Le chapitre troisième quant à lui s'occupe de la conception technique du système, c'est-à-dire des choix technologiques, des procédures d'installation, de configuration, de test ainsi que de la planification de l'implémentation. Après avoir eu une solution logique, nous allons l'orienté dans les solutions technologiques.

4. Le chapitre quatrième se focalise sur l'implémentation de la solution, Il est question d'appliquer toutes les procédures prévues et montrer les résultats émanant de ces dernières.

0.8. Outils logiciels et équipements utilisés

Dans l'élaboration de ce travail, nous avons pu recourir à beaucoup d'outils logiciels qui ont donné forme à ce dernier, c'est le cas de :

? Puppet Master version 3.8.7; ? Puppet agent version 3.4.3;

TFE_ESIS_AS 2016

5

INTRODUCTION GENERALE

? Foreman version1.10;

? VMware 12 Pro;

? Ubuntu 14.04 LTS;

? Microsoft Project 2013;

? CentOS 6.6.

TFE_ESIS_AS 2016

CHAPITRE 1: SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

1.1. Introduction

Afin de bien poursuivre notre travail et être sûr de mettre en place une solution qui répond aux besoins en matière de gestion des configurations, il nous est indispensable d'étudier l'existant de façon générale.

Ce chapitre traite de la description de l'infrastructure réseau du centre de données de Katanga Networking Academy sur ses différents aspects et des spécifications des besoins fonctionnels et non fonctionnels de ce dernier. C'est ainsi qu'à la fin de cette première partie du travail, nous aurons une vue assez générale sur toute l'infrastructure et nous aurons réuni les différents besoins qui nous serviront d'entrée dans la seconde partie de ce travail.

1.2. Présentation de l'association

Fondé en 1984 par Leonard Bosack et Sandra Lerner, Cisco qui tire son nom de la ville de San Francisco aux Etats-Unis, est une entreprise informatique qui oeuvre dans le domaine de l'interconnexion des réseaux de données et dans lequel il est leader du marché.

Dans le souci de réduire la fracture numérique entre le nord et le sud, l'entreprise Cisco a mis sur pied un programme (Cisco networking Academy) pour aider les organismes de formation et éducation à produire des étudiants plus compétents. Ce programme fournit aux étudiants les connaissances pratiques, techniques et technologiques de base sur les systèmes réseaux et des certifications industrielles.

KANACAD pour Katanga Networking Academy est une association sans but lucratif qui dispense le programme Cisco networking Academy, permettant de se préparer à une carrière dans les technologies de l'information principalement les réseaux du siècle présent et qui se fixe les objectifs ci-après [2]:

? La vulgarisation des nouvelles technologies de l'information et de communication via les concepteurs des technologies et cela de manière officielle, c'est le cas de CISCO, Microsoft, etc. ;

? Réduire la fracture numérique entre les coins et les recoins de la province du Haut Katanga en particulier et de la République Démocratique du Congo en général ;

? Contribuer au développement des communautés par l'accès aux nouvelles technologies de l'information et de communication ;

6

SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

? Acquérir, par la formation, les divers outils de communication en renforçant l'autonomie des populations locales et leur participation responsable à travers une économie interconnectée à différentes échelles et à tout niveau, comme par exemple la capacité de générer des technologies ou encore, celle de rechercher et générer des fonds ;

? Renforcer les connaissances et les compétences des communautés de base

par les technologies Cisco, Microsoft, Linux, Oracle, etc. ;

1.2.1. Situation géographique

Katanga Networking Academy est basée à Lubumbashi dans la province du Haut Katanga en République Démocratique du Congo, son siège principal se situe au numéro 05 de l'avenue Lubumbashi, au quartier Makomeno.

1.2.2. Structure

La structure des académies CISCO se présente comme suit :

^CISCO

^CATC

^Académie ^régionale			^Académie ^régionale

TFE_ESIS_AS 2016

^locale

^locale

Figure 1.1 structure des académies Cisco

^Académie

^locale

^Académie

^Académie

^Académie

^locale

? Cisco Academy Training Center (CATC)

Ce sont les centres d'académies Cisco qui font le relais avec Cisco pour

former, assister et suivre les instructeurs des Académies régionales et

locales ;

? Académie régionale

Fonctionne comme un point central supportant un minimum de dix

académies locales et établit un lien entre ces dernières et le Cisco Academy

Training Center ;

? Académie locale

Entité qui dispense le curriculum Cisco Networking Academy.

TFE_ESIS_AS 2016

7

SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

1.3. Etude de l'existant

L'infrastructure se compose de trois sites distants : ? Lubumbashi (le quartier général) :

Qui prend le coeur du centre de données et les différentes interconnexions avec le local administratif de Lubumbashi et les différents laboratoires de formation de l'académie CISCO ;

? Likasi

Relié à Lubumbashi via des liaisons WAN jusqu'aux différents locaux de formation de Likasi ;

? Kolwezi

Relié à Lubumbashi via des liaisons WAN jusqu'aux différents locaux de formation de Kolwezi.

L'interconnexion avec les sites distants est faite via les liaisons Frame Relay¹ en passant par l'opérateur des télécommunications Vodacom.

Frame Relay permet un traitement efficace en volume et en vitesse, en réunissant les fonctions des couches liaison de données et réseau en un seul protocole simple. En tant que protocole de liaison de données, Frame Relay permet d'accéder au réseau en délimitant et en fournissant des trames dans l'ordre approprié et détecte les erreurs de transmission grâce à son contrôle de redondance cyclique standard.

En tant que protocole de réseau, il fournit plusieurs liaisons logiques sur un même circuit physique et permet au réseau d'acheminer les données sur ces liaisons jusqu'à leurs destinations respectives.

1.3.1. Architecture 1.3.1.1. Physique

L'architecture physique du réseau informatique de Katanga Networking Academy se présente comme suit :

¹ Est une évolution de la commutation des paquets X25. Il établit, en mode connecté une liaison virtuelle entre les deux extrémités. Cette liaison est soit permanente (PVC pour Permanent Virtual Circuit), soit établit à la demande (SVC pour Switched Virtual Circuit).

^{No Revision}

^User

^{Storage Server}

^{User Group}

^Group

^ASA

^{Blick
Gateway, X25
Network,
Telco Switch}

^2G,3G,

^{Radio,Switch,}

^VAS/SMSC

^Computer

^IN,

^Signaling

^Computer

^{Access Switch}

^Remark

^NearStore

^CISCO1

^{Location 1}

^{NearStore Client SW}

C ^{DIGITAL MEDIA ENCODER 1000}

^CISCO2

^{Access Switch}

^{Wireless Access Point}

^ASA

^ASA

^ASA

^{Wireless Access Point}

^{No Revision Remark}

^{Network Cameras}

^{SERIAL ETHERNET}

^SERIAL

)

^{Distribution Switch}

^{Distribution Switch}

^{Distribution Switch}

^{Distribution Switch}

^{Access Switch}

^{NGN Location 2}

^{Main Link To Mengo}

^{Backup Link To Mengo}

^Wireless

^{ASA ASA}

^{Most Secured Servers}

^(Billing

& ^VAS)

^{Computer ComputerComputer Computer}

^{Computer ComputerComputer Computer Group}

^{Access Point}

^{SERIAL ETHERNET}

^{ALL HQ Buildings, Floors and}

^Offices

^{Access Switches}

^Si

^{HQ Server Farm Module}

^{HQ Building Distribution}

^{Campus Backbone}

^{Building Access}

^Revision

^No

^Distribution

^Switches

^{Distribution Switches}

^{WS C6509-E}

^{WS 3750 G}

^{Access Switches}

^{Core Switches}

^{WS 3760}

^{WS 3750 G}

⁰

^{IT Servers @bility}

^Si

^{WLAN Controller}

^User

^{General Architecture}

^{Remark No Revision Remark}

^{Power Status Alarm AP}

^{CISCO 2100 SERIES}

^{Wireless LAN Controller}

^{Network Management}

^Module

^{Access Control Server,}

^{Monitoring Server,}

^{Syslog Server,etc...}

^{Management Servers}

^{Edge Distribution}

^Module

^{Distribution Switches}

^{NetApp Filer}

^{Storage and risk Management}

^{Access Switch}

^{Access Switches}

^{Storage Server}

^{ASA ASA}

^{Internet Connectivity module}

^{Access Switch}

^{DMZ Module (Public Servers)}

^ASA

^ASA

^{Risk Management}

^{WAN Module}

^{DMZ Servers (Exchange Front End)}

^{WAN Router}

^{WAN Hub}

^Router

^{WAN Router}

^{Frame Relay Backbone For}

^{remote sites}

^RAS

^{Access Switch}

^ASA

^DESIGNED : ^{Bertin Polombwe}

^{APPROVED 1} :

^{CHECKED 1} : ^{CHECKED 2} :

^{Wireless Access Point}

^ISP/INTERNET

^{LAN WAN Architecture Network Diagram}

^ASA

^{NGN Network TelcoNetwork}

^{Telco 1}

^{WAN Spoke Router}

^ADLS

^Sites

^{Wireless Access Point}

^ASA

^{Dial-up Client} ?

^OR

^VPN ??

^DATE : ^DATE : ^DATE : ^DATE :

^{WAN Spoke Router}

^SERIAL

^{Access Switch}

^DATE : ²⁰¹²

^{FILE NAME} :

^{File server likasi}

^{GPRS Cabin} && ^{USSD Gateway}

^ISP

^{Access Switch}

^DRAWN :

^{File sever kolwezi}

^{This segment is not well specified. Should it be}

^{on WAN or on the Campus backbone?}

^{Computer User Group}

^LIKASI

^{CISCO AIRONET 1200 I WIRELESS ACCESS POINT}

^IS-HOTSPOT

^{FILE NAME} :

^{NOC DATE} : ^{Oct 12, 2012}

^KOLWEZI

^{Wireless Access Point}

^Computer

^{Wireless Access Point}

^SERIAL

^SERIAL

^{User Group}

^Revision

^A

Figure 1.2 architecture générale de Katanga Networking Academy

TFE_ESIS_AS 2016

8

SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

TFE_ESIS_AS 2016

9

SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

1.3.1.2. Logique

Sur le plan logique, nous allons donner le plan d'adressage et le plan de nommage utilisés à travers les tableaux suivants.

Tableau 1.1 plan d'adressage

Sites	Adresses réseaux	Plages		Masques
Lubumbashi Likasi Kolwezi	10.137.68.0 10.137.69.0 10.137.70.0	10.137.68.1 10.137.69.1 10.137.70.1	- 10.137.68.254 - 10.137.69.254 - 10.137.70.254	255.255.255.0 255.255.255.0 255.255.255.0
Tableau 1.2 plan de nommage
Sites	Access point	Switchs	Routeurs	Serveurs
Lubumbashi Likasi Kolwezi	kan- aplub- kan- aplks- kan- apklz-	kan- swlub- kan- swlks- kan- swklz-	kan- rtlub- kan- rtlks- kan- rtklz-	kan-srvlub- kan-srvlks- kan-srvklz-

NB : Le plan de nommage est tel que la dernière partie est réservée à la fonction ou rôle que joue l'équipement dans le réseau, soit le nom de l'application principale tournant sur le serveur, voir même un numéro identifiant l'équipement par rapport à son emplacement, par exemple kan-srvlub-ad est le nom du serveur situé à Lubumbashi sur lequel tourne l'annuaire active directory.

1.3.1.3. Supports de transmission ? WAN

Les ondes électromagnétiques sont utilisées comme supports de transmission pour les liaisons entre les différents sites moyennant des antennes VSAT², qui permettent la liaison avec l'opérateur des télécommunications Vodacom, qui fournit des services pour le Frame Relay.

² Very Small Aperture Terminal ou terminal à très petite ouverture en français, désigne une technique de communication par satellite bidirectionnelle qui utilise des antennes paraboliques dont le diamètre est inférieur à 3 mètres.

10

SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

· LAN

Tableau 1.3 supports de transmission utilisés dans le LAN

Filaire Sans fil

Les câbles UTP³ de catégories 5, 6 , 7 sont utilisés pour assurer l'interconnexion entre les différents équipements réseaux et serveurs.

La fibre optique grâce aux haut débits qu'elle offre est utilisée pour interconnecter les locaux éloignés géographiquement et aussi pour les connexions inter-serveurs.

Les signaux radio fréquence sont émis par différents points d'accès afin de garantir une certaine mobilité dans le système. La technologie sans fil utilisée est le Wi-Fi⁴, avec simplicité comme principale caractéristique, en dehors de cela, les fréquences exploitées par ses techniques de transmission sont d'usage libres et ne nécessitent pas de licence [3, p. 24]. Elle utilise le WPA⁵ comme solution de sécurisation du réseau sans fil.

TFE_ESIS_AS 2016

1.3.2. Eléments constitutifs 1.3.2.1. Sur le plan physique

Du point de vue physique nous avons :

· Faux plancher

Qui a pour fonctions de faire passer les câbles des courants forts et faibles, la conduite d'air froid issu de la climatisation de la salle qui provient des baies par des dalles percées (résultant du principe d'alternance allée chaude - allé froide) et a aussi pour fonction de soutenir les matériels ;

· Faux plafond

Permet le passage des câbles des courants forts/faibles, la conduite de l'air froid issu de la climatisation de la salle qui ressort par des bouches au plafond, la canalisation d'eau, la reprise de l'air chaud dans l'allée chaude par des grilles placées derrière les baies, l'air chaud est capté par les armoires de climatisation dans le plénum du faux plafond, fixer les différents équipements de sécurité et passer les câbles associés (capteurs de température, hygrométrie, détection d'incendie ainsi que de présence, etc.), il sert aussi à intégrer l'éclairage ;

³ Unshielded Twisted Pair soit paire torsadée non blindée en français.

⁴ Wireless Fidelity, est l'ensemble des protocoles de communication sans fil régis par les normes du groupe IEEE 802.11 (ISO/CEI 8802-11).

⁵ Wi-Fi Protected Access est un mécanisme pour sécuriser les réseaux sans fil de type Wi-Fi utilisant l'al-gorithme de chiffrement TKIP (Temporary Key Integrity Protocol).

TFE_ESIS_AS 2016

11

SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

· Système de détection d'intrusion et d'extinction d'incendie (DEI)

Ce système a pour fonction de détecter les départs de feu à l'intérieur des baies, des locaux voisins, des faux planchers ainsi que des faux plafonds, il permet de prévoir les asservissements de la climatisation, des contrôles d'accès et des portes coupe-feu, ce système émet un signal d'alarme déclenchant un plan d'évacuation, en même temps il permet d'éteindre les incendies provenant dans les différents endroits du centre de données ;

· Système de détection d'eau ou d'humidité

Ce système a pour fonction principale de détecter le plus vite possible les fuites d'eau, les infiltrations, les défauts du système de climatisation de telle sorte à agir avec la plus haute efficacité dans la protection des systèmes ;

· Système de contrôle et de régulation de la température et de l'hygro-métrie

Les équipements informatiques produisent une certaine température lors de leurs fonctionnements et cette dernière est limitée, il est donc important de maintenir la température ambiante du lieu où se trouvent ces équipements autour d'une vingtaine de degrés Celsius, telle est la fonction de l'hygrométrie qui y arrive en climatisant la salle, en réfrigérant les baies et les processeurs ;

· Alimentation électrique

Qui permet d'assurer d'une façon fiable l'alimentation électrique des systèmes d'informations ;

· Alimentation sans interruption

Assure trois fonctions ; celle de la protection contre les coupures électriques courtes (allant d'une dizaine des minutes jusqu'à moins d'une heure) et contre les micros-coupures électriques de l'ordre de quelques centièmes de secondes, deuxièmement elle régule les niveaux haut et bas de tension du courant électrique, du maintien de ses caractéristiques alternatives (fréquence et forme sinusoïdale) ainsi que du filtrage des harmoniques et enfin la transition tout en permettant la mise en route du système d'alimentation de secours ;

· Redondance des équipements et des alimentations

La redondance est un moyen utilisé à tous les niveaux afin de limiter les risques des pannes. En résumé, chaque élément est présent au moins en double et le basculement se fait automatiquement en cas de panne, cela assure une haute disponibilité ;

· Système de contrôle d'accès et de surveillance

Ce système a pour fonction de contrôler l'accès en vérifiant l'authentification via les badges, il est couplé avec des ensembles mécaniques faisant obstruction au passage libre, et des ensembles électroniques de détection d'ouverture prolongée, d'effraction et/ou de pénétration.

TFE_ESIS_AS 2016

12

SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

1.3.2.2. Sur le plan réseau

Plusieurs éléments constituent la structure réseau de l'infrastructure : ? Les baies

De type 42U, dédiées au câblage ou mixtes câblage/équipements, accueillant les patch panel, brush panel dans leurs parties hautes et les équipements actifs dans leurs parties basses ;

? Les switchs

Relient plusieurs segments par câble ou par fibre optique dans le réseau, répartis sur trois niveaux :

1. Coeur

Modèle CISCO Catalyst 6509-E, servent à interconnecter d'autres switchs dits de concentration ou de distribution, au nombre de deux, ils sont hyper fiables vu que sans eux rien ne fonctionne, ils fonctionnent en parallèle, mais chacun d'eux étant capable de gérer tout le trafic en cas de panne ou d'arrêt quelconque pour modification de l'autre ;

2. Distribution

Modèle CISCO 3750 Avec PoE⁶, distribuent le réseau aux switchs d'accès, ils sont eux même raccordés au switchs coeur dit de backbone ;

3. Accès

Modèle CISCO 2960-X 24 ports qui délivrent le réseau aux utilisateurs et équipements finaux.

? Les pare-feu

Qui sont matériels et logiciel, permettent de faire respecter la politique de sécurité du réseau en définissant les types des communications autorisées et interdites, dans notre cas Pfsense est utilisé comme pare-feu logiciel et Cisco ASA 5506-X comme pare-feu matériel ;

? Les routeurs

De modèle Cisco 1921/K9 C1921, ce sont les éléments intermédiaires permettant d'assurer le routage des paquets entre les différents sites ;

? Les accélérateurs WAN

Permettant de réduire la quantité de données circulant dans les deux sens à travers le WAN au moyen des techniques de compression et de mise en cache de données ;

⁶ Power Over Ethernet (alimentation électrique par câble Ethernet), est la technologie qui utilise les câbles Ethernet RJ45 pour alimenter en électricité les équipements PoE tels que les téléphones IP, les caméras en même temps que la transmission des données.

TFE_ESIS_AS 2016

13

SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

· Les équipements de liaison WAN

Fournit par la maison des télécommunications Vodacom ;

· Les équipements d'accès à Internet

Fournit par la maison des télécommunications Vodacom ;

· Les points d'accès

Modèle Cisco AP541 qui permettent de couvrir certaines zones avec des signaux sans fil favorisant ainsi la mobilité ;

· Les contrôleurs sans fil

Modèle Cisco AIR-CT2504-5-K9 permettent de centraliser l'administration des différents points d'accès ;

· Les serveurs

Modèle HP PROLIANT GEN8 RAM 64GB faisant tourner des systèmes d'exploitation basés sur le noyau Linux et Windows, permettant d'offrir différents services, ils offrent aussi la possibilité de faire la virtualisation des serveurs grâce à l'emploie d'un hyperviseur bare-metal⁷.

· Le câblage

Qui sont de deux types dans l'infrastructure :

ToR (top of rack) : consiste en la mise en place d'un switch d'accès dans chaque baie pour offrir la connectivité nécessaire à tous les serveurs qui y sont rackés. Le but est de garder le plus gros câblage à l'intérieur de la baie. Le seul câblage est celui des uplinks du switch ToR vers les switchs de distribution.

EoR (End of rack) : contrairement à la solution ToR, aucun switch ne se trouve dans les baies serveurs. A la place, au bout de chaque rangée, un ou plusieurs switchs assurent la connectivité de tous les serveurs de la rangée.

Voici un tableau qui reprends l'inventaire de quelques équipements clés de l'in-frastructure réseau :

⁷ Hyperviseur de type 1 ou natif, c'est un système qui s'installe directement sur la couche matérielle de la machine. Cette plateforme est alors considérée comme outil de contrôle du système d'exploitation.

14

SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

Tableau 1.4 inventaire des équipements

Sites Equipements Modèles Types de machine nombre

Cisco Catalyst 6509 -E Physique 2

Switch Cisco 3750 Physique 8

Lubumbashi Cisco 2960 Physique

Routeur Cisco 1921/K9 C1921 Physique 5

Serveur HP PROLIANT GEN8 Virtuel & Physique 18

Cisco Catalyst 6509 -E Physique -

Switch Cisco 3750 Physique -

Likasi

Cisco 2960 Physique 2 Routeur Cisco 1921/K9 C1921 Physique 1

Virtuel 2

Serveur HP PROLIANT Physique 1

Cisco Catalyst 6509 -E Physique -

Switch Cisco 3750 Physique -

Cisco 2960 Physique 2

TFE_ESIS_AS 2016

TFE_ESIS_AS 2016

15

SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

Kolwezi Routeur Cisco 1921/K9 C1921 Physique 1

Serveur HP PROLIANT

Virtuel 2 Physique 1

TFE_ESIS_AS 2016

16

SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

1.3.2.3. Sur le plan système

Un système étant un ensemble d'éléments interagissant entre eux selon certains principes ou règles, il est déterminé par la nature de ses éléments constitutifs, les interactions entre ces derniers, sa frontière (critère d'appartenance au système) ainsi que les interactions avec son environnement. Le centre de données de Katanga Network Academy a en son sein plusieurs systèmes en fonction des différents besoins.

Les systèmes serveurs Windows sont propriétaires et offrent des procédures d'ins-tallation facilitées par le recours à une interface graphique ergonomique, l'installation peut aussi se faire en ligne de commande, ils jouent un très grand rôle qui est celui de la centralisation grâce à active directory et le contrôleur de domaine.

? Active Directory

Annuaire des objets du réseau, il permet aux utilisateurs de localiser, de gérer et d'utiliser facilement les ressources, il stocke les informations sur les objets comme les serveurs, le domaine, sites, utilisateurs, ordinateurs, imprimantes. En somme, il permet la centralisation des données, l'évolutivité, la standardisation, l'extensibilité ainsi que la sécurité ;

? Contrôleur de domaine

Il stocke les données de l'annuaire et gère les communications entre les utilisateurs et le domaine, y compris les processus d'ouverture de session d'utilisateur, l'authentification et les recherches d'annuaire. Il synchronise les données d'annuaire en utilisant la réplication multi maître, assurant ainsi la cohérence des informations en permanence.

Les systèmes basés sur le noyau Linux quant à eux sont dits open source, ils offrent la possibilité d'apporter des modifications à leurs codes source, ce facteur permet d'améliorer la sécurité de ces systèmes, les procédures d'installation diffère d'un système Linux à un autre, les différents services sont implémentés en ajoutant des packages en fonction du besoin, ainsi la plupart des serveurs de l'infrastructure sont basés sur le noyau Linux, c'est le cas de :

? IredMail Server

Qui se présente comme une mise en commun des composants logiciels dont l'installation et la configuration sont entièrement automatisées. Il permet d'obtenir très rapidement un système de messagerie complet (relais de messagerie, règles de messagerie, Webmail, anti-spam, etc.) ;

? Xivo Server

Qui est une solution open source de téléphonie sur IP, offrant des services de communication unifiée et centre des contacts, il est basé sur le célèbre moteur de télécommunications Astérix et est distribué sous licence GPL v3, il s'intègre dans les environnements hétérogènes et convient à tout type d'architecture [4]. Il dispose des fonctionnalités classiques d'un autocommutateur téléphonique privé comme la messagerie unifiée, serveur vocal interactif, conférence téléphonique, contrôle depuis un ordinateur (CTI serveur), gestion de répertoire, services internet, résultats

TFE_ESIS_AS 2016

17

SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

statistiques, mobilité, auto-configuration, assistance de bureau, centre de contact, etc. [5] ;

? BigBluButton Server

Logiciel libre sous licence LGPL permettant de réaliser des conférences web qui sont utiles pour l'association, il offre des fonctionnalités comme la création des espaces virtuels de conférences multi-utilisateurs, le partage des documents, le partage de bureau, communication via la conférence par voix sur IP, webcam ainsi que le chat qui peut être privé ou public, tableau blanc pour annoter les présentations, l'enregistrement des sessions pour relecture en HTML⁸ 5, etc. ;

? Tiki Server

Logiciel libre écrit en PHP et distribué selon les termes de la licence GNU LGPL, c'est une application web de gestion de contenu et de travail collaboratif proposant diverses fonctionnalités supplémentaires comme le calendrier, forum, moteur de sondage, etc. ;

? Bacula Server

Logiciel de sauvegarde centralisée distribué sous licence GPL, il prend en charge l'automatisation des sauvegardes totales, incrémentales et différentielles, il prend également en charge les opérations de restauration de fichiers et, dans certains cas, de restauration à zéro (bare-metal recovery), il s'appuie sur une architecture modulaire et distribué, il utilise un SGBD (MySQL, PostgreSQL) pour la gestion des catalogues des sauvegardes et supporte beaucoup des médias ( Disque dur, bandes magnétiques, prise en charge des chargeurs de bandes, etc.) ;

? FreeNAS Server

Distribution Linux basée sur FreeBSD et dont le but dans l'infrastructure est celui de créer un serveur de stockage NAS⁹, elle propose des méthodes de partage CIFS¹⁰ pour Windows, NFS¹¹ pour Linux et AFP¹² pour Macintosh, il propose aussi du FTP¹³ et TFTP¹⁴. Le protocole ISCSI¹⁵ lui est intégré pour le stockage réseau, en ce qui concerne ce dernier nous

⁸ HypertText Markup Langage, est le format de données conçu pour représenter les pages web.

⁹ Network Attached Storage, désigne un périphérique de stockage permettant de stocker et partager des fichiers au travers d'un réseau, le plus souvent un réseau local Ethernet, mais parfois au travers un réseau étendu de type WAN.

¹⁰ Common Internet File System en français System de Fichier Internet Commun, ancien protocole permettant le partage des ressources sur des réseaux locaux de PC Windows.

¹¹ Network File System en français système des fichiers en réseau, est à l'origine un protocole développé par Sun Microsystems en 1994 qui permet à un ordinateur d'accéder à des fichiers via un réseau. Il fait partie de la couche application du modèle OSI.

¹² Apple Filing Protocol est un protocole de partage de fichier utilisé sur Macintosh, il s'utilise généralement à travers le port TCP 548, il fait partie de la couche présentation du modèle OSI.

¹³ File Transfert Protocol ou protocole de transfert des fichiers est un protocole de communication destiné à l'échange informatique des fichiers sur un réseau TCP/IP.

¹⁴ Trivial File Transfert Protocol ou protocole simplifié de transfert des fichiers. Il fonctionne en UDP sur le port 69.

¹⁵ Internet Small Computer Interface est un protocole IP destiné à relier les installations de stockage de données.

TFE_ESIS_AS 2016

18

SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

pouvons mettre en place un RAID¹⁶ logiciel ou matériel car ils sont supportés ainsi que la gestion des utilisateurs se trouvant dans l'annuaire Active Directory.

Outre les systèmes cités précédemment, Internetworking Operating System de CISCO est le système d'exploitation qu'utilisent les équipements de l'infrastructure, il est muni d'une interface en ligne de commande accessible via Telnet, port série, et SSH et peut aussi disposer d'une interface web.

Différentes versions sont utilisées sur la gamme des routeurs, switchs et point d'accès. Ce système a pour particularité de prendre immédiatement tous les changements de configuration en compte, de ce fait, il utilise deux espaces distincts qui servent au stockage de la configuration dont le running-config stockée en mémoire vive et qui contient la configuration actuelle utilisée et startup-config stocké en mémoire non volatile et qui contient la configuration au démarrage du matériel. [6, p. 10]

1.3.3. Sécurité

Dans les organisations possédant une structure informatique conséquente, l'accès physique aux données et aux composants du système d'information fait partie de la politique de sécurité du même système d'information, il est plus courant de penser à l'aspect technique/logique lorsque nous parlons de la sécurité mais l'on oublie souvent de parler de l'accès et de la protection physique, raison pour laquelle la sécurité peut être divisée en trois branches en vue de la rendre la plus optimale possible.

1.3.3.1. Sécurité physique

Le contrôle d'accès a une importance capitale en ce lieu et c'est parmi les préoccupations majeures au sein de l'infrastructure. Plusieurs solutions existent afin de contrôler les identités du personnel accédant au Datacenter. Vu que la sécurisation de ce dernier passe en premier lieu par la mise en place d'un fonctionnement cohérent, il est tout d'abord essentiel de séparer via des barrières physiques les locaux IT¹⁷, techniques et télécoms. Tout cela dans le but de limiter l'accès aux seules personnes habilitées.

L'accès aux installations est assuré via les badges, la lecture des informations stockées par le badge d'accès se fait lors du défilement sur le lecteur de ce dernier. Les informations étant stockées dans une puce magnétique située sur le badge. Les lecteurs de badges sont connectés aux unités de contrôle d'accès qui assurent une mémorisation locale de la liste des badges autorisés, des plages horaires, les historiques et une gestion autonome d'accès même en cas de déconnexion du réseau Ethernet, ces unités sont raccordées au serveur via le réseau, les unités de contrôle d'accès dialoguent avec le serveur mais aussi entre elles pour assurer les interactions, asservissements et les données qu'elles échangent sont sécurisées par un cryptage de données. Les échanges de données entre

¹⁶ Redundant Arrays of Inexpensive Disks soit regroupement des disques peu onéreux, est un ensemble des techniques de virtualisation du stockage permettant de répartir des données sur plusieurs disques durs afin d'améliorer soit les performances, soit la sécurité ou la tolérance de l'ensemble du ou des systèmes.

¹⁷ Information Technology (Technologie de l'information).

TFE_ESIS_AS 2016

19

SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

unité de contrôle d'accès et le serveur se font par des trames UDP¹⁸ afin d'optimiser les échanges et l'encombrement du réseau.

La vidéosurveillance reposant sur un système numérique permet aussi de renforcer la sécurité, grâce à des caméras placées sur différents points à surveiller et sont reliées à un terminal qui permet de visualiser les images fournies par toutes les caméras de surveillance, toutes ces données sont stockées sur des disques.

1.3.3.2. Sécurité réseau

Certes, le recours à la virtualisation et à d'autres technologies nouvelles s'avère rentable, mais le rôle capital que joue aujourd'hui le réseau fait qu'il soit essentiel de remettre à plat la façon dont on le sécurise. Les choix effectués en la matière peuvent avoir une incidence sur les coûts d'exploitation d'aujourd'hui et de demain, la durée de fonctionnement des services de sécurité et la précision avec laquelle l'accès des utilisateurs à telle ou telle application est contrôlé.

La solution open source Packetfense fonctionnant avec une multitude d'équipe-ments sans fil et filaire possède plusieurs mécanismes pour la gestion des accès réseau de l'infrastructure tout en assurant les fonctions suivantes [7] :

· L'enregistrement des composants réseaux ;

· La vérification de conformité des postes présents sur le réseau ;

· La détection d'activités illicites ;

· La détection proactive de vulnérabilités ;

· L'isolation des composantes réseau problématiques ;

· Une gestion simple et efficace des invités sur le réseau.

L'utilisation de Pfsense comme pare-feu offre aussi plusieurs fonctions notamment la redondance et l'équilibrage de la charge, un portail captif, donne des graphes concernant la charge système et réseau, les tables d'état ou state table qui contiennent les informations sur les connexions réseaux dans le but de permettre l'acquisition d'un aperçu des connexions et surtout de créer des règles, etc.

Le pare-feu Cisco ASA 5506-X grâce à son module intégré Firepower qui supporte le mode en ligne et le mode surveillance passive, le premier mode offre les avantages supplémentaires que le deuxième mode, le module Firepower déployé en mode en ligne fournit la meilleure analyse de l'inspection approfondie de cas avant que les paquets soient renvoyés au plan principal ASA. Il prend des mesures lorsque le trafic malveillant est détecté.

Lorsque le trafic arrive à l'interface d'entrée de l'ASA :

· L'ASA déchiffre le trafic si elle faisait partie d'un tunnel VPN¹⁹ établie ;

¹⁸ User Datagram Protocol en français Protocole de Datagramme Utilisateur, est un des principaux protocoles de télécommunication utilisés par internet. Il fait partie de la couche transport du modèle OSI, il appartient à la couche 4, comme TCP.

¹⁹ Virtual Private Network ou réseau privé virtuel est un tunnel garantissant l'exclusivité d'une connexion entre un point A et un point B distant via un réseau non sécurisé comme internet par exemple, l'accès à ce tunnel est non seulement réservé mais aussi chiffré (crypté).

TFE_ESIS_AS 2016

20

SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

? Les paquets sont filtrés par rapport aux politiques du pare-feu tels que ACL²⁰, NAT²¹ et inspection ;

? En option, le trafic est envoyé au module Firepower pour un contrôle plus profond (on peut configurer de sorte qu'on envoie tout le trafic ou uniquement le trafic à haut risque au module Firepower afin de conserver les ressources système) ;

? Après passage au Firepower le paquet est renvoyé au moteur principal de l'ASA pour la prochaine étape de décision de routage ;

? Le trafic est ensuite passé à l'interface de sortie de l'ASA pour être transmis au reste du réseau.

1.3.3.3. Sécurité des postes de travail

Symantec Endpoint Protection offre une protection plus rapide et plus avancée contre les attaques sophistiquées et ciblées qui existent sur les postes de travail faisant tourner les systèmes d'exploitation Windows, les couches de protection incluent le pare-feu, la prévention des intrusions, l'antivirus ainsi que les technologies avancées insight et SONAR.

La technologie de surveillance insight de Symentec basée sur la réputation protège contre les logiciels malveillants en mutation tout en garantissant des temps d'analyse réduits. SONAR quant à elle offre une protection puissante contre les attaques zero day en surveillant le comportement des fichiers. [8]

1.3.4. Virtualisation

La virtualisation est l'ensemble des technologies matérielles ou logicielles qui permettent de faire fonctionner plusieurs systèmes d'exploitation et/ou plusieurs applications sur une même machine, séparément les uns des autres, comme s'ils fonctionnaient sur des machines physiques distinctes [9, p. 7]. Elle impacte sur les domaines de stockage, application, système d'exploitation, réseau et sécurité.

C'est une technologie de plus en plus incontournable, les environnements virtuels sont très en vogue au sein des entreprises de toutes tailles. Il est vrai que les avantages de cette technologie sont nombreux en termes de productivité, de coûts et d'exploitation.

En effet, elle permet la baisse de coûts importantes par la réduction du nombre des machines physiques, mais aussi par toutes les autres économies induites : énergie, temps de mise en oeuvre des systèmes.

Katanga Networking Academy utilise PROXMOX comme solution de virtuali-sation bare-metal, elle s'installe directement sur la couche matérielle du serveur hôte sans que celui-ci n'ait un système d'exploitation tournant dessus, elle est open source et est

²⁰ Access Control List (Liste de contrôle d'accès).

²¹ Network Address Translation en français Traduction d'adresse réseau consiste à faire correspondre les adresses IP internes non unique et souvent non routable d'un intranet à un ensemble d'adresses externes uniques.

TFE_ESIS_AS 2016

21

SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

basée sur les composantes OpenVZ²² et KVM²³. Elle permet la gestion des réseaux virtuels, du stockage et la gestion centralisée de cluster ainsi que de la haute disponibilité.

Le domaine de la virtualisation des serveurs consiste à placer les postes clients légers peu encombrants et sécurisés sur des postes de travail et à les relier sur des environnements de travail virtualisés. Grâce à ces derniers, Katanga Networking Academy met à la disposition de ses utilisateurs des postes de travail sécurisés disponibles en permanence depuis n'importe quel noeud du réseau. De plus nous pouvons administrer à distance. Ils ont l'avantage de réduire les couts liés à la maintenance des postes et à renforcer la sécurité de ces derniers. [10]

1.3.4.1. Principales caractéristiques de Proxmox

· Une interface web qui facilite un management de l'environnement en un point,

· Les snapshots à chaud, qui permettent une sauvegarde de l'état d'un serveur virtuel, ce qui donne la possibilité de faire une migration à chaud (les fichiers sauvegardés peuvent être transférés vers une autre machine ou peuvent être utilisés pour la restauration) [11] ;

· Le regroupement de plusieurs noeuds au sein d'une même entité est possible grâce à la fonction clustering, elle permet d'assurer une haute disponibilité [11] ;

· Le module KVM étant créé pour le noyau linux permet d'améliorer les performances des machines virtuelles en faisant une émulation d'un ordinateur complet dans le but de rendre le système indépendant de l'hôte ;

· OpenVZ est le noyau du système d'exploitation qui se charge de l'isolation entre différentes machines virtuelles et permet d'exécuter des applications dans des contextes différents, ceci permet d'obtenir des meilleures performances ;

· Les ressources sont modifiables à chaud. 1.3.5. Critique du réseau existant

Vu la grandeur et l'évolution du réseau, nous voyons que l'infrastructure mise en place par Katanga Networking Academy connait des points forts et faibles.

1.3.5.1. Points forts

· Le réseau est très bien dimensionné ;

²² Est une technique de virtualisation de niveau système d'exploitation basée sur le noyau Linux. Cette technique de virtualisation de niveau système est souvent appelée conteneurisation et les instances sont appelés conteneur. OpenVZ permet à un serveur physique d'exécuter de multiples instances de système d'exploitation isolés, qualifiées de serveurs privés virtuels ou environnements virtuels.

²³ Kernel-based Virtual Machine est un hyperviseur libre de type 1 pour Linux. KVM est intégré dans le noyau Linux depuis la version 2.6.20.

TFE_ESIS_AS 2016

22

SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

· La virtualisation des systèmes qui réduit les coûts ;

· La réplication des serveurs de fichier sur chaque site ;

· Une très bonne mobilité grâce aux différents points d'accès ;

· Une très bonne politique de sécurité ;

· Présence des VLAN²⁴ qui segmentent logiquement le réseau et augmentent le niveau de sécurité ;

· Présence d'un logiciel de gestion de parc informatique. 1.3.5.2. Points à améliorer

· La répétition des mêmes tâches par les administrateurs ;

· La mise à jour faite manuellement sur chaque noeud ;

· L'installation manuelle des logiciels, elle nécessite le passage sur chaque noeud pour l'exécution de la tâche ;

· La configuration des différents noeuds est effectuée manuellement, elle nécessite donc de prendre le noeud à distance ou aller sur place ;

· Le manque de serveur pour la centralisation de la configuration des différents noeuds.

1.4. Spécification des besoins 1.4.1. Introduction

Parmi les tâches des administrateurs systèmes nous avons la mise à jour, le dépannage, la reconfiguration, le débogage, la modification, etc., la configuration manuelle est inadaptée à la croissance, répétitive, génère des erreurs d'inattention, n'a pas d'historique (documentation des interventions), n'est pas toujours reproductible de façon fiable et requiert une grande rigueur surtout pour un travail en équipe.

Par ailleurs la gestion centralisée par scripts ne permet pas la gestion des erreurs, pose des problèmes pour différentes architectures et différents systèmes d'exploitation, évolue mal et n'est pas transposable ailleurs.

Étant donné le nombre des serveurs qui devient de plus en plus élevé. Gérer ce nombre devient de plus en plus difficile et exige l'augmentation du nombre d'heures supplémentaires de travail des administrateurs et le nombre de ces derniers.

Dans le but d'améliorer le quotidien des administrateurs système, Katanga Networking Academy souhaite la mise en place d'un système qui permettra de gérer plus facilement le parc de ses serveurs, plusieurs avantages en découlent notamment :

· La gestion de manière efficace et centralisée de la configuration de plusieurs machines tout en ayant la souplesse de s'adapter aux spécificités de chacune d'entre elles ;

²⁴ Virtual Local Area Network pour réseau local virtuel en français, est un réseau informatique logique indépendant.

TFE_ESIS_AS 2016

23

SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

· L'homogénéité de la configuration ;

· La cohérence des configurations ;

· Le gain en temps, en performance et en flexibilité ;

· La diminution du nombre d'erreurs ;

· Automatisation des tâches répétitives ;

· La gestion de manière proactive des changements ;

· Un travail en équipe plus facile pour les administrateurs système.

1.4.2. Spécification des besoins fonctionnels

Les besoins fonctionnels permettent de ressortir une action pouvant être menée sur l'infrastructure en réponse à la demande.

En somme, après discussion avec les responsables de Katanga Networking Academy sur ce grand nombre de serveurs à manager, il en résulte que le nouveau système de gestion des configurations de l'association devra être un système qui permettra aux administrateurs systèmes de se concentrer sur l'écriture des états de configuration à atteindre sur différents noeuds et les affranchir des commandes propres à chaque système d'exploitation pour arriver aux états désirés, pour ce faire, nous aurons à :

· Implémenter un système pour la gestion des configurations qui nous permettra de définir l'infrastructure comme le code ;

· Implémenter un système qui permettra aux administrateurs de gérer les serveurs tout au long de leurs cycles de vie, de l'approvisionnement et de la configuration à l'orchestration et la surveillance.

De ces deux implémentations, nous devons ressortir des fonctionnalités devant répondre aux besoins posés par Katanga Networking Academy, ces fonctionnalités sont :

· Authentification ;

· Ajout des nouveaux noeuds ;

· Regroupement des hôtes et les gérer indépendamment des leurs emplacements physiques ;

· Gestion des versions des logiciels installés ;

· Synchronisation automatique des noeuds avec l'état de configuration ;

· Génération des rapports ;

· Génération des statistiques ;

· Monitoring ;

· Audits ;

· Signature des certificats ;

· Résolution de noms ;

· Attribution automatique d'adresses IP.

TFE_ESIS_AS 2016

24

SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

1.4.3. Spécification des besoins non fonctionnels

Les besoins non fonctionnels sont ceux qui représentent les exigences explicites ou contraintes internes et externe auxquelles le système doit répondre, c'est ainsi, notre système doit répondre aux critères ci-après :

· Utilisabilité ;

· Stabilité ;

· Performance ;

· Disponibilité ;

· Sécurité ;

· Portabilité ;

· Simplicité de mise en place ;

· Fiabilité ;

· Coût.

1.5. Conclusion partielle

L'étude que nous avons menée nous a permis de mettre un accent sur les problèmes réels que rencontre Katanga Networking Academy afin d'y ressortir le maximum d'idées qui nous ont mené à la détermination des objectifs que nous devrons atteindre dans ce présent travail. C'est pour cela que nous aurons à proposer un système qui apporte des solutions aux différents problèmes liés à la gestion des configurations de l'infrastruc-ture.

La suite de notre travail nous mène dans la conception générale et la conception logique détaillée qui nous permettra de préparer le cadre pour le choix technologique de la solution.

TFE_ESIS_AS 2016

CHAPITRE 2: CONCEPTION GENERALE ET DETAILLEE LOGIQUE

2.1. Introduction

L'étude de l'existant nous a permis de ressortir les besoins et les fonctionnalités qu'aura le futur système. A ce stade ce dernier parait comme une boîte noire qui encapsule tous les mécanismes qui pourront répondre aux fonctionnalités demandées, nous allons la décomposée en modules dans le but de réduire son niveau d'abstraction.

Nous avons opté pour la méthode top down design qui procède par décomposition du problème. Le problème est ainsi divisé en un certain nombre des sous problèmes, chacun de complexité moindre. Cette division est ensuite appliquée aux sous problèmes générés, et ainsi de suite, jusqu'à ce que la résolution de chacun des sous problèmes soit trivial [12, Chap. 0].

Dans cette partie du travail, nous ferons la conception générale de notre futur système qui repose sur le concept de l'infrastructure comme code²⁵ et nous ferons aussi une conception détaillée logique qui nous permettra de diminuer le niveau d'abstraction situé au niveau de la conception générale.

2.1.1. Niveaux d'abstraction appliqués à la conception

L'abstraction consiste à ne considérer que les aspects jugés importants d'un système à un moment donné, en négligeant les autres aspects.

Dans le traitement d'un problème complexe, il est conceptuellement impossible de l'appréhender d'un seul bloc dans son intégralité, notre esprit a besoin de dégrossir le problème afin de le comprendre petit à petit. Une fois que ce problème sera subdivisé en sous-problème de taille plus petite, l'analyse de chacun de ces sous problèmes exige à en comprendre les grandes lignes, ensuite de rendre plus fine sa compréhension pour enfin comprendre tous les détails [12, Chap. 2]. L'abstraction permet une meilleure maitrise de la complexité, c'est pour cela notre processus de conception sera divisé en trois phases :

? La conception générale ;

? La conception logique détaillée ;

? La conception physique ou technique.

²⁵ Nouveau concept pour le contrôle et la gestion des ressources hétérogènes. L'infrastructure comme code permet de programmer des infrastructures.

TFE_ESIS_AS 2016

26

CONCEPTION GENERALE ET DETAILLEE LOGIQUE

Figure 2.1 niveaux d'abstraction appliqués à la conception [13, p. 6]

La conception générale avec un niveau d'abstraction élevé est en fait la description générale du futur système qui nous permet de faire le regroupement de tous les composants logiques de la solution qui sont faiblement couplés entre eux et intervenant dans l'architecture du système, ceci sera fait sans entrer dans les moindres détails sur la façon dont ils sont regroupés.

La conception détaillée logique avec un niveau d'abstraction intermédiaire ou moyen, identifie et inventorie les composants logiciels nécessaires à l'implémentation de la solution et décrit les relations existantes entre ces composants tout en s'appuyant sur les exigences de qualité de service ou fonctionnalités définies lors de la phase de spécification des besoins. A ce stade nous ferons abstraction sur la façon dont les différents composants logiciels seront implémentés.

Pour mettre fin à notre phase de conception, nous réduirons à nouveau le niveau d'abstraction au plus bas niveau via la conception physique afin d'offrir les détails maximums avec plus des concepts de réalisation dans une solution technologique de gestion des configurations reposant sur les principes de l'infrastructure définit par le logiciel ou l'infrastructure comme code.

2.2. Conception générale

2.2.1. Adoption de l'infrastructure comme code

L'infrastructure comme code autrement appelé infrastructure définie par le logiciel (software defined infrastructure) est un type d'infrastructure informatique que les équipes d'exploitation peuvent gérer automatiquement via le code, au lieu d'utiliser un processus manuel.

TFE_ESIS_AS 2016

27

CONCEPTION GENERALE ET DETAILLEE LOGIQUE

Le concept de l'infrastructure comme code est similaire à la programmation des scripts, qui sont utilisés pour automatiser les processus informatiques importants. Cependant, les scripts sont principalement utilisés pour automatiser une série d'étapes statiques qui doivent être répétées plusieurs fois sur plusieurs serveurs par exemple. Au lieu des scripts, l'infrastructure comme code utilise un niveau supérieur ou langage descriptif pour coder des processus plus souples et adaptatifs de provisionnement et de déploiement.

2.2.1.1. Apport de l'infrastructure comme code

La valeur de l'infrastructure comme code peut être décomposée en trois catégories mesurables à savoir :

? Le coût (réduction),

? La vitesse (exécution plus rapide) et

? Les risques (supprimer les erreurs et les violations de sécurité) [14].

La réduction des coûts vise à aider l'entreprise non seulement financièrement, mais aussi en termes des personnes et de l'effort, ce qui signifie qu'en supprimant la composante manuelle, les administrateurs systèmes sont en mesure de recentrer leurs efforts vers d'autres tâches de l'entreprise.

L'automatisation de l'infrastructure permet la vitesse grâce à une exécution plus rapide lors de la configuration de l'infrastructure et vise également à fournir une visibilité pour aider d'autres équipes à travers le travail de l'entreprise rapidement et plus efficacement.

L'automatisation supprime les risques associés à l'erreur humaine, cela permet de diminuer les temps d'arrêt et d'augmenter la fiabilité.

2.2.1.2. Types d'approches

Il y a généralement deux approches, l'infrastructure comme code déclaratif (fonctionnelle) et l'infrastructure comme code impératif (procédure). La différence entre l'ap-proche déclarative et impérative est essentiellement « quoi » par rapport à « comment ».

L'approche déclarative se concentre sur ce que la configuration cible éventuelle devrait être, tandis que celle impérative se concentre sur la façon dont l'infrastructure doit être modifiée pour répondre à cela.

L'approche déclarative définit l'état désiré et le système exécute ce qui doit arriver pour atteindre cet état désiré. L'impérative définit des commandes spécifiques qui doivent être exécutées dans l'ordre approprié pour mettre fin à la conclusion souhaitée.

2.2.1.3. Méthodes

Il existe deux méthodes pour l'infrastructure comme code, la méthode push et la méthode pull :

TFE_ESIS_AS 2016

28

CONCEPTION GENERALE ET DETAILLEE LOGIQUE

? Push

Décrit un style de communication de réseau où la demande pour une transaction donnée est initiée par l'éditeur ou le serveur de contrôle.

Les services push sont souvent basés sur les préférences d'informations exprimées à l'avance. Ceci est appelé une publication ou abonnement modèle, un noeud client souscrit à diverses informations (canaux) fournies par le serveur de contrôle, dès qu'un nouveau contenu est disponible sur un des canaux, le serveur pousse cette information vers le client ;

? Pull

Décrit un style de communication de réseau où la demande initiale de données provient d'un noeud client, puis est rependue par le serveur. Les demandes de Pull constituent le fondement du réseau informatique, où de nombreux noeuds demandent des données à partir d'un ou plusieurs serveurs centralisés.

2.2.1.4. Concepts de base de la programmation orientée objet

Un objet est l'entité élémentaire dans le paradigme orienté objet. Il intègre les données et les procédures ou méthodes qui manipulent ces données. Cela montre le principe de l'encapsulation qui permet l'abstraction des données. La classe est l'entité conceptuelle qui décrit les objets. Les classes d'objets sont organisées en hiérarchie d'héri-tage. Voici quelques concepts liés à la programmation orientée objet et qui de même interviendront dans notre travail :

? Classe

Une classe est une entité qui regroupe sous le même nom les données et les méthodes qui manipulent ces données. Une méthode appartenant à une classe ne peut manipuler que les données de celle-ci et ne peut pas accéder aux données d'une autre classe. Une classe peut être considérée comme un module à partir duquel on peut créer des objets [15, p. 32] ;

? Instance

La classe est un descripteur statique qu'on ne peut pas utiliser directement, à partir d'une classe on peut construire autant d'instances ou objets de la classe qui a permis de les créer. Deux instances différentes faisant parties d'une même classe partagent la même liste des méthodes et de données mais avec des valeurs différentes au cas où les données ne sont pas statiques ;

? Transmission des messages

Le mécanisme de transmission de message assure l'interaction entre les objets. Un objet qui envoie un message mentionne toujours le récepteur du message, le nom de la méthode à exécuter et les arguments de cette méthode. L'objet récepteur du message recherche le nom de la méthode puis procède à son activation. Le résultat de l'exécution de cette méthode sera retourné à l'objet qui a envoyé le message. La recherche est faite en remontant l'arbre d'héritage ;

TFE_ESIS_AS 2016

29

CONCEPTION GENERALE ET DETAILLEE LOGIQUE

? Héritage

L'héritage est la propriété la plus innovatrice et l'une des plus intéressantes dans la programmation orientée objet. Il se fait sur des classes et non pas sur des objets, ce mécanisme permet, quand on veut construire une classe ayant des propriétés communes avec une autre classe qui existe dans le système, de ne programmer que les différences entre les deux. Ainsi, toutes les variables et les procédures de la classe existante seront ajoutées aux variables et aux procédures de la classe en construction. La nouvelle entité créée par héritage sera une nouvelle classe étant capable de créer de nouvelles instances. [16, p. 12]

2.2.2. Architecture logique

Plusieurs types d'architecture existent, pour notre projet voici l'architecture qui convient à nos besoins :

^{Serveur d'attribution}

^{automatique d'IP}

^{Serveur des fichiers}

^{Serveur de noms}

^{Signature des}

^certificats

^{Gestionnaire des}

^{configurations}

^{Base de données}

^{Gestionnaire de cycle de vie}

Figure 2.2 architecture générale du futur système

Après avoir ressortit l'architecture générale du système, voici de façon sommaire

ce que fait chacun des modules :

? Serveur de noms

Fournit la résolution de noms de domaine en adresses IP. L'inverse est

aussi possible ;

? Serveur d'attribution automatique d'adresse IP²⁶

Gère l'affectation automatique d'adresse IP sur le réseau ou les sous

réseaux, cette affection est définie par des plages d'adresses ;

²⁶ Internet Protocol (Protocole internet), est un numéro d'identification qui est attribué de façon permanente ou provisoire à chaque appareil connecté à un réseau informatique.

TFE_ESIS_AS 2016

30

CONCEPTION GENERALE ET DETAILLEE LOGIQUE

? Serveur des fichiers

Permet de gérer les fichiers et l'installation des images système disponible via un environnement préalable au boot ;

? Signature des certificats

Permet au gestionnaire de cycle de vie de signer des certificats SSL²⁷ des clients ou noeuds qui viennent prendre les configurations sur le gestionnaire des configurations ;

? Gestionnaire des configurations

Permet d'utiliser des recettes, faire des déclarations des états de configuration dans lesquels les différents noeuds doivent être, il simplifie l'automatisation et l'orchestration dans l'environnement afin de fournir un déploiement cohérent ;

? Gestionnaire de cycle de vie

Permet de gérer les cycles de vie complets des serveurs physiques et virtuels, de la création d'un hôte et l'installation du système d'exploitation, grâce à une gestion basée sur un gestionnaire des configurations ;

? Base de données

Permet de collectionner les informations sur les différents noeuds gérés en vue d'une consultation future.

2.3. Conception détaillée logique

A ce stade, nous allons faire des zooms sur les différents modules intervenant dans l'architecture décrite au niveau de la conception générale, cela nous permettra de voir comment les modules interagissent entre eux, leurs constitutions, etc., tout cela dans le but de réduire le niveau d'abstraction appliqué au niveau de la conception générale.

2.3.1. Serveur de noms

Dans les réseaux de données, les périphériques sont identifiés par des adresses IP numériques pour l'envoi et la réception de données sur les réseaux, il est difficile de retenir ces adresses numériques, pour cette raison, des noms de domaines ont été créés pour convertir les adresses numériques en noms simples et explicites grâce au protocole servant à la résolution des noms.

Le protocole DNS²⁸ définit un service automatisé qui associe les noms des ressources à l'adresse réseau numérique requise. Il comprend le format des demandes, des réponses et des données. Les communications via ce protocole utilisent un format unique nommé message. Ce format de message est utilisé pour tous les types de demandes clientes et de réponses serveurs. [17, Chap. 5]

²⁷ Secure Sockets Layer, actuellement Transport Layer Security, est un protocole de sécurité d'échange sur internet.

²⁸ Domain Name Service ou système de noms de domaine, est un service permettant de traduire un nom de domaine en informations de plusieurs types qui y sont associées, notamment en adresse IP de la machine portant ce nom.

TFE_ESIS_AS 2016

31

CONCEPTION GENERALE ET DETAILLEE LOGIQUE

Le serveur DNS stocke différents types d'enregistrements des ressources utilisées pour résoudre les noms. Ces enregistrements contiennent le nom, l'adresse et le type d'en-registrement.

Certains de ces types d'enregistrements sont les suivants :

· A

Sont des enregistrements qui font des mappages entre un nom d'hôte et une adresse IPv4. Ils représentent généralement la majorité des enregistrements de ressources des zones de recherches directes ;

· CNAME (Canonical NAME)

Sont des enregistrements entre un nom d'hôte et un autre nom d'hôte. Ils permettent de créer des alias pour un nom d'hôte donné c'est-à-dire plusieurs noms d'hôte à une même machine ;

· MX (Mail eXchanger)

« Définition d'un serveur de courrier électronique, information exploitée par les serveurs de messagerie pour retrouver le serveur correspondant à l'adresse de destination d'un courrier électronique. Chaque enregistrement MX a une priorité associée. Le serveur de plus haute priorité (portant le nombre le plus petit) recevra les connexions SMTP²⁹. S'il ne répond pas, le deuxième serveur sera contacté, etc. » cf. [18, p. 177] ;

· PTR (Pointeur)

Correspondance adresse IP vers un nom. Elle est stockée dans une zone dédiée à la résolution inverse, nommée en fonction de la plage d'adresses IP ;

· AAAA

Sont des enregistrements qui font les mappages entre un nom d'hôte et une adresse IPv6 ;

· NS (Name Server)

Sont les enregistrements qui identifient les serveurs DNS de la zone DNS. Ils sont utilisés dans le cadre de la délégation DNS.

Lorsqu'un client envoie une requête, le processus de résolution du serveur cherche d'abord dans ses propres enregistrements pour résoudre le nom. S'il n'est pas en mesure de résoudre le nom à l'aide de ses enregistrements stockés, il contacte d'autres serveurs DNS.

Voici un schéma simple qui explique la requête de résolution de nom d'un client vers le serveur DNS en passant par le réseau :

²⁹ Simple Mail Transfert Protocol (Protocole Simple de Transfert des Courriers) est le protocole standard permettant de transférer les courriers d'un serveur à un autre en connexion point à point.

TFE_ESIS_AS 2016

32

CONCEPTION GENERALE ET DETAILLEE LOGIQUE

^réseau

^DNS

^client

^Serveur

Figure 2.3 interaction entre un client et le serveur DNS

La requête peut être transmise à plusieurs serveurs, cela nécessite un délais supplémentaire et consomme la bande passante³⁰. Lorsqu'une correspondance est trouvée, elle et retournée au serveur demandeur d'origine, le serveur stocke temporairement dans la mémoire cache³¹ l'adresse numérique correspondant au nom. Si ce même nom est de nouveau demandé, le premier serveur peut retourner l'adresse en utilisant la valeur stockée dans sa mémoire cache de noms.

La structure d'attribution de noms est subdivisée en petites zones générales. Chaque serveur DNS tient à jour un fichier de base de données spécifique et se charge uniquement des mappages entre noms et adresses IP dans cette partie de la structure globale. Lorsqu'un serveur DNS reçoit une demande de traduction d'un nom qui n'appartient pas à sa zone de traduction, le serveur de noms transfère la requête à un autre serveur de noms se trouvant dans la zone de traduction voulue.

2.3.2. Serveur d'attribution automatique d'adresse IF

Il permet de rapatrier automatiquement la configuration pour un client qui vient de démarrer et souhaitant configurer son interface réseau. De cette façon, on centralise la gestion des configurations réseau et tous les clients de l'infrastructure pourront recevoir des réglages identiques.

Le serveur DHCP³² va fournir des nombreux paramètres réseau, notamment une adresse IP et le réseau d'appartenance de la machine. Mais il peut aussi indiquer d'autres informations, telles que le serveur de résolution des noms « DNS », la passerelle par défaut, etc. [18, p. 179]

L'acquisition d'une adresse IP à partir du serveur DHCP se fait en passant par 4 étapes comme l'indique le diagramme ci-dessous :

³⁰ Quantité de données transmises par unité de temps.

³¹ La mise en cache réduit le trafic réseau de données de demandes de résolution des noms et les charges de travail des serveurs situés aux niveaux supérieur dans la hiérarchie.

³² Dynamic Host Configuration Protocole (Protocole de Configuration Dynamique d'Hôte) est un protocole de communication utilisé pour gérer les informations de configuration de façon centralisée.

33

CONCEPTION GENERALE ET DETAILLEE LOGIQUE

^client

^1.DISCOVERY

^DHCP

^2.OFFER

^3.REQUEST

^4.ACK

TFE_ESIS_AS 2016

^Serveur

Figure 2.4 processus d'acquisition d'une adresse IP via le serveur DHCP

Comme le montre le diagramme ci-haut, lorsqu'un client configuré pour recevoir automatiquement une adresse IP démarre ou se connecte au réseau, le client diffuse un message de détection (DHCP DISCOVERY) pour identifier le serveur DHCP disponible sur le réseau. Le serveur DHCP répond par un message d'offre de configuration IP (DHCP OFFER), ce message contient l'adresse IP et le masque de sous réseau à attribuer, l'adresse IP du serveur de résolution des noms et l'adresse de la passerelle par défaut. L'offre de bail indique également la durée du bail.

Le client peut recevoir plusieurs messages DHCPOFFER au cas ou dans le réseau nous disposons de plusieurs serveurs d'attribution automatique d'adresse. Il doit donc opérer un choix et envoyé une requête DHCPREQUEST qui identifie de façon explicite le serveur DHCP et l'offre de bail qu'il accepte. Le client peut également choisir de demander une adresse que le serveur lui avait attribué précédemment. [17, Chap. 5]

S'il arrive que l'adresse IP demandée par le client ou celle offerte par le serveur est encore disponible, le serveur renvoie un message d'accusé de réception (DHCPACK) confirmant au client que le bail est conclu. Si l'offre n'est plus valide, le serveur sélectionné répond par un message d'accusé de réception négatif (DHCPNACK). Si ce dernier est retourné, le processus de sélection doit recommencer avec la transmission d'un nouveau message DHCPDISCOVERY et une fois que le client a obtenu le bail, ce dernier doit être renouvelé avant son expiration via une autre requête DHCPREQUEST. [17, Chap. 5]

Le serveur DHCP garantit que toutes les adresses IP sont uniques (une adresse IP ne peut pas être attribuée à deux périphériques réseau différents en même temps). Le protocole DHCP permet de reconfigurer aisément les adresses IP des clients sans devoir apporter des modifications manuelles aux clients.

2.3.3. Serveur des fichiers

Le protocole TFTP utilise le protocole UDP, il ne sécurise pas le moins du monde les échanges, dans notre système il est utilisé pour booter les systèmes sur le réseau via

TFE_ESIS_AS 2016

34

CONCEPTION GENERALE ET DETAILLEE LOGIQUE

le serveur PXE³³ qui fait partie de ce module, il est en interaction avec le serveur TFTP et le serveur DHCP qui sont tous des proxys intelligents pour le gestionnaire de cycle de vie.

Une première étape essentielle dans l'amorçage d'un système consiste à préparer le serveur TFTP avec le fichier de configuration PXE et l'image de démarrage, cela présuppose que nous avons déjà configuré notre proxy intelligent DHCP pour l'attribution d'adresse IP, ainsi pour le début d'un nouveau système à partir du PXE se passera de cette façon :

? Le boot d'accueil avec le protocole PXE ;

? L'hôte envoie une diffusion à la recherche d'un serveur DHCP qui peut gérer les demandes PXE ;

? Le serveur DHCP (proxy intelligent) répond et donne une adresse IP au client ;

? Le serveur PXE sera contacté, il connait la route vers le serveur TFTP ;

? Le serveur TFTP détient une image de démarrage pour l'hôte. 2.3.4. Signature des certificats

La signature de certificats est un processus essentiel du gestionnaire des configurations visant à renforcer la sécurité du serveur maître et de ses données.

Le gestionnaire des configurations utilise SSL comme protocole de transport en-crypté pour protéger les communications entre les clients et le maître. Les certificats des clients doivent être signés par le maître pour que la communication soit possible. Il y a donc un peu de gestion associée à ces certificats. Cela permet de satisfaire les objectifs de sécurité suivant :

? De manière optionnelle, l'authentification du client parce que dans la réalité celle-ci sera assuré par le serveur maître ;

? La confidentialité des données échangées (session chiffrée) ; ? L'intégrité des données échangées.

Quand on branche un nouveau client au maître, celui-ci va automatiquement générer son propre certificat ainsi qu'une demande de signature de certificat (CSR³⁴), qui seront communiqué au serveur maître.

Par défaut, le client quittera ensuite puisque la communication ne peut pas être établie tant que le maître n'aura pas signé le certificat du client. Voici un diagramme expliquant la procédure de signature de certificat par le maître :

³³ Pre-boot eXecution Environment, permet à une station de travail de démarrer depuis le réseau un système d'exploitation qui se trouve sur un serveur.

³⁴ Certificate Signing Request (demande de signature de certificat), est un message envoyé à partir d'un demandeur à une autorité de certification afin de demander un certificat d'identité numérique.

35

CONCEPTION GENERALE ET DETAILLEE LOGIQUE

^client				^CSR				^Maître		^(CA)
		^Certificat SSL Client Signé

TFE_ESIS_AS 2016

^{Autorité de}

^{certification}

Figure 2.5 processus de signature du certificat d'un client

Le client doit d'abord attendre un certain temps pour que cette signature ait lieu, cela peut se faire moyennant des commandes.

Durant cette première exécution du client, celui-ci doit donner des informations sur la signature du certificat qu'il aura créé.

Dans certaines situations, on peut vouloir modifier le certificat du maître (celui que les clients vérifieront lors de la communication afin de s'assurer que le lien établi est bel et bien originaire du bon endroit). Ces cas peuvent inclure l'utilisation d'un FQDN³⁵ additionnel pour la communication client/maître, ou tout simplement la correction de la liste des noms des domaines valable pour le maître. Nous pouvons modifier le certificat du maître sans avoir à résigner tous les certificats des clients, aussi longtemps que le nouveau certificat du maître est signé avec le même CA³⁶ (il ne faudra donc pas effacé le CA du maître durant cette opération).

2.3.5. Gestionnaire des configurations

Le tout fonctionne sur un modèle client-serveur, le serveur est appelé maître. Nous définissons sur celui-ci les différentes configurations qui sont décrites dans des classes, ceci fait référence aux concepts de la programmation orientée objet énoncés au niveau de la conception générale, les différentes configurations décrites sont appelées configurations de référence qui sont en fait les états dans lesquels on souhaite retrouver le système. Les clients, via des agents, vont entreprendre les actions nécessaires pour correspondre à cet état.

L'agent doit donc faire en sorte que la machine ait à tout moment le même état définit sur la configuration de référence.

De façon plus détaillée, voici comment se représente les interactions entre les clients et le gestionnaire des configurations :

³⁵ Fully Qualified Domain Name (Nom de Domaine Complètement Qualifié), est une adresse de nom de domaine entière, y compris le nom d'hôte, et le haut-niveau du domaine.

³⁶ Certificate Authority (Autorité de certification) est un tiers de confiance permettant d'authentifier les identités des correspondants.

36

CONCEPTION GENERALE ET DETAILLEE LOGIQUE

^configurations			^Attribution de certificat

^{Echange de catalogue}

^{Echange de catalogue}

^{Demande de certificat}

^Client

^Client

TFE_ESIS_AS 2016

^{Echange de catalogue}

^Client

^{Gestionnaire des}

Figure 2.6 interaction entre le gestionnaire des configurations et les clients Caractéristiques principales du client :

· Consommateur des services ;

· Proactif ;

· À l'origine de la demande. Caractéristiques du serveur :

· Fournisseur des services ;

· Réactif ;

· Traitement de plusieurs clients simultanément ;

· Contrôle d'accès ;

· Garant de l'intégrité globale.

Le serveur maître contient la configuration commune et les points de différence entre les clients, ces derniers font tourner des agents qui :

· Appliquent les configurations initiales pour les noeuds concernés ;

· Appliquent les nouveautés de configuration au fil du temps ;

· S'assurent de manière régulière que la machine correspond bien à la configuration voulue.

Le serveur maître sait servir :

· Des recettes de configuration ;

· Des fichiers ;

· Des modèles (qui sont des fichiers avec des variables de remplacement).

Le logiciel client est appelé un « agent », et l'hôte lui-même ainsi que les agents sont définis comme des « noeuds ». Le maître s'exécute comme un démon sur un hôte et contient la configuration requise pour l'environnement. Les agents se connectent au maître via une connexion cryptée qui utilise le standard SSL. Il est important de préciser que si l'agent a déjà la configuration requise, rien ne se passera, cela signifie que le maître appliquera seulement les changements sur l'environnement s'ils sont nécessaires. L'en-semble de ces processus est appelé une « exécution de configuration ». Par défaut, l'agent vérifiera toutes les 30 minutes le maître afin de voir si des modifications doivent être effectuées. Cet intervalle de temps sera bien sûr paramétrable.

TFE_ESIS_AS 2016

37

CONCEPTION GENERALE ET DETAILLEE LOGIQUE

En somme, voici comment se passe le processus de gestion des configurations :

^Client ^(agent)

^Requête du client

^Maître

^Catalogues des ordres

^Compte rendu

Figure 2.7 processus de gestion des configurations

L'outil de gestion des configurations peut recueillir beaucoup des faits sur un hôte, comme la taille de la mémoire, le fuseau horaire, le type de processeur, l'environnement dans lequel l'hôte travaille et beaucoup d'autres informations, une fois ces faits recueillis, l'outil de gestion des configurations peut les envoyés au gestionnaire de cycle de vie.

2.3.6. Gestionnaire de cycle de vie

Le gestionnaire de cycle de vie est étroitement lié au gestionnaire des configurations, il peut fonctionner comme un noeud classificateur externe pour le gestionnaire des configurations et comme outil de génération des rapports. Il présente une alternative au système d'inventaire, et surtout, il peut gérer l'ensemble du cycle de vie du système, de l'approvisionnement à la configuration jusqu'au déclassement.

Un cycle de vie complet d'une machine se compose des étapes suivantes : ? L'installation du système d'exploitation ;

? L'installation et la configuration des autres progiciels, ainsi que la configuration des utilisateurs et des groupes par exemple ou les interfaces réseau ;

? Mise à jour, gestion et vérification : l'installation des correctifs et/ou le changement de la configuration des serveurs et enfin la surveillance sur toute la durée de vie.

Le gestionnaire de cycle de vie nous aide exactement au point d'installer automatiquement un système d'exploitation. Après cela, grâce à une très bonne intégration avec le gestionnaire des configurations, de cette façon le nouveau système sera configuré en fonction du cahier de charge. Enfin, le gestionnaire des configurations envoie des faits sur le système de gestion de cycle de vie qui nous permet de suivre l'ensemble du système sur sa durée de vie complète. Avec un plugin de découverte, le gestionnaire de cycle de

TFE_ESIS_AS 2016

38

CONCEPTION GENERALE ET DETAILLEE LOGIQUE

vie peut aussi découvrir de nouvelles machines de l'infrastructure en fonction de leur adresses MAC³⁷.

Les serveurs DHCP, DNS et TFTP définis dans l'architecture au niveau de la conception générale (module d'attribution automatique d'adresse IP, module du serveur de noms, le module du serveur des fichiers ainsi que le module pour la signature des certificats) constituent des proxy intelligents nous permettant d'aider à orchestrer le processus aux systèmes de fourniture.

Comme mentionné sur le point précèdent concernant le gestionnaire des configurations, il recueille des différents faits sur les hôtes, ces faits peuvent ensuite être utiliser à l'intérieur du gestionnaire de cycle de vie pour déterminer les paramètres avec lesquels il faudra installer un logiciel. Par exemple, cela pourrait aider le gestionnaire des configurations et le gestionnaire de cycle de vie pour décider si un serveur web pourrait fonctionner sur un certain système sur le port 80 ou 8080. Le gestionnaire de cycle de vie agit comme un noeud classificateur externe pour le gestionnaire des configurations.

2.3.7. Base de données

La base de données vient s'intégrer au gestionnaire de cycle de vie pour collectionner ou sauvegarder les différents faits et paramètres que le gestionnaire des configurations envoi au gestionnaire de cycle de vie. Cela permet plusieurs consultations à la demande au niveau du gestionnaire de cycle de vie et une conservation efficace des informations en rapport avec tous les noeuds de l'infrastructure gérée par le gestionnaire des configurations.

2.4. Conclusion partielle

Dans cette partie du travail, il était question de faire la conception générale qui nous a permis de définir l'architecture générale du système, la conception logique détaillée quant à elle, nous a permis de faire des zooms sur les différents modules qui composent l'architecture générale du futur système, ces zooms ont eu pour mission de faire voir la façon dont les différents modules interagissent avec le reste du système afin de réduire l'abstraction à un niveau moyen. La seconde partie de notre conception réduit l'abstrac-tion au niveau le plus bas possible.

³⁷ Medium Access Control (sous couche de contrôle d'accès) est parfois appelé adresse physique, c'est un identifiant matériel unique en hexadécimal propre à chaque périphérique réseau.

TFE_ESIS_AS 2016

CHAPITRE 3: CONCEPTION TECHNIQUE

3.1. Introduction

La conception générale nous a permis de ressortir l'architecture générale de notre système, la conception détaillée logique quant à elle, nous a permis de détailler chacun des modules composant l'architecture générale de notre système. La solution ainsi conçue (globalement et en détail) peut être alors réalisée dans les technologies disponibles.

3.1.1. Niveau d'abstraction

A ce stade, nous avons déjà franchi la conception générale et la conception détaillée logique, nous sommes arrivés au plus bas niveau d'abstraction de notre conception.

Figure 3.1 niveau d'abstraction de la conception technique

3.2. Choix technologiques 3.2.1. Critères de choix

Les choix des différentes solutions technologiques ne seront pas faits de façon arbitraire, nous allons faire recours à la première partie de notre travail et plus précisément au niveau des spécifications des besoins non fonctionnels, ces dernières vont constituer nos critères de choix pour différentes solutions technologiques, chaque critère vaut 5 points, ce qui fera un total de 45 points vu leur nombre qui est de 9. Les solutions qui seront retenues seront celles qui auront les plus grandes cotes sur 45.

TFE_ESIS_AS 2016

40

CONCEPTION TECHNIQUE

Voici donc nos critères de choix :

Critère 1 (C1) : Utilisabilité, nous voyons la capacité pour un utilisateur d'exécu-ter une tâche dans un temps donné après une formation d'une durée déterminée ;

Critère 2 () : Stabilité, nous voyons par là un système qui, une fois écarté de sa position d'équilibre, il tend à y revenir ;

Critère 3 (C3) : Performance, représente la capacité du système à avoir un temps d'attente moindre (moins de 10 secondes) ;

Critère 4 (C4) : Disponibilité, représente la capacité du système à tourner avec un temps d'arrêt très réduit ;

Critère 5 (C5) : Sécurité, nous voyons un système dont l'accès est personnalisé et les connexions sécurisées ;

Critère 6 (C6) : Portabilité, c'est la capacité d'un système d'être utilisable avec plusieurs systèmes d'exploitation (plateformes) ;

Critère 7 (C7) : Simplicité de mise en place, exprime la qualité du système d'être facile à implémenter ;

Critère 8 (C8) : Fiabilité, nous voyons par là un système critique, un système dont la probabilité d'avoir des défaillances pendant le temps de fonctionnement est moindre ;

Critère 9 (C9) : coût, nous voyons une solution efficace pouvant être implémentée avec un budget minimum.

Pour le choix de certaines solutions technologiques, nous ne nous baserons pas que sur les neuf critères de choix mais plutôt sur quelques critères qui seront déterminant et dans certains cas nous donnerons juste les raisons qui nous ont motivé à choisir une technologie par rapport à une autre.

3.2.2. Choix du gestionnaire des configurations

Pour le choix du gestionnaire des configurations, plusieurs solutions existent à l'heure actuelle, néanmoins nous avons retenu quatre solutions technologiques, à savoir Chef, System Center Configuration Manager (SCCM), Cfengine et Puppet.

Tableau 3.1 cotations des gestionnaires des configurations

Critères	C1		C3	C4	C5	C6	C7	C8	C9		Total	Chef
3	3,5	4	3,5	3	3	2	3,5	4	29,5		SCCM
3	3,5	4	3,5	3	3	2	3,5	2	27,5		Cfengine
3	3,5	4	3,5	3	3	2	3,5	4	29,5		Puppet
4	3,5	4	3,5	3	3	2,5	3,5	4	31

Voici la représentation de ce tableau sous forme des graphiques et courbes afin de permettre une très bonne vision :

TFE_ESIS_AS 2016

41

CONCEPTION TECHNIQUE

4,5

4 3,5 3 2,5 2 1,5 1 0,5 0

Figure 3.2 diagramme en bâtons

Chef SCCM Cfengine Puppet

35 30
		25 20 15 10 5 0

Figure 3.3 diagramme en courbes

La solution technologique pour la gestion des configurations retenue est donc Puppet qui l'emporte sur les autres avec un total de 31 points sur 45 et elle intègre en elle un module de signature de certificat.

3.2.2.1. Présentation de Puppet

Puppet est un logiciel open source comportant les outils nécessaires à la configuration des systèmes informatiques. Il s'appuie sur un langage de programmation « Ruby » et est sous licence GPL v2. Il a été principalement développé par Luke KANIES et son entreprise Puppet Labs.

« KANIES a développé puppet grâce à son expérience dans les systèmes Unix et les systèmes d'administration depuis 1997. Non satisfait des outils de configuration existants, il

TFE_ESIS_AS 2016

42

CONCEPTION TECHNIQUE

a commencé à travailler avec des outils de développement en 2001, et a fondé Puppet Labs en 2005, une entreprise de développement open source basée sur les outils d'auto-matisation. Peu de temps après, Puppet Labs sort son nouveau produit phare : Puppet. Il peut être utilisé pour gérer la configuration d'application sous Unix et OSX, ainsi que Linux et Windows ». Cf. [16, p. 11]

^Admin

^Client

^{Echange de catalogue}

^SSH

^HTTPS

^{Puppet Master}

^{Demande de certificat}

^{Echange de catalogue}

^{Attribution de certificat}

^{Tableau de}

^bord

^Client

^{Echange de catalogue}

^Client

Figure 3.4 principe d'utilisation de puppet Son modèle est basé sur trois piliers :

? Le déploiement ;

? Un langage de configuration et une couche d'abstraction ; ? Sa couche transactionnelle.

3.2.2.2. Fonctions principales de Puppet

Etant un outil de déploiement et de gestion automatisée de configurations et des systèmes informatiques. Il repose sur un modèle client/serveur : un serveur central sert de dépôt des configurations, les systèmes clients (noeuds) se mettent à jour de manière manuelle ou automatique.

Avec Puppet, l'administrateur n'écrit pas un ensemble d'opérations à exécuter sur les différents noeuds sous la forme d'un script, l'administrateur décrit l'état final de la machine dans un manifest, ce qui l'affranchit de la connaissance des commandes propres à chaque système d'exploitation pour arriver à cet état. Le client puppet peut être exécuté plusieurs fois, les changements seront opérés seulement si l'état de la machine ne correspond pas à celui désiré.

TFE_ESIS_AS 2016

43

CONCEPTION TECHNIQUE

^{Configuration}

^language

^{Transaction Layer}

^{Abstraction Layer}

^Ressources

Figure 3.5 fonctions principales de puppet

Puppet utilise son propre langage de déclaration pour définir les points de configuration qui sont écrits dans une « ressource », ce qui le distingue d'autres outils de gestion des configurations. Ce langage permet de déclarer si un package doit être installé ou si un service doit être lancé par exemple.

La plupart des outils de gestion des configurations (script shell ou pearl par exemple) sont procéduraux. Ils décrivent comment les choses doivent être faites plutôt que de se focaliser sur l'état final attendu. Les utilisateurs de puppet ont juste besoin de déclarer l'état final voulu de ses hôtes : les packages à installer, les services à exécuter, etc. Avec puppet, l'administrateur n'attache pas d'importance sur comment ces actions vont être faites.

Le moteur de puppet est sa couche transactionnelle, une transaction puppet : ? Interprète et compile la configuration ;

? Communique la configuration compilée à l'agent ; ? Applique la configuration sur l'agent ;

? Rapporte le résultat de cette application au Master.

La première étape de puppet est celle d'analyser la configuration et de calculer comment l'appliquer sur l'agent. Pour cela, puppet crée un graphique représentant toutes les ressources, ainsi que leurs relations entre elles et chaque agent. Puis il applique chaque ressource sur un hôte. Ce qui est en fait une des caractéristiques les plus puissantes de puppet.

Deuxièmement, puppet se sert des ressources et les compile dans un catalogue pour chaque agent. Le catalogue est envoyé à l'hôte et appliqué par l'agent puppet. Les résultats de cette application sont renvoyés au Master sous forme de rapport.

La couche transactionnelle permet aux configurations d'être créées et appliquées indéfiniment sur un hôte. Ceci est appelé « idempotent », cela signifie que des multiples applications de la même opération donneront le même résultat. Une configuration de puppet peut être exécutée plusieurs fois sur un hôte en toute sécurité avec le même résultat, assurant ainsi à la configuration de rester compatible.

3.2.2.3. Manifests

Pour que Puppet fonctionne, nous devons lui dire quoi faire. Ceci se fait grâce aux manifests.

TFE_ESIS_AS 2016

44

CONCEPTION TECHNIQUE

Les programmes de Puppet sont appelés « manifests », et ils utilisent l'extension de fichier .pp. Le coeur du langage Puppet est la déclaration des ressources, qui représente l'état désiré d'une ressource.

Les manifests peuvent également utiliser des instructions conditionnelles, un groupe des ressources dans des collections, générer du texte avec des fonctions, référencer du code dans d'autres manifests, et tant d'autres choses, mais tout revient en dernière analyse à faire en sorte que les bonnes ressources soient gérées de la bonne manière.

Avant d'être appliqués, les manifests sont compilés dans le catalogue, qui est un graphe acyclique dirigé qui ne présente que les ressources et l'ordre dans lequel elles doivent être synchronisées. Toute la logique conditionnelle, la recherche de données, l'in-terprétation de variables, et le regroupement de ressources calculent l'écart lors de la compilation.

Parmi les manifests deux sont importants. Lorsque le client consultera le Puppet Master, l'agent lira les fichiers dans un certain ordre :

· Le fichier /etc/puppet/environnement/nom-environnement/nom-du-mo-dule/manifests/site.pp qui dit à Puppet où et quelle configuration charger pour les clients. C'est également dans ce fichier que nous ferons la déclaration des ressources, on spécifiera également d'importer les « noeuds » ;

· Le fichier /etc/puppet/nom-environnement/nom-du-module/mani-fest/node.pp est lu lors de l'import. Dans ce fichier, nous renseignons les FQDN des clients ainsi que les modules qui leurs sont associés.

3.2.2.4. Ressources

Une ressource est un élément que Puppet sait configurer [19, p. 53] :

· File (contenu, permissions, propriétaire) ;

· Package (présence ou absence) ;

· Service (activation/désactivation, démarrage/arrêt) ;

· Cron, group, host, user, etc.

Dans Puppet chaque ressource est identifiée par un nom, elle est composée d'un certain nombre d'attributs qui ont chacun une valeur.[20, p. 21]

3.2.2.5. Modules

Un module est une collection des manifests, ressources, fichiers, templates, classes et définitions. Un simple module contiendra tout ce qui est requis pour configurer une application particulière. Chaque module a besoin d'une structure de répertoire spécifique et d'un fichier appelé « init.pp ». Cette structure autorise Puppet à charger automatiquement les modules. Pour accomplir ce chargement automatique Puppet vérifie une série de répertoires appelée le chemin du module (en anglais module path). Ce chemin est configuré avec l'option de configuration du module path dans la section [main] de « pup-pet.conf ».

TFE_ESIS_AS 2016

45

CONCEPTION TECHNIQUE

Par défaut, Puppet recherche les modules dans /etc/puppet/modules et /var/lib/puppet/modules. Si nécessaire on peut rajouter d'autres chemins.

Un module est défini de la façon suivante :

1. /etc/puppet/environnement/nom-environnement/nom-du-module/mani-fests/ :

· Le répertoire manifests contiendra le fichier init.pp et tout autre configuration;

· Le fichier init.pp est le coeur du module et chaque module doit en avoir un ;

· Dans le fichier init.pp nous retrouvons des classes qui seront instanciées lors de l'appel d'un agent. Dans ces classes on retrouve les configurations de référence.

2. /etc/puppet/environnement/nom-environnement/nom-du-module/files/ :

Le répertoire files contiendra tous les fichiers que l'on souhaite utiliser comme une partie du module, par exemple des fichiers à uploader.

3. /etc/puppet/environnement/nom-environnement/nom-du-module/tem-plates/ :

Le répertoire « templates » contiendra tous les templates que le module pourrait utiliser.

3.2.3. Choix du gestionnaire de cycle de vie

Le choix du gestionnaire de cycle de vie a été porté sur Foreman « le contre maitre », il est gratuit, open source, facile à mettre en place, bénéficie d'une grande communauté et une grande documentation, il s'intègre bien avec la majorité des gestionnaires des configurations.

Foreman offre les avantages ci-après [21]:

· Installation simple et automatique, il crée les fichiers de configuration d'Apache, VHosts et tous les fichiers nécessaires à son exécution ;

· Il peut être utilisé pour configurer les noeuds, attribuer des classes et définir les paramètres des classes ;

· Donne des rôles sur la base de données ;

· Offre une section des rapports avec des graphiques montrant des détails comme les distributions de système d'exploitation, pourcentage, les mémoires et architectures.

3.2.3.1. Présentation de Foreman

Foreman est un outil Open Source de gestion du cycle de vie des serveurs physiques ou virtuels. De l'installation à la mise à jour en continu, tout en passant par la configuration initiale de la machine, Foreman s'occupe du cycle de vie de la machine. Foreman peut traiter les rapports venant d'une, ou plusieurs, instances Puppet. Il peut

TFE_ESIS_AS 2016

46

CONCEPTION TECHNIQUE

fonctionner sur la plupart des systèmes d'exploitation d'aujourd'hui. Cela, que ce soit avec une infrastructure sur site ou dans le Cloud, privé ou public.

3.2.3.2. Fonctionnement

Foreman utilise un système des proxys intelligents pour lancer ses actions sur les différents hôtes, il envoie ses requêtes aux proxys intelligents exécutant les différentes actions telles que l'allocation d'adresse, la gestion des appels puppet, etc. Il nourrit une base de données et produit des rapports avec les informations données par puppet et le tout est pilotable via une interface web.

^Admin

^{Puppet Master}

^{Attribution de certificat}

^{Echange de catalogue}

^{Echange de catalogue}

^Client

^Client

^SSH

^Foreman

^{communication}

^{Demande de certificat}

^HTTPS

^{Echange de catalogue}

^Client

Figure 3.6 fonctionnement de Foreman avec Puppet 3.2.4. Architecture niveau physique

Après avoir effectué les différents choix, nous avons retenu comme solutions technologiques à mettre en place dans notre système : Puppet comme outil de gestion des configurations, Foreman sera notre gestionnaire de cycle de vie qui contient en son sein une base de données PostgreSQL, des proxy intelligents (TFTP, DHCP, DNS).

Voici ce qu'est l'architecture du système avec les différentes solutions technologies citées ci-haut :

TFE_ESIS_AS 2016

47

CONCEPTION TECHNIQUE

^{Serveur DHCP}

^{Serveur TFTP}

^PostgreSQL

^{Serveur DNS}

^{Puppet CA}

^Puppet

^Foreman

Figure 3.7 architecture générale du système au niveau physique

3.3. Procédures et planification

3.3.1. Procédures d'installation

Plan sommaire :

· Procédure d'installation de puppet et foreman sur le serveur ;

· Test d'installation de puppet et foreman sur le serveur ;

· Procédure d'installation de l'agent puppet sur le client sous Ubuntu 14.04.2 LTS ;

· Procédure d'installation de l'agent puppet sur le client sous CentOS 6.6. 3.3.1.1. Serveur sous Ubuntu 14.04.2 LTS (PROC.INST.3.1)

a. Installation

Installer Puppet master et Foreman sur le serveur via les commandes suivantes en mode root :

· Ouvrir le terminal ;

· Saisir la commande sudo su pour se connecter en tant que root ;

· Saisir le mot de passe root et valider en appuyant sur la touche enter ;

· Saisir successivement les commandes ci-après pour installer les packages de puppet et foreman [22] :

apt-get -y install ca-certificates

wget https://apt.puppetlabs.com/puppetlabs-release-trusty.deb dpkg -i puppetlabs-release-trusty.deb

echo" deb http://deb.theforeman.org/ trusty 1.10"> /etc/apt/sources.list.d/foreman.list

TFE_ESIS_AS 2016

48

CONCEPTION TECHNIQUE

echo "deb http://deb.theforeman.org/ plugins 1.10">> /etc/apt/sources.list.d/foreman.list

wget -q http://deb.theforeman.org/pubkey.gpg -O- | apt-key add - apt-get update && apt-get -y install foreman-installer foreman-installer

b. Test

· L'exécution de la dernière commande (foreman-installer) nous servira de test, dans notre cas nous allons personnaliser l'exécution de cette commande en définissant le login et le mot de passe de connexion à Foreman de cette manière :

foreman-installer -foreman-admin-password=Id2303

Le résultat de cette commande devra être l'impression des informations concernant l'URL³⁸ pour accéder à l'interface web de Foreman qui sera https://kan-srvlub-foreman.kanacad.org, le login qui sera admin et le mot de passe Id2303, l'URL et le port du proxy intelligent qui sera https://kan-srvlub-foreman.kanacad.org:8443 et enfin le port par lequel fonctionne le puppetmaster qui est 8140.

3.3.1.2. Client Ubuntu 14.04.2 LTS (PROC.INST.3.2)

Au niveau de ce client, la procédure sera la suivante :

· Ouvrir le terminal ;

· Se connecter en tant que root en faisant sudo su ;

· Saisir le mot de passe root puis valider ;

· Enfin télécharger le package de l'agent puppet à partir du dépôt d'Ubuntu en passant par la commande apt-get install puppet.

3.3.1.3. Client sous CentOS 6.6 (PROC.INST.3.3)

Sous CentOS la procédure n'est pas trop différente de celle d'Ubuntu, elle se passe de cette façon :

· Ouvrir le terminal ;

· Saisir la commande su pour passer en mode root ;

· Saisir le mot de passe du root et valider ;

· Saisir la commande rpm -ivh http://yum.puppetlabs.com/puppetlabs-re-lease-el-6.noarch.rpm suivi de la commande yum install puppet afin d'installer le package de l'agent puppet. [23]

³⁸ Uniform Resource Locator, en français localisateur uniforme de ressource, désigne une chaîne de caractères utilisée pour une adresser les ressources du World Wide Web.

TFE_ESIS_AS 2016

49

CONCEPTION TECHNIQUE

3.3.2. Procédures de configuration

Il est question ici de montrer les configurations que prendront notre serveur et nos clients, mis à part cela, nous allons montrer les différentes configurations des modules qui seront déployés dans nos environnements.

Plan sommaire :

· Fixer les adresses IP en statique sur les serveurs et même les clients ;

· Editer les fichiers hosts du serveur et des clients ;

· Tester les configurations ;

· Editer les fichiers hostname du serveur ainsi que des clients ;

· Editer les fichiers puppet.conf sur le serveur et sur les clients ;

· Créer les arborescences des modules qui seront déployés sur le serveur (mysql, dhcp et apache), cette arborescence sera fonction de l'environne-ment dans lequel il sera (production ou développement) ;

· Créer les fichiers init.pp, install.pp, config.pp, service.pp, node.pp et site.pp de chaque module ;

· Editer les fichiers fichiers init.pp, install.pp, config.pp, service.pp, node.pp et site.pp de chaque module en fonction des spécification de ce dernier ;

· Créer le domaine ;

· Créer le proxy intelligent ;

· Importer toutes les classes des différents modules au niveau du gestionnaire de cycle de vie foreman ;

· Assigner les modules aux noeuds concernés.

3.3.2.1. Configuration du serveur sous Ubuntu 14.04.2 LTS (PROC.CONF.3.1)

Son adresse IP sera fixée en éditant le fichier interfaces dans le répertoire /etc/net-work et se présentera de la façon suivante :

Figure 3.8 fixation de l'adresse IP du serveur

Le fichier hosts sera édité en faisant nano /etc/hosts et aura comme informations, l'adresse IP du serveur suivi du FQDN du serveur et enfin le nom du serveur. Sur les autres lignes nous mettrons les adresses IP ainsi que les FQDN de tous les noeuds que nous devrons gérer dans notre infrastructure [22]. Ce fichier se présentera comme suit :

TFE_ESIS_AS 2016

50

CONCEPTION TECHNIQUE

Figure 3.9 configuration du fichier hosts du serveur

Le fichier hostname quant à lui sera édité en faisant nano /etc/hostname, c'est dans ce fichier que nous renseignerons le FQDN du serveur [22].

Figure 3.10 configuration du fichier hostname du serveur

Enfin nous éditerons le fichier puppet.conf se trouvant dans puppet, à l'aide de l'éditeur nano, nous ferons nano /etc/puppet/puppet.conf , nous mettrons la ligne show_diff à la valeur true, cela devra ressembler à ceci :

Figure 3.11 configuration du fichier puppet.conf du serveur

Nous allons créer un domaine à partir de l'interface web du gestionnaire de cycle de vie, il faudra d'abord se connecter puis aller sur l'onglet : Infrastructure > Domaines > Nouveau domaine puis saisir le nom kanacad et le nom complet kanacad.org puis valider.

TFE_ESIS_AS 2016

51

CONCEPTION TECHNIQUE

Figure 3.12 création du domaine

Enfin nous créerons le proxy intelligent, il faudra être connecté sur l'interface web du gestionnaire de cycle de vie, aller sur l'onglet Infrastructure > Smart proxies > Nouveau smart proxy puis saisir le nom du proxy intelligent (kanacad) et son URL et port ( https://kan-srvlub-foreman.kanacad.org:8443).

Figure 3.13 création du proxy intelligent

3.3.2.2. Configuration du client sous Ubuntu 14.04.2 LTS (PROC.CONF.3.2)

Dans le fichier interfaces nous renseignerons les configurations IP via la commande nano /etc/network/interfaces, cela se présente comme suit :

Figure 3.14 fixation de l'adresse IP du client Ubuntu

Dans son fichier hosts via la commande nano /etc/hosts, nous renseignerons l'adresse IP du serveur, son FQDN, son nom et aussi l'adresse IP du client, son FQDN et son nom comme le montre la figure suivante :

TFE_ESIS_AS 2016

52

CONCEPTION TECHNIQUE

Figure 3.15 configuration du fichier hosts du client Ubuntu

Dans le fichier hostname, nous renseignerons le FQDN du client comme suit :

Figure 3.16 configuration du fichier hostname du client Ubuntu

Moyennant la commande nano /etc/puppet/puppet.conf, nous éditerons le fichier de configuration de notre client puppet en spécifiant le FQDN du serveur maître de la façon suivante :

Figure 3.17 configuration du fichier puppet.conf du client Ubuntu

3.3.2.3. Configuration du client sous CentOS 6.6 (PROC.CONF.3.3)

Fixer son adresse IP en éditant le fichier ifcfg de l'interface eth0 moyennant la commande nano /etc/sysconfig/network-scripts/ifcgf-eth0, ce qui donnera le résultat suivant :

TFE_ESIS_AS 2016

53

CONCEPTION TECHNIQUE

Figure 3.18 fixation de l'adresse IP du client CentOS

Editer le fichier hosts, pour y insérer l'adresse IP du serveur et de notre client ainsi que leurs FQDN, cela se fait via la commande nano /etc/hosts et se présente comme suit :

Figure 3.19 configuration du fichier hosts du client CentOS

Spécifier le FQDN du client en éditant son fichier network en faisant nano /etc/sysconfig/network, le fichier se présentera comme suit :

Figure 3.20 configuration du fichier network du client CentOS

Enfin nous nous mettrons à configurer son fichier puppet.conf afin de spécifier le FQDN de notre serveur en faisant nano /etc/puppet/puppet.conf, ce fichier devra ressembler à ceci :

TFE_ESIS_AS 2016

54

CONCEPTION TECHNIQUE

Figure 3.21 configuration du fichier puppet.conf du client CentOS 3.3.2.4. Tests des configurations des paramètres IP

Nous allons dans un premier temps tester les configurations des paramètres IP du serveur, du premier client et du deuxième moyennant la commande ifconfig, le résultat de ce test devra être l'affichage des paramètres IP tels que l'adresse IP de l'hôte concerné, le masque ainsi que l'adresse de broadcast du réseau.

Deuxièmement, nous allons vérifier que les hostname de tous les noeuds correspondent bien à ce qui a été décrit dans leurs configurations, ce test se fera en faisant Ping $(hostname -f). Le résultat devra être par exemple pour le client kan-node1.kanacad.org :

Figure 3.22 résultat attendu après test de l'hostname

3.3.2.5. Module MySQL

Nous allons premièrement créer une arborescence pour notre module, ce dernier aura trois répertoires à savoir : files, templates et manifests. La commande pour créer cette arborescence est : mkdir -p /etc/puppet/environnement/production/mo-dules/mysql/{files, templates, manifests}, ensuite nous créerons le fichier init.pp avec la commande : touch /etc/puppet/environnement/production/modules/mysql/mani-fests/init.pp.[17, p. 19]

TFE_ESIS_AS 2016

55

CONCEPTION TECHNIQUE

Une fois l'arborescence créée nous nous mettrons à éditer le fichier init.pp en important les autres fichier de configuration à savoir install.pp, config.pp et service.pp et ensuite créer une classe mysql et y ajouté les classes incluses comme suit :

Figure 3.23 configuration du fichier init.pp du module MySQL

Le fichier init.pp contiendra une seule classe appelée mysql. A cela, on y ajoutera trois fichiers install.pp, config.pp et service.pp contenant respectivement les classes mysql::install, mysql::config et mysql::service. La classe mysql demande au puppetmas-ter d'exécuter les classes incluses.

Les trois fichiers devront se trouver dans le même répertoire que le fichier init.pp. Le premier fichier (install.pp) s'assurera que les paquets MySQL-server, MySQL-client et Phpmyadmin sont bien installés.

Figure 3.24 configurations du fichier install.pp du module MySQL

Il nous permettra aussi de créer un utilisateur MySQL et un groupe MySQL auquel on donne les droits administrateurs sur MySQL.

Le second fichier, config.pp, utilisera la class mysql::config. Cette dernière sera une classe de type « ressource fichier ». Elle permettra de copier un fichier de configuration de MySQL prédéfinie.

TFE_ESIS_AS 2016

56

CONCEPTION TECHNIQUE

Figure 3.25 configuration du fichier config.pp du module MySQL

Le troisième fichier importé, service.pp servira à vérifier si le service récemment installé fonctionne ou est démarré.

Figure 3.26 configuration du fichier service.pp du module MySQL

Dans le fichier site.pp qui nous permettra d'importer le noeud concerné, nous aurons à l'éditer de cette façon :

Figure 3.27 configuration du fichier site.pp du module MySQL

Figure 3.28 configuration du fichier node.pp du module MySQL

Dans le fichier node.pp nous spécifierons le noeud concerné ainsi que le module qui lui sera associé, ce fichier sera édité de la manière suivante :

TFE_ESIS_AS 2016

57

CONCEPTION TECHNIQUE

3.3.2.6. Module DHCP [24, p. 41]

Pour le module DHCP, la procédure sera la même à la seule différence qu'ici le nom du module à saisir lors de la création de l'arborescence sera dhcp et le nom de la classe sera dhcp.

Pour le fichier init.pp, nous aurons à importer les modules install.pp, config.pp et service.pp et la classe se présentera comme suit :

Figure 3.29 configurations du fichier init.pp du module DHCP

Le fichier install.pp de ce module, devra s'assurer que le paquet soit installé, sa configuration se présentera donc de cette manière :

Figure 3.30 configuration du fichier install.pp du module DHCP

Figure 3.31 configuration du fichier config.pp du module DHCP

La configuration du fichier config.pp de ce module se présentera de la manière suivante :

TFE_ESIS_AS 2016

58

CONCEPTION TECHNIQUE

Le fichier service.pp du module DHCP s'assurera que le paquet installé tourne, il aura la configuration suivante

Figure 3.32 configuration du fichier service du module DHCP

Le fichier site.pp qui spécifie d'importer le fichier node.pp qui détient le FQDN du noeud concerné par cette configuration sera configuré de cette manière :

Figure 3.33 configuration du fichier node.pp du module DHCP

Enfin, le fichier node.pp spécifie le FQDN du noeud qui devra avoir les configurations décrites ci-haut, cela donnera comme résultat ceci :

Figure 3.34 configuration du fichier node.pp du module DHCP

3.3.2.7. Module Apache [24, p. 39]

La différence avec les deux modules précédents se situe au niveau de l'environ-nement, les deux premiers seront déployés dans l'environnement de production, par contre celui-ci sera déployé dans l'environnement de développement.

Le principe reste le même, créer l'arborescence en faisant mkdir -p /etc/puppet/environ-nement/developpement/modules/apache/{files, templates, manifests}, ensuite dans le répertoire manifest créer les fichiers init.pp, node.pp install.pp et enfin service.pp en faisant /etc/puppet/environnement/developpement/modules/apache/manifests init.pp node.pp install.pp service.pp.

Le fichier se présentera de cette manière :

TFE_ESIS_AS 2016

59

CONCEPTION TECHNIQUE

Figure 3.35 configuration du fichier init.pp du module Apache

Le fichier install qui nous permettra d'installer le package sur le noeud concerné sera configuré de la façon suivante :

Figure 3.36 configuration du fichier install.pp du module Apache

Le fichier service.pp nous permettra de vérifier si le service apache tourne sur le noeud, il adoptera cette configuration [25, p. 28]:

Figure 3.37 configuration du fichier service.pp du module Apache Le fichier node.pp se présentera de cette façon :

Figure 3.38 configuration du fichier site.pp du module Apache

Enfin, le fichier node.pp sera édité et contiendra le FQDN du noeud qui aura les configurations montrées dans les lignes d'en haut aura cette présentation :

TFE_ESIS_AS 2016

60

CONCEPTION TECHNIQUE

Figure 3.39 configuration du fichier nodee.pp du module Apache

Après avoir effectué toutes les configurations, nous allons importer toutes les classes des différents modules sur notre gestionnaire de cycle de vie, la procédure sera la suivante : aller sur l'onglet Configurer > Classes > cliquer sur importer depuis kanacad > cocher le module trouvés dans les différents environnements > Faire la mise à jour. [26, p. 49]

Figure 3.40 importation des classes puppet

3.3.3. Procédure des tests 3.3.3.1. Objectifs des tests

1. Déterminer que le système arrive à déployer les configurations prévues pour les noeuds ;

2. Déterminer que le système arrive à faire le monitoring, à avoir une vue globale, générer des rapports, audits et statistiques concernant les différents noeuds.

3.3.3.2. Tests

1. Test du premier objectif a. Etapes du test

? Tester la connectivité entre tous les noeuds et le serveur à l'aide de l'utilitaire Ping, il faudra pinger l'adresse IP du serveur (Ping 10.137.68.23).

Le résultat attendu devra ressembler à ceci :

TFE_ESIS_AS 2016

61

CONCEPTION TECHNIQUE

Figure 3.41 résultat du test de connectivité avec le serveur

· Créer les certificats numériques des clients à l'aide de la commande puppet agent -test, le résultat attendu devra être la création d'un certificat SSL avec une empreinte de type SHA256 ;

· Signer les certificats des clients au niveau du proxy intelligent Puppet CA en allant dans l'onglet Configurer > Smart proxies > certificats [26, p. 47];

· Modifier le fichier init.pp du module dhcp en mettant en commentaire l'importation du fichier config.pp puis enlever la classe incluse de ce dernier dans la classe principale dhcp. Affecter la classe dhcp et dhcp :: service au noeud kan-node1.kanacad.org en allant sur l'onglet Hôtes > tous les hôtes > cliquer sur le nom du client ( kan-node1.kanacad.org) > Modifier > Classes puppet puis affecter la classe dhcp et dhcp::service, afin de voir si le système arrive à déployer le service dhcp et se rassurer que ce dernier est en service sur le noeud ;

· Affecter le module du client kan-node2.kanacad.org, nous procéderons en allant sur l'onglet Hôtes > tous les hôtes > cliquer sur le nom du client ( kan-node2.kanacad.org) > Modifier > Classes puppet puis affecter les classes du module [23, p. 19] ;

· Synchroniser le serveur puis les noeuds qu'il gère avec leurs états de configuration décrits sur lui-même en faisant puppet agent -test sur les noeuds à manager, le résultat devra être l'application des configurations définies et le temps que l'agent puppet a pris pour exécuter le catalogue du client sur lequel il est installé [27, p. 32].

2. Test du deuxième objectif a. Etapes du test

· Aller sur l'onglet Hôtes > Tous les hôtes, voir si tous les noeuds sont visibles. Le résultat devra être un tableau reprenant le nom des hôtes, le logo et la version du système d'exploitation, l'environnement, le modèle, le groupe d'hôtes ainsi que le dernier rapport de chacun de ses hôtes ;

· Aller sur l'onglet Surveiller > Tableau de bord, voir si le système arrive à avoir les statuts de configuration des hôtes et le diagramme de la configuration des hôtes. Le résultat devra être le nombre d'hôte qui ont effectué des changements sans erreurs, les hôtes en erreur, les bons rapports dans les derniers 35 minutes, hôte en

TFE_ESIS_AS 2016

62

CONCEPTION TECHNIQUE

attente de changements, hôte désynchronisés, hôte sans aucun rapport, hôte dont les alertes sont désactivées ;

? Aller sur l'onglet Surveiller > Rapports puis Hôtes > Tous les hôtes > cliquer sur le nom d'un hôte > Rapport, voir si le système arrive à générer des rapports sur chaque hôte et même l'ensemble du système. Le résultat devra être un tableau reprenant le nom des hôtes ainsi que son rapport, pour chaque hôte le résultat sera un tableau reprenant le nom de l'hôte sur lequel nous visualisons le rapport ainsi que les indications sur l'application des configurations ;

? Aller sur l'onglet Hôtes > Tous les hôtes > cliquer sur le nom de l'un des hôtes, voir si le système arrive à faire le monitoring des noeuds gérés, le résultat sera un tableau reprenant les informations sur le noeud concerné (statut du noeud, état de configuration, nom de l'hôte, adresse IP, adresse MAC, architecture du processeur, le nom du domaine, le nom du système d'exploitation ainsi que l'environnement puppet dans lequel le noeud travail) ainsi que des graphiques en rapport avec l'application des configurations [26, p. 11];

? Aller sur l'onglet Surveiller > Statistiques, voir si le système génère des statistiques. Le résultat devra être des diagrammes en camembert décrivant en pourcentage les statistiques sur la mémoire, la répartition des classes, la répartition des systèmes d'exploitation, la répartition des environnements et l'architecture des processeurs ;

? Aller sur l'onglet Surveiller > Audits, voir si le système arrive à générer un audit sur l'ensemble. Puis aller sur l'onglet Hôtes > tous les hôtes > cliquer sur le nom d'un noeud > Audits. Le résultat devra être la liste des actions apportées à l'ensemble du système et l'autre sur un noeud spécifique.

3.3.4. Plan d'implémentation

La planification est l'action de planifier, c'est-à-dire d'organiser dans le temps une succession d'actions ou d'évènements afin de réaliser un objectif particulier, dans notre cas, nous planifions l'implémentation.

Après avoir eu les procédures d'installation, les procédures des configurations des différents modules ainsi que celles de test, nous avons déjà réuni les informations nécessaires pour entamer la phase d'implémentation. Sur ce l'implémentation se passera comme suit :

? Créer les machines virtuelles en chargeant les images systèmes dans VMware, une de type Ubuntu 14.04.2 LTS pour le serveur, une autre du même type pour un client et enfin une image CentOS 6.6 pour le dernier client ;

TFE_ESIS_AS 2016

63

CONCEPTION TECHNIQUE

· Répliquer la connexion de la machine physique sur les machines virtuelles ;

· Configurer les paramètres du serveur et de deux clients (fichiers hosts et hostname) ;

· Installer puppet et foreman sur le serveur en suivant la procédure d'installation et tester si elle a réussi ;

· Installer les agents puppet sur les clients en suivant leurs procédures d'installation ;

· Configurer le serveur et les noeuds ;

· Tester les configurations des noeuds et serveur ;

· Editer le fichier puppet.conf du serveur ;

· Editer les fichiers puppet.conf des clients ;

· Créer l'arborescence des modules mysql, dhcp et apache et les différents fichiers (init.pp, install.pp, config.pp, service.pp, node.pp et site.pp ) nécessaires aux différents modules sur le serveur ;

· Editer les fichiers init.pp, install.pp, config.pp, service.pp, node.pp et site.pp de chaque module ;

· Se connecter à l'interface web de foreman et créer un domaine ;

· Créer un nouveau proxy intelligent regorgeant le TFTP, Puppet et Puppet CA ;

· Importer toutes les classes des différents modules de puppet vers foreman ;

· Tester les communications entre les clients et le serveur ;

· Créer les certificats numériques des clients des hôtes ;

· Signer les certificats à partir du proxy intelligent dans foreman ;

· Modifier les hôtes en leur attribuant les classes des modules qui leurs sont concernées ;

· Synchroniser le serveur puis les clients avec leurs états des configurations définis sur le serveur ;

· Vérifier que les hôtes sont visibles ;

· Vérifie que le tableau de bord du système est visible ;

· Vérifier que le système génère les rapports sur l'ensemble du système et sur chacun des noeuds ;

· Vérifier que le système fait le monitoring des noeuds ;

· Vérifier que le système génère les statistiques.

· Vérifier que le système génère l'audit sur l'ensemble du système et sur chacun des noeuds.

Toutes les étapes citées ci-haut ont une durée de temps bien définie dans l'espace et dans le temps, voilà pourquoi il s'est avéré important de faire un diagramme de GANTT

TFE_ESIS_AS 2016

64

CONCEPTION TECHNIQUE

retraçant toutes les tâches qui seront effectuées dans l'implémentation de telle sorte que rien ne soit oublié.

65

CONCEPTION TECHNIQUE

Figure 3.42 extrait du diagramme de GANTT pour la planification de l'implémentation

TFE_ESIS_AS 2016

TFE_ESIS_AS 2016

66

CONCEPTION TECHNIQUE

3.4. Conclusion Partielle

Sur la phase des spécifications des besoins et celle de conception (logique et physique), nous avons suivi un processus de développement dans lequel chaque cause qui intervenait dans le système produisait un effet dans ce dernier, rien n'a été mis au hasard. Dans ce chapitre nous avons planifié ce que nous ferons durant la prochaine phase. Les résultats de ce chapitre sont les procédures d'installation, les procédures de configuration du serveur, des clients ainsi que leurs tests, les procédures des tests globaux du système et enfin le plan d'implémentation de notre système.

Dans la phase suivante de notre travail, nous n'allons plus perdre du temps en réfléchissant sur la façon d'installer le système, ni même la façon de le configurer ou tester, tous ces aspects ont déjà été traités dans l'abstraction.

TFE_ESIS_AS 2016

CHAPITRE 4: IMPLEMENTATION

4.1. Introduction

Dans les chapitres précédents nous avons préparé toutes les données nécessaires à l'implémentation en passant par le processus d'abstraction que nous avons appliqué.

Nous avons déjà réuni toutes les informations en quantité suffisante afin d'entamer le travail, il n'est plus question de modifier notre planification, réfléchir sur l'architecture qui devra accueillir la solution ou la façon de déployer nos configurations, la conception faite antérieurement a déjà résolu toutes ces préoccupations. Présentement, il est question d'exécuter le travail qui a été planifié et ressortir les résultats attendus.

4.2. Installation et configuration

Voici le plan sommaire de ce que nous ferons dans cette partie :

· Installer le serveur puppet et foreman ;

· Tester si l'installation du serveur puppet et foreman a réussi ;

· Appliquer les configurations prévues pour le serveur ;

· Tester les paramètres IP su serveur ;

· Configurer le serveur :

· Configurer le domaine ;

· Configurer le proxy intelligent ;

· Importer les classes puppet dans foreman ;

· Installer l'agent puppet sur le premier client ;

· Installer l'agent puppet sur le deuxième client ;

· Appliquer les configurations prévues pour le premier client ;

· Tester les paramètres IP du premier client

· Appliquer les configurations prévues pour le deuxième client ;

· Tester les paramètres IP du deuxième client.

4.2.1. Installations

4.2.1.1. Serveur sous Ubuntu 14.04.2 LTS

Concernant la procédure d'installation de puppet et foreman, nous nous sommes connectés en tant que root sur le terminal, nous avons suivi la procédure d'installation qui avait été donnée dans le chapitre précédent, dès la première commande nous avons eu des messages d'erreurs.

TFE_ESIS_AS 2016

67

IMPLEMENTATION

Nous avons résolu le problème en faisant la mise à jour de tous les packages locaux du serveur en frappant la commande apt-get update [28, p. 23], ensuite nous nous sommes mis à suivre la procédure d'installation PROC.INST.3.1.

Ensuite nous avons exécuté la commande foreman-installer qui a éditer le fichier puppet.conf et imprimer les informations utiles à foreman et puppet, nous avons personnalisé l'exécution de cette commande en y ajoutant le login qui est admin et le mot de passe qui sera utilisé pour la connexion comme représenté sur la figure suivante :

Figure 4.1 test d'installation de puppet et foreman

Le résultat de cette commande imprime les informations sur l'URL que nous utiliserons pour nous connecter à l'interface web de foreman, le login et le mot de passe, l'URL du proxy foreman, voici en fait le résultat attendu :

Figure 4.2 résultat du test après exécution de foreman-installer

4.2.1.2. Client sous Ubuntu 14.04.2 LTS

L'installation de l'agent puppet sur ce client n'a pas été un succès sur ce dernier vu les erreurs qui ont été générées lors de l'exécution de la commande spécifiée dans la procédure d'installation, du moins l'équivoque a été levée en faisant la mise à jour de la liste de tous les packages locaux de la machine via la commande apt-get update, enfin nous avons suivi la procédure PROC.INST.3.2.

4.2.1.3. Client sous CentOS 6.6

L'installation de l'agent puppet s'est effectué avec succès tout en respectant la procédure d'installation de ce client (PROC.INST.3.3).

TFE_ESIS_AS 2016

68

IMPLEMENTATION

4.2.2. Configurations

Pour la partie configurations, la conception technique nous a permis de prévoir les configurations nécessaires, dans cette partie présente nous avons pris les configurations prévues déjà à l'avance.

4.2.2.1. Serveur sous Ubuntu 14.04.2 LTS

Sur le serveur la procédure de configuration est PROC.CONF.3.1, les tests prévus pour ce dernier ont réussi, les résultats de ces tests se présentent de la manière suivante :

Figure 4.3 résultat du test des paramètres IP du serveur

Figure 4.4 résultat du test de vérification de l'hostname du serveur

Les différents modules prévus ont été déjà créés, le module mysql et dhcp ont été placés dans l'environnement de production et apache dans l'environnement de développement du gestionnaire des configurations, nous les importerons depuis ce dernier vers le gestionnaire de cycle de vie Foreman.

Nous allons tout d'abord lancer le navigateur et ensuite saisir dans la barre d'adresse l'URL de connexion à foreman comme suit :

Figure 4.5 connexion à l'interface web de foreman

Apres lancement nous aurons l'interface web de foreman, il nous faudra saisir le login et le mot de passe :

TFE_ESIS_AS 2016

69

IMPLEMENTATION

Figure 4.6 interface d'accueil de foreman

Nous allons d'abord créer un proxy intelligent, en suivant cette procédure : onglet Infrastructure > Smart proxies > Nouveau smart proxies et enfin saisir le nom et l'URL du proxy.

Figure 4.7 informations du proxy intelligent

TFE_ESIS_AS 2016

70

IMPLEMENTATION

Figure 4.8 résultat après création du proxy intelligent

Ensuite nous créons un domaine, en allant sur Configurer > Domaines > Nouveau domaine et saisir le nom qui est kanacad et le nom complet kanacad.org.

Figure 4.9 création du domaine kanacad.org

Figure 4.10 importation des classes

Après, nous allons sur l'onglet Configurer > Classes, cliquer sur Import depuis kanacad afin d'importer toutes les classes qui constituent les différents modules, ensuite cocher les modules et enfin faire la mise à jour.

TFE_ESIS_AS 2016

71

IMPLEMENTATION

Figure 4.11 mise à jour des classes puppet

Après avoir fait la mise à jour, nous aurons un tableau reprenant toutes les classes présentes dans les différents environnements de production et de développement (production et development) le tableau se présente de cette manière :

72

IMPLEMENTATION

TFE_ESIS_AS 2016

Figure 4.12 tableau des classes importées depuis puppet

TFE_ESIS_AS 2016

73

IMPLEMENTATION

4.2.2.2. Client sous Ubuntu 14.04.2 LTS

Les configurations prévues pour ce client (PROC.CONF.3.2) ont été appliquées et aucun problème ne s'est révélé. Le FQDN de ce client est kan-node1.kanacad.org et son adresse IP est 10.137.68.7. Voici donc les résultats des tests effectués sur ce client :

Figure 4.13 résultat du test de configurations des paramètres IP du client kan-node1

Figure 4.14 résultat du test de vérification de l'hostname du client kan-node1

4.2.2.3. Client sous CentOS 6.6

Nous avons appliqué la procédure prévue (PROC.CONF.3.3) pour ce client et le résultat sont les suivant :

Figure 4.15 résultat de test de configuration des paramètres IP du client kan-node2

TFE_ESIS_AS 2016

74

IMPLEMENTATION

Figure 4.16 résultat du test de l'hostname du client kan-node2 4.3. Tests et résultats

4.3.1. Premier objectif

4.3.1.1. Test des connectivités entre clients et serveur

Premièrement nous avons testé la connectivité du client kan-node1 avec le serveur en faisant un Ping sur l'adresse IP du serveur, le test a réussi et voici le résultat :

Figure 4.17 résultat du test de connectivité entre le client kan-node1 et le serveur

Enfin le test de connectivité entre le deuxième client kan-node2 et le serveur a également réussi, voici le résultat :

Figure 4.18 résultat du test de connectivité entre le client kan-node2 et le serveur 4.3.1.2. Création des certificats

Premièrement, nous allons procéder à la création du certificat numérique du client kan-node1.kanacad.org afin de sécuriser les communications entre ce dernier et le serveur de gestion des configurations de notre infrastructure. Il nous faudra saisir la commande puppet agent -test. Le résultat se présente comme suit :

TFE_ESIS_AS 2016

75

IMPLEMENTATION

Figure 4.19 création du certificat sur le client kan-node1

Ensuite, nous allons créer le certificat numérique de ce client à l'aide de la commande puppet agent --test. Le résultat de cette dernière donne ceci :

Figure 4.20 création du certificat sur le client kan-node2 4.3.1.3. Signature des certificats

Au niveau du serveur, nous nous connectons en tant que root et nous saisissons la commande puppet cert -list pour voir la liste des certificats en attente de signature ainsi que l'empreinte de ce dernier qui est de type SHA256. Voici à quoi ressemble le résultat attendu :

Figure 4.21 liste des certificats en attente de signature sur le serveur

Nous avons bien vu le certificat numérique au niveau de puppet, maintenant il faudra signer ce certificat au niveau de foreman en passant par le proxy intelligent Puppet CA, le chemin est le suivant : infrastructure > smart proxy > certificats, voir la liste et cliquer sur signer.

TFE_ESIS_AS 2016

76

IMPLEMENTATION

Figure 4.22 procédure de signature des certificats

Figure 4.23 signature de certificat du client kan-node1

Figure 4.24 signature de certificat du client kan-node2

4.3.1.4. Affectation des modules aux noeuds

A présent, nous allons modifier le noeud kan-node1.kanacad.org afin de lui affecter la classe dhcp et dhcp::service. La modification a réussi et a donné le résultat suivant :

TFE_ESIS_AS 2016

77

IMPLEMENTATION

Figure 4.25 inclusion des classes dhcp et dhcp :: service

Nous allons modifier l'hôte kan-node2.kanacad.org en lui attribuant le module apache qui se trouve dans l'environnement de développement du gestionnaire des configurations Puppet. Le résultat se présente comme suit :

Figure 4.26 inclusion des classes du module Apache

4.3.1.5. Synchronisation des états des configurations des noeuds

Figure 4.27 résultat du test de synchronisation du serveur kan-srvlub-foreman

Le serveur n'a pas eu de module qui lui a été assigné, du moins pour qu'il n'ap-paraisse pas en erreur au niveau du tableau de bord, il s'avère nécessaire de le synchroniser aussi, le test a réussi et le résultat se présente comme suit :

TFE_ESIS_AS 2016

78

IMPLEMENTATION

Pour la synchronisation du deuxième client, nous avons commencé par modifier le fichier init.pp comme indiqué dans la procédure.

Figure 4.28 modification du fichier init.pp du module dhcp

Le résultat de la synchronisation du premier client avec son état de configuration a réussi, le package dhcp est présent sur le noeud et tourne sur ce dernier, voici le résultat de ce test :

Figure 4.29 résultat du test de synchronisation du client kan-node1

Figure 4.30 résultat du test de synchronisation du client kan-node2

Le test sur le client kan-node2 n'a pas réussi suite à un problème lié au système de fichier survenu sur ce dernier, voici le résultat émanant de ce test :

79

IMPLEMENTATION

4.3.2. Deuxième objectif

4.3.2.1. Visualisation des hôtes

Le test pour la visualisation des noeuds que nous gérons a réussi, à travers l'onglet Hôtes puis tous les hôtes nous savons visualiser tous les noeuds, voici comment se présente le résultat :

Figure 4.31 résultat de test pour la visualisation des noeuds gérés

TFE_ESIS_AS 2016

TFE_ESIS_AS 2016

80

IMPLEMENTATION

4.3.2.2. Visualisation du tableau de bord

Le résultat pour la visualisation du tableau de bord à travers les onglet spécifiés au niveau des procédures de test a réussi, le résultat est le suivant :

Figure 4.32 résultat du test pour la visualisation du tableau de bord

TFE_ESIS_AS 2016

81

IMPLEMENTATION

4.3.2.3. Visualisation des rapports

Figure 4.33 résultat du test de visualisation du rapport global

82

IMPLEMENTATION

Figure 4.34 résultat du test de visualisation du rapport d'un noeud

TFE_ESIS_AS 2016

TFE_ESIS_AS 2016

83

IMPLEMENTATION

4.3.2.4. Monitoring d'un noeud

Pour voir si le système arrive à offrir un monitoring sur les noeuds gérés nous avons fait un test, ce dernier comme indiqué au niveau des procédures des tests, nous avons navigué dans les onglets spécifiés antérieurement, voici le résultat :

Figure 4.35 résultat du test de monitoring d'un hôte

TFE_ESIS_AS 2016

84

IMPLEMENTATION

4.3.2.5. Visualisation des statistiques

Nous avons navigué dans les onglets indiqués au niveau des procédures de test pour visualiser les statistiques, le test a réussi et a donné ceci :

Figure 4.36 résultat du test de visualisation des statistiques

85

IMPLEMENTATION

4.3.2.6. Visualisation de l'audit

Le test pour la visualisation de l'audit a été un succès, voici comment se présente le résultat de ce test :

Figure 4.37 résultat du test de visualisation de l'audit sur l'ensemble du système

TFE_ESIS_AS 2016

86

IMPLEMENTATION

Le résultat de l'audit sur un noeud spécifique se présente comme suit :

Figure 4.38 résultat du test de visualisation de l'audit sur un noeud

TFE_ESIS_AS 2016

87

IMPLEMENTATION

4.4. Conclusion partielle

4.4.1. Evaluation des besoins 4.4.1.1. Besoins fonctionnels

Tableau 4.1 évaluation des besoins fonctionnels

ID	Noms des besoins	Evaluations	Notes
PF-F-01	Authentification	100%	L'accès au système requiert une authentification
PF- F-02	Ajout des nouveaux noeuds	0%	Nécessite un hyperviseur bare-metal ou un environnement physique
PF- F-03	Regroupement des hôtes et les gérer indépendamment de leurs emplacements physiques	0%	Nécessite plusieurs hôtes qui sont dans les mêmes environnements de puppet
PF- F-04	Gestion des versions des logiciels installés	100%	Test avec succès
PF- F-05	Synchronisation automatique des noeuds avec l'état de configuration	100%	Test avec succès
PF- F-06	Génération des rapports	100%	Test avec succès
PF- F-07	Génération des statistiques	100%	Test avec succès
PF- F-08	Monitoring	100%	Test avec succès
PF- F-09	Audits	100%	Test avec succès
PF- F-10	Signature des certificats	100%	Test avec succès
PF- F-11	Résolution de noms	0%	Requiert la configuration du proxy intelligent DNS
PF- F-12	Attribution automatique d'adresses IP	0%	Requiert la configuration du proxy intelligent DHCP
	TOTAL	66,66%

TFE_ESIS_AS 2016

88

IMPLEMENTATION

4.4.1.2. Besoins non fonctionnels

Tableau 4.2 évaluation des besoins non fonctionnels

ID	Noms des besoins	Evaluations	Notes
PF-NF-01	Utilisabilité	95%	Le système est facile à utiliser
PF-NF-02	Stabilité	90%	Le système ne prend pas beaucoup de temps pour se rétablir après déstabilisation
PF-NF-03	Performance	98%	Le système offre un temps d'attente moindre
PF-NF-04	Disponibilité	99%	Le temps d'arrêt est trop moindre
PF-NF-05	Sécurité	98%	Les communications sont chiffrées et la connexion au système exige d'en avoir les droits
PF-NF-06	Portabilité	100%	Le système peut gérer tout type
PF-NF-07	Simplicité de mise en place	100%	Trop facile à mettre en place et à configurer
PF-NF-08	Fiabilité	100%	Le système est critique
PF-NF-09	Coût	100%	Tous les composants du système sont open source et gratuit, cela n'en-gage pas de frais supplémentaires pour leurs mises en place

TOTAL 97,77%

TFE_ESIS_AS 2016

TFE_ESIS_AS 2016

89

IMPLEMENTATION

0 0

0 0

100 100 100 100 100 100 100 100

66,66666667

Figure 4.39 graphique d'évaluation des besoins fonctionnels

PF-NF-01 PF- NF-

02

95

90

PF- NF-

03

98

PF- NF-

04

99

PF- NF

05

98

PF- NF-

100 100 100 100

06

PF- NF-

07

PF- NF-

08

PF- NF-

09

97,77777778

TOTAL

Figure 4.40 graphique d'évaluation des besoins non fonctionnels

En bref, nous avons implémenté le système tel que prévu au niveau de la conception technique qui est en fait la matérialisation de toute la conception logique de notre système, seules 66,66% des fonctionnalités ont été implémentées par rapport à l'ensemble des toutes les fonctionnalités ou tous les besoins fonctionnels.

TFE_ESIS_AS 2016

CONCLUSION GENERALE

Ce présent travail a traité sur la gestion des configurations d'un Datacenter basée sur un gestionnaire des configurations (Puppet) et un gestionnaire de cycle de vie (Foreman), il s'agissait de concevoir et implémenter un système centralisant toutes les configurations du parc des serveurs du centre de données de Katanga Networking Academy. L'objectif poursuivi était celui de permettre aux administrateurs systèmes de s'affranchir des commandes propres à chaque système d'exploitation utilisé dans le Datacenter cible.

Pour arriver aux résultats attendus, nous avons utilisé les grands principes de l'in-génierie des systèmes qui consistaient à diviser les tâches, mettre l'abstraction afin de partir du général au particulier. Voilà pourquoi notre travail a été structuré en quatre parties. Dans un premier temps, nous avons fait la description du Datacenter dont il était question dans notre travail et critiquer l'existant dans le but de ressortir les spécifications fonctionnelles du futur système.

Sur base des spécifications fonctionnelles recueillies dans la première partie, nous nous sommes appuyés dessus dans le but de concevoir logiquement le système qui devait répondre aux différents besoins exprimés par Katanga Networking Academy ; cette conception consistait en la mise en place d'une architecture générale du dit système et une conception détaillée logique qui montrait les détails sur la façon dont les différents modules constituant l'architecture générale interagissaient entre eux.

Après avoir ainsi conçu une solution logique répondant aux besoins, nous avons réalisé cette dernière dans les technologies disponibles en opérant des choix technologiques des composants pouvant réaliser les fonctionnalités de chaque module ce qui a conduit à la mise en place de l'architecture du système sur le plan physique. Du reste, nous avons également planifié l'implémentation du système en partant des procédures d'installation, des configurations ainsi que des tests unitaires et ceux globaux du système.

L'implémentation du système a en fait mis un terme à ce travail, c'est-à-dire concrétiser tout ce qui a été développé dans l'abstraction en d'autres termes réaliser tout ce qui a été planifié en appliquant les procédures d'installation données auparavant pour la mise en place du système ainsi que leurs tests unitaires et globaux.

Il était aussi question d'appliquer les configurations prévues pour les différents noeuds et enfin procéder aux tests des objectifs fixés dans ce travail afin de prouver l'hypothèse de ce travail.

Perspectives d'avenir

Nous ne prétendons en aucun instant avoir mis en place une solution qui résout tous les problèmes, c'est pourquoi nous avons évalué les besoins exprimés par Katanga Networking Academy en fonction de ce que nous avons eu à faire, il est clair que les 100% des besoins n'ont pas été atteints dans notre travail, néanmoins nous donnerons les limites de la solution mise en place ainsi que les perspectives d'avenir.

La solution mise en place répond aux seules réalités que rencontre Katanga Networking Academy dans la période allant d'octobre 2015 à septembre 201, le système se limite à la

TFE_ESIS_AS 2016

91

CONCLUSION GENERALE

gestion du parc des serveurs de l'association qui est en fait constitué de 99% des serveurs basés sur le noyau Linux. Notre prochain challenge sera celui de pouvoir gérer les serveurs Windows, les équipements réseaux ainsi que les entités ou les ressources pouvant se trouver dans le cloud.

Etant donné aussi que la technologique évolue à pas de géant et pousse à ce que la tendance future de la virtualisation se dirige vers la conteneurisation des services et applications avec Docker, un autre défi sera celui de gérer ces services ainsi que les applications déployées dans des conteneurs Docker.

Il sied de noter que ce travail est une oeuvre humaine, elle est sujette à des imperfections. Cependant, nous restons ouvert à toute remarque, critique et correction pour l'amélioration et l'évolution de ce travail.

TFE_ESIS_AS 2016

REFERENCES

[1] C. BAHUKA LENGE, « Etude et mise en oeuvre d'une administration système automatisée et centralisée autour d'un gestionnaire de configuration », Ecole Supérieure d'Informatique Salama, Lubumbashi, 2010.

[2] [En ligne]. Disponible sur: http://www.kanacad.org/?page_id=15. [Consulté le: 16-avr-2016].

[3] P. ATELIN, Réseaux sans fil 802.11 : Technologie - Déploiement - Sécurisation. ENI.

[4] [En ligne]. Disponible sur: http://www.avencall.com/solutions-et-services/decou-vrez-xivo/. [Consulté le: 01-mai-2016].

[5] [En ligne]. Disponible sur: https://framasoft.org/article5221.html. [Consulté le: 01-mai-2016].

[6] A. DULAUNOY, « Introduction à TCP/IP et aux routeurs de type IOS (Cisco) ». .

[7] [En ligne]. Disponible sur: http://www.linuxfr.org/news/packetfence-183-un-puis-sant-contr%C3%B4leur-dacc%C3%A8s-au-r%C3%A9seau. [Consulté le: 27-avr-2016].

[8] [En ligne]. Disponible sur: https://www.symantec.com/fr/fr/products/computer-se-curity-software/.

[9] L. Thierry, La virtualisation des systèmes d'information. 2005.

[10] [En ligne]. Disponible sur: http://www.journaldunet.com/solutions/ex-
pert/49698/pourquoi-virtualiser-son-parc-informatique.shtml. [Consulté le: 07-avr-2016].

[11] [En ligne]. Disponible sur: http://www.it-connect.fr/kvm-proxmox/. [Consulté le: 26-avr-2016].

[12] B. POLOMBWE, « Cours des télécommunications ». Ecole Supérieure d'Informa-tique Salama, 2014-2015.

[13] B. ESPINASSE, « Méthodes fonctionnelles SADT ». Université d'Aix-Marseille.

[14] L. Macvittie, « How deploy frequency impacts infrastructure stability », 26 Févirier 2015.

[15] H. BERSINI, La programmation orientée objet, 4^e éd. Eyrolles.

[16] G. PICARD, « Langage et Concepts de Programmation Orientée-Objet », École Nationale Supérieure des Mines de Saint-Étienne, 2013-2014.

[17] L. KANIKI, « Cours des protocoles réseaux ». Ecole Supérieure d'Informatique Sa-lama, 2015-2016.

[18] R. HERTZOG, Cahier de l'admin Debian, 2^e éd. Eyrolles.

[19] J. RHETT, Learning Puppet 4, 1^re éd. O'REILLY, 2015.

[20] F. PAILLOT et C. DELALANDE, « gestion d'infrastructure avec puppet », présenté à Séminaire RAISIN puppet, Bordeaux, 27-mai-2010.

[21] [En ligne]. Disponible sur: http://www.coreye.fr/fr/expertises/foreman. [Consulté le: 24-juill-2016].

[22] 24-janv-2016. [En ligne]. Disponible sur: http://aaronmcmahan.com/foreman/pup-pet/2016/01/24/Managing-Your Infrastructure Part 1 : Setup Foreman. [Consulté le: 03-juin-2016].

TFE_ESIS_AS 2016

93

REFERENCES

[23] [En ligne]. Disponible sur: http://www.tecmint.com/install-puppet-in-centos/. [Consulté le: 23-juill-2016].

[24] A. DIMITRI, Q. DEXHEIMER, et R. BLONDE, « Configuration automatique d'un cluster de calcul avec Puppet », mars 2012.

[25] J. LOOPE, Managing infrastructure with Puppet, 1^re éd. O'REILLY, 2011.

[26] G. OGILVE, « How to keep track of puppet with Foreman ». .

[27] J. ARUNDEL, Puppet 2.7 Cookbook. Packt publishing.

[28] G. CATTEAU et A. MARTINS, « introduction à Linux ». 2008.