TFC As 2022 Mukoma Tshammoyo Patrick

ECOLE SUPERIEURE D’INFORMATIQUE SALAMA
République Démocratique Du Congo

Province de Haut-Katanga
Lubumbashi
www.esisalama.org
MISE EN PLACE D’UN SYSTEME DE BACKUP ET REPLIQUE

AUTOMATIQUE DES MACHINES VIRTUELLES.
« Cas d’une entreprise anonyme »
Travail présenté et défendu en vue de

l’obtention du grade d’ingénieur technicien
en administration systèmes et réseaux
Par : MUKOMA TSHAMOYO Patrick
Option : Administration systèmes et
réseaux
JANVIER-2022
ECOLE SUPERIEURE D’INFORMATIQUE SALAMA
République Démocratique Du Congo
Province de Haut-Katanga
Lubumbashi
www.esisalama.org
MISE EN PLACE D’UN SYSTME DE BACKUP ET REPLIQUE

AUTOMATIQUE DES MACHINES VIRTUELLES.
« Cas d’une entreprise anonyme »
Travail présenté et défendu en vue de

l’obtention du grade d’ingénieur technicien
en administration systèmes et réseaux
Par : MUKOMA TSHAMOYO Patrick
Dirigé par : M. POLOMBWE Bertin
Co-dirigé par : M. TSHINYOKA Patrick
JANVIER-2022
Page | I
EPIGRAPHE
« Dès qu'on nous embrasse, il est bon de prévoir tout de suite l'instant
où nous serons giflés. »
Jules RENARD
Page | II
DEDICACE
Ils ont été là dès ma conception, ils ont assisté à ma naissance, ils ont pris en
charge mes premiers pas, ils m’ont inscrit, ils m’ont soutenu, ils m’ont orienté, ils m’ont
relevé, ils ont tout fait pour moi, par la grâce du seigneur ! je vous dois ce travail chers
parents, vous êtes exceptionnels. Et si c’était à refaire, je ne choisirai que vous comme
parents. TSHAMOYO KATATA David, tu es un modèle d’intégrité, de sacrifice et de
courage. NGOYI KABUNDA Hélène, tu es ma source de motivation.
Ce travail est votre…
Page | III
REMERCIEMENTS
La rédaction d’un travail scientifique passe par plusieurs étapes. Celle-ci est l’une de
plus attendues de la majorité de lecteur. Après avoir pris du temps à réaliser combien nous avons
bénéficié de multiples faveurs, nous nous devons de remercier ceux dont les nomes suivent :
Je suis reconnaissant aux autorités de l’Ecole Supérieure d’Informatique Salama. Je dis

merci aux enseignants Michée KALONDA MBO, Herbert KALONJI KABWELA pour leur
soutien total.
J’ai eu le plaisir et une grande faveur d’être entouré et encadré par un duo d’encadreurs
qui m’ont aidé, m’ont fait confiance et ont su me guider tout au long de mon parcours académique.
Ils ont apporté une richesse exceptionnelle à mes travaux par leurs conseils avisés et leur support
plus qu’importants.
Je tiens donc à remercier de tout cœur monsieur Bertin POLOMBWE qui m’a guidé
durant cette étude. Il a su m’orienter et m’encourager lorsque tout semblait sombre. Je remercie
également monsieur Patrick TSHINYOKA qui a accepté de se disponibiliser afin de me permettre
d’atteindre mes objectifs. De plus j’ai bénéficié d’un soutient sans relâche de leurs parts et une
assistance académique sans mesure.
Je voudrais remercier mes collègues de promotion pour toutes les bonnes actions posées
à mon égard. Je pense particulièrement à TSHIBOLA BANZA Raïssa allias SPILOOTA,
MWADI KALENGA Chaty allias BIGUI, NDAMUSO MUSHAMUKA Stéphanie, TSHIEND
MUTSHAIL Noé, NKOMBA Allégra, MUKOPA KIBALE Médard, MUKUNA MBAGUI
Merveille et MULANGU KABONGO Jonathan.
Toute ma reconnaissance à Percy MULENGA LUMUNA, Boanèrges TSHEBWE

KONGOLO, Joseph KABEYA MWENABULANDA, Ignace MUKONKI et Dan MBAYO
KABULO. Pour tout ce que vous êtes, je dis merci. Merci d’avoir été là, merci pour la fraternité
et l’amour que vous ne cessez de me témoigner. Soyez rassurés, j’ai compris qu’il y a une vie
après le travail de fin de cycle.
Le support moral de la famille est primordial dans ce genre de défi. Merci à Maman NGOYI
KABUNDA Hélène et mon papa TSHAMOYO KATATA David ainsi qu’à ma famille entière,
qui de près ou de loin a toujours su m’offrir son soutien, sa compréhension, son encouragement,
sa patience et son affection. Je sais combien vous êtes fiers de moi.
Page | IV
LISTE DES FIGURES
Figure 1. 1 Architecture logique de haut niveau ........................................................... 14

Figure 1. 2 Architecture logique détaillée ..................................................................... 16
Figure 1. 3 LAN KOLWEZI.......................................................................................... 17
Figure 1. 4 LAN KAMBOVE........................................................................................ 18
Figure 1. 5 Architecture système ................................................................................... 20
Figure 1. 6 Diagramme de cas d'utilisation.................................................................... 23
Figure 2. 1 Architecture logique générale ...................................................................... 26

Figure 2. 2 la sauvegarde ................................................................................................ 28
Figure 2. 3 Support magnétique ...................................................................................... 30
Figure 2. 4 Support optique ............................................................................................ 30
Figure 2. 5 Support à semi-conducteur ........................................................................... 31
Figure 2. 6 Virtualisation ................................................................................................ 31
Figure 2. 7 Hyperviseur .................................................................................................. 33
Figure 2. 8 Fichier inventaire .......................................................................................... 34
Figure 2. 9 Fichier inventaire 2 ....................................................................................... 35
Figure 2. 10 Fichier host ................................................................................................. 36
Figure 3. 1 choix outil automatisation ............................................................................ 43

Figure 3. 2 Acronis backup ............................................................................................. 45
Figure 3. 3 Veeam backup .............................................................................................. 46
Figure 3. 4 CA ARC SERVE.......................................................................................... 48
Figure 3. 5 Bacula ........................................................................................................... 49
Figure 3. 6 Architecture ansible ...................................................................................... 51
Figure 3. 7 Fichier host ................................................................................................... 52
Figure 3. 8 ansible playbook ........................................................................................... 53
Figure 3. 9 ssh trust ......................................................................................................... 53
Figure 3. 10 fonctionnement veeam backup ................................................................... 55
Figure 4. 1 dossier iso veeam backup ............................................................................. 63

Figure 4. 2 bouton install ................................................................................................ 64
Figure 4. 3 Case à cocher ................................................................................................ 65
Figure 4. 4 bouton parcourir ........................................................................................... 65
Figure 4. 5 Sélection utilitaires ....................................................................................... 66
Figure 4. 6 Composant manquants ................................................................................. 66
Figure 4. 7 Installation composants ................................................................................ 67
Figure 4. 8 Lancer installation ........................................................................................ 67
Figure 4. 9 Progression installation ................................................................................ 68
Page | V
Figure 4. 10 Fin installation ............................................................................................ 68

Figure 4. 11 Icône veeam backup ................................................................................... 69
Figure 4. 12 Netplan configuration ................................................................................. 71
Figure 4. 13 Configuration NetPlan ................................................................................ 71
Figure 4. 14 Boite de dialogue ........................................................................................ 71
Figure 4. 15 Selection carte réseau ................................................................................. 71
Figure 4. 16 Sélection type adressage ............................................................................. 72
Figure 4. 17 Configuration carte réseau Windows ......................................................... 72
Figure 4. 18 edit file host ................................................................................................ 73
Figure 4. 19 config ficher host ........................................................................................ 73
Figure 4. 20 configuration fichier variables.................................................................... 73
Figure 4. 21 Script Winrm .............................................................................................. 74
Figure 4. 22 playbook repository .................................................................................... 74
Figure 4. 23 script PowerShell création repository......................................................... 75
Figure 4. 24 playbook ajouter serveur ............................................................................ 75
Figure 4. 25 script ajouter serveur .................................................................................. 75
Figure 4. 26 Playbook création tâche sauvegarde........................................................... 76
Figure 4. 27 Script création tâche sauvegarde ................................................................ 76
Figure 4. 28 Playbook tâche réplication ......................................................................... 77
Figure 4. 29 Script tâche de réplication .......................................................................... 77
Figure 4. 30 Playbook Démarrer tâche sauvegarde ou réplication ................................. 78
Figure 4. 31 Script démarrer tâche sauvegarde ou réplication ....................................... 78
Figure 4. 32 Playbook restaurer machine virtuelle ......................................................... 79
Figure 4. 33 Script restaurer machine virtuelle............................................................... 79
Figure 4. 34 Test repository ............................................................................................ 80
Figure 4. 35 test ajout ESXi ............................................................................................ 81
Figure 4. 36 Test tâche de sauvegarde ............................................................................ 81
Figure 4. 37 Test t tâche réplication ............................................................................... 82
Figure 4. 38 test restauration machine virtuelle .............................................................. 82
Page | VI
LISTE DES TABLEAUX
Tableau 1. 1 adressage kolwezi ...................................................................................... 10

Tableau 1. 2 adressage kambove .................................................................................... 10
Tableau 1. 3 adressage Johannesburg ............................................................................. 11
Tableau 1. 4 Plan de nommage ....................................................................................... 12
Tableau 1. 5 Listes des besoins ....................................................................................... 22
Tableau 2. 1 Liste des modules du futur système ........................................................... 27
Tableau 3. 1 listes des outils d’automatisation ............................................................... 40

Tableau 3. 2 les critères du choix technologique ............................................................ 43
Tableau 3. 3 Acronis backup .......................................................................................... 44
Tableau 3. 4 Veeam backup ............................................................................................ 46
Tableau 3. 5 CA ARC serve ........................................................................................... 47
Tableau 3. 6 Bacula ........................................................................................................ 48
Tableau 4. 1 Evaluation des besoins fonctionnels .......................................................... 83

Tableau 4. 2 Evaluation des besoins non fonctionnels ................................................... 83
Page | VII
LISTE DES ACRONYMES
IT : Information Technology
RDC : République Démocratique du Congo
SAP: System Applications & Product
MPLS: Multiprotocol Label Switch
Ops: Opérations
ERP: Enterprise Resource Planning
EIGRP: Enhanced Interior Gateway Routing Protocol
LAN: Local Area Network
WAN: Wide Area Network
IGP: Interior Gateway Protocol
VM: Virtual Machine
NAS: Network Attached Storage
SAN: Storage Area Network
CD : Compact Disc
DVD : Digital Versatile Disc
OS: Operating System
PC: Personnal Computer
ASCII: American Standard Code for Information Interchange
XML: Extensible Markup Language
AWS: Amazon Web Services
GCE: Google Computer Engine
DSL: Digital Subscriber Line
USD: United State Dollar
JSON: JavaScript Object Notation
SSH: Secure Shell
API: Application Programming Interface
RAM: Radom Access Memory
USB: Universal Serial Bus
Page | VIII
BIOS: Basic Input Output System

ROM: Read Only Memory
VBR: Veeam Backup & Replication
ISO: International Organization for Standardization
Page | IX
TABLE DES MATIERES
EPIGRAPHE ..................................................................................................................... I
DEDICACE ...................................................................................................................... II
REMERCIEMENTS ....................................................................................................... III
LISTE DES FIGURES ................................................................................................... IV
LISTE DES TABLEAUX .............................................................................................. VI
LISTE DES ACRONYMES .......................................................................................... VII
TABLE DES MATIERES .............................................................................................. IX
AVANT PROPOS ....................................................................................................... XIII
0. introduction ............................................................................................................... 1
0.1 Problématique ......................................................................................................... 1
0.2 Hypothèse ............................................................................................................... 1
0.3 Choix et intérêt du sujet .......................................................................................... 2
0.3.1 Intérêt personnel .............................................................................................. 2
0.3.2 Intérêt scientifique ........................................................................................... 2
0.3.3 Intérêt social ..................................................................................................... 2
0.4 Méthodologie et techniques .................................................................................... 2
0.5 Etat de la question ................................................................................................... 3
0.6.1 Spatiale et temporelle....................................................................................... 3
0.6.2 Technologique ................................................................................................. 4
0.7 Subdivision du travail ............................................................................................. 4
0.8 Outils logiciels et équipements utilisés ................................................................... 4
chapitre 1 specification technique du futur systeme ......................................................... 6
1.1 Introduction ............................................................................................................. 6
1.2 Présentation de l’entreprise ..................................................................................... 6
1.2.1 Situation géographique .................................................................................... 6
1.2.2 Organisation et Organigramme ........................................................................ 6
1.2.3 Présentation des Opérations de l’usine ............................................................ 7
1.3 Etude de l’existant .................................................................................................. 7
1.3.1 Contexte ........................................................................................................... 7
Page | X
1.3.2 Système informatique ...................................................................................... 9

