Page |

ECOLE SUPERIEURE D’INFORMATIQUE SALAMA

République Démocratique du Congo
Province du Haut-Katanga
Lubumbashi
www.esisalama.org

« PLAN DE CONTINUITE D’UN SERVICE SYSTEME IMPLEMENTE

AVEC UNE CONTENEURISATION DANS LE CLOUD »
Cas d’un SGBD

Travail présenté dans le cadre de l’obtention du

diplôme d’ingénieur technicien en informatique
dans la filière administration systèmes et réseaux

Par : TSHIBUNDA KABUNDI Dyna

Option : Administration systèmes et Réseaux

MARS 2021

TFC_ESIS_AS
 Page |I

ECOLE SUPERIEURE D’INFORMATIQUE SALAMA

République Démocratique du Congo
Province du Haut-Katanga
Lubumbashi
www.esisalama.org

« PLAN DE CONTINUITE D’UN SERVICE SYSTEME IMPLEMENTE

AVEC UNE CONTENEURISATION DANS LE CLOUD »
Cas d’un SGBD

Travail présenté dans le cadre de l’obtention du

diplôme d’ingénieur technicien en informatique
dans la filière administration systèmes et réseaux

Par : TSHIBUNDA KABUNDI Dyna

Option : Administration systèmes et Réseaux
Directeur : M. Bertin POLOMBWE
Co-directeur : M. Patrick TSHINYOKA

ANNEE ACADEMIQUE 2019-2020

TFC_ESIS_AS
 Page |2

EPIGRAPHE

« L'innovation n'est pas un flash de génie. C'est un travail dur. Et ce travail

devrait être organisé comme une partie régulière de chaque unité de l'entreprise et à
chaque niveau de gestion. »

Peter Drucker

TFC_ESIS_AS
 Page |3

DEDICACE

A mon père KABUNDI TSHIANI Emmanuel et à ma mère KAOMBE Marie

qui ont toujours été présents pour moi. Non seulement ils m’ont envoyé aux études mais
m’ont aussi soutenu physiquement, financièrement et spirituellement durant tout mon
parcours académique.

A mon très cher et tendre ami, LUBANDA Higelin, présent depuis le début de
mon cursus.

TFC_ESIS_AS
 Page |4

REMERCIEMENTS

Ce présent travail de fin de cycle universitaire, résultat d’une longue période de

patience, de peine et de sacrifice n’a pas été le fruit des efforts personnels.

Avant toute chose, nous tenons à remercier le Bon Dieu, maître des temps et des
circonstances, de nous avoir protégé ensuite donné la sagesse et l’intelligence nécessaires
pour parvenir à la fin de ce premier cycle.

Nous remercions notre directeur et codirecteur, Monsieur Bertin POLOMBWE

et Monsieur Patrick TSHINYOKA 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 à toutes les autorités

académiques de l’Ecole Supérieure d’Informatique Salama et plus particulièrement à
notre coordonnateur de filière, Monsieur Michée KALONDA, pour son soutien et ses
encouragements.

Nous tenons à remercier le couple MISABIKO, Junior AUMBA et Evelyne

MUNTETE, pour leur soutien immense et leurs encouragements durant notre cursus.

Un grand merci à tous mes frères : KITENGE Kiki, KALUBI Hans, TSHIANI
Israël, MITONGA Kraus et à toutes mes sœurs : KASONGO clarisse, MUNTETE
Evelyne, KABEDI Sarah et KAOMBE Rebecca pour tous leurs soutiens manifestés à
notre égard.

Nous remercions nos amis(es), collègues ainsi que cousine : NDAMUSO

Stéphanie, MUNKOKOLE Lorraine, TSHIDIBI Christelle, KISEME Olga, MUTALE
Sarah, TSHIMANGA Shekinah, ILUNGA Melissa, MAKUMBI Hugues, KYOBA
Jackie pour leur assistance et encouragement.

Nous remercions les ingénieurs MUKOLE Peniel et KABULU Jean-Luc pour

leurs temps accordés pour les échanges et discussions ainsi que pour toute aide apportée
pour la réalisation de ce travail.

Nous pensons également à MWINKEU Joël, MUSHEMBE Fabrice, DJAMBA

Paulin, KAMUNGA David, NTENGU Joël et TUMAINI Corneille qui se sont montrés
collaboratifs pendant tout notre parcours académique. Nous leur disons sincèrement «
merci »

À tous ceux qui ne cessaient de nous assister de près ou de loin durant notre
cursus, nous tenons à leurs exprimer au travers de ces mots, notre profonde gratitude.

TFC_ESIS_AS
 Page |5

LISTE DES FIGURES

Figure 1.1 organigramme d’ANONYMOUS................................................................. 23

Figure 1.2 topologie physique d’ANONYMOUS .......................................................... 30

Figure 1.3 Diagramme de cas d’utilisation du système ................................................ 35

Figure 1.4 Diagramme de séquence du scénario 2 ....................................................... 37

Figure 1.5 Diagramme de séquence du scénario 1 ....................................................... 38

Figure 2.1 Illustration de services cloud ...................................................................... 44

Figure 2.2 architecture logique du système .................................................................. 45

Figure 2.3 Communication réseau entre processus [5] ................................................ 48

Figure 2.4 Illustration d’un LAN ................................................................................. 49

Figure 2.5diagramme de séquence détaillée du scénario 1 .......................................... 51

Figure 2.6 Différence entre machine virtuelle et conteneur [6] .................................... 53

Figure 2.7Le diagramme de séquence de migration du service .................................... 54

Figure 2.8 courbe de comparaison conteneurs............................................................. 56

Figure 2.9 Architecture de docker ............................................................................... 59

Figure 2.10 diagramme Radar de comparaison SGBD ................................................ 60

Figure 2.11 Architecture de PostgreSQL [18] ............................................................. 61

Figure 2.12 architecture de la synchronisation ............................................................ 65

Figure 2.13 diagramme Radar de comparaison cloud ................................................. 66

Figure 2.14 Architecture cloud AWS............................................................................ 67

Figure 2.15 Architecture AMI ...................................................................................... 68

Figure 2.16 diagramme d’interaction entre modules.................................................... 71

Figure 2.2.17diagramme de Gantt ............................................................................... 73

Figure 3.1 mises à jour gestionnaire ............................................................................ 75

TFC_ESIS_AS
 Page |6

Figure 3.2 versions package ........................................................................................ 75

Figure 3.3 installation de docker ................................................................................. 75

Figure 3.4 version docker ............................................................................................ 75

Figure 3.5 création de groupe docker .......................................................................... 76

Figure 3.6 installation de postgres............................................................................... 76

Figure 3.7 création du fichier volume .......................................................................... 77

Figure 3.8 utilisateur postgres ..................................................................................... 77

Figure 3.9 liste des images postgres ............................................................................ 77

Figure 3.10 interface postgres ..................................................................................... 77

Figure 3.11 connexion à postgres ................................................................................ 77

Figure 3.12 bases de donnée postgres.......................................................................... 78

Figure 3.13 interface de AWS ...................................................................................... 78

Figure 3.14 connexion AWS ........................................................................................ 79

Figure 3.15 connexion de l’utilisateur ......................................................................... 79

Figure 3.16 interface EC2 ........................................................................................... 80

Figure 3.17 installation Ubuntu sur le cloud................................................................ 80

Figure 3.18 propriété de l’instance .............................................................................. 81

Figure 3.19 configuration règles sortantes .................................................................. 81

Figure 3.20 configuration règles sortantes .................................................................. 81

Figure 3.21 types de connexion au cloud ..................................................................... 82

Figure 3.22 mises à jour du serveur cloud ................................................................... 82

Figure 3.23 installation de postgres sur le cloud.......................................................... 83

Figure 3.24 clé de sécurité connexion au cloud ........................................................... 83

Figure 3.25 déploiement de l’image sur le cloud.......................................................... 84

TFC_ESIS_AS
 Page |7

Figure 3.26 emplacement du nouveau fichier............................................................... 84

Figure 3.27 fichier config2 Figure 3.28 fichier config .................................. 84

Figure 3.29 adresse ip local ........................................................................................ 85

Figure 3.30 adresse ip local et cloud ........................................................................... 85

Figure 3.31 standby ..................................................................................................... 85

Figure 3.32 replication entre deux serveurs ................................................................. 86

Figure 3.33 synchronisation des données..................................................................... 86

Figure 3.34 activer l’application ................................................................................. 86

Figure 3.35 BDD local ................................................................................................ 87

Figure 3.36 BDD cloud ............................................................................................... 87

Figure 3.37 table dans la BDD local ........................................................................... 88

Figure 3.38 serveurs postgres ...................................................................................... 88

Figure 3.39 données dans le locaL .............................................................................. 89

Figure 3.40 tableau de bord du serveur cloud.............................................................. 90

Figure 3.41 tableau de bord du serveur local .............................................................. 91

Figure 3.42 tableau d’acceptance ................................................................................ 92

Figure 3.43 tableau conception physique ..................................................................... 93

Figure 3.44 tableau de l’implémentation ..................................................................... 93

TFC_ESIS_AS
 Page |8

LISTE DES TABLEAUX

Tableau 1.1 Description détaillée des villes minières ................................................... 26

Tableau 1.2 plan d’adressage d’ANONYMOUS ........................................................... 27

Tableau 1.3 plan de nommage d’ANOMOUS ............................................................... 27

Tableau 2.1 comparaison outils de conteneurisation.................................................... 56

Tableau 2.2 comparaison outils gestion de base de données ........................................ 59

Tableaux 2.3 scénario du CU conteneuriser le service ................................................. 70

Tableau 2.4 scénario du CU déployer le service .......................................................... 70

Tableau 3.1 d’évaluation des besoins fonctionnel ........................................................ 94

Tableau 3.2 Evaluation besoins non fonctionne .......................................................... 95

TFC_ESIS_AS
 Page |9

LISTE DES ACRONYMES

SSH: Secure Shell

AWS: Amazon Web Services

NAS: Network Attached Storage

IT: Information Technology

OS : Operating System

ANBE : Analyse de besoins

ANEF : Analyse Exigence Fonctionnel

ANEN : Analyse Exigence Non fonctionnel

ANFO : Analyse Fonctionnalités

PAAS: Platform As A Service

IAAS: Infrastructure As A Service

SAAS: Software As A Service.

VM: Virtual Machine

IP: Internet Protocol

LAN: Local Area Network

AMI: Amazon Machine Images

PDG : Président directeur général

MAC : Media Access Control

WIFI : Wireless Fidélité

RDC : République démocratique du Congo

TFC_ESIS_AS
 P a g e | 10

TABLE DES MATIERES

EPIGRAPHE................................................................................................................. 2
DEDICACE .................................................................................................................. 3
REMERCIEMENTS ..................................................................................................... 4
LISTE DES FIGURES .................................................................................................. 5
LISTE DES TABLEAUX ............................................................................................. 8
LISTE DES ACRONYMES .......................................................................................... 9
AVANT-PROPOS ...................................................................................................... 13
CHAPITRE 0 INTRODUCTION GENERALE ........................................................... 14
0.1. Aperçu général .............................................................................................. 14
0.2. Problématique ............................................................................................... 14
0.3. Hypothèse ..................................................................................................... 16
0.4. Choix et intérêt du sujet ................................................................................. 17
0.4.1. Choix du sujet ........................................................................................ 17
0.4.2. Intérêt du sujet ....................................................................................... 17
0.5. Méthodes et techniques ................................................................................. 18
0.5.1. Méthodes ............................................................................................... 18
0.5.2. Techniques ............................................................................................. 18
0.6. Etat de l’art ................................................................................................... 19
0.7. Délimitation du travail ................................................................................... 20
0.8. Subdivision du travail .................................................................................... 20
0.9. Outils logiciels et équipements utilisés .......................................................... 20
0.9.1. Logiciels ................................................................................................ 21
0.9.2. Matériels ................................................................................................ 21
CHAPITRE 1 SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME ..... 22
1.1. Introduction................................................................................................... 22
1.2. Présentation de l’entreprise............................................................................ 22
1.2.1 Situation géographique ........................................................................... 22
1.2.2 Organisation ........................................................................................... 22
1.2.3 Organigramme d’ANONYMOUS .......................................................... 23
1.3. Etude du réseau existant ................................................................................ 24
1.3.1. Contexte................................................................................................. 24

TFC_ESIS_AS
 P a g e | 11

1.3.2. Activités de la société ............................................................................. 25

1.3.3. Sites Miniers .......................................................................................... 25
1.3.4. Description des sites ............................................................................... 25
1.3.5. Description détaillée des villes minières ................................................. 25
1.4. Infrastructure Réseau et Système existante .................................................... 26
1.5. Architecture logique de l’entreprise ............................................................... 27
1.5.1. Plan d’adressage ..................................................................................... 27
1.5.2. Plan de nommage ................................................................................... 27
1.6. Architecture physique de l’entreprise ............................................................ 28
1.6.1. Support de transmission ......................................................................... 28
1.6.2. Elément constitutifs ................................................................................ 28
1.7. Architecture .................................................................................................. 29
1.8. Plan de continuité de service existant ............................................................ 31
1.8.1. Introduction............................................................................................ 31
1.8.2. Extrait du plan de continuité de service de l’entreprise ........................... 31
1.9. Critique du système ....................................................................................... 32
1.9.1. Points forts ............................................................................................. 32
1.9.2. Points faibles .......................................................................................... 33
1.10. Spécification des besoins et exigences (nouveaux besoins) ............................ 34
1.10.1. Spécification des besoins ........................................................................ 34
1.10.2. Exigences ............................................................................................... 38
1.10.2.1. Exigences fonctionnelles .................................................................... 38
1.10.2.2. Exigences non fonctionnelles .............................................................. 39
1.11. Liste des fonctionnalités ............................................................................ 39
1.11.1. Fonctionnalités principales ..................................................................... 40
1.11.2. Fonctionnalités secondaires .................................................................... 40
1.12. Conclusion partielle ................................................................................... 40
CHAPITRE 2 CONCEPTION DU SYSTEME ............................................................ 41
2.1. Introduction................................................................................................... 41
2.2. Type d’abstraction appliquéeinge à la conception [2] .................................... 41
2.2.1. Conception générale ............................................................................... 42
2.2.1.1. Solution par rapport aux besoins ......................................................... 42
2.2.1.2. Concepts de base d’un cloud computing ............................................. 42
2.2.1.2.1. Mode de déploiement ......................................................................... 43
2.2.1.2.2. Types de services cloud ...................................................................... 43

TFC_ESIS_AS
 P a g e | 12

2.2.1.3. Architecture Logique du système ........................................................ 45

