CONCEPTION D'UN ENVIRONNEMENT VIRTUEL POUR LE DEPLOIEMENT D'UN CENTRE DE DONNEES: CAS DE BJNet

RÉPUBLIQUE DU BÉNIN
¤¤¤¤¤¤¤¤¤¤
UNIVERSITÉ D’ABOMEY-CALAVI (UAC)
¤¤¤¤¤¤¤¤¤¤
ECOLE POLYTECHNIQUE D’ABOMEY -CALAVI (EPAC)
¤¤¤¤¤¤¤¤¤¤¤¤¤
DEPARTEMENT DE GENIE INFORMATIQUE ET
TELECOMMUNICATION (GIT)
Option : Réseaux Informatiques et Internet (RII)
MEMOIRE DE FIN DE FORMATION

POUR L’OBTENTION DU
DIPLOME D’INGENIEUR DE CONCEPTION

THEME :
Présenté par :
CONCEPTION D’UN ENVIRONNEMENT VIRTUEL POUR
Bidossessi Emmanuel AGOSSOU
LE DEPLOIEMENT D’UN CENTRE DE DONNEES : CAS
Soutenu publiquement le Vendredi 18 février 2011 devant le jury composé de :
DE BJNet
Réalisé par :
Joris Dagbégnon FAGBEMIRO
Présenté et soutenu publiquement devant le jury composé de :
Président : Capitaine Michel DOSSOU, Dr., Enseignant à l’EPAC
Membres : 1- Lieutenant Bidossessi R. ALAHASSA, Ir., Maître de mémoire
2- Dr. Médésu SOGBOHOSSOU, Enseignant à l’EPAC
3- Capitaine Firmin DONADJE, Ir.
Année Académique : 2013 – 2014
7ème Promotion
SOMMAIRE
SOMMAIRE.......................................................................................................... i
DEDICACES ......................................................................................................... ii
REMERCIEMENTS .............................................................................................. iii
LISTE DES SIGLES ET ABREVIATIONS ................................................................... v
LISTE DES TABLEAUX ........................................................................................ viii
LISTE DES FIGURES .............................................................................................ix
RESUME ............................................................................................................. x
ABSTRACT ..........................................................................................................xi
INTRODUCTION GENERALE ................................................................................ 1
CHAPITRE 1 : ETUDE DE L’EXISTANT ................................................................... 5
CHAPITRE 2 : LA VIRTUALISATION .................................................................... 13
CHAPITRE 3 : CHOIX DE LA SOLUTION DE VIRTUALISATION ............................. 26
CHAPITRE 4 : ARCHITECTURE VIRTUELLE DU CENTRE DE DONNEES ET

RECOMMANDATIONS DE DEPLOIEMENT ......................................................... 42
CHAPITRE 5 : SIMULATION ET TESTS ................................................................ 56
CHAPITRE 6 : ANALYSE ET DISCUSSION ............................................................ 64
CONCLUSION ET PERSPECTIVES ....................................................................... 68
BIBLIOGRAPHIE ................................................................................................ 69
ANNEXES .......................................................................................................... 77
GLOSSAIRE ....................................................................................................... 89
ENGLISH VERSION ............................................................................................ 91
TABLES DES MATIERES ................................................................................... 102
Réalisé par Joris Dagbégnon FAGBEMIRO i

DEDICACES
Mon père Zacharie FAGBEMIRO MARTIN,
Ma mère Rita QUENUM,
Ma sœur Fèmi Iris et son époux Victorin,
Mon frère Kayodé.
Merci de m’avoir toujours soutenu et d’avoir cru en moi.
Dagbégnon Joris FAGBEMIRO
Réalisé par Joris Dagbégnon FAGBEMIRO ii

REMERCIEMENTS
Je remercie en premier lieu le Seigneur Dieu Tout-Puissant pour

m’avoir permis d’aller jusqu’au bout du présent travail malgré les
épreuves traversées.
Je remercie aussi tous ceux qui, de près ou de loin, ont participé à la

réalisation de ce travail. Je pense particulièrement :
- Au Professeur Félicien AVLESSI, Directeur de l’Ecole

Polytechnique d’Abomey-Calavi, et à son adjoint le Professeur
Clément BONOU ;
- Au Professeur Marc Kokou ASSOGBA, chef du département de
Génie Informatique et Télécommunications et à tous les
enseignants dudit département ;
- A l’ensemble du corps enseignant de l’EPAC ;
- A mon maitre de mémoire, Ing. Bidossessi R. ALAHASSA, qui a
accepté encadrer ce travail ;
- Au feu Docteur Sèmiyou ADEDJOUMA ;
- A tout le personnel de la Direction des Transmissions et de
l’Informatique de l’Etat-Major Général des Forces Armées
Béninoises ;
Réalisé par Joris Dagbégnon FAGBEMIRO iii

REMERCIEMENTS
- A Arnaud QUENUM (Ingénieur chez NetApp en France), Gildas DA

MATHA SANT’ANNA (Ingénieur à Comtel Technologies) et tout le
personnel de Comtel Technologies ;
- Aux ingénieurs John AOGA, Brice HESSOU, Déo-Gratias SONON,
Léocady TABE, Boris DOSSA, Boris KOUMONDJI, Florentio DE
SOUZA, Oscar GBADOU, Briand IDOSSOU, Maxime HOUNTONDJI,
Lionel HOUSSOU, Marlise MONTCHO et Thierry DJOSSOU ;
- A mes camarades de la 7ème promotion, que ce soit en GIT, GE,
GME et GC ;
- Aux autres étudiants du département, en particulier Steaven,
Asser, Romaric, Gafarou, Bilquis, Juliana, Anicet, Carole, Costa,
Franck ;
- A tous les membres du club de génie en herbe de l’EPAC que j’ai
eu la joie et l’honneur de diriger ces trois dernières années ;
- A Abdias OFFRIN, Cédric MEHOU, Candide HOUNGNANDAN,
Claude CHABI, Lauraine QUENUM, Yessirath TOUKOUROU,
Maëlle HOUETO et tous mes autres ami(e)s que je ne pourrais
citer ici.
Réalisé par Joris Dagbégnon FAGBEMIRO iv

LISTE DES SIGLES ET ABREVIATIONS
C
CDDL : Common Development and Distribution License
CIPMA : Chaire Internationale Physique Mathématique et Application
CRM : Customer Relationship Management
D
DAS : Direct Attached Storage
DMZ : DeMilitarized Zone
DNS : Domain Name System
E
ERP : Enterprise Resource Planning
EPT : Extended Page Tables
G
Go : Gigaoctet
I
IBM : International Business Machines
ICMP : Internet Control Message Protocol
IMAP : Internet Message Access Protocol
iSCSI : Internet Small Computer System Interfaces
IT : Information Technology
Réalisé par Joris Dagbégnon FAGBEMIRO v

K
KVM : Kernel-based Virtual Machine
KVM : Keyboard Video Mouse
L
LVM : Logical Volume Manager
M
MAC : Medium Access Control
N
NAS : Network Attached Storage
NFS : Network File System
NIC : Network Interface Card
O
OSI : Open Systems Interconnection
P
POP : Post Office Protocol
PRA : Plan de Reprise d’Activités
R
RAM : Random Access Memory
RAID : Redundant Array of Inexpensive Disk
Réalisé par Joris Dagbégnon FAGBEMIRO vi

S
SAN : Storage Area Network
SAS : Serial Attached iSCSI
SDN : Software Defined Networking
SMB : Server Message Block
SMF : System Management Facility
SMTP : Simple Mail Transfer Protocol
SPOF : Single Point Of Failure
UCL : Université Catholique de Louvain

UAC : Université d’Abomey-Calavi
V
VLAN : Virtual Local Area Network
VNIC : Virtual Network Interface Card
VPN Virtual Private Network
Z
ZFS : Z or Zettabyte File System
Réalisé par Joris Dagbégnon FAGBEMIRO vii

LISTE DES TABLEAUX
Tableau III.I : Caractéristiques matérielles des serveurs du projet BJNet .... 28

Tableau III.IV : Tableau comparatif des techniques de virtualisation .......... 33
Tableau III.V : Récapitulatif des outils pour les serveurs, relais et pare-feux
.................................................................................................................... 40
Tableau V.I : Caractéristiques matérielles des machines virtuelles utilisées
pour la simulation ....................................................................................... 58
Tableau V.II : Plan d’adressage des zones créées pour la simulation .......... 60
Réalisé par Joris Dagbégnon FAGBEMIRO viii

LISTE DES FIGURES
Figure 1.1: Architecture physique du centre de données de BJNet .................. 11

Figure 2.1: Différence entre architecture standard et architecture virtualisée
(Source : Raynaud, 2011)................................................................................. 15
Figure 2.2: Domaines de la virtualisation ........................................................ 16
Figure 2.3: Virtualisation au sein d’un OS par isolation (source : Donnette et
Hannequin, 2007) ............................................................................................ 20
Figure 2.4: Noyau en espace utilisateur (source : Donnette et Hannequin, 2007)
......................................................................................................................... 21
Figure 2.5: Virtualisation complète: à gauche avec un hyperviseur de type 1 et
à droite avec un hyperviseur de type 2 (source: Santy, 2010) ......................... 23
Figure 2.6: Paravirtualisation (Source : VMware, 2007) .................................. 23
Figure 4.1: Première approche d’architecture ................................................. 43
Figure 4.2 : Architecture de l’environnement virtuel du centre de données de
BJNet................................................................................................................ 48
Figure 5.1: Topologie de l’environnement de simulation................................ 57
Figure 5.2 : Test d’accès réseau entre le relais inverse web et le serveur web
......................................................................................................................... 61
Figure 5.3: Test d’accès réseau entre le client et le relais inverse HTTP de la DMZ
publique ........................................................................................................... 62
Figure A - 1 : Niveau de privilège dans les processeurs de l’architecture x86 .. 79
Figure 1: Physical architecture of the datacenter ............................................ 94
Figure 2: Domains of virtualization .................................................................. 95
Figure 3 : Virtual architecture of datacenter ................................................... 98
Figure 4: Architecture of simulation ................................................................ 98
Réalisé par Joris Dagbégnon FAGBEMIRO ix

RESUME
Le déploiement du centre de données de BJNet passe par la mise en

place d’une douzaine de serveurs et relais, et de quatre pare-feux, répartis sur
quatre réseaux différents. Cependant, il n’y a de disponible qu’une seule
machine physique ayant une seule carte réseau. Le challenge est donc de
rendre possible ce déploiement de centre de données sur le seul serveur
disponible. Pour cela, nous avons opté pour les solutions de virtualisation, qui
permettent de faire fonctionner sur un seul serveur physique, plusieurs autres
serveurs en simultané, mais aussi de les mettre en réseau. Nous avons donc
conçu un environnement de virtualisation pour le déploiement des serveurs
de ce centre de données. Pour cela, nous avons comparé les outils à utiliser
pour fournir ces services, ainsi que les diverses techniques et solutions de
virtualisation et avons choisi de combiner la virtualisation au sein d’un OS
(utilisation des zones Solaris) et la virtualisation complète. Les solutions de
virtualisation choisies sont le système d’exploitation OpenIndiana et
l’hyperviseur de type 2 VirtualBox. Nous avons donc, à la base de ceux-ci,
conçu l’architecture de cet environnement virtuel qui intègre à la fois les
aspects systèmes et réseaux et avons, pour finir, fait des recommandations
pour un déploiement sûr et efficace. Les résultats de notre simulation ont
montré, qu’en plus d’être fonctionnelle et de satisfaire aux contraintes, notre
architecture est extensible et peut donc couvrir des besoins futurs d’ajout de
serveurs.
Mots-clés : virtualisation, Zones Solaris, OpenIndiana, CrossBow
Réalisé par Joris Dagbégnon FAGBEMIRO x

ABSTRACT
The deployment of the datacenter of BJNet calls for the set up of a dozen of
servers and relays, and four firewalls, distributed over four different
networks. However, only a single physical machine which have one network
card is available. So the challenge is to make possible the deployment of this
datacenter on this server. To address this problem, we have opted for
virtualization’s solutions that allow to run on a single physical server, several
servers simultaneously, but also to network them. So we have designed a
virtualization environment for deploying servers in this data center. For this,
we have compared the tools which will be used to provide these services, as
well as various virtualization’s technics and solutions and have chosen to
combine virtualization within an OS (by the use of Solaris zones) and full
virtualization. Selected virtualization’s solutions are the operating system
OpenIndiana and type 2 hypervisor VirtualBox. So, based on that, we have
designed the architecture of this virtual environment that integrates both
aspects of systems and networks and, finally, makes recommendations for a
safe and efficient deployment. The results of our simulation have shown that,
in addition to being functional and respectful of constraints, our architecture
is scalable and can therefore cover future needs for adding servers.
Keywords: virtualization, Solaris Zones, OpenIndiana, CrossBow
Réalisé par Joris Dagbégnon FAGBEMIRO xi

INTRODUCTION GENERALE
Les systèmes informatiques modernes sont construits autour d’une

architecture client-serveur où des équipements légers, les clients, viennent
chercher des données et utiliser des services fournis par un ou des serveurs
et cela au travers d’un réseau. Il peut s’agir, en termes de services, de
stockage de données, de consultation et d’envoi de mails, d’utilisation
d’applications pour le calcul ou la gestion (ERP, CRM,…)1, etc. Pour la
fourniture de ces services, il a longtemps été d’usage de dédier un serveur à
un service. Ce modèle empêchait ainsi que la défaillance d’un serveur
n’entraîne l’indisponibilité de tous les services ; mais nécessitait de grands
moyens financiers, pour l’acquisition des serveurs et des équipements
réseaux, leur exploitation (alimentation, refroidissement) et leur
maintenance. De plus, le taux d’utilisation de ces serveurs allait de 5%
(VMWare, 2014) à 20% en moyenne (Sekkaki, 2007). C’est dans l’optique de
mieux utiliser les ressources des serveurs et de réduire les moyens nécessaires
à la mise en place de services, que s’est popularisé l’usage de la virtualisation.
Cette technologie existait déjà depuis les années 1960, mais était surtout
utilisée sur les mainframes2 comme ceux d’IBM3 (Hess et Newman, 2010).
C’est dans les années 2000 que cette technologie a commencé à être
populaire auprès du grand public. Elle a apporté au monde de l’informatique
nombre de nouvelles opportunités ; en plus de celle permettant de faire
fonctionner plusieurs serveurs sur un nombre réduit de machines physiques,
1
ERP : Enterprise Resource Planning ; CRM : Customer Relationship Management
2
Issus de l’informatique centralisée des années 1960, les mainframes sont d’imposants et puissants ordinateurs
qui centralisent les données et les traitements d’un système d’information ; et où les clients qui se connectent
sont généralement de simples terminaux informatiques, généralement passifs.
3
IBM : International Business Machines Corporation est une multinationale américaine présente dans les
domaines du matériel et des services informatiques et du logiciel.
Réalisé par Joris Dagbégnon FAGBEMIRO 1

voire même une seule machine physique (Singh, 2004). Il s’agit d’une
technologie à la portée de tous, du particulier qui souhaite exécuter en toute
sécurité une distribution Linux sur sa plate-forme Windows, aux grandes
entreprises qui souhaitent rentabiliser davantage leur infrastructure
informatique (Santy, 2010).
1. Contexte, justification et problématique

BJNet est un réseau d’infrastructures permettant l’interconnexion de
toutes les structures de l’administration publique, notamment de l’Université
et la Défense. En outre, le réseau peut fournir un accès à Internet à toutes
structures exploitant ses infrastructures. Ce réseau est national ; ses
infrastructures sont donc présentes dans tous les départements et couvre une
bonne partie des communes du Bénin.
BJNet souhaite offrir aussi à ses clients, outre l’interconnexion et l’accès à

Internet, certains services additionnels comme le DNS (Domain Name
System), l’hébergement de sites web, le mail, etc.
Il lui faut donc se doter d’un certain nombre de serveurs, regroupés au sein
d’un centre de données, qui accompliront ces tâches. Lesdits serveurs seront
évidemment regroupés en un réseau informatique, et dans le cas de BJNet, il
s’agit en l’occurrence de quatre réseaux distincts interconnectés.
Cependant, le projet ne dispose que de deux serveurs physiques, qui

fonctionneront en cluster, c’est-à-dire que les services déployés sur l’un
seront répliqués à l’identique sur l’autre. On peut donc considérer que, pour
le déploiement des serveurs (répartis sur quatre réseaux différents et
hébergeant des services fonctionnant sous divers systèmes d’exploitation)

constituant le datacenter de BJNet, on ne dispose que d’un serveur physique.

La virtualisation se présente donc comme la seule solution à cette
problématique.
C’est donc dans le cadre de l’utilisation de la virtualisation, pour le