1.3.3 Architecture logique de haut niveau de l’infrastructure ................................ 13
1.4 Critique de l’existant ............................................................................................. 22
1.4.1 Points forts ..................................................................................................... 22
1.4.2 Points faibles .................................................................................................. 22
1.5 Spécification des besoins et exigences ................................................................. 22
1.5.1 Besoins ........................................................................................................... 22
1.5.2 Diagramme de cas d’utilisation ..................................................................... 23
1.5.3 Scenarios ........................................................................................................ 23
1.5.3 Exigences fonctionnelles ............................................................................... 24
1.5.4 Exigences non fonctionnelles ........................................................................ 24
1.5.5 Besoin futur.................................................................................................... 25
1.6 Conclusion partielle .............................................................................................. 25
CHAPITRE 2 CONCEPTION du SYSTEME ............................................................... 26
2.1 Introduction ........................................................................................................... 26
2.2 Conception logique générale ................................................................................ 26
2.2.1 Outil d’automatisation ................................................................................... 27
2.2.2 Sauvegarde ..................................................................................................... 27
2.2.3 Système de stockage ...................................................................................... 27
2.3 La conception logique détaillée ............................................................................ 28
2.3.1 La sauvegarde informatique........................................................................... 28
2.3.2 Le support de stockage .................................................................................. 29
2.3.3 La virtualisation ............................................................................................. 31
2.3.4 L’automatisation ............................................................................................ 34
Chapitre 3 la conception physique .................................................................................. 39
3.1 Introduction ........................................................................................................... 39
3.2 Niveau d’abstraction ............................................................................................. 39
3.2.1 Choix des technologies .................................................................................. 39
3.3 Présentation de Ansible ........................................................................................ 49
3.3.1 Architecture physique générale de ansible .................................................... 50
3.4 Présentation de Veeam Backup & restauration .................................................... 54
Page | XI
3.4.1 Différents produits de Veeam software ......................................................... 54

3.4.3 Edition de Veeam Backup ............................................................................. 54
3.4.4 Infrastructure de Veeam backup .................................................................... 55
3.4.5 Exigences matérielle et logicielle de Veeam backup e réplication ................ 55
3.5 Planification et tests .............................................................................................. 57
3.5.1 Plans d’installation ......................................................................................... 57
3.5.2 Plan de configuration ..................................................................................... 60
3.5.3 Tests ............................................................................................................... 61
CHAPITRE 4 IMPLEMENTATION ............................................................................. 63
4.1 Introduction ........................................................................................................... 63
4.2 Installations ........................................................................................................... 63
4.2.1 Installation de veeam backup ......................................................................... 63
4.2.2 Installation de Ansible ................................................................................... 69
4.3 Configurations ...................................................................................................... 70
4.3.1 Configuration des cartes réseaux ................................................................... 70
4.3.2 Importation du module veeam.backup.powershell ........................................ 72
4.3.3 Configuration du fichier host ......................................................................... 73
4.3.4 Configuration du fichier de variables ............................................................ 73
4.3.5 Configuration de winrm sur le node .............................................................. 74
4.3.6 Création des playbooks et scripts PowerShell pour la gestion de veeam backup
................................................................................................................................ 74
4.4 Tests ...................................................................................................................... 80
4.4.1 Repository ...................................................................................................... 80
4.4.2 Ajout du serveur ESXi ................................................................................... 81
4.4.3 Tâche sauvegarde ........................................................................................... 81
4.4.4 Tâche de réplication ....................................................................................... 82
4.4.5 Restaurer machines virtuelles ........................................................................ 82
4.5 Evaluation des besoins .......................................................................................... 83
4.5.1 Evaluation des besoins fonctionnels .............................................................. 83
4.5.2 Evaluation des besoins non fonctionnels ....................................................... 83
Page | XII
CONCLUSION GENERALE......................................................................................... 85
Références ....................................................................................................................... 86
Page | XIII
AVANT PROPOS
Régie par le programme national de la République Démocratique du Congo,

l’Ecole supérieure d’Informatique Salama organise des projets à défendre à la fin du
premier cycle d’études en informatiques. En effet, ce programme vient pousser les
étudiants à mettre en pratique toutes les notions apprises dans différents cours de leurs
filières afin de proposer une solution concrète qui réglerait un problème en société. Dans
ce cadre s’inscrit notre travail de fin d’études en Administration système et réseaux
intitulé : « MISE EN PLACE D’UN SYSTEME DE SAUVEGARDE ET REPLIQUE
AUTOMATIQUE DES MACHINES VIRTUELLES ».
Dans l’optique de permettre aux admins de l’entreprise « Anonymous » de pouvoir
retrouver les machines virtuelles en cas d’un sinistre, nous élaborons ce travail qui repose
sur l’usage des playbooks ansible et script veeam PowerShell, facile à comprendre et à
utiliser. Ceci permet un gain de temps grâce à l’usage des commadlets.
Nous vous prions de lire ce travail avec beaucoup d’intérêt afin de comprendre la raison
qui nous a poussé à le rédiger et la source de la solution proposée. Ceci est possible en le
parcourant de son introduction à sa conclusion générale en passant par les différents
chapitres intermédiaires.
Page | 1
0. INTRODUCTION
Les avancées continues dans le domaine de l’informatique ont poussé les entreprises
ambitieuses, visant une grande productivité à opter pour des nouvelles tendances dans leur façon
d’utiliser leurs infrastructures informatiques ou d’administrer leurs systèmes informatiques.
L’automatisation et la robotique rendent les entreprises plus sûres, plus efficaces et leur
permettent de maximiser les profits. L’automatisation implique la mise en place de dispositifs
automatisés, le plus souvent sous forme de systèmes informatiques ou robotisés pour faciliter et
exécuter les tâches répétitives. Pour la plupart il s’agit des tâches nécessitant à la fois la précision
et la rapidité d’exécution.
0.1 Problématique
Après avoir mené une recherche sur l’infrastructure réseau de l’entreprise « Anonymous »,
nous nous sommes rendus compte que les administrateurs de leur réseau étaient confrontés au
problème en rapport avec la virtualisation de leurs serveurs. Il se fait qu’il arrive de fois que l’hôte
sur lequel est installé les machines virtuelles tombe en panne ou soit ce sont les machines
virtuelles, qui directement rencontrent un disfonctionnement. Étant donné qu’ils n’ont pas
répliqué leurs machines virtuelles ou encore mise en place un système de sauvegarde qui leur
permettrait, en cas d’un sinistre de reprendre rapidement les activités, ils se voient mettre
beaucoup de temps (plus de trois jours) pour remettre le système en marche.
De ce qui précède nous nous sommes posés quelques questions qui nous permettront
d’apporter la solution audit problème.
➢ Quelles sont les mesures à prendre afin d’éviter la perte définitive des données
en cas d’une panne majeure ou d’un sinistre (incendie, inondation …) ?
➢ Quelle technique ou démarche pouvons-nous mettre en place afin d’éviter aux

administrateurs beaucoup de configuration lors de la remise en marche d’une ou
plusieurs machines virtuelles afin de gagner en temps ?
0.2 Hypothèse
Eu égard aux question posées ci-haut, constituant l’essentiel de notre problématique, nous
pouvons avancer des réponses provisoires de manière suivante :
➢ Pour ce qui est de la première question, nous avons opté pour la sauvegarde et la
réplication des machines virtuelles, vu que tous les services et applications
réseaux sont installés sur des machines virtuelles.
➢ Et pour ce qui est de la deuxième question, nous allons mettre en place un système
qui va gérer de manière automatique tous les processus de configuration de
sauvegarde, réplication et de restauration.
En général voici donc la constitution de notre solution :

Page | 2
➢ Nous aurons besoin d’un outil d’automatisation qui va nous permettre

d’automatiser les différentes tâches de sauvegarde, de réplication et de
restauration
➢ Nous aurons aussi besoin d’un logiciel de sauvegarde
➢ Enfin nous aurons besoin d’un outil de stockage qui va nous permettre de bien
garder nos backups pour notre plan de reprise.
0.3 Choix et intérêt du sujet
0.3.1 Intérêt personnel
Nous avons choisi ce thème, à cause de la passion que nous avons toujours eu pour tout
sujet qui cadre avec l’automatisation de l’administration système avec le script. Nous avons aussi
opté pour ce thème (la sauvegarde et réplication automatique des machines virtuelles), vu
qu’actuellement la meilleure façon d’administrer un système informatique complexe est
d’automatiser les différentes tâches répétitives et routinières afin de gagner en temps, d’éviter les
erreurs liées à l’administration manuelle, et d’optimiser la production de l’entreprise
0.3.2 Intérêt scientifique
Nous ne sommes pas le premier à traiter sur ce genre de sujet, moins encore le dernier à le
traiter ; ce travail ne se limite pas seulement dans l’intérêt de l’obtention du diplôme, mais aussi
pour qu’il soit une référence pour les autres qui viendront après nous, nous ne voulons pas qu’ils
partent du néant. Notre fin est de fournir un travail professionnel et de qualité afin qu’il serve de
modèle pour les chercheurs que nous avons précédés dans ce domaine.
0.3.3 Intérêt social
Le présent travail permettra aux administrateurs systèmes du réseau de l’entreprise
« Anonymous » de mettre en place un plan de reprise après sinistre moins couteux, mais plus
pratiques et efficace
0.4 Méthodologie et techniques
Dans le but de mieux appréhender les problèmes posés et de comprendre la profondeur de
notre problématique afin de bien proposer une solution optimale, une approche méthodique du
travail est indispensable. Compte tenu du caractère technique de notre travail, nous avons recouru
essentiellement aux méthodes et technique ci-après :
➢ La méthode analytique nous a permis d’examiner les différents outils de
sauvegarde et différentes plateformes d’automatisation.
➢ La méthode Top down design qui consiste à aller du plus haut niveau
d’abstraction au plus bas niveau de réalisation. Au plus haut niveau nous
retrouverons les besoins et au plus bas niveau nous retrouverons le système. Avec
cette méthode, une vue d’ensemble est conçue, mais sans détailler aucun sous-
système de premier niveau. Ensuite, chaque sous-système différent de sorte que
la spécification entière est décomposée en éléments de base.
Page | 3
Pour constituer un système ainsi conçu, nous rassemblons les spécifications qui
ont été décomposés en des éléments de base afin d’obtenir la solution palliant
plus ou moins au problème en question.
➢ L’implémentation, cette technique nous a permis d’implémenter notre solution,

de la tester, et de vérifier les hypothèses.
➢ La conception, nous a permis de définir la mise en place de notre système.
➢ La documentation, grâce à cette technique, nous avons pu acquérir beaucoup de

connaissances au travers : des livres, des articles scientifiques, des tutoriaux et
des travaux ayant un lien direct ou indirect avec notre travail.
0.5 Etat de la question

Vue l’expansion du monde informatique, il est plutôt rare de trouver un sujet qui n’ait jamais
fait l’objet d’une recherche, ou d’une publication antérieure. Nous ne sommes pas le premier à
parler ou à traiter sur ce sujet « la sauvegarde automatique des machines virtuelles », il y a eu bel
et bien des personnes qui ont déjà travaillé sur ce sujet avant nous, suivant différentes orientations,
c’est le cas de :
➢ Christelle NGALULA NTUMBA, La haute disponibilité de données
d’un data center par la réplication et le backup [travail de fin d’étude]
ESIS, année académique 2015-2016, inédit. Dont le but principal était de
prévoir un plan de reprise d’activité après un sinistre dans un data center,
en utilisant la sauvegarde de donnée incrémentale et la restauration de
données. Notre travail se débarque du travail de Christelle dans le sens
où nous allons pouvoir automatiser les processus de sauvegarde et de
restauration chose qu’elle faisait manuellement [1].
➢ Anicet SAKALA KAMANGA, Etude et mise en place d’un système de

sauvegarde et restauration des données dans un intranet [Travail de fin
d’étude] ESIS, année académique 2012-2013, inédit. Dont le but
principal de son sujet était la sauvegarde et la restauration de donnée dans
un intranet. Notre travail se démarque avec celui de Anicet dans le sens
où il s’était juste limité à faire les backups de données (fichier, base de
données, …), cependant nous nous allons nous focaliser sur la
sauvegarde des machines virtuelles [2].
0.6 Délimitation du travail

0.6.1 Spatiale et temporelle
Le cadre de notre travail est étalé sur l’année
académique 2020-2021 et est basé sur l’infrastructure de
l’entreprise « Anonymous », qui nous a permis de faire
une étude sur son infrastructure réseau, d’identifier les
Page | 4
besoins et de planifier une implémentation de notre

système dans leur infrastructure existante.
0.6.2 Technologique
Dans le cadre de notre travail de fin d’étude, nous limiterons notre plan de reprise après
sinistre qu’à la sauvegarde et la réplication en utilisant Veeam backup et Ansible afin
d’automatiser la sauvegarde des machines virtuelles.
0.7 Subdivision du travail
Mise à part l’introduction et la conclusion générale, notre travail comportera 4 chapitres qui
sont :
➢ Chapitre 1. SPECIFICATION FONCTIONNELLES DU FUTUR SYSTEME.
Dans ce chapitre nous aurons à faire la description de notre cas d’application,
critiquer l’existant et enfin y ressortir les besoins fonctionnels et non fonctionnels
du futur système.
➢ CHAPITRE 2. CONCEPTION LOGIQUE DU SYSTEME. Dans ce chapitre

nous aurons à traiter de la conception logique du futur système c’est-à-dire la
conception générale et détaillée logique du système à partir des besoins recueillis
dans la première partie, nous allons résoudre le problème logiquement.
➢ CHAPITRE 3. CONCEPTION PHYSIQUE DU SYSTEME. Ce chapitre

s’occupera de la conception technique du système, c’est-à-dire les choix
technologiques, les procédures d’installation la configuration, le test ainsi que la
planification de l’implémentation après avoir eu une solution logique, nous allons
l’orienter dans les solutions techniques.
➢ CHAPITRE 4. L’IMPLEMENTATION GENERALE. Dans ce chapitre nous

allons nous focaliser sur l’implémentation de la solution. Il est question
d’appliquer toutes les procédures prévues et montrer le résultat émanant de ces
dernières.
0.8 Outils logiciels et équipements utilisés