2.2.2. Conception détaillée logique .................................................................. 47
2.2.2.3. VM du serveur de conteneur ............................................................... 51
2.2.2.5. Protocole de transfert .......................................................................... 53
2.2.2.6. Hyperviseur de type 1 ......................................................................... 53
2.2.2.7. Environnement conteneur ................................................................... 54
2.2.3. Conception physique .............................................................................. 55
2.2.3.1. Choix de la technologie ...................................................................... 55
1. Présentation de DOCKER ............................................................................. 56
2. Présentation de PostgreSQL .......................................................................... 60
3. Présentation d’Amazon Web Service ............................................................. 66
2.3. Planification .................................................................................................. 71
2.3.1. Plan d’installation ...................................................................................... 72
2.3.2. Plan de configuration ................................................................................. 72
2.3.3. Plan de test ............................................................................................. 72
2.3.4. Plan d’implémentation ........................................................................... 73
2.4. Conclusion partielle....................................................................................... 73
CHAPITRE 3 MISE EN PLACE DE LA SOLUTION ................................................ 74
3.1. Introduction................................................................................................... 74
3.1.1. Ubuntu 20.04 ......................................................................................... 74
3.1.2. Docker ................................................................................................... 74
3.1.3. PostgreSQL ............................................................................................ 76
3.1.4. AWS EC2 .............................................................................................. 78
3.1.6. Evaluation des besoins ........................................................................... 94
3.1.6.1. Besoins fonctionnels ........................................................................... 94
3.1.6.2. Besoins non fonctionnels .................................................................... 95
3.2. Discussion ..................................................................................................... 95
CONCLUSION GENERALE ...................................................................................... 96
Bibliographie............................................................................................................... 97

TFC_ESIS_AS
 P a g e | 13

AVANT-PROPOS

Dans ce travail nous garantissons un plan de continuité des services pour une
haute disponibilité. Ce plan va consister en une virtualisation plus légère 1 des services et
en leur stockage dans un environnement extérieur qui est le cloud. Notons qu’un réseau
informatique d’entreprise dont l’administrateur système ne détient pas d’informations est
un réseau qui est exposé chaque fois à l’indisponibilité des services. De ce fait, en tant
qu’administrateur système nous avons pensé à une solution de stockage externe, distant
et sécurisé et d’une synchronisation des données entre services dans le but de résoudre
les problèmes d’anomalie et d’inactivité des services, d’un arrêt des services que bon
nombre d’entreprises rencontrent.

1
On parle de conteneurisation qui est une méthode qui permet de virtualiser, dans un conteneur, les
ressources matérielles systèmes de fichiers, réseau, processeur, mémoire vive, etc. nécessaires à
l'exécution d'une application. [16]

TFC_ESIS_AS
 P a g e | 14

CHAPITRE 0 INTRODUCTION GENERALE

0.1. Aperçu général

Aujourd’hui plus que jamais, les entreprises sont exposées à des risques majeurs
d’origines diverses (climatiques, pandémies, accidents, malveillances, conflits sociaux,
défaillances techniques, erreurs,). Ces risques peuvent entrainer de véritables sinistres
pouvant avoir des conséquences gravissimes, voire définitives sur leurs activités et leurs
missions.

Le plan de continuité de service est appelé à gérer des situations imprévues

pouvant entrainer des chocs extrêmes ayant pour conséquence une incapacité à
redémarrer les activités et de fournir les services attendus par les clients ou les usagers.
L’impact est alors extrêmement grave, perte financière lourde, perte de confiance des
clients, des partenaires, sanction civile ou pénale, etc. Selon une étude faite par Disaster
Recovery Institue International2, au canada, 43% des entreprises ferment après un sinistre
et 29% de celles qui survivent périclitent dans les deux ans qui suivent. [1]

Pour un réseau évolutif, les entreprises prennent en charge la modernisation de

l’infrastructure pour une rapidité, flexibilité et une évolutivité rentables d’où l’intérêt de
notre sujet qui est la mise en place d’un plan de continuité des activités ; ce plan va
consister à conteneuriser les services d’un réseau local et de les déployer sur un stockage
externe qui est le cloud. Les entreprises n’auront pas besoin d’utiliser une architecture
physique avec un grand nombre d’équipements notamment des serveurs de stockage et
n’auront plus besoin de dépenser pour l’entretien des équipements afin de faire
fonctionner les services ainsi les services auront du mal à être indisponibles. Cette
solution offre un bon rendement et un espace de travail confortable.

0.2.Problématique

Il n’est pas toujours facile de gérer l’allocation des ressources des serveurs
virtuels déployés sur différents serveurs physiques ainsi que le nombre fastidieux des
machines virtuelles qui y tournent pour différentes applications. Les pannes brusques que
rencontre le matériel physique ne durent que quelques heures ou quelques minutes mais
représentent une perte d’argent colossale. Le remplacement des équipements en panne est

2
Disaster Recovery Institute International est une organisation à but non-lucratif qui aide les entreprises du
monde entier à se préparer et à se remettre des catastrophes en fournissant une formation, et un leadership
éclairé dans la continuité des activités, la reprise après sinistre, la cyber-résilience et les domaines connexes
[17]

TFC_ESIS_AS
 P a g e | 15

une charge pour l’entreprise par les dépenses qui doivent être effectuées, l’entretien et la
maintenance d’un parc informatique en local est une lourde tâche pour les employés.

Plus le nombre d’information à traiter augmente ou le nombre d’application

hébergées sur les serveurs est élevé, plus il y a lenteur dans le stockage interne des
données et le réseau devient moins performant. Les informations dites critiques de
l’entreprise ne sont plus conservées correctement. Les services déployés dans un LAN ne
sont accessibles qu’en local ce qui alourdit encore la tâche aux administrateurs qui doivent
travailler sur place. Le but étant de maximiser le plus possible les ressources dans une
entreprise et d’alléger les coûts tout en offrant un déploiement rapide et une haute
disponibilité des services.

Les données les plus critiques se trouvent généralement dans les bases de
données. Une entreprise ne peut pas fonctionner sans accès à ses données, et dans certains
cas, les données définissent l'entreprise. Ces données doivent être protégées.

L'autre aspect de la protection des données est la récupération des

données. Lorsque les données sont inaccessibles, l'entreprise est affectée et peut être
inopérante jusqu'à ce que les données soient restaurées. Enfin, la plupart des bases de
données doivent être protégées contre les catastrophes, ce qui signifie maintenir une
réplique de la base de données. La réplique doit être suffisamment à jour, et elle doit être
rapide et simple pleinement opérationnelle.

Après notre recherche au sein de l’entreprise ANONYMOUS3, nous avons

remarqué plusieurs problèmes précités qui ont attirés notre attention sur ce qui est de son
infrastructure réseau. Etant appelé à être évolutif, cette dernière devra être à mesure de
prendre en charge des nouvelles technologies tout en gardant l’intégrité du système
existant. Parmi ces nombreuses difficultés que rencontrent l’entreprise nous nous sommes
penchés sur les plus importantes selon nos connaissances et aptitudes acquises au cours
de notre cursus universitaire dont :

 La gestion des ressources du réseau

 La mise à jour du réseau
 La récupération des données après catastrophes
 Le plan de continuité des activités
 La maintenance régulière des services

Tout en tenant compte des équipements que constituent l’infrastructure de

ANONYMOUS, proposer une solution d’administration qui permettrait de résoudre les

3
Anonymous : une entreprise anonyme

TFC_ESIS_AS
 P a g e | 16

quelques problèmes énumérés ci-haut. Pour ce faire nous nous sommes posés quelques
questions :

 Etant buter à un problème où l’infrastructure réseau ne répond pas aux

exigences d’un réseau évolutif, comment arriver à améliorer ce dernier sans le changer ?
 Comment rendre les services déployés sur le réseau indépendant de leurs
multiples systèmes d’exploitation quels qu’ils soient ?
 Les taches de la maintenance matérielle et logicielle des applications dans
l’entreprise deviennent souvent fastidieuses pour les administrateurs car pour une
disponibilité liée aux services on doit se rassurer que les matériels sur lesquels ces
services sont déployés fonctionnent correctement et sans contrainte, comment arriver à
réduire les coûts et tâches de la maintenance tout en gardant ces services en
fonctionnement ?
 Quel système de résilience pour la protection des données mettre en place
qui pourrait contribuer à la continuité des services après un sinistre qui intervient
involontairement et brusquement dans l’entreprise ?

0.3.Hypothèse

Pour répondre aux questions posées dans la problématique, plusieurs solutions

peuvent être envisagées selon différents domaines. Pour notre part, en tant
qu’administrateur systèmes, la solution apportée constitue même le soubassement de
notre travail et nous y répondrons dans la suite de la manière suivante :

Etant donné que l’entreprise vise un grand profit, nous essayerons de mettre en
place un système de virtualisation qui est la conteneurisation des services qui devra
permettre d’expédier ces services et de garantir que leur contenu est identique au départ
et à l’arrivée dans le nouvel environnement, de garantir la sécurité grâce à leur mise en
isolation. Ces applications seront indépendantes du système d’exploitation et du support
physique. D’où nous répondons à la préoccupation liée à la dépendance des applications
de leur système d’exploitation ainsi qu’aux tâches réduites sur la maintenance logicielle.

Le système va déployer des services mis en isolation sur un stockage externe

alloué pour l’entreprise. Cette solution donne la possibilité d’accéder à distance aux
services de l’entreprise sans interruption. On aura plus à se soucier du matériel à
remplacer à chaque incident ou d’une panne physique parce qu’une partie des données
dites critiques de l’entreprise seront stockées dans un nuage informatique appelé cloud.
D’où nous répondons au problème lié aux tâches fastidieuses de la maintenance matérielle
et à la reprise après catastrophe des services

TFC_ESIS_AS
 P a g e | 17

Vu que les services sont mis en conteneur, à partir du Cloud et moyennant une
connexion internet, l’administrateur peut les déployer à n’importe quel moment, à
n’importe quel endroit indépendamment du système d’exploitation et du support
physique. Et pour ce qui concerne la connexion internet, en cas de problème il est possible
de travailler en synchronisation c’est à dire que la grande partie des données est sur le
Cloud, on travaille en local avec l’application et lors du rétablissement de la connexion
les nouvelles données ou mises à jour sont directement transmises sur le Cloud.

0.4.Choix et intérêt du sujet

0.4.1. Choix du sujet

Le choix est au départ motivé par le souci d’améliorer les réseaux d’entreprises
en République Démocratique du Congo et plus précisément les entreprises de l’Etat les
initier à la modernisation de leur infrastructure réseau, à maitriser les nouvelles
technologies afin de contribuer au développement de notre pays.

L’idée de mettre en place cette solution est venue après avoir passé notre stage
dans l’entreprise ANNONYMOUS. Vu les problèmes que l’entreprise peut rencontrer en
cas d’indisponibilité d’un service important ou d’une grande lenteur des services déployés
sur le serveur suite à une augmentation des utilisateurs. Ainsi, étant administrateurs
systèmes et réseaux, nous sommes caractérisés par le sens de la découverte et de
l’innovation afin d’être plus performant dans ce domaine.

0.4.2. Intérêt du sujet

L’intérêt se situe aux différents points :

 Du point de vue personnel

Ce travail est d’une importance capitale parce qu’il nous permet de tester nos
capacités à résoudre un problème dans la société et à nous adapter aux nouvelles
technologies pour ainsi nous mettre à jour.

 Du point de vue scientifique

Ce travail va apporter un plus dans le monde scientifique pour toute personne

qui désire se documenter ou apprendre plus sur ce sujet : il constitue une source
d’inspiration.

 Du point de vue social

Cette solution va permettre aux entreprises de rendre leurs services totalement

disponibles et évolutifs cette solution permettra aux centres d'excellence d'ameliorer la productivité des employés
en garatissant une tranparence et simplicité dans leurs maniere collabrer et travailler
ensemble.

TFC_ESIS_AS
 P a g e | 18

0.5.Méthodes et techniques

Au cours de notre travail, nous utiliserons quelques méthodes et techniques qui

nous permettront de mener à bien notre projet. La méthode étant la manière de conduire
sa pensée, de dire ou de faire quelque chose suivant certains principes et avec un certain
ordre

La technique est l’ensemble des procédés raisonnées. Nous sommes sans

ignorer qu’il en existe plusieurs permettant de recueillir les informations essentielles
devant nous permettre de mener à bon terme nos recherches scientifiques question d’avoir
un enchaînement logique pour l’élaboration de notre travail de fin de cycle.

0.5.1. Méthodes

 Top down design : dans cette méthode nous partons du plus haut niveau
d’abstraction au plus bas niveau en utilisant des modèles abstraits dits
d’analyse qu’on transforme en modèle logique capable de résoudre le
problème de façon indépendante de la technologie. Pour rendre concret le
système il faut utiliser des modèles physiques qui implémentent des
modèles logiques.

 Bottom up : cette méthode nous a permis d’utiliser des composants

techniques existants sur le marché pour obtenir après assemblage un
système physique qui répond aux exigences des modèles logiques obtenus
par le top down design. Cette approche qui part du plus bas niveau vers le
plus haut niveau est appelé bottom up

0.5.2. Techniques

 Documentation : elle nous a servi à recueillir des documents dans le but de

mener des études vraies et réelles. Cette méthode nous a permis à avoir les
connaissances nécessaires sur ce sujet, afin de mener à bien ce travail.

 Interview : C’est une technique d’échange qui nous a permis de nous

entretenir avec les experts sur la matière, poser des questions à nos encadreurs
et à d’autres ingénieurs administrateurs sur la solution qui fait sujet de notre
travail.

 Traçabilité : qui nous a permis de suivre l’évolution du projet, depuis l’étape

de l’analyse jusqu’à son implémentation en attribuant à chaque étape des
numéros spécifiques.

TFC_ESIS_AS
 P a g e | 19

0.6.Etat de l’art
Pour mieux comprendre et bien avancer avec notre travail, nous nous sommes
référés à d’autres travaux ou documentations. Nous pouvons citer :

NSEYA KALALA Alice de l’école supérieure d’informatique Salama (2018-

2019) dans « migration des applications traditionnelles vers les conteneurs » dans ce
travail il a été question de mettre en place un système de conteneurisation pour empêcher
l’interruption brusque des services causée par un dysfonctionnement au niveau des
serveurs ainsi faire la migration vers les conteneurs pour permettre la mise à niveau des
applications traditionnelles vers une technologie moderne moins exigeante et efficace.

KALOMBO TSHONY Ephraïm de l’école Supérieure d’Informatique Salama

(2018-2019) dans « la conteneurisation et le clustering sous proxmox » dans ce travail, il
s’est basé sur l’aspect d’équilibrage des charges. Il a mis en place un système de
conteneurisation d’une application sur docker swarm pour permettre sa légèreté, sa
performance ainsi gagner en espace et la redondance de plusieurs serveurs regroupés dans
des clusters sur lesquels le docker swarm a été reparti. Cette solution a permis de rendre
accessible une application indépendamment du nombre d’utilisateur qui y accèdent.

TSHAMALA TSHISABI Murphy de l’école supérieure d’informatique Salama

(2017-2018) dans « Conception d’un système de découverte et de haute disponibilité en
vue d’assurer une gestion centralisée » dans ce travail est question d’implémenter un
système qui prend en charge l’orchestration des conteneurs pour une optimisation et une
gestion pour l’usage de son infrastructure. Il a envisagé de sécuriser les déploiements en
misant sur les disponibilités de services gérer les liens entre conteneurs et les
interconnexions.

MUKENDI KABONGO Jonathan de l’école supérieure d’informatique Salama

(2017-2018) dans « conception d’une solution de monitoring des conteneurs Docker »
dans ce travail est question de de détecter les causes majeures qui entrainent les
conteneurs dans un état inactif et envisager une solution de monitoring adapté à Docker.

MUPENGELE KABAMBA Fabrice de l’école supérieure d’informatique

Salama (2018-2019) dans « étude et mise en place d’un serveur TFP dans le cloud
computing pour les entreprises » dans ce travail il est question d’une mise en place d’un
serveur FTP autonome indépendant du parc informatique physique afin d’assurer la haute
disponibilité des services.