déploiement du centre de données de BJNet, que s’inscrit notre présent
travail de fin d’études.
2. Objectifs
Le principal objectif visé par ce travail est de concevoir l’environnement
de virtualisation pour le déploiement du centre de données de BJNet.
Plus spécifiquement, il s’agira pour nous :
 de choisir, à la lumière des contraintes spécifiques au contexte d’étude,

les outils pour la fourniture des services, la technique et la solution de
virtualisation la plus idoine ;
 de concevoir l’architecture virtuelle globale des serveurs à déployer;
 et de faire des recommandations pour un déploiement efficace.
Le présent mémoire fait le point de nos travaux et comprend six chapitres:
 Les deux premiers nous permettront de mieux présenter le centre

de données de BJNet à mettre en place et de faire ensuite l’état de
l’art sur la virtualisation ;
 Le troisième présentera les aspects techniques pris en considération
quant au choix des outils à utiliser sur les serveurs, de la technique
et de la solution de virtualisation à utiliser ; et le quatrième sera

consacré à la conception de l’architecture virtuelle des serveurs à

déployer ;
 Les deux derniers chapitres seront consacrés à une simulation de
notre environnement proposé et à une analyse critique dudit
environnement.
Enfin, nous conclurons par un point de nos travaux et par la proposition

de perspectives.

1. CHAPITRE 1 : ETUDE DE L’EXISTANT
CHAPITRE
ETUDE DE

L’EXISTANT
5
CHAPITRE 1 : ETUDE DE L’EXISTANT
1.1 Présentation du projet BJNet

BJNet est un projet initié, dans le cadre de la coopération entre
l’Université Catholique de Louvain (UCL) et l’Université d’Abomey-Calavi
(UAC), par deux professeurs. D’une part, le Professeur Marc LOBELLE, Colonel
de Réserve de l’Arme des Transmissions dans l’Armée Belge et Professeur à
l’Université Catholique de Louvain ; et d’autre part, le Professeur Norbert
HOUNKONNOU, Président de la Chaire Internationale Physique
Mathématique et Application (CIPMA) et coordonnateur du projet au Bénin.
Ce projet vise la modernisation de l’Administration publique par la mise

en place d’un réseau pour l’interconnexion entre ses principales structures.
Cette interconnexion se fait avec de la fibre optique et des faisceaux hertziens.
Dans son modèle de déploiement, BJNet base le cœur du réseau sur les
tronçons de fibre optique de Bénin Télécoms S.A. qui, met à la disposition de
BJNet, une paire de fibre noire que BJNet se charge d’alimenter avec ses
propres équipements. Au regard du budget et tenant compte de la faisabilité
dans les délais impartis, BJNet interconnecte certaines structures avec des
fibres acquises sur fonds propre. Ainsi, la Faculté des Sciences de la Santé, le
campus d’Abomey-Calavi, le Ministère de la Défense Nationale et le campus
du camp Guézo sont entièrement interconnectés en fibre optique. Les autres
entités sont interconnectées en faisceaux hertziens.
Ce réseau est national, car les structures à interconnecter sont

présentes dans tous les départements du Bénin.

1.2 Intérêt de la mise en place d’un centre de

données
Ce projet est d’un grand intérêt, surtout pour l’enseignement, car il
apporte une solution au problème d’insuffisance d’enseignants et de
ressources didactiques dans les centres universitaires. En effet, parmi la
vingtaine de centres universitaires répartis sur le territoire, les campus
universitaires de Calavi et Parakou ont plus d’enseignants et de supports
pédagogiques que les autres. BJNet, grâce à l’interconnexion envisagée,
permettra à ces autres centres universitaires de bénéficier de la mutualisation
desdites ressources. Ainsi, les applications qui seront développées, comme la
plate-forme d’apprentissage à distance, permettront de juguler largement le
déficit d’enseignants. De plus, ce réseau permettra d’améliorer la coopération
entre les universités.
Le projet BJNet, afin de satisfaire pleinement son objectif

d’interconnexion des structures sus-mentionnées, se doit de mettre en place
un service de base : le DNS. En effet, cela permettra aux utilisateurs du réseau
d’employer des noms symboliques plutôt que les adresses IP afin de
communiquer.
Outre cela, BJNet mettra en place les services à valeur ajoutée suivants :
- Service de mail,
- Hébergement de sites web,
- Transfert de fichiers.

Et envisage ultérieurement de :
- Mettre en place un cache de Google,
- S’inscrire comme un nœud du réseau Eduroam au profit des universités,
- etc.
Il faudra donc, pour fournir ces services mettre en place des serveurs et
les mettre en réseau afin qu’ils puissent stocker, traiter et servir les données
aux utilisateurs. La mise en place de ce centre de données permettra donc de
centraliser, faire fonctionner et gérer de manière convenable lesdits serveurs.
1.3 Architecture physique du centre de

données de BJNet
La fourniture des services DNS, de mail et d’hébergement web par BJNet
ne consistera pas seulement à mettre en place les serveurs remplissant ces
fonctions.
En effet, outre les services à offrir, le réseau est tenu de garantir une
certaine sécurité à ses clients. Cela passe donc par la mise en place de
solutions de sécurité, en l’occurrence des pare-feux ; mais cela passe aussi par
la mise en place de DMZ (DeMilitarized Zone) qui servira d’interface entre les
serveurs proprement dits et les utilisateurs. Les concepteurs de l’architecture
physique du centre de données ont, pour accroître la sécurité, choisi de
mettre en place deux DMZ : une pour les utilisateurs accédant au centre de
données depuis le réseau BJNet et une pour ceux y accédant depuis d’autres
réseaux, en l’occurrence Internet.

Aussi, afin de mieux administrer les divers serveurs à mettre en place, le

centre de données sera équipé d’outils d’administration et de surveillance
réseau et système (Dude, Nagios et OpenVAS)4. Ces outils permettent de faire
des mises à jour groupées et automatiques, d’établir une cartographie du
réseau, générer des alertes en cas de dysfonctionnement, configurer à
distance les équipements, faire des scans de vulnérabilités, générer des
rapports de fonctionnement, etc. Ces outils seront regroupés au sein d’un
réseau : le Centre d’Administration Réseau.
Enfin, pour garantir une certaine disponibilité de ses services, le centre de

données de BJNet sera réparti sur deux sites, disposant chacun d’un serveur
physique. Le cluster ainsi mis en place permet de mettre en œuvre deux
fonctionnalités :
- augmentation de la puissance de traitement : les requêtes des clients

ne seront pas toutes traitées par la même machine ;
- augmentation de la disponibilité : les inconvénients liés aux pannes
seront minimisés par la redondance des machines entre elles.
Les services seront donc déployés à l’identique sur les deux sites, et
fonctionneront en primaire sur l’un et en secondaire sur l’autre. Nous avons
donc pris pour principal cas d’étude, le serveur de l’un des sites, étant
entendu que tout ce qui se fera sur ledit serveur sera répliqué sur le serveur
de l’autre site.
4
Site officiel Dude : http://www.mikrotik.com/thedude (consulté le 16 Décembre 2014)
Site officiel Nagios : www.nagios.org (consulté le 16 Décembre 2014)
Site officiel OpenVAS : www.openvas.org (consulté le 16 Décembre 2014)

L’architecture physique du centre de données du réseau BJNet est

présentée à la figure 1.1 de la page suivante.
On note que pour atteindre les objectifs de sécurité et de disponibilité,

les serveurs, pare-feux et outils de monitoring sont répartis sur quatre
réseaux distincts : celui du centre d’administration réseau, celui de la DMZ
publique, celui de la DMZ privée et celui du réseau de données critiques qui
regroupe les serveurs de mails, web et de bases de données.

Figure 1.1: Architecture physique du centre de données de BJNet

1.4 Les contraintes liées au centre de données

de BJNet
L’architecture physique présentée ci-dessus semble induire un
déploiement basé sur le modèle « un serveur physique pour un service ».
Le projet BJNet ne dispose cependant que de deux serveurs qui seront

utilisés à raison de un par site et voudrait utiliser le plus possible des outils
libres et/ou open-source.
De plus, l’outil Dude ne fonctionnant que sous Windows et le serveur

OpenVAS ne fonctionnant que sous un système GNU/Linux, on se rend
compte que plus d’un système d’exploitation seront utilisés dans le centre de
données.
En conclusion, le centre de données de BJNet, afin de fournir efficacement

les services prévus par ce réseau, se caractérise par la présence de plusieurs
serveurs, relais et pare-feux, avec différents systèmes d’exploitation tournant
sur ceux-ci et répartis sur quatre réseaux distincts (2 DMZ, un réseau de
données critiques et un centre d’administration réseau). Cependant, le réseau
ne disposant que de deux serveurs physiques (un par site) pour ce
déploiement, il faut donc se tourner vers la virtualisation afin de mettre en
place les divers éléments et les réseaux par lesquels ils sont interconnectés.
En effet, la virtualisation a été reliée aux serveurs dans la perspective d’une
meilleure utilisation des ressources physiques (Emerson, 2010).

2. CHAPITRE 2 : LA VIRTUALISATION
CHAPITRE
LA
VIRTUALISATION

13
CHAPITRE 2 : LA VIRTUALISATION
La virtualisation est un outil qui change radicalement l’approche de

l’informatique en repoussant les limites de nos ordinateurs. Elle s’est de plus
en plus imposée dans les parcs de serveurs, les systèmes de stockage et les
réseaux des organisations (Techini, 2011).
2.1 Concepts de la virtualisation

La virtualisation fait référence à l’abstraction physique des ressources
informatiques (Hess and Newman, 2010) ; elle est un framework ou une
méthodologie de division des ressources d’un ordinateur en de multiples
environnements d’exécution, par l’application d’un ou plusieurs concepts ou
technologies comme le partitionnement du matériel et du logiciel, le temps
partagé, la simulation partielle ou complète de machine, l’émulation, la
qualité de service et beaucoup d’autres (Singh, 2004). La virtualisation est la
création d’une version virtuelle d’un système d’exploitation, d’un serveur,
d’un appareil de stockage ou de ressources réseaux.
Nous voyons que la virtualisation repose sur trois éléments importants

(Santy, 2010) :
 l’abstraction des ressources informatiques ;

 la création d’environnements virtuels ;
 la répartition des ressources par l’intermédiaire de différents outils,
de manière à ce que celles-ci puissent être utilisées par plusieurs
environnements virtuels ;
A partir de ces trois concepts fondamentaux, on peut donner la
définition suivante :

La virtualisation est un processus qui va permettre de masquer les

caractéristiques physiques d’une ressource informatique de manière à
simplifier les interactions entre cette ressource et d’autres systèmes, d’autres
applications et les utilisateurs (Santy, 2010).
En d’autres termes, les ressources allouées à une machine virtuelle sont

fournies à partir de leurs équivalents physiques. Les disques virtuels,
interfaces réseau virtuelles, réseaux locaux virtuels, commutateurs virtuels,
processeurs virtuels et la mémoire virtuelle correspondent tous à des
ressources physiques sur des systèmes informatiques physiques (Hess and
Newman, 2010).
Ainsi, la virtualisation permet de:

- diviser une ressource physique (serveur, système d’exploitation,
périphérique de stockage) en plusieurs ressources logiques (comme sur la
figure 2.1 ci-dessous),
- agréger plusieurs ressources physiques (périphériques de stockage,

serveurs) en une ressource logique.
Figure 2.1: Différence entre architecture standard et architecture virtualisée (Source :

Raynaud, 2011)

2.2 Domaines de la virtualisation

Le mot « virtualisation » a longtemps sous-entendu la virtualisation au
niveau des serveurs. Cependant, la virtualisation est partout dans le monde
informatique et n’impacte pas seulement les serveurs.
Aujourd’hui la virtualisation, comme montré sur la figure 2.2, impacte trois

domaines principalement : les systèmes (regroupant les côtés client et
serveur), le stockage et le réseau.
Figure 2.2: Domaines de la virtualisation
Au niveau du réseau, les principales tendances sont : le VPN (Virtual

Private Network), le VLAN (Virtual Local Area Network), le SDN (Software
Defined Networking) et le “Network in a box“.
L’utilisation des VLAN est déjà, depuis longtemps, présente dans le

monde informatique et permet une segmentation logique d’un réseau de
plusieurs machines. L’abstraction étant faite au niveau des couches 2 ou 3 du
modèle OSI, on distingue des port-based VLAN, MAC address-based VLAN,
Network address-based VLAN et des protocol-based VLAN (Santy, 2010).

Le VPN est un réseau dont les ressources sont partagées entre plusieurs
utilisateurs, de telle sorte que chaque client ait l’impression d’avoir un réseau
dédié et non partagé (Pujolle, 2006). On distingue les VPN d’entreprise et les
VPN d’opérateurs.
Le SDN est, par contre, une technologie récente de virtualisation réseau

où le contrôle du réseau est découplé du réseau lui-même et est directement
programmable. La migration de ce contrôle, autrefois bien ancré dans chaque
équipement réseau, dans les équipements informatiques permet
l’abstraction du matériel sous-jacent, du point de vue des applications et
services réseau, qui peuvent traiter le réseau comme une entité virtuelle ou
logique (ONF, 2012).
Enfin, le “Network in a box“ est un concept où l’entièreté du réseau

(équipements réseau et machines connectées) est virtualisée. Cela passe par
la création de carte réseau virtuelle, de switch virtuel, de machines virtuelles
(faisant office de routeur, pare-feux, etc.) (Tripathi et al. 2009),... Parmi les
outils offrant ces fonctionnalités, on peut citer Crossbow5, Open vSwitch6.
La virtualisation de stockage est le processus qui va séparer la

présentation logique et la réalité physique de l’espace de stockage (Santy,
2010). Le LVM (Logical Volume Manager) consiste à regrouper des disques
physiques ou partitions (appelés volumes physiques) en un seul grand espace
(appelé groupe de volumes) dans lequel vous pouvez découper des espaces
logiques à volonté (appelés volumes logiques), les agrandir, les réduire, etc.
Le SAN (Storage Area Network) et le NAS (Network Attached Storage) sont
5
Site officiel du projet : http://www.opensolaris.org/os/project/crossbow (consulté le 16 Décembre 2014)
6
Site official: www.openvswitch.org (consulté le 16 Décembre 2014)

des espaces de stockage accessibles par le réseau (par le biais de protocole

comme NFS, SMB7, Fibre Channel, etc.) mais qui apparaissent localement
attachés au serveur.
Quant à la virtualisation appliquée au domaine des systèmes, nous

regroupons sous ce terme les technologies de virtualisation s’appliquant aux
applications et aux systèmes d’exploitation. On emploie le terme
virtualisation côté client (ou simplement virtualisation client) lorsque lesdits
systèmes d’exploitations ou applications virtuels sont destinés à être utilisés
par un utilisateur lambda (grâce à un ordinateur de bureau ou un ordinateur
portatif) au sein d’un système informatique (en un mot par un client) ; lorsque
le système d’exploitation ou l’application virtuelle est destinée à être utilisé
par le ou les administrateurs dudit système informatique pour fournir des
services, on parle de virtualisation côté serveur ou simplement virtualisation
serveur.
2.3 Différentes techniques de virtualisation

système
Comme nous l’avions déjà dit précédemment, la virtualisation système
regroupe les technologies de virtualisation ayant trait aux applications et aux
systèmes d’exploitation.
7
NFS: Network File System; SMB : Server Message Block

2.3.1 Approches centrées sur les applications
Désignés sous les termes de machine virtuelle de processus (Laarouchi,

2009), de virtualisation au niveau applicatif (ANSSI, 2012) ou encore de
virtualisation au sein d’un OS8 (Donnette et Hannequin, 2007), ces approches
ciblent une application et lui présentent une couche d’abstraction
correspondant à son environnement d’exécution.
Les méthodes mises en œuvre ici sont l’émulation et le cloisonnement

(ou isolation).
2.3.1.1 L’émulation
L'émulation consiste à imiter le comportement d’une entité en

présentant aux couches supérieures une interface logicielle caractéristique du
fonctionnement de cette entité, indépendamment de l’architecture
matérielle sous-jacente. Elle est intéressante quand la cible doit s’exécuter sur
de nombreux environnements différents, la couche d’abstraction réalisant le
travail d’adaptation nécessaire au profit des applications qui deviennent ainsi
portables (ANSSI, 2012).
Les solutions de virtualisation telles que Citrix Application Stream

(Citrix), Symantec Workspace Virtualization (Symantec), App-V (Microsoft)
sont des exemples de virtualisation applicative utilisant cette technique. Les
solutions de virtualisation s’appuyant sur des moteurs d’exécution, telles que
Java Virtual Machine, .NET Framework entrent également dans cette
catégorie (ANSSI, 2012).
8
OS : Operating System

2.3.1.2 Le cloisonnement (virtualisation au sein d’un OS)
Le cloisonnement est quant à lui mis en place dans un but d’isolation ou