Dans l’élaboration de notre travail, nous avons fait recours aux logiciels ci-après :
➢ Microsoft office Word 2016
➢ Microsoft office Excel 2016
➢ Stratum
➢ Wonder Share PDFelement
➢ Ansible
➢ Veeam Backup
Page | 5
➢ Google Chrome
➢ Microsoft Edge
➢ Ubuntu
➢ Edraw max
➢ Esxi version 7
Page | 6
CHAPITRE 1 SPECIFICATION TECHNIQUE DU FUTUR SYSTEME
1.1 Introduction
Afin de bien poursuivre notre travail et de fournir le système souhaité par l’entreprise,
nous allons décrire l’entreprise en général. Et puisque notre solution est informatique, nous
mettrons un accent particulier sur l‘infrastructure réseau.
Nous traiterons aussi de la manière dont les tâches administratives sont gérées
actuellement pour y ressortir les points forts et faibles, lesquels nous permettrons d’établir les
besoins fonctionnels, non fonctionnels, les exigences et les contraintes.
1.2 Présentation de l’entreprise
Pour des raisons de sécurité 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
La société se trouve dans la région minière du grand Katanga
1.2.2 Organisation et Organigramme
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
supers intendants.
➢ PDG
➢ Directeurs généraux
➢ Directeur général chargé de l’environnement, de la santé et de la sécurité
du travail
➢ Manager de la mine
➢ Manager de l’exploitation minière
➢ Manager des usines de traitement rapporte au directeur général des
opérateurs
➢ Les supers intendant
Page | 7
➢ Les super intendants

Le département IT dépend des opérations.
1.2.3 Présentation des Opérations de l’usine
Une usine Métallurgique (usine piro-métallurgiques et hydro métallurgique) des usines
séparées de 90 Km (mesuré distance Kolwezi et Kambove) qui reçoivent les minerais de 7 mines
et une mine souterraine.
1.3 Etude de l’existant
Cette section traite respectivement sur l’infrastructure système et réseau existant afin de
pouvoir y insérer notre future solution, ainsi que le service d’administration des certains des
serveurs et son organisation en vue d’en déduire les points forts et les points faibles à 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, 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 firewall.
➢ Un ensemble d’application minières pour gérer les différents aspects de
la stabilité du terrain, de la flotte des engins (dispatch informatisé), de la
planification minière etc.
➢ Un ensemble d’application de gestion administrative telle que le pointage
automatique, le contrôle d’accès pour la sécurité physique etc.
➢ Un ensemble d’application qui regroupe les communications unifiées, la
messagerie, les services d’infrastructure système et réseau etc.
Tous ces systèmes (plus de 100 serveurs) sont hébergés dans leurs différents datacenter
construit sur une infrastructure VSAN (VMware hyperconvergée) dont le principal se trouve à
Kolwezi.
Un réseau d’entreprise reliant les sites éloignés par MPLS 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. Une partie des tâches administratives (gestion opérationnelle) est effectuée
manuellement et l’autre partie est gérée par un orchestrateur. L’ingénierie et le développement
sont négligés dans certains département.
Page | 8
Des problèmes sociaux au sein de l’équipe IT empêchent un meilleur professionnalisme

dans le travail avec d’éventuel conséquences qui peuvent s’en suivre à long terme.
1.3.1.1 Activités de la société
Exploitation minière pour la production du cuivre et du cobalt.
1.3.1.2 Sites Miniers
La société est implantée dans 4 villes de la RDC et dans 3 villes internationales, parmi
lesquels nous nommons :
➢ Kolwezi
➢ Kambove
➢ Lubumbashi
➢ Kinshasa
➢ Johannesburg
➢ Hongkong
➢ Londres
Il y a que deux villes qui comportent des sites miniers, les autres villes ont des bureaux
administratifs.
1.3.1.3 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 site à Kambove
Le site minier de Kolwezi est divisé en plusieurs zones.
b. Kambove : possède trois sites miniers et un site administratif
c. Lubumbashi : la société possède un site administratif qui est le siège de la société
d. Kinshasa : la société possède un site administratif à Kinshasa qui est une représentation
de la société chargée des affaires avec le gouvernement.
e. Johannesburg : possède un site administratif pour les opérations commerciales.
f. Londres : la société possède une représentation pour les relations internationales.
g. Hongkong : La société est une filiale d’une multinationale basée à Hongkong. C’est là
que se trouve le quartier général de la société mère.
Page | 9
1.3.1.4 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. Dans le camp il y a un
bâtiment pour le datacenter, c’est là qu’il y a tous les serveurs de l’entreprise. Un datacenter de
backup se trouve à kambove.
Il y a 20 bureaux éparpillés dans tout 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.
A l’usine (site des opérations métallurgiques) de Kolwezi il y a deux bâtiments à deux
niveaux et à peu près 100 utilisateurs. Il y a à peu près 15 bureaux éparpillés connecté aux
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 pat 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 de Ops.
1.3.2 Système informatique
A Hongkong, l y a un ERP qui permet la gestion de toute l’entreprise et cette partie est
inaccessible à la gestion locale.
1.3.2.1 Infrastructure réseau et système existante
L’infrastructure réseau de l’entreprise est composée de plusieurs sites distants (Kolwezi,
Kambove, Kinshasa, Lubumbashi, Hongkong, Londres), lesquels sont interconnectés par le
fournisseur d’accès internet VODACOM.
Page | 10
1.3.2.2 Plan d’adressage
KOLWEZI : 10.10.0.0/16
Tableau 1. 1 adressage kolwezi
SITE DEPARTEMENT SUBNET NETMASK
SITE USINE GRAND UZDK 10.10.0.0 255.255.192

PETIT UZDK 10.10.64.0 255.255.192
SITE CAMP BUREAU 10.10.128.0 255.255.192
DATACENTER 10.10.192.0 255.255.192
KAMBOVE : 10.11.0.0/16
Tableau 1. 2 adressage kambove
SITE USINE GRAND KAM 10.11.0.0 255.255.192

PETIT KAM 10.11.64.0 255.255.192
DATACENTER NEXUS1 10.11.128.0 255.255.192
NEXUS2 10.11.192.0 255.255.192
Page | 11
JOHANNESBURG : 10.12.0.0/16
Tableau 1. 3 adressage Johannesburg
SITE ADMINISTRATIF BUREAU1 10.12.0.0 255.255.224

BUREAU2 10.12.32.0 255.255.224
GESTION 10.12.64.0 255.255.224
LUBUMBASHI : 10.13.0.0/16
KINSHASA : 10.14.0.0/16
Page | 12
1.3.2.3 Plan de nommage
Tableau 1. 4 Plan de nommage
ID Nom du site Ville Code Site
1 Site de l’usine 1 Kolwezi USKOL

2 Site du camp Kolwezi CPKOL
3 Site de la mine 1 Kolwezi MIKOL
4 Site de logistique 1 Kolwezi LOKOL
5 Site administratif Kolwezi ADKOL
6 Site de l’usine 2 Kambove USKAM
7 Site de logistique 2 Kambove LOKAM
8 Site Administratif 2 Kambove ADKAM
9 Site de la mine 2 Kambove MIKAM
10 Site administratif 3 Lubumbashi ADLUB
11 Site administratif 4 Kinshasa ADKIN
12 Site administratif 5 Johannesburg ADJOH
Page | 13
1.3.3 Architecture logique de haut niveau de l’infrastructure

L’infrastructure réseau de « Anonymous » est composée de plusieurs sites distants
(Lubumbashi, Kinshasa, Johannesburg,) lesquels sont interconnectés par le fournisseur d’accès
internet VODACOM en utilisant la technologie MPLS. Cependant les réseaux des différents LAN
(Local Area Network) sont implémentés avec le protocole de routage EIGRP et les différents
WAN (Wide Area Network) sont connectés entre eux par la technologie MPLS
Page | 14
Figure 1. 1 Architecture logique de haut niveau

Page | 15
1.3.3.1 Architecture logique détaillée
Dans cette partie nous illustrerons les différents types de réseau que possède l’entreprise, nous
allons faire un « proof of concept » ainsi nous décrirons le réseau WAN avec MPLS, les LAN
détaillés des quelques sites.
1.3.3.2 Le réseau WAN avec MPLS
La société interconnecte ses différents sites en passant par un fournisseur MPLS, ce dernier utilise
des protocoles IGP et EGP pour fournir le service MPLS à la société. Il utilise également les labels
dans son Backbone, nous approfondirons cela dans la suite du travail.
Page | 16
Figure 1. 2 Architecture logique détaillée

Page | 17
1.3.3.3 LAN détaillé par site

Comme dit ci-haut nous détaillerons quelques LAN de la société.
Le diagramme ci-dessous illustre le LAN de Kolwezi.
Figure 1. 3 LAN KOLWEZI

Page | 18
Le diagramme ci-dessous illustre le LAN de Kambove
Figure 1. 4 LAN KAMBOVE

Page | 19
Le diagramme ci-dessous illustre le LAN de Johannesburg

Page | 20
1.3.3.4 Architecture système
Figure 1. 5 Architecture système

Page | 21
La société possède plusieurs serveurs dans son Datacenter, parmi lesquels nous pouvons
citer :
➢ Serveur de base de données
➢ Serveur de messagerie
➢ Serveur de fichier et d’impression
➢ Serveur de SharePoint
➢ 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.3.3.5 Présentation du système
Le côté système de la société s’occupe d’effectuer les tâches administratives telles que :
➢ Installation des logiciels
➢ Arrêt et redémarrage des services
➢ Faire des mises à jour
➢ Effectuer les configurations
➢ Créer des utilisateurs en plus d’autres sur plusieurs serveurs, qui
sont parfois distants
➢ Entretenir les serveurs
L’infrastructure système de l’entreprise est composée de plusieurs branches dans
lesquelles nous nommons : Un datacenter principal sur le site de Kolwezi, un Cloud privé à
Johannesburg et un datacenter de Backup à Kambove, le diagramme ci-haut illustre une vue de
haut niveau (moins de détails) de ce qu’est le datacenter de Kolwezi.
1.3.3.6 Organisation du système
Nous pouvons dire qu’administrer c’est gérer, comme dans toutes entreprises, les
administrateurs systèmes de la société installent et configurent le matériel, installent les
applications sur un ou plusieurs postes et tout cela ils le font manuellement, ils gèrent les
utilisateurs, ce qui comprend l’ajout, ma suppression d’un profil, la gestion des droits spécifiques
ou par groupe.
Historiquement, les administrateurs systèmes ont généralement gérer les serveurs,
installer des logiciels, modifier des configurations et administrer des services manuellement, la
société ne fait pas exception pour ces administrateurs.
Page | 22
1.4 Critique de l’existant

1.4.1 Points forts
La société est à jour avec les nouvelles technologies et il y a un outil d’orchestration qui
permet d’automatiser certaines tâches administratives et de centraliser l’administration de
différents centres de données (chaque centre de données est géré localement).
1.4.2 Points faibles
Pas de réplication, ni de sauvegarde des machines virtuelles pour pouvoir assurer la
disponibilité des services en cas d’une défaillance de cette dernière.
1.5 Spécification des besoins et exigences
1.5.1 Besoins
Après avoir, à mainte reprise, discuter avec les responsables des services (systèmes et
réseaux) de l’entreprise « Anonymous », plusieurs besoins ont été récoltés. Voici le tableau qui
reprend quelques besoins que le futur système doit satisfaire :
Tableau 1. 5 Listes des besoins
ID BESOIN DESCRIPTION BESOIN
B.1.0 Avoir la possibilité de sauvegarder les machines virtuelle
B.2.0 Mettre en place la redondance des machines virtuelles
B.3.0 Trouver le bon type de sauvegarde
B.4.0 Automatisation des processus de sauvegarde, de redondance des VM,

et des restaurations des VM
B.5.0 Avoir la possibilité de retrouver une ou plusieurs machines virtuelles
après un sinistre
B.6.0 Les backups doivent être stockés sur un bon support de stockage
Page | 23
1.5.2 Diagramme de cas d’utilisation
Après avoir ressorti les besoins, que demande le futur système nous allons faire un
diagramme de cas d’utilisation qui va nous permettre de modéliser le comportement du futur
système. Capturer les exigences et identifier également les interactions entre le système et ses
utilisateurs.
Figure 1. 6 Diagramme de cas d'utilisation
1.5.3 Scenarios
Le scenario est un outil écrit lors de l’étape finale du développement du projet. Le
diagramme de cas d’utilisation décrit ci-haut nous a permis de découvrir petit à petit les
fonctionnalités que l’on devrait avoir dans le futur système, nous allons désormais parler de
l’interaction entre l’admin et le système, il s’agit de décrire la chronologie des actions qui devront
être réalisées par les acteurs et par le système lui-même, raison pour laquelle nous allons parler
de scenario.
Page | 24
Voici la liste des scenarios pour les cas d’utilisation du futur système :
➢ Sauvegarder machine virtuelle :
• La sauvegarde réussie : ce scénario intervient lorsque le cas

d’utilisation se déroule normalement
• L’ajout non réussi : on observe ce scenario lorsque le cas

d’utilisation ne s’est pas bien déroulé
➢ Répliquer machines virtuelles :
• Réplication réussie : ce scenario intervient lorsque la réplication

s’est bien effectuée
• Réplication non réussie : dans le cas où la réplication s’est mal

passée ou a été interrompue
➢ Restaurer une VM ou les VM
• Restauration réussie : lorsque la restauration s’est bien passée
• Restauration non réussie : lorsqu’elle s’est mal passée
1.5.3 Exigences fonctionnelles