Contrairement aux ingénieurs cités ci-haut, notre travail se démarque dans le fait
que nous travaillons sur la haute disponibilité des conteneurs réalisés à l’aide du cloud
comme site de recouvrement distant.

TFC_ESIS_AS
 P a g e | 20

0.7. Délimitation du travail

Dans le temps, il sied de noter que ce travail couvre la période allant du mois
d’Octobre 2019 au mois de Mars 2021.

Dans l’espace, ce travail se focalise sur l’infrastructure réseau de l’entreprise

ANONYNOUS comme cas d’application et se limite aux seules réalités de cette dernière
dont 99% des applications sont hébergées en local ainsi que la sauvegarde des données
de ces dernières.

Nous nous sommes limités au déploiement des applications virtualisées avec docker sur
les serveurs virtuels hébergées dans le cloud d’Amazon et gérer la synchronisation des
données entre le réseau local et le cloud.

0.8. Subdivision du travail

Hormis l’introduction et la conclusion générale, trois chapitres constituent le
fruit de notre recherche ou de notre projet :

Premier chapitre : « SPECIFICATION FONCTIONNELLE DU FUTUR

SYSTEME » : nous verrons dans ce chapitre un bref aperçu historique de l’entreprise qui
est notre cas d’application, nous étudierons son existant ensuite viendra les besoins
fonctionnels et non fonctionnels, les points forts et faibles et nous chuterons par les limites
et une conclusion

Deuxième chapitre : « CONCEPTION DU SYSTEME » : dans ce chapitre, nous

parlerons de l’architecture générale, de la conception logique jusqu’au moindre détail de
notre système enfin de la conception physique en faisant référence au choix de différentes
technologies à utiliser pour la réalisation de notre système parmi celles qui existent en se
basant sur différents critères que nous allons tracés

Le chapitre trois : « MISE EN PLACE DE LA SOLUTION » ici, il sera donc

question de la réalisation et de l’implémentation dudit système.

0.9. Outils logiciels et équipements utilisés

Afin d’élaborer notre travail, nous avons eu recours aux équipements et logiciels
suivants :

TFC_ESIS_AS
 P a g e | 21

0.9.1. Logiciels

 GANTT Project
 VMware 15pro pour la virtualisation
 Microsoft Excel pour différents diagrammes en radar4
 Draw.io pour la modélisation du travail
 Microsoft office Word 2016 pour la saisie du travail
 Microsoft office Visio

0.9.2. Matériels
 Ordinateur portable de 8 Giga de RAM
 Compte cloud Amazon

4
Diagramme en Radar : diagramme en radar, en étoile ou encore en toile d'araignée sert à représenter
sur un plan en deux dimensions au moins trois ensembles de données multivariées. Chaque axe, qui
part d'un même point, représente une caractéristique quantifiée.

TFC_ESIS_AS
 P a g e | 22

CHAPITRE 1 SPECIFICATIONS FONCTIONNELLES DU FUTUR SYSTEME

1.1.Introduction

Dans la mesure où nous devons poursuivre correctement notre travail et être sûr
de mettre en place une solution qui répondrait aux besoins en matière de gestion de
ressource matérielle et de haute disponibilité des services, ce chapitre donnera un aperçu
détaillé sur l’entreprise ANONYMOUS, pris comme cas d’application, ainsi que son
infrastructure réseaux. Après l’étude du réseau existant et d’une critique de cette
infrastructure, nous dégagerons les points faibles qui feront sujet de notre conception et
de l’implémentation de notre travail.

1.2.Présentation de l’entreprise

Pour des raisons de sécurité et de clause de confidentialité auxquelles nous avons

été soumis, nous ne pouvons pas divulguer le nom de la société pour laquelle nous
travaillons, c’est pourquoi certaines informations seront anonymes.

1.2.1 Situation géographique

Notre société se trouve dans la région minière du grand Katanga ; (haut Katanga
et Lualaba).

1.2.2 Organisation

L’entreprise possède une organisation standard et typique des sociétés minières.

A sa tête il y a le Président Directeur Général, suivi des Directeurs généraux qui

supervisent les Directeurs généraux chargés des opérations, les chargés de
l’administration et finances, de l’environnement, de la santé et de la sécurité au travail.
Puis les Managers qui sont gérés par les directeurs généraux, voici quelques Manager :

 Manager de la mine
 Manager de l’exploitation minière
 Manager des usines de traitement rapporte au directeur général des
opérations.

Les Managers chapotent les super intendants généraux, à leurs tours ils chapotent
les super intendants.

 PDG
 Directeurs généraux

TFC_ESIS_AS
 P a g e | 23

 Directeur général chargé des opérations et les Chargés de l’administration

et finance
 Directeur général chargé de l’environnement, de la santé et de la sécurité
su travail
 Manager de la mine
 Manager de l’exploitation minière
 Manager des usines de traitement rapporte au directeur général des
opérations.
 Les super intendants

Le département IT dépend des opérations.

1.2.3 Organigramme d’ANONYMOUS

Figure 1.1 organigramme d’ANONYMOUS

TFC_ESIS_AS
 P a g e | 24

1.3.Etude du réseau existant

Cette section traite respectivement l’infrastructure système et réseau

existante afin de pouvoir y insérer notre future solution, ainsi que le service
d’administration des centaines applications des serveurs et son organisation en vue d’en
déduire les points forts et les points à améliorer qui nous permettrons d’établir les
exigences auxquelles le futur système devra répondre.

1.3.1. Contexte

Une société minière en RDC intègre en son sein un département informatique

qui gère son système d’information. Celui-ci est basé sur le produit SAP 5, mais possède
également plusieurs systèmes informatiques qui gèrent les différents domaines de
production minière et la productivité de l’entreprise. Nous pouvons citer entre autres :
 Un système de contrôle de processus industriel qui est séparé du réseau
business par un firewall.
 Un ensemble d’applications de gestion administrative telle que le pointage
automatique, le contrôle d’accès pour la sécurité physique etc.
 Un ensemble d’applications qui regroupe les communications unifiées, la
messagerie, les services d’infrastructure système et réseaux etc.

Tous ces systèmes (plus de 100 serveurs) sont hébergés sur des serveurs
virtuels pour la plus part. Les serveurs sont localisés principalement dans un Datacenter
construit sur une infrastructure VSAN6 (VMware hyper-convergée). Un réseau
d’entreprise reliant les sites éloignés par MPLS 7 permet de couvrir tous les bureaux et
opérations de la société.

Ces systèmes sont gérés traditionnellement par une équipe IT avec une
structure très minimale. Cette gestion traditionnelle non basée sur la modélisation
d’entreprise donne tout de même des résultats plus ou moins satisfaisants.

A court terme, les choses semblent bien marcher, mais la gouvernance IT

n’est pas optimale. La gestion opérationnelle des systèmes est manuelle et complexe.
L’ingénierie et le développement sont négligés dans le département. Des problèmes
sociaux au sein de l’équipe IT empêchent un meilleur professionnalisme dans le travail
avec d’éventuelles conséquences qui peuvent s’en suivre à long terme.

5
System, Applications and products ; est un progiciel de gestion intégré
6
Virtual San ; est une solution de stockage de classe d’entreprise partagée et extrêmement simple.
7
Multi Protocol Label Switching, est un mécanisme de transport de données basé sur la communication de
labels.

TFC_ESIS_AS
 P a g e | 25

1.3.2. Activités de la société

Exploitation minière pour la production du cuivre et du cobalt.

1.3.3. Sites Miniers

La société est implantée dans trois villes de la RDC, parmi lesquelles nous
nommons :

 Kolwezi
 Kambove
 Lubumbashi

Il n’y a que deux villes qui comportes des sites miniers (kambove et Kolwezi) à
Lubumbashi il y’a les bâtiments administratifs et les Datacenter

1.3.4. Description des sites

La société est implantée dans les villes suivantes :

a. Kolwezi :

La ville de Kolwezi possède 3 sites miniers, parmi lesquels :

 Un site minier qui comporte une usine hydro métallurgique avec 5 mines
à ciel ouvert
 L’autre site comprend une mine souterraine et deux mines à ciel ouvert.
 Un site se trouve à Kolwezi et un autre à Kambove

Le site minier de Kolwezi est divisé en plusieurs zones.

b. Kambove : possède trois sites miniers et un site administratifs

c. Lubumbashi : La société possède un site administratif qui est le siège de la
société.
1.3.5. Description détaillée des villes minières

A Kolwezi il y a trois sites administratifs qui supportent les opérations minières

et de traitement. Parmi les trois il y en a un où se trouve le camp des travailleurs qui sont
logés par la société, un site consacré à la logistique, un site pour l’administration générale.
Le bâtiment administratif de la logistique a deux niveaux, chaque niveau compte 100
utilisateurs. Le bâtiment administratif de l’administration générale possède 3 niveaux. Il
y a 10 bureaux éparpillés à la logistique qui iront sur le core switch de la logistique. Il y
a 20 bureaux éparpillés dans tous le camp.

A la mine (opération de la mine) il y a un bureau administratif de deux niveaux

de 50 personnes, bureaux éparpillés 5.

TFC_ESIS_AS
 P a g e | 26

A l’usine (site des opérations métallurgiques) de Kolwezi il y a deux bâtiment à

deux niveaux et un niveau (le ré de chaussé et le premier étage) et a à peu près 100
utilisateur. Il y a à peu près 15 bureaux éparpillés connecté à la distribution switch de
l’usine ce sont des switches à 8 ports chacun.

Un dispatch informatisé gère la flotte des engins miniers, il est situé à une
distance de 30 km par rapport au centre-ville, l’usine possède aussi des bureaux
techniques pour la gestion des opérations métallurgiques. Site des bureaux pour les
opérations de la mine. Il est éloigné des bureaux des opérations minières de 1km, c’est un
petit bureau avec un Access switch de 24 ports relié à la distribution d’ops.

Kambove : Les même sites que ceux de Kolwezi ; Site administratif, 1 niveau
qui sera connecté au site de télécom, Bureau administratifs chargé de l’administration et
de la logistique.

Tableau 1.1 Description détaillée des villes minières

Villes Opération(s) Bureau Niveau(x) Nombres

agents
Kolwezi Mines 5 2 50
Métallurgies 15 3 100
Administration 1 1 -
Telecom 1 1 -

Kambove Mine 5 2 50
Métallurgies 15 4 150
Administration 1 1 -
Telecom 1 1 -

1.4.Infrastructure Réseau et Système existante

L’infrastructure réseau de L’Entreprise est composée de plusieurs sites

distants (Kolwezi, Kambove, Lubumbashi), lesquels sont interconnectés par le
fournisseur d’accès internet VODACOM.

TFC_ESIS_AS
 P a g e | 27

1.5.Architecture logique de l’entreprise

1.5.1. Plan d’adressage

Le plan d’adressage a pour but de définir pour chaque réseau physique une
adresse de réseau IP8 ainsi que pour chaque machine qui se connecte à ce réseau.

Voici comment se présente l’architecture logique du réseau :

Tableau 1.2 plan d’adressage d’ANONYMOUS

Sites Adresses réseaux Plages Masques

Lubumbashi 192.168.12.0 192.168.12.1-

192.168.12.255 255.255.255.0

192.168.13.0 192.168.13.1- 255.255.255.0

192.168.13.255

Kolwezi 192.168.14.0 192.168.14.1- 255.255.255.0

192.168.14.255

Kambove 192.168.15.0 192.168.15.1- 255.255.255.0

192.168.15.255

1.5.2. Plan de nommage

C’est un ensemble de règles qui sont régis au sein d’un système

informatique pour pouvoir nommer les différents équipement que nous possédons au sein
de ce dernier et ce plan va permettre à IT de pouvoir identifier tous qu’il a au sein de son
parc informatique.

Tableau 1.3 plan de nommage d’ANOMOUS

Sites Accès point Switch Serveur Routeur

Kolwezi AN_ap_klz01 AN_sw_klz01 AN_rt_klz01 AN_srv_klz01

Lubumbashi AN_ap_lub01 AN_sw_lub01 AN_rt_lub01 AN_srv_lub01

Kambove AN_ap_kbv01 AN_sw_kbv01 AN_rt_kbv01 AN_srv_kbv01

8
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.

TFC_ESIS_AS
 P a g e | 28

Dans le cas de notre plan de nommage la première partie(AN) représente

l’entreprise ; ANONYMOUS, la deuxième identifie l’équipement, la troisième identifie
le site.

1.6.Architecture physique de l’entreprise

1.6.1. Support de transmission

Le support de transmission sont permettent aux équipements des communiquer

entre eux d’échanger des informations. Ce support peut simplement être un câble réseau,
composé d’un fil de cuivre ou de cuivre optique. Dans d’autres cas c’est un media sans
fils, à base de la technologie à base d’infrarouge, d’ondes radio ou de microondes.

Pour l’infrastructure réseau d’ANONYMOUS les supports de transmission

utilisés sont :

 Media filaire : nous avons les câbles coaxiaux, câble UTP9 catégorie 5 et
6 utiliser pour connecter les hôtes aux équipements réseaux ; la fibre
optique utilisé pour interconnecter les bâtiments éloignés
 Media sans fils : le wifi ; il émet des ondes et rayonne sur tout le périmètre
de l’entreprise, il permet aussi d’interconnecter les différents guest house
sur diffèrent sites.
1.6.2. Elément constitutifs

 Les points d’accès ou Access points : permettent de fournir un bon niveau de

signal réseau WIFI sur tout l’étendu de l’entreprise ; il en a comme model Uapro
et Uae wifi.
 Le pare-feu : nous permet de filtrer les trafics, définir les communications qui
peuvent être faites sur le réseau, le paquet entrant et sortant.
 Les switchs : équipements réseau utilisé pour interconnecter les équipements sur
le réseau.
 Les serveurs

La Société possède plusieurs Serveurs dans son Datacenter, parmi lesquels nous
pouvons cités :

 Serveur de base des données

 Serveur de messagerie
 Serveur de fichier et d’impression
 Serveur de Share point

9
Unshielded Twisted Pair (paire torsadée non blindée) ; une ligne symétrique formée de deux fils
conducteurs enroulés en hélices l’un autour de l’autre.

TFC_ESIS_AS
 P a g e | 29

 Serveur de communication unifiée (Voice, vidéoconférence)

 Virtualisation, stockage
 Serveur proxy
 Serveur d’application (application sous Windows et sous linux)
 Contrôleur de Domaine.

1.7.Architecture

TFC_ESIS_AS
 P a g e | 30

Figure 1.2 topologie physique d’ANONYMOUS

TFC_ESIS_AS
 P a g e | 31

1.8. Plan de continuité de service existant

1.8.1. Introduction

Le but d’un plan de continuité est de fournir un outil de référence des actions à
prendre pendant ou immédiatement après une urgence ou un accident qui a occasionné
l’interruption normale des actions ou des activités.

- Urgence

Une situation réelle ou imminente qui peut occasionner des blessures, perte de
vie, destruction des biens, ou causer des interférences, perte ou perturbation des
opérations normales d’une organisation à tel point qu’elle constitue une menace

- Incident

Est tout évènement qui peut être ou peut conduire à une interruption d’activité,
perturbation, perte et/ou crise.

Les incidents peuvent être : catastrophe naturelle, défaillance d’un équipement, incendie,
indisponibilité d’un serveur, coupure d’électricité ou un accident sous toutes ses formes.

1.8.2. Extrait du plan de continuité de service de l’entreprise