de confinement. Un isolateur est un logiciel permettant d'isoler l'exécution
des applications dans des contextes ou zones d'exécution. L'isolateur, comme
on peut le voir sur la figure 2.3 ci-dessous, permet ainsi de faire tourner
plusieurs fois la même application prévue pour ne tourner qu'à une seule
instance par machine. Notons que cette technologie consiste en quelque
sorte à généraliser la notion de "contexte" Unix9 (Donnette et Hannequin,
2007).
Figure 2.3: Virtualisation au sein d’un OS par isolation (source : Donnette et

Hannequin, 2007)
Les technologies Linux Vserver, BSD jails (« chroot »), OpenVZ ou Zone
Solaris mettent en œuvre des zones isolées (cloisonnées) gérées par le
système d’exploitation.
9
Le contexte d’un processus est l’ensemble des données qui permettent de reprendre l’exécution d’un processus
qui a été interrompu.

2.3.2 Approches centrées sur les systèmes

Désignées sous les termes de machines virtuelles de système ou
virtualisation au niveau système, ces approches visent un système
d’exploitation et lui présentent une couche d’abstraction correspondant à un
environnement matériel compatible.
Les méthodes mises en œuvre ici sont le cloisonnement, la virtualisation
complète, la paravirtualisation et la virtualisation assistée par le matériel.
2.3.2.1 Le cloisonnement (virtualisation au sein d’un OS)
Cette approche est semblable à celle présentée au 2.3.1.2 par utilisation

d’environnements cloisonnés.
On peut donc aller du simple « emprisonnement » dans un
environnement volontairement minimal à une image complète du système
accessible uniquement au processus isolé (Bonnet, 2008). On est ainsi plus
proche d’une machine virtuelle que d’une simple isolation de processus. Dans
ce cas un noyau hôte se charge de l'ordonnancement10 des différents noyaux
en espace utilisateur (Laarouchi, 2009) (voir figure 2.4 ci-dessous).
Figure 2.4: Noyau en espace utilisateur (source : Donnette et Hannequin, 2007)
10
L’ordonnancement suggère ici la mise en place d’un ordre d’exécution des requêtes des divers noyaux.

La principale contrainte de ce modèle de virtualisation réside dans le fait que

les systèmes invités doivent impérativement être du même type que le
système hôte (Santy, 2010).
2.3.2.2 La virtualisation complète

Egalement appelée modèle de machine virtuelle (Santy, 2010), la
virtualisation complète ou totale (full virtualization en anglais) consiste à
émuler l’intégralité d’une machine physique pour le système invité. Le
système invité «croit» s’exécuter sur une véritable machine physique
(Donnette et Hannequin, 2007). Cette technique se base sur deux principes :
celui de la traduction binaire des instructions que le noyau du système invité
souhaite exécuter et l’exécution directe des instructions relatives aux
applications utilisateurs (Santy, 2010).
La couche applicative chargée de la gestion des machines virtuelles se

décline en deux types présentés sur la figure 2.5 à la page suivante.
Le premier type est celui où ladite couche s’installe à la place du
système d’exploitation, c’est-à-dire directement sur le matériel. On parle dans
ce cas d’hyperviseur de type 1 ou d’hyperviseur “bare-metal“. Les solutions
utilisant ce type d’hyperviseur pour de la virtualisation totale sont : vSphere
(anciennement ESXi Hypervisor) de VMware, KVM, etc.
Le second type est celui où cette couche applicative s’exécute au sein
d’un OS hôte et est vu par celui-ci comme une application (Laarouchi, 2009).
Dans ce cas, ce logiciel est appelé Moniteur de Machines Virtuelles (MMV)
(VMM en anglais) ; on le désigne couramment cependant sous le terme
d’hyperviseur de type 2. Les solutions utilisant cette technique sont : VMware
Workstation, VirtualBox d’Oracle, Hyper-V de Microsoft, Qemu, etc.

Figure 2.5: Virtualisation complète: à gauche avec un hyperviseur de type 1 et à droite

avec un hyperviseur de type 2 (source: Santy, 2010)
2.3.2.3 La paravirtualisation
La technique de paravirtualisation ne nécessite pas de simuler le
matériel, mais implique une modification du système invité (Primet, Mornard
et Gelas, 2007). Elle consiste pour le système d’exploitation virtualisé à
communiquer plus efficacement avec l’hyperviseur (de type 1) de manière à
accroître les performances du système. La modification du noyau permet de
remplacer les instructions non virtualisables par des hyper-appels (hypercalls)
qui vont communiquer directement avec l’hyperviseur (Santy, 2010) comme
montré sur la figure 2.6 ci-dessous :
Figure 2.6: Paravirtualisation (Source : VMware, 2007)

Les solutions implémentant ce genre de technique sont XenServer de

Citrix, vSphere de VMware, HyperV de Microsoft, …
2.3.2.4 La virtualisation assistée par le matériel

La nécessité de développer des solutions de virtualisation assistées par
le processeur a fait son apparition avec la prolifération des systèmes à base
d’architecture x8611. Cette architecture, à l’origine se prêtait très mal à la
virtualisation (confère Annexe A) et nécessitait un travail considérable de la
part de l’hyperviseur. A l’aide de la virtualisation matérielle, l’hyperviseur est
en mesure de virtualiser correctement l’ensemble des instructions de
l’architecture x86, y compris celles posant problème (Santy, 2010).
Les deux principaux fabricants de processeurs sur le marché, Intel et
AMD, ont inauguré une nouvelle gamme de processeurs incluant une
technologie d’aide matérielle à la virtualisation. Cette technologie est connue
sous le nom de Intel VT-x (anciennement Vanderpool) et AMD-V
(anciennement Pacifia) (Santy, 2010).
Ce mode de virtualisation peut être utilisé en complément des

techniques précédentes.
2.4 Avantages de la virtualisation

Au cours des dernières années, la virtualisation semble s’être imposée
comme un élément incontournable au sein des entreprises et ce sont
principalement les serveurs qui sont au centre de toutes les attentions.
La virtualisation présente les avantages suivants (Santy, 2010) :
 Optimisation de l’infrastructure informatique- réduction des coûts liés

à l’exploitation des centres de données ;
 Amélioration de l’impact écologique des centres de données
(démarche « green IT ») ;
11
x86 désigne l’architecture des processeurs de Intel et AMD notamment. Cette désignation est due au fait que
ces processeurs sont compatibles avec le jeu d’instruction de l’Intel 8086.

 Facilité de mise en place d’environnements de tests ;

 Augmentation de la disponibilité du matériel et des applications pour
une amélioration de la continuité d'activité ;
 Facilité de mise en place d’un Plan de Reprise d’Activité (PRA) ;
 Souplesse et réactivité dans la gestion au quotidien ;
 Amélioration de la sécurité au niveau des postes clients mais aussi au
niveau des serveurs ;
 Amélioration de la flexibilité et de la compatibilité
 Etc.
2.5 Limites à la virtualisation

Les solutions de virtualisation sont donc très intéressantes au vu de la
consolidation de serveurs, de la réduction de taille des centres de données et
du coût qu’elle entraîne. Cependant, il y a certains points qui limitent
l’immense engouement que suscite cette technologie (Santy, 2010) :
 le besoin de capacité de stockage
 la présence d’un point de défaillance unique
 un problème de standardisation
 etc.
La virtualisation est donc une technologie qui, malgré ses limites a de

nombreux avantages et applications ; surtout en ce qui concerne l’utilisation
d’un petit nombre de serveurs physiques pour mettre en place plusieurs
serveurs opérationnels différents. Nous allons, dans le chapitre suivant,
comparer les diverses solutions qu’elle nous offre afin de dégager la (ou les)
plus adéquate(s) pour le déploiement des serveurs du centre de données de
BJNet.

3. CHAPITRE 3 : CHOIX DE LA SOLUTION DE VIRTUALISATION
CHAPITRE
CHOIX DE LA
SOLUTION DE

VIRTUALISATION
26
CHAPITRE 3 : CHOIX DE LA SOLUTION DE VIRTUALISATION
Dans les chapitres précédents, nous avons présenté plus en détail le

centre de données de BJNet ; mais nous avons aussi présenté l’état de l’art
sur la virtualisation, technologie qui offre entre autres intérêts celui de
pouvoir faire fonctionner simultanément plusieurs serveurs sur une seule
machine physique. Il s’agira dans ce chapitre de présenter les choix
techniques effectués pour pouvoir choisir la solution de virtualisation la plus
adéquate pour le déploiement de ce centre de données ; ainsi que les outils à
utiliser sur les serveurs.
Le choix de la solution de virtualisation idoine étant crucial pour un

projet de virtualisation, il convient de prendre en compte un certain nombre
de paramètres comme le matériel de la machine hôte, l’approche de
virtualisation adéquate, etc. En effet, chaque type de virtualisation a ses
avantages et inconvénients qui conditionnent l’application qui en est faite
(Kolyshkin, 2006). La démarche suivie est la suivante :
- présentation des caractéristiques du serveur,

- comparaison entre les approches de virtualisation et choix des plus
adéquates,
- choix des solutions de virtualisation à employer pour le déploiement,
- et choix des outils à utiliser sur les serveurs.
3.1 Présentation des caractéristiques de la

machine hôte
Le matériel sur lequel va être déployée une solution de virtualisation
joue un grand rôle dans le choix de ladite solution (Golden, 2008). En effet, les
caractéristiques du serveur peuvent orienter dans le choix d’une solution de

virtualisation. Que ce soit la mémoire physique disponible, la quantité de RAM

(Random Access Memory)12 disponible, le nombre de processeurs et le
nombre de cœurs par processeur ou le nombre de cartes réseau, tous ces
paramètres influencent la couche applicative de virtualisation à utiliser, le
nombre de machines virtuelles qu’on peut créer et aussi le nombre de
machines virtuelles pouvant fonctionner simultanément.
Le tableau suivant récapitule les caractéristiques des serveurs du projet

BJNet :
Tableau III.I : Caractéristiques matérielles des serveurs du projet BJNet
CARACTERISTIQUES VALEURS
Marque Chenbro
Type RM 217 2U
AMD Opteron 4170 Lisbon 64 bits (x
Processeur
2)
Nombre de cœurs par processeur 6
Support matériel de la virtualisation Oui (AMD-V)
RAM 8 Go13
Disque Dur 2 To14

Intel 82574L Gigabit Ethernet (x2)
Ports RJ 45 ASMB4-iKVM port (x1)
SAS RAID Controller port (x1)
12
La RAM est la mémoire principale de l’ordinateur où sont chargées les données et les instructions des
programmes que l’on désire exécuter, ainsi qu’une partie du système d’exploitation nécessaire au bon
fonctionnement de l’ordinateur (Zanella et Ligier, 2008).
13
Go : Gigaoctet (Go) égal à 1000 Mo dans le Système International (BIPM, 2014)
14
To : Téraoctet

L’un des ports RJ45 Intel est celui qui sera utilisé par les services et
l’autre est dédié à l’administration du serveur. Le port ASMB4-iKVM (Asus
Server Management Board-internet Keyboard Video Mouse) est fonctionnel
seulement quand on installe une carte ASMB4 permettant de connecter le
serveur à un switch KVM15 ; et le dernier port permet, au travers du réseau de
se connecter au contrôleur RAID (Redundant Array of Inexpensive Disks) des
disques SAS (Serial Attached SCSI)16 du serveur.
Le choix de la bonne solution de virtualisation dans l’absolu est très

difficile, et la pléthore d’offres de virtualisation disponibles (VMWare vSphere
Hypervisor, VMWare Workstation, Oracle VM VirtualBox, Microsoft Virtual
PC, Microsoft HyperV, Citrix Xen Server, Citrix XenApp, ProxMox VE, Solaris
Zones, KVM, Parallels Desktop, Linux-VServer, OpenVZ, etc.) ne facilite pas la
décision. C’est pourquoi il est nécessaire de réduire le champ d’étude aux
solutions applicables dans un cas bien spécifique (Bonnet, 2008). Notre cas ici
est celui de l’utilisation de solutions libres pour la virtualisation de serveurs,
répartis sur 4 réseaux différents, avec des distributions UNIX/Linux comme
systèmes d’exploitation dominants.
15
Un switch KVM est un équipement permettant de contrôler plusieurs serveurs à partir d’un seul ensemble de
clavier, écran et souris.
16
Le SAS est une technique d’interface pour disque dur, qui apporte le mode de transmission en série et constitue
une amélioration des bus SCSI (Small Computer System Interfaces) en termes de performances.

3.2 Choix des techniques de virtualisation

adéquates
3.2.1 Comparaison entre les techniques de virtualisation
Les critères sur lesquels nous avons basé notre comparaison entre les
techniques de virtualisation sont les performances qu’elles offrent, les
systèmes d’exploitation supportés nativement et la demande en ressources
matérielles de l’hôte.
3.2.1.1 La virtualisation au sein d’un OS ou cloisonnement
Ce type de virtualisation est essentiellement utilisé sur les systèmes

UNIX et Linux (Benkemoun et Hinfray, 2008).
L’intérêt de cette technique réside principalement dans le fait qu’elle

offre les meilleures performances17, c’est-à-dire qu’elles sont très proches de
celle d’un système natif (Kolyshkin, 2006), et il y a un net gain en sécurité et
simplicité d’administration du fait de la séparation entre les systèmes invités
(Bonnet, 2008). Les systèmes invités se basant tous sur le même noyau que
celui du système hôte, ce noyau n’est chargé en RAM qu’une seule fois ; il est
donc possible d’exécuter un grand nombre d’environnements virtuels en
parallèle. La limite théorique est au-delà de 8000 (Victor et Cotten, 2010).
17
Victor et Cotten (2010) donnent l’exemple suivant : sur un serveur physique ayant 2 processeurs de 300MHz,
512 Mo de RAM et 40 Go d’espace disque, on fait tourner 40 zones exécutant chacune 5 copies du service web
Apache. Avec toutes les zones fonctionnant simultanément et de multiples requêtes adressées à chaque zone,
l’overhead engendré est si faible qu’il n’est pas mesurable (< à 5%).

La principale contrainte de ce modèle de virtualisation réside dans le

fait que les systèmes invités doivent impérativement être du même type
(UNIX ou Linux) que le système hôte (Santy, 2010) ;
3.2.1.2 La virtualisation complète
Il est ici utile de rappeler que l’utilisation de cette technique passe par
l’installation d’un hyperviseur de type 2 ou de type 1 qui va émuler le matériel
sous-jacent et le présenter au système d’exploitation invité.
Un des gros intérêts de cette technique de virtualisation est de pouvoir

émuler n’importe quelle architecture matérielle. On peut donc faire
fonctionner les systèmes d’exploitation que l’on désire indépendamment de
l’architecture du système hôte (Kolyshkin, 2006). De plus, dans le cas
d’utilisation d’un hyperviseur de type 1, on a un contrôle plus fin de l’accès au
matériel et de l’utilisation des ressources (Bonnet, 2008).
Un désavantage de la virtualisation complète est que l’émulation du

matériel est coûteuse et la performance limitée ; car toutes les instructions
au matériel émulé doivent être traduites au vol avant d’être exécutées sur le
matériel réel (Anhalt et Primet, 2008) et l’empilement des couches
d’abstraction (cas d’un hyperviseur de type 2), réduit les performances des
machines virtuelles (Benkemoun et Hinfray, 2008). Aussi, pour son utilisation,
le noyau de l’hyperviseur doit être chargé dans la RAM et ensuite celui de
chacune des machines virtuelles créées aussi. C’est donc une méthode très
consommatrice en ressources (DRTIC et Eduter-Cnerta, 2013). La
virtualisation assistée matériellement (Intel VT-x et AMD-V) vient cependant

réduire un peu cette perte de performances (toutes les instructions n’ayant

plus besoin d’être traduites).
3.2.1.3 La paravirtualisation
Cette technique suppose aussi l’utilisation d’un hyperviseur de type 1,

mais sans émulation de matériel ici car le système invité est modifié. Il est
conscient d’être virtualisé et collabore ainsi avec l’hyperviseur à l’optimisation
des performances.
Le principal atout de la paravirtualisation réside dans ses faibles coûts

de virtualisation (une grande partie du travail de virtualisation ayant déjà été
réalisée en modifiant le noyau du système invité). Il offre de meilleures
performances par rapport à la virtualisation complète (Kolyshkin, 2006) et
elles sont assez proches de celles d’un système natif (Golden, 2008).
Son principal facteur limitant vient du fait qu’il ne supporte que les
systèmes ayant été modifiés pour être compatible avec l’hyperviseur utilisé
(Kolyshkin, 2006) (mais sur un processeur bénéficiant de la virtualisation
matérielle, on peut installer n’importe quel système). De plus, la
consommation en ressources matérielles (surtout la RAM) est aussi
importante qu’en virtualisation complète car les noyaux de l’hyperviseur et
des machines à créer sont chargés dans la RAM.
Le tableau suivant résume donc cette comparaison.