Il s’agit là des fonctionnalités du système. Ce sont les besoins spécifiant un comportement
d’entrée/sortie du système. Ainsi ils permettent de ressortir une action pouvant être menée sur
l’infrastructure en réponse à la demande. Ainsi notre système doit être capable de :
➢ Sauvegarder toutes les machines virtuelles du datacenter
➢ Répliquer toutes les machines virtuelles du datacenter
➢ Restaurer les machines virtuelles
➢ Automatiser les processus de sauvegarde, de réplication et de
restauration
1.5.4 Exigences non fonctionnelles
Il s’agit des besoins qui caractérisent le système. Ce sont des besoins en matière de
performance, de type de matériel ou le type de conception, contraintes internes et externe
auxquelles le système doit répondre, c’est ainsi ; afin d’obtenir un système qui convienne le mieux
à l’entreprise, notre système devra répondre à ces exigences :
➢ Disponibilité
➢ Facilité de déploiement et d’utilisation
➢ La performance
Page | 25
➢ Le coût
➢ L’interopérabilité
1.5.5 Besoin futur
L’entreprise « Anonymous » est une entreprise évoluant dans le secteur minier et produit
généralement du cobalt et du cuivre, elle a pour objectif de devenir le premier producteur du
cuivre en Afrique donc au monde par conséquent.
Afin d’y parvenir l’entreprise s’est munie d’un Datacenter (centre de données) pour
améliorer la productivité en échangeant les informations de ses différentes succursales que
l’évolution de ses mines ainsi que des transactions faites. D’où le besoin suivant : « le système
doit supporter l’augmentation du nombre des serveurs du Datacenter.
1.6 Conclusion partielle
Pour conclure ce chapitre, nous dirons qu’il a été l’occasion pour nous de d’écrire
l’entreprise bénéficiaire de notre future solution en générale. L'étude que nous avons menée nous
a permis de mettre un accent sur les problèmes réels que rencontre « Anonymous » afin d'y
ressortir le maximum d'idées qui nous ont mené à la détermination des objectifs que nous devrons
atteindre dans ce présent travail. C'est pour cela que nous aurons à proposer un système qui
apporte des solutions aux différents problèmes liés à la gestion des configurations de
l'infrastructure.
Page | 26
CHAPITRE 2 CONCEPTION DU SYSTEME
2.1 Introduction
Ce chapitre nous permettra de nous focaliser sur les aspects conceptuels de ce travail.
L’étude de l’existant que nous avons effectués au précédent chapitre nous a permis de ressortir
les besoins et les fonctionnalités qu’aura le futur système. A ce stade, le futur système parait
comme une boite noire qui encapsule tous les mécanismes qui pourront répondre aux
fonctionnalités demandées. Nous allons essayer de décomposer le futur système en quelques
modules afin de réduire son niveau d’abstraction. Nous allons, tout au long de ce chapitre
concevoir l’architecture logique générale, l’architecture physique générale et l’architecture
logique détaillée du futur système.
2.2 Conception logique générale
La future architecture devra avoir les différentes fonctionnalités qui sont :
➢ Sauvegarder machines virtuelles
➢ Répliquer machines virtuelles
➢ Restaurer machines virtuelles
➢ Sécuriser machines virtuelles
Dans le but, celui de l’intégration des toutes les fonctionnalités énumérées,

l’architecture ci-dessous nous servira de base de conception logique du système. Nous allons
ensuite décrire chacune de ces fonctionnalités pour en déduire l’architecture physique du système.
Figure 2. 1 Architecture logique générale

Page | 27
2.2.1 Outil d’automatisation

Ce module nous permettra de pouvoir gérer automatiquement notre outil de sauvegarde.
2.2.2 Sauvegarde
Ce module est le centre de la solution que nous allons proposer à l’entreprise
« Anonymous ». Il est le centre de tout notre système, il sert à interagir avec les différents modules
dans le but de pouvoir nous permettre à réaliser notre objectif, qui est celui de pouvoir mettre en
place un plan de reprise après sinistre basé sur la sauvegarde des machines virtuelles et la
réplication des machines virtuelles.
2.2.3 Système de stockage
Ce module va nous permettre de conserver (stocker) tous les backups de nos machines
virtuelles.
2.2.4 virtualisations
C’est dans ce module que nous allons trouver toutes nos machines virtuelles (différents
serveurs), que nous devons sauvegarder et répliquer.
Voici un tableau qui reprend de manière synthétique tous les modules du futur système :
Tableau 2. 1 Liste des modules du futur système
Id Modules Description modules
01 Outil d’automatisation Module qui permet d’automatiser les

processus de sauvegarde, réplication
et restauration
02 Virtualisation Module qui contient toutes les

machines virtuelles
03 Outil de sauvegarde Le point central de notre système.
04 Système de stockage C’est là que nous allons conserver

toutes nos backups
Page | 28
2.3 La conception logique détaillée

Dans cette rubrique nous allons voir avec détail chacun de ces modules cités ci-haut et
nous donnerons plus de lumière sur leurs différents comportements ou leurs fonctionnements
2.3.1 La sauvegarde informatique
2.3.1.1 Définition
En informatique la sauvegarde est l’opération de copie préventive de données sur un
support indépendant. Elle a pour but de mettre en sécurité des informations et de pallier toute
éventualité de panne matérielle, d’infection par un logiciel malveillant, et de suppression
volontaire ou fortuite.
Figure 2. 2 la sauvegarde
2.3.1.2 Utilité
L’utilité de la sauvegarde est de pouvoir restaurer le plus rapidement possible un système
après une défaillance ou un incident.
2.3.1.3 Types de sauvegarde
Il existe quatre grands types ou catégories de sauvegarde [3] à savoir :
a. La sauvegarde complète
La sauvegarde complète consiste à copier l’ensemble des fichiers et dossier d’un système.
Chaque fois que vous effectuez une sauvegarde complète, vous stockez entièrement et une
nouvelle fois la source de données [4].
L’avantage de la sauvegarde complète est qu’elle permet d’obtenir une image fidèle des
données est par ailleurs très rapide, cependant elle prend beaucoup de temps au vu de la quantité
des données à sauvegarder. De plus elle nécessite beaucoup d’espace disque.
Page | 29
b. La sauvegarde incrémentale
La sauvegarde incrémentale effectue d’abord une première copie complète de toutes vos
données et chaque sauvegarde qui vient après permet d’enregistrer les modifications apportées
depuis la dernière sauvegarde [4].
Contrairement à la sauvegarde complète, la sauvegarde incrémentale est très rapide à
réaliser, mais plus lente à la restauration, elle a aussi l’avantage d’utiliser peu de quantité de
stockage.
c. La sauvegarde différentielle
Comme avec la sauvegarde incrémentale, la différentielle va effectuer une copie initiale et
complète de tous vos fichiers et dossiers. Mais les prochaines sauvegardes vont permettre de
stocker tous les changements apportés depuis votre dernière sauvegarde complète.
Ce type de sauvegarde permet d’enregistrer les données plus rapidement que la sauvegarde
complète et demande aussi mois d’espace. Quant à la restauration, elle est plus rapide que celle
de la sauvegarde incrémentale qui nécessite moins d’espace de stockage [4].
d. Sauvegarde miroir
La sauvegarde miroir réalise une copie conforme des fichiers de votre système. Elle
s’effectue ponctuellement et prend en compte l’ensemble des données sources telles qu’elles
existaient lors de la dernière sauvegarde [4].
Ce procédé a l’avantage de proposer une restauration rapide et ne contient pas de fichiers
anciens ou obsolètes. Vous pouvez le combiner avec l’une des méthodes présentées ci-dessus
pour optimiser votre méthode de stockage.
2.3.1.3 La restauration
On ne peut pas parler de la sauvegarde sans parler de la sauvegarde informatique, la
sauvegarde de données ne résout pas à elle seule le problème, on doit aussi être en mesure de
pouvoir restaurer les données sauvegardées pour pouvoir parler d’un quelconque plan de reprise
d’activité après sinistre.
2.3.2 Le support de stockage
Le support de stockage communément appelé mémoires de masse, permettent de
conserver les données lorsque l’ordinateur est éteint, de manière permanente [5].
2.3.2.1 Différents types de support de stockage
a. Support magnétique
Le support de stockage magnétique sont les supports dont une ou deux faces sont
recouvertes d’un matériau magnétique (particulier dans le cas des bandes et des disques flexibles,
ou en couches minces dans le cas des disques durs), alimenté lors de l’écriture sur le support ; la
lecture peut être soit magnétique, soit optique (support magnéto-optique). Ces supports existent
sous plusieurs formats : disque (disques durs, disquette), bande (streamer, cartouche ou cassette),
carte à mémoire [5].
Page | 30
Figure 2. 3 Support magnétique
b. support optique
Le support optique, constitué d’un substrat généralement de plastique, mais pouvant être
également en verre (technologie Century Master), protégeant une ou plusieurs couches sensibles
sur lesquelles les données sont enregistrées par des techniques variées, sous forme de cavités
cuvettes, et lue par un procédé optique. Ces supports peuvent être de format physique de type
disque, carte (nommée carte laser), bande ou cassette. Les recherches sur les mémoires optiques
de très haute densité int donné naissance aux techniques holographiques qui utilisent trois
dimensions pour l’enregistrement des sonnées. De nouveaux supports liés à l’élément sensible et
permettant un important volume de stockage sont en cours de test [5].
Figure 2. 4 Support optique
c. support à semi-conducteur
Mieux connus sous le nom de mémoires flash, l’information est stockée grâce au
déplacement de charges électroniques dans de petits transistors.
Contrairement aux disques durs, ce support n’a aucune pièce mobile, cet avantage lui confère une
rapidité de plus, il ne dispose pas de pièce mécanique, ce qui le rend plus résistant aux chocs que
d’autres supports, cela les garantit également d’un danger qui est l’usure mécanique [5].
Page | 31
Figure 2. 5 Support à semi-conducteur
d. technologie de stockage réseau

➢ Le NAS : le stockage en réseau NAS est un périphérique de stockage
relié au réseau afin de stocker un gros volume de données en un seul
endroit. Le NAS facilite la gestion des sauvegardes des données.
➢ Le SAN : le système SAN à la différence du NAS, l’accès au stockage

est de bas niveau, les aspects de stockage n’apparaissent pas comme des
volumes partagés, elles sont directement accessibles en mode bloc par le
système de fichier des serveurs. Chaque serveur voit donc l’espace
disque d’une baie SAN comme son propre disque dur.
2.3.3 La virtualisation
2.3.3.1 Définition
La virtualisation est définie comme étant l’ensemble de techniques matérielles et
logicielles permettant de fournir un ensemble ou un sous-ensemble de ressources informatique de
manière qu’elles puissent être utilisées.
La virtualisation permet le fonctionnement de plusieurs machines virtuelles
indépendantes les unes des autres sur une même ressource physique centralisée et sécurisée en
salle informatique [6].
Figure 2. 6 Virtualisation
Page | 32
2.3.3.2 Types de virtualisation

D’une manière générale il existe trois types principaux de virtualisation qui sont :
➢ La virtualisation de serveur
➢ La virtualisation de poste client
➢ La virtualisation de stockage
a. la virtualisation de serveur
La virtualisation de serveur permet de mieux rentabiliser le parc informatique et utiliser plus
efficacement les ressources des serveurs disponibles, il est intéressant de virtualiser le serveur,
pour cela, par un principe d’émulation, une couche logicielle isole les ressources physiques des
systèmes d’exploitation.
Ceux-ci s’exécutent alors sur les machines virtuelles. Par ce principe, plusieurs systèmes
d’exploitation peuvent cohabiter sur une même machine, indépendamment l’un de l’autre. La
virtualisation des serveurs permet à un serveur de faire le travail de plusieurs serveurs en
partageant les ressources d’un serveur unique dans des environnements multiples [6].
b. La virtualisation de poste client

L’ensemble de ressources du poste client et données sont sur le serveur, l’administration est
très nettement simplifiée tout comme la mobilité des utilisateurs (bureau virtuel). La virtualisation
du poste client est in moyen radical mais efficace pour maitriser le cout total de possession.
Ce type de technologie de virtualisation concerne beaucoup plus un client (un poste de travail
ou un ordinateur de bureau, pc portable, bref une machine de l’utilisateur final). Ceux-ci peuvent
être très difficiles pour un administrateur système à gérer.
Alors que n’importe quelle machine dans le centre de données de l’entreprise a des procédures
très strictes concernant ce qui est chargé sur elle et quand ils sont mis à jour avec des nouvelles
versions logicielles, il est souvent une scène tout à fait différente quand il s’agit de la machine de
l’utilisateur final. Même s’il est censé y avoir des procédures suivies pour les actions ci-dessus
sur une machine de l’utilisateur final, ces procédures ne sont pas souvent suivies ou payé
d’attention [6].
c. La virtualisation de stockage
Cette virtualisation permet de séparer l’application u système d’exploitation hôte et des
autres applications présentes afin d’éviter les conflits. Cette solution est particulièrement pratique
pour simplifier l’administration du parc informatique notamment lors de l’installation des
nouveaux correctifs.
La virtualisation de stockage est un concept en administration système, en se référant à
l’abstraction (séparation) de stockage logique (partition virtualisée de données stockées) de
Page | 33
stockage physique (tourner, lire et écrire des disques magnétiques ou optiques tels que les CD,
DVD, ou même un disque dur, etc.)
Cette séparation permet aux systèmes d’exploitation d’avoir une plus grande souplesse
dans leur façon de gérer le stockage pour les utilisateurs finaux. La virtualisation de stockage
permet d’atteindre l’indépendance lieu par l’abstractions de l’emplacement physique des données.
Le système de virtualisation présente à l’utilisateur un espace de stockage de données logique
pour lui-même et gère le processus de mappage [6].
2.3.3.3 L’hyperviseur
Un hyperviseur est un logiciel qui permet de créer et d’exécuter des machines virtuelles.
Il isole son système d’exploitation et ses ressources des machines virtuelles, et permet de créer et
de gérer ces machines virtuelles.
Le matériel physique utilisé en tant qu’hyperviseur est appelé Hôte, tandis que toutes les
machines virtuelles qui utilisent ses ressources sont appelées Invités.
L’hyperviseur traite les ressources (telles que le processeur, la mémoire et le stockage) à
la manière d’un pool qui peut être déplacé sans difficulté entre les invités existants ou vers de
nouvelles machines virtuelles [7].
Figure 2. 7 Hyperviseur
Si on souhaite définir un hyperviseur, on peut dire qu’il s’agit d’un outil de virtualisation
qui permet à plusieurs systèmes d’exploitation (OS) de fonctionner simultanément sur une même
machine physique. Théoriquement c’est une couche logicielle très légère (en comparaison à un
OS classique) qui permet d’allouer un maximum de ressources physiques aux machines virtuelles.
Page | 34
Un hyperviseur, également appelé gestionnaire de machine virtuelle, est un programme