Le plan contribuera à assurer la poursuite des services essentiels aux entreprises en

minimisant l’impact de tout dommage causé aux équipements ou aux enregistrements
locaux. Le plan contribuera à inclure un niveau de détail suffisant pour maintenir les
données de l’entreprise et :

- Pour garantir une approche préparée en cas d’urgence

- Une continuité des services et des équipements après une urgence ou un incendie
- Fournir un cadre convenu dans lequel les personnes peuvent travailler dans une
manière de résoudre le problème causé par une urgence
 Etape 1 : créer un environnement de recouvrement à distance

Ce stockage est généralement hébergé par un fournisseur de service tiers, qui charge le
client en fonction de la capacité et de la bande passante utilisée. Il est aussi possible que
ce stockage off-site soit propriétaire au sein d’une entreprise.

TFC_ESIS_AS
 P a g e | 32

 Etape 2 : déplacer les données locales dans le nouvel environnement

Les données dites critiques de l’entreprise comme les bases de données doivent être
conservées et bien protégées. On implémente une replication des données en local et dans
le cloud.

 Etape 3 : créer une synchronisation des données locales avec celles du

recouvrement distant.

Pour une cohérence des données, la synchronisation est un prérequis pour l’intégrité, la
fiabilité et la permanence des données

 Etape 4 : tester une connexion aux données à distance

Se rassurer de l’accessibilité aux données à partir d’un point distant.

1.9.Critique du système

Après une longue période de stage passée au sein de l’entreprise

ANONYMOUS, plus précisément dans le département IT, nous avons constaté des points
forts et des points faibles que nous allons tacher d’énumérer dans la suite.

1.9.1. Points forts

- Une bonne organisation au sein du réseau, l’infrastructure est bien équipé en

matériel informatique moderne
- Une bonne organisation comme sur le pan de nommage
- Présence des onduleurs comme un plan de secours en cas de coupure de courant
pour les desktops
- Le wifi est sécurisé, seules les personnes autorisées peuvent se connecter
au wifi
- Il y a la présence des points d’accès qui permettent au wifi de rayonner sur toute
l’étendue de l’entreprise
- Il y a aussi la présence d’une bonne gestion de réseau, les logiciels de monitoring,
de surveillance.
- La présence de la virtualisation faite avec ESX10 et VMware
- L’évolution du réseau, les plages d’adresse qu’ils possèdent permettent d’intégrer
d’autre machine au réseau sans aucun problème

10
Est une entreprise de classe, de type 1 hyperviseur développé par VMware pour déployer et au service
des ordinateurs virtuels

TFC_ESIS_AS
 P a g e | 33

- La présence de VLAN11, chaque réseau est un VLAN et un vlan de gestion au

niveau du département IT
- Il y a aussi le WDS12 qui permet d’installer les applications à distance
- Les ordinateurs portables sont sécurisés par docking station et le câble de sécurité.

1.9.2. Points faibles

Par rapport au système présenté et à la solution envisagée, nous avons pu

ressortir les points faibles suivants :

 La gestion du parc informatique se fait manuellement :

L’entreprise ANONYMOUS étant en croissance, la gestion de son parc

informatique est de plus en plus ardue avec l’augmentation du nombre d’actifs à gérer
(matériels et/ou licences de logiciels). Le système informatique doit être maintenu à jour.
Le manque des mises à jour des logiciels de notre entreprise ne permet pas d’apporter des
nouvelles fonctionnalités et surtout de corriger les failles de sécurité de ses programmes.

Pour une bonne gestion d’un parc informatique il est possible de mettre en place :

 Un outil de gestion ;

 Confier la gestion à une agence externe ;

 Opter pour un parc informatique homogène.

Le système est soumis à plusieurs problèmes liés au réseau :

Ces divers problèmes sont principalement causés par des pertes de

données multiples ; Virus informatiques, bugs logiciels, pannes matérielles, corruption
des fichiers, incendie, inondation, vol, erreur utilisateur. Ces divers désagréments
entraînent parfois la perte de données critiques pour l’entreprise telles que les données
financières, les données clients, ou les données internes.

 La lenteur des services :

Le fait que l’entreprise soit par nature constituée de plusieurs sites a rendu
complexe la gestion et l'accès aux fichiers et aux applications quelle que soit sa taille, une
entreprise dont les sites sont géographiquement distribués utilise de plus en plus les réseaux pour
donner à ses employés l'accès aux données. Toutefois, l'accès à ces données à travers le réseau

11
Virtual LAN, est un réseau informatique logique Independent.
12
Windows Déploiement Services (les services de déploiement Windows) ; sont une technologie de
Microsoft permettant d’installer un système d’exploitation Windows via le réseau.

TFC_ESIS_AS
 P a g e | 34

se traduit souvent par des performances médiocres, ce qui impacte la productivité et mécontente
les employés.
 Le système est limité, pas d’accès à un point extérieur :

Les services de l’entreprise ne sont pas accessibles en dehors du réseau

local par conséquent les IT de l’entreprise ne peuvent pas effectuer des configurations ou
modifications sur les applications depuis un point un point distant de l’entreprise et le
réseau n’est pas évolutif.
 Manque de sécurité informatique :

Un système informatique défaillant peut-être source de pertes de données

considérables et de dégâts financiers importants. Sans dispositif performant de sécurité
informatique de l’entreprise, les risques encourus sont non négligeables. Il est vrai que la
sécurité informatique en entreprise peut être compromise de multiples façons.

1.10. Spécification des besoins et exigences (nouveaux besoins)

1.10.1. Spécification des besoins

Notre sujet étant une solution à apporter à l’entreprise ANONYMOUS, après

plusieurs rencontres avec les responsables des services (systèmes et réseaux) il en résulte
les besoins suivants :

- Mettre en place un système de virtualisation moins gourmand en termes de

ressource par rapport au système existant (ANBE-01)
- Déployer les différents services sur le stockage externe (ANBE-02)
- Rendre disponible la sécurité des services (ANBE-03)
- Avoir la possibilité de se connecter à distance (ANBE-05)
- Faciliter le déploiement des services sur n'importe quel environnement (rendre les
applications indépendantes de la plateforme) (ANBE-06)
- Avoir la possibilité de gérer de manière autonome les services (ANBE-07)
- Tester le développement du déploiement (ANBE-08)
- Fournir une bonne qualité de service (ANBE-09)
- Assurer la haute disponibilité des services (ANBE-10)
- Réduire le coût et les tâches dues à l’entretien du matériel (ANBE-11)
- Faciliter la gestion des applications (ANBE-12)
- Réduire les pannes importantes du réseau (ANBE-13)
- Garantir une maintenance régulière avec une meilleure maitrise du budget
(ANBE-14)

TFC_ESIS_AS
 P a g e | 35

Concernant notre futur système, voici le diagramme des cas d’utilisation des
fonctionnalités :

Figure 1.3 Diagramme de cas d’utilisation du système

TFC_ESIS_AS
 P a g e | 36

Scenario conteneuriser service (ANFO-SN-01)

 Cas d’utilisation : préparer environnement de conteneurisation en local

Figure 1.4 Diagramme de séquence du scénario 1

 Scénario 2 (ANFO-SN-02)
 Cas d’utilisation : configuration du cloud/ préparer le cloud

Ce scénario décriotre service de base de donnée sera déployée.

Figure 1.4 Diagramme de séquence conteneuriser service

TFC_ESIS_AS
 P a g e | 37

Scenario configurer environnement de conteneurisation (ANFO-SN-02)

 Cas d’utilisation : préparer le cloud ; ce cas d’utilisation décrit la préparation

de l’environnement du cloud

Figure 1.4 Diagramme de séquence du scénario 2

TFC_ESIS_AS
 P a g e | 38

Scenario uploader image d’un service (ANFO-SN-03)

 Cas d’utilisation : migrer image vers le cloud

Ce scénario décrit le processus de création de l’image de notre base de

données en local et de son déploiement sur l’environnement du cloud qui a été configuré
auparavant.

Figure 1.5 Diagramme de séquence du scénario 1

1.10.2. Exigences
1.10.2.1. Exigences fonctionnelles

Les besoins fonctionnels étant une réponse immédiate applicable au cas

d’application. Dans ce travail, Ce système sera en mesure donc de :

 Garantir un déploiement total des applications existantes du réseau local dans le

cloud (ANFO-EX-01) réf. étape 2 du plan de continuité ;
 Garantir un stockage externe des données du réseau local (ANFO-EX-01.1) réf.
étape 1 du plan de continuité

TFC_ESIS_AS
 P a g e | 39

 Garantir une connexion à distance au cloud de l’entreprise pour gérer les services,
y faire des modifications après s’être authentifier (ANFO-EX-02) réf. étape 4 du
plan de continuité ;
 Garantir un fonctionnement des services même en cas de panne ou de défaillance
(ANFO-EX-03) ;
 Fournir une haute disponibilité des services par une replication des données
(ANFO-EX-03.1) réf. étape 3 du plan de continuité ;
 Permettre d’approvisionner à la fois les ressources de traitement, de stockage et
du futur réseau. (ANFO-EX-04) ;
 Garantir une maintenance régulière de la part du fournisseur (ANFO-EX-05) ;

1.10.2.2. Exigences non fonctionnelles

Les besoins non fonctionnels représentent les exigences implicites auxquelles le

système doit répondre. Ainsi à part les besoins fondamentaux, notre système doit répondre
aux critères suivants :

 L’évolutivité : un stockage externe doit être intégré sans avoir à modifier le travail
de conception initiale

 La facilité d’installation : la configuration doit être compréhensive pour les

administrateurs de l’entreprise

 L’accessibilité des conteneurs : les services mis en conteneur doivent être

disponibles, léger et facile à déployer

 La simplicité d’utilisation : L’interface utilisateur doit être simple et adaptée à

l'utilisateur

 La sécurité : le système doit garantir la sécurité

 Rapidité : En effet, vu le nombre important des tâches quotidiennes, il est

impérativement nécessaire que la durée d'exécution des traitements s'approche le
plus possible du temps réel

 Fiabilité : le système en moyenne de temps doit avoir un bon fonctionnement

d’un taux de 100% soit 24h/24 (idéal)

 Disponibilité : la sûreté de fonctionnement et la reconfiguration en cas de panne

doivent caractériser le système

1.11. Liste des fonctionnalités

Après l’énumération des besoins ainsi que des exigences de notre système, cette
étape nous permet d’énumérer les fonctionnalités dont celles ; principales et secondaire.

TFC_ESIS_AS
 P a g e | 40

1.11.1. Fonctionnalités principales

 Accès à distance (ANFO-FCT-01)

 Réplication des données (ANFO-FCT-02)
 L’interopérabilité du système (ANFO-FCT-04)
 Déploiement des conteneurs du réseau local vers le cloud (ANFO-FCT-05)

1.11.2. Fonctionnalités secondaires

 Mettre à jour les conteneurs
 Automatiser le démarrage des conteneurs
 Gérer les ressources des conteneurs
 La gestion des fichiers journaux
 La gestion de la sauvegarde
 Administration et optimisation des ressources

1.12. Conclusion partielle

Comme il est toujours important d’étudier l’existant afin de mieux avancer ; ce

chapitre nous a permis de faire une analyse détaillée du système existant, comprendre et
critiquer tous les problèmes liés à la situation existante, leurs contraintes ainsi que toutes
leurs limites. Cette étude nous a servi à récolter des informations et à faire une étude des
besoins qui nous ont aidés à mieux comprendre les différentes difficultés à résoudre à
travers ce sujet. Les besoins et spécifications fonctionnelles ressortis nous ont servi de
brèche afin de passer au deuxième chapitre qui sera consacré à la conception logique
générale et détaillée de notre système.

TFC_ESIS_AS
 P a g e | 41

CHAPITRE 2 CONCEPTION DU SYSTEME

2.1.Introduction

L’étude des besoins dans le chapitre précédent nous a éclairé pour concevoir
notre système. Dans ce chapitre, les éléments d’opportunité qui nous permettrons
d’élaborer notre travail ont été épinglés dans le chapitre précédent. Les éléments de
faisabilité seront détaillés ci-dessous.

2.2.Type d’abstraction appliquée à la conception [2]

Une abstraction est définie comme étant une opération intellectuelle consistant
à isoler dans un objet un caractère. Elle consiste également à prendre en compte des
aspects importants d’un système en n’en écartant les autres pour mener à bien un travail
ou un processus pendant un instant donné.

Pour mieux comprendre un problème très complexe, il s’avère très important de

le dissocier, de le subdiviser en des petits problèmes de difficultés moindre, cela pour
arriver à les analyser un par un afin de les comprendre avec plus de détails possible. Nous
subdiviserons notre processus de conception en trois étapes :

 La conception générale ;
 La conception logique détaillée ;
 La conception physique.

La conception générale, selon le contexte, regroupe tous les éléments logiques

qui participent à la composition de notre système, il décrit à un niveau plus élevé de
l’idéalisation comment ses éléments interagissent et cela sans touché à certains critères.
En soit il fait le regroupement de ceux-ci sans pour entrer en détail, bien qu’ils
interviennent dans l’infrastructure de notre système.

La conception logique détaillée, est une charnière entre la conception générale

et la conception technique. Elle permet une description cette fois-ci non superficielle
comme dans le concept précèdent, mais vient décrire tous les éléments logiques
nécessaires qui feront l’objet de notre solution ; permettant également d’examiner et de
vérifier tous ses éléments en faisant une abstraction sur comment ceux-ci interagissent.
Son apport est aussi de faire ressortir en détails les besoins décrits précédemment, entre
autre on peut citer la gestion à distance et la replication des données qui est en fait une
partie des fonctionnalités susmentionnées.

Quant à la conception physique, elle vient mettre en œuvre la théorie décrite en

donnant plus de lumière, sur la réalisation d’une politique de conteneurisation des

TFC_ESIS_AS
 P a g e | 42

applications réseaux via un orchestrateur, et La conception générale qui est basée sur une
étude fonctionnelle du système de manière superficielle c’est-à-dire qu’elle ne tient pas
compte des détails. C’est le plus haut niveau d’abstraction. Tandis que la conception
détaillée, elle, permet une étude des sous-systèmes de notre système d’une manière
beaucoup plus approfondie. Plus les détails augmentent, plus le niveau d’abstraction
diminue et le système devient de plus en plus concret. Et ainsi notre étude est effectuée
dans ses moindres détails.

En se basant sur les différents concepts précités, nous envisageons une solution
capable de répondre aux exigences en matière de fonctionnalités décrits dans la
spécification des besoins. [3]

2.2.1. Conception générale

2.2.1.1.Solution par rapport aux besoins

Dans le chapitre premier, en vue de concevoir le nouveau système, la liste des

fonctionnalités a été évoquée. Ainsi dans la conception générale, nous parlerons
brièvement de chaque fonctionnalité selon son rôle par rapport à notre solution.

A titre de rappel, notre système aura comme fonctionnalités principales :

 Accès à distance
 Réplication des données
 L’interopérabilité du système
 Déploiement des conteneurs du réseau local vers le cloud

Et comme fonctionnalités secondaires :

 Mettre à jour les conteneurs

 Automatiser le démarrage des conteneurs
 Gérer les ressources des conteneurs
 La gestion des fichiers journaux
 La gestion de la sauvegarde
 Administration et optimisation des ressources

2.2.1.2.Concepts de base d’un cloud computing