Tableau III.IV : Tableau comparatif des techniques de virtualisation

TECHNIQUE DE
CARACTERISTIQUES
VIRTUALISATION
- Performances : très bonnes, très proches du
Virtualisation au sein d’un natif
OS - Systèmes supportés : UNIX, Linux
(containers ou zones) - Demande en ressources matérielles (RAM,

processeur) : faible
- Performances : bonnes, proches du natif
- Systèmes supportés : tous types
Virtualisation complète
- Demande en ressources matérielles (RAM,
processeur) : assez forte
- Performances : bonnes, proches du natif et
meilleures qu’en virtualisation complète
- Systèmes supportés : ceux ayant été modifiés
pour fonctionner avec le paravirtualiseur
Paravirtualisation
(nécessite Intel VT-x ou AMD-V pour les
systèmes n’ayant pas été modifiés)
- Demande en ressources matérielles (RAM,
processeur) : assez forte
3.2.2 Techniques de virtualisation choisies
A l’étude du tableau précédent, la paravirtualisation semble être la

solution idoine lorsqu’on voudrait pouvoir utiliser dans son environnement
virtuel, n’importe quel système d’exploitation (moyennant l’intégration par le

processeur de la virtualisation matérielle). Cependant, il ne convient pas à

notre cas.
En effet, la quantité de RAM disponible sur les serveurs du projet ne

permettra pas de mettre en place les serveurs virtuels présentés à la figure
1.1 dans un environnement paravirtualisé. Supposons qu’on utilise le
paravirtualiseur Xen, qui nécessite au minimum 2Go de RAM (Citrix, 2014) et
que pour les pare-feux et les serveurs des DMZ et du réseau de données
critiques (16 au total) on utilise le système Debian, qui nécessite
généralement 512 Mo de RAM (Debian, 2013). Il faudrait donc 10,2 Go de
RAM or les serveurs ne disposent que de 8Go de RAM.
Ainsi, le choix le plus adéquat est celui de la technique de virtualisation

au sein d’un OS. La majorité des services à déployer fonctionnant dans des
environnements Linux et UNIX, leur virtualisation dans les zones nous garantit
une bonne performance ; et de plus, les zones sont bien adaptées aux scénaris
où il y a un grand nombre d’environnements d’exécution identiques (Golden,
2008).
Il s’est alors posé le problème de la virtualisation des systèmes

d’exploitation n’étant pas supporté dans les zones. On a décidé, comme
solution, d’utiliser la technique de virtualisation complète. On installera donc
un hyperviseur de type 2 (étant donné que c’est une application) dans une
zone et au sein de cet hyperviseur, seront créées les machines virtuelles
nécessaires à l’installation desdits systèmes.

En résumé, pour la mise en place de l’environnement virtuel du

datacenter de BJNet, nous avons combiné deux techniques : celle de la
virtualisation au sein d’un OS et celle de la virtualisation complète.
3.3 Solutions de virtualisation retenues pour le

centre de données
Après le choix des techniques de virtualisation à utiliser pour le
déploiement du centre de données de BJNet, nous sommes passés au choix
des solutions implémentant lesdites techniques.
La plupart des systèmes d’exploitation basés sur UNIX proposent un

moyen d’isoler les processus (chroot, BSD Jails, etc.) ; mais l’UNIX de Sun
Microsystems, Solaris, propose un système de zones très évolué, plus proche
d’une machine virtuelle que d’une isolation de processus (Bonnet, 2008). Sa
version libre et open-source, OpenSolaris a été abandonnée après le rachat
de Sun Microsystems par Oracle en 2010. Les solutions open-source phares
qui en ont découlé sont OpenIndiana18 et SmartOS19.
OpenIndiana est une distribution de la famille UNIX (System V release

4) et basée sur le noyau illumos20. C’est un fork d’OpenSolaris et est présenté
comme son successeur (Klimov, 2014). Il est actuellement compatible avec
Solaris 11 et Solaris 11 Express et constitue donc une alternative open-source
aux produits commerciaux Solaris d’Oracle (Lumsden, 2011). Il est distribué
18
Site officiel : www.openindiana.org (consulté le 16 Décembre 2014)
19
Site officiel : http://www.smartos.org (consulté le 16 Décembre 2014)
20
illumos est un noyau dérivé de celui d’OpenSolaris (OS/Net) et géré par l’illumos Foundation, créée après l’arrêt
du projet OpenSolaris par Oracle. (Site officiel : www.illumos.org) (consulté le 16 Décembre 2014)

sous licence CDDL (Common Development and Distribution License)21. Il

bénéficie des fonctionnalités très intéressantes (pour une utilisation en tant
que serveur) qu’offre le noyau illumos :
- ZFS (Z ou Zettabyte File System) : système de fichiers révolutionnaire

128 bits créé par Sun Microsystems (Oracle, 2010a) ; qui supporte
jusqu’à 16 exbioctets et qui offre le RAID, la déduplication, le snapshot,
etc.
- Solaris zones
- Crossbow : outil de virtualisation réseau permettant la création de
cartes réseau virtuelles, de switch virtuels, l’attribution de pile TCP/IP
exclusive à une zone, la gestion de la bande passante, etc.
- DTrace : outil permettant de suivre les performances des services et de
détecter les problèmes en temps réel
- SMF (System Management Facility) : outil de gestion des services et qui
permet par exemple le démarrage en parallèle de services, le
redémarrage automatique après incident, etc.
- Etc.
SmartOS est aussi une distribution basée sur le noyau illumos, et

bénéficiant donc de ses fonctionnalités. Cependant SmartOS offre l’avantage,
par rapport à OpenIndiana, de pouvoir installer dans ses zones n’importe quel
autre système d’exploitation compatible x86. En effet, OpenIndiana est limité
dans ses Branded Zones22 Linux (LxBrand) aux systèmes RedHat et CentOS
21
La CDDL est une licence open source créée par Sun Microsystems, basée sur la Mozilla Public License, version
1.1. Elle était notamment destinée au projet OpenSolaris. (Plus d’informations sur le site de l’Open Source
Initiative : http://opensource.org/licenses/cddl1.php ) (consulté le 16 Décembre 2014)
22
Une Branded Zones (BrandZ) est une zone permettant de faire marcher un environnement d’exécution
différent de celui de l’OS qui héberge les zones

(Oracle, 2010b). Le support des autres systèmes d’exploitation est rendu

possible par le fait que KVM (Kernel-based Virtual Machine)23, une
technologie de virtualisation complète, a été porté au sein de SmartOS et
intégré aux zones (à la création d’une zone, on spécifie si la zone sera du type
natif ou du type KVM afin d’installer des systèmes Linux, Windows ou UNIX).
La limite à cette intégration de KVM au sein de SmartOS est qu’elle n’est
utilisable que sur des serveurs ayant un processeur Intel bénéficiant des
technologies VT-x et EPT (Extended Page Tables) (McWhirter et Wiedenroth,
2014).
Ainsi, vu que les serveurs du projet BJNet sont équipés de processeurs

AMD (cf. Tableau III.I), nous ne pouvions que choisir OpenIndiana comme
solution de virtualisation pour la création des zones.
Quant à l’hyperviseur de type 2 à utiliser, notre choix s’est porté sur

VirtualBox d’Oracle (en mode headless24). Les raisons en sont que ce produit
est libre d’utilisation, bénéficie d’une communauté active et offre le support
pour la plupart des systèmes d’exploitation du marché.
3.4 Choix des outils à utiliser sur les serveurs

OpenIndiana combiné à VirtualBox étant retenues, le choix des outils à
utiliser pour mettre en place les services sera fait en conséquence.
23
Site officiel : https://www.linux-kvm.org (consulté le 18 Décembre 2014)
24
Le mode headless désigne la version de VirtualBox n’intégrant pas d’interface graphique. Une interface web,
phpvirtualbox, est cependant disponible pour accéder aux systèmes invités ayant d’interface graphique.

3.4.1 Le serveur DNS

Il existe plusieurs logiciels open-source faisant office de serveur DNS :
BIND, OpenDNS, MaraDNS, etc.
Le logiciel le plus utilisé sur les serveurs de noms est BIND (ISC, 2014).
Il est intégré à OpenIndiana et constitue donc notre choix.
3.4.2 Le serveur web

Parmi le grand nombre de serveurs web existants (Apache HTTP Server,
Microsoft IIS, Litespeed, Nginx, Varnish, Apache Tomcat, etc.), les plus
populaires parmi ceux libres et open-source sont Apache HTTP Server et
Nginx.
Apache HTTP Server est le serveur web le plus utilisé au monde avec
58,9% de parts de marché et devance Nginx qui a 22,8% (w3techs, 2014). Il
est préféré à Nginx pour son extensibilité, sa fiabilité et son grand nombre de
modules (permettant d’héberger des sites écrits avec différents langages ou
différents frameworks) ; alors que Nginx est un serveur web léger mieux
adapté pour servir du contenu statique (Rowe, 2014).
Puisqu’il peut être installé dans OpenIndiana, Apache HTTP Server

constitue notre choix pour le serveur web.
3.4.3 Le relais inverse HTTP (HyperText Transfer

Protocol)
Le relais inverse HTTP (encore appelé serveur mandataire ou reverse

proxy en anglais) est un serveur qui apparaît au client comme un serveur web

ordinaire alors qu’il n’est pas en réalité le serveur qui génère les pages
demandées. Il est souvent utilisé lorsque le vrai serveur web se trouve
derrière un pare-feu et peut-être aussi utilisé pour équilibrer les charges entre
plusieurs serveurs (back-end servers) ou encore pour mettre des pages en
cache (Apache, 2014).
Nginx est reconnu comme l’un des meilleurs serveurs pour un usage en relais
inverse HTTP car il utilise moins de RAM et très peu de threads pour un grand
nombre de connexions simultanées alors qu’Apache HTTP Server en utilise un
par connexion (Rowe, 2014). Utiliser Nginx comme relais et Apache HTTP
Server comme serveur back-end est un scénario très utilisé (Rowe, 2014). De
plus, il peut être installé dans OpenIndiana.
On choisit donc Nginx pour le relais inverse HTTP.
3.4.4 Le serveur mail

C’est le serveur qui stockera les mails des utilisateurs et qui se chargera
d’envoyer les mails des utilisateurs.
Pour le serveur de mail sortant et entrant, nous choisissons Postfix, car

il est plus simple de configuration que Sendmail et est largement répandu.
Pour le serveur POP/IMAP (Post Office Protocol/Internet Message Access
Protocol), nous avons retenu d’utiliser Dovecot, car il forme avec Postfix le
couple le plus utilisé pour les serveurs de mails.
3.4.5 Le relais SMTP (Simple Mail Transfer Protocol)

Ce relais se chargera de transférer les requêtes SMTP effectuées vers le
serveur de mail sortant et entrant.

Nous avons choisi d’utiliser Nginx car il est très léger, rapide, libre, capable de
faire proxy SMTP et peut être installé sur OpenIndiana.
3.4.6 Le relais POP/IMAP

Le relais POP/IMAP se chargera, lorsqu’un client voudra consulter ses mails,
d’aller les récupérer sur le serveur mail du centre de données critiques.
Nous avons choisi d’utiliser Perdition car il est libre, puissant et largement
utilisé.
3.4.7 Le serveur de bases de données

Nous avons choisi d’utiliser MySQL car il est libre et est le moteur de bases de
données libre le plus utilisé (DB-engines, 2014).
3.4.8 Les pare-feux

Pour les pare-feux, nous avons retenu d’utiliser celui intégré à
OpenIndiana et qui est IPFilter.
Tableau III.V : Récapitulatif des outils pour les serveurs, relais et pare-feux
Elément à mettre en
Outil choisi
place
Serveur DNS BIND 9
Serveur web Apache HTTP Server
Relais inverse HTTP Nginx
Serveur mail Postfix + Dovecot
Relais SMTP Nginx
Relais POP/IMAP Perdition
Serveur de bases de
MySQL
données
Pare-feux IPFilter

En conclusion, pour le déploiement du datacenter de BJNet, la solution

retenue combine les zones de OpenIndiana et l’hyperviseur VirtualBox. Nous
sommes passés ensuite à la conception de l’architecture de l’environnement
virtuel du datacenter.


4. CHAPITRE 4 : ARCHITECTURE VIRTUELLE DU CENTRE DE DONNEES ET RECOMMANDATIONS DE DEPLOIEMENT
CHAPITRE
ARCHITECTURE
VIRTUELLE DU CENTRE
DE DONNEES ET
RECOMMANDATIONS DE
DEPLOIEMENT
42
CHAPITRE 4 : ARCHITECTURE VIRTUELLE DU CENTRE DE DONNEES ET RECOMMANDATIONS DE DEPLOIEMENT
Après avoir choisi d’utiliser OpenIndiana combinée à VirtualBox comme

solution de virtualisation pour le déploiement du centre de données de BJNet,
nous avons conçu l’architecture de l’environnement de virtualisation et
proposer des recommandations pour le déploiement de celui-ci.
4.1 Architecture de l’environnement virtuel

A l’analyse de la topologie physique présentée à la figure 1.1, nous avons
déduit une première architecture présentée à la figure 4.1 ci-dessous :
Figure 4.1: Première approche d’architecture
Comme on peut le voir sur la figure précédente, l’idéal pour la mise en

place des serveurs aurait été que les serveurs physiques disposent de quatre
interfaces réseaux ; chacune étant dédiée à chacun des quatre réseaux qui
constituent le centre de données de BJNet.
Cette architecture a donc été modifiée au regard des points suivants :

1) Concernant le routage du trafic entre les 4 réseaux
Le serveur n’ayant qu’une seule interface réseau, on a deux options : le

routeur qui s’en occupera peut être physique (comme sur la figure 4.1) et
donc situé à l’extérieur du serveur ou il peut être virtuel et donc situé à
l’intérieur du serveur.
Dans le premier cas, il faudrait utiliser les VLAN. Chaque réseau sera
donc associé à un VLAN (les paquets provenant de ce réseau seront marqués
avec l’identifiant de ce VLAN). Ainsi, si un serveur d’un VLAN doit joindre un
autre serveur appartenant à un VLAN différent, le paquet devra passer par
l’interface réseau du serveur pour aller vers le routeur avant de revenir par
cette interface pour aller vers sa destination. L’interface réseau du serveur
sera donc sollicitée six fois, pour le traitement d’une seule requête par
exemple :
 d’abord, lorsque la requête du client va vers l’un des relais dans

l’une des DMZ ;
 ensuite, lorsque le relais doit joindre le serveur concerné et envoie
donc le paquet au routeur (les VLANs étant différents) ;
 ensuite, lorsque le routeur doit envoyer ce paquet vers ledit
serveur ;
 ensuite, lorsque le serveur, après avoir généré la réponse la renvoie
au relais en passant une fois encore par cette interface pour joindre
le routeur ;
 ensuite, lorsque le routeur envoie le paquet au relais et
 enfin lorsque le relais répond au client.

Puisque les requêtes vers le centre de données seront nombreuses et

simultanées, les performances de cette carte réseau seraient fortement
diminuées.
La deuxième option, qui suppose la création d’une zone routeur, est donc
la mieux adaptée au besoin d’utilisation efficiente de la bande passante
offerte par la carte réseau.
2) Concernant l’interconnexion entre les cartes réseau virtuelles (VNIC25)

des zones
Dans Crossbow, une VNIC est toujours liée à un lien de données (datalink)
qui peut être une carte réseau physique (NIC) ou un etherstub (switch virtuel)
(Nagarajayya, 2008). Donc pour interconnecter deux VNIC, il faut toujours un
etherstub (Oracle, 2012).
3) Concernant la sécurité du trafic inter-zones
Certaines zones, dans un fonctionnement normal du centre de données,

ne doivent pas initier de requêtes vers certaines autres zones. Par exemple,
un relais HTTP ne doit pas initier de requêtes vers le serveur de bases de
données situé dans le réseau de données critiques ; seuls les serveurs web et
mail doivent y accéder. De telles requêtes peuvent donc être l’œuvre
d’attaquants ayant pris le contrôle de ce relais web par exemple. Les pare-
feux étant chargés de contrôler l’accès aux machines d’un réseau, le trafic
venant d’une zone ou allant vers une zone doit donc toujours passer par eux.
A leur niveau, ils vérifient si les paquets respectent les règles de sécurité
configurées ; si oui les paquets peuvent continuer, sinon ils sont supprimés.
25
VNIC : Virtual Network Interface Card

4) Concernant le réseau de données critiques
Une mesure supplémentaire de sécurité sera rajoutée à ce réseau,

regroupant des serveurs sensibles, en ne le rendant pas directement
accessible depuis l’extérieur du réseau du centre de données. Il ne sera donc
pas directement connecté à la carte réseau physique. Les clients n’auront pas
conscience de son existence et ce sont les DMZ qui se chargeront de
transférer leurs requêtes.
5) Concernant le centre d’administration réseau
Les machines virtuelles qui hébergeront les systèmes d’exploitation

adaptés aux outils prévus (Dude, Nagios et OpenVAS) seront créées dans
VirtualBox, qui sera installée dans une zone (appelons la « zone_admin »).
Cette zone doit avoir les cartes réseaux nécessaires pour permettre la visibilité
depuis l’extérieur du serveur et la connexion avec le reste du réseau du centre
de données.
Nous avons deux options pour la création du centre d’administration

réseau : on peut installer le pare-feu dans une zone et installer les machines
abritant les outils d’administration dans une autre zone hébergeant
VirtualBox ou installer lesdites machines et le pare-feu dans VirtualBox.
Dans le premier cas, la zone pare-feu aurait trois VNICs pour se connecter
aux deux zones routeurs et à la zone où VirtualBox serait installé. Les
machines créées dans VirtualBox devront être en mode “pont“26 sur la ou les
VNICs de la zone hôte pour pouvoir communiquer avec le pare-feu. Or dans
26
Le mode pont est un mode réseau de VirtualBox où la carte réseau de la machine virtuelle est liée à la carte
réseau de la machine qui héberge VirtualBox ; et la machine virtuelle apparaît dans le réseau auquel est
connectée la machine hôte comme une nouvelle machine (Oracle, 2013). Ainsi la machine virtuelle peut avoir
accès à Internet par exemple.

le mode pont, une VNIC doit être exclusivement dédiée à la machine virtuelle
(Oracle, 2013). Alors, il faudrait autant de VNIC que de machines à créer.
Dans le second cas, le réseau entre le pare-feu et les machines clientes

serait entièrement contenu dans VirtualBox et c’est le pare-feu qui sera
connecté aux VNICs de la zone. Il faudrait donc dans ce cas, juste deux VNICs.
L’ajout de nouvelles machines au centre d’administration réseau ne
nécessiterait pas la reconfiguration de la zone hôte et peut en outre
permettre d’installer un pare-feu différent de celui de OpenIndiana (pfSense
par exemple).
Nous avons donc choisi la seconde option.
En tenant compte des contraintes sus-citées, nous avons conçu

l’architecture présentée à la figure 4.2.

Figure 4.2 : Architecture de l’environnement virtuel du centre de données de BJNet

Il convient, afin de mieux faire comprendre notre architecture, de faire les

remarques suivantes:
a) Concernant la zone routeur 1 (zrouter1)

Elle est l’interface entre le réseau extérieur au centre de données et celui-
ci. Elle se charge de router les requêtes des clients vers la DMZ concernée et
ensuite de renvoyer la réponse ;
b) Concernant la zone routeur 2 (zrouter2)
Elle est chargée de router le trafic entre les zones. C’est donc par elle que
les relais joindront les serveurs auxquels ils correspondent ; et que les outils
d’administration joindront les machines à administrer.
c) Concernant les passerelles par défaut

Les passerelles par défaut, auxquelles les machines adresseront les
paquets à destination d’un réseau qui leur est inconnu, sont réparties comme
suit :
 celles des serveurs, relais et des machines d’administration sont les

pare-feux de leur réseau respectif ;
 celle des pare-feux des DMZ et du centre d’administration réseau
est la zone routeur 1 ;
 celle du pare-feu du réseau de données critiques est la zone routeur
2;
 et celle de la zone routeur 1 est le routeur physique auquel est
connecté le serveur.

d) Concernant le centre d’administration réseau

VirtualBox voit comme cartes réseau physiques, les deux cartes réseau
virtuelles créées pour la zone (zone_admin) qui l’héberge. Ainsi la machine
virtuelle faisant office de pare-feu a aussi trois cartes réseau:
- l’une en mode “pont“ sur la carte réseau virtuelle de la zone, qui est
connectée à la zone routeur 1 (et donc à l’extérieur) ;
- la seconde en mode “pont“ sur la carte réseau virtuelle de la zone, qui
est connectée à la zone routeur 2 ;
- la dernière en mode “réseau interne privé“27 et reliée aux machines
virtuelles hébergeant Nagios, Dude et OpenVAS.
Les cartes réseaux des machines Nagios, Dude et OpenVAS sont aussi en
mode “réseau interne privé“.
4.2 Définition des recommandations pour le

déploiement
Nous abordons ici certains points importants ayant trait au déploiement
du centre de données et faisons des recommandations pour une bonne mise
en place de ce centre de données.
4.2.1 Plan d’adressage des zones
Les machines de la DMZ publique auront des adresses IP publiques,

puisqu’elles sont les machines répondant aux requêtes provenant d’Internet.
27
Le mode réseau interne privé est un mode réseau de VirtualBox qui établit un réseau limité exclusivement
aux machines virtuelles (Oracle, 2013)

Le reste de l’adressage des machines du centre de données se fera avec

des adresses IP privées. Le nombre d’adresses IP privées à attribuer est
actuellement de 30 (puisqu’il y a 30 VNICs). On prévoit une augmentation de
15 nouvelles machines pour la fourniture des services additionnels. Une
adresse réseau de classe C, qui offre jusqu’à 254 adresses hôtes, est donc
suffisante pour cet adressage. Puisque les VNIC sont regroupés dans des
réseaux différents, nous allons donc créer des sous-réseaux au sein de cette
adresse réseau. Les sous-réseaux qu’on peut créer peuvent permettre
d’adresser 126, 62, 30, 14, 6 ou 2 hôtes.
Le nombre de cartes réseaux à adresser dans les sous-réseaux de la DMZ

privée, du centre de données critiques et du centre d’administration réseau
est de 5 au maximum actuellement. Mais ce nombre pourrait aller jusqu’à 12
avec l’ajout de nouveaux serveurs. Nous avons donc décidé de faire des sous-
réseaux de 30 machines hôtes. Ainsi, au moment d’ajouter de nouveaux
serveurs au centre de données, il n’y aura pas un manque d’adresses IP. Le
masque de sous-réseau est donc de 255.255.255.224 (/27).
Pour l’interconnexion entre les pare-feux et les routeurs, nous avons

décidé de créer des sous-réseaux de 6 machines hôtes. Le nombre de VNICs
nécessaires pour connecter le pare-feu du centre d’administration réseau aux
zones routeurs est de 3 ; un sous-réseau de 2 machines hôtes n’est donc pas
suffisant. Le masque de ces sous-réseaux est donc 255.255.255.248 (/29).

4.2.2 Déploiement et configuration de OpenIndiana
Nous n’allons pas décrire ici toutes les étapes aboutissant à la mise en
fonction du système d’exploitation OpenIndiana, mais seulement mettre
l’accent sur deux points importants.
Le premier est le niveau de RAID utilisé. Le serveur ayant deux disques

de capacité identique (1 To), nous avons choisi d’effectuer un RAID 1 (ou
mirroring) afin de dupliquer les données. Ce niveau de RAID impliquant la
division par deux de l’espace de stockage disponible, l’espace disque utilisable
par le système et les machines virtuelles est donc de 1 To.
Le second est le partitionnement du disque. La configuration matérielle

recommandée pour l’installation de OpenIndiana en mode serveur est de 3Go
d’espace disque et de 768 Mo de RAM (Lumsden, 2011). Les zones à créer
(désignées sous le vocable zone locale) partagent des répertoires avec le
système d’exploitation hôte (désignée comme zone globale) ; et donc ces
répertoires peuvent augmenter en taille avec la création des zones locales.
Nous avons donc créé deux partitions : l’une de 20 GB pour l’installation du
système et l’autre de 980 Gb pour les zones.
4.2.3 Création des machines virtuelles
Nous avons conçu le protocole en 6 étapes ci-dessous afin de créer de

manière efficace les zones nécessaires.

 Etape 1 : création de l’emplacement (dataset) où seront stockées les

zones
Ici, il a été question de créer le dataset situé sur le pool de stockage ZFS28
qui stockera les zones à instancier. Cela a été fait avec la commande
zfs create –o mountpoint=point_de_montage chemin_du_dataset_a_créer.
Il n’y a que l’utilisateur root qui dispose des droits sur ce dataset.
 Etape 2 : création des etherstubs (switchs virtuels)

A cette étape, nous avons créé les switches qui sont prévus par
l’architecture ; et ceci grâce à la commande dladm create-etherstub
nom_du_switch.
 Etape 3 : création et installation d’une zone modèle

Afin de rendre plus rapide la création des zones de l’architecture, il est plus
avisé de créer une zone modèle, qui sera ensuite clonée afin de créer les
autres ; en effet, construire une zone à partir des paquetages est plus long
que de copier une zone existante.
Les zones sont créées (configurées) avec la commande zonecfg (zonecfg

–z nom-de-la-zone), à laquelle on passe les paramètres de configuration de la
zone. Lesdits paramètres permettent de spécifier le répertoire où cette zone
sera créée (zonepath), si la zone sera démarrée automatiquement au
démarrage du serveur, le type réseau de la zone (share-IP ou exclusive-IP)29,
28
Un pool de stockage ZFS est un groupe logique de périphériques décrivant la disposition et les caractéristiques
physiques du stockage disponible. L'espace pour les jeux de données (dataset) est alloué à partir d'un pool (Sun,
2008).
29
Une zone de type exclusive-IP est une zone qui dispose de sa propre instance IP et peut donc avoir sa propre
adresse IP, table de routage, règles de filtrage, etc. Une zone de type share-IP partage la même instance IP que
la zone globale et donc la même adresse, les mêmes règles de filtrage, etc.

les cartes réseaux de la zone ainsi que leurs adresses IP, le nombre de CPU
associé à la zone, la mémoire associée, etc. Cependant, seuls les paramètres
zonepath et zonename (nom de la zone) sont nécessaires pour la création
basique d’une zone.
Après la configuration, on est passé à l’installation de la zone modèle créée

(zoneadm –z nom_de_la_zone install). Cette installation se fait en ligne et sa
durée dépend donc de la bande passante du réseau.
 Etape 4 : création des VNICs

Ici nous avons procédé à la création des cartes réseaux virtuelles. La
commande est dladm create-vnic –l link_vnic nom_vnic. Link_vnic permet de
spécifier si la VNIC sera reliée à une carte réseau physique ou à un switch
virtuel.
 Etape 5 : création, installation et démarrage des zones

A cette étape, nous avons instancié les zones voulues. Pour cela, il a été
créé un fichier de configuration. Celui-ci, utilisé pour la configuration de base
de la zone, a permis de spécifier le zonepath, l’ip-type, l’autoboot ainsi que les
VNICs de la zone. Ce fichier est passé en paramètre à la commande zonecfg
avec l’option -f ; ensuite la zone est installée en clonant la zone modèle créée
à l’étape 3 (zonecfg –z zone_à_créer clone nom_zone_modèle).
La zone ainsi créée peut maintenant être démarrée (zoneadm –z

nom_zone boot).

 Etape 6 : configuration des zones

La connexion à une zone peut maintenant se faire (avec la commande
zlogin nom_zone) pour y effectuer les configurations nécessaires. Dès que la
commande est entrée, l’outil de configuration de base se lance et par son biais
on configure : le hostname (nom de la machine sur le réseau) de chaque
interface réseau, les adresses IP de chacune des interfaces, les serveurs de
nom, le compte de l’utilisateur root, le fuseau horaire, etc. Après cela, la zone
est redémarrée et on peut procéder maintenant aux configurations
additionnelles. En termes de configuration additionnelle, il s’agit de
l’activation du routage, de la configuration des routes, de l’installation et de
la configuration des services prévus pour chaque zone, etc.
L’architecture de l’environnement virtuel pour le déploiement du

datacenter étant conçue, nous sommes passés à une étape de simulation afin
de valider le travail.

5. CHAPITRE 5 : SIMULATION ET TESTS
CHAPITRE
SIMULATION

ET TESTS
56
CHAPITRE 5 : SIMULATION ET TESTS
Dans l’optique de vérifier que notre architecture virtuelle est

fonctionnelle, et permet une communication entre les diverses zones, nous
avons effectué une simulation suivie de quelques tests dont les résultats sont
présentés dans ce chapitre.
5.1 Présentation de l’environnement de

simulation
Pour les besoins de la simulation, nous avons créé les zones suivantes :
- Pare-feu de la DMZ publique (firewall1)

- Pare-feu du réseau de données critiques (firewall4)
- Zone routeur 1 (zrouter1)
- Zone routeur 2 (zrouter2)
- Relais inverse HTTP de la DMZ publique (rihttp2)
- Serveur web du réseau de données critiques (web1)
La topologie de l’environnement est celle présentée à la figure 5.1 :
Figure 5.1: Topologie de l’environnement de simulation
Le serveur ainsi que le client ont été réalisés dans des machines virtuelles.

Les moyens utilisés sont les suivants :
- hyperviseur : VirtualBox 4.2.16 r86992
- serveur : une machine virtuelle sur laquelle a été installée OpenIndiana

(version : oi_151a8 64bit) et au sein de laquelle, les diverses zones ont été
créées
- client : une machine virtuelle tournant sous Debian Squeeze
Le tableau suivant récapitule les caractéristiques matérielles des machines

virtuelles utilisées pour la simulation :
Tableau V.I : Caractéristiques matérielles des machines virtuelles utilisées pour la

simulation
Rôle RAM Disque Dur Carte Réseau
- mode : Host Only

Serveur 768 Mo 10 Go
- adresse : 192.168.56.2/24
- mode : Host Only
Client 384 Mo 8 Go
- adresse : 192.168.56.4/24
Pour les besoins de la simulation, les adresses réseau suivantes ont été
choisies :

- pour les machines de la DMZ publique : 10.0.0.0/8. On y a créé un sous-

réseau de 30 machines hôtes ayant donc pour masque 255.255.255.224
(/27)
- pour le reste des machines : 192.168.1.0/24. On y a créé les sous-

réseaux de 30 machines hôtes avec pour masque de sous-réseau
255.255.255.224 (/27). On y a aussi créé les sous-réseaux de 6 machines
hôtes pour l’interconnexion des pare-feux et routeurs avec pour
masque de sous-réseau 255.255.255.248 (/29)
Le plan d’adressage est présenté dans le Tableau V.II.
Ces paramètres étant établis, nous avons créé les éléments nécessaires
à la simulation en suivant le protocole présenté en 4.2.3. Le détail des
commandes utilisées est présenté en annexe B.

Tableau V.II : Plan d’adressage des zones créées pour la simulation
Pare-feu du réseau de données critiques

Adresse vcdn1 192.168.1.138 /29
Adresse vcdn2 192.168.1.161 /27
Pare-feu DMZ Publique
Adresse vdmzpu1 192.168.1.2 /29

Adresse vdmzpu3 192.168.1.129 /29
Zone routeur2
Adresse vrouter1 192.168.1.131 /29
Adresse vrouter2 192.168.1.137 /29
Zone routeur1
Adresse vphys1 192.168.56.3 /24
Relais inverse HTTP2

Adresse vrihttp2 10.0.0.35 /27
Serveur web1
Adresse vweb1 192.168.1.162

5.2 Tests effectués

Les tests que nous avons faits sont des tests d’accès réseau afin de vérifier
que des paquets peuvent transiter d’une zone à l’autre et que de l’extérieur,
on peut accéder au centre de données. On confirme ainsi donc, implicitement,
le fonctionnement des services à mettre en place lorsqu’on passera en
production.
Les outils de test utilisés sont ping et traceroute. Le premier permet de

confirmer qu’une machine arrive à joindre une autre ; et le second permet de
voir les routeurs qui acheminent le paquet ICMP (Internet Control Message
Protocol) de l’émetteur vers le récepteur.
5.2.1 Tests d’accès au serveur web du centre de données

critiques à partir du relais inverse HTTP de la DMZ publique
Lorsqu’un test de ping est concluant dans OpenIndiana, on reçoit dans la

console un message de ce type : adresse_IP_destinataire is alive.
Le résultat de ce test est présenté sur la figure suivante :
Figure 5.2 : Test d’accès réseau entre le relais inverse web et le serveur web
Ce test a donc été concluant.

Puisqu’on arrive à joindre par le réseau le serveur web à partir d’une

machine de la DMZ publique, alors on conclut que les serveurs du centre de
données critiques sont joignables depuis les DMZ ; ainsi les relais situés dans
les DMZ peuvent après avoir reçu les requêtes des clients, les transmettre à
ces serveurs pour qu’elles soient traitées. Et lesdits serveurs peuvent aussi
renvoyer les réponses des requêtes aux relais.
De plus, grâce à l’outil traceroute, on peut confirmer qu’une requête

vers le centre de données critiques passe par la zone routeur 2 (adresse
192.161.1.131) puis par le pare-feu de ce réseau (adresse 192.168.1.138).
5.2.2 Test d’accès au relais inverse HTTP de la DMZ publique à

partir du client
Lorsqu’un test de ping est concluant dans Debian, les statistiques
concernant le nombre de paquets ICMP envoyés et reçus sont affichés.
Le résultat de ce test est présenté sur la figure suivante :
Figure 5.3: Test d’accès réseau entre le client et le relais inverse HTTP de la DMZ
publique

Ce test a donc été concluant aussi.
Les utilisateurs du réseau BJNet peuvent donc joindre le centre de

données pour consulter et envoyer des mails, consulter des pages web, etc.
On peut, grâce au traceroute, voir que le routage vers l’une ou l’autre

des DMZ se fait dans la zone routeur 1 (adresse 192.168.56.2) et qu’ensuite
le trafic passe par le pare-feu de la DMZ concernée (adresse 192.168.1.2).


6. CHAPITRE 6 : ANALYSE ET DISCUSSION
CHAPITRE
ANALYSE
ET
DISCUSSION
64
CHAPITRE 6 : ANALYSE ET DISCUSSION
Le projet BJNet, afin d’offrir des services à valeur ajoutée aux structures
qu’il interconnecte, doit mettre en place un centre de données. Après la
conception de l’architecture physique de ce centre, il s’est posé le problème
de déploiement de l’ensemble des serveurs au sein d’un serveur physique.
Grâce à la virtualisation, nous avons pu mettre en place un environnement de
virtualisation fonctionnel pour le déploiement des serveurs du centre de
données de BJNet.
En effet, le choix de l’utilisation de la virtualisation au sein du système

d’exploitation permet de profiter de la légèreté des zones et de leur moindre
coût en ressources, mais aussi de profiter des technologies complémentaires
apportées par les distributions basées sur illumos (en l’occurrence ici
OpenIndiana). On bénéficie ainsi de la sécurité et de la fiabilité des systèmes
UNIX mais aussi de celle de ZFS, des capacités de suivi et de dépannage des
services de DTrace et enfin de la capacité de CrossBow à virtualiser tout un
réseau par la création de cartes réseaux virtuelles, de switchs virtuels, etc.
Aussi, l’architecture réseau proposée respecte-t-elle les contraintes fixées par
l’environnement de travail et rend les serveurs accessibles depuis l’extérieur
du réseau.
Ainsi, l’environnement mis en place est fonctionnel mais est aussi

extensible. En effet, on peut facilement rajouter des serveurs sur chacun des
réseaux : le plan d’adressage prévoit cela et il suffira juste de créer une zone
(en clonant la zone modèle) et sa VNIC et de la relier au switch du réseau
ciblé ; ou mieux encore, rajouter tout un nouveau réseau.

Cependant, nous avons identifié quelques aspects qui pourraient être

approfondis.
En premier, le nombre de zones déployées ici étant faible, la création

desdites zones a été faite manuellement (même si nous avons réduit
considérablement le temps de création en utilisant une zone modèle à cloner)
et le routage a été fait de manière statique ; mais si le nombre de zones
devient élevé, alors il faudrait rendre plus dynamique la mise en place de
celles-ci. Cela passera par la création de scripts pour l’automatisation de la
création, de l’installation et de la configuration des zones.
Ensuite, dans le cadre de cette étude, nous avons créé les zones avec
des caractéristiques matérielles par défaut. Cependant, le centre de données
étant appelé à fournir des services à un nombre d’utilisateurs qui va
s’accroître, il serait judicieux d’effectuer une étude sur les besoins matériels
des services à fournir afin de définir les ressources allouées à une zone. Un
serveur DNS ne consomme pas la même puissance de calcul, le même espace
en RAM, la même bande passante qu’un serveur web ou un serveur de bases
de données. On assurerait ainsi qu’un serveur ne manque pas de ressources
ou au contraire qu’il n’utilise pas abusivement les ressources du système. Les
distributions basées sur illumos intègrent pour cela des outils pour limiter
l’espace disque, la RAM, le nombre de processeurs ou de cœurs de
processeurs, la bande passante utilisée par une zone, etc ; et l’outil DTrace qui
permet de suivre les performances des services. Cela permettrait d’améliorer
les performances globales du centre de données et sa disponibilité.
Ensuite, l’utilisation de VirtualBox rajoute de la complexité à

l’architecture conçue et rajoute une nouvelle couche de virtualisation et donc

une baisse de performances qui peut être préjudiciable si un grand nombre

d’OS devaient être ainsi déployés. SmartOS, qui constitue une très bonne
alternative à OpenIndiana si on veut virtualiser divers systèmes
d’exploitation, n’a pas été utilisé dans notre travail car l’intégration de KVM
n’est supportée que par les processeurs Intel bénéficiant des technologies
VT-x et EPT. Cependant, une communauté travaille depuis un moment sur une
version de SmartOS qui intégrerait le support de KVM sur les processeurs
AMD30. Il serait intéressant de la tester et de baser l’architecture de
l’environnement sur elle.
Enfin, nous proposons, dans la mesure du possible, d’augmenter le

nombre de serveurs dans le cluster et de se doter de solutions de stockage
partagé (NAS ou SAN) afin de pouvoir délocaliser certains services importants,
d’augmenter la redondance des services et d’augmenter la disponibilité du
datacenter.
30
http://imgapi.uqcloud.net/builds (consulté le 20 Décembre 2014)

CONCLUSION ET PERSPECTIVES
Ce projet nous a permis d’utiliser la virtualisation pour concevoir un

environnement qui permettra la mise en place du centre de données de
BJNet.
La virtualisation est en effet une technologie, qui entre autres
avantages, offre celui de permettre le déploiement de plusieurs serveurs
(fonctionnant même sous divers OS) sur un nombre réduit de serveurs, voire
même un seul. Le centre de données du projet BJNet a pour but de fournir
des services comme le DNS, le mail, l’hébergement de sites web aux
structures de la Défense, de l’Université et de l’Administration qu’il
interconnecte. Il a été confronté au problème de déploiement de plusieurs
serveurs répartis en quatre réseaux sur une seule machine physique. Nous
avons donc comparé les diverses techniques de virtualisation et avons,
compte tenu du matériel disponible et des contraintes liées à ce cas d’étude,
choisi les techniques idoines : celle de la virtualisation au sein d’un OS
combinée à celle de la virtualisation complète. L’OS retenu fut OpenIndiana
et l’hyperviseur de type 2 fut VirtualBox. Nous avons ensuite choisi les outils
qui seront installés sur chaque serveur et avons construit l’architecture
virtuelle de ce centre de données. Il intègre des cartes réseaux virtuelles, des
switchs virtuels et des zones routeurs. Nous avons aussi fait des
recommandations pouvant permettre de déployer efficacement les zones
nécessaires. La simulation effectuée nous a permis de montrer le
fonctionnement effectif de notre environnement.
En perspective, nous proposons d’étudier les demandes en ressources
des outils à mettre en place sur les serveurs afin de dimensionner les
ressources à allouer aux machines virtuelles à créer. Une autre perspective
serait d’étudier l’augmentation de la disponibilité du centre de données par
l’ajout de stockage partagé ou l’intégration d’outils de haute disponibilité en
cluster.

BIBLIOGRAPHIE
- Anhalt, F., Primet, P., 2008: Analysis and evaluation of a XEN based virtual
router. Rapport de recherche (RR-6658). INRIA, France, 22-24.
https://hal.inria.fr/file/index/docid/320620/filename/RR_inria_virtual_router
.pdf [consulté le 1er décembre 2014]
- ANSSI, 2012 : Problématiques de sécurité associées à la virtualisation des
systèmes d’information. Livre blanc. Agence Nationale de la Sécurité des
Systèmes d’Information, France, 3-6.
http://www.ssi.gouv.fr/IMG/pdf/2012_05_29_-_Guide_1343_-_Problema-
tique_de_securite_Virtualisation_3_9.pdf [consulté le 17 Septembre 2014]
- Benkemoun, A., Hinfray, R., 2008 : Etude de la virtualisation et du
fonctionnement de la solution libre Xen. Rapport de recherche. Département
des Systèmes d’Informations et de Télécommunications, Université de
Technologie de Troyes, France, 4-26.
http://www.antoinebenkemoun.fr/data/AC_Virtualisation.pdf [consulté le 1er
Septembre 2014]
- Bonnet, L., 2008 : Etat de l’art des solutions libres de virtualisation pour une
petite entreprise. Livre blanc. Bearstech, 98 p.
http://bearstech.com/old/files/LB-virtualisationEntrepriseBearstech.pdf
[consulté le 21 Aout 2014]
- Citrix, 2014 : Citrix XenServer 6.0.2 Installation Guide. Guide d’installation.
Citrix, USA, 5-6.
http://support.citrix.com/servlet/KbServlet/download/34970-102-
704220/installation.pdf [consulté le 21 Aout 2014]

BIBLIOGRAPHIE
- Donnette, B., Hannequin, D., 2007 : La virtualisation. Livre blanc. Groupe

LINAGORA, France, 61 p.
https://www.08000linux.com/public/page_attachments/0000/0001/Virtualis
ation_Linagoragroup_WB_V1.0.pdf [consulté le 21 Juillet 2014]
- DRTIC, Eduter-Cnerta, 2013 : Virtualisation de l’architecture serveurs pour le
système d’informations de l’EPLEFPA-Recommandations pour les serveurs de
Logiciels de Gestion Administrative. Rapport d’étude. DRTIC et Eduter-Cnerta,
France, 114p
http://www.eduter-cnerta.fr/fileadmin/user_upload/actus_accueil/livre_-
blanc_virtualisation.pdf [consulté le 9 Novembre 2014]
- Emerson, 2010 : Promesses, défis et impératifs de la Gestion de l’Infrastructure
des Datacenters. Livre blanc. Emerson, USA, 8 p.
http://www.emersonnetworkpower.com/trellis/fr-EMEA/Documents/-
0810-DCIM-MPP-FR.pdf [consulté le 26 Juin 2014]
- Eureva, 2009 : La virtualisation de poste de travail et d’application : concepts
et utilisation pratique. Livre blanc. Eureva, Paris, France, 18 p.
http://www.eureva.fr/media/682/La%20virtualisation%20v1.2.pdf [consulté
le 17 Aout 2014]
- Golden, B., 2008: Virtualization for Dummies. ISBN: 978-0-470-14831-0, Wiley,
Indianapolis, USA, 1-329.
http://cdn2.flepi.com/g/FpycPtQ/14072371-12/a15cfba90b90171cfc47b0-
30751894b6 [consulté le 10 Aout 2014]
- Hess, K., Newman, A., 2010 : Virtualiser ou ne pas virtualiser. In Hess, K.,
Newman, A., ed 2010. Virtualisation en pratique. Pearson Education, Paris,
France, Chap 1.

BIBLIOGRAPHIE
http://www.pearson.fr/resources/download.cfm?GCOI=27440100649500&th
efile=2410_chap01.pdf [consulté le 24 Novembre 2014]
- Kolyshkin, K., 2006 : Virtualization in Linux. Livre blanc. OpenVZ, 5 p.
http://download.openvz.org/doc/openvz-intro.pdf [consulté le 10 Novembre
2014]
- Laarouchi, Y., 2009 : Sécurités (immunité et innocuité) des architectures
ouvertes à niveaux de criticité multiples : application en avionique. Thèse de
Doctorat de l’Université de Toulouse, Institut National des Sciences Appliquées,
spécialité systèmes Informatiques, France, 67-83.
http://eprint.insa-toulouse.fr/archive/00000333/01/2009_Laarouchi.pdf
[consulté le 17 Septembre 2014]
- Lavigne, Y., 2011 : Consolidation des ressources informatiques et continuité de
service. Mémoire pour l’obtention du diplôme d’ingénieur CNAM
(Conservatoire National des Arts et Métiers), Nord Pas-de-Calais, spécialité
informatique, option système d’information, France, 35-44.
http://dumas.ccsd.cnrs.fr/docs/00/59/43/28/PDF/2011.TH16916.lavigne.yan
nick.pdf [consulté le 6 Juillet 2014]
- Nagarajayya, N., 2008 : Getting Started With OpenSolaris Project Crossbow or
Network Virtualization. Livre blanc. Sun Microsystems, USA, 24 p.
http://s3.amazonaws.com/ppt-download/getting-started-with-opensolaris-
project-crossbow-or-network3761.pdf?response-content-
disposition=attachment&Signature=qbADF6%2F%2BLgoxM%2FpPJUUxR%2Fr
o2XE%3D&Expires=1414533267&AWSAccessKeyId=AKIAI6DXMWX6TBWAHQ
CQ [consulté le 28 Octobre 2014]

BIBLIOGRAPHIE
- ONF, 2012 : Software-Defined Networking: The New Norm for Networks. Livre
blanc. Open Networking Foundation, USA, 12 p.
https://www.opennetworking.org/images/stories/downloads/sdn-
resources/white-papers/wp-sdn-newnorm.pdf [consulté le 1er Septembre
2014]
- Oracle, 2013 : Oracle VM VirtualBox-User Manual. Manuel d’utilisation.
Version 4.3.0. Oracle, USA, 91-101.
http://dlc.sun.com.edgesuite.net/virtualbox/4.3.0/UserManual.pdf [consulté
le 4 Septembre 2014]
- Oracle, 2012: Using Virtual Networks in Oracle Solaris 11.1. Livre blanc. Oracle,
68 p. https://docs.oracle.com/cd/E26502_01/pdf/E28992.pdf [consulté le 21
Novembre 2014]
- Primet, P., Mornard, O., Gelas, J-P., 2007: Evaluation des performances réseau
dans le contexte de la virtualization Xen. Colloque Francophone sur l'Ingénierie
des Protocoles (CFIP), Mars 2008, Les Arcs, France. <hal-00250589>, 7-8.
https://hal.archives-ouvertes.fr/hal-00250589/document [consulté le 4
Septembre 2014]
- Pujolle, G., 2006 : Les réseaux. 5ème édition. ISBN : 2-212-11987-9, Eyrolles,
Paris, France, 851-853.
- Raynaud, P., 2011 : Déploiement d’une solution de virtualisation au sein d’une
multinationale. Mémoire pour l’obtention du diplôme d’ingénieur CNAM
(Conservatoire National des Arts et Métiers), Limoges, spécialité informatique,
11-13.
http://dumas.ccsd.cnrs.fr/docs/00/58/76/61/PDF/2011.TH16880.raynaud.phi
lippe.pdf [consulté le 21 aout 2014]

BIBLIOGRAPHIE
- Santy, F., 2010 : La virtualisation. Projet de recherche et communication

scientifique. Université Libre de Bruxelles, Faculté des Sciences, Département
d’Informatique, 1-22.
http://student.ulb.ac.be/~fsanty/cours/ba3/rechcom/virtualisation.pdf
[consulté le 4 Juillet 2014]
- Sun, 2008 : Guide d’administration Solaris ZFS. Livre blanc. Sun Microsystems,
USA, 33-34 et 91-97.
http://ftp.halpanet.org/doc/guide_zfs.pdf [consulté le 8 Décembre 2014]
- Techini, N. ,2011 : Configuration et mise en place d’un Datacenter sécurisé
dans un environnement virtuel. Rapport de projet de fin D'ETUDES pour
l'obtention du diplôme : Mastère Professionnel en Nouvelles Technologies
des Télécommunications et Réseaux. Université Virtuelle de Tunis, 3-7.
http://pf-mh.uvt.rnu.tn/627/1/Configuration_et_mise_en_place_d%-
27un_Datacenter_s%C3%A9curis%C3%A9_dans_un_environnement_virtuel.p
df [consulté le 13 Juin 2014]
- Tripathi, S., Droux, N., Belgaied, K. et Khare, S., 2009 : Crossbow Virtual Wire :
Network in a Box. Livre blanc. Sun Microsystems, USA, 17p.
https://www.usenix.org/legacy/event/lisa09/tech/full_papers/tripathi.pdf
[consulté le 15 Octobre 2014]
- Victor, J., Cotten, P., 2010 : Solaris : Zones and Containers FAQ. Guide de
réponses aux questions les plus fréquentes sur les zones Solaris. Oracle, USA,
19p.
- VMware, 2007: Understanding Full virtualization, Paravirtualization and
Hardware Assist. Livre blanc. VMware, USA. 17p
http://www.vmware.com/files/pdf/VMware_paravirtualization.pdf [consulté
le 17 Septembre 2014]

BIBLIOGRAPHIE
- Zanella, P. et Ligier, Y., 2008 : Architecture et technologie des ordinateurs. 4ème

édition. ISBN : 2 10 049367 1, DUNOD, Paris, France, 157-164.
WEBOGRAPHIE
- Apache, 2014: mod_proxy-Apache HTTP Server Version 2.2. Apache Software
Foundation, USA.
http://httpd.apache.org/docs/2.2/mod/mod_proxy.html [consulté le 8
Décembre 2014]
- BIPM, 2014 : Préfixes SI. Bureau International des Poids et Mesures.
http://www.bipm.org/fr/measurement-units/prefixes.html [consulté le 1er
Décembre 2014]
- DB-engines, 2014 : DB-Engines Ranking-popularity ranking of database
management systems.
http://db-engines.com/en/ranking [consulté le 20 Décembre 2014]
- Debian, 2013: Meeting Minimal Hardware Requirements.
https://www.debian.org/releases/etch/hppa/ch03s04.html.en [consulté le
1er décembre 2014]
- Guerrini, Y., 2014 : Comparatif : les solutions gratuites de virtualisation.
http://www.tomshardware.fr/print/solutions-gratuites-virtualisation-hyperv-
vsphere,reviews-907.html [consulté le 24 Novembre 2014]
- Guerrini, Y., 2013 : Comparatif virtualisation : les solutions gratuites.
http://www.tomshardware.fr/print/virtualisation-serveur-hyperviseur-
gratuit-logiciels,reviews-9.html [consulté le 17 Novembre 2014]
- ISC, 2014: BIND | Internet System Consortium.
http://www.isc.org/downloads/bind/ [consulté le 3 Décembre 2014]

BIBLIOGRAPHIE
- Klimov, J., 2014: Distributions – illumos. illumos wiki.

http://wiki.illumos.org/display/illumos/Distributions [consulté le 23
Novembre 2014]
- Lumsden, A., 2011: Frequently Asked Questions-OpenIndiana-OpenIndiana
Wiki.
- McWhirter, S., Wiedenroth, S., 2014: Hardware Requirements – SmartOS
Documentation – SmartOS Wiki.
https://wiki.smartos.org/display/DOC/Hardware+Requirements [consulté le
1er Novembre 2014]
- Oracle, 2010a: Oracle Solaris ZFS File System (Introduction).
https://docs.oracle.com/cd/E19253-01/819-5461/6n7ht6qr5/index.html
[consulté le 1er Décembre 2014]
- Oracle, 2010b: About Branded Zones and the Linux Branded Zone.
https://docs.oracle.com/cd/E19683-01/817-1592/gchhy/index.html [consulté
le 23 Novembre 2014]
- Rowe, W., 2014: Nginx vs Apache.
https://anturis.com/blog/nginx-vs-apache/ [consulté le 3 Décembre 2014]
- Sekkaki, N., 2007 : Nicolas Sekkaki (IBM France) : "Nous espérons réduire de
42 % la consommation d'énergie de nos centres de données". Interview de
Nicolas Sekkaki, DG d’IBM Global Technology Services France.
http://www.journaldunet.com/solutions/0705/070521-3q-ibm-green-
project.shtml [consulté le 1er Décembre 2014]
- Singh, A., 2004 : An introduction to virtualization.
www.kernelthread.com/publications/virtualization/. [consulté le 4 Juillet
2014]

BIBLIOGRAPHIE
- VMware, 2014 : Server Virtualization and Consolidation.

http://www.vmware.com/consolidation/overview [consulté le 17 Novembre
2014]
- W3techs, 2014: Usage Survey of Web Servers broken down by Ranking. Web
Technology Surveys
http://w3techs.com/technologies/cross/web_server/ranking [consulté le 4
Décembre 2014]

ANNEXES
ANNEXES
77
ANNEXES
ANNEXE A : Les défis de la virtualisation sur

l’architecture x86
Bien que largement répandu, le jeu d’instructions de l’architecture x86
n’est pas exempt de défauts. Si cette architecture se prête mal à la
virtualisation, c’est à cause de 18 instructions dites critiques. Ces instructions
critiques sont des instructions sensibles à la configuration (instructions qui ont
la possibilité d’interroger ou de modifier la configuration du système comme
par exemple le mode du processeur ou la quantité de mémoire allouée à un
processus particulier) mais qui ne font pas partie des instructions privilégiées.
D’un point de vue pratique, les instructions d’un processeur sont

réparties en plusieurs catégories (ou niveaux d’abstraction) appelées
anneaux. Un processeur qui implémente l’architecture x86 dispose de quatre
anneaux où chaque anneau correspond à un certain niveau de privilèges. Si
nous appelons D(i) le niveau de privilège accordé aux applications qui
s’exécutent sur l’anneau i, nous pouvons définir la relation suivante sur les
anneaux : D(3) < D(2) < D(1) < D(0)

ANNEXES
Figure A - 1 : Niveau de privilège dans les processeurs de l’architecture x86
Les instructions critiques nécessitent en théorie de s’exécuter au niveau

de privilège le plus élevé, c.-à-d. à l’anneau 0. Le problème de 18 de ces
instructions critiques, est qu’elles peuvent également s’exécuter aux anneaux
1, 2 et 3. Cela constitue un réel problème pour les logiciels de virtualisation.
En effet, il ne faut en aucun cas qu’un système virtuel ait la possibilité de
modifier les ressources physiques de la machine. Il est donc du ressort de
l’hyperviseur d’intercepter ces instructions critiques de manière à simuler leur
comportement.
Du point de vue des instructions privilégiées, aucun problème ne se

pose : ces instructions vont être piégées (puisque le système virtuel est
exécuté à l’anneau 3) et l’hyperviseur pourra les traiter. Mais pour ces 18
instructions critiques, la situation est plus complexe. Comme elles ne seront
pas piégées (puisqu’elles ne nécessitent pas un niveau de privilège très élevé),
l’hyperviseur doit être en mesure de les détecter de manière à pouvoir les

ANNEXES
interpréter. Il en résulte évidemment une surcharge de calcul importante ainsi

qu’une grande complexité de l’hyperviseur.
D’autre part, les systèmes d’exploitation sont conçus pour être exécuté
au niveau de privilèges 0, puisqu’ils sont sensés disposer d’un contrôle total
des ressources. Or, lorsqu’ils sont virtualisés, les systèmes d’exploitation ne
sont plus exécutés sur l’anneau 0, mais sur l’anneau 3. L’hyperviseur doit donc
être en mesure de leurrer le système d’exploitation virtualisé afin que celui-ci
ne se rende pas compte qu’il s’exécute avec un faible niveau de privilèges.
Pour plus d’informations, prière consulter : Analysis of the Intel

Pentium’s Ability to support a Secure Virtual Machine Monitor (John Scott
Robin et Cynthia Irvine) disponible à l’adresse:
https://www.usenix.org/legacy/events/sec2000/full_papers/robin/robin.pdf
[consulté le 20 Décembre 2014] ou l’article Formal requirements for
virtualizable third generation architectures de Geral J. Popek et Robert P.
Goldberg (revue “Communications of the ACM“, Volume 17, Juillet 1974,
pages 412-421).

ANNEXES
ANNEXE B : Commandes utilisées pour la mise en

place de l’environnement de simulation
Etape 1 : création du pool de stockage ZFS qui hébergera les zones
zfs create –o mountpoint=/zonefs rpool/zonefs
chmod 700 /zonefs
Etape 2 : création des étherstubs
dladm create-etherstub extswitch1
dladm create-etherstub dmzpuswitch1
dladm create etherstub routerswitch1
dladm create-etherstub routerswitch2
dladm create-etherstub cdnswitch1
Etape 3 : Création et installation d’une zone modèle
zonecfg –z zclone
zoneadm –z zclone install
Etape 4 : création des VNICs
# création des VNICs connectées à la carte physique

dladm create-vnic -l e1000g1 vphys1 # zrouter1

ANNEXES
# création des VNICs connectées aux switchs virtuels

dladm create-vnic –l extswitch1 vdmzpu0 # zrouter1
dladm create-vnic -l extswitch1 vdmzpu1 # firewall1
dladm create-vnic -l vdmzpuswitch1 vdmzpu2 # firewall1
dladm create-vnic –l routerswitch1 vdmzpu3 #firewall1
dladm create-vnic -l routerswitch1 vrouter1 # zrouter2
dladm create-vnic -l routerswitch2 vrouter2 # zrouter2
dladm create-vnic -l routerswitch2 vcdn1 # firewall4
dladm create-vnic -l cdnswitch1 vcdn2 # firewall4
dladm create-vnic –l dmzpuswitch1 vrihttp2 #rihttp2
dladm create-vnic –l cdnswitch1 vweb1 #web1
Etape 5: création, installation et démarrage des zones
 zrouter 1
# création
cat <<EOF > "/home/admin/profil_zones/zone_zrouter1"
create -b
set zonepath=/zonefs/zrouter1
set ip-type=exclusive
set autoboot=true
add net
set physical=vphys1
end
add net
set physical=vdmzpu0
end
commit
EOF
zonecfg –z zrouter1 –f /home/admin/profil_zones/zone_zrouter1

ANNEXES
#installation
zoneadm – z zrouter1 clone zclone
#démarrage
zoneadm –z zrouter 1 boot
 firewall1
# création
cat <<EOF > "/home/admin/profil_zones/zone_firewall1"
create -b
set zonepath=/zonefs/firewall1
set autoboot=true
add net
end
add net
end
add net
end
commit
EOF
zonecfg –z firewall1 –f /home/admin/profil_zones/zone_firewall1
#installation
zoneadm – z firewall1 clone zclone
#démarrage
zoneadm –z firewall1 boot

ANNEXES
 zrouter2
# création
cat <<EOF > "/home/admin/profil_zones/zone_zrouter2"
create -b
set zonepath=/zonefs/zrouter2
set autoboot=true
add net
set physical=vrouter1
end
add net
set physical=vrouter2
end
commit
EOF
zonecfg –z zrouter2 –f /home/admin/profil_zones/zone_ zrouter2
#installation
zoneadm – z zrouter2 clone zclone
#démarrage
zoneadm –z zrouter2 boot
 firewall4
# création
cat <<EOF > "/home/admin/profil_zones/zone_firewall4"
create -b
set zonepath=/zonefs/firewall4
set autoboot=true
add net

ANNEXES
set physical=vcdn1
end
add net
set physical=vcdn2
end
commit
EOF
zonecfg –z firewall4 –f /home/admin/profil_zones/zone_firewall4
#installation
zoneadm – z firewall4 clone zclone
#démarrage
zoneadm –z firewall4 boot
 rihttp2
# création
cat <<EOF > "/home/admin/profil_zones/zone_rihttp2"
create -b
set zonepath=/zonefs/rihttp2
set autoboot=true
add net
set physical=vrihttp2
end
commit
EOF
zonecfg –z rihttp2 –f /home/admin/profil_zones/zone_rihttp2
#installation
zoneadm – z rihttp2 clone zclone

ANNEXES
#démarrage
zoneadm –z rihttp2 boot
 web1
# création
cat <<EOF > "/home/admin/profil_zones/zone_web1"
create -b
set zonepath=/zonefs/web1
set autoboot=true
add net
set physical=vweb1
end
commit
EOF
zonecfg –z web1 –f /home/admin/profil_zones/zone_web1
#installation
zoneadm – z web1 clone zclone
#démarrage
zoneadm –z web1 boot
Etape 6: configuration des zones
 zrouter1
# activation du forwarding de paquets IPv4
routeadm –e ipv4-forwarding
routeadm –u
# configuration des routes

route –p add 10.0.0.32/27 192.168.1.2

ANNEXES
 firewall1
routeadm –u
route –p add 192.168.1.160/27 192.168.1.131
route –p add 192.168.1.136/29 192.168.1.131
 zrouter2
routeadm –u
route –p add 192.168.1.160/27 192.168.1.138
route –p add 10.0.0.32/27 192.168.1.129
 firewall4
routeadm –u

Route –p add 10.0.0.32/27 192.168.1.137
Route –p add 192.168.1.128/29 192.168.1.137

ANNEXES
ANNEXE C : Diagramme de séquence de l’émission d’une requête HTTP jusqu’à la génération de la réponse
rdc = réseau de données critiques

GLOSSAIRE
Cluster
En réseau et système, un cluster est une grappe de serveurs (ou « ferme
de calcul ») constituée de deux serveurs au minimum (appelés aussi nœuds)
et partageant une baie de disques commune.
Overhead
Ressource consommée ou perdue dans l'achèvement d'un processus,
qui ne contribue pas directement à la réalisation de ce dernier.
Fork
Un fork (ou embranchement) est un nouveau logiciel créé à partir du
code source d'un logiciel existant. Un fork peut être bénéfique pour un projet
donné lorsque sa gouvernance actuelle conduit à une impasse, sa reprise par
un nouveau groupe pouvant le relancer. Il peut aussi être néfaste en
provoquant un éparpillement des ressources.
System V (UNIX)
UNIX System V, ou System V (soit « système cinq ») est une version du
système d'exploitation d'origine UNIX, dévoilée par l'entreprise AT&T en
janvier 1983. System V est une version majeure d'UNIX, avec le système
386BSD, c'est une des deux principales branches de la famille des systèmes
UNIX. La plupart des systèmes UNIX propriétaires (comme AIX, HP-UX ou
encore IRIX) descendent directement de System V. Bien que Linux ne
descende pas directement de System V, il s'en inspire beaucoup du fait que

GLOSSAIRE
System V a servi de base à l'élaboration de la norme POSIX, que Linux tente

de respecter au maximum.
IT (Information Technology)
Terme regroupant toutes les formes de technologie utilisées pour créer,
stocker, échanger et utiliser l’information dans ses diverses formes.
Point de défaillance unique

Un point unique de défaillance (Single Point of Failure ou SPOF en
anglais) est un point d'un système informatique dont le reste du système est
dépendant et dont une panne entraîne l'arrêt complet du système. Le point
unique de défaillance a comme principale caractéristique de ne pas être
protégé (redondant). Il est donc un risque pour la disponibilité du système.
Plan de Reprise d’Activité
Un plan de reprise d'activité est un document qui permet à une

entreprise de prévoir, par anticipation, les démarches à entreprendre pour
reconstruire et remettre en route un système informatique en cas de sinistre
important du centre informatique. Le plan de reprise d'activité est rédigé en
tenant compte de tous les incidents qui sont susceptibles d'engendrer un
sinistre important sur le système informatique : un incendie, une panne, un
dégât des eaux.

ENGLISH VERSION
ENGLISH
VERSION

ENGLISH VERSIO
Introduction
Modern computer systems are built around a client-server architecture
where light equipment, customers, pick data and use services provided by one
or more servers, and this through a network. This may be, in terms of services,
data storage, consultation and sending of mails, use applications for
calculating or management (ERP, CRM, ...), etc. For the provision of these
services, it has long been customary to dedicate a server to a service. This
model thus prevented the malfunction of a server also prevents other run;
but required large financial resources for the acquisition of servers and
network equipment, operation (power, cooling) and maintenance.
Furthermore, the utilization rate of these servers was 5% [1] to 20% on
average [2]. This is with a view to better use of server resources and reduce
the resources needed to set up services, which has popularized the use of
virtualization. This technology already existed since the 1960s but was mostly
used on IBM mainframes like (Hess and Newman, 2010). It was in the 2000s
that the technology began to be popular with the general public. It gave the
world of computing many new opportunities; outside it possible to run
multiple servers onto fewer physical machines, or even a single physical
machine (Singh, 2004). This is a technology within the reach of all, the
individual who wishes to safely run a Linux distribution on the Windows
platform, corporations that want more value from their IT infrastructure
(Santy, 2010).
It is in the context of the use of virtualization to deploy the BJNet data

center that is part of our present work graduation.

ENGLISH VERSIO
1. Architecture of the datacenter of BJNet

The BJNet project aims for the establishment of an interconnection
network between the main structures of Defence (various military camps),
University (academic centers) and at term of the Administration.
The BJNet project to fully meet its interconnection target of the above
mentioned structures, must implement a basic service: DNS. Besides, BJNet
like to offer the following high-added value services: email service, web
hosting, file transfer, etc.
In addition to the services to be provided, the network has to guarantee

some security and availability to its customers. This therefore requires the set-
up of security solutions, namely firewalls; but also the implementation of
DMZ. The data center is also equipped with administration and network and
system monitoring tools (Dude, Nagios and OpenVAS) and will be spread over
two sites, each with a physical server.
Thus, to achieve the goals of security and availability, servers, firewalls and
monitoring tools are spread over four separate networks: the network
operations center, the public DMZ, the private DMZ and the critical data
network.
The physical architecture of BJNet data center is shown in Figure 1.

ENGLISH VERSIO
Figure 1: Physical architecture of the datacenter
This architecture seems to induce a deployment based on the "one

physical server for one service." The BJNet project however has only one
server per site and more than one operating system will be used in the data
center.
We must therefore turn to virtualization to set up servers and networks

through which they are interconnected.
2. Overview of the virtualization
2.1 Definition and domains of virtualization
Virtualization is a process that will help to mask the physical

characteristics of a computing resource to simplify the interaction between
this resource and other systems, other applications and users (Santy, 2010).
Today, virtualization impact mainly three areas: systems (comprising the

client and server sides), storage and network. (as shown on Figure 2)

ENGLISH VERSIO
Figure 2: Domains of virtualization
2.2 Different techniques of system’s virtualization
These techniques are virtualization within an OS (usage of containers or

zones), full virtualization, paravirtualization and hardware-assisted
virtualization (Intel VT-x and AMD-V).
Solutions that use containers are Linux VServer, OpenVZ, Solaris Zones, etc.
Among solutions that use full virtualization , we have Oracle VirtualBox

(type 2 hypervisor), VMware Workstation (type 2 hypervisor), VMware
vSphere (type 1 hypervisor), etc. and paravirtualisation is used mainly by Citrix
XenServer (type 1 hypervisor), VMware vSphere, Microsoft HyperV (type 1
hypervisor), …

ENGLISH VERSIO
2.3 Benefits and drawbacks of virtualization
Virtualization offers many opportunities:

 server consolidation (moving a number of physical servers to a single
server supporting a number of virtual machines)
 Reduction of costs associated with the operation of data centers
 Establishment of an easy disaster recovery plan
 Etc.
However, there are certain points that limit the immense enthusiasm
aroused by this technology:
 The need for storage capacity

 The presence of a single point of failure
 A standardization problem
3. Choice of the virtualization offer to use

The choice of suitable virtualization solution is crucial for a virtualization
project, it should take into account a number of parameters such as the
material of the host machine, the right virtualization approach, etc. Indeed,
each type of virtualization has pros and cons that affect the application that
is made.
This choice in the absolute is very difficult, and the plethora of

virtualization’s offers available does not make easy the decision. This is why it
is necessary to reduce the field of study to applicable solutions in a very
specific case (Bonnet, 2008). Our case here is that of the use of free solutions

ENGLISH VERSIO
for server virtualization, divided into 4 different networks with UNIX / Linux
distributions as the dominant operating systems.
After presenting the material and to choose the right virtualization

technology, we performed a comparison based on the criteria of
performance, supported operating systems natively and demand for
hardware resources.
Choosing the most appropriate, given the hardware and operating

systems to put in place was that of virtualization within an OS combined with
full virtualization with type 2 hypervisor.
The solutions that implement these techniques that have been selected
are OpenIndiana (incorporating Solaris zones) and VirtualBox.
The tools to implement the servers were then chosen: Apache HTTP
Server, Nginx, Perdition, BIND, MySQL, Postfix, Dovecot and IPFilter.
4. Virtual architecture of the datacenter

The ideal for the development of the data center would have been that
physical servers have 4 network interfaces; each dedicated to each of the four
networks of BJNet datacenter.
The virtual architecture was constructed taking into account constraints

routing of traffic between the four networks, the interconnection of the
VNICs, safety of traffic between the zones and the configuration of the
machines which will be create in VirtualBox.
The architecture designed is shown in the following figure.

ENGLISH VERSIO
Figure 3 : Virtual architecture of datacenter
We then make recommendations on addressing zones, installing

OpenIndiana and creating zones of the data center.
5. Simulation
The topology of the simulation environment is:
Figure 4: Architecture of simulation

ENGLISH VERSIO
Network access tests were conducted from http reverse proxy of the
public DMZ to the web server and the client to the http relay public DMZ.
These tests were conclusive and confirmed that the architecture is functional.
6. Analysis and discussion

After the design of the physical architecture of the data center, it landed
the deployment problem of all servers within a physical server. With
virtualization, we were able to establish a functional virtualization
environment for deploying BJNet data center servers.
Indeed, the choice of the use of virtualization within the operating

system allows to enjoy the lightness of zones and their cost in resources, but
also to take advantage of complementary technologies provided by the
distributions based on illumos (in this instance OpenIndiana). Also, the
proposed network architecture meets the constraints set by the work
environment and makes servers accessible from outside of the datacenter
network.
Thus, the environment set up is ready for deployment in production, but is

also extensible. Indeed, one can easily add servers on each network: the
addressing plan includes this and you just create a zone (by cloning the
template zone) and his VNIC and connect to the target network switch; or
better yet, just add a new network.
However, we have identified some areas that could be further developed.
First, the number of zones deployed here is low, the creation of such
zones was done manually and routing was done statically; but if the number
of zones is high, then it would make it more dynamic creation and routing

ENGLISH VERSIO
within the zones. This will include creating scripts to automate the
configuration and the installation of zones; and by using an appropriate
dynamic routing protocol (OSPF, RIP, etc.).
Then, in the context of this study, we have created areas with hardware
features by default. However, the data center is expected to provide services
to a number of users which is going to increase, it would be wise to conduct a
study on the material needs of the services to be provided in order to define
the resources allocated to an area.
Then, using VirtualBox adds complexity to the designed architecture

and adds a new layer of virtualization and thus a drop in performance that can
be detrimental if many OS should be well deployed. SmartOS, which is a very
good alternative to OpenIndiana if you want to virtualize different operating
systems, has not been used in our work for the integration of KVM is only
supported by Intel VT-x benefiting from technology and EFA. However, a
community working for a while on a version of SmartOS that integrates KVM
support on AMD processors. It would be interesting to test and base
architecture of the environment on it.
Finally, we propose, to the extent possible, increase the number of

servers in the cluster and to have shared storage (NAS or SAN) in order to
relocate some important services, increase service redundancy and increase
the availability of the data center.

ENGLISH VERSIO
Conclusion
This project allowed us to use virtualization to design an environment that will
allow the establishment of BJNet data center.
Virtualization is indeed a technology, which among other benefits provides

that enable the deployment of multiple servers (even running different OS)
on fewer servers, or even one. The project data center BJNet aims to provide
services such as DNS, mail hosting websites to defense structures of the
University and Administration it interconnects. He was faced with the
problem of deployment of multiple servers in four networks on a single
physical machine. We compared the various techniques of virtualization and
have given the material available and the constraints of this case study,
selected the suitable techniques: that of virtualization within an OS combined
with that of full virtualization. The successful OS was OpenIndiana and type 2
hypervisor was VirtualBox. We then chose the tools that will be installed on
each server and have built virtual architecture of the data center. It includes
virtual network adapters, switches and routers areas. We have also made
recommendations that can help to effectively deploy the necessary areas. The
simulation performed allowed us to demonstrate the effective operation of
our environment.
In further studies, we propose to study the resource demands of the tools to

set up on the servers in order to size the resources to be allocated to virtual
machines to create. Another perspective would be to study the increase in the
availability of the data center by adding shared storage or integration of high-
availability cluster tools.

TABLES DES MATIERES
SOMMAIRE.......................................................................................................... i
DEDICACES ......................................................................................................... ii
REMERCIEMENTS .............................................................................................. iii
LISTE DES SIGLES ET ABREVIATIONS ................................................................... v
LISTE DES TABLEAUX ........................................................................................ viii
LISTE DES FIGURES .............................................................................................ix
RESUME ............................................................................................................. x
ABSTRACT ..........................................................................................................xi
INTRODUCTION GENERALE ................................................................................ 1
1. Contexte, justification et problématique ................................................. 2
2. Objectifs ................................................................................................... 3
CHAPITRE 1 : ETUDE DE L’EXISTANT ................................................................... 5
1.1 Présentation du projet BJNet ................................................................... 6
1.2 Intérêt de la mise en place d’un centre de données................................ 6
1.3 Architecture physique du centre de données de BJNet........................... 7
1.4 Les contraintes liées au centre de données de BJNet ............................ 12
CHAPITRE 2 : LA VIRTUALISATION .................................................................... 13
2.1 Concepts de la virtualisation .................................................................. 14
2.2 Domaines de la virtualisation ................................................................. 16
2.3 Différentes techniques de virtualisation système .................................. 18
2.3.1 Approches centrées sur les applications .......................................... 19

TABLES DES MATIERES
2.3.1.1 L’émulation................................................................................ 19
2.3.1.2 Le cloisonnement (virtualisation au sein d’un OS) ..................... 20
2.3.2 Approches centrées sur les systèmes ............................................. 21
2.3.2.1 Le cloisonnement (virtualisation au sein d’un OS) ..................... 21
2.3.2.2 La virtualisation complète .......................................................... 22
2.3.2.3 La paravirtualisation ................................................................... 23
2.3.2.4 La virtualisation assistée par le matériel .................................... 24
2.4 Avantages de la virtualisation................................................................. 24
2.5 Limites à la virtualisation ........................................................................ 25
CHAPITRE 3 : CHOIX DE LA SOLUTION DE VIRTUALISATION ............................. 26
3.1 Présentation des caractéristiques de la machine hôte .......................... 27
3.2 Choix des techniques de virtualisation adéquates ................................. 30
3.2.1 Comparaison entre les techniques de virtualisation ........................ 30
3.2.1.1 La virtualisation au sein d’un OS ou cloisonnement .................. 30
3.2.1.2 La virtualisation complète .......................................................... 31
3.2.1.3 La paravirtualisation ................................................................... 32
3.2.2 Techniques de virtualisation choisies ............................................... 33
3.3 Solution de virtualisation retenues pour le centre de données ............. 35
3.4 Choix des outils à utiliser sur les serveurs .............................................. 37
3.4.1 Le serveur DNS ................................................................................. 38
3.4.2 Le serveur web ................................................................................. 38
3.4.3 Le relais inverse HTTP (HyperText Transfer Protocol) ...................... 38

TABLES DES MATIERES
3.4.4 Le serveur mail ................................................................................. 39
3.4.5 Le relais SMTP (Simple Mail Transfer Protocol) ............................... 39
3.4.6 Le relais POP/IMAP ........................................................................... 40
3.4.7 Le serveur de bases de données ................................................... 40
3.4.8 Les pare-feux ................................................................................. 40
CHAPITRE 4 : ARCHITECTURE VIRTUELLE DU CENTRE DE DONNEES ET

RECOMMANDATIONS DE DEPLOIEMENT ......................................................... 42
4.1 Architecture de l’environnement virtuel................................................ 43
4.2 Définition des recommandations pour le déploiement ......................... 50
4.2.1 Plan d’adressage des zones .............................................................. 50
4.2.2 Déploiement et configuration de OpenIndiana ............................... 52
4.2.3 Création des machines virtuelles ..................................................... 52
CHAPITRE 5 : SIMULATION ET TESTS ................................................................ 56
5.1 Présentation de l’environnement de simulation ................................... 57
5.2 Tests effectués ....................................................................................... 61
5.2.1 Tests d’accès au serveur web du centre de données critiques à

partir du relais inverse HTTP de la DMZ publique ..................................... 61
5.2.2 Test d’accès au relais inverse HTTP de la DMZ publique à partir du

client .......................................................................................................... 62
CHAPITRE 6 : ANALYSE ET DISCUSSION ............................................................ 64
CONCLUSION ET PERSPECTIVES ....................................................................... 68
BIBLIOGRAPHIE ................................................................................................ 69

TABLES DES MATIERES
ANNEXES .......................................................................................................... 77
ANNEXE A : Les défis de la virtualisation sur l’architecture x86 ................... 78
ANNEXE B : Commandes utilisées pour la mise en place de l’environnement

de simulation ................................................................................................ 81
ANNEXE C : Diagramme de séquence de l’émission d’une requête HTTP

jusqu’à la génération de la réponse ............................................................. 88
GLOSSAIRE ....................................................................................................... 89
ENGLISH VERSION ............................................................................................ 91
Introduction.................................................................................................. 92
1. Architecture of the datacenter of BJNet ................................................ 93
2. Overview of the virtualization ................................................................ 94
2.1 Definition and domains of virtualization ............................................. 94
2.2 Different techniques of system’s virtualization ............................... 95
2.3 Benefits and drawbacks of virtualization ......................................... 96
3. Choice of the virtualization offer to use................................................. 96
4. Virtual architecture of the datacenter ................................................... 97
5. Simulation............................................................................................... 98
6. Analysis and discussion .......................................................................... 99
Conclusion .................................................................................................. 101
TABLES DES MATIERES ................................................................................... 102

CONCEPTION D'UN ENVIRONNEMENT VIRTUEL POUR LE DEPLOIEMENT D'UN CENTRE DE DONNEES: CAS DE BJNet

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

CONCEPTION D'UN ENVIRONNEMENT VIRTUEL POUR LE DEPLOIEMENT D'UN CENTRE DE DONNEES: CAS DE BJNet

Transféré par

Droits d'auteur :

Formats disponibles

RÉPUBLIQUE DU BÉNIN

Option : Réseaux Informatiques et Internet (RII)

MEMOIRE DE FIN DE FORMATION

DIPLOME D’INGENIEUR DE CONCEPTION

Année Académique : 2013 – 2014

REMERCIEMENTS .............................................................................................. iii

LISTE DES SIGLES ET ABREVIATIONS ................................................................... v

LISTE DES TABLEAUX ........................................................................................ viii

LISTE DES FIGURES .............................................................................................ix

INTRODUCTION GENERALE ................................................................................ 1

CHAPITRE 1 : ETUDE DE L’EXISTANT ................................................................... 5

CHAPITRE 2 : LA VIRTUALISATION .................................................................... 13

CHAPITRE 3 : CHOIX DE LA SOLUTION DE VIRTUALISATION ............................. 26

CHAPITRE 4 : ARCHITECTURE VIRTUELLE DU CENTRE DE DONNEES ET

CHAPITRE 5 : SIMULATION ET TESTS ................................................................ 56

CHAPITRE 6 : ANALYSE ET DISCUSSION ............................................................ 64

CONCLUSION ET PERSPECTIVES ....................................................................... 68

ENGLISH VERSION ............................................................................................ 91

TABLES DES MATIERES ................................................................................... 102

Réalisé par Joris Dagbégnon FAGBEMIRO i

Mon père Zacharie FAGBEMIRO MARTIN,

Ma mère Rita QUENUM,

Ma sœur Fèmi Iris et son époux Victorin,

Mon frère Kayodé.

Merci de m’avoir toujours soutenu et d’avoir cru en moi.

Dagbégnon Joris FAGBEMIRO

Réalisé par Joris Dagbégnon FAGBEMIRO ii

Je remercie en premier lieu le Seigneur Dieu Tout-Puissant pour

Je remercie aussi tous ceux qui, de près ou de loin, ont participé à la

- Au Professeur Félicien AVLESSI, Directeur de l’Ecole

Réalisé par Joris Dagbégnon FAGBEMIRO iii

- A Arnaud QUENUM (Ingénieur chez NetApp en France), Gildas DA

Réalisé par Joris Dagbégnon FAGBEMIRO iv

Réalisé par Joris Dagbégnon FAGBEMIRO v

Réalisé par Joris Dagbégnon FAGBEMIRO vi

UCL : Université Catholique de Louvain

Réalisé par Joris Dagbégnon FAGBEMIRO vii

Tableau III.I : Caractéristiques matérielles des serveurs du projet BJNet .... 28

Réalisé par Joris Dagbégnon FAGBEMIRO viii

Figure 1.1: Architecture physique du centre de données de BJNet .................. 11

Réalisé par Joris Dagbégnon FAGBEMIRO ix

Le déploiement du centre de données de BJNet passe par la mise en

Mots-clés : virtualisation, Zones Solaris, OpenIndiana, CrossBow

Réalisé par Joris Dagbégnon FAGBEMIRO x

Keywords: virtualization, Solaris Zones, OpenIndiana, CrossBow

Réalisé par Joris Dagbégnon FAGBEMIRO xi

Les systèmes informatiques modernes sont construits autour d’une

Réalisé par Joris Dagbégnon FAGBEMIRO 1

1. Contexte, justification et problématique

BJNet souhaite offrir aussi à ses clients, outre l’interconnexion et l’accès à

Cependant, le projet ne dispose que de deux serveurs physiques, qui

Réalisé par Joris Dagbégnon FAGBEMIRO 2

constituant le datacenter de BJNet, on ne dispose que d’un serveur physique.

C’est donc dans le cadre de l’utilisation de la virtualisation, pour le

Plus spécifiquement, il s’agira pour nous :

 de choisir, à la lumière des contraintes spécifiques au contexte d’étude,

Le présent mémoire fait le point de nos travaux et comprend six chapitres:

 Les deux premiers nous permettront de mieux présenter le centre

Réalisé par Joris Dagbégnon FAGBEMIRO 3

consacré à la conception de l’architecture virtuelle des serveurs à

Enfin, nous conclurons par un point de nos travaux et par la proposition

Réalisé par Joris Dagbégnon FAGBEMIRO 4

1.1 Présentation du projet BJNet