qui permet à plusieurs systèmes d’exploitation de partager un seul hôte matériel. Le rôle principal
d’un hyperviseur est de dédier des ressources matérielles à chaque VM.
2.3.3.3.1 Types d’hyperviseurs
Les hyperviseurs sont de plus en plus présents dans les architectures des entreprises, étant
donné que la virtualisation se développe et se répand rapidement. Les solutions multiples et plus
ou moins coûteuses, mais, en ce qui concerne les hyperviseurs, il y a deux types.
a. Hyperviseur de type 1
Un hyperviseur de type 1 est un système qui s’installe directement sur la couche

matérielle du serveur. Ces systèmes sont allégés de manière à se concentrer sur la gestion des
systèmes d’exploitation invités c’est-à-dire ceux utilisés par les machines virtuelles qu’ils
contiennent. Ceci permet de libérer le plus de ressources possibles pour les machines virtuelles.
Toutes fois, il est possible d’exécuter uniquement un hyperviseur à la fois sur un serveur. Parmi
les hyperviseurs de type 1 on trouve des systèmes comme Xen, VMware ESXi, Proxmox, ... [7]
b. Hyperviseur de type 2
Un hyperviseur de type 2 est un logiciel qui s’installe et s’exécute sur un système
d’exploitation déjà en place, de ce fait, plus de ressources sont utilisées étant donné qu’on fait
tourner l’hyperviseur et le système d’exploitation qui le supporte, il y a donc moins de ressources
disponibles pour les machines virtuelles, l’intérêt qu’on peut trouver c’est le fait de pouvoir
exécuter plusieurs hyperviseurs simultanément vu qu’ils ne sont pas liés à la couche matérielle.
Figure 2. 8 Fichier inventaire
Un hyperviseur de type 2 est assez comparable à un émulateur car celui-ci s’installe sur
un système d’exploitation déjà en place, il démarre la plupart de temps comme une simple
application.
Parmi les hyperviseurs de type 2, on trouve VMware Player, VMware Workstation,
Virtual PC et VirtualBox, … [7]
2.3.4 L’automatisation
La partie de ce travail comprendra différents modules que nous avons cité au point
précédent.
2.3.4.1 Le fichier d’inventaire
Le fichier d’inventaire est un fichier dans lequel on renseigne les serveurs sur lesquels on
effectue nos actions. Le fichier d’inventaire peut être dans l’un des nombreux formats, en fonction
des plugins d’inventaire que vous avez.
Page | 35
Un exemple de fichier d’inventaire est le suivant :
En général, si on travaille sur plusieurs serveurs. On définit ces machines dans notre fichier
d’inventaire et en principe, on regroupe ces hôtes par groupe. Par exemple, imaginons le scénario
où l’on veut installer Nginx sur la moitié de nos serveurs, on créera alors un groupe appelé Nginx
et on y ajoutera tous les serveurs où l’on veut l’installer :
Figure 2. 9 Fichier inventaire 2
2.3.4.2 Fichier de configuration

a. définition
Les fichiers de configuration définissent des réglages (affichage, langue, vitesse de
transmission, protocoles de communication, prendre en compte certains périphériques, etc.)
Dans les applications, les services d’un serveur informatique ou les systèmes d’exploitation.
La prise en compte de modification de ces réglages peut être quasi immédiate, comme il
est généralement nécessaire pour les systèmes et les services rendus par un serveur ou différée
jusqu’à la prochaine exécution, comme il est généralement suffisant pour une application [8].
b. Structure
La structure des fichiers de configuration est variable : elle peut se conformer aux
conventions mises en place par l’éditeur du système d’exploitation, dépendre des outils de
développement utilisés pour programmer une application ou être entièrement propriétaire, ce qui
la rend souvent difficile à interpréter.
Une grande parte de fichier de configuration est néanmoins écrite au format ASCII (sous
forme textuelle) et formatée en lignes terminées par des caractères « nouvelles lignes » ou
« CR/LF » (carriage return/ line feed) selon le système d’exploitation. Leur contenu peut alors
être examiné à l’aide d’un éditeur de texte.
Page | 36
Dans d’autres cas, il faut recourir à des applications spéciales pour créer, modifier et tester
la syntaxe des fichiers de configuration. Pour les services et les systèmes d’exploitation, le code
source et parfois la seule documentation disponible. En général, les pages de manuel ou d’aide
rendent partiellement compte de la syntaxe à utiliser dans ces fichiers ?
Les formats XML et YAML tendent à se généraliser dans l’écriture des fichiers de
configuration. Ils ont l’avantage d’avoir une syntaxe déjà bien définie et de disposer d’outils de
vérification et de validation connus [8].
Une version de YAML ressemble à ceci :
Figure 2. 10 Fichier host
c. Syntaxe
Pour plus de clarté, les fichiers de configuration respectent en général une syntaxe qui
associe des directrices (ou mots clés) à des valeurs.
Cette syntaxe peut adopter des formes et des niveaux de complexité différents selon
l’ampleurs et la précision des fonctionnalités de l’application.
Les paramètres peuvent être organisés linéairement (par ex : rs vitesse=9400), en tableau
(comme fstab) ou encore en « objet », ce qui est le cas avec le XML, délimités par un début et
une fin, et caractérisés par des propriétés et des options propres à chaque type d’objet.
A la manière des langages de programmation, les fichiers de configuration peuvent être
accompagné de commentaires qui seront ignorés par le programme, mais qui permettront aux
créateurs du logiciel d’insérer des indications, et aux utilisateurs de mieux comprendre le
comportement du programme et de neutraliser momentanément certaines lignes [8].
d. Comportement du fichier de configuration
2.3.4.3 Les modules

Les modules sont généralement autonomes et peuvent être écrits dans un langage de script
standard (tel que Python, Perl, Ruby, Bash, etc.). L’une des propriétés directrices des modules est
l’idempotence, ce qui signifie que même si une opération est répétée plusieurs fois (par exemple,
après une panne) le système sera toujours placé dans le même état.
Les modules sont mis en correspondance avec les ressources et leurs état respectifs,
représentés dans des fichiers. Ils permettent de gérer pratiquement tout ce qui contient une API,
une interface en ligne de commande ou un fichier de configuration avec lequel vous pouvez
interagir, y compris les périphérique réseau tels que les équilibreurs de charge, les commutateurs,
Page | 37
les pare-feu, les orchestrateurs de conteneurs, les conteneurs eux-mêmes et même les instances
de machine virtuelle dans un hyperviseur ou une machine virtuelle, cloud public (AWS, GCE,
AZURE) et /ou privé (Open Stack, Cloud Stack, par exemple) ainsi que dispositifs de stockage et
de sécurité, et configuration système.
➢ Les modules peuvent être écrits dans n’importe quel langage de
programmation
➢ Les configurations déclarées dans les fichiers de configuration sont
distribuées sur le réseau
➢ Les modules sont un moyen d’accroitre les capacités des outils DevOps
Après ce tour d’horizon qui nous a permis d’avoir un aperçu détaillé sur les modules du
système, un diagramme qui résume de manière succincte et plus ou moins précise toutes les
parties du système s’avère être nécessaire pour sa bonne compréhension en somme [8].
Page | 38

Dans ce chapitre, il a été question de décrire chaque module de manière générale, nous
avons eu à modéliser notre travail afin qu’il s’adapte à toute sorte de système. Dans le prochain
nous allons parler de la conception physique du futur système.
Page | 39
CHAPITRE 3 LA CONCEPTION PHYSIQUE
3.1 Introduction
Dans ce chapitre il sera question de faire le choix du matériel et logiciel afin
d’implémenter les différentes fonctions logiques écrites ci-haut. La solution ainsi conçue
(globalement et d’une manière détaillée) peut être alors réalisée avec les technologies disponibles.
3.2 Niveau d’abstraction

A ce niveau du travail, la conception logique générale et la conception logique détaillée
ont déjà été franchises, arrivés au plus bas niveau d’abstraction de notre conception, il s’avère
important de faire un choix technologique concernant notre solution.
3.2.1 Choix des technologies
3.2.1.1 Critères de choix
Les choix des différentes solutions technologiques ne seront pas faits de façon arbitraire,
nous allons recourir au premier chapitre de notre travail et plus précisément au niveau des
exigences non fonctionnels, ces dernières constitueront nos critères de choix pour différentes
solutions technologiques, chaque critère vaut 5 points, étant donné le nombre d’exigences non
fonctionnelles du système, nos critères vaudront au total 35 points. Les solutions technologiques
qui seront retenues seront celles qui auront les plus grandes cotes sur 35.
Voici donc nos critères de choix :
➢ Critère 1 (C1) : Disponibilité, elle représente la capacité du système à être en état
de fonctionner dans des conditions données et à tourner avec un temps d’arrêt
très réduit ;
➢ Critère 2 (C2) : Faciliter d’installation, elle représente la qualité du système à être
facile à implémenter ;
➢ Critère 3 (C3) : Gestion aisée, représente la capacité pour un utilisateur
d’exécuter une tâche dans un temps donné après une formation d’une durée
déterminée ;
➢ Critère 4 (C4) : Evolutivité, désigne la capacité d’un produit à s’adapter à un
changement d’ordre de grandeur de la demande (montée en charge), en particulier
sa capacité à maintenir ses fonctionnalités et ses performances en cas de forte
demande ;
➢ Critère 5 (C5) : Langage de configuration compréhensible, ce dernier doit être
facilement configurable ;
➢ Critère 6 (C6) : L’interopérabilité, est la capacité que possède un produit ou un
système, dont les interfaces sont intégralement connues, à fonctionner avec
d’autres produits ou systèmes existants ou futur et ce sans restriction d’accès ou
de mise en œuvre ;
Page | 40
➢ Critère 7 (C7) : Coût réduit, solution efficace pouvant être implémentée avec un
budget minimum ;
3.2.1.1.1 choix de l’outil d’automatisation

Chefs, Puppet, Ansible, Salt stack, tels sont les outils qui feront l’objet de notre étude afin
de pouvoir choisir l’outil d’automatisation.
Tableau 3. 1 listes des outils d’automatisation
Métrique Chef Puppet Ansible Salt Stack
Disponibilité ✓ ✓ ✓ ✓
Facilité Pas vraiment Pas vraiment Facile Pas vraiment

d’installation facile facile facile
Gestion aisée Pas vraiment Pas vraiment Facile Facile
facile facile
Evolutivité Hautement Hautement Hautement Hautement
évolutif évolutif évolutif évolutif
Langage de DSL(Ruby) DSL(PuppetDSL) YAML(Python) YAML
configuration (Python)
Interopérabilité Haute Haute Haute Haute
Coût 13700 USD 11200-19900 10000 USD 15000 USD

USD
a. disponibilité
Il est question de comparer Chef, Puppet, Ansible Salt Stack sur la base de la disponibilité.
Tous ces outils sont hautement disponibles, ce qui signifie qu’il existe plusieurs serveurs ou
plusieurs instances. Disons que si votre maître principal ou votre serveur tombe en panne, il y a
toujours un serveur de sauvegarde ou un autre maître pour le remplacer.
Parcourons chacun des outils individuellement :
a.1 Chef
En cas de défaillance su serveur principal, c’est-à-dire du serveur Chef, un serveur de
sauvegarde remplace le serveur principal
a.2 Puppet
Il a une architecture multi-maîtres, si le maître actif tombe en panne, l’autre maître prend
la place du maître actif
Page | 41
a.3 Ansible
Il s’exécute avec un seul nœud actif, appelé instance principale. Si le primaire tombe en
panne, une instance secondaire doit prendre sa place.
a.4 Salt stack
Plusieurs maitres peuvent être configurés. Si un maître est en panne, les agents se
connectent à l’autre maître de la liste. Par conséquent, il a plusieurs maîtres pour configurer les
serviteurs.
b. Facilité d’installation
Par facilité d’installation, concentrons-nous sur chaque outil un par un :
✓ Chef a une architecture d’agent-maitre. Le serveur Chef s’exécute sur l’ordinateur maître
et le client Chef s’exécute en tant qu’agent sur chaque ordinateur client. En outre, il existe
un composant supplémentaire appelé poste de travail, qui contient toutes les
configurations qui sont testées puis transférées cers desserveur chef central. Par
conséquent, ce n’est pas si facile.
✓ Puppet a également une architecture d’agent principal. Le serveur Puppet s’exécute sur
l’ordinateurs maître et les clients Puppet s’exécutent en tant qu’agent sur chaque
ordinateur client. Après cela, il y a également une signature de certificat entre l’agent et
le maître. Par conséquent, ce n’est pas aussi facile.
✓ Avec ansible seul le maître d’exécute sur la machine serveur, mais aucun agent ne
s’exécute sur la machine cliente. Il utilise la connexion ssh pour se connecter aux
systèmes clients ou aux nœuds que vous souhaitez configurer. La machine virtuelle
cliente ne nécessite aucune configuration particulière, elle est donc plus rapide à
configurer.
✓ Salt Stack, le serveur est appelé maître du sel et les clients sont appelés minions du sel,
lesquels s’exécutent en tant qu’agents sur la machine cliente.
c. La gestion aisé
Pour entamer cette partie, il sied de dire que Puppet et Chefs suivent les configurations
par tirage & ansible et Salt Stack suivent les réglages push.
Dans la configuration push, toutes les configurations présentes dans le serveur central
seront poussées vers les nœuds, tandis que dans la configuration pas extraction, les nœuds
esclaves extrairont automatiquement toutes les configurations du serveur central sans aucune
commande.
✓ Avec Chef vous devez être un programmeur pour gérer les configurations car il offre des
configurations dans Ruby DSL. Le client extrait les configurations du serveur.
✓ Avec Puppet, il est difficile de gérer les configurations car il utilise YAML, c’est-à-dire
un langage de balisage qui ressemble beaucoup à l’anglais. Le serveur envoie les
configurations à tous les nœuds. Bon pour les applications en temps réel et il y a une
exécution à distance immédiate.
Page | 42
✓ Salt Stack, facile à apprendre à gérer les configurations car il utilise également YAML.
Le serveur envoie les configurations à tous les clients. Exécution distance immédiate.
d. L’évolutivité
Les quatre outils sont hautement évolutifs. Supposons que si vous avez besoin de
configurer environ 70 nœuds aujourd’hui et demain 500, cela ne pose aucun problème. Ce n’est
pas un problème avec ces outils. Ils peuvent gérer une infrastructure importante, il vous suffit de
spécifier l’adresse IP et le nom d’hôte des nœuds que vous souhaitez configurer. Le reste de tâche
sera géré par ces outils. Par conséquent, tous ces outils sont tellement évolutifs.
e. Langue de configuration
✓ Chef utilise le langage Ruby Domain Specific Language (Ruby DSL). Il a une courbe
d’apprentissage abrupte et orientée développeur.
✓ Puppet utilise son propre langage spécifique au domaine de la marionnette (Puppet DSL)
ce n’est pas très facile à apprendre et son administration système est orientée.
✓ Ansible utilise YAML, c’est-à-dire un autre langage de balisage (Python). Il est assez
facile à apprendre et orienté administrateur. De nos jours, Python est intégré à la plupart
des déploiement Unix et Linux. Par conséquent, la configuration et l’utilisation de l’outils
sont plus rapide
✓ Saltstack utilise également YAML (Python). Il est encore facile à apprendre et orienté
administrateur
f. L’interopérabilité
Dans ces outils, maître ou serveur principal ou vous pouvez aussi dire machine de
contrôle, doit être sous linux/Unix mais leurs esclaves ou les nœuds qu’ils doivent configurer
peuvent être sous Windows. Décortiquons chaque outil un à un :
✓ Chef serveur ne fonctionne que sous Linux/Unix, mais Chef client et Workstation
peuvent également fonctionner sous Windows.
✓ Puppet master fonctionne que sous Linux/Unix, mais Puppet agent fonctionne également
sous Windows.
✓ Ansible prend également en charge les machines Windows, mais le serveur ansible doit
être installé sur une machine Linux/Unix.
✓ Salt Stack master ne fonctionne que sous Linux/Unix, mais les sbires de sel peuvent aussi
fonctionner sous Windows.
g. Coût réduit
Les coûts d’entreprise pour les outils de configuration sont les suivant :
✓ Puppet, le prix de Puppet va de 112USD par nœud/ par an avec un plan de support
standard à 199 USD par nœud / an avec le plan premium.
Page | 43
✓ Ansible, le prix pour ansible Tower pur les opérations informatiques standard jusqu’à 100
nœuds est de 10 000 USD /an. Cela inclut une assistance 8*5, tandis que premium offre
une aisance 24*7 pour 14000 USD /an.
✓ Salt Stack, le coût pour Salt stack Enterprise par nœud est de 150 USD/an (environ). Vous
pouvez contacter le support pour le prix actuel de l’abonnement annuel.
Voici un tableau qui illustre les critères remplis de chaque technologie
Tableau 3. 2 les critères du choix technologique
Critères C1 C2 C3 C4 C5 C6 C7 Total
Chef 4 1.5 1 3.5 2 4 2.5 18.5/35

Puppet 4 1.5 1 4 1.5 4 1 17/35
Ansible 4 4 4 4 4 4 3 27/35
Saltstack 4 2 4 4 4 4 2 24/35
Figure 3. 1 choix outil automatisation
Comme vous pouvez le voir ci-haut, Puppet et Chefs sont les anciens dans ce domaine,
tandis qu’Ansible et le Saltstack sont des nouveaux. Et ansible semble très promoteurs avec la
tendance croissante.
Page | 44
Partant de cette étude et vu le total des critères remplis, il serait judicieux d’opter pour la
solution Ansible.
3.2.1.1.2 Choix de l’outil de sauvegarde

Pour ce qui est de l’outil de sauvegarde nous allons faire une étude comparative sur base
des chiffres de quatre logiciels de sauvegarde & réplication les plus populaires actuellement en
entreprise (Acronis backup, Veeam Backup, CA ARC serve, et Bacula) [1].
a. Acronis backup
Tableau 3. 3 Acronis backup
Critère Pourcentage
Sauvegarde et réplication combinée 100

Réduction des coûts de stockage par déduplication des données 66
Console de gestion centralisée 70
Sauvegarde cohérente des bases de données pour la restauration des 60
applications
Réduction des coûts de stockage par déduction des données 68
Rétablissement de répliques 62
Prévention contre la perte de données 65
Vérification de la protection 5.25
Mise à profit des données 75
Visibilité complète 70
Virtualisation assurée 60
Sous forme graphique nous aurons la forme suivante :

Page | 45
Acronis backup
100
88
66 68 67 69
62 65
60
50
45
Figure 3. 2 Acronis backup
Ce qui nous donne en moyenne 63%

Page | 46
b. Veeam backup
Tableau 3. 4 Veeam backup

applications
Vérification de la protection 88
Qui donne en moyenne 87%

Sous forme graphique nous aurons la forme suivante
Veeam backup
100
88
62 66 68 65 67 69
60
50 45
Figure 3. 3 Veeam backup

Page | 47
c. CA ARC serve
Tableau 3. 5 CA ARC serve

applications
Qui donne en moyenne 70,5%

Page | 48
CA ARC Serve
100
88
66 68 65 67 69
62 60
50 45
Figure 3. 4 CA ARC SERV
d. Bacula
Tableau 3. 6 Bacula

applications
Page | 49
Qui donne en moyenne 67%

Bacula
100
88
66 68 65 67 69
62 60
50
45
Figure 3. 5 Bacula
Comme on le voit très bien, la moyenne la plus élevée parmi les quatre outils choisis,
Veeam Backup remporte et répond aux critères pour le choix de notre outil.
3.3 Présentation de Ansible

Ansible est un dispositif théorique permettant de réaliser des communications à une
vitesse supraluminique. Elle peut envoyer et recevoir des messages en provenance et en direction
du périphérique correspondant sur n’importe quelle distance sans aucun délai. Les ansibles sont
une composante emblématique de la littérature de science de fiction.
Ansible se démarque de la plupart des outils de ce type, car il ne fonctionne pas en mode
client-serveur ou maître-esclave. Il utilise les technologies SSH (secure socket shell) et JSON
(JavaScript Object Notation) pour distribuer les modules sur les nœuds distants, et utilise donc
les ressources uniquement pour les tâches utiles. Tant que le nœud n’est pas modifié, aucun agent
ni daemon ne fonctionne en arrière-plan. Cette configuration tient compte des contextes des
différents systèmes d’un environnement IT multiniveau [8].
Ansible est :
Page | 50
✓ Simple :
• Automatisation facile
• Pas besoin d’être programmeur
• Les tâches exécutées en ordre
• Utilisable partout
• Devenez productif rapidement

✓ Puissant :
• Déploiement d’application
• Gestion de configuration
• Orchestration de workflow
• Automatisation des réseaux
• Orchestrer le cycle de vie complet

✓ Sans agent :
• Utilise OpenSSH & Win RM
• Pas d’agent à exploiter ou maintenir
• Démarrer immédiatement
• Plus efficace, plus sécure

Dans les prochains paragraphes, nous allons découvrir l’architecture d’ansible et son
fonctionnement. Puis nous montrerons la gestion de configuration des environnements et le
déploiement des hôtes.
3.3.1 Architecture physique générale de ansible
Ansible est un moteur d’automatisation simple qui automatise le Cloud, le
provisionnement, la gestion de la configuration, le déploiement d’applications, l’orchestration des
services ainsi que beaucoup d’autres fonctionnalités.
Dans cette section nous allons vous donner un aperçu de la façon dont ansible fonctionne
Page | 51
Figure 3. 6 Architecture ansible
3.3.1.1 Host Inventory

Ansible permet à l’heure actuelle de manipuler des inventaires statiques et des inventaires
dynamiques. Le modèle statique fonctionne bien avec des environnements figés, n’évoluant pas
souvent. Par contre il devient vite limitant dans le cadre d’environnements en cours de
développement sujets à des reconstructions ou en évolution permanentes.
Au travers des inventaires dynamiques, ansible est capable de générer automatiquement
son inventaire à partir des APIs d’un Cloud provider ou des services tiers, pour pouvoir ensuite
l’utiliser.
Les inventaires ansible peuvent contenir des variables relatives aux instances mais pour
gagner en clarté, les variables sont placées dans les group_var et des host_var.
L’inventaire fournit la liste des hôtes sur lesquels ansible exécutera les tâches. Il peut
également être utilisé pour regrouper les hôtes et configurer les variables pour les hôtes et les
groupes.
Page | 52
Figure 3. 7 Fichier host
3.3.1.2 Playbooks
Les playbooks sont une manière complètement différente d’utiliser ansible que dans le
mode d’exécuter de tâches ad hoc, et sont particulièrement puissants.
En un mot, les playbooks sont la base d’un système de gestion de configuration et de
déploiement d’application complexes. Les playbooks peuvent déclarer des configurations, mais
ils peuvent également orchestrer les étapes de tout processus de commande manuelle, même si
différentes étapes doivent rebondir entre des ensembles des machines dans des ordres particuliers.
Ils peuvent lancer des tâches de manière synchrone ou asynchrone.
Le playbook est le langage de configuration d’ansible utilisé pour effectuer l’ensemble
des tâches et d’étapes de configuration ou pour faire appliquer une politique sur les nœuds
distants. Les modules Ansible sont utilisés dans les Playbook pour exécuter une opération. Le
playbook est écrit en YAML qui est un langage simple, lisible par l’homme et développé dans un
anglais de base comme la langue du texte. Les playbooks sont plus susceptibles d’être conservés
dans le système de contrôle de version et utilisés pour les configurations des systèmes distants
[8].
Page | 53
Figure 3. 8 ansible playbook
3.3.1.3 SSH Trust
Par défaut, ansible essaiera d’utiliser OpenSSH en natif pour les communications à
distance lorsque cela est possible. Cela active ControlPrsist (une fonctionnalité performante),
Kerberos et des options dans ~/.ssh/config, telles que la configuration de l’hôte sauté. Quand nous
parlons avec des machines distantes, ansible suppose par défaut que nous utilisons des clé SSH.
Figure 3. 9 ssh trust

Page | 54
3.4 Présentation de Veeam Backup & restauration

Veeam software est une société privée spécialisée en technologie de l’information et en
développement de logiciel de sauvegarde, de reprise d’activité et d’administration des
environnements virtualisés pour VMware et Hyper-V. Le siège social de l’entreprise se trouve à
Baar (Suisse) ou la société produit des logiciels pour la virtualisation et le nom Veeam provient
de la prononciation de l’acronyme anglais VM Virtual machine [9].
La technologie Veeam a été fondée en 2006 par Ratmir Timashev, au début les produits
que Veeam avait publié c’est le reporter et le monitor qui sont des outils de supervision de
documentation et d’analyse des infrastructures virtuelles. En 2007 la société a pu attirer l’attention
grâce à son produit gratuit de copie des sauvegardes de machines virtuelles. ce qui lui a couté de
l’admiration auprès des entreprises.
Avec seulement 10 employés, la société a pu publier son premier produit de Veeam
backup et réplication et après s’en est suivi plusieurs autres produits de Veeam software et le
dernier produit publié dernièrement en 2015 c’est le Veeam Availability suite.
3.4.1 Différents produits de Veeam software
Parmi les produits de Veeam software nous avons :
➢ Veeam Backup et Réplication : c’est un logiciel de sauvegarde des données et de
reprise d’activité pour les machines virtuelles VMware VSphere et Microsoft
Hyper-V
➢ Veeam ONE : logiciel de supervision, génération de rapports et planification de
capacité pour les environnements virtuels VSphere et Hyper-V.
➢ Veeam stencils : c’est un outil de schémas de Microsoft Visio pour la
virtualisation et destinée pour les diagrammes.
➢ Veeam Task Manager : c’est un outil gratuit pour surveillance en temps réel de
la performance Hyper-V
➢ Veeam Management Pack : logiciel de supervision et d’administration des
environnements virtuels
➢ Veeam Generic Report Library : qui est un ensemble d’intégrité complémentaires
et de rapports d’analyse de performances.
➢ Veeam Endpoint Backup : c’est un outil de backup gratuit pour les ordinateurs et
laptop avec Windows.
➢ Veeam Backup Essentials : c’est une suite logicielle regroupant Veeam Backup
et réplication et Veeam ONE
➢ Veeam Availability suite : c’est aussi une suite logicielle regroupant Veeam
Backup et réplication et Veeam ONE destinée aux grands environnements.
En ce qui concerne notre travail nous allons parler de veeam backup et réplication
3.4.3 Edition de Veeam Backup
Veeam Backup et réplication a différentes éditions parmi lesquelles nous trouvons :
Page | 55
➢ Standard
➢ Enterprise
➢ Enterprise plus
3.4.4 Infrastructure de Veeam backup
Veeam backup et réplication fait partie d’une infrastructure client-serveur à 3 niveaux ou
3-tier. Dans l’architecture à 3 niveaux, il existe un niveau intermédiaire c’est-à-dire on a
généralement une architecture partagée entre le client qui est l’ordinateur demandeur de
ressources, un serveur d’application appelé également middleware chargé de fournir la ressource
mais faisant appel à un autre serveur ainsi que le serveur de données fournissant au serveur
d’application.
Le schéma ci-dessous montre comment Veeam Backup fonctionne [9]
Figure 3. 10 fonctionnement veeam backup
3.4.5 Exigences matérielle et logicielle de Veeam backup e réplication

3.4.5.1 Matérielle
➢ Un processeur 32 ou 64 bits
➢ Mémoire : 4 GB de RAM
➢ Espace disque : 2GB pour l’installation du produit, pour la machine virtuelle de
restauration un espace assez important est recommandé
➢ Carte réseau : 1Gbps sur site de backup et réplication et 1Mbps la vitesse hors
site backup et réplication.
3.4.5.2 Logicielle
Page | 56
Logicielle par rapport à Windows :

➢ Microsoft Windows Server 2012 R2
➢ Microsoft Windows server 2012
➢ Microsoft Windows server 2008 R2 SP1
➢ Microsoft Windows Server 2008 SP2
➢ Microsoft Windows 10
➢ Microsoft Windows8.X
➢ Microsoft Windows 7 SP1
Logicielle par rapport aux autres outils
➢ Microsoft Server 2016/2014/2008R2/2012
➢ System center virtual machine manager 2012R2/2012/2008R2
➢ Microsoft .NET. Framework 4.0 qui est inclus dans le setup
➢ Windows installer 4.5 inclus dans le setup
➢ Microsoft PowerShell 2.0 ou antérieur
➢ Internet explorer 9.0 ou antérieur
Veeam prend en charge la sauvegarde des machines virtuelles hébergées sous les
systèmes suivants :
➢ VMware
• ESXi 7
• ESXi6.0
• ESXi 5.x
• ESX/ESXi 4.x
• Version gratuite de VMware ESXi n’est pas pris en charge

➢ Microsoft
• Windows Server Hyper-V 2012 (Jusqu’à R2)
• Windows server 2008R2 SP1 avec Hyper-V (installation de base incluse)
• Microsoft Hyper-V Server 2008 R2 SP1 (Hyperviseur gratuit)
• Windows server 2012 avec Hyper-V
• Microsoft Hyper-V Server 2012 R2 SP1 (Hyperviseur gratuit)

Page | 57
3.5 Planification et tests

Voici la liste des modules à installer et à configurer :
➢ ESXi (virtualisation)
➢ Ansible (automatisation)
➢ Veeam Backup (sauvegarde & r »plication)
3.5.1 Plans d’installation
3.5.1.1 ESXi
3.5.1.1.1. Exigences matérielles
Pour pouvoir installer l’hyperviseur ESXi, nous aurons besoin, en termes d’exigences
matériels de :
➢ Un processeur d’au moins deux cœurs x86 64 bits commercialisé après
septembre 2006
➢ Une mémoire vive d’au moins 4 gigas, mais il est recommandé de fournir
au moins 8 gigas dans les environnements de production
➢ Pour prendre en charge des machines virtuelles 64 bits, la prise en charge
de la virtualisation matérielle (Intel VT-X ou AMD RVI) doit être activée
sur les processeurs x64
➢ Avoir au moins une carte réseau Ethernet Gigabit, mais il est
recommandé d’en avoir deux dans un environnement de production
3.5.1.1.2 Procédure d’installation
Avant de pouvoir passer à l’installation, il faut toujours vérifier si le système dispose la
configuration matérielle requise minimale.
Les conditions préalables :
➢ Le fichier ISO d’installation de ESXi doit se trouver à l’un des
emplacements suivants :
• Sur le CD ou DVD
• Sur une clé USB

➢ Vérifier si l’horloge du matériel du serveur est paramétré en UTC, ce
paramètre se trouve dans le BIOS
➢ Vérifier que le clavier et l’écran sont raccordé à la machine sur laquelle
le logiciel ESXi est installé
➢ Penser à déconnecter votre stockage en réseau.
Procédures d’installation :
Page | 58
➢ Insérer le cd ou DVD d’installation de ESXi dans le lecteur CD/DVD-

ROM ou brancher la clé USB d’installation et redémarrer la machine.
➢ Configurer le BIOS de manière de sorte qu’il démarre à partir du CD-
ROM ou de la clé USB
➢ Dans la page sélectionner un disque, sélectionner le lecteur sur lequel
installer ESXi et appuyer sur Enter
➢ Sélectionner le type de clavier de l’hôte
➢ Entrez le mot de passe racine de l’hôte
➢ Appuyer sur Enter pour démarrer l’installation
➢ Lorsque l’installation est terminée, retirez le CD, DVD ou la clé USB
d’installation
➢ Appuyer sur enter pour redémarrer l’hôte
3.5.1.2 Ansible
3.5.1.2.1 Exigences matérielles
Voici les exigences requises pour l’installation de Ansible :
➢ Une mémoire RAM d’au moins 4 gigas
➢ Au moins 20 gigas d’espace disque dédié
➢ L’ordinateur doit avoir au moins une carte réseau
➢ Configuration requise pour le nœud :
• Sur les nœuds gérés, nous aurons besoin d’un système de

communication, qui est normalement ssh par défaut, cela utilise sftp. Si
cela n’est pas disponible, nous pouvons passer à scp dans ansible. Fg.
Nous aurons également besoin de Python 3 (version 3.8)
3.5.1.2.2 Procédure d’installation :
Système d’exploitation pris en charge :
➢ Red Hat Enterprise Linux6 64 bits
➢ Red Hat Enterprise Linux 7 64 bits
➢ CentOS6 64 bits
➢ CentOS7 64 bits
➢ Ubuntu 20.04 LTS 64 bits
➢ Ubuntu 21.04 LTS 64 bits
Installation du nœud de contrôle sur Fédora :
➢ Sudo dnf install ansible
Page | 59
Sur RHEL et CentOS :

➢ Sudo yum install ansible
Sur Ubuntu :
➢ Sudo apt update
➢ Sudo apt install software-properties-common
➢ Sudo apt-add-repository –yes –update ppa:ansible/ansible
➢ Sudo apt install ansible
Sur Debian:
➢ Ajouter la ligne suivante à /etc/apt/sources.list : de
➢ http://ppa.launchpad.net/ansible/ansible/ubuntu trusty main
➢ Puis lancez ces commandes:
➢ Sudo apt-key adv –keyserver keyserver.ubuntu.com –recy-keys
93C4A3FD7BB9C367
➢ Sudo apt update
➢ Sudo apt install ansible
Sur Gentoo:
➢ Emerge -av app-admin/ansible
➢ Echo ‘app-admin/ansible/>>/etc/portage/package.accept_keywords
Sur FreeBSD :
➢ Bien qu’ansible fonctionne avec les versions Python 2 et 3, FreeBSD propose
différents package pour chaque version Python. Donc, pour installer, nous
pouvons utiliser :
➢ Sudo pkg install py27-ansible ou
➢ Sudo pkg install py36-ansible
3.5.1.3 Veeam Backup
3.5.1.3.1 Exigences matérielles
Voici les exigences requises pour l’installation de Ansible :
➢ Infrastructure physique : Windows (client ou serveur), Linux, MAC
➢ 4gigas de RAM
Page | 60
➢ Processeur ayant au moins deux cœurs

3.5.1.3.2 Procédure d’installation
➢ Télécharger la dernière version de Veeam Agent pour Windows à partir de
www.veeam.com/downloads.html
➢ Double-cliquer sur le fichier de veeam télécharger pour lancer l’installation
➢ Lire et accepter les termes du contrat de licence
➢ Cliquer sur installer
➢ Une fois le produit installé, il vous sera proposé de brancher un stockage externe
à utiliser comme cible de sauvegarde.
3.5.2 Plan de configuration
3.5.2.1 ESXi
Module existant déjà au sein de l’entreprise « Anonymous »
3.5.2.2 Ansible
Module existant déjà au sein de l’entreprise « Anonymous », nous serons juste obligé de
reconfigurer un fichier inventaire existant ou créer un nouveau fichier, où nous allons spécifier le
nœud sur lequel il y aura veeam backup.
3.5.2.3 Veeam Backup
Nous tenons à signaler que la configuration de notre VBR se fera d’une manière
automatique grâce aux playbooks ansible et scripts PowerShell.
Outre la configuration de veeam backup, nous devons aussi configurer Winrm sur le nœud
(Windows server 2016 pour qu’il puisse communiquer avec le contrôleur.
Et voici une liste des configurations à faire :
➢ L’ajout d’un backup repository : Pour configurer l’endroit où nous allons stocker
nos sauvegardes, nous devons créer ou ajouter un backup repository au VBR
dans Backup infrastructure.
➢ Ajout d’un serveur (Hyperviseur ESXi)
➢ Ajouter une tâche de sauvegarde
➢ Ajouter d’une tâche de réplication
➢ Démarrer une tâche (sauvegarde ou réplication)
➢ Restaurer une ou plusieurs machines virtuelles
➢ Supprimer un backup repository
➢ Supprimer un serveur du backup infrastructure
➢ Supprimer une tâche (sauvegarde ou réplication)
➢ Démarrer VBR
Page | 61
3.5.3 Tests
3.5.3.1 Tests unitaires
Notons ici que les modules (ESXi et Ansible) sont épargnés pour ces tests, car c’est des
modules qui fonctionnent déjà au sein de l’entreprise « Anonymous »
3.5.3.1.1 Veeam Backup
Sur le nœud veeam, nous aurons à vérifier si :
➢ Winrm a été bien configuré
➢ Les configurations de la carte réseau sont bien faites à l’aide des utilitaires
suivants :
• IPCONFIG
• NSLOOKUP
➢ Le repository a été bien installé
• En mode graphique
• Get-VBRBackupRepository
➢ Le serveur ESXi a été bien ajouté
• Get-VBRServer
• En mode graphique
3.5.3.2 Test intégral
➢ Connectivité entre ansible et veeam backup : pour ce test nous allons utiliser
l’utilitaire PING
➢ Tester si la sauvegarde des machines virtuelles s’effectue normalement
• Get-VBRBJob -type backup : commande à taper après avoir démarré une

tâche de sauvegarde
➢ Tester si la réplication des machines virtuelles est effective
• Get-VBRJob -type replication

➢ Vérifier si la restauration s’effectue normalement après avoir simulé une panne.
Page | 62

Au cours de ce chapitre nous avons choisi les différents modules qui implémentent les
fonctions logiques. Nous avons aussi décrit l’architecture physique et enfin nous avons décrit les
plans d’installation et de configuration de nos différents modules qui vont nous permettre de bien
implémenter notre solution.
Page | 63
CHAPITRE 4 IMPLEMENTATION
4.1 Introduction
Dans ce chapitre il est question de mettre en œuvre notre solution que nous avons défendu
depuis le début, nous vous épargnerons trop de théories, étant donné que cela a été déjà fait dans
notre plan d’implémentation.
Pour notre implémentation nous aurons juste besoin de trois machines, une machine va
nous servir de contrôleur (sur lequel nous allons installer ansible), la deuxième va nous permettre
d’installation de veeam backup (nœud qui sera géré par notre contrôleur) et sur la dernière nous
allons installer dessus ESXi qui va nous permettre de créer les machines virtuelles que nous
devons répliquer et sauvegarder
4.2 Installations
4.2.1 Installation de veeam backup
Exécuter Setup.exe pour lancer le programme d’installation.

Après avoir télécharger le fichier ISO de sauvegarde et de réplication Veeam. Montez le
fichier ISO en tant que lecteur dans le système d’exploitation du serveur. Puis double-cliquez sur
le fichier Seup.exe pour démarrer l’installation.
Figure 4. 1 dossier iso veeam backup

Page | 64
Cliquez sur le bouton Install, puis patienter
Figure 4. 2 bouton install

Page | 65
Cochez les deux cases
Figure 4. 3 Case à cocher
Sélectionner le bouton parcourir ou browser pour sélectionner la licence Veeam puis cliquer sur
suivant.
Figure 4. 4 bouton parcourir

Page | 66
Choisissez les composant que nous allons installer, laisser le choix par défaut
Figure 4. 5 Sélection utilitaires
Cliquer sur installer pour installer les composants manquants
Figure 4. 6 Composant manquants

Page | 67
Cliquer sur suivant
Figure 4. 7 Installation composants
Cliquer sur installer
Figure 4. 8 Lancer installation

Page | 68
Patientez l’installation
Figure 4. 9 Progression installation
Fin d’installation, cliquer sur finish
Figure 4. 10 Fin installation

Page | 69
Vous verrez apparaitre l’icône de veeam backup & replication sur votre bureau
Figure 4. 11 Icône veeam backup
4.2.2 Installation de Ansible
Figure 4. 39 Mise à jour des packages

Page | 70
Figure 4. 40 Installation ansible
Figure 4. 41 Vérification ansible
4.3 Configurations
4.3.1 Configuration des cartes réseaux
La configuration des cartes réseaux de nos deux machines (le node et le contrôleur), et la
fixation des adresses avec netplan.
4.3.1.1 Contrôleur (Ubuntu)
Dans le terminal en tant que root tapez les commandes :
➢ Ifconfig ens38 10.10.1.5 netmask 255.0.0.0
Page | 71
➢ nano /etc/netplan/01-network-manager-all.yaml
Figure 4. 12 Netplan configuration
Figure 4. 13 Configuration NetPlan
4.3.1.2 Node (windows16)

Voici une les étapes à suivre pour configurer la carte réseau sur Windows server 2016 :
Windows + R
Tapez ncpal.cpl
Figure 4. 14 Boite de dialogue
Choisir la carte réseau
Figure 4. 15 Selection carte réseau

Page | 72
Figure 4. 16 Sélection type adressage
Figure 4. 17 Configuration carte réseau Windows
4.3.2 Importation du module veeam.backup.powershell

La commande import-module veeam.backup.powershell -verbose nous permet
d’ajouter le module veeam à PowerShell [10]
Page | 73
4.3.3 Configuration du fichier host

Ce fichier contient le nom ou l’adresse IP de tous les nœuds à) gérer, dans notre cas nous
aurons juste à ajouter une seule machine.
Figure 4. 18 edit file host
Figure 4. 19 config ficher host
4.3.4 Configuration du fichier de variables

Premièrement il faut créer un fichier ayant l’extension yml dans le répertoire
/etc/ansible/grop_vars
Dans lesquels vous aurez à configurer :
Tapez ansible-vault edit windows.yml
Figure 4. 20 configuration fichier variables

Page | 74
4.3.5 Configuration de winrm sur le node

Winrm est le protocole que nous allons utiliser pour pouvoir faire communiquer le
contrôleur et le nœud
Un script configurant winrm et l’autorisant sur le pare-feu de Windows serveur 2026 doit
être exécuté afin de permettre une communication distante avec le contrôleur ansible. Ce script
est disponible en ligne sur le site officiel de Red Hat.
Figure 4. 21 Script Winrm
4.3.6 Création des playbooks et scripts PowerShell pour la gestion de veeam backup
4.3.6.1 La création du repository
Figure 4. 22 playbook repository

Page | 75
Figure 4. 23 script PowerShell création repository
4.3.6.2 Ajouter un serveur (hyperviseur ESXi)
Figure 4. 24 playbook ajouter serveur
Figure 4. 25 script ajouter serveur

Page | 76
4.3.6.3 Création de la tâche de sauvegarde de la machine virtuelle
Figure 4. 26 Playbook création tâche sauvegarde
Figure 4. 27 Script création tâche sauvegarde

Page | 77
4.3.6.4 Création de la tâche de la réplication de la machine virtuelle
Figure 4. 28 Playbook tâche réplication
Figure 4. 29 Script tâche de réplication

Page | 78
4.3.6.5 démarrer une tâche (sauvegarde ou réplication)
Figure 4. 30 Playbook Démarrer tâche sauvegarde ou réplication
Figure 4. 31 Script démarrer tâche sauvegarde ou réplication

Page | 79
4.3.6.6 Restaurer machines virtuelles
Figure 4. 32 Playbook restaurer machine virtuelle
Figure 4. 33 Script restaurer machine virtuelle

Page | 80
4.4 Tests
Cette étape présente le résultat obtenu après les différentes configurations réalisées par
rapport à chaque module du système.
4.4.1 Repository
Figure 4. 34 Test repository

Page | 81
4.4.2 Ajout du serveur ESXi
Figure 4. 35 test ajout ESXi
4.4.3 Tâche sauvegarde
Figure 4. 36 Test tâche de sauvegarde

Page | 82
4.4.4 Tâche de réplication
Figure 4. 37 Test t tâche réplication
4.4.5 Restaurer machines virtuelles
Figure 4. 38 test restauration machine virtuelle

Page | 83
4.5 Evaluation des besoins

4.5.1 Evaluation des besoins fonctionnels
Tableau 4. 1 Evaluation des besoins fonctionnels
Besoins Evaluations Notes
Sauvegarder machine virtuelle 100% Testé avec succès
Répliquer machine virtuelle 100 % Testé avec succès
Restaurer machine virtuelle 100% Testé avec succès
Automatiser processus 100% Testé avec succès

sauvegarde, replication et
restauration
Total 100%
4.5.2 Evaluation des besoins non fonctionnels
Tableau 4. 2 Evaluation des besoins non fonctionnels
Besoins Evaluation Notes
Disponibilité 80% Le système est disponible

Performance 95% Le système est performant
Coût 70% Le coût est moyen
Interopérabilité 85% Le système est
interopérable
Déploiement facile 80% Le déploiement est facile
Total 82%
Page | 84

Toute somme, nous avons tout au long de ce chapitre implémenté notre système comme
cela a été prévu au niveau de la conception technique. Ce chapitre a permis en fait de matérialiser
la conception logique réalisée au précèdent chapitre, et 100% des fonctionnalités ont été
implémenté par rapport aux besoins fonctionnels.
Page | 85
CONCLUSION GENERALE
Ce travail a traité sur la sauvegarde automatique des machines virtuelles dans un

Datacenter avec ansible, Il s’agissait de prévoir un plan de reprise après sinistre pour
l’entreprise « Anonymous, pas seulement ça mais aussi faciliter la tâche aux
administrateurs de configuration manuelle qui prend beaucoup de temps vu la grandeur
de l’infrastructure à gérer.
Pour y arriver nous avons utilisé les grands principes de l’ingénierie des systèmes
qui constituent à diviser les tâches dans des différents modules afin de partir du général
au particulier. Voilà pourquoi notre travail a été structuré en quatre parties.
Dans la première section de notre travail nous avons étudié l’infrastructure de
l’entreprise Anonymous afin de pouvoir y ressortir les besoins que nous avons par la suite
transformé en exigences fonctionnelles du futur système.
En suite est intervenue la deuxième partie de notre travail, où on a été appelé à
concevoir l’architecture logique du futur système. Nous sommes partis de l’architecture
logique générale, qui nous a permis d’avoir une vue globale du futur système à
l’architecture logique détaillée, qui à son tour nous a permis d’étudier en profondeur les
différentes composantes ou modules de notre futur système.
Après avoir conçu logiquement notre système, nous sommes passés à l’étape trois
de notre projet, où nous avons essayé de concevoir l’architecture physique du futur
système. Dans cette section nous avons, à partir des études comparatives des différentes
technologies avons trouvé les meilleures technologies pour afin passer à la dernière étape
de notre travail, qui est bel et bien l’implémentation.
Au cours de l’implémentation, nous sommes allés de l’installation et configuration
de veeam backup et réplication à l’installation et configuration de ansible, ensuite avons
établis une connexion Winrm entre nos différents nœuds, puis nous avons par la suite
créer nos différents modules qui nous permettaient de pouvoir automatiser les tâches de
sauvegarde.
Il serait prétentieux de dire que l’on a épuisé le sujet car beaucoup reste encore à
faire. Il y a certainement des choses à améliorer à l’issue de ce travail. Celui-ci ouvre
néanmoins d’autres perspectives qui pourront être élucidés par d’autres travaux.
Page | 86
REFERENCES
[1] C. N. NTUMBA, «La haute disponibilité de données dans un datacenter par la

réplication et backup,» ESIS, LUBUMBASHI, 2016.
[2] A. S. KAMANGA, «Etude et mise en place d'un système de sauvegarde et de

réstauration des données dans un intranet,» ESIS, Lumbubashi, 2013.
[3] NetExplorer, NetExplorer, 01 Décmbre 2021. [En ligne]. Available:

https://www.netexplorer.fr/blog/quels-sont-les-differents-types-de-sauvegardes.
[Accès le 10 Décembre 2021].
[4] C. goyard, «Définition d'une sauvegarde informatique,» 21 mai 2019. [En ligne].
Available: https://www.appvizer.fr/magazine/services-
informatiques/sauvegarde/definition-dune-sauvegarde-informatique-1472940000.
[Accès le 28 novembre 2021].
[5] R. futura, «Sauvegarde qu'est-ce que c'est,» Futura Redaction, [En ligne].
Available: https://www.futura-sciences.com/tech/definitions/sauvegarde-
sauvegarde-18146/. [Accès le 10 Décembre 2021].
[6] J. B. Eric FOURN, VMware vSphere6, concevoir votreinsfrastructure de

virtualisation, Paris: Eni, 2017.
[7] C. ARNAUD, Les hyperviseurs, Grenoble: Eyrolles, 2019.
[8] M. DeHaan, Ansible, gérer la configuration de vos serveurs et le deploiement de

vos applications, Madrid: Eni, 2018.
[9] S. HEBERLE, Veeam Backup & Réplication, assurer la disponibilité de vos

données dans un datacenter, Madrid: Eni, 2019.
[10] A. Zhelezko, «VEEAM,» Veeam product, 5 Décembre 2017. [En ligne]. Available:
https://www.veeam.com/blog/start-microsoft-powershell-cmdlets.html. [Accès le
02 Décembre 2021].
[11] L. parisien, « parisien,» Le parisien, [En ligne]. Available:

http://dictionnaire.sensagent.leparisien.fr/support%20magn%C3%A9tique/fr-fr/.
[Accès le 10 novembre 2021].
[12] TechLib, «TechLib,» [En ligne]. Available:

https://techlib.fr/definition/opticalmedia.html. [Accès le 15 Décembre 2021].
Page | 87

TFC As 2022 Mukoma Tshammoyo Patrick

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

TFC As 2022 Mukoma Tshammoyo Patrick

Transféré par

Droits d'auteur :

Formats disponibles

ECOLE SUPERIEURE D’INFORMATIQUE SALAMA

République Démocratique Du Congo

MISE EN PLACE D’UN SYSTEME DE BACKUP ET REPLIQUE

« Cas d’une entreprise anonyme »

Travail présenté et défendu en vue de

MISE EN PLACE D’UN SYSTME DE BACKUP ET REPLIQUE

« Cas d’une entreprise anonyme »

Travail présenté et défendu en vue de

Je suis reconnaissant aux autorités de l’Ecole Supérieure d’Informatique Salama. Je dis

Toute ma reconnaissance à Percy MULENGA LUMUNA, Boanèrges TSHEBWE

LISTE DES FIGURES

Figure 1. 1 Architecture logique de haut niveau ........................................................... 14

Figure 2. 1 Architecture logique générale ...................................................................... 26

Figure 3. 1 choix outil automatisation ............................................................................ 43

Figure 4. 1 dossier iso veeam backup ............................................................................. 63

Figure 4. 10 Fin installation ............................................................................................ 68

LISTE DES TABLEAUX

Tableau 1. 1 adressage kolwezi ...................................................................................... 10

Tableau 2. 1 Liste des modules du futur système ........................................................... 27

Tableau 3. 1 listes des outils d’automatisation ............................................................... 40

Tableau 4. 1 Evaluation des besoins fonctionnels .......................................................... 83

LISTE DES ACRONYMES

BIOS: Basic Input Output System

TABLE DES MATIERES

1.3.2 Système informatique ...................................................................................... 9

3.4.1 Différents produits de Veeam software ......................................................... 54

Régie par le programme national de la République Démocratique du Congo,

➢ Quelle technique ou démarche pouvons-nous mettre en place afin d’éviter aux

En général voici donc la constitution de notre solution :

➢ Nous aurons besoin d’un outil d’automatisation qui va nous permettre

➢ L’implémentation, cette technique nous a permis d’implémenter notre solution,

➢ La conception, nous a permis de définir la mise en place de notre système.

➢ La documentation, grâce à cette technique, nous avons pu acquérir beaucoup de

0.5 Etat de la question

➢ Anicet SAKALA KAMANGA, Etude et mise en place d’un système de

0.6 Délimitation du travail

besoins et de planifier une implémentation de notre

➢ CHAPITRE 2. CONCEPTION LOGIQUE DU SYSTEME. Dans ce chapitre

➢ CHAPITRE 3. CONCEPTION PHYSIQUE DU SYSTEME. Ce chapitre

➢ CHAPITRE 4. L’IMPLEMENTATION GENERALE. Dans ce chapitre nous

0.8 Outils logiciels et équipements utilisés

➢ Microsoft office Excel 2016

➢ Wonder Share PDFelement

CHAPITRE 1 SPECIFICATION TECHNIQUE DU FUTUR SYSTEME

➢ Les super intendants

Des problèmes sociaux au sein de l’équipe IT empêchent un meilleur professionnalisme

1.3.1.4 Description détaillée des villes minières

1.3.2.2 Plan d’adressage

SITE DEPARTEMENT SUBNET NETMASK

SITE USINE GRAND UZDK 10.10.0.0 255.255.192

SITE DEPARTEMENT SUBNET NETMASK

SITE USINE GRAND KAM 10.11.0.0 255.255.192

SITE DEPARTEMENT SUBNET NETMASK

SITE ADMINISTRATIF BUREAU1 10.12.0.0 255.255.224

1.3.2.3 Plan de nommage

Tableau 1. 4 Plan de nommage

ID Nom du site Ville Code Site

1 Site de l’usine 1 Kolwezi USKOL

1.3.3 Architecture logique de haut niveau de l’infrastructure

Figure 1. 1 Architecture logique de haut niveau

1.3.3.1 Architecture logique détaillée

Figure 1. 2 Architecture logique détaillée

1.3.3.3 LAN détaillé par site