Le cloud computing est la fourniture des services informatiques (notamment des

serveurs, de stockage, des bases de données, la gestion réseau, des logiciels, des outils
d’analyse, l’intelligence artificielle) via Internet (le cloud) dans le but d’offrir une
innovation plus rapide, des ressources flexibles et des économies d’échelle. Le cloud
computing permettra de gérer notre infrastructure plus efficacement et adapter l’échelle
des services en fonction des besoins de notre entreprise. [4]

TFC_ESIS_AS
 P a g e | 43

2.2.1.2.1. Mode de déploiement

Il existe trois modes de déploiement de services cloud :

 Public :

Un cloud public est détenu et exploité par un fournisseur de services cloud

tiers, qui propose des ressources de calcul, telles que des serveurs et du stockage, via
internet. Dans un cloud public, tout le matériel et tous les logiciels et toute l’infrastructure
sont la propriété du fournisseur du cloud. [4]

 Privé :

Un cloud privé est l’ensemble des ressources de cloud computing utilisées

de façon exclusive par une entreprise ou une organisation. Le cloud privé peut se trouver
physiquement dans le centre de données local de l’entreprise. Le cloud privé est un cloud
dans lequel les services et l’infrastructure se trouvent sur un réseau privé. [4]

 Hybride :

Le cloud hybride regroupe des cloud publics et privés, liés par une
technologie leur permettant de partager des donnés et des applications. Le cloud hybride
permet que les données et applications se déplacent entre des clouds privés et publics. [4]

2.2.1.2.2. Types de services cloud

La plupart des services de cloud computing peuvent être classés en quatre

grandes catégories : IaaS, PaaS et SaaS.

 IaaS :

Avec ce service, on loue une infrastructure informatique (serveurs,

machines virtuelles, stockage, réseaux, systèmes d’exploitation) auprès d’un fournisseur
de services cloud, avec un paiement en fonction de l’utilisation. [4]

 PaaS :

L’expression plateforme en tant que service qualifie les services du cloud

computing qui offrent un environnement à la demande pour développer, tester, fournir et
gérer des applications logicielles. [4]

 SaaS :

Le logiciel en tant que service est une méthode de diffusion d’applications

logicielles via internet, à la demande et en général sur abonnement. Avec le SaaS, le

TFC_ESIS_AS
 P a g e | 44

fournisseur de services cloud hébergent et gèrent les applications logicielles et

l’infrastructure sous-jacente, et gèrent la maintenance, par exemple la mise à niveau des
logiciels et application des correctifs de sécurité. Les utilisateurs se connectent à
l’application via internet, en général par l’intermédiaire d’un navigateur web sur leur
téléphone, leur tablette ou leur PC. [4]

Par rapport aux besoins détaillés de l’entreprise et selon le budget financier,

notre choix sur l’architecture logique va se baser sur un cloud public comme mode de
déploiement des services de l’entreprise sur le cloud et sur l’infrastructure en tant que
service (IaaS) comme type de service mis à notre disposition par le fournisseur.

Figure 2.1 Illustration de services cloud

TFC_ESIS_AS
 P a g e | 45

2.2.1.3.Architecture Logique du système

Figure 2.2 architecture logique du système

Après avoir ressortit l’architecture générale du système voici tous les modules
qui le composent :

- Le réseau local de l’entreprise qui est le Lan

- Image du service SGBD
- Machine virtuelle du serveur de conteneurisation
- Le protocole de transfert de fichier
- Internet
- IaaS service
- Environnement de conteneur
- Protocole d’accès et de transfert
- La station de travail

Voici de façon sommaire ce que fait chacun des modules ;

TFC_ESIS_AS
 P a g e | 46

1. LA N

Décrit le réseau local de l’entreprise ANONYMOUS dans lequel plusieurs

équipements sont interconnectés, notamment le serveur local qui prendra en charge le
serveur virtuel où s’effectuera la virtualisation en conteneur de notre système de gestion
de base de données. Son objectif est de faciliter le traitement et l’échange des données
entre utilisateurs de l’entreprise à une échelle géographique relativement restreinte.

2. Image du serveur SGBD :

Ce module décrit la configuration du conteneur qui va prendre en charge

notre système de gestion de base de données que nous pourrons récupérer, partager et
déployer sur l’environnement du cloud.

3. VM du serveur conteneur

Ce composant décrit la machine virtuelle sur laquelle va s’exécuter l’image

de notre service qui est un système de gestion de base de données. C’est sur cet
environnement que sera configuré notre conteneur.

Le conteneur possède la capacité de s’exécuter sur n’importe quel système

d’exploitation serveur, que ce soit Windows ou Linux, et de fonctionner avec d’autres
systèmes informatiques existants ou futurs, sans restriction d’accès ou de mise en œuvre.
A cet aspect, s’associe la réplication des données de manière synchrone qui peut être
considérée comme un backup.

4. Protocole de transfert de fichier

Ce bloc va permettre de déplacer l’image de notre système de gestion de base

de données du local vers le cloud et de se connecter en toute sécurité à notre serveur en
local et à distance au cloud. Son but est d’établir une connexion sécurisée entre le serveur
distant et un ordinateur en utilisant le cryptage à clé publique pour fournir une
authentification forte des utilisateurs et des communications cryptées sécurisées sur
Internet.

5. Internet

Module clé de notre architecture qui va permettre de fournir la connexion

d’accéder à distance à notre service se trouvant sur le cloud. Son objectif est de faire
communiquer plusieurs équipements géographiquement éloignés.

6. IaaS service

TFC_ESIS_AS
 P a g e | 47

Ce composant décrit le type de service cloud du fournisseur mis à notre

disposition en vue d’héberger et de gérer notre système de gestion de base de données.
Les utilisateurs y accèdent par l’intermédiaire d’internet.

7. Environnement conteneur

Module décrit l’espace dans lequel le conteneur s’exécute dans le cloud ; la

configuration de son image.

8. Station de travail

Elle représente un équipement terminal de traitement de données permettant à

l’utilisateur ou l’administrateur du réseau d’interagir avec le système.

9. Hyperviseur de type 1

Ce composant a pour but de donner la possibilité de faire tourner plusieurs

systèmes d’exploitation sur un seul serveur. Et ces systèmes d’exploitation sont appelés
systèmes invités.

2.2.2. Conception détaillée logique

Une fois que la conception logique est établie, on passe à la conception détaillée
ou ingénierie détaillée de notre futur système : Après avoir présenté l’idée générale sur
les différents blocs de notre système épinglé dans le point précédent, nous essayerons
cette fois de donner des explications un peu plus détaillées sur quelques blocs qui ont été
présentés de manière simplifiée dans la conception générale.

Vue que notre conception de la solution est modulaire ; c’est-à-dire, nous avons
découpé notre système en sous modules qui peuvent être traités séparément pour ainsi
permettre une meilleure compréhension dans la conception, Nous allons ainsi dans la suite
montrer avec beaucoup de lumière les blocs importants présentés dans l’architecture
générale du système.

2.2.2.1. Le LAN

Le LAN (Local Area Network) est le réseau informatique limité à l’échelle

géographique de notre site d’entreprise. Le LAN permet d’interconnecter plusieurs types
d’équipements dans un réseau local (micro-ordinateur, téléphone, etc.).

Principe de fonctionnement dans un réseau local repose sur :

TFC_ESIS_AS
 P a g e | 48

a) Une adresse Mac :

Est un identifiant physique dans une carte réseau ou une interface réseau qui est
utilisé pour attribuer mondialement une adresse unique (codé sur 48 bits). L’adresse MAC
est utilisée dans les trames transmises. Une trame transporte un paquet.

b) Une adresse IP :

Une adresse IP est le numéro d’identification de chaque appareil connecté à un

réseau utilisant le protocole internet.

c) Un numéro de port :

Le numéro de port sert à identifier un processus en cours de communication par

l’intermédiaire de son protocole de couche application (associé au service utilisé,
exemple : 80 pour http.

Figure 2.3 Communication réseau entre processus [5]

d) Un commutateur :

Un commutateur ou switch est un équipement qui relie plusieurs segments

(câbles ou fibres) dans un réseau informatique. Il s’agit d’un boitier disposant de plusieurs
ports Ethernet.

TFC_ESIS_AS
 P a g e | 49

Figure 2.4 Illustration d’un LAN

2.2.2.2.Image du service SGBD

Une image du service SGBD13 est un fichier statique non modifiable qui décrit
les configurations de ce service. Il va contenir le code exécutable pour permettre
l’exécution de notre système de gestion de base de données de façon isolée dans notre
infrastructure informatique.

L'image du service SGBD va inclure les bibliothèques et les outils système, et

les autres paramètres des plateformes nécessaires à l'exécution d'un programme logiciel
sur la plateforme de conteneur. Elle va partager le noyau du système d'exploitation de sa
machine hôte.

a. Principe de fonctionnement

L’image du service SGBD sera compilée à partir des couches du système de

fichiers sur une image parente ou de base. Cette superposition de couches favorise la
réutilisation des différents composants : l'utilisateur ne repart pas de zéro à chaque projet.
Du point de vue technique, l’image de base sert à construire une image totalement
nouvelle alors que la présence d'un parent sous-entend la modification d'une image
existante.

13
Système de Gestion de Base de Données ; est un logiciel système servant à stocker, à manipuler ou gérer,
et à partager des données dans une base de données, en garantissant la qualité, la pérennité et confidentialité
des informations, tout en cachant la complexité des opérations

TFC_ESIS_AS
 P a g e | 50

L’image du service SGBD sera stockée dans un registre privé ou public d'un
référentiel. L'auteur de l'image l'envoie au registre et l'utilisateur va y chercher quand il
veut l'exécuter comme conteneur.

- Système de gestion de base de données (SGBD)

Un système de gestion de base de données est un système qui permet de gérer

une base de données partagée sur plusieurs utilisateurs simultanément. Il est un logiciel
système servant à stocker, gérer, trier et utiliser des données dans une base de données. Il
garantit la confidentialité, la pérennité et la qualité des informations. Dans sa forme la
plus simple, il s’agit d’une interface graphique, tandis que le modèle le plus complexe
associe des langages de programmation.

Une base de données est un ensemble structuré de données apparentée qui

modélisent un univers réel. En informatique, elle désigne un ensemble des dispositifs
informatiques de collecte, mise en forme, stockage et utilisation d’information.

Fichier et Base de données

Les données des fichiers sont décrites dans les programmes par conséquent il y’a
la multiplication des fichiers qui entraine la redondance des données et rend difficile les
mises à jour tandis que les données de la base de donnée sont décrites hors des programme
dans la base elle-même.

Le but poursuivit du système de gestion de base de donnée est d’inscrire, de

retrouver, de modifier, de trier, de transformer ou d’imprimer les informations de nos
bases de données. Il permet d’effectuer des comptes rendus des informations enregistrées
et comporte des mécanismes pour assurer la cohérence des informations, éviter des pertes
des informations dues à des pannes, assurer la confidentialité et permettre son utilisation
par d’autres logiciels

Par rapport à notre solution, une autre des fonctionnalités importantes que le
SGBD va effectuer est la Réplication synchrone des données en temps réel. La réplication
synchrone permet d’augmenter inévitablement la latence d’écriture car toutes les
modifications seront répliquées aux deux emplacements avant que la base de données
puisse continuer. L’effet de performance qui va en résulter est inimaginable, excluant
l’utilisation de la mise en miroir synchrone. Cette réplication permettra de mettre à jour
uniquement les données modifiées et pas la base de données en entièreté.

 Fonctions d’un système de gestion de base de données

 Définition des données : langage de définition des données(DDL)
conforme à un modèle de données.

TFC_ESIS_AS
 P a g e | 51

 Manipulation des données : interrogation, mise à jour (insertion,

suppression, modification) langage de manipulation des données (DML)
 Contrôle des données : contraintes d’intégrité, contrôle des droits
d’accès, gestion de transactions : gestion de contrôle des données(DCL)

2.2.2.3.VM du serveur de conteneur

Ce module va permettre d’embarquer le système de gestion de base de données dans

un ou plusieurs conteneurs logiciels et qui pourra s'exécuter sur n'importe quel serveur machine,
qu'il soit physique ou virtuel. Le but de ce module est de faciliter le déploiement du service, et
la gestion du dimensionnement de l'infrastructure sous-jacente.

Le diagramme de séquence qui illustre la conteneurisation du SGBD dans le réseau local est le
suivant :

Figure 2.6 Le diagramme de séquence qui illustre la conteneurisation

2.2.2.4. Les Fonctionnalités

Figure 2.5diagramme de séquence détaillée du scénario 1
2.2.2.4.1. Snapshot/backup
a) Un snapshot

Lors de la configuration de l’image du système de gestion de base de données,

on envisagera d’effectuer des instantanés qui sont des copies en lecture seule des systèmes

TFC_ESIS_AS
 P a g e | 52

de fichiers à un moment donné. Ces instantanés permettent de revenir à une configuration

précédente en cas d’erreur dans la configuration du fichier actuel de notre image de
service de base de données. Ces instantanés se distinguent par leur rapidité.

Principe de fonctionnement

Le concept de snapshot est très différent des sauvegardes sur bande. Les
données ne sont pas copiées sur n’importe quel support pendant la sauvegarde, au lieu de
cela, il informe simplement le NAS que toutes les données se trouvant dans les blocs en
cours d’utilisation doivent être préservées et non écrasées. La sauvegarde se produit
pendant l’accès quotidien aux fichiers ainsi, lorsqu’un fichier est modifié après la création
d’un instantané, ses blocs de données d’origine sont protégés contre les écrasements. Les
nouvelles mises à jour sont écrites dans un nouvel emplacement. Le système de fichiers
maintien des enregistrements et des pointeurs pour garder une trace des données
instantanées et des modifications des fichiers.

b) La Conteneurisation et la Virtualisation

Conteneur : Un conteneur est une structure de données, une classe, ou un

type de données abstrait, dont les instances représentent des collections
d’autres objets. Il est utilisé pour stocker des objets sous une forme organisée
qui suit des règles d’accès spécifiques [6]
 Conteneurisation : La conteneurisation est une méthode qui permet de
virtualiser, dans un conteneur, les ressources matérielles (systèmes de
fichiers, réseau, processeur, mémoire vive, etc.) nécessaires à l’exécution
d’une application. [6]
 La virtualisation : La virtualisation consiste à exécuter sur une machine hôte
dans un environnement isolé, des systèmes d’exploitation ou des applications.
[6]
 Conteneurisation vs virtualisation

La virtualisation permet, via un hyperviseur de simuler une ou plusieurs machines

physiques, et les exécuter sous forme de machines virtuelles (VM) sur un serveur ou un
terminal. Ces VM14 intègrent elles-mêmes un OS15 sur lequel des applications sont exécutées.
Tandis que le conteneur va faire directement appel à l’OS de sa machine hôte pour réaliser ses
appels système et exécuter son application d’où son extrême légèreté et un lancement rapide de
beaucoup plus rapide. [6]

14
Virtual Machine (machine virtuel).
15
Operating System (système d’exploitation) ; ensemble des programmes qui dirige l’utilisation des
ressources d’un ordinateur par des logiciels applicatifs.

TFC_ESIS_AS
 P a g e | 53

Figure 2.6 Différence entre machine virtuelle et conteneur [6]

2.2.2.5.Protocole de transfert

Le protocole de transfert est un protocole qui va nous permettre de nous

connecter à distance à d’autres ordinateurs sur le réseau du cloud et de déplacer les
fichiers ou d’exécuter des commandes. A l’aide d’un client, il sera envisageable de créer
un tunnel protégeant l’authentification.

2.2.2.6.Hyperviseur de type 1

L’hyperviseur de type 1 appelé natif est le logiciel qui va s’exécuter directement

sur la plateforme matérielle ; cette plateforme est considérée comme un outil de contrôle
de système d’exploitation. Contrairement à l’hyperviseur de type 2 qui est un logiciel qui
s’exécute à l’intérieur d’un autre système d’exploitation et un troisième système
d’exploitation appelé invité va donc s’exécuter en troisième niveau au-dessus du matériel.

Figure 2.7 Différence entre hyperviseur type 1 et hyperviseur type 2 [7]

TFC_ESIS_AS
 P a g e | 54

2.2.2.7.Environnement conteneur

Après la migration du conteneur se trouvant dans le local vers le cloud, ce

module va permettre de stocker l’image SGBD et de l’exécuter à chaque demande
effectuée sur cet espace de stockage à partir d’un point extérieur ; la configuration de son
image.

Le digramme de séquence qui illustre le fonctionnement logique de la migration

d’un service vers le cloud est le suivant :

Figure 2.7Le diagramme de séquence de migration du service

- Reprise après sinistre

La reprise après sinistre est l’ensemble de procédures de reprise après un

évènement perturbant dans le réseau, ces évènements peuvent inclure des inondations,
des incendies ou une personne agissant de manière malveillante ou négligente intention.
C’est le processus complet d’identification de différents risques, définir les exigences de
récupération de données et de continuité de service, et fournir les architectures avec les
procédures associées.

TFC_ESIS_AS
 P a g e | 55

2.2.3. Conception physique

La conception logique épinglée ci-haut, nous a permis de concevoir et de mettre

en place notre propre architecture logique de notre système. Par ce fait, la conception
physique à son tour, nous amènera au plan physique d’implémentation de notre projet.

Bien avant de passer à cette conception, nous allons tout d’abord faire une étude
comparative des différentes technologies que nous utiliserons pour projet.

2.2.3.1.Choix de la technologie
 Critère de choix

Notre critère de choix sera effectué en fonction des exigences fonctionnelles et

non fonctionnelles de l’entreprise qui sont :

 C1 La facilité d’installation
 C2 La haute disponibilité
 C3 coût
 C4 La sécurité
 C5 Rapidité
 C6 Fiabilité
 C7 L’accessibilité
 C8 facilité d’utilisation

Etant donné que notre solution a trois grandes parties, notre choix sera basé sur
trois technologies dont une pour représenter chaque partie de la solution. Nous aurons :

La technologie des conteneurisations

La technologie des systèmes de gestion de base de
données
La technologie du cloud

 La technologie des conteneurs

 KUBERNETES
 ROCKET
 DOCKER.

TFC_ESIS_AS
 P a g e | 56

Tableau 2.1 comparaison outils de conteneurisation

Critères C1 C2 C3 C4 C5 C6 C7 C8 Total/40

Kubernetes 2 5 1 3,75 5 4 4 2 26,75

Rocket 2,5 4 2 4,5 4 3 2 2 24

Docker 4,75 4 3,25 3 4 5 3,75 4,5 32,25

Technologie des conteneurs

La facilité d’installation
ou de déploiement
5
Facilité d'utilisation 4 La haute disponibilité
3
2
1
Accessibilité 0 Le cout réduit

Fiabilité La sécurité

Rapidité

DOCKER KUBERTENES ROCKET

Figure 2.8 courbe de comparaison conteneurs

Après des longues études effectuées sur les trois grandes technologies sur le
marché de la conteneurisation, Docker représente le choix approprié pour notre solution.

1. Présentation de DOCKER

Docker est une technologie des conteneurs ou une plateforme pour les
développeurs et les administrateurs qui permettent de créer les conteneurs, c’est une sorte
de machine virtuelle qui contient une application et toutes ces dépendances. [8]

 Les termes docker

 Conteneur
Un conteneur est une instance d’exécution d’une image docker ; un
conteneur docker est constitué des éléments suivants :

TFC_ESIS_AS
 P a g e | 57

o Une image docker

o Un environnement d’exécution
o Un jeu standard d’instructions

Volume
Un volume est un répertoire spécial présent dans un ou plusieurs
conteneurs et qui ignore l’association de systèmes de fichiers. Les
volumes sont conçus de telle sorte que les données sont conservées, quel
que soit le cycle de vie du conteneur
 Principaux élément de docker
 Conteneur : répertoire contenant toute l’application
 Images index : un référentiel (public ou privé) pour les images docker
 Dockerfiles : scripts automatisant le processus de création des images
 Dockerregistry : est une application server de type conteneur qui permet
de stocker et distribuer des images docker avec un système
d’authentification. [8]
a. Le conteneur

Les conteneurs docker ont plusieurs caractéristiques principales, ils permettent :

 La portabilité des applications

 L’isolation des processus
 La prévention des modifications venant de l’extérieur
 La gestion de l’utilisation des ressources

En plus, ils nécessitent beaucoup moins des ressources que les machines
virtuelles traditionnelles utilisées pour le déploiement d’application isolée.

Ils ne permettent pas :

 Les mélanges avec d’autres processus

 La vulnérabilité aux attaques et l’utilisation abusives des ressources
du système hôte
b. Docker image

Les images docker constituent la base des conteneurs docker à partir desquels
tout commence à se former. Ils sont similaires aux images disque du système
d’exploitation par défaut qui sont utilisées pour exécuter des applications sur les serveurs
ou ordinateurs de bureau. [8]

Ces images permettent une portabilité transparente sur tous les systèmes ; elles
constituent une base solide, cohérente et fiable avec tout ce qui est nécessaire pour
exécuter les applications.

TFC_ESIS_AS
 P a g e | 58

c. Dockerfile

Un dockerfile est un fichier qui permet de construire une image docker adaptée
aux besoins

Les Dockerfiles prennent très peu de place et peuvent se partager ou se

transmettre facilement. En même temps ils permettent de recréer son environnement
rapidement. Mais aussi d’effectuer des tests avec des librairies qui ont subi des mises à
jour, pour vérifier que le système fonctionne toujours aussi bien avant de déployer ces
mises à jour. [9]

d. Docker Registry

Un registry docker est une application serveur de type conteneur qui permet de
stocker des images docker avec un système d’authentification par défaut nous avons un
docker hub qui est registry héberger par docker. Utilisable gratuitement et accessible
depuis internet si nous désirons avoir une distribution locale. Il faudra nous orienter vers
un registry privé

Un docker registry privé donne :

 Un contrôle sur où sont stockées les images
 Une gestion du réseau de distribution de nos images
 Une intégration de la distribution d’image dans notre 16workflow
local
e. Docker Daemon

Le docker daemon est à la fois responsable de la création, du démarrage et du

monitoring des conteneurs, mais aussi de la construction et du stockage des images. Il est
démarré par le système d’exploitation hôte. [10]

16
Flux de travaux ou flux opérationnel ; est la représentation d’une suite de taches ou d’Operations
effectuées par une personne, un groupe de personnes, un organisme, etc.

TFC_ESIS_AS
 P a g e | 59

Figure 2.9 Architecture de docker

 La technologie des systèmes de gestion de base de données

Le critère de choix du système de gestion de base de données sera effectué

uniquement sur trois grandes technologies qui sont :

 MySQL
 PostgreSQL
 Oracle.

Comparaison entre les trois grandes technologies :

Tableau 2.2 comparaison outils gestion de base de données

Critères C1 C2 C3 C4 C5 C6 C7 C8 Total/40

PostgreSQL 3,25 4 3,5 4 5 4,5 5 5 34,25

Oracle 3 3 1 4 5 5 4 2 27

MySQL 2 3 3 3 4 4 3 4 26

TFC_ESIS_AS
 P a g e | 60

technologie des SGBD

La facilité d’installation
ou de déploiement
5
Facilité d'utilisation 4 La haute disponibilité
3
2
1
Accessibilité 0 Le cout réduit

Fiabilité La sécurité

Rapidité

POSTGRESQL ORACLE MYSQL

Figure 2.10 diagramme Radar de comparaison SGBD

En se basant sur les critères de choix qui sont des besoins non fonctionnels de
l’entreprise, la technologie des systèmes de gestion de base de données pour le test de la
solution apportée à l’entreprise serait PostgreSQL.

2. Présentation de PostgreSQL

PostgreSQL est un système de gestion de base de données objets reconnu pour

son comportement stable, mais aussi pour ses possibilités étendues, directement dans le
moteur de la base de données. Les utilisateurs peuvent étendre le logiciel grâce à des
licences libres, en ajoutant de nouveaux types de données, fonctions, opérateurs,
méthodes d’indexation ou langages de procédure (langages de programmation pour les
fonctions d’écriture et les déclencheurs). [11]

PostgreSQL utilise un modèle client/serveur.

Une session PostgreSQL est le résultat de la coopération des processus

(programmes) suivants :

 Un processus serveur : qui gère les fichiers de la base de données, accepte

les connexions à la base de la part des applications clientes et effectue sur la
base les actions des clients. Le programme serveur est appelé postgres.
 L'application cliente (l'application de l'utilisateur) : qui veut effectuer des
opérations sur la base de données. Les applications clientes peuvent être de
natures très différentes : un client peut être un outil texte, une application
graphique, un serveur web qui accède à la base de données pour afficher des
pages web ou un outil spécialisé dans la maintenance de bases de données.

TFC_ESIS_AS
 P a g e | 61

 Fonctionnement de PostgreSQL

Figure 2.11 Architecture de PostgreSQL [18]

L’architecture physique de PostgreSQL comme le décrit l’architecture ci-haut se compose
essentiellement de :

 La mémoire partagée
 Processus en arrière-plan
 Structure du répertoire de données / fichiers de données.
a. La mémoire partagée [12]

Une mémoire partagée fait référence à la mémoire réservée aux captures transactionnelles
et à un autre journal. La mémoire partagée comprend les éléments suivants :

 Le shared Buffers : qui est une mémoire cache contenant les blocs de
tables et d’index Postgres les plus accédés.
 Le WAL Buffers : sont des mémoires qui stockent temporairement les
modifications dans la base de données, lesquelles modifications dans les
tampons WAL sont écrites dans le fichier WAL à un moment
prédéterminé. Au moment de la sauvegarde et de la restauration, les
tampons WAL et les fichiers WAL sont très importants pour récupérer
les données à un moment donné. Cette mémoire va être vidée au fur et à
mesure dans les fichiers WAL (write ahead logging). Ce mécanisme
permet de ne pas perdre de données en cas d’arrêt brutal de l’instance ou
du serveur.

TFC_ESIS_AS
 P a g e | 62

 Le Processus Array / work mem : correspond à l’espace mémoire de travail

qui spécifie sur les connexions par client à utiliser par le tri interne
d’opérations et les tables de hachage pour écrire des données dans des
fichiers de disque temporaires.
 Maintenance work mem :la mémoire de travail de maintenance spécifie la
quantité de mémoire pour les opérations de maintenance de la base de données.
Elle est plus grande que la mémoire de travail.

b. Fichier de l’instance
1. Les fichiers WAL

Contient la journalisation des transactions effectuées sur les bases de

données d’un DB cluster17. Ils sont alimentés par le WAL18 buffers et permettent, en cas
d’arrêt brutal du serveur de redémarrer le groupe de base de données PostgreSQL et de
rejouer les transactions à partir du dernier checkpoint valide. Les fichiers WAL peuvent
être archivés si l’instance fonctionne en mode archive.
2. Les fichiers Logs

Contient des informations sur le fonctionnement de cette instance.

3. Le fichier ph_hba_conf

Fichier qui permet de configurer des autorisations de connexion.

4. Le fichier posgres.conf

Ce fichier contient les paramètres pour l’instance.

5. Le fichier pg_control

Il contient des informations permettant à l’instance d’ouvrir un groupe de

base de données et d’en assurer l’intégrité.

Enfin des fichiers temporaires qui sont créés par l’instance pour effectuer des
tris, créer des index et autre.
c. Processus de l’instance

Postgres est considéré comme le processus principal de PostgreSQL. Il est aussi

appelé postmaster. C’est lui qui lance et surveille les processus Background du serveur

17
Un DB cluster est l’ensemble de bases de données stocké à un même emplacement dans le système, de
fichiers
18
Write-Ahead Logging ; une méthode conventionnelle pour s’assurer de l’intégrité de données. Son rôle
principal est d‘effectuer le changement des fichiers de données (tables et index) écrient dans le journal des
transactions.

TFC_ESIS_AS
 P a g e | 63

PostgreSQL. Il écoute également toutes les connexions entrantes et lance un process par
session [13] :

 BGWRITER : est chargé d’écrire les blocs modifiés dans la mémoire

shared Buffers vers les fichiers de données tables ou index
 AUTO-VACCUM : gère et supervise le nettoyage des tables et lance le
calcul des statistiques.
 WALWRITER : est chargé d’écrire dans les fichiers WAL le contenu du
WAL Buffers. Cette écriture survient soit au moment d’un COMMIT 19,
soit si le WAL Buffers est trop rempli.
 STATS COLLECTOR : c’est un collecteur de statistiques qui a pour but
de récupérer certaines informations sur l’activité des processus postgres.
Ce processus peut être désactivé.
 ARCHIVER : effectue l’archivage des journaux de transactions (fichiers
WAL) si le mode archive est activé.
 LOG-WRITER : rédige les messages (informations, avertissement,
erreurs) des différents processus postgres vers les fichiers logs.
 CHECKPOINTER : ce processus écrira toutes les pages considérées
comme brouillon de la mémoire sur le disque et nettoiera la zone des
tampons partagés. Si la base de données PostgreSQL tombe en panne, il
sera possible de mesurer la perte de données entre l’heure du dernier
point de contrôle et l’heure d’arrêt de PostgreSQL.
d. Processus utilisateur [14]

Les utilisateurs Postgres sont créés au niveau du DB cluster, il existe un super

utilisateur par défaut qui est POSTGRES ainsi il est possible de créer des utilisateurs
supplémentaires ; les utilisateurs sont définis au niveau du DB cluster et les utilisateurs
peuvent créer des tables dans plusieurs bases. Il est possible de paramétrer des droits de
connexion base par base cela peut poser problème si deux logiciels veulent créer leurs
tables dans deux bases différentes avec le même nom d’utilisateur, car il y aurait un seul
mot de passe, donc des problèmes de sécurité.

 Les tables et leurs structures

Chaque table est stockée dans un fichier autonome, il en est de même pour les
index. Les fichiers associés aux tables et index sont stockés dans un tablespace.

19
C’est l’enregistrement effectif d’une transaction.

TFC_ESIS_AS
 P a g e | 64

Le nom des fichiers associés aux tables et index est numérique. Une fonction
SQL de postgres ainsi qu’un utilitaire permettent de connaître le nom des tables et index
20

en fonction de leur numéro.

 Les transactions et les propriétés ACID

Une transaction est un groupe de commandes SQL dont les résultats seront :

 Rendus entièrement visibles pour le reste du système lorsque la

transaction est validée (COMMIT)
 Ou enlevé de la base, si la transaction est annulée (ROLLBACK21)
Propriété d’une transaction [14]

Les transactions doivent être ACID :

 Atomicité : tous les changements apportés aux données

sont effectués totalement ou pas du tout.
 Cohérence : les transactions doivent respecter les
contraintes des données de la base de données.
 Isolation : les écritures et lectures des transactions
réussies ne seront pas affectées par les écritures et
lectures d’autres transactions, qu’elles soient ou non
réussies
 Durabilité : les transactions réussies survivront de
façon permanente et ne seront affectées par
d’éventuelles pannes ou problèmes techniques.
 Les rôles et les droits [14]

Les rôles permettent de définir des types d’utilisateurs, ce sont des ensembles de
droits avec des login et mot de passe le rôle postgres a tous les droits, tous les utilisateurs
ont le rôle public qui permet de désactiver des droits à tout le monde.

Tous les rôles ont des droits par défaut :

 Droit de connexion sur toutes les bases de données

 Droit de créer des objets temporaires
 Droit de créer des fonctions SQL et PL/pgSQL

20
Structured Query Language (langage de requête structurée) ; est un langage permettant de communiquer
avec la base de données
21
Est une méthode permettant d’annuler l’ensemble des requêtes que l’on vient de réaliser en outre c’est
l’effet inverse du COMMIT.

TFC_ESIS_AS
 P a g e | 65

 Droit d’utiliser les fonctions créées par d’autres dans le

schéma public

Pour assurer une haute disponibilité des services, postgres implémente une réplication des
données appelée :

 Synchronisation des données

La synchronisation des données consiste à rejouer les transactions par paquet de

l’emplacement principalement vers l’emplacement secondaire par une transmission des
transactions en groupe. Cette solution nécessite un réseau fiable pour une intégrité et
cohérence des données.

Figure 2.12 architecture de la synchronisation

e. La technologie des cloud

 Amazon Web Services (AWS)

 Google cloud
 Microsoft Azure

TFC_ESIS_AS
 P a g e | 66

Tableau 2.3 comparaison outils cloud

critères C1 C2 C3 C4 C5 C6 C7 C8 Total/40

AWS 4 4 4 4 5 4,5 5 3 33,5

AZURE 4 3,5 2 4 4 3,5 4 3 31,5

Google 3 4 2 5 4 3 3,5 2 26,5

cloud

Technologie des clouds

La facilité d’installation
ou de déploiement
5
facilité d'utilisation 4 La haute disponibilité
3
2
1
Accessibilité 0 Le cout réduit

Fiabilité La sécurité

Rapidité

AWS AZURE GOOGLE CLOUD

Figure 2.13 diagramme Radar de comparaison cloud

Partant de cette étude effectuée sur différentes technologies du cloud computing,
Amazon Web Service est le mieux placé pour répondre aux besoins de l’entreprise
Anonymous en terme de stockage externe pour ses applications et services.

3. Présentation d’Amazon Web Service

Amazon Web Service, AWS 22 en sigle est un fournisseur de solutions cloud

innovantes et économiques permettant aux entreprises qui les utilisent de grandir et
monter en échelle. Il met à disposition un cluster virtuel de machines, disponible à tout
moment, via internet. Les machines proposées émulent les caractéristiques d’un
ordinateur réel, y compris le matériel physique (processeurs et carte graphiques pour le

22
Lancé en 2006, AWS est la plateforme de cloud computing qui regroupe les services cloud d’Amazon
conçu comme une ressource interne à partir de l’infrastructure de Webstore

TFC_ESIS_AS
 P a g e | 67

traitement, mémoire locale ou vive, stockage sur disque ou SSD23) ; un choix de systèmes
d’exploitation ; de réseau ; des applications pré-chargées telles que des serveurs web, des
bases de données, des outils de gestion de la relation client, etc. [15]

Architecture Physique de AWS

sss

Figure 2.14 Architecture cloud AWS

f. Composant services AWS

Le cloud AWS regroupe au-delà d’une cinquantaine de services et ne cesse de

se développer. Ces services sont repartis en plusieurs catégories : calcul, stockage, base
de données, migration, mise en réseau et diffusion de contenu, outils pour développeurs,
outil de gestion, sécurité et identité, analyse, intelligence artificielle, services mobiles,
services applicatifs, messagerie, productivité d’entreprise, streaming de bureau et
d’application, internet des objets, centres d’appels et développement de jeux. [15]

Les principaux services AWS sont :

a. Amazon Elastic Compute Cloud (Amazon EC2)

Amazon Elastic Compute Cloud offre une capacité de calcul évolutif dans le
cloud Amazon Web Services. L’utilisation d’Amazon EC2 dispense à l’entreprise
d’investir à l’avance dans du matériel et, par conséquent, de développer et déployer des
applications plus rapidement. Il peut être utilisé pour lancer autant de serveur virtuels que

23
Solid-State Drive ; est un support permettant le stockage des données sur une mémoire Flash.

TFC_ESIS_AS
 P a g e | 68

nécessaire, configurer la sécurité et la mise en réseau, et gérer le stockage. Il permet

également de monter ou descendre en puissance rapidement afin de gérer l’évolution des
exigences ou des pics de popularité, ce qui permet de réduire la nécessité de prévoir le
trafic du serveur [15]

 Concepts
 Instance

Une instance est un serveur virtuel figurant dans le cloud. Sa configuration au

moment du lancement est une copie de l’AMI que l’utilisateur a spécifié lors du
lancement de l’instance.

 AMI

Amazon Web service publie de nombreuses AMI contenant des configurations

logicielles courantes pour un usage public. Cela permet au client de démarrer rapidement
et facilement de nouvelles instances disposant de tout ce dont l’utilisateur a besoin.

Scénario

Figure
b. Amazon Simple Storage 2.15(Amazon
Services Architecture
S3) AMI

C’est un service de stockage de données réparties qui est très durable. Il permet
de faciliter la collecte, le stockage et l’analyse de données à grande échelle. Ces données
peuvent être collectées à partir de nombreuses sources telles que des sites web, des
applications mobiles, des applications d’entreprises ou des capteurs d’objets connectés.
De nombreux utilisateurs de ce service stockent des milliards d’objets et des téraoctets
comme cible de sauvegarde. Ou comme stockage pour les applications de calcul sans
serveur. [15]

c. Amazon Relational Database Service (Amazon RDS)

Permet d’installer, de gérer et de mettre à l’échelle facilement une base de

données relationnelle dans le cloud. Il offre une capacité d’économie et ajustable ainsi
qu’une automatisation des tâches administratives chronophages, telles que l’allocation de

TFC_ESIS_AS
 P a g e | 69

matériel, le paramétrage des bases de données, l’application de correctifs et les

sauvegardes. [15]

Amazon RDS permet d’aller facilement de la conception du projet à son

déploiement, de dimensionner les ressources de calcul et de stockage la base de données
en quelques clics ou via un appel d’API24, et souvent sans interruption de l’instance. Ce
service fonctionne sur la même infrastructure extrêmement fiable que celle utilisée par
les autres offres de AWS ainsi il présente plusieurs autres fonctionnalités qui améliorent
la fiabilité des bases de données de production vitales, notamment les sauvegardes
automatisées, les instantanés de base de données et le remplacement d’hôte automatique.

d. Amazon VPC

C’est un service qui permet d’avoir un réseau privé dans lequel les clients
alloueront les ressources de cloud computing, ce qui signifie que personne n’y a accès à
part le client lui-même. [15]

g. Sécurité implémentée dans AWS

AWS offre une infrastructure sécurisée, très performante, résiliente et efficace pour les
applications des entreprises clientes. Les experts en sécurité de classe mondial qui
surveillent chaque infrastructure construisent et maintiennent également les vastes
sélections des services de sécurité novateurs, qui peuvent aider à respecter plus
simplement les exigences de sécurité et de réglementation de chaque entreprise cliente.
[15]

La sécurité du cloud AWS consiste en :

- La protection des données : le cloud propose des services qui permettent de

protéger les données, les comptes et les charges de travail des accès non autorisés.
Il offre un service de détection des menaces, de gestion des clés et de chiffrement
permettant de surveiller et de protéger en continu les comptes et les charges de
travail des clients

- Protection des infrastructures : la protection des applications WEB se fait en

filtrant le trafic selon les règles que chaque client crée. Exemple, le filtrage des
requêtes web en fonction des adresses IP, des en-têtes http, des corps http ou des
chaines de l’URL, ce qui permet de bloquer les types d’attaque les plus rependus
tels que l’injection de code SQL ou le script de site à site

24
Application Programming Interface (interface de programmation applicative) ; est un ensemble normalisé
de classes, de méthodes, de fonctions et de constantes qui sert de façade par laquelle un logiciel offre des
services à d’autres logiciels

TFC_ESIS_AS
 P a g e | 70

- Détection des menaces et surveillance continue : la détection des menaces grâce

à une surveillance en continu des activités de réseau et de comportements de
compte au sein de l’environnement cloud.

- Conformité et confidentialité des données : le cloud met à disposition la visibilité

complète du statut de conformité du client et contrôle en permanence notre
environnement à l’aide des contrôles de conformité automatiques fondés sur les
bonnes pratiques AWS et les normes du secteur que votre organisation suit.

Mécanisme de déploiement : nous allons illustrer un mécanisme de

conteneurisation et de déploiement d’une application vers le cloud. En se référant
principalement aux diagrammes de séquence des figures 1.4 et 1.6 du premier chapitre,
2.6 et 2.8 du deuxième chapitre.

Description textuelle des cas d’utilisation.

Tableau 2.3 scénario du CU conteneuriser le service

Conteneuriser service(ANFO-SN-02)
Nom du cas : Conteneuriser service

Objectif : Virtualiser le service PostgreSQL

Acteur principal : L’administrateur
Précondition(s) : - Avoir déjà été authentifié
- Outil de conteneurisation Docker déjà
installé

Post-conditions : Lancement de PostgreSQL à partir de Docker

Tableau 2.4 scénario du CU déployer le service

Déployer service dans le cloud

Nom du cas : Déployer service

Objectif : Permettre l’accès au service PostgreSQL à distance

Acteur principal : L’administrateur
Précondition(s) : - Avoir déjà été authentifié
- La conteneurisation du service PostgreSQL
dans le réseau local a déjà été effectuer
- La connexion au cloud a déjà été préétabli

Post-conditions : Le service PostgreSQL s’exécute sur le cloud

TFC_ESIS_AS
 P a g e | 71

Pour illustrer le scénario des deux cas d’utilisation, voici un diagramme d’interaction :

Figure 2.16 diagramme d’interaction entre modules

2.3. Planification
Pour que la mise en place de notre solution soit concrète, il est absolument
important que les modules de notre application soient tous bien installés, configurés,
testés afin d’être implémentés. Nous aborderons dans les prochaines lignes différentes
phases de planification (Installation, Configuration, Test, Implémentation).

TFC_ESIS_AS
 P a g e | 72

2.3.1. Plan d’installation

Dans cette première étape, il est question de planifier les différentes installations
que nous aurons à faire. Voici de façon ordonnée les installations que nous allons
effectuer :

 Installation du serveur Ubuntu 20.04 ;

 Installation de Docker sur le serveur local ;
 Installation de PostgreSQL ;
 Installation de pgAdmin en local ;
 Installation du Serveur Ubuntu 20.04 sur le cloud
 Installation de Docker sur le cloud
 Installation de PostgreSQL sur le cloud

2.3.2. Plan de configuration

Nous allons dans cette deuxième étape montrer les principaux plans de
configuration des installations planifiées. Voici de manière ordonnée notre plan de
configuration :

 Configurer le serveur Ubuntu sur l’hyperviseur de type 2

 Configurer Docker en téléchargeant son package sur le serveur Ubuntu
 Configurer PostgreSQL à partir de docker pour le conteneuriser
 Configurer pgAdmin pour accéder à la base de données par interface graphique
 Configurer le serveur virtuel sur le cloud en installant un système d’exploitation
Ubuntu
 Configurer Docker sur le serveur Ubuntu du cloud
 Configurer PostgreSQL à partir de docker en déployant le fichier volume contenant
les configurations de PostgreSQL du local vers le cloud.
 Configurer la synchronisation entre les deux bases de données en faisant
communiquer les deux serveurs ; du local et du cloud

2.3.3. Plan de test

Dans la troisième étape, il sera question de planifier les tests de différentes
fonctionnalités de notre application. Voici les fonctionnalités que nous allons tester :

 La conteneurisation de la base de données local et sur le cloud ;

 La connexion à la base de données en local
 La connexion à distance à l’application sur le cloud
 La réplication des données entre les deux bases de données

TFC_ESIS_AS
 P a g e | 73

2.3.4. Plan d’implémentation

Dans cette dernière étape de planification, il est question de planifier
temporellement l’implémentation. Voici donc notre plan d’implémentation sous forme de
diagramme de GANTT :

Figure 2.2.17diagramme de Gantt

2.4. Conclusion partielle

Nous voici arrivé à la fin de la seconde partie de notre travail. Dans cette partie,
une étude approfondie a été faite. Nous avons commencé par la conception générale à
partir de laquelle nous avons ressortie l’architecture générale de notre futur système.
Ensuite, nous avons procédé avec une conception détaillée logique qui nous a permis de
faire une étude des différents modules qui composent l’architecture générale de
l’application dans leurs détails et nous avons fini par la conception physique à partir de
laquelle nous avons effectué les choix technologiques qui seront supportés par notre
solution. La troisième partie de notre travail se penchera sur l’implémentation qui nous
conduira à une application prête à être développé.

TFC_ESIS_AS
 P a g e | 74

CHAPITRE 3 MISE EN PLACE DE LA SOLUTION

3.1.Introduction
A titre de rappel, ce présent travail consiste à mettre en place un système de
continuité des services à accès distant pour faciliter le travail à l’utilisateur en
automatisant certaines tâches telles que mentionnées ci-haut.

En effet, ce présent chapitre va consister en la mise en place dudit système en

passant par les phases d’installation, de configuration et de test. Nous allons donc mettre
en application tout ce qui a été planifié et ressortir les résultats attendus.

Pour l’installation, nous allons évoquer les exigences nécessaires avant

installation, l’inventaire des tâches et la procédure d’installation.

Pour chaque configuration, nous montrerons la procédure à suivre pour aboutir

à ce que nous cherchons résoudre.

Puis pour chaque test, nous évoquerons l’objectif de test, le critère d’acceptance
et la procédure de test.

3.1.1. Ubuntu 20.04

Sorti le 23 avril 2020, Ubuntu 20.04 est une version de support à long terme (LTS) et
comme toutes les versions LTS, elle sera supportée pendant cinq ans c’est-à-dire qu’il
bénéficiera des mises à jour de sécurité et de maintenance jusqu’en avril 2025
a) Installation (IMP-INST-01)

Exigences : avoir au moins 4Go de RAM, un processeur double cœur de 2Ghz et

d’au moins 25 Go d’espace de stockage
Taches : installer VMware 15 pro ensuite passer à l’installation
Procédure : Ubuntu 20.04 s’installe comme tous les autres systèmes d’exploitation
Ubuntu de version précédente.

3.1.2. Docker
a) Installation (IMP-INST-02)

Exigences : avoir déjà installer la version 64 bits de l'une de ces versions d’Ubuntu :

 Ubuntu Focal 20.04 (LTS)

 Ubuntu Bionic 18.04 (LTS)
 Ubuntu Xenial 16.04 (LTS)
 Ubuntu Wily 15.10
 Ubuntu Trusty 14.04 (LTS)

TFC_ESIS_AS
 P a g e | 75

 Ubuntu Precise 12.04 (LTS)

Procédures : Installer Docker en ligne de commande en tant qu'utilisateur disposant des

privilèges su ou root :

$ sudo apt update : pour mettre à jour le gestionnaire des pacquets sur le package

Figure 3.1 mises à jour gestionnaire

$ sudo apt upgrade –y : qui va récupérer les nouvelles versions des packages existants

Figure 3.2 versions package

$ sudo snap install Docker : pour télécharger le package de docker

Figure 3.3 installation de docker

Pour vérifier que docker est installé sur notre environnement on exécute : $ docker --
version

Figure 3.4 version docker

TFC_ESIS_AS
 P a g e | 76

b) Configuration (IMP-CONF-02)
Pour éviter de taper la commande sudo à chaque exécution de docker nous exécutons les
commandes suivantes :
$ sudo groupadd docker : pour créer un groupe nommé docker
$ sudo usermod -aG docker $USER : ajouter un utilisateur au groupe docker
$ newgrp docker : pour vérifier que nous pouvons maintenant exécuter les commandes
Docker sans sudo
$ reboot: on redemarre notre Docker

Figure 3.5 création de groupe docker

3.1.3. PostgreSQL

Notre solution va prendre en charge la version 13 de PostgreSQL. Cette version Inclut

des améliorations significatives, des gains d'espace et des gains de performances pour les
index, des temps de réponse plus rapides pour les requêtes et une meilleure planification
des requêtes

a) Installation (IMP-INST-03)
A partir de docker installer PostgreSQL en ligne de commande en tapant : $ docker pull
postgres

Figure 3.6 installation de postgres

b) Configuration (IMP-CONF-03)
Pour commencer, nous allons créer un dossier qui contiendra toutes les configurations par
défaut de l’image postgres et toutes les modifications apportées sur l’image

TFC_ESIS_AS
 P a g e | 77

Figure 3.7 création du fichier volume

Pour se connecter à la base de donné, nous créons un utilisateur et lui attribuons un mot
de passe.

Figure 3.8 utilisateur postgres

Enfin pour vérifier que le conteneur est actif et qu’il contient l’image postgres on execute
la commande : $ docker ps

Figure 3.9 liste des images postgres

c) Test
Critères d’acceptance :
 Exécuter le conteneur qui contient l’image Postgres et accéder à son bash (100%)

Figure 3.10 interface postgres

Se connecter à postgres sur le serveur local en tant qu’utilisateur postgres (100%)

Figure 3.11 connexion à postgres

TFC_ESIS_AS
 P a g e | 78

 Lister toutes les bases de données par défaut de PostgreSQL

Figure 3.12 bases de donnée postgres

3.1.4. AWS EC2

a) Installation (IMP-INST-05)
Condition : créer un compte cloud dans le cas où il n’existe pas.

Figure 3.13 interface de AWS

TFC_ESIS_AS
 P a g e | 79

On se connecte en tant qu’utilisateur IAM25, étant donné que les tâches que nous allons
commencer à effectuer seront quotidiennes.

Figure 3.14 connexion AWS

Pour un système securisé notre système implémente un système d’authentification.

Figure 3.15 connexion de l’utilisateur

25
Identity and Access Management (IAM) est un service web qui permet de contrôler l'accès aux ressources
AWS

TFC_ESIS_AS
 P a g e | 80

b) Configuration (IMP-COF-05)
A cette étape nous sélectionnons le service AWS que nous souhaitons utiliser

Figure 3.16 interface EC2

La première étape dans la configuration va consister à sélectionner un système

d’exploitation qui sera installé sur notre serveur virtuel dans le cloud. Nous allons installer
un système d’exploitation Ubuntu 20.04.

Figure 3.17 installation Ubuntu sur le cloud

TFC_ESIS_AS
 P a g e | 81

Les instances dans EC2 sont des serveurs virtuels que le cloud met à notre disposition
pour effectuer des tâches telles que : installer des applications, effectuer des
configurations…
Nous avons installé un système d’exploitation Ubuntu 20.04 de 1 Go de mémoire, 1
VCPU, 2.5GHZ de type T2.micro

Figure 3.18 propriété de l’instance

Dans le groupe de sécurité, nous spécifions les règles sur la destination des trafics
sortant

Figure 3.19 configuration règles sortantes

Ensuite les règles sur les trafics entrant.

Figure 3.20 configuration règles sortantes

TFC_ESIS_AS
 P a g e | 82

Nous allons essayer de nous connecter à notre instance ensuite effectuer les
configurations sur le serveur Ubuntu :
- AWS implémente trois types de connexion à l’instance : soit par une connexion
directe à l’instance à partir du cloud, soit par une session manager soit par un
client SSH à partir d’un post distant et ceci, en possédant une clé de connexion.

Figure 3.21 types de connexion au cloud

- Pour configurer notre système Ubuntu nous commencerons par les mises à jour
des packages en utilisant la commande : $ sudo apt-get update ensuite la mise à
jour des packages snap en utilisant : $ sudo snap refresh et l’installation de Docker
sur le cloud.

Figure 3.22 mises à jour du serveur cloud

Ensuite nous téléchargeons Postgres à partir de Docker, exactement comme dans notre
réseau local

TFC_ESIS_AS
 P a g e | 83

Figure 3.23 installation de postgres sur le cloud

Comme nous l’avons dit, il est possible de se connecter à notre instance EC2 par un client
SSH depuis un post distant. Nous selectionons une paire de clé que nous possederons
pour une connexion en toute sécurité.

Figure 3.24 clé de sécurité connexion au cloud

Un conteneur Docker peut posséder un dossier Volume dans lequel plusieurs fichiers
sécurisés se trouvent qui contiennent les configurations et toutes les modifications

TFC_ESIS_AS
 P a g e | 84

effectuées sur l’image. Nous allons déployer ce fichier, en se connectant au cloud via la
clé de sécurité, à partir du client SSH dans le cloud.
 Le déploiement de l’image sur le cloud a réussi avec succès. (100%)

Figure 3.25 déploiement de l’image sur le cloud

Le dossier a été copier dans le répertoire Home sur le cloud :

Figure 3.26 emplacement du nouveau fichier

3.1.5. Synchronisation des données

Pour configurer la synchronisation nous allons commencer par modifier les fichiers
suivants :

.passfile ; Pg_hba.conf ;postgresql.conf ;

Figure 3.27 fichier config2 Figure 3.28 fichier config

On commence par récuperer l’adresse ip local, ensuite l’adresse ip du cloud

TFC_ESIS_AS
 P a g e | 85

Figure 3.29 adresse ip local

Renseigner les deux adresses dans les fichiers de configuration

Figure 3.30 adresse ip local et cloud

activer la fonctionnalité de mise en connexion

Figure 3.31 standby

TFC_ESIS_AS
 P a g e | 86

Informer les deux serveurs qui doivent être mis en replication

Figure 3.32 replication entre deux serveurs

Déterminer la fréquence d’envoi des données

Figure 3.33 synchronisation des données

Activer la réplication en mode synchrone

Figure 3.34 activer l’application

TFC_ESIS_AS
 P a g e | 87

Connexion aux deux bases de données

Figure 3.35 BDD local

Figure 3.36 BDD cloud

TFC_ESIS_AS
 P a g e | 88

Une donnée insérée dans la base de donnée local :

Figure 3.37 table dans la BDD local

Figure 3.38 serveurs postgres

TFC_ESIS_AS
 P a g e | 89

Les données insérées dans le local se sont répliquées dans le cloud

Figure 3.39 données dans le locaL

TFC_ESIS_AS
 P a g e | 90

Le tableau de bord qui montre les transactions en cours d’exécution sur le cloud et toutes les connexions

Figure 3.40 tableau de bord du serveur cloud

TFC_ESIS_AS
 P a g e | 91

Le tableau de bord de postgres dans le local

Figure 3.41 tableau de bord du serveur local

TFC_ESIS_AS
 P a g e | 92

Figure 3.42 tableau d’acceptance

TFC_ESIS_AS
 P a g e | 93

Figure 3.43 tableau conception physique

Figure 3.44 tableau de l’implémentation

TFC_ESIS_AS
 P a g e | 94

Conclusion partielle
3.1.6. Evaluation des besoins
3.1.6.1.Besoins fonctionnels
Tableau 3.1 d’évaluation des besoins fonctionnel
ID Besoins Evaluation Notes
1 Authentification (ANBF- 100% L’accès au système
03) requiert une
authentification
2 Déploiement total des 100% Possible de copier les
applications existantes du configurations du
Lan vers le cloud local dans le cloud
(ANBF-01)
3 Accès au système distance 100% Possible d’accéder
(ANBF-02) depuis un point
distant au service
4 Gestion des applications à 100% Superviser, observer
distance(ANBF-05) l’état des applications
à distance.
5 Continuité des services 100% requiert un plan de
même après continuité des
panne(ANBF-06) services même après
une catastrophe.
6 Haute disponibilité des 100% Les services sont
applications(ANBF-06) disponibles à tout
moment et sans
rupture de
fonctionnement.
TOTAL 100%

TFC_ESIS_AS
 P a g e | 95

3.1.6.2. Besoins non fonctionnels

Tableau 3.2 Evaluation besoins non fonctionne

ID Besoins Evaluation Notes

1 Coût (ANBNF-03)
2 Disponibilité (ANBNF-02)
3 Rapidité de traitement
(ANBNF-05)
4 Performance (ANBNF-06)
5 Simple à utiliser (ANBNF-07)
6 Simple à installer(ANBNF-01)
7 Flexibilité (ANBNF-08)
8
Sécurité (ANBNF-04)
75% Le coût est calculé en fonction
de l’utilisation du processeur
et de la mémoire alloués.
100% Le système est opérationnel à
chaque instant.
80% Le système présente un temps
de réponse plus rapide que
l’ancien système
100% Les fonctionnalités du système
passent avec succès et le
système est fiable
100% Le système est facile à utilisé
100% Le système est adapté aux
besoins de l’utilisateur
100% Plusieurs utilisateurs peuvent
y accéder
Implémente plusieurs services
100% de sécurité gérés par des
personnes qualifiées dans la
sécurité réseau

TOTAL 93,6%

3.2. Discussion
Nous voici arrivé à terme de l’implémentation de notre travail qui a porté sur la
mise en place d’un plan permettant de déployer des services en local dans un stockage
externe et leur synchronisation.

Par rapport aux trois tableaux présentés ci-haut dont celui des tests d’acceptance,
de l’évaluation des besoins fonctionnels et non fonctionnels qui retracent toutes les étapes
de la réalisation du projet depuis la phase de l’analyse jusqu’à son implémentation ; nous
pouvons affirmer les lignes qui suivent :

 Les tests d’acceptances ont été vérifiés et fonctionnent avec succès (100%) ;
 L’évaluation des besoins fonctionnels donne un total de 100% ce qui veux dire
que les fonctionnalités assignées ont été implémentées avec succès et ;
 Enfin le système répond à 93,6% aux besoins non fonctionnels qui est un
pourcentage tolérable pour un système informatique.

TFC_ESIS_AS
 P a g e | 96

CONCLUSION GENERALE

Ce travail a porté sur un plan de continuité des services qui consiste à

conteneuriser les applications du réseau local de l’entreprise, de les déployer sur un
stockage externe et assurer une synchronisation des données entre les deux
emplacements.

Par rapport aux objectifs assignés et à la solution proposée pour notre travail, en
tenant compte des grands résultats tels que : Succès des tests d’acceptance (100%), le
système répondant à 93,6% aux besoins, la cohérence des données entre le réseau local et
le cloud, nous pouvons affirmer que l’hypothèse a été vérifiée.

En dépit de toutes recherches effectuées, nous ne pouvons en aucun cas prétendre

avoir mis en place une solution optimale qui résout tous les problèmes.

Il sied à noter que ce travail n’est pas une œuvre divine, il est le fruit d’une
œuvre humaine. Cette œuvre est sujette à des imperfections, raison pour laquelle nous
avons évalué les besoins exprimés par l’entreprise en ce qui concerne le stockage externe
des données et de leurs synchronisations. Pour d’autres chercheurs qui viendront après
nous, ils pourront améliorer en automatisant le plan en une seule application logicielle et
implémenter un système de sécurité de suivi pour chaque hôte de l’entreprise pour éviter
des attaques malveillantes.

TFC_ESIS_AS
 P a g e | 97

Bibliographie

[1] «CONNECT,» [En ligne]. Available: https://connect.ed-diamond.com/.

[2] M. B. POLOMBWE, «le Processus d'ingénierie système,» 2019.
[3] M. K. Israel, «GESTION DES CONFIGURATIONS D’UN DATACENTER BASEE
SUR PUPPET ET FOREMAN,» LUBUMBASHI, 2016.
[4] M. Azure, «Qu'est-ce que le cloud computing ?,» Microsoft, 2 Juin 2019. [En ligne].
Available: https://azure.microsoft.com/fr-fr/. [Accès le 20 Juin 2020].
[5] L. S. Avignon, LAN Reseau, Avignon, 2009.
[6] Openclassrooms, «Optimisez votre déploiement en créant des conteneurs avec Docker,»
12 Decembre 2019. [En ligne]. Available: https://openclassrooms.com/fr. [Accès le 15
Aout 2020].
[7] J. Montérémal, «Quel type de virtualisation pour optimiser vos ressources informatiques
?,» 05 Decembre 2019. [En ligne]. Available: https://www.appvizer.fr/. [Accès le 17
Aout 2020].
[8] R. Hat, «Docker, qu'est-ce que c'est ?,» 20 Mars 2019. [En ligne]. Available:
https://www.redhat.com/fr. [Accès le 27 Aout 2020].
[9] J. PASTOURET, «QU’EST-CE QUE DOCKER, ET COMMENT ÇA FONCTIONNE
?,» 17 Juillet 2018. [En ligne]. Available: https://les-enovateurs.com. [Accès le 12
Septembre 2020].
[10] Y. A. Dhuraibi, «Comment déployer Docker ?,» 4 Mai 2017. [En ligne]. Available:
https://www.scalair.fr/. [Accès le 5 Septembre 2020].
[11] EDUCBA. [En ligne]. Available: http://www.Oracle contre PostgreSQL. com. [Accès
le 7 Janvier 2019].
[12] J. D. john C. Worsley. [En ligne]. Available:
http://www.PostgreSQLParLaPratique.com. [Accès le 18 Octobre 2020].
[13] «IONOS,» [En ligne]. Available:
https://upload.wikimedia.org/wikipedia/commons/5/52/PostgreSQL_processes_1.png.
[Accès le 15 Novembre 2020].
[14] M. FERNAND, «Cours de ORACLE Database,» ESIS, 2020.
[15] AWS, «Amazon Web Services,» 15 Mai 2019. [En ligne]. Available:
https://aws.amazon.com/fr/. [Accès le 20 Septembre 2020].
[16] anonyme, «IONOS,» [En ligne]. Available:
https://www.ionos.fr/digitalguide/serveur/configuration/la-virtualisation/.
[17] DATACORE, «Votre stratégie de reprise après sinistre et de résilience d'entreprise :
2ème partie,» 12 Juin 2018. [En ligne]. Available: https://www.datacore.com/fr/blog.
[Accès le 11 Aout 2020].
[18] EDUCAB, «Architecture PostgreSQL,» 5 Janvier 2020. [En ligne]. Available:
https://www.educba.com/. [Accès le 29 Aout 2020].

TFC_ESIS_AS