Rapport MBINA MBOUMBA Wilde

MEMOIRE POUR L’OBTENTION DU DIPLOME DE
Master Ingénierie Informatique, Réseaux et

Télécommunications
THEME : VIRTUALISATION DE SERVEURS : CAS DE LA SOCIETE

DE PATRIMOINE DU SERVICE PUBLIC DE L'EAU POTABLE, DE
L'ENERGIE ÉLECTRIQUE ET DE L’ASSAINISSEMENT
Réalisé par : Wilde Kisteul MBINA MBOUMBA
Encadreur Pédagogique : Encadreur en Entreprise :
Dr. PAMBA CAPOCHICHI Eugène M. BANGOYE TITSE François
Enseignant ESGIS Directeur des Systèmes d’Informations
Année Académique : 2021-2022
MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com

VIRTUALISATION DE SERVEURS : CAS DE LA SOCIETE DE
PATRIMOINE DU SERVICE PUBLIC DE L'EAU POTABLE, DE
L'ENERGIE ELECTRIQUE ET DE L’ASSAINISSEMENT
DEDICACE
Je dédie ce travail à :
Mon cher père MBOUMBA Alain
Ma chère mère MPAPPEE Danielle
Qu'aucune dédicace ne puisse exprimer mes sentiments sincères pour eux, pour leur infinie
patience, leurs encouragements indéfectibles, leur aide, la preuve de leur profond Amour et de
leur soutien, mon respect pour leurs grands sacrifices.
Merci infiniment

REMERCIEMENTS
C’est avec un grand plaisir que je réserve cette page, en signe de profonde reconnaissance à
tous ceux qui m’ont aidé à la réalisation de ce travail.
Je tiens à exprimer mes vifs remerciements au Docteur PAMBA CAPOCHICHI Eugène
pour son dévouement, son soutien et ses contributions tout au long de ce travail.
Je ne manquerai pas d’exprimer ma profonde gratitude à l’égard de mon encadrant en milieu
professionnel, le Directeur des Systèmes d’Information, Monsieur BANGOYE TITSE
François, pour son dévouement, son soutien et son apport tout au long de la préparation de ce
mémoire et bien sûr à toutes les équipes de la Société de Patrimoine du Service Public de
l'Eau Potable, de l'Energie Électrique et de l’Assainissement (SP).
Je n’oublierai pas l’ensemble des enseignants de l’EGIS qui ont contribué à notre formation ;
qu’ils trouvent ici toute notre gratitude.
Aussi, je remercie infiniment ma fiancée, MENGUE M’ELLA, qui m’accompagne dans
toutes les épreuves de ma vie.
Enfin, je tiens à remercier tous les membres du jury d’avoir accepté d’évaluer mon travail.

RESUME
De nos jours les entreprises doivent fournir plus de servir et la plupart de temps avec des
budgets en permanence baissent. Elles doivent être suffisamment souples et réactives pour
répondre efficacement aux besoins de l’activité qui est la source des revenus de l'entreprise.
Le système traditionnel de gestion d’une infrastructure serveur qui consiste à octroyer un
serveur physique à une application est devenu totalement obsolète. De nombreuses entreprises
optent pour la virtualisation des serveurs.
A l’instar de toutes ces entreprises, la Société de patrimoine a décidé de virtualiser son
architecture serveur. L’objectif dans ce mémoire est de proposer une architecture de
virtualisation de serveur totalement redondant.
La problématique est par conséquent la suivante : Comment la virtualisation de serveur
peut-elle réformer et améliorer l’infrastructure serveurs de la Société de Patrimoine ?
Pour répondre à cette problématique, premièrement, les concepts de virtualisation sont
abordés de manière concise, et ce, dans l’unique but de présenter aux lecteurs les biens fondés
de cette technologie. Ensuite nous avons mis en place une architecture de stockage SAN HP
P2000. C’est sur cette dernière que nous avons configuré le cluster de basculement Hyper-V.
Ce dernier permet à des machines virtuelles de basculer, sans interruption de service, sur un
autre hôte en cas des défaillances de l’hôte qui les exécutent. Une fois le cluster en place nous
avons installé tous les serveurs essentiels que ne disposait pas la Société de Patrimoine.
La virtualisation de l’infrastructure serveur de la Société de patrimoine nous a permis de
restructurer notre environnement serveur. Nous avons ainsi migré notre contrôleur de
domaine qui était sous Windows 2008, vers la version 2016 ; elle nous a doté aussi des
serveurs d’antivirus, de stockages et sauvegarde. Nous obtenons finalement une architecture
totalement agile. Si dans le future nous avons besoin d’un nouveau serveur en quelques
minutes il suffit de créer une machine virtuelle et la mettre en production.
ii
ABSTRACT
Businesses these days have to provide more service and most of the time with constantly
shrinking budgets. They must be sufficiently flexible and reactive to respond effectively to the
needs of the activity which is the source of the company's income. The traditional system for
managing a server infrastructure, which consists of granting a physical server to an
application, has become totally obsolete. Many companies are opting for server virtualization.
Like all these companies, the Society of Patrimoine has decided to virtualize its server
architecture. The objective in this rapport is to propose a fully redundant server virtualization
architecture.
The problem is therefore the following: How can server virtualization reform and improve the
server infrastructure of the Heritage Company?
To answer this problem, first, the concepts of virtualization are approached in a concise
manner, and this, for the sole purpose of presenting to readers the merits of this technology.
Then we implemented an HP P2000 SAN storage architecture. It is on the latter that we have
configured the Hyper-V failover cluster. The latter allows virtual machines to failover,
without interruption of service, to another host in the event of failures of the host which runs
them. Once the cluster was in place, we installed all the essential servers that Society of
Patrimoine did not have.
The virtualization of Society of Patrimoine’s server infrastructure allowed us to restructure
our server environment. We therefore migrated our domain controller, which was under
Windows 2008, to the 2016 version; it also provided us with antivirus, storage, and backup
servers. We finally obtain a totally agile architecture. If in the future we need a new server in
a few minutes, just create a virtual machine and put it into production.
iii
Table des matières

DEDICACE................................................................................................................................................i
REMERCIEMENTS....................................................................................................................................i
RESUME..................................................................................................................................................ii
ABSTRACT..............................................................................................................................................iii
INTRODUCTION......................................................................................................................................4
Chapitre 1 : Présentation de la structure d’accueil................................................................................6
1. Societé de Patrimoine du service public de l'eau potable, de l’Energie électrique et de
l’assainissement (SP)..........................................................................................................................7
1.1 Historique et missions de la SP...........................................................................................7
1.2 Organisation de la SP..........................................................................................................8
2. Analyse de l’existant et Problématique....................................................................................11
2.1 Architecture de l’infrastructure système existante..........................................................11
2.2 Problématique..................................................................................................................13
Chapitre 2 : Généralités sur les concepts de Virtualisation de serveurs...............................................12

2.1 Présentation générale de la virtualisation............................................................................13
2.2 Différents types d’hyperviseur..............................................................................................14
2.2.1 Hyperviseur de type 1...................................................................................................14
2.2.2 Hyperviseur de type 2...................................................................................................15
2.3 Domaine d’application de la virtualisation...........................................................................16
2.3.1 La virtualisation de serveurs.........................................................................................16
2.3.2 La virtualisation d’application.......................................................................................17
2.3.3 La virtualisation de stations de travail..........................................................................17
2.3.4 La virtualisation de stockage.........................................................................................18
2.4 Avantages de la virtualisation...............................................................................................20

2.4.1 Réduction des coûts CAPEX/OPEX................................................................................20
2.4.2 Simplification du déploiement et de l’administration...................................................23
2.4.3 Gestion optimisée de l’obsolescence du matériel........................................................24
2.4.4 Simplification des tests logiciel.....................................................................................25
2.5 Techniques de Redondance dans la virtualisation................................................................26
2.5.1 Présentation du cluster de basculement......................................................................26
2.5.2 Architecture d’un cluster de basculement Hyper-V......................................................26
2.5.3 Descriptif de l’architecture d’un cluster de basculement....................................................27
Chapitre 3 : Virtualisation de serveurs : cas de la SP............................................................................29

3.1 Design de l’architecture de la solution de virtualisation.......................................................30
3.2 Planning des travaux.............................................................................................................31
3.3 Installation de l’hyperviseur HV0 (ADDS et serveur Backup)......................................................34
3.3.1 Installation et configuration de l’hyperviseur HV0..............................................................34
3.3.2 Migration d’active directory 2008 vers 2016.......................................................................34
3.3.3 Installation du serveur backup.............................................................................................42
3.4 Mise en place d’un SAN HPE StorageWorks P2000 FC G3....................................................43
3.4.1 Composants de notre architecture SAN HPE StorageWorks P2000 FC G3...........................43
3.4.2 Architecture physique des HP StorageWorks 8/8 SAN Switch......................................46
3.4.3 Configuration des HP StorageWorks 8/8 SAN Switch...................................................48
3.4.4 Configuration de la baie de stockage HP P2000 FC G3.................................................56
3.4.5 Installation et Configuration des serveurs ProLiant DL380 Gen9 et connexion à la baie
de stockage HP P2000 FC G3........................................................................................................59
3.5 Configuration du cluster de basculement de serveurs.........................................................64
3.5.1 Installation du rôle Hyper-V et Clustering de basculement.................................................64
3.4.2 Validation du cluster de basculement.................................................................................65
3.5.3 Création du cluster de basculement....................................................................................68
3.6 Installation des serveurs dans le cluster...............................................................................74
3.7 Conversion des serveurs physiques existants en serveurs virtuels.......................................76

2
3.8 Réalisation des tests de basculement...................................................................................77
Chapitre 4 : Évaluation technique et budgétaire de la solution Proposée............................................79

4.1 Evaluation de la solution proposée.......................................................................................80
4.2 Évaluation budgétaire...........................................................................................................82
Chapitre 5 : Bilan.................................................................................................................................83

5.1 Remarques............................................................................................................................84
5.2 Suggestions.................................................................................................................................84
CONCLUSION........................................................................................................................................85
Références......................................................................................................Erreur ! Signet non défini.
Glossaire...............................................................................................................................................vii
Liste des figures.....................................................................................................................................ix
Liste des tableaux.................................................................................................................................xii
Annexe 1 : Installation et configuration Windows serveur 2019.........................................................xiii
Annexe 2 : Installation d’une machine virtuelle dans un cluster de basculement...............................xvi
3
INTRODUCTION GENERALE
De nos jours, les directions des systèmes d'information sont véritablement confrontées au
dilemme entre fournir chaque année davantage de services et recevoir des budgets de plus en
plus réduits. Elles doivent être suffisamment souples et réactives pour répondre efficacement
aux besoins de l’activité qui est la source des revenus de l'entreprise.
La quantité de données générées est également en constante augmentation, tandis que les
contraintes légales liées aux plans de continuité d'activité et de protection des données
accroissent la charge de travail des équipes informatiques. De nombreux centres de données
(Data Centers) sont affectés par des pénuries chroniques d'espace entraînant de nouvelles
difficultés lorsque des machines supplémentaires sont exigées par les métiers qui font face à
de nouveaux besoins. En outre, l'énergie est actuellement un autre sujet d'intérêt, les
entreprises n'ayant parfois pas la capacité ou la volonté de se doter de plus d'électricité pour
des raisons écologiques.
Il ressort clairement de ce qui précède que les méthodes classiques actuellement utilisées dans
les directions des systèmes d'information doivent évoluer et qu'une refonte des systèmes
d'information est donc nécessaire. La virtualisation utilise un logiciel qui simule les
fonctionnalités du matériel afin de créer un système virtuel. Elle est efficace pour supporter
les besoins métiers évoqués ci-dessus, tout en réduisant les coûts, tant pour l'acquisition
d'équipements, que pour l’énergie électrique et la maintenance.
C’est dans ce contexte que la Société de Patrimoine du Service Public de l'Eau Potable, de
l'Energie Électrique et de l'Assainissement (SP), souhaitait revitaliser et virtualiser son
infrastructure système et disposant déjà d'une infrastructure SAN HPE StorageWorks P2000
G3 FC, achetée il y a deux ans mais jamais configurée par manque de connaissances internes,
nous a demandé de procédé à la virtualisation de ses serveurs.
La solution proposée doit répondre aux objectifs suivants :
 Configurer la baie HP P2000 G3 FC ;
 Mettre en place un cluster de basculement de serveurs virtuels. Ce dernier nous
permettra non seulement d'installer certains serveurs virtuels indispensables que SP
ne possède pas, tels que le serveur de fichier et d’antivirus, mais également de
libérer de l’espace dans la salle des serveurs et d’économiser de l'énergie ;
 Fournir une infrastructure système de virtualisation de machine virtuelle
redondante ;
 Mettre en place une solution de sauvegarde de serveurs.
Pour réaliser notre travail, nous aborderons plusieurs notions telles que la virtualisation des
serveurs, les clusters de basculements de machines virtuelles, les procédés de sauvegarde et
la configuration des équipements SAN.
4
Afin de bien organiser notre mémoire, nous l’avons subdivisé en cinq chapitres :
Dans le premier chapitre, nous présenterons la structure d’accueil, analyserons la
problématique et analyserons l'existant.
Le deuxième chapitre sera consacré à l’état de l’art sur la virtualisation, dans lequel nous
expliciterons les différents concepts de la virtualisation.
Le troisième chapitre fera un focus sur la mise en place de la solution visée. Nous
aborderons l'environnement matériel et logiciel. Nous décrirons également les étapes de la
mise en place de la solution. Et nous enrichirons cette partie de quelques scénarios de
fonctionnement de notre nouvelle architecture.
Le chapitre quatre décrit la performance de la solution proposée et l'évaluation budgétaire.

Dans le dernier chapitre, nous passerons en revue les difficultés rencontrées et nous ferons des
recommandations pour améliorer le fonctionnement de la SP.
5
Chapitre 1 : Présentation de la

structure d’accueil
6
Dans cette partie, nous présenterons premièrement la structure d’accueil à travers son
historique, ses missions et son organisation. Deuxièmement, nous décrirons l’architecture de
son infrastructure système existante dans le but de le comprendre et d’en sortir la
problématique.
1. Societé de Patrimoine du service public de l'eau potable, de

l’Energie électrique et de l’assainissement (SP)
1.1 Historique et missions de la SP
1.1.1 Historique de la SP
La Société de Patrimoine (SP) du service Publique de l'énergie électrique et de

l'assainissement est un Etablissement Public à Caractère Industriel et Commercial (EPIC)
créée par le décret n° 01501/PR/MERH du 29 décembre 2011 portant création et organisation
de cette administration. Elle est implantée à Libreville et son siège social est situé à Louis. La
création de cette entreprise intervient pour pallier les difficultés d'accès à l'eau potable et à
l'électricité. La Société de patrimoine est détenue à 100% par l’Etat gabonais avec un capital
d’un milliard de FCFA (1 000 000 000 FCFA).
1.1.2 Missions de la SP
La Société de Patrimoine est un instrument de mise en œuvre de la politique d'exploitation et

de conservation de l'ensemble des équipements en matière d'énergie électrique, des ressources
hydrauliques et d'assainissement en République Gabonaise. Ses missions sont les suivantes :
 Découvrir, planifier, et gérer les infrastructures et autres installations qui sont la
propriété de l’Etat dans les domaines de l'eau, de l’électricité et de l’assainissement ;
 Produire, transporter et distribuer de l'énergie électrique, de l'eau potable et assainir les
eaux ;
7
 Assister le gouvernement dans l'identification des besoins de création et le

développement des réseaux de distribution d’eau potable et d’énergie électrique à
faible taux d'émission de gaz à effet de serre ;
 L’exploiter l'ensemble des unités de production d'énergie électrique telles que les
barrages hydrauliques, les centrales thermiques et les panneaux photovoltaïques
appartenant à l’Etat ;
 Préciser les conditions de mise en concession de l’exploitation de certaines unités de
production d’énergie électrique ou d’eau potable. Dans ce cas, elle doit en déterminer
le cahier de charge qui devra obligatoirement être validé par le ministère de tutelle ;
par la même occasion, elle joue un rôle consultatif auprès du Gouvernement dans le
domaine de la création, de la mise en exploitation, de la reconversion ou de la
suppression des unités de production de l’énergie ou de l’eau potable sur l’ensemble
du territoire ;
 Racheter et distribuer de l’énergie produite par les opérateurs ou productions privé,
après approbation du Ministère de l’Énergie et des Ressources Hydrauliques ;
 Exploiter l’ensemble des unités de production, des lignes de transport, des réseaux de
distribution d’électricité et d’eau construits par l’Etat ;
 Exploiter des installations et équipements d’assainissement et de traitement des eaux
usées mis en place par l’Etat ;
 Acheter et redistribuer de l’énergie électrique produite par les opérateurs privés ;
 Gérer le Patrimoine du secteur de l’eau et de l’électricité (renouvellement,
développement, gestion technique, administrative et comptable).
1.2 Organisation de la SP
La Société de Patrimoine fonctionne selon le mode d'organisation hiérarchique. Autrement

dit, seule la Direction générale détient l'autorité et la délègue aux autres directions. Ainsi,
toutes les décisions engageant la Société de Patrimoine sont prises par le Directeur Général.
Les autres directions n'agissent que sur ses instructions.
La Société de Patrimoine regroupe une centaine d'agents qui sont répartis dans plusieurs
directions, toutes sous la responsabilité du Directeur Général. Chaque direction est gérée par
un directeur. On distingue les directions communes à toutes les sociétés et les directions
propres au secteur de l'eau et de l'énergie que sont :
 La Direction des Ressources Humaines (DRH)
 Élaboration et mise en œuvre de la politique de gestion prévisionnelle des emplois et

de des compétences ;
 Gestion du personnel ;
 Mise en œuvre de la politique de l'entreprise ;
 Origination et développement du dialogue social ;
8
 Gestion des activités relatives à la paie.
 La Direction Administrative et Financière (DAF)
 Tenue des comptes de l'entreprise ;

 Gestion financière des ressources de l'entreprise ;
 Recherche des financements ;
 Gestion de la relation avec les fournisseurs ;
 Gestion de la dette et des risques financiers.
 La Direction Commercial (DCO)
 Gestion des contrats d'achats/vente d'énergie ;

 Facturation des clients ;
 Recouvrement des factures ;
 Gestion de la dette et des risques ;
 Marketing et développement des ventes.
 La Direction du Patrimoine et Moyens (DPM)
 Contrôle de l'exploitation affermée (maintenance des installations, qualité de l'eau

distribuée, qualité de l'énergie distribuée) ;
 Centralisation et analyse des statistiques d'exploitation du secteur (SP et opérateur
privé) ;
 Gestion des biens mobiliers et immobiliers de l'entreprise ;
 Etudes et planification (schémas directeurs, programmes travaux pluriannuels etc.…)
se rapportant aux renforcements, extensions, renouvellements et créations d'ouvrages ;
 Maître d'œuvre (suivi et contrôle des travaux).
 La Direction des Systèmes de l'Information (DSI)
 Support informatique des projets de l'entreprise ;

 Support technique aux utilisateurs ;
 Sécurité des systèmes d'information et du matériel informatique ;
 Veille à la santé informatique et à la sécurité des données de l'entreprise.
 La Direction des Affaires Juridiques (DAJ)
 Élaboration, rédaction et négociation des contrats privés passés par la société ;

 Négociation des conditions et des primes des polices d'assurance souscrites par la
société ;
9
 Préparation des conseils d'administration et suivi des formalités légales en matière ;

 Gestion du contentieux général de la société ;
 Suivi et mise à jour du patrimoine foncier de la société.
 La Direction du Budget et du Contrôle de Gestion (DBCG)
 Conception et suivi de l'exécution du budget de l'entreprise ;

 Rationalisation et maîtrise du processus de prévision des produits de charges.
 La Direction de l'Exploitation (DEX)
 Conduite des ouvrages et réseaux ;

 Gestion et maintenance des ouvrages ;
 Pilotage des projets d'étude dans le secteur de l’électricité ;
 Mouvements d'énergie et gestion des flux hydriques ;
 Hygiène Sécurité environnement.
 La Direction de l'Eau et Assainissement (DEA)
 Couverture des domaines de la cartographie, de l'assainissement, de la production, de

la gestion des réseaux et de la distribution d'eau portable.
Nous avons été reçus à la Direction des Système d’Information. Ce département est constitué
de trois services à savoir : Service Helpdesk, Service application et le Service Infrastructures,
Réseaux et Sécurité. Nous avons été affectés au service Infrastructures, Réseaux et Sécurité
au poste de chargé Infrastructures, Système et Sécurité.
Directeur des Systèmes

d'Information
DSI
Chef de service Chef de service

Chef de Service
Infrastructure, Etude et Projet
Helpdesk
Réseau et sécurité Informatiques
CSIRS CSEPI CSH
Chargé Chargé
Techniciens Techniciens
Infrastructure Infrastructure Chargé Applications
Helpdesk Helpdesk
Sytème et Sécurité réseau
CISS CIR CA TH TH
Figure 1: Organigramme de la DSI
10
2. Analyse de l’existant et Problématique
Cette partie donne non seulement un descriptif général sur le projet à mettre en œuvre, mais
aussi couvre l'ensemble des spécifications de l'infrastructure Système Informatique et
technologique de la structure d’accueil. Elle contient tous les détails sur cette infrastructure
système.
2.1 Architecture de l’infrastructure système existante
Figure 2 : Architecture Système de la SP
11
L’architecture système de la Société de Patrimoine était composée de quatre serveurs

physiques à savoir :
 SVR-AD ;
 SVR-SAGE-COMPTA ;
 SVR-SAGE-PAIE ;
 Contrôleur AP & WDS.
Pour la messagerie, nous utilisons le service Microsoft 365 Business Premium online. Le
tableau ci-dessous présente plus en détails la constitution de tous les serveurs de la SP :
Système
Nom du Serveur Type Caractéristiques Services Installés
d’exploitation
ProLiant ML10 Gen9 3,30
Serveur GHZ, 16GO ram, Intel
SVR-PAIE Serveur Sage Paie Windows 2012
physique Xeon® CPU-E3-1225 V5,
Socket (1), Port (1)
Serveur GHZ, 16GO Ram, Intel Serveur Sage de
SVR-COMPTA Windows 2012
physique Xeon® CPU-E3-1225 V5, Comptabilité

Serveur GHZ, 16GO Ram, Intel WDS, Contrôleur des
SVR-WDS Windows 2012
physique Xeon® CPU-E3-1225 V5, AP UBUQUITI
Exchange Online,
Microsoft 365 Azure AD, OneDrive,
Service
Business Service Microsoft cloud Outlook, SharePoint, Microsoft 365
cloud
Premium Teams, Word, Excel,
PowerPoint…

Serveur GHZ, 16GO Ram, Intel
SVR-AD ADDS, DNS Windows 2008
physique Xeon® CPU-E3-1225 V5,
Tableau 1: Détails des serveurs de la SP
12
2.2 Problématique
L’architecture système de la Société de Patrimoine du Service Public de l'eau Potable, de

l'Energie Electrique et de l’assainissement (SP) était très simple dans la mesure où il disposait
d’un déficit de services de base pour une Infrastructure système. Il était constitué de quatre
serveurs physiques. Cette infrastructure système était assez limitée pour les raisons suivantes :
 Le serveur actives directory était configuré sous un système d’exploitation Windows

serveur 2008, totalement obsolète. Cette version du système d’exploitation n’est plus
prise en charge par Microsoft ;
 Inexistence d’un serveur d’antivirus : nous étions contraints d’acheter des CD/DVD de
licences d’antivirus individuels pour chaque poste utilisateur. Cela nous a coûté
extrêmement cher comparativement à la centralisation d’une solution d’antivirus ;
 Absence de serveurs de fichier : les utilisateurs n’avaient pas un espace de partage de
fichier centralisé ;
 Manque de serveur de sauvegarde : en cas de crash d’un de nos serveurs, nous étions
incapables de le restaurer, les sauvegardes étaient effectuées sur des disques durs
externes ;
 Architecture système non agile : chaque fois que nous avons besoin d’un service ou
d’une nouvelle application, il fallait prévoir l’acquisition d’un nouveau serveur. Cette
non-agilité accroissait les coûts du système ;
 À toutes ces limites, nous pouvons ajouter que dans notre salle serveur nous
disposions d’un SAN HP StorageWorks P2000 G3 FC/ISCSI (deux HP StorageWorks
8/8 SAN Switch, 2 serveurs ProLiant DL380P G9 et une baie de stockage HP P2000)
qui avait était acheté deux ans auparavant. Mais malheureusement elle n’a jamais été
configuré et mis en service faute de ressources humaines compétentes pour le faire.
Face à ces problèmes cités ci-dessus, La problématique est par conséquent la suivante :
Comment la virtualisation de serveur peut-elle réformer et améliorer l’infrastructure
serveurs de la Société de Patrimoine ?
Nous tenterons d’apporter une réponse précise et concise à cette problématique dans les
chapitres suivants.
13
Chapitre 2 : Généralités sur

les concepts de
Virtualisation de serveurs
MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com 12

Dans le premier chapitre, nous avons présenté la structure d'accueil, ce qui nous a
permis de définir le contexte de notre stage. Dans ce chapitre, nous débuterons par une
présentation générale de la virtualisation, ensuite, nous aborderons les types de virtualisation.
Puis nous examinerons les avantages de la virtualisation et terminerons par les techniques de
redondance.
2.1 Présentation générale de la virtualisation
En informatique, la virtualisation consiste à créer une version virtuelle d'un

périphérique ou d'une ressource, telle qu'un système d'exploitation, un serveur, un
périphérique de stockage ou une ressource réseau. Par conséquent, nous pouvons considérer la
virtualisation comme l'abstraction physique des ressources informatiques. En d'autres termes,
les ressources physiques allouées à une machine virtuelle sont abstraites de leurs ressources
physiques équivalentes.
Chaque périphérique virtuel, qu'il s'agisse d'un disque, d'une interface réseau, d'un
LAN, d'un commutateur, d'un processeur ou d'une RAM, correspond à une ressource
physique sur le système informatique physique. De ce fait, les machines virtuelles hébergées
par le serveur sont considérées par l'ordinateur hôte comme des applications nécessaires pour
dédier ou répartir ses ressources. Il existe de nombreux domaines d’application à la
virtualisation, et il s’agit généralement de la virtualisation de serveur, de poste de travail,
d’application, de stockage et du réseau.
Lorsque nous évoquons la virtualisation, nous faisons généralement référence à la

virtualisation des serveurs, et ce, pour des raisons historiques. Il s’agit en effet du premier
domaine d’application touché par cette technologie. La virtualisation des serveurs consiste à
allouer, à l’aide d’un logiciel de virtualisation(hyperviseur), une partie du matériel composant
un serveur à chacune des machines virtuelles que nous souhaitons y voir hébergées
simultanément. Chaque machine virtuelle est un environnement virtuel cohérent piloté par un
système d’exploitation et fonctionnant indépendamment des autres machines.

L’ordinateur hôte dispose bien évidemment de ressources matérielles suffisantes pour

garantir à ses invités une puissance de calcul optimale et un espace disque adéquat. Un
système hôte se compose généralement de plusieurs processeurs multicœurs, de plusieurs
giga-octets (Go) de RAM (Random Access Memory), de plusieurs téraoctets (To) d’espace
disque ou d’un accès à un stockage en réseau (NAS), voire à un réseau de stockage (SAN). La
virtualisation s'appuie sur un système que l'on appelle un hyperviseur. Il est important de
noter qu'il existe deux types d'hyperviseurs : les hyperviseurs de type 1 et les hyperviseurs de
type 2. Nous expliquerons ces concepts plus en détail ci-dessous.
2.2 Différents types d’hyperviseur

2.2.1 Hyperviseur de type 1
Un hyperviseur de type 1 est un système qui s’installe directement sur la couche

matérielle du serveur : on parle d'hyperviseur natif. 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. Cela permet de libérer autant de ressources que
possibles pour les machines virtuelles. Lorsqu'un hyperviseur de type 1 est installé sur une
machine, celle-ci ne peut pas servir à autre chose qu'à faire tourner l'hyperviseur, elle est
dédiée à cet usage. Il faut considérer que l'hyperviseur devient le système d'exploitation de la
machine.
En fait, les ressources matérielles de la machine, que ce soit un ordinateur ou un serveur, sont
gérées directement par l'hyperviseur lui-même.
Parmi les hyperviseurs de type 1 figurent des solutions proposées par de grands
éditeurs dont : Hyper-V de Microsoft, ESXi de VMware, Proxmox VE qui se base
sur Linux KVM et qui est open source, ou encore Citrix avec Citrix XenServer. VMware est
le leader sur le marché avec sa solution VMware ESXi, intégrée notamment dans sa suite
vSphere.
Il est à noter que Hyper-V est un cas particulier, car il s'installe en tant que rôle sur une
machine Windows (à l'exception d'Hyper-V Server) : il donne l'impression d'être un
hyperviseur de type 2, mais ce n'est pas le cas. Il est intégré à Windows de manière à accéder

directement au matériel et Windows est en quelque sorte modifié pour être un niveau au-
dessus de l'instance Hyper-V.
Les hyperviseurs de type 1 sont ceux que l'on déploie en entreprise lorsque l'on souhaite
monter une infrastructure basée sur la virtualisation.
Figure 3: Hyperviseur de type 1
2.2.2 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. On parle d'hyperviseur hébergé. C’est le cas d’une machine sous
Windows 10 sur laquelle sera installé un hyperviseur (comme n'importe quel autre logiciel)
dans le but de créer des machines virtuelles.
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. Naturellement, moins de ressources
sont disponibles pour les machines virtuelles et les performances sont moindres, car il faut
passer par l'OS principal. L'avantage est qu'il est possible d'exécuter plusieurs hyperviseurs
simultanément, car ils ne sont pas liés à la couche matérielle. Néanmoins, dans certains cas, ce
n'est pas si simple, il peut y avoir des conflits. Le véritable avantage réside cependant dans le
fait que l'on peut non seulement utiliser sa machine pour ses tâches habituelles, mais aussi

l'utiliser comme hyperviseur en cas de besoin, par exemple pour mettre en place une VM pour
quelques tests.
Les hyperviseurs de type 2 incluent les solutions suivantes : Oracle VirtualBox, gratuit à
installer sur Windows et Linux, VMware Workstation (payant) et sa version gratuite,
VMware Workstation Player. Sur MacOs, l’on peut installer VMware Fusion.
Évidemment, ces hyperviseurs de type 2 sont idéaux pour tester sur une machine existante,
tout comme Hyper-V peut l'être sur Windows 10. L’hyperviseur de type 2 n'est pas destiné à
la production.
VM VM VM VM
Autres
Applications
Hyperviseur Hyperviseur
Type 2 Type 2
OS
Ressources Matérielles
Figure 4 : Hyperviseur type 2
2.3 Domaine d’application de la virtualisation

Nous distinguons principalement quatre types de virtualisation dont la virtualisation de
serveurs, d’application, de postes de travails ainsi que la virtualisation de stockage. Nous
détaillerons ces points plus loin.
2.3.1 La virtualisation de serveurs

La virtualisation de serveurs consiste à consolider plusieurs serveurs virtuels (qu’il s’agisse
des serveurs de messagerie, des serveurs d'applications, des serveurs de fichiers, d’Active
Directory, etc.), généralement dédiés, sur un même serveur physique, de sorte que le serveur
suivant fasse office d'hyperviseur. Les principes fondamentaux de cette technologie résident
dans l'abstraction du matériel sous-jacent en le rendant virtuel, de manière qu'un système

d'exploitation puisse y être installé. Par conséquent, la virtualisation d'un serveur ou d'un
poste de travail réel est la même. Les principales solutions de virtualisation de serveurs sont :
o VMware vSphere (Leader Mondial);

o Microsoft Hyper-V ;
o KVM de Red Hat Enterprise Virtualization.
2.3.2 La virtualisation d’application

La virtualisation des applications consiste à créer un environnement virtuel spécifique
à l'application qui inclut ses propres clés de registre dans son propre registre, son propre
système de fichiers ou même des bibliothèques tierces ou des Frameworks. Ainsi,
l'application virtuelle fonctionne dans une "bulle" qui la sépare du système d'exploitation et
des autres applications en cours d'exécution.
Les clés de registre et le système de fichiers ne constituent en rien des copies de ceux
du système d’exploitation sur lequel l’application est exécutée. Ils contiennent simplement les
modifications effectuées par l’application pour pouvoir fonctionner. L’application n’aura
donc accès qu’à ses propres versions de fichiers de configuration système. Sur le même
principe, elle ne pourra agir que sur sa propre base de registre. Aucun conflit avec d’autres
applications n’est donc à craindre. D’où le concept de bulle applicative étanche.
Figure 5 : Virtualisation d'application

2.3.3 La virtualisation de stations de travail
La virtualisation des postes de travail est l’évolution logique de la virtualisation des

serveurs. Le poste de travail se résume à une machine virtuelle disponible sur un serveur
localisé au sein du centre de données. Les utilisateurs se connectent simplement à cette
machine virtuelle, généralement via des terminaux légers.
Ce type de virtualisation répond à un certain nombre de défis auxquels doivent répondre

les services informatiques :
 Les employés mobiles ont besoin d’un accès complet aux ressources informatiques
(applications ou données), quel que soit le lieu où ils se trouvent ;
 Le nombre de périphériques à gérer explose ; il existe, en outre, une variété toujours
plus importante de dispositifs. Nous sommes par exemple confrontés à un nombre
croissant de demandes provenant des employés, relatives à une connexion de tablettes
au réseau local de l’entreprise ;
 Les tâches en relation avec la gestion des ordinateurs de bureau doivent être simplifiées
et rationalisées, afin d’éviter que les administrateurs soient systématiquement détournés
des tâches stratégiques, d’autant plus que les besoins des utilisateurs se diversifient.
Les coûts relatifs à certaines tâches clés, comme la configuration des stations de travail
ou le déploiement de mise à jour, de correctifs ou de mise à niveau, doivent être réduits
;
 Les employés attendent de leur employeur qu’il favorise l’usage de dispositifs
personnels, tels que les smartphones, les laptops ou les tablettes. Cette tendance, de
plus en plus fréquente au sein des sociétés, est qualifiée de « consumérisation » ;
 L’accroissement de la mobilité des employés, l’explosion du nombre de périphériques
et la « consumérisation » augmentent les risques liés à la sécurité.
2.3.4 La virtualisation de stockage
La virtualisation du stockage consiste à fédérer plusieurs ressources de stockage

indépendantes et éventuellement hétérogènes en une ressource centralisée. Des volumes ou
disques de stockage virtuels logiques sont créés à partir de ces différentes ressources et

présentés par la suite aux serveurs concernés. Ainsi, qu'une entreprise ait acheté des NAS, des
baies de stockage iSCSI et/ou des baies de stockage en fibre optique, que ces appareils soient
équipés de disques SATA, SAS ou SSD ou qu'ils aient été produits par différents fabricants,
l'entreprise peut centraliser tout l'espace de stockage disponible et le gérer à partir d'un seul
outil.
Lorsque l’acquisition de matériel de stockage supplémentaire s’avérera nécessaire, la

société n’aura pas à se soucier de la marque ou de la technologie de ce dernier puisque cette
nouvelle ressource sera virtualisée. L’ajout d’éléments de stockage se fait au sein de l’espace
logique, en toute transparence, rendant ce type de solution extrêmement évolutive. Nous
pouvons partir du principe que la capacité de stockage ne dépend plus de la capacité physique
d’un dispositif mais uniquement des contraintes budgétaires. Un espace de stockage très
important peut ainsi être mis à la disposition d’un serveur à partir de plusieurs baies
originellement isolées, ce qui n’aurait pas été possible si elles étaient demeurées séparées.
Un environnement récent peut également être pérennisé par ce biais (dans le cas, par
exemple, d’une fusion de sociétés ayant donné lieu à l’existence au sein de la nouvelle
structure de baies de stockage hétérogènes issues des anciennes entreprises). Enfin,
l’administration du stockage peut être réalisée à partir d’une seule et unique console.
Figure 6 : Virtualisation des stockages

L’appliance de virtualisation du stockage doit être correctement dimensionnée, la

totalité des requêtes transite par cette dernière. Dans le cas contraire, les accès au stockage
pourraient être peu performants, voire peu fiables. Une quantité importante de cache peut lui
être octroyée pour pallier ce genre de problème. Nous précisons que le débit proposé par les
liens Ethernet ou FC doit également être suffisamment performant, faute de quoi le cache se
trouvera rapidement saturé.
2.4 Avantages de la virtualisation
2.4.1 Réduction des coûts CAPEX/OPEX

Les systèmes d'information, ou plus précisément l'infrastructure associée, sont essentiels
au bon fonctionnement d'une entreprise, mais sont souvent perçus par les dirigeants comme
des centres de coûts. Ces exigences imposent aux responsables informatiques de garantir un
certain niveau de service malgré des exigences sans cesse croissantes. Les budgets, en
revanche, devraient rester les mêmes, voire être réduits. Cependant, au sein de l'infrastructure
physique, l'utilisation moyenne des serveurs au sein d'un centre de données est estimée à
moins de 10 % dans 80 % d'entre eux. Les centres de données eux-mêmes atteignent leur
capacité maximale en termes d'espace requis, d'alimentation et de refroidissement. La raison
fondamentale de ce gaspillage réside dans le fait que les entreprises ont investi massivement
dans des serveurs conçus chacun pour héberger une seule application ou un seul service. Cette
prolifération de serveurs physiques entraînera des augmentations importantes, voire
astronomiques, des coûts d'exploitation. On estime également que les administrateurs système
consacrent 70 % de leur temps à des tâches de support ou de maintenance, qui n’ajoutent
pourtant aucune valeur à l'entreprise.
Les coûts indirects tels que l'administration et la consommation d'énergie sont bien plus
élevés que l'achat du serveur lui-même et peuvent représenter jusqu'à trois fois le coût
d'acquisition de l'infrastructure matérielle. Les entreprises perdent beaucoup d'argent en raison
du coût élevé de la maintenance de leur infrastructure. Elle crée des inefficacités
opérationnelles qui entravent l'innovation et la gestion de nouveaux projets indispensables au
développement de l'entreprise. Dans ce contexte, la virtualisation permet aux responsables
informatiques de s'engager à moderniser les systèmes d'information de leur entreprise tout en

réduisant les coûts et en répondant aux exigences susmentionnées. Les entreprises distinguent
en principe deux types de coûts :
 CAPEX (Capital Expenditures), qui sont des dépenses liées aux investissements et
immobilisations (i.e. matériel divers, logiciels, etc.) ;
 OPEX (Operational Expenditures), lorsqu’il s’agit des dépenses liées au
fonctionnement de la société (i.e. expertise, prestation, conseil, gestion de projets,
etc.).
La virtualisation est certainement un moyen de réduire les coûts CAPEX/OPEX. Voici

comment la virtualisation réduit les coûts CAPEX/OPEX. Les points énumérés ci-dessous ne
sont pas exhaustifs, mais documentent les points les plus importants.
 Diminution du nombre de serveurs

Avant tout, la virtualisation élimine le besoin d'acheter du matériel chaque fois qu'un
nouveau système doit être déployé. Cette déclaration est facilement observable
lorsqu'il s'agit de configurer de nouveaux serveurs. En effet, l’on peut créer un certain
nombre de machines virtuelles par serveur. Les proportions relatives de consolidation
dépendront des ressources qu'il faudra effectivement allouer à chaque machine
concernée. Ainsi, la réduction du nombre de machines dans l'infrastructure rendue
possible par la virtualisation est une source d'économies importantes.
 Diminution du matériel réseau

La virtualisation limite également l'achat de composants réseau car les machines
virtuelles peuvent communiquer au sein du même hôte physique sans avoir besoin de
périphériques tels que des routeurs et des commutateurs. De plus, les machines
virtuelles peuvent être configurées pour coexister sur la même carte réseau ou être
regroupées au sein de groupes d'interfaces réseau. Cela permet de réduire le nombre de
composants réseau.
 Réduction de la consommation électrique

Si la virtualisation permet de réduire le nombre de machines présentes dans
l'infrastructure, elle permet également de réduire significativement la consommation
d'énergie électrique. C'est probablement l'économie la plus notable. Il a été prouvé que

quelques serveurs physiques consomment plus d'énergie qu'un seul serveur renforcé
(hyperviseur).
La virtualisation réduit efficacement le nombre d'alimentations, de processeurs et de
disques durs. Cependant, ces éléments génèrent et dissipent de grandes quantités de
chaleur. Il convient de garder à l'esprit que la consommation d'énergie est étroitement
liée au refroidissement et au débit d'air. La réduction du nombre des éléments ci-
dessus réduira en conséquence l'énergie dépensée pour le refroidissement de
l'installation.
La flexibilité offerte par la virtualisation du stockage permet d'ajuster les besoins en
capacité de stockage en fonction du nombre de baies dont on a besoin. La réduction du
nombre d'emplacements réduit également la consommation d'énergie. A l'heure où les
considérations environnementales sont aussi une priorité, ces économies d'énergie
s'avèrent être un argument supplémentaire pour défendre le budget alloué à la gestion
des systèmes d'information.
 Diminution de la consommation d’espace

Les centres de données ne sont pas évolutifs à l'infini et leur maintenance nécessite
une somme d'argent importante. Les entreprises doivent distinguer les facilités
allouées aux salariés et les facilités fournies à l'informatique, les premières au
détriment des secondes. La virtualisation, en réduisant le nombre de machines, de
serveurs et de baies de stockage, favorise ainsi une réduction significative de l’espace
qui serait normalement réservé aux serveurs. Cependant, il faut noter que la
virtualisation augmente l’importance du serveur, dans le sens où le serveur sera
centralisé au même endroit, avec pour conséquence le risque de tout perdre lors d’un
crash majeur.
 Optimisation de la restauration
La virtualisation réduit le temps de récupération dans la réalité. Par temps de
récupération, nous entendons le temps moyen nécessaire pour s’assurer qu’un système
indisponible en raison d’une panne quelconque peut être réutilisé par l’utilisateur. Il
est souvent fait référence à la notion de RTO (Recovery Time Target). La
virtualisation réduit considérablement ce temps en fournissant aux administrateurs
système des sauvegardes instantanées ou des machines virtuelles entières. En effet, la

restauration avec une copie en direct du système s'avère beaucoup plus rapide que
l'installation d'un nouveau système. Par ailleurs, cela obligera l'administrateur système
à fouiller dans une masse de sauvegardes croissantes pour restaurer le système en
fonctionnement normal.
Cette technologie est particulièrement efficace tant que les données utilisées par
la solution existant sur le serveur ne sont pas stockées sur le même disque logique que
l'environnement restauré, sous peine de perdre ultérieurement les données de mise à
jour (surtout si la sauvegarde de la VM en question date de plusieurs jours). Il est donc
nécessaire de doter le serveur virtuel d'un emplacement logique supplémentaire sur le
SAN qui contiendra les données et pourra être utilisé sans problème par la machine
récupérée, une fois celle-ci opérationnelle.
Il convient également de préciser qu'une machine virtuelle peut être considérée
comme très fiable car elle ne repose sur aucun matériel physique susceptible de
tomber en panne. Par conséquent, une sauvegarde de machine virtuelle sera toujours
un point de restauration stable et fiable pour le matériel physique sous-jacent. Certains
produits, tels que VMware et Hyper-V, permettent de convertir une machine physique
en machine virtuelle. Cette méthode, communément appelée sauvegarde P2V
(physique vers virtuelle), permet aux administrateurs système de mettre en production
des machines virtuelles pour remplacer rapidement et de manière fiable les serveurs
physiques défaillants p une fraction des coûts négligeables, et réduit considérablement
les interruptions de service.
 Optimisation de la sauvegarde
Les professionnels traitent souvent les sauvegardes comme un projet complexe,
fortement dépendant du système d'exploitation présent sur la machine, du composant
matériel, de l'application hébergée et de l'outil de sauvegarde choisi. Les projets de
protection sont de gros utilisateurs de ressources financières et sont difficiles à justifier
auprès des décideurs.
Une machine virtuelle étant traitée comme un simple fichier par l'hyperviseur, sa
sauvegarde ne traitera également qu'un seul fichier. Par conséquent, toutes les licences
supplémentaires, les restrictions système ou les mises à jour des revendeurs
deviennent nulles. Pour sauvegarder des Vms sans logiciel de sauvegarde sophistiqué,
il suffit de copier/coller les fichiers de la VM et de les stocker sur un support externe.

2.4.2 Simplification du déploiement et de l’administration
Lorsque de nouveaux serveurs ou de nouvelles applications doivent être déployés dans

des moyennes ou grandes structures, les différents acteurs impliqués contribuent souvent (pas
forcément par envie) à ralentir le processus d'intégration. En effet, les priorités de l'un
correspondent très rarement à celles de l'autre. Les utilisateurs sont impatients de pouvoir
utiliser le logiciel dont ils ont besoin dès que possible. Les chefs de projet sont obligés de
passer par des spécialistes système et réseau pour l'intégration.
La virtualisation rend ce processus beaucoup plus facile. Tout d'abord, il n'est pas
nécessaire d'acheter du matériel supplémentaire car il suffit de créer une nouvelle machine
virtuelle. Ensuite, cette méthode peut être effectuée rapidement et automatiquement. Si
plusieurs machines virtuelles sont nécessaires, il faut en créer une, puis la cloner autant de fois
que l’on souhaite. De plus, l'espace disque alloué à tout nouveau serveur peut facilement être
provisionné à partir du SAN, grâce à la virtualisation du stockage. Les disques virtuels (donc
logique) peuvent être créés en quelques clics depuis n'importe quel LUN du pool de stockage.
En conséquence, l'intégration peut se résumer en quelques heures au lieu de semaines ou
même de mois comme auparavant.
Parti administratif, en général, les produits disponibles sur le marché de la virtualisation

disposent d'une console de gestion des machines virtuelles accessible depuis une interface
unique. Cette interface de gestion centralisée prend tout son sens lorsqu'il s'agit de supporter
une infrastructure composée de systèmes d'exploitation hétérogènes. L'interface en question
nous permet d'interagir avec le panneau de contrôle de ce dernier comme si nous étions
devant le système physique.
En outre, certains outils de surveillance sont disponibles, permettant aux administrateurs

système de surveiller en temps réel la consommation ou les performances des différentes
machines virtuelles ou la quantité d'espace de stockage disponible.
2.4.3 Gestion optimisée de l’obsolescence du matériel

La constante évolution technique du matériel et des applications que nous connaissons

dans le domaine des systèmes d’information, nous oblige, en tant qu’administrateur systèmes,
à veiller constamment à la mise à jour de notre infrastructure. Nous estimons l’espérance de
vie d’une infrastructure matérielle à trois, voire cinq ans au maximum. La garantie offerte par
le constructeur sur le produit en question est généralement d’une telle durée, ce qui ne trompe
pas sur les délais précités. Une application, quant à elle, peut avoir été développée pour
fonctionner sur une plateforme plus récente que celle disponible sur le serveur sensé
l’héberger.
A contrario, ce dernier doit éventuellement être doté d’un système d’exploitation

correspondant aux standards en vigueur plusieurs années auparavant, pour que l’application
puisse y fonctionner. La migration d’une telle application sur un environnement virtuel
adéquat permet de résoudre de telles problématiques. Bien que le système d’exploitation en
question ne soit plus supporté par son éditeur, l’application peut continuer à y fonctionner.
Les problèmes de mises à jour de l’environnement ou de support de ce dernier par l’éditeur ne
sont pas résolus mais l’entreprise peut ainsi donner un sursis à l’application concernée et
éviter d’avoir à se précipiter dans de nouveaux développements d’applications ou dans l’achat
de ces dernières, ce qui lui permet d'économiser une fortune.
De plus, la virtualisation des applications elles-mêmes permet de faire fonctionner ces

dernières dans des « bulles » applicatives qui ne dépendent plus du système d’exploitation
sous-jacent, offrant les mêmes bénéfices que décrits au paragraphe précédent, et ce, malgré le
fait que le système d’exploitation ait été mis à jour. La virtualisation des serveurs permet de
gérer au mieux la problématique de l’espérance de vie du matériel puisque si le système hôte
devient obsolète, ce ne sera pas le cas des machines virtuelles. Nous pourrons ajouter de la
RAM, des processeurs, de l’espace disque, des interfaces réseau ou tout autre périphérique à
ces dernières indépendamment du matériel physique sous-jacent. Leur système d’exploitation
pourra même être mis à jour une fois que le matériel physique qui les héberge l’aura
également été. De plus, remplacer un serveur obsolète par du nouveau matériel peut se faire
de manière tout à fait transparente pour les clients dudit serveur. Les machines virtuelles
clientes sont simplement migrées sur un nouveau système physique, et ce, en court de
production (Live migration).

2.4.4 Simplification des tests logiciel
L'utilisation de machines virtuelles pour effectuer des tests de logiciels a été l'une des
premières raisons pour lesquelles la virtualisation de l'environnement x86 a été mise en
œuvre. Une fois la copie de travail créée (création de la machine virtuelle, démarrage,
application des patchs, attribution des noms et des adresses IP), une copie de sauvegarde de la
copie est créée (snapshot). Cette copie de travail est ensuite utilisée pour installer, modifier ou
supprimer des packages logiciels.
Cette méthode permet ainsi d’éviter tout conflit ou problème potentiel (plantage, écrans
bleus, vidages de mémoire, etc.) qui pourraient survenir au moment de la mise en production
desdits logiciels. Si certains de ces problèmes venaient à apparaître, la copie de travail
pourrait servir de plateforme de débogage. Si cette dernière venait à être irrémédiablement
corrompue, il suffirait de la supprimer et d’en créer une nouvelle à partir de la machine
originale.
Cette approche évite ainsi tout conflit ou problème potentiel (crash, écran bleu, vidage
mémoire, etc.). Si certains de ces problèmes apparaissent, la copie de travail peut servir de
plateforme de débogage. Si ce dernier est endommagé de manière irréparable, il convient
simplement de le supprimer et d’en créer un nouveau à partir de la machine d'origine.
2.5 Techniques de Redondance dans la virtualisation

2.5.1 Présentation du cluster de basculement
Un cluster de basculement est un groupe d'ordinateurs indépendants qui travaillent ensemble

pour augmenter la disponibilité et l'évolutivité des rôles dans le cluster. Les serveurs en
cluster (appelés « nœuds ») sont connectés par des câbles physiques et par des logiciels. Si un
ou plusieurs nœuds tombent en panne, les autres nœuds prennent le relais pour fournir les
services nécessaires (ce processus est appelé "basculement"). De plus, les rôles de groupe sont
activement surveillés pour vérifier qu'ils fonctionnent correctement. S'ils ne fonctionnent pas,
ils seront redémarrés ou déplacés vers un autre nœud.

Les clusters de basculement fournissent également une fonctionnalité de volume partagé de

cluster (CSV) qui fournit un espace de noms cohérent et distribué que les rôles de cluster
peuvent utiliser pour accéder à la mémoire partagée à partir de tous les boutons. Par
conséquent, le clustering de basculement garantit aux utilisateurs une interruption de service
minimale.
2.5.2 Architecture d’un cluster de basculement Hyper-V
Figure 7 : Architecture d'un cluster de basculement
Nous détaillerons tous les éléments constitutifs d’un cluster de basculement dans le point ci-
dessous.
2.5.3 Descriptif de l’architecture d’un cluster de basculement

Un cluster de basculement est constitué des nœuds de serveur, de stockages partagés

(Stockage de donnée et Quorum), des Switch SAN, de différents réseaux tels que : le réseau
de production, le réseau SAN et le Heartbeat.
 Nœuds : les nœuds sont les serveurs faisant partie du cluster, ils ont accès à toutes les
données de configuration en cluster. Chaque nœud communique avec les autres nœuds
du cluster par l'intermédiaire d'un ou de plusieurs réseaux (Hearbeat) physiquement
indépendants. Tous les nœuds du cluster sont groupés sous le nom de cluster, qui est
utilisé pour l'accès et la gestion du cluster.
 Stockage partagé : Pour que les nœuds fonctionnent, il est primordial que les données
soit sauvegardées sur un stockage partagé. Il est possible d’utiliser soit un SAN
(Storage Area Network) ou un NAS (Network Attached Storage). Dans un cluster de
basculement, il est fortement recommandé d’utiliser les SAN fibre optique, car ils
présentent plusieurs avantages tels que : haute performance en lecture et écriture sur la
baie de stockage, évaluation illimitée, snapshot et réplication inter SAN. Dans ce
stockage, nous distinguons deux types de volumes : le quorum et volume de donnée.
 Switch SAN : Si l’on choisit d’utiliser un SAN comme stockage partagé, nous aurons
besoin de switches SAN. Ils permettent d’assurer des connexions réseaux redondantes
en lecture/écriture sur les baies de stockage. À l’aide de la technologie MPIO
(Multipath I/O) installée sur les nœuds du cluster, un équilibre de charge et une
tolérance de panne dynamique sont garantis.
 Réseau de production : C’est le réseau local de l’entreprise. Pour communiquer avec

les autres machines du domaine sur le réseau local, notre cluster aura un nom unique
et une adresse IP.
 Réseau Hearbeat : C’est une liaison privée entre les nœuds. Il envoie un signal
régulier (HeartBeat – Battement de cœur) auquel répond chaque nœud du cluster de
basculement. Il permet également de détecter la défaillance d’un nœud dans le cluster.

Les nœuds transmettent et reçoivent des pulsations à l’aide de la monodiffusion du

protocole UDP (port 3343).
Chapitre 3 : Virtualisation
de serveurs : cas de la SP


Après un tour d'horizon des concepts liés à la virtualisation des serveurs, nous aborderons
dans ce chapitre la phase de conception et de réalisation de l'architecture de virtualisation.
Cette section se concentrera sur la présentation de l'architecture du matériel utilisé lors de la
transition vers la nouvelle infrastructure système, son déploiement et sa configuration.
3.1 Design de l’architecture de la solution de virtualisation
Pour réaliser le design de la solution cible, nous avons effectué l’inventaire des serveurs pour
déterminer les serveurs physiques à virtualiser et les serveurs virtuels à ajouter. Notre objectif
n’étant pas de virtualiser tous les serveurs de la SP, nous avons dû choisir quels serveurs
étaient des candidats éligibles à la virtualisation.
Notre solution consiste à mettre en place une solution de virtualisation hyper redondante.
Nous utiliserons la fonctionnalité de cluster de basculement Hyper-V de Microsoft qui va
permettre la mise en haute disponibilité des serveurs virtuels.
Tout d’abord, nous mettrons en service un SAN fibre optique pour le stockage des machines
virtuelles. Ensuite, nous installerons les rôles Hyper-V sur nos deux nouds (HV1 et HV2) de
serveurs. Par la suite, nous finaliserons la configuration du cluster de basculement. Sur ce
dernier, nous installerons plusieurs machines virtuelles ou convertirons des serveurs
physiques en machines virtuelles. Nous installerons notamment :
 Serveur d’antivirus (Kaspersky) ;

 Serveur de fichiers ;
 Serveur Azure ADConnect (synchronisation des annuaires active directory local vers
Azure AD) ;
 SVR-WDS (conversation machine physique en Vms).
Mais avant d’effectuer toutes ces étapes, nous résoudrons d’abord la problématique du serveur
active directory qui fonctionne sous Windows serveur 2008. Nous le migrerons vers Windows
2016. Pour le faire, nous installerons et configurerons un hyperviseur (HV0) sous un hôte
Windows Datacenter 2019. C’est sur ce dernier que nous migrerons notre contrôleur Active
directory 2008 vers la version Windows 2016. Sur ce même hyperviseur nous installerons
aussi un serveur de backup pour faire la sauvegarde de nos machines virtuelles.

Pour mieux comprendre notre démarche et les étapes de réalisation de notre projet, nous
l’avons schématisé par le graphique ci-dessous.
Installation et configuration de Windows Datacenter 2019

Intsallation et configuration ADDS(migration vers Windows 2016)
Installation de Installation et configuration serveur backup(SVR-BACKUP)
l'hyperviser HV0
Configuration des swicths SAN HP StorageWorks 8/8

Configurqtion et configuration de la baie HP P2000 G3
Mise en service du Configuration et configuration des serveur Noeuds
SAN HP 2000 G3
FC
Installation et configuration des roles Hyper-V

Installation de la fonctionnalité cluster de basculement
Installation et Installation et configuration MPIO
configuration du Installation et configuration des seveur de fichier, d'antivirus, serveur
cluster de AZure Ad connect et conversion de certain serveur physique en Vms.
basculement
Hyper-V
Figure 8 : étapes de la phase de réalisation
3.2 Planning des travaux
Pour mieux gérer nos travaux, nous l’avons inscrit dans le cadre d’un projet de la Société de
Patrimoine. Ce projet a été subdivisé en quatre phases : Initialisation, Planification,
Réalisation, contrôle et clôture. Le planning que nous avons mis en place est présenté ci-
dessous.

Années 2022
Phases/Taches Mois Jan Fevrier Mars Avril Mai Juin Juillet Aout
Semaine 1 11 12 25 26 28 4 5 8 9 10 1 30 1 31 1 2 6 7 13 14 16 17 21 22 24 25 29 30 6 7 8 14 15 21 22 26 27 29 30 3 4
Phase 1: Initialisation
Choix du theme
Développement de la Charte projet
Approbation de la charte
Phase 2: Planification
Conception générale
Plan détaillé et Cahier des Charges
Approbation Plan détaillé et Cahier des Charges
Achat de lience et matériel nécessaire
Phase 3: Réalisation
Configuration physique des équipements
Configuration de l'hypervieur HV0 (le serveur active directory et le
serveur backup)
Configuration du SAN Storage HP P2000
Configuration, parametrage du cluster de basculement des

serveurs(HV1 et HV2)
Transformation du controleur Ubiquity en serveur virtuel
Mise en service des serveurs d'antivurus, fichiers, Azure Ad contect
et de backup
Validation de la phase par DSI
Phase 4: Contrôle et suivi
Tests d’intégration et de consolidation
validation de la l'implémentation
Phase 5: Clôture du projet
Liste des corrections
Documentation leçons apprises
Décommissionnement anciens systèmes
Réunion de clôture
Figure 9: Macro-Planning

3.3 Installation de l’hyperviseur HV0 (ADDS et serveur Backup)

3.3.1 Installation et configuration de l’hyperviseur HV0
Sur un serveur HP ProLiant DL380 G10, nous avons installé Windows serveur Datacenter
2019 (Voir Annexe 1 sur les étapes d’installation). Les caractéristiques de ce serveur sont les
suivants :
Processor Intel Xeon Silver 4110 (Octo-Core 2.1 GHz / 3.0 GHz Turbo - 16 Threads - Cache
11 Mo) 16 Go DDR4 RDIMM (1x 16 Go - 12 slots) 8 baies pour disques durs HPE
SAS/SATA SFF. Contrôleur de stockage HPE Smart Array P408i-a/2Gbit/s avec batterie de
stockage intelligente.
Figure 10 : Serveur ProLiant DL380 G10
3.3.2 Migration d’active directory 2008 vers 2016

Nous avons un serveur Active directory qui fonctionnait sous Windows 2008 R2. Avant de
débuter les configurations du SAN et du cluster de basculement, il nous fallait migrer ce
contrôleur de domaine vers la version Windows 2016. Nous avons pour cela eu recours à la
machine virtuelle (SVR-AD1) installée sur l’hyperviseur HV0. Cette machine virtuelle doit
être membre du domaine.

Figure 11: Migration ADDS 2008 Vers 2016
Avant de pouvoir directement réaliser la migration, nous devons préparer et faire une mise à
jour de notre forêt. Pour cela, il faudra retourner sur notre SVR-AD, puis rentrer l’ISO
d’installation d’un Windows 2016 pour mettre à niveau la forêt. On l’effectue grâce aux
commandes Adprep /forestprep (préparation de la forêt) et Adprep /domainprep
(préparation du domaine).
Il faut ensuite mettre notre deuxième serveur (SVR-AD1) dans le domaine, puis installer le
rôle AD DS et promouvoir le deuxième contrôleur de domaine.
Figure 12 : Ajout SVR-AD1 dans le domaine

Figure 13 : Ajout du rôle AD DS sur le serveur SVR-AD1
Figure 14 : Ajout d'un contrôleur de domaine a un domaine existant

Figure 15 : Option du contrôleur de domaine secondaire
Ensuite, nous devons transférer les rôles FSMO (Flexible Single Master Operation) du
contrôleur SVR-AD vers SVR-AD1. Ils sont aux nombres de cinq à savoir :
 Maître d’attribution de noms de domaines

Ce rôle est chargé d’ajouter et de supprimer les domaines dans la forêt. Il est unique
dans la forêt.
 Maître de schéma
Il gère le schéma Active Directory contenant tous les objets pouvant être créés et les
attributs. Il est le seul à pouvoir modifier le schéma. Par exemple, lors de l'ajout d'un
service Exchange dans votre organisation, ce rôle modifie les attributs au cours de la
préparation AD. Comme le précèdent, ce rôle est unique dans la forêt.
 Maître RID
Il distribue le pool RID à chaque contrôleur de domaine pour garantir que chaque SID
émis par le DC sera unique. Tout comme les deux autres rôles, il est unique dans le
domaine.
 Émulateur de contrôleur principal de domaine (PDC)

Il est unique dans le domaine, il se charge de synchroniser l'heure entre les différents
serveurs et ordinateurs, de modifier les mots de passe et de verrouiller les comptes.
 Maître infrastructure
Il est unique au sein du domaine, son rôle est de gérer les références inter-domaines.
Pour l’instant, tous ces rôles sont détenus par notre Contrôleur de domaine principal.
Figure 16: Rôle FSMO sur SVR-AD
Le transfert peut se faire en PowerShell ou sur l’interface graphique du gestionnaire de

serveur. Nous avons choisi de le faire en PowerShell. La commande permettant de le faire est
décrite ci-dessous :
Move-ADDirectoryServerOperationMasterRole -Identity "NomServer" -

OperationMasterRole 0,1,2,3,4 -force
Les numéros ici correspondent aux noms des différents rôles master. Le tableau plus bas nous
détaille les identifiants des différents rôles :
Identifiant Rôle FSMO

0 PDC Emulator
1 RID master
2 Infrastructure master
3 Schema master
4 Domain naming master
Tableau 2 : Identification des rôles FSMO

Figure 17: Transfert des rôles FSMO de SVR-AD vers SVR-AD1
Figure 18 : statut des rôles après transfert
Une fois tous les rôles transférés sur le deuxième contrôleur et après avoir effectué des
vérifications que tous les rôles sont à nouveaux fonctionnels, nous pouvons maintenant
rétrograder le premier contrôleur puis le sortir du domaine. Cela s’accomplit grâce à la
commande Dcpromo.exe en CMD. Mais avant de le faire, nous allons retirer le premier
contrôleur en tant que catalogue Global du domaine. Les captures ci-dessous illustrent nos
propos.

Figure 19 : Retirer SVR-AD en tant que catalogue global
Figure 20 : rétrograder du serveur en contrôleur à l’aide de Dcpromo.exe

Figure 21 : Rétrogradation du serveur SVR-AD en tant que contrôleur de domaine (Suite 1)
Comme nous pouvons le constater dans notre unité d’organisation Domain Controllers, il ne
nous reste plus qu’un seul contrôleur de domaine.

Une fois le serveur principal rétrogradé en tant que contrôleur de domaine nous pouvons
maintenant le sortir de notre domaine. Les adresses IP étant fixées de manière statique sur
tous nos serveurs, il faut renseigner sur chaque serveur la nouvelle adresse du serveur DNS.
Aussi, sur notre serveur DHCP, faudra-t-il modifier les paramètres pour ajouter l’adresse du
nouveau serveur DNS.
3.3.3 Installation du serveur backup

La deuxième machine virtuelle que nous avons installée sur notre HV0 est le serveur backup.
Comme nous n’avions pas de serveur de backup dans l’architecture existant, il nous en fallait
un pour assurer une protection de nos serveurs en production.
Il nous permettra de sauvegarder tous nos serveurs. Nous avons opté pour le logiciel de
sauvegarde Veeam backup réplication, qui est le leader en matière de la protection moderne
des données. Il garantit la résilience des données grâce à des sauvegardes sécurisées et à des
solutions de restauration rapides et fiables pour le cloud hybride.
3.4 Mise en place d’un SAN HPE StorageWorks P2000 FC G3

3.4.1 Composants de notre architecture SAN HPE StorageWorks P2000 FC G3
HP P2000 G3 FC est une solution de stockage haute performance qui combine des
performances remarquables avec une grande fiabilité, disponibilité, flexibilité et souplesse de
gestion. Notre architecture de virtualisation repose sur un SAN HP P2000 G3 FC. Il était
important pour nous de mettre en service ce SAN. Ce dernier est constitué des équipements
suivants :
Deux (2) Switches SAN StorageWorks 8/8 :

Les commutateurs SAN StorageWorks 8/8 sont conçus pour les PME et s'adaptent
parfaitement aux SAN d'entrée de gamme. Le commutateur SAN StorageWorks 8/8
assure une connectivité SAN qui améliore la performance du système, maximise la
valeur des déploiements de serveurs virtuels et réduit les coûts de stockage totaux. Il
assure la redondance en lecture/écriture sur les baies de stockage grâce la prise en
charge de MPIO (MultiPath I/O).
Il fournit une solution rentable à commutateur unique pour les nouvelles installations
SAN à petite échelle qui connectent uniquement le stockage et les serveurs. La licence
d'extension optionnelle Full Fabric SAN fournit une connectivité à d'autres
commutateurs. Il est livré avec une licence Full Fabric et peut être connecté à de
nombreux commutateurs. Les deux commutateurs à 8 ports sont livrés avec des
options de croissance pour une extension ininterrompue jusqu'à 24 ports activés.
Figure 24 : Façade arrière des switch HP StorageWorks 8/8
Deux nœuds de serveur (HPE ProLiant DL380p Gen9) :

Le serveur HPE ProLiant DL380 Gen9 offre des performances et une évolutivité de
pointe. Sa fiabilité, sa simplicité d'entretien et sa disponibilité presque continue,
assorties d'une garantie complète, en font le serveur idéal pour n'importe quel
environnement de serveur. Il est conçu pour réduire les coûts et la complexité en
exploitant des processeurs E5-2600 v4 d'Intel de dernière génération offrant jusqu'à
21 % de gain de performances et il est doté de la toute dernière mémoire HPE DDR4
Smart Memory 2 400 MHz prenant en charge 3 To et assure une augmentation des
performances pouvant atteindre 23 %.
Prise en charge des cartes réseau 12 Gbit/s SAS et 40 Go avec une large gamme
d'options de calcul. La mémoire persistante HPE, le premier module NVDIMM au
monde optimisé sur ProLiant, offre des niveaux inégalés de performances pour les
bases de données et les charges de travail analytiques. Il convient d’exécuter tout type
d'applications, des plus simples aux plus stratégiques, et de les déployer en toute
confiance.
Les caractéristiques des nœuds HPE ProLiant DL380 Gen9 que nous disposons sont :
 Processor : 2 x Intel Xeon E5-2690V3 / 2.6 GHz (3.5 GHz) (14 cœurs) ;
 Ram : 64 GO DDR4 SDRAM ;
 Port réseau : 4 ports RJ45 ;
 Disque : 4 disques de 380 Go en Raid 5 (nous verrons plus bas dans la suite du
rapport comment nous l’avons configuré).
Figure 25 : ProLiant DL380 Gen9

Une Baie de stockage HP P2000 FC G3 :

Dans le marché nous avons deux types de baie HP P2000 FC G3. Les systèmes grand
format de forme (disque 3.5’’) et les systèmes petits formats de forme (disque 2.5’’).
Les serveurs utilisés dans le projet sont des systèmes petit format de forme avec deux
contrôleurs P2000 FC.
Figure 26 : Système petit facteur de forme vue façade arrière
Figure 27 : Système petit facteur de forme vue façade avant
Cette baie prend en charge les niveaux de Raids 0,1,5,6,10 et 50. Il est possible de
créer jusqu’à 512 LUNs (Volume) d’une taille maximale de 16 TB chacun. Notre baie

est constituée de dix (10) disques SAS de 1 TO chacun. Nous avons utilisé le Raid 6
dans nos configurations.
Figure 28 : HP P2000 FC G3
3.4.2 Architecture physique des HP StorageWorks 8/8 SAN Switch
Dans cette section nous verrons comment les équipements susmentionnés sont interconnectés
entre eux. Le raccordement de ces équipements a été effectué en totale conformité avec le
manuel d’installation du fournisseur HP. Les nœuds de serveurs sont connectés à la baie grâce
aux switches qui jouent leur rôle de commutateur et assurent une redondance en lecture et
écriture sur la baie de stockage. Le support de connexion utilisé est la fibre optique, elle
garantit des performances de hautes qualités.

Figure 29 : Architecture du SAN HP P2000 FC G3
NB : Architecture du SAN HP P2000 FC G3 ci-dessus ne représente que les ports SFP
connecté. Cet équipement présente de nombreux autres ports.
Le tableau ci-dessous résume les numéros WWN (Word Wide Name) des ports de différents
équipements.

Equipement Port WWN

Port 1 50 01 43 80 24 27 F1 3C
Serveur 1
Port 2 50 01 43 80 24 27 F1 3E
Port 1 50 01 43 80 24 27 F0 3C
Serveur 2
Port 2 50 01 43 80 24 27 F0 3C
Port 0 20 00 00 27 F8 93 0C 40
Port 1 20 01 00 27 F8 93 0C 40
Switch SAN 1
Port 4 20 04 00 27 F8 93 0C 40
Port 5 20 05 00 27 F8 93 0C 40
Port 0 20 00 00 27 F8 97 00 78
Port 1 20 01 00 27 F8 97 00 78
Switch SAN 2
Port 4 20 04 00 27 F8 97 00 78
Port 5 20 05 00 27 F8 97 00 78
P2000 CTL 1 Port 1 20 70 00 C0 FF 1A 2A 85
P2000 CTL 1 Port 2 21 70 00 C0 FF 1A 2A 85
Baie HP P2000 G3 FC
P2000 CTL 2 Port 1 24 70 00 C0 FF 1A 2A 85
P2000 CTL 2 Port 2 25 70 00 C0 FF 1A 2A 85
Tableau 2 : Numéro de WWN des équipements
3.4.3 Configuration des HP StorageWorks 8/8 SAN Switch
Après l'installation du matériel et la mise sous tension des composants pour la première fois,
la première étape est la configuration des commutateurs SAN. Dans notre infrastructure
système, nous avons un serveur DHCP sous Windows 2016 avec l’option filtre par adresse
MAC activée. Cette option nous permet d’autoriser les adresses mac qui peuvent se connecter
sur notre réseau. Il nous a fallu premièrement enregistrer les adresses MAC des switches SAN
sur notre serveur DHCP.
Pour cela nous avons récupéré les adresses MAC sur les cartes d’informations des
commutateurs disponibles sur les équipements. Deuxièmement, grâce à un câble serial et à
l’émulateur tel que PuTTY, nous avons établi une connexion aux switches pour fixer les
adresses IP.
Les identifiant de connexion par défaut sont les suivants :
 Login : admin
 Password : Password (Ce mot de passe par défaut a été changé)

Figure 30 : Connexion au switch SAN
Une fois les identifiants de connexion rentrés nous devons maintenant fixer les adresses IP
du switch SAN. Pour cela, nous utiliserons les commandes ipaddrset comme illustrée dans
les figures ci-dessous :
Figure 31 : Fixation de l'adresse IP sur le switch 1
Figure 32: Fixation de l'adresse IP sur le switch 2
Après avoir fixé les adresses IP des deux switches, nous pouvons maintenant nous connecter
sur la console web de management grâce à ces adresses.
Sur cette console web, nous créerons les zones et les alias des ports HBA (Host Bus Adapter).
Ces concepts qui seront développés dans la suite de ce rapport. Nous tenons à rappeler que les

serveurs (Nœuds) et la baie de stockage HP P2000 sont tous connectés aux switches par le
support fibre optique. Les ports HBA des serveurs et de la baie de stockage sont identifiés par
un numéro unique appelé WWN (Word Wide Name). Ce dernier permet d’identifier les
périphériques sur le SAN. C’est l’équivalent des adresses IP dans un réseau.
Avant d’aller plus loin, il serait intéressant de définir les concepts d’alias et de zone :
 Alias : les ports WWN étant constitué de 24 bits, ils sont assez difficiles à identifier
sur un équipement. L’alias permettra de faire correspondre un WWN à un nom plus
facile à identifier ou nommer. Prenons l’exemple d’un hyperviseur ayant deux ports
WWN que nous pourrions renommés en alias suivant :
Port 1 : 500143802427F13C alias HV1-P1
Port 2 : 500143802427F13D alias HV1-P2
 Zone : elle permet un regroupement logique des ports et des périphériques de

stockage au sein d’un réseau de stockage. Elle définit une route qui permet à un nœud
ou des nœuds d’accéder à des volumes logiques (LUN) sur une bais de stockage. Elle
détermine les hôtes qui ont le droit de communiquer avec les nœuds de stockage.
Chaque hôte ou baie de stockage peut être membre de plusieurs zones dans un SAN.
Pour l’essentiel, le zoning permet à un administrateur de contrôler précisément qui
peut voir quoi dans un SAN. Lorsqu’on crée une zone, il faudra définir les ports
(WWN) qui en font partie (les membres).
Le zoning est un service rendu par la fabrique SAN Fibre Channel. Il sert à la fois de
mécanisme de sécurité (le zoning empêche les serveurs non autorisés de se connecter
aux ressources de stockage auxquelles ils n'ont pas accès) et de limitation des
communications d’hôte à hôte. Le zoning Fibre Channel peut s’effectuer par numéro
de port sur un switch (on parlait historiquement de hard zoning) ou par numéro de
World Wide Name (l’identifiant unique d’une carte ou HBA Fibre Channel). On parle
dans ce dernier cas de « soft zoning ». Le soft zoning est aujourd’hui la méthode
privilégiée de zoning d’un SAN du fait de sa plus grande flexibilité et de son
adaptation aux environnements virtualisés.
Le Zoning est une pratique courante sur les SAN, qui permet de limiter les corruptions
de données mais aussi d’accroître la sécurité. Il peut toutefois compliquer la gestion du
SAN à très grande échelle, notamment lorsqu’il faut modifier fréquemment les

paramètres de zonage dans un environnement très mouvant, ou lorsqu’il faut

provisionner rapidement un grand nombre d’hôtes et de baies de stockage.
Une fois ces différents concepts expliqués, nous pouvons passer aux détails de notre
configuration. Cette dernière se déroule en deux étapes. Premièrement nous allons créer les
alias, deuxièmement, nous terminerons par la configuration des zones.
 Création des alias :
Pour créer des alias nous devons nous connecter au Switch SAN via la console web de
gestion et rentrer les identifiants de connexions. Ensuite, une fois la connexion établie,
nous cliquerons sur Zone Admin. C’est sur cet onglet que les configurations des zones et
des alias sont opérées.
Figure 33 : Connexion à la console web de gestion
Quatre ports sont connectés sur chacun de nos switch SAN. Il s'agit des ports 0, 1, 4 et 5.
Nous allons ainsi créer les alias de ces ports.

Figure 34 : Les quatre ports connectés sur le switch SAN
Nous créerons les alias des ports présentés dans la figure 34. Pour chaque alias, nous
indiquerons les WWN des équipements établissant la connexion à ce port à savoir : le WWN
du port du switch connecté et le WWN de l’équipement à l’autre extrémité (les nœuds ou la
baie). Comme nous avons quatre ports connectés, nous créerons alors quatre alias sur chaque
switch. La figure ci-dessous récapitule les noms des alias que nous créerons.
Port Alias Descriptif Nom de l'alias

Switch 1
0 H1_P1 Port 1 de l'Hyperviseur 1 P0_witch1/H1_P1
1 P2000_CTL1_P1 Port 1 du contrôleur 1 de la baie P2000 P1_witch1/P2000_CTL1_P1
Switch 2
Tableau 3 : Identifications des alias des ports
Après identification de tous les alias, nous devons songer à la configuration. Pour le faire,
toujours sur l’onglet Zone Admin, nous devons cliquer sur New Alias, donner un nom à notre
alias et ajouter les WWN des ports membres.

Fi
gure 35 : Création et configuration d'un alias
Prenons l’exemple de l’alias H1_P1. Les membres faisant partie de cet alias sont les ports
connectés de part et d’autre de cette liaison. Nous avons ainsi créé quatre alias sur chaque
switch SAN.
Figure 36 : Résumé des quatre (4) alias créés
Après la création des alias, nous configurerons les zones.
 Configuration des zones

Nous créerons ainsi deux zones par switch. Les zones sont l’équivalent des routes en
réseau. Le tableau ci-dessous illustre les zones qui ont été créées.
T
a
b
Zone Alias l
Switch 1 e
H2_P1 a
H1_P1_P2000_CTL1_P1 u
P2000_CTL1_P1
4
H1_P1
H2_P1_P2000_CTL2_P1 :
P2000_CTL2_P1
Switch 2
H2_P2
H2_P2_P2000_CTL2_P2
P2000_CTL1_P2
H1_P2
H1_P2_P2000_CTL1_P2
P2000_CTL1_P2
Planification zones créées
Tout comme pour la création des alias, les zones sont créées dans la partie Zone Admin. Il
faut ensuite cliquer sur New Zone, donner un nom à sa zone et ajouter les alias faisant partie
de la zone. La figure ci-dessous illustre la création des zones.

Figure 37 : Création des zones
Dès l’instant où tous les alias et toutes les zones ont été créées, nous dévons finaliser la
configuration par la création d’une zone config. La zone config est notre fichier de
configuration.
 Création d’une zone Config

La zone config est créée dans la partie Zones admin. La configuration est quasi
identique à la création des alias et des zones. Tout d’abord, nous devons donner un
nom à notre zone, ensuite nous devons ajouter les zones faisant partie de notre zone
config. Enfin nous devons enregistrer notre configuration en cliquant sur le bouton
Save Config puis sur Enable Config.
Fi
gure 38 : Création des zones
3.4.4 Configuration de la baie de stockage HP P2000 FC G3

Sur la baie de stockage, nous créerons un volume. C’est sur ce volume que les serveurs
viendront lire/écrire les données. Notre baie est constituée de dix (10) disques de 1GB chacun.
Avec ces dix (10) disques, nous créerons un volume (Vdisk) de 8GB en RAID 6.
Pour se connecter sur la baie, nous avons utilisé le port CLI sur les contrôleurs de la baie. Ce
port permet d'accéder au système à l'aide de l'interface de communications (Universal Serial
Bus) et d’un logiciel d'émulation du terminal. Les commandes CLI décrites dans les étapes ci-
dessous permettent de configurer l'adresse de chaque module de contrôleur. Une fois les
nouvelles adresses IP configurées, il est possible de les modifier si nécessaire à l'aide de SMU
(Interface de configuration).
Figure 39 : Connexion à la Baie HP2000 via le port CLI

Figure 40 : Fixation des adresses IP des contrôleurs de la baie
Figure 41 : Vérification des IP fixées
L’étape initiale de configuration de la baie étant achevée, nous pouvons maintenant nous
connecter sur l’interface graphique (Storage Management Utility) pour la création du volume.
Sur l’interface de management, nous avons créé un volume au nom de Vdisk-SP. Ce dernier
possède une capacité de 8 TB en RAID6.

Figure 42 : Volume créé sur la HP P2000
3.4.5 Installation et Configuration des serveurs ProLiant DL380 Gen9 et

connexion à la baie de stockage HP P2000 FC G3
Les switches et la baie de stockage étant configurés, nous devons à présent configurer les
serveurs pour qu’ils puissent lire les données sur baie. Nous allons commencer par
l’installation des systèmes d’exploitation sur ces serveurs. Mais au préalable, il nous a fallu
choisir le système d’exploitation compatible à ces serveurs. Notre infrastructure système étant
essentiellement constituée des serveurs sous Windows, nous avons choisi de continuerer avec
ce système. Nous avons préféré installer Windows serveur 2016 Datacenter sur nos serveurs
étant donné que nous avons pour ambition de virtualiser notre infrastructure système.
Les paragraphes ci-dessous nous expliquerons les étapes d’installation de Windows

Datacenter sur nos serveurs.
Pour installer le système sur les serveurs HP ProLiant DL380p Gen9, faut cliquer sur la
touche F10 (Intelligent Prosivioning) pendant le processus de démarrage du serveur. Ensuite,
il faut utiliser le service Intelligent Prosivioning de HP.
Intelligent Provisioning est un outil d'assistance serveur simple à utiliser, qui offre un
déploiement rapide et une flexibilité sur la façon de déployer des serveurs. C’est une solution
intégrée dans la plupart des serveurs HPE ProLiant qui fournit la configuration du système via
un assistant facile à utiliser. Il augmente la simplicité car aucun support n'est nécessaire
(aucun CD SmartStart requis). L’on peut y accéder en appuyant sur F10 pendant le processus
de démarrage du serveur, ou l’on peut accéder à moment sur Intelligent Provisioning à partir
de l'interface utilisateur du navigateur iLO.
Tous les micrologiciels, pilotes et outils nécessaires sont disponibles sur le système afin que
le serveur soit immédiatement prêt pour le provisionnement. Cet outil de configuration du
système et du système d'exploitation entièrement intégré réduit les étapes d'installation et de
configuration du serveur pour déployer les serveurs plus rapidement.
Les figures 22 à 27 illustrent quelques impressions du processus d’installation en quatre (4)

étapes.
Tous d’abord, il faut cliquer sur F10 pendant le processus de démarrage du serveur.
Figure 43 : Initialisation du processeur Intelligent Provisioning
À l’affichage suivant, il faudra cliquer sur configurer et installer.
Figure 44 : Début d'installation du système d’exploitation

Ensuite, l’étape 1 du processus d’installation consiste à spécifier les paramètres du matériel.
Figure 45 : étapes 1 - Paramètres matériels
Puis, à l’étapes 2, il faudra choisir le système d’exploitation en spécifiant le chemin d’accès

de l’ISO. Dans notre cas, nous avons installé le système d’exploitation grâce à l’ISO présent
dans notre clé USB.
Figure 46 : étape 2 : sélection du système d'exploitation
A L’étape suivant (étape 3), les informations du système d’exploitation s’affichent. Il faudra
choisir la langue du système, rentrer la clé du produit et définir le mot de passe administrateur
du serveur. Une fois les paramètres souhaités rentrés, il suffit de cliquant sur « suivant ».
Enfin, la dernière étape permet de vérifier les configurations finales avant de lancer le début
de l’installation du système Windows 2016 Datacenter.

Figure 47 : Etape 4 – Vérification
Figure 48 : Début de l'installation
L’installation étant achevée et la configuration de base (nom de serveur, fixation des adresse
IP, gestion à distance, association de la cartes réseau) effectuée ; nous devons maintenant
connecter nos serveurs à la baie de stockage. Pour cela, nous devons installer la fonctionnalité
MPIO qui permet la prise en charge de multiples chemins de stockage. Le MPIO répond à
deux problématiques : la performance et la fiabilité. Il utilise les composants de chemin
d’accès physique redondants (adaptateurs, câbles et commutateurs) pour créer des chemins

d’accès logiques entre le serveur et les périphériques de stockage. En cas de défaillance de

l’élément à l’origine de l’échec du chemin d’accès logique ; la logique de gestion multivoie
utilise un autre chemin pour l’E/S afin que les applications puissent toujours accéder à leurs
données. De plus, selon la configuration, MPIO peut également améliorer les performances en
rééquilibrant la charge sur tous ces chemins d’accès.
Les figures 35 et 36 illustrent respectivement l’installation de la fonctionnalité MPIO et la

connexion des serveurs à la baie de stockage.
Figure 49 : Installation de MPIO

Figure 50 : Découverte des chemins redondants
3.5 Configuration du cluster de basculement de serveurs
3.5.1 Installation du rôle Hyper-V et Clustering de basculement
Une fois l’installation des systèmes d’exploitation Windows Datacenter 2016 effectuée, nous
installerons le rôle Hyper-V puis la fonctionnalité le clustering de basculement sur les deux
nœuds du cluster.

Figure 51: Installation du rôle Hyper-V
Figure 52 : Installation la fonctionnalité clustering de basculement
Une fois l’installation de la fonctionnalité finie, il convient d’ouvrir le Gestionnaire de Cluster

de basculement. Ces cette console qui gère toutes les configurations du cluster de
basculement.

Figure 53 : Gestionnaire du cluster de basculement
Avant de créer un cluster de basculement, nous recommandons fortement à l’utilisateur de

valider sa configuration en s’assurant que ses paramètres matériels et logiciels sont
compatibles avec son cluster de basculement. Microsoft ne prendra en charge une solution de
cluster que si elle a réussi tous les tests de validation et si tous les composants matériels ont
été certifiés pour les instances de Windows Server s'exécutant sur les nœuds du cluster.
3.4.2 Validation du cluster de basculement
Les serveurs faisant partie d’un cluster doivent être identiques en termes de matériel et
logiciel. Car lorsqu’une machine virtuelle est migrée d’un hôte à un autre, elle ne doit pas
constater une différence de performance entre les deux hôtes ; cela pourrait engendrer des
perturbations de fonctionnement de la machine virtuelle. La validation du cluster nous
permettra de déterminer si les deux nœuds sont compatibles au cluster de basculement. Les
figures 40 à 44 nous montrent les étapes de la validation du cluster de basculement.

Figure 54 : Lancement de l'assistant de Validation d'une configuration
Figure 55 : Sélection des nœuds du cluster

Figure 56 : Exécution du test de validation
Figure 57 : Validation en cours

Figure 58 : Résumé du test de validation
3.5.3 Création du cluster de basculement
Après avoir réussi la validation du cluster de basculement, nous pouvons à présent créer notre
cluster de basculement. Les figures 45 à 50 illustrent avec précision la création d’un cluster de
basculement.
Il faut démarrer le Gestionnaire de serveur. Dans le menu Outils, sélectionner Gestionnaire

du cluster de basculement. Dans le volet Gestionnaire du cluster de basculement, sous
Gestion, sélectionner Créer le cluster. L'Assistant Création d'un cluster s'ouvre.
Figure 59 : Lancement de l'assistance de création du cluster de basculement

Ensuite, nous devons choisir les serveurs faisant partie de notre cluster ; c’est-à-dire les
serveurs nœuds. Quand la page Sélectionner les serveurs s’affiche, dans la zone entrer un
nom, il faut ajouter le nom NetBIOS ou le nom de domaine complet d’un serveur que l’on
prévoit d’ajouter en tant que nœud de cluster de basculement, puis sélectionne Ajouter.
Répéter cette étape pour chaque serveur à ajouter. Pour ajouter plusieurs serveurs à la fois,
séparer les noms d’une virgule ou d’un point-virgule. Par exemple, entrer les noms au format
server1.contoso.com ; server2.contoso.com. Une fois l’étape terminée, cliquer sur Suivant
Figure 60 : Sélection des serveurs Nœuds
L’étape suivante consiste à donner un nom et une adresse IP à notre cluster. En effet, les
utilisateurs, pour accéder à nos machines virtuelles qui se trouvent dans notre cluster de
basculement, utiliseront cette adresse IP et ce nom.
Dans la page Point d'accès pour l'administration du cluster ; Dans la zone nom du cluster,
entrer le nom que l’on veut utiliser pour administrer le cluster et une adresse IP disponible. Il
est important de comprendre que pendant la création du cluster, ce nom est inscrit en tant
qu'objet ordinateur de cluster (aussi appelé objet nom de cluster ou CNO) dans Active
directory (AD DS). Si l’on spécifie un nom NetBIOS pour le cluster, le CNO est créé à
l'emplacement où résident les objets ordinateur des nœuds du cluster. Il peut s'agir soit du
conteneur Ordinateurs par défaut, soit d'une unité d’organisation. Un objet AD ordinateur sera
créé dans l’annuaire Active directory. Cet Object aura pour nom ClusterSP.

Figure 61 : : Attribution de l'adresse IP au cluster de basculement
Figure 62 : Confirmation des paramètres avant création

Figure 63 : Résumé de la création du cluster
Figure 64 : Affichage du gestionnaire de cluster
L’installation du cluster de basculement étant achevée ; nous ferons un tour du gestionnaire de

cluster de basculement pour explorer différents onglets.

C’est dans l’onglet Rôles que nous installerons nos différents rôles de cluster. Un rôle peut
être une machine virtuelle ou un service disponible en haute disponibilité. Pour l’instant, nous
n’avons aucun rôle.
Figure 65 : Gestionnaire de cluster de basculement – rôle
Nous pouvons voir dans l’onglet Nœuds nos différents nœuds faisant partie de notre cluster.
Figure 66 : Gestionnaire de cluster de basculement – Nœud
Dans le stockage de notre cluster, nous retrouvons nos deux disques logiques SAN créés
précédemment :

Le disque témoin de 1, 40 Go configuré pour le quorum et le deuxième disque de 7,5 To

réservé au stockage des Vms.
Figure 67 : Gestionnaire de cluster de basculement – Disque
Pour les réseaux, nous en possédons deux comme illustré dans la figure 668 ; un pour le
Heartbeat (communication directe entre les Noeux, réservé aux nœuds du cluster uniquement)
et un réseau de production (communication avec le réseau entier de l’entreprise).
Figure 68 : Gestionnaire de cluster de basculement – Réseau
Notre cluster étant créé et fonctionnel, il ne nous reste plus qu’à installer les serveurs que nous
voulions mettre en place. Le point suivant fait un point sur le déroulement de l’installation des
machines virtuelles sur un cluster de basculement Hyper-V.

3.6 Installation des serveurs dans le cluster

Conformément à nos objectifs, nous avons trois serveurs à installer et configurer à savoir le
serveur de fichier, le serveur d’antivirus et le serveur ADConnect (pour Azure AD). Nous
verrons en détails comment créer des machines virtuelles dans un cluster de basculement.
Lorsque l’on crée un cluster Hyper-V, chaque ordinateur virtuel créé dans le cluster sera
considéré comme un rôle de cluster par le gestionnaire du cluster de basculement. Néanmoins,
pour que nos machines virtuelles soient disponibles pour tous les nœuds du cluster, nous
aurons besoin d'un volume partagé de cluster (aussi appelé CSV en anglais pour : Cluster
Shared Volumes).
Pour cela, il suffit de sélectionner notre disque de 7,5 To qui est actuellement attribué à
"Stockage disponible" et de cliquer sur "Ajouter aux volumes partagés de cluster" dans la
colonne de droite.
Figure 69 : : Ajout du stockage Disque-VM aux volumes partagés de cluster
Nous obtenons un volume partagé en cluster. C’est sur ce volume que toutes les machines virtuelles
seront stockées.

Figure 70 : Volume partagé de cluster
Une fois le volume de cluster créé, nous pouvons maintenant créer nos machines virtuelles
dans notre cluster. L’annexe 2 nous montre les étapes pas à pas de la création d’une machine
virtuelle dans un cluster de basculement. C’est grâce à cette étape que nous avons installé le
serveur d’antivirus, de stockage et le serveur Azure AD.
Figure 71 : Machine virtuelle installée sur notre cluster
3.7 Conversion des serveurs physiques existants en serveurs virtuels

Dans notre architecture existante, nous avons un serveur physique que nous devions
transformer en machine virtuelle. Pour ce faire, nous avons utilisé le convertisseur Disk2vhd
de Microsoft.
Disk2vhd est un utilitaire qui crée des versions de disque dur virtuel pour une utilisation dans
Microsoft Hyper-V. La différence entre Disk2vhd et d’autres outils physiques ou virtuels est
que l’on peut exécuter Disk2vhd sur un système en production. Disk2vhd utilise la
fonctionnalité d’instantané de volume de Windows, introduite dans Windows XP, pour créer
des instantanés à un point dans le temps cohérents des volumes que l’on souhaite inclure dans
une conversion. L’on peut même avoir Disk2vhd, créer les disques durs virtuels sur les
volumes locaux, même ceux qui sont convertis (bien que les performances soient meilleures
lorsque le disque dur virtuel se trouve sur un disque différent de celui qui est converti).
Il suffit de lancer l’outil sur le serveur que nous souhaitons convertir et le laisser effectuer le
travail.
Figure 72 : Création d'un disque Vhdx d'une machine Physique
À la suite du processus, l’on peut obtenir le fichier/disque vhdx, le copier dans le cluster de
basculement Hyper-V et le placer dans le dossier contenant les disques VM.

Figure 73 : Image VHDX créée
Une fois que nous avons le disque vhdx, il nous faut juste utiliser la procédure d’installation
d’une machine virtuelle décrite dans l’annexe 2. La seule différence ici est qu’au niveau du
choix de la connexion d’un disque dur nous utiliserons un disque virtuel existant.
3.8 Réalisation des tests de basculement
Pour vérifier que notre infrastructure de virtualisation est totalement redondant, nous allons
effectuer des tests de migration à chaud. Nous allons simuler la panne de l’hyperviseur HV2.
Normalement tous les serveurs virtuels disponibles sur cette hyperviseur doivent être migrés
sur l’hyperviseur active (HV1).
Comme le montre la capture ci-dessous, chaque hyperviseur possède deux machines

virtuelles.
Figure 74 : Liste des serveurs dans notre cluster
Nous allons volontairement suspendre l’hyperviseur HV2.

Figure 75 : Suspension de l'hyperviseur HV2
Nous constatons bien que les deux serveurs présents sur l’hyperviseur HV2 ont été migrés à
chaud en moins de 30s. Cette migration est totalement transparente pour les utilisateurs.
Figure 76 : Migration à chaud des serveurs présent sur HV2

Chapitre 4 : Évaluation

technique et budgétaire de
la solution Proposée
4.1 Evaluation de la solution proposée

La solution proposée est un succès et les livrables prévus dans nos objectifs ont été délivrés à
100%. Tous les objectifs ont été atteints en termes de qualité, périmètre et budget. Il est
important toutefois de noter que la nouvelle infrastructure a été livrée début août 2022. Et
depuis son implémentation, tout est fonctionnel, nous n’avons enregistré aucun bug
fonctionnel. Actuellement, et selon notre outil de monitoring de serveur (ManageEngine
Application Manager) , notre architecture de virtualisation est à 25% d’utilisation de ses
capacités (figure 78 à 80).
Applications Manager est une solution unifiée de surveillance des performances des
applications, de surveillance de l'infrastructure et de surveillance de l'expérience de
l'utilisateur final, approuvée par plus de 6 000 entreprises dans le monde. Les équipes des
opérations informatiques et de DevOps utilisent Applications Manager pour garantir la santé
et les performances optimales de leurs applications critiques, à la fois dans le centre de
données et dans le cloud.
Nous avons voici cette application car elle est facile à mettre en service et le support de
maintenance est excellent.
Cet outil de supervision nous montre que nous avons suffisamment de ressource pour
répondre aux exigences de croissance. A l'avenir, nous pourrions augmenter la puissance de
notre infrastructure de virtualisation si nécessaire.
Figure 77 : Monitoring d’hyperviseur 1 (Noeud 1)

Figure 78 : Monitoring Hyperviseur 2 (Noeud 2)
Figure 79: Utilisation des UC total sur chaque Hyperviseur
Figure 80 : Utilisation UC invitée sur chaque hyperviseur

4.2 Évaluation budgétaire
Dans cette rubrique, nous allons faire un bilan financier de toutes les dépenses effectuées.
Nous avons catégorisé ces dépenses en deux blocs : les dépenses liées au matériel et celles
liées à l’acquisition des logiciels.
Désignation Quantité Prix unitaire (TTC) Prix (TTC)

Dépense Matériel
Serveur HP P2000 FC/ISCSI 10 to disque 4 254 377,00 XAF 4 254 377,00 XAF
dure 1
Switch SAN StorageWorks 8/8 2 1 655 293,31 XAF 3 310 586,62 XAF
ProLiant DL380 G9 Intel® Xeon® CPU E5-

2609 0 @ 2.40 GHz 2.39GHz (2 2 2 350 309,00 XAF 4 700 618,00 XAF
processeurs) 32 GO RAM 4 disque 300Go
HPE ProLiant DL380 Gen10 4208 2.1GHz 8-
1 2 656 460,00 XAF 2 656 460,00 XAF
core 1P 32GB-R P408i-a NC 8SFF
HPE B-series 8Gb Shortwave Fiber Channel 2 113 111,00 XAF
1 Pack SFP+ Transceiver 226 222,00 XAF
HPE iLO Advanced 1-server License with
1yr Support on iLO 1 191 911,00 XAF 191 911,00 XAF
Licensed Fe
HPE 9.5mm SATA DVD-ROM Optical Drive 1 69 572,00 XAF 69 572,00 XAF
HPE 2TB SATA 6G Midline 7.2K SFF (2.5in) 4 391 807,00 XAF 1 567 228,00 XAF
SC 1yr Wty 512e Digitally Si
HPE 300GB SAS 12G Enterprise 10K SFF 143 000,00 XAF 429 000,00 XAF
(2.5in) SC 3yr Wty 3
HPE 32GB (1x32GB) Dual Rank x4 DDR4- 2 359 075,00 XAF 718 150,00 XAF
2933 CAS-21-21-21 Registered Smar
Dépense Logiciel
Windows server 2019 FRE OLP 16 LIC 2 4 901 907,00 XAF 9 803 814,00 XAF
CORELIC DATA CENTER
Licence Veeam Backup réplication 1 1 500 000,00 XAF 1 500 000,00XAF
Licence ManageEngine Applications
Manager Professional Edition - Perpetual
Licensing (10 serveurs) 1 726 997 XAF
30 154 935,62
Total XAF
Tableau 5 : Bilan financier du projet

Chapitre 5 : Bilan

5.1 Remarques
Durant cette période de stage, nous avons beaucoup appris sur le travail dans la société de
patrimoine, mais cela n'a pas été sans difficultés.
La première difficulté était de convaincre le Directeur Général de la Société de Patrimoine de
financer le projet. Ce projet initié par le Directeur des Systèmes d’Information n’ayant pas la
dernière décision sur le décaissement des fonds a dû être préalablement soumis à
l’appréciation du Directeur général. Il a fallu plusieurs réunions avec les membres du Codir
pour avoir les financements nécessaires. Et malheureusement là encore, nous n’avons pas
obtenu la totalité du financement demandé.
La deuxième difficulté rencontrée était liée aux délais de livraison du matériel informatique.
Au départ, notre fournisseur nous a donné des délais de livraison de deux
mois mais malheureusement, nous n’avons reçu le matériel que trois mois plus tard. Ce qui a
entraîné des retards dans notre planning initial. Heureusement, ce retard a été rattrapé en
accélérant les phases de configuration et de déploiement.
Pour finir, la difficulté récurrente rencontrée durant ce stage a été l’organisation de notre
temps de travail. En effet, il était difficile d’organiser notre temps entre les discussions dans le
but d’avoir des informations pour comprendre le fonctionnement du système à informatiser et
les diverses tâches que nous avions en tant que chargé des Infrastructure Système de la société
de Patrimoine.
5.2 Suggestions
Premièrement, la Société de patrimoine devrait mettre en place un comité de gestion de projet.
Ce comité devrait être au centre du cycle de vie d’un projet (avant-projet, Initialisation,
Planification, Exécution, Contrôle et Clôture). Ceci permettra de valider les projets jugés
prioritaires, nommé le chef de projet et finalement faire un suivi des projets en lui allouant les
ressources humaines et financières nécessaires pour la réalisation du projet. Aussi, la
Direction Générale de la Société de Patrimoine devrait-elle donner à ses directeurs de
département plus de pouvoir dans le financement des projets. Chaque année, les budgets des
départements sont discutés et alloués en fonction des exigences et priorités des départements.
Et au moment de l’exécution de ces budgets, il y a encore beaucoup d’hésitation de la part de
la Direction.
Deuxièmement, concernant les problèmes de retard de livraison, la SP devrait avoir une liste
des fournisseurs fiables capables de respecter ses délais de livraison. En outre, concernant les
projets de grosse ampleur comme celui-ci, nécessitant des commandes du matériel à
l’étranger, nous devrons mettre dans notre planning de projet un délai supplémentaire de
livraison d’un ou deux mois pour respecter le planning initial.
Enfin, pour ce type de projet, la SP devrait modéliser les ressources humaines sur une période
bien précise. Cette période permettrait aux ressources humaines de se concentrer amplement
sur le projet et donc de le terminer plus rapidement.

CONCLUSION GENERALE
En somme, dans le cadre de notre Master professionnel en Ingénierie Informatique,

Réseaux et télécommunications à l’ESGIS GABON, nous avons eu la chance d’effectuer un
stage d’une durée de six mois au sein de la Société de Patrimoine du Service public de l'Eau
potable, de l'Energie électrique et de l’Assainissement (SP). Il convient de rappeler les
différentes actions qui ont eu lieu au sein de cette entreprise au cours des six derniers mois.
Après un examen attentif de l'architecture du système, il a été convenu de mettre en place un
système de virtualisation de serveur redondant à l'aide de l'architecture de stockage HPE
P2000 G3 FC SAN.
Pour y répondre, nous avons d'abord mené dans une première phase, une étude
approfondie de l'infrastructure informatique existante au siège de la Société de Patrimoine et
avons tenté d'en définir les limites. Nous avons ensuite réalisé une étude conceptuelle de la
nouvelle architecture système que l'entreprise visait. Puis nous sommes passés à la phase de
réalisation. Dans cette phase, nous avons tout d’abord déployé l’infrastructure physique, puis
nous avons installé et configuré tous les équipements du système de virtualisation à savoir la
configuration du stockage HPE P200G3 FC, des nœuds du cluster de serveur HPE ProLiant
G9 et du cluster de basculement. Ensuite, nous avons implémenté une nouvelle politique de
sécurité à l’échelle de la société pour protéger les différentes postes des utilisateurs grâce à la
mise en place d’un serveur d’antivirus. Enfin, nous avons mis en place un système nous
permettant de sauvegarder notre système de virtualisation.
Le système de virtualisation de serveurs que nous avons mis en place durant notre stage
continuera de fonctionner dans les prochaines années eu égard aux résultats qu’il a déjà
permis d’obtenir. Aujourd’hui, si nous avons besoin de mettre en place un nouveau service, il
nous suffit de créer une machine virtuelle sur notre plateforme de virtualisation. Cela nous fait
gagner en temps et en ressource financière.
Cette expérience a été très enrichissante car elle m'a permis de découvrir en contexte le
secteur de l’eau et de l’énergie Gabonais, ainsi que les différentes missions et postes qui
contribuent à son développement. En étant impliqués dans la vie quotidienne de l'entreprise et
en interagissant avec divers acteurs, nous avons eu l'opportunité de renforcer nos compétences
dans le domaine des opérations d’une infrastructure SAN, virtuelles, de comprendre les
politiques de sécurité opérationnelles et les différents composants d’une infrastructure
informatique. Ce stage nous a également appris à améliorer nos compétences en
communication dans un environnement professionnel. Le déploiement s'est fait dans un
contexte de production avec un système en fonctionnement, ce qui nous a rapproché des
responsables et de la direction du SP et de mieux maîtriser les contraintes liées à la continuité
du service du SP pendant la migration. De ce point de vue, ce stage est une énorme
contribution pour nous sur le plan humain. Il nous a donné la possibilité de nous intégrer dans
l'environnement de l’entreprise et d'améliorer nos compétences.

Bibliographie
[1] : Mattnew Portnoy (2012). Virtualization Essentials.
[2] : Hewlett Packard Entreprise (2010). HP Storage P2000 G3 MSA Système câble
configuration guide. https://www.hpe.com/psnow/doc/c02451851
[3] : Florian Burnel (2022). Virtualisation Hyperviseur type 1 et 2. https://www.it-

connect.fr/les-types-dhyperviseurs/
[4] : Alphorm ; Patrick IZZO (2022). Formation haute disponibilité Windows 2012 R2 : Le
guide complet. https://www.alphorm.com/tutoriel/formation-en-ligne-la-haute-disponibilite-
sous-windows-serveur-2012-r2
[5] : Microsoft Learn(2022). Créer un cluster de basculement. https://learn.microsoft.com/fr-

fr/windows-server/failover-clustering/create-failover-cluster
[6] : Florian Burnel (2022). Cluster à basculement Hyper-V avec Windows Server 2016.
https://www.it-connect.fr/cluster-a-basculement-hyper-v-avec-windows-server-2016/
[7] : Microsoft ; Francois Dishan. Guide pas à pas : migration d’active directory de
Windows Sever 2008 R2 vers Windows Server 2022.
https://techcommunity.microsoft.com/t5/itops-talk-blog/step-by-step-guide-active-directory-
migration-from-windows/ba-p/2888117
[8] : RDR-IT (2022). Les rôles FSMO. https://rdr-it.com/les-roles-fsmo/
vi
Glossaire
• Bulle : une bulle (en anglais Bubble ou pipeline stall) est un temps d'attente lors de
l'exécution d'une instruction sur un processeur à pipeline.
• Cluster : grappe de serveurs (ou « ferme de calcul ») constituée de deux serveurs au

minimum (appelé aussi nœud) et partageant une baie de disques commune, pour assurer une
continuité de service et/ou repartir la charge de calcul et/ou la charge réseau.
• DHCP : Dynamic Host Configuration Protocol (DHCP) est un protocole client/serveur qui
fournit automatiquement une adresse Internet Protocol (IP) et d'autres informations de
configuration pertinentes à un hôte IP (par exemple, masque de sous-réseau et passerelle par
défaut).
• DSI : Direction (ou Directeur) des systèmes d’information.
• Framework : Kit de composants logiciels structurels qui sert à créer les fondations, ainsi
que les grandes lignes de tout ou partie d’un logiciel.
• Hyperviseur : plateforme de virtualisation permettant à plusieurs systèmes d’exploitation
de travailler sur une machine physique en même temps.
• LAN : de l’anglais Local Area Network ou réseau local. Ce réseau désigne par abus un
réseau d’entreprise. Il s’agit plus précisément d’un réseau comprenant des dispositifs qui
communiquent entre eux au niveau 2 du modèle OSI, soit par le biais de trames. Le protocole
IP (Internet Transport) n’est pas nécessaire à cet échelon.
• LUN : pour Logical Unit Number. Dans un réseau SAN, un LUN est le numéro
d’identification d’un espace de stockage présenté à un ou plusieurs serveurs.
• Mainframe : terme trouvant son origine dans l’informatique des années soixante, s’agissant
d’un ordinateur ultra-performant, créé pour effectuer des traitements basés. Ce sont des
serveurs de données conçus pour traiter jusqu'à 1 000 milliards de transactions Web par jour
avec les plus hauts niveaux de sécurité et de fiabilité.
• NAS : de l’anglais Network Attached Storage, pour serveur de stockage en réseau,
s’agissant d’un serveur de fichiers autonome, relié à un réseau et dont la principale fonction
est le stockage de données en un volume centralisé pour des clients réseau hétérogènes.
• RAM : de l’anglais Random Access Memory ; est la mémoire à court terme d'un ordinateur,
où sont stockées les données que le processeur utilise actuellement.
• RTO : Recovery Time Objective, peut se traduire par la durée maximale d'interruption
admissible. Il s'agit du temps maximal acceptable pendant lequel une ressource informatique
(serveur, réseau, ordinateur, application) peut ne pas être fonctionnelle à la suite d’une
interruption majeure de service.
MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com vii

• SAN : de l’anglais Storage Area Network et qui implique une mutualisation des ressources
de stockage au travers d’un réseau spécialisé permettant un accès bas niveau aux disques
utilisés ;
• SP : Société de Patrimoine du Service public de l'Eau potable, de l'Energie électrique et de
l'Assainissement.
• SSD : de l'anglais solid-state drive.
• VM : de l’anglais, Virtual Machine pour machine virtuelle.
• VMM : de l’anglais, Virtual Machine Manager pour Gestionnaire de machine virtuelle ou
plus généralement un hyperviseur.
MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com viii

Liste des figures
Figure 1: Organigramme de la DSI......................................................................................................10

Figure 2 : Architecture Système de la SP.............................................................................................11
Figure 3: Hyperviseur de type 1...........................................................................................................15
Figure 4 : Hyperviseur type 2...............................................................................................................16
Figure 5 : Virtualisation d'application..................................................................................................17
Figure 6 : Virtualisation des stockages.................................................................................................19
Figure 7 : Architecture d'un cluster de basculement.............................................................................27
Figure 8 : étapes de la phase de réalisation...........................................................................................31
Figure 9: Macro-Planning....................................................................................................................33
Figure 10 : Serveur ProLiant DL380 G10............................................................................................34
Figure 11: Migration ADDS 2008 Vers 2016.......................................................................................35
Figure 12 : Ajout SVR-AD1 dans le domaine......................................................................................35
Figure 13 : Ajout du rôle AD DS sur le serveur SVR-AD1.......................................................................36
Figure 14 : Ajout d'un contrôleur de domaine a un domaine existant...................................................36
Figure 15 : Option du contrôleur de domaine secondaire.....................................................................37
Figure 16: Rôle FSMO sur SVR-AD....................................................................................................38
Figure 17: Transfert des rôles FSMO de SVR-AD vers SVR-AD1......................................................39
Figure 18 : statut des rôles après transfert............................................................................................39
Figure 19 : Retirer SVR-AD en tant que catalogue global....................................................................40
Figure 20 : rétrograder du serveur en contrôleur à l’aide de Dcpromo.exe...........................................40
Figure 21 : Rétrogradation du serveur SVR-AD en tant que contrôleur de domaine (Suite 1).............41
Figure 24 : Façade arrière des switch HP StorageWorks 8/8................................................................43
Figure 25 : ProLiant DL380 Gen9........................................................................................................44
Figure 26 : Système petit facteur de forme vue façade arrière.............................................................45
Figure 27 : Système petit facteur de forme vue façade avant..............................................................45
Figure 28 : HP P2000 FC G3...............................................................................................................46
Figure 29 : Architecture du SAN HP P2000 FC G3.............................................................................47
Figure 30 : Connexion au switch SAN.................................................................................................49
MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com ix

Figure 31 : Fixation de l'adresse IP sur le switch 1..............................................................................49

Figure 32: Fixation de l'adresse IP sur le switch 2................................................................................49
Figure 33 : Connexion à la console web de gestion..............................................................................51
Figure 34 : Les quatre ports connectés sur le switch SAN....................................................................52
Figure 35 : Création et configuration d'un alias....................................................................................53
Figure 36 : Résumé des quatre (4) alias créés.......................................................................................53
Figure 37 : Création des zones.............................................................................................................55
Figure 38 : Création des zones.............................................................................................................56
Figure 39 : Connexion à la Baie HP2000 via le port CLI.....................................................................57
Figure 40 : Fixation des adresses IP des contrôleurs de la baie............................................................57
Figure 41 : Vérification des IP fixées...................................................................................................58
Figure 42 : Volume créé sur la HP P2000............................................................................................58
Figure 43 : Initialisation du processeur Intelligent Provisioning..........................................................60
Figure 44 : Début d'installation du système d’exploitation...................................................................60
Figure 45 : étapes 1 - Paramètres matériels..........................................................................................60
Figure 46 : étape 2 : sélection du système d'exploitation......................................................................61
Figure 47 : Etape 4 – Vérification........................................................................................................61
Figure 48 : Début de l'installation.........................................................................................................62
Figure 49 : Installation de MPIO..........................................................................................................63
Figure 50 : Découverte des chemins redondants..................................................................................63
Figure 51: Installation du rôle Hyper-V...............................................................................................64
Figure 52 : Installation la fonctionnalité clustering de basculement.....................................................64
Figure 53 : Gestionnaire du cluster de basculement.............................................................................65
Figure 54 : Lancement de l'assistant de Validation d'une configuration...............................................66
Figure 55 : Sélection des nœuds du cluster...........................................................................................66
Figure 56 : Exécution du test de validation..........................................................................................67
Figure 57 : Validation en cours............................................................................................................67
Figure 58 : Résumé du test de validation..............................................................................................68
Figure 59 : Lancement de l'assistance de création du cluster de basculement......................................68
Figure 60 : Sélection des serveurs Nœuds...........................................................................................69
Figure 61 : : Attribution de l'adresse IP au cluster de basculement.......................................................70
Figure 62 : Confirmation des paramètres avant création......................................................................70
Figure 63 : Résumé de la création du cluster........................................................................................71
Figure 64 : Affichage du gestionnaire de cluster..................................................................................71
MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com x

Figure 65 : Gestionnaire de cluster de basculement – rôle....................................................................72

Figure 66 : Gestionnaire de cluster de basculement – Nœud................................................................72
Figure 67 : Gestionnaire de cluster de basculement – Disque..............................................................73
Figure 68 : Gestionnaire de cluster de basculement – Réseau..............................................................73
Figure 69 : : Ajout du stockage Disque-VM aux volumes partagés de cluster.....................................74
Figure 70 : Volume partagé de cluster..................................................................................................75
Figure 71 : Machine virtuelle installée sur notre cluster.......................................................................75
Figure 72 : Création d'un disque Vhdx d'une machine Physique..........................................................76
Figure 73 : Image VHDX créée............................................................................................................77
Figure 74 : Liste des serveurs dans notre cluster..................................................................................77
Figure 75 : Suspension de l'hyperviseur HV2.......................................................................................78
Figure 76 : Migration à chaud des serveurs présent sur HV2...............................................................78
Figure 77 : Monitoring d’hyperviseur 1 (Noeud 1)..............................................................................80
Figure 78 : Monitoring Hyperviseur 2 (Noeud 2).................................................................................81
Figure 79: Utilisation des UC total sur chaque Hyperviseur.................................................................81
Figure 80 : Utilisation UC invitée sur chaque hyperviseur...................................................................81
MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com xi

Liste des tableaux
Tableau 1: Détails des serveurs de la SP..............................................................................................12

Tableau 2 : Identification des rôles FSMO...........................................................................................38
Tableau 3 : Identifications des alias des ports......................................................................................52
Tableau 4 : Planification zones créées..................................................................................................54
Tableau 5 : Bilan financier du projet....................................................................................................82
MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com xii

Annexe 1 : Installation et configuration Windows serveur

2019
1 – Insérer le DVD Rom ou la clé contenant les fichiers d’installation de « Microsoft

Windows Server 2019 ».
2 – Mettre l’ordinateur sous tension et démarrer sur le DVD ou la clé.
NB : Si votre ordinateur ne démarre pas sur le DVD ou la clé, pensez à modifiez les
paramètres de votre BIOS afin de démarrer sur le lecteur CD/DVD/USB avant de démarrer
sur le disque dur ou un autre périphérique.
4 – Sélectionnez la langue d’installation de votre choix et cliquez sur « Suivant » :
5 – Cliquez sur « Installer Maintenant » :
MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com xiii

5 – Sélectionnez l’édition de Windows Server de votre choix et sélectionnez une édition

avec l’expérience de bureau pour avoir une interface graphique. Cliquez ensuite sur «
Suivant » :
5 – Cochez la case pour accepter le contrat de licence et cliquez sur « Suivant » :
6 – Cliquez sur le type d’installation Personnalisé :
MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com xiv

7 – Sélectionnez le disque sur lequel installer Windows Server 2019 et cliquez sur «
Suivant » :
8 – Patientez pendant l’installation de Windows Server 2019 :
MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com xv

Annexe 2 : Installation d’une machine virtuelle dans un cluster

de basculement
Pour créer un nouvel ordinateur virtuel dans votre cluster, faites un clic droit sur Rôles et
cliquez sur : Ordinateurs virtuels -> Nouvel ordinateur virtuel
Choisissez le nœud sur lequel vous souhaitez héberger cet ordinateur virtuel.
Notez que cet assistant ci-dessous est strictement identique à celui que nous utilisons lorsque
les serveurs Hyper-V ne sont pas en cluster.
MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com xvi

Indiquez un nom pour votre machine virtuel et cochez la case : Stocker l'ordinateur virtuel à
un autre emplacement. En effet, par défaut, vos serveurs Hyper-V sont configurés pour être
stockés localement sur un de vos serveurs Hyper-V et plus particulièrement dans le dossier
"C:\ProgramData\Microsoft\Windows\Hyper-V\".
Pour que l'exécution de nos machines virtuelles puisse être basculée automatiquement d'un
nœud de votre cluster à un autre nœud du cluster, nous devons prendre l'habitude de stocker
nos ordinateurs virtuels sur un des volumes partagés de notre cluster. Nous allons alors le
stocker dans le volume partagé de cluster que nous avons créé.
MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com xvii

Sélectionnez le commutateur réseau virtuel que notre machine virtuelle devra utiliser.
Choisir la génération de votre machine virtuelle. Nous choisirons la génération 2.
MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com xviii

Définir la mémoire de notre machine virtuelle. Nous choisirons d’allouer de la mémoire de

manière statique.
Créez un disque dur virtuel pour cet ordinateur virtuel.
MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com xix

A cette étape nous devons insérer les fichiers ISO du système que nous souhaitons installer.
Un résumé de la configuration de votre ordinateur virtuel s'affiche. Cliquez sur Terminer.
MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com xx

L'assistant Nouvel ordinateur virtuel disparait et un assistant Haute disponibilité apparait

automatiquement.
Il suffit maintenant de démarrer la machine virtuelle et l’installation du système débutera.
MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com xxi

Rapport MBINA MBOUMBA Wilde

Transféré par

Informations du document

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

Rapport MBINA MBOUMBA Wilde

Transféré par

Droits d'auteur :

Formats disponibles

MEMOIRE POUR L’OBTENTION DU DIPLOME DE

Master Ingénierie Informatique, Réseaux et

THEME : VIRTUALISATION DE SERVEURS : CAS DE LA SOCIETE

Réalisé par : Wilde Kisteul MBINA MBOUMBA

Encadreur Pédagogique : Encadreur en Entreprise :

Dr. PAMBA CAPOCHICHI Eugène M. BANGOYE TITSE François

Enseignant ESGIS Directeur des Systèmes d’Informations

Année Académique : 2021-2022

MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com

MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com

MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com

Table des matières

1.1 Historique et missions de la SP...........................................................................................7

1.2 Organisation de la SP..........................................................................................................8

2. Analyse de l’existant et Problématique....................................................................................11

2.1 Architecture de l’infrastructure système existante..........................................................11

Chapitre 2 : Généralités sur les concepts de Virtualisation de serveurs...............................................12

2.2 Différents types d’hyperviseur..............................................................................................14

2.2.1 Hyperviseur de type 1...................................................................................................14

2.2.2 Hyperviseur de type 2...................................................................................................15

2.3 Domaine d’application de la virtualisation...........................................................................16

2.3.1 La virtualisation de serveurs.........................................................................................16

2.3.2 La virtualisation d’application.......................................................................................17

2.3.3 La virtualisation de stations de travail..........................................................................17

2.3.4 La virtualisation de stockage.........................................................................................18

2.4 Avantages de la virtualisation...............................................................................................20

MBINA MBOUMBA Wilde Kisteul Contact: +24174767520 E-mail: Kisteulwild@gmail.com

2.4.1 Réduction des coûts CAPEX/OPEX................................................................................20

2.4.2 Simplification du déploiement et de l’administration...................................................23

2.4.3 Gestion optimisée de l’obsolescence du matériel........................................................24

2.4.4 Simplification des tests logiciel.....................................................................................25

2.5 Techniques de Redondance dans la virtualisation................................................................26

2.5.1 Présentation du cluster de basculement......................................................................26

2.5.2 Architecture d’un cluster de basculement Hyper-V......................................................26

2.5.3 Descriptif de l’architecture d’un cluster de basculement....................................................27

Chapitre 3 : Virtualisation de serveurs : cas de la SP............................................................................29

3.2 Planning des travaux.............................................................................................................31

3.3 Installation de l’hyperviseur HV0 (ADDS et serveur Backup)......................................................34

3.3.1 Installation et configuration de l’hyperviseur HV0..............................................................34

3.3.2 Migration d’active directory 2008 vers 2016.......................................................................34

3.3.3 Installation du serveur backup.............................................................................................42

3.4 Mise en place d’un SAN HPE StorageWorks P2000 FC G3....................................................43

3.4.1 Composants de notre architecture SAN HPE StorageWorks P2000 FC G3...........................43

3.4.2 Architecture physique des HP StorageWorks 8/8 SAN Switch......................................46

3.4.3 Configuration des HP StorageWorks 8/8 SAN Switch...................................................48

3.4.4 Configuration de la baie de stockage HP P2000 FC G3.................................................56

3.5 Configuration du cluster de basculement de serveurs.........................................................64

3.5.1 Installation du rôle Hyper-V et Clustering de basculement.................................................64

3.4.2 Validation du cluster de basculement.................................................................................65

3.5.3 Création du cluster de basculement....................................................................................68

3.6 Installation des serveurs dans le cluster...............................................................................74

3.7 Conversion des serveurs physiques existants en serveurs virtuels.......................................76

3.8 Réalisation des tests de basculement...................................................................................77

Chapitre 4 : Évaluation technique et budgétaire de la solution Proposée............................................79

4.2 Évaluation budgétaire...........................................................................................................82

Chapitre 5 : Bilan.................................................................................................................................83

Le chapitre quatre décrit la performance de la solution proposée et l'évaluation budgétaire.

Chapitre 1 : Présentation de la

1. Societé de Patrimoine du service public de l'eau potable, de

1.1 Historique et missions de la SP

La Société de Patrimoine (SP) du service Publique de l'énergie électrique et de

La Société de Patrimoine est un instrument de mise en œuvre de la politique d'exploitation et

 Assister le gouvernement dans l'identification des besoins de création et le

La Société de Patrimoine fonctionne selon le mode d'organisation hiérarchique. Autrement