TABLE DES MATIERES

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

PARTIE I : PRESENTATION ET RAISON DE CHOIX DU THEME........................................................2

1) Raison du choix du thème :........................................................................................................................................... 2

2) Intérêt du sujet :............................................................................................................................................................ 3

4) Fonctionnement de la virtualisation :............................................................................................................................. 6

a) Mécanisme :............................................................................................................................ 6

b) Usage :.................................................................................................................................... 6

5) Moyen de réaliser le projet :.......................................................................................................................................... 7

a) Un hyperviseur appelé « Xenserveur » :..................................................................................7

b) Une hyperviseur de type 1 :..................................................................................................... 7

c) Utilisation des logiciels comme NX et TLS............................................................................8

6) Objectif et résultat attendu :.......................................................................................................................................... 8

a) Objectif du projet :.................................................................................................................. 8

b) Résultat attendu :.................................................................................................................... 8

Conclusion :.................................................................................................................................................................... 10

CHAPITRE I : LA PRINCIPE DE LA VIRTUALISATION :....................................................................11

1) Historique :................................................................................................................................................................. 11

2) Définition :.................................................................................................................................................................. 12

3) Virtualisation dans les systèmes informatiques............................................................................................................ 14

a) Virtualisation du stockage de données................................................................................... 14

b) Virtualisation des serveurs.................................................................................................... 15

c) Virtualisation des applications.............................................................................................. 16

1) Virtualisation dans les environnements réseaux :........................................................................................................ 17

a) Réseaux locaux virtuels......................................................................................................... 17

b) Virtual Private Network (VPN)............................................................................................. 18

c) Réseaux de recouvrement...................................................................................................... 19

d) Réseaux actifs et programmables.......................................................................................... 19

2) Projets de virtualisation de réseaux............................................................................................................................. 20

a) Technologie du réseau (X-Bone)........................................................................................... 21

 b) Couche de virtualisation (Emulab)........................................................................................21

c) Domaine architectural (CABO)............................................................................................. 22

d) Niveau de virtualisation (PlanetLab)..................................................................................... 23

3) Intérêt de la Virtualisation :......................................................................................................................................... 24

a) La sécurité............................................................................................................................. 24

b) Le coût.................................................................................................................................. 25

c) Criticité et performances....................................................................................................... 26

4) Types de virtualisation :.............................................................................................................................................. 27

a) La virtualisation au niveau du système d’exploitation...........................................................27

b) La virtualisation totale.......................................................................................................... 28

c) La virtualisation matérielle assistée....................................................................................... 29

d) La paravirtualisation............................................................................................................. 31

e) La virtualisation Hybride...................................................................................................... 32

5) Les avantages de la virtualisation :.............................................................................................................................. 33

CHAPITRE II : LES HYPERVISEURS :................................................................................................... 34

1) Le fonctionnement des hyperviseurs........................................................................................................................... 34

2) Les différents types des hyperviseurs.......................................................................................................................... 36

a) Les hyperviseurs de type 1.................................................................................................... 36

b) Les hyperviseurs de type 2.................................................................................................... 37

3) Quelques exemples d’hyperviseur............................................................................................................................... 38

a) VMWare vSphere Hypervisor............................................................................................... 38

b) Citrix Xenserveur.................................................................................................................. 39

c) Proxmox............................................................................................................................... 40

4) Caractéristiques et utilisation des outils de virtualisation :........................................................................................... 41

PARTIE III : MATHODOLOGIE ET PRESENTATION DU XEN...........................................................44

CAPITRE I : METHODOLOGIE :............................................................................................................. 44

Introduction..................................................................................................................................................................... 44

1) Système d’information avant la virtualisation :........................................................................................................... 44

a) Inventaire des ordinateurs et des servers :.............................................................................45

b) Inventaire des progiciels :..................................................................................................... 45

2) Système informatique avec virtualisation.................................................................................................................... 46

a) Solution adoptée :............................................................................................................................... 46

b) Les Besoins fonctionnels :.................................................................................................................. 47

 Installation de Citrix XenServer :................................................................................................................................ 47

 Installation d’Active Directory :.................................................................................................................................. 48

 Installation de serveur Terminal Server :..................................................................................................................... 48

 Installation de serveur NX (NoMachine)..................................................................................................................... 49

CHAPITRE II : PRESENTATION DU XEN............................................................................................. 51

Introduction..................................................................................................................................................................... 51

1) Les interactions entre l’hyperviseur, les applications, et le système d’exploitation......................................................51

2) Les domaines.............................................................................................................................................................. 54

a) Domaine privilégié................................................................................................................ 54

b) Domaines non-privilégiés..................................................................................................... 55

c) Domaines matériels assistés.................................................................................................. 56

3) L’architecture du Xen en paravirtualisation................................................................................................................. 57

a) La gestion des informations système........................................................................................................................... 57

b) La communication inter domaines............................................................................................................................... 59

c) La gestion du temps.................................................................................................................................................... 61

d) La gestion de mémoire................................................................................................................................................ 63

i. Modèle de gestion de mémoire en para-virtualisation...........................................................63

ii. Mise à jour de la table des pages........................................................................................... 65

iii. La création d’un DomU : l’aspect mémoire...........................................................................65

iv. Les gestions des fautes de pages........................................................................................... 66

e) La gestion de l'ordonnancement.................................................................................................................................. 66

4) Le réseau sous Xen...................................................................................................................................................... 69

PARTIE IV : SIMILATION ET IMPACT DU PROJET............................................................................71

Introduction :.............................................................................................................................................. 71

4.1. Environnement de travail :................................................................................................................... 71

4.1.1. Matériels :............................................................................................................................................................. 71

4.1.2. Logiciels :.............................................................................................................................................................. 72

4.2. Description de l’application :............................................................................................................... 73

4.2.1. Installation de Citrix XenServer :......................................................................................................................... 73

4.2.2. Installation du XenCenter 7.0 :............................................................................................................................. 76

4.2.3. Ajout d’une machine virtuelle :............................................................................................................................. 78

4.2.4. Installation de Windows 2012 serveur :................................................................................................................. 79

4.2.5. Installation d’Active Directory :............................................................................................................................ 81

4.3.1 Mise en œuvre a la solution Xen :.......................................................................................................................... 85

4.3.2 impact et solution du projet :.................................................................................................................................. 85

CONCLUSION GENERAL :..................................................................................................................... 87
 INTRODUCTION GENERALE

Actuellement, le monde informatique entre dans une ère où on doit traiter des
données massives et des calculs lourds. Avec l’évolution de la technologie, nous sommes
obligés de travailler avec des énormes quantités de mémoires et des processeurs puissants
pour que les traitements se fassent dans une latence minime de temps. Or, une méthode
parmi tant d'autres a été trouvée depuis lors avec la construction de système de distribution
de stockages et de traitements de données.

La virtualisation est un sujet d'actualité pour les acteurs de l'industrie des systèmes
d'informations. Etant donnée notre entrée imminente sur le marché de travail, acquérir des
connaissances dans ce domaine constitue une valeur ajoutée à notre formation. La
virtualisation est applicable dans de multiples domaines des systèmes d'information.
Cependant, nous ne traiterons ici uniquement de la virtualisation de systèmes
d'exploitation.

Or, l’augmentation des besoins des utilisateur sur un serveur entrain la perte de
temps pour le traitement des données. Sur ce la virtualisation est-il nécessaire ?

Les technologies de virtualisation sont actuellement adoptées à différents niveaux :

ordinateurs de bureau, serveurs, applications et également, pour le stockage ; ces sont
l’infrastructure du réseau qui virtualisent. C’est pourquoi, on a adopté le thème de cet
ouvrage « Optimisation des sources réseaux via virtualisation » qu’on subdivise en
quatre Parties.

Dans le cadre de la première partie, nous effectuerons une présentation sur le thème
choisi. Puis, nous effectuerons un tour d'horizon de la virtualisation et L’hyperviseur.
Ensuite l’étude et la méthodologie permettant de réaliser du projet et la présentation du
Xen. Enfin nous présentons quelque simulation pour montrer les résultats attendus.

1
 PARTIE I : PRESENTATION ET RAISON DE CHOIX DU THEME

Dans cette Partie, nous commençons de distinguer les raisons du thème choisie,
puis la présentation du problématique, ensuite fonctionnements et les moyens pour la
réalisation, et en fin l’objectif et les résultats attendu.

1) Raison du choix du thème :

La plupart des entreprises, les services informatiques sont négligeables à plusieurs

raisons :

- Matériels et coût : même s’ils ont envie de se lancer plus loin, la connaissance au
développement d’une architecture informatique est l’un des principaux obstacles.
D’autre part, les prix des matériaux sont élevés (RAM, disque dur, processeur…)
- Temps : le lancement des applications, des bases de données, les utilisateurs n’ont
pas le choix que d’attendre si leur ordinateur est à faible capacité.
- Serveur et réseaux : le prix des serveurs et des équipement réseaux sont élevés, du
cotés dépannages, les technicien et administrateur réseaux s’engagent davantage
aux détections des pannes et des mises en réseaux.

2
 2) Intérêt du sujet :

Pour le particulier, la virtualisation permet d’avoir accès à des applications ne

fonctionnant pas sur le système d’exploitation principal de l’utilisateur. On peut
notamment citer les applications trop vieilles pour s’exécuter sur la dernière génération
du système d’exploitation. Un autre domaine couvert par la virtualisation est l’utilisation
de programmes non portés sur la plate-forme cible (architecture PC vs architecture Mac
1, par exemple). On peut aussi citer, même si c’est plus rare, l’utilisation de virtualisation
pour les jeux : faire fonctionner un jeu fait pour Microsoft Windows dans une machine
virtuelle s’exécutant sur un système GNU/Linux.

Pour les professionnels et les chercheurs en sécurité, un système d’exploitation

virtualisé permet d’observer le comportement d’un logiciel malveillant virus, ver,
spyware, etc. Dans un système sain sans avoir à infecter une machine physique. De plus,
le processus d’infection est reproductible, car il suffit de sauvegarder l’état de la machine
virtuelle avant l’infection pour pouvoir répéter l’opération plusieurs fois, dans des
conditions contrôlées. Il est alors possible d’analyser l’état de la machine virtuelle après
infection, et de tirer des conclusions sur l’action du logiciel.

Pour une entreprise, les technologies de virtualisation permettent de séparer des

applications et des systèmes de manière logique, quand les prérequis des applications sont
mutuellement exclusifs. Par exemple, une application critique mais incompatible avec
une version donnée d’un logiciel ne peut pas cohabiter sur la même machine avec une
autre application dépendant d’une autre version du même logiciel. Certains cas
d’incompatibilités peuvent se résoudre en laissant installés les deux logiciels dans deux
versions différentes, mais le surcoût de maintenance est non négligeable.

En plus de la simple incompatibilité de versions, deux applications peuvent aussi

avoir le même rôle, mais dans des contextes différents. Par exemple une version de
développement et une version finale d’un site web ne peuvent pas cohabiter de manière
simple, à moins d’y consacrer un effort de maintenance là aussi conséquent. Pour le
développement d’une application web, le test du site sous plusieurs navigateurs est
primordial. La virtualisation de plusieurs systèmes d’exploitation permettra aux
développeurs de tester le rendu de plusieurs navigateurs sur plusieurs plates-formes sans
avoir à changer de machine et donc d’environnement de travail en permanence.
3
 Au-delà de la possibilité de faire fonctionner des applications qui ne peuvent
normalement pas s’exécuter sur une machine donnée, la virtualisation permet aussi de les
rassembler sur une même machine physique, sans avoir à maintenir un serveur distinct
par application. Traditionnellement, l’usage était de consacrer une machine physique à un
service (messagerie, stockage, hébergement d’intranet, etc.), tant pour des raisons
pratiques (associer une machine à un rôle unique) que pour la sécurité (séparation des
services).

Toutefois, cette dispersion a un coût qui n’est pas nul pour l’entreprise, que ce soit
en espace occupé (location au mètre carré dans les Datacenter*), en énergie
(consommation électrique) ou en maintenance (plus de machines physiques implique plus
de risques de pannes matérielles). De plus, la plupart des services fournis sur un réseau
local (DHCP, DNS, Intranet, ...) ne consomment qu’une très faible partie des ressources
offertes par une machine récente. Tous ces facteurs font qu’il n’est plus pertinent
aujourd’hui d’utiliser des machines séparées pour héberger des services ne nécessitant
qu’une fraction de la puissance d’une machine.

Aussi, à l’heure actuelle, la tendance est plutôt au rassemblement de plusieurs

services, autrefois distincts, sur une seule machine, par le biais de l’utilisation de
technologies de virtualisation pour maintenir une séparation entre les services. On parle
de consolidation de serveurs.
Enfin, l’utilisation d’applications « anciennes » (au sens informatique du terme) est
au moins aussi importante chez les entreprises que chez les particuliers. L’importance
parfois critique de ces applications pour le fonctionnement de l’entreprise fait qu’il est
souvent plus facile de continuer à maintenir un système et une machine obsolètes (et donc
avec un risque de panne matérielle plus important) que d’entamer une migration vers une
nouvelle plate-forme. La virtualisation permet dans ce cas d’exécuter l’application
comme dans son environnement d’origine, mais sur du matériel récent. On peut citer,
sans ordre particulier : une application de comptabilité (ou un progiciel quelconque)
utilisée depuis des années mais non portée sur la nouvelle version d’un système
d’exploitation ou encore un logiciel de pilotage de machine industrielle. Ce sont deux
exemples classiques d’application de la virtualisation pour autre chose que de
l’hébergement de services.
En plus des possibilités techniques citées ci-dessus, la virtualisation est également une
technologie clef pour l’avenir de l’entreprise. En effet, elle ne permet pas seulement de
contourner les limitations matérielles des ordinateurs, mais eslle peut aussi fournir un
4
 avantage décisif sur la concurrence dans le milieu très disputé qu’est l’informatique de
services.

3) Annonce du Problématique :

La multiplication des serveurs est devenue source de problème financier et au niveau

de la gestion de l’ensemble de l’infrastructure, le fait d’utiliser un serveur pour chaque
application engendre une sur utilisation des ressources système. Le service informatique de
l’entreprise est donc obligé d’effectuer des tâches supplémentaires qui n’apportent aucune
valeur ajoutée pour l’entreprise à cause de l’utilisation de plusieurs serveurs donc la
réduction des couts d’équipements, d’exploitation et de maintenance est devenue
obligatoire.

L’insuffisance des temps de démarrage sur un server a un autre a cause de

l’augmentation des besoins des utilisateurs sur des server. Beaucoup des services installés
dans des différents de système d’exploitation. D’où les utilisateurs ont obligé de changer
de sessions pour se loger à un autre.

La saturation des ressources matériel tel que le câblage. La gestion des servers est l’un
des principaux problèmes pour la détection des pannes. Ainsi le cout élevé de l’électricité
est un grand problème financier.

5
4) Fonctionnement de la virtualisation :

a) Mécanisme :

La virtualisation repose sur le mécanisme suivant :

 Un système d’exploitation principal (appelé « système hôte ») est installé sur un

serveur physique unique. Ce système sert d’accueil à d’autres systèmes
d’exploitation.
 Un logiciel de virtualisation (appelé « hyperviseur ») est installé sur le système
d’exploitation principal. Il permet la création d’environnements clos et
indépendants sur lesquels seront installés d’autres systèmes d’exploitation
(« systèmes invités »). Ces environnements sont des « machines virtuelles ».
 Un système invité est installé dans une machine virtuelle qui fonctionne
indépendamment des autres systèmes invités dans d’autres machines virtuelles.
Chaque machine virtuelle dispose d’un accès aux ressources du serveur physique
(mémoire, espace disque…).

b) Usage :

La virtualisation permet de centraliser les trois Serveurs en un seul réseau. En cas

d’incident, la mise en place d’un Plan de retour d’activité est rapide. Les applications
installer dans ces serveurs virtuels sont utilisés davantage par les utilisateurs sans changer
leur système d’exploitation. Le système d’information de l’entreprise s’améliore mieux sur
le plan de vitesse de traitement.

6
5) Moyen de réaliser le projet :
Les moyens utilisés :

a) Un hyperviseur appelé « Xenserveur » :

Il est l’une des premières plateformes de virtualisation open source du secteur pour
la gestion des infrastructures virtuelles cloud, de serveur et de poste. Les organisations de
toute taille peuvent installer XenServer en moins de dix minutes pour virtualiser les
charges les plus contraignantes et automatiser les processus de gestion, améliorant la
souplesse et la mobilité de l’informatique.

b) Une hyperviseur de type 1 :

Il y a deux (02) type d’hyperviseur mais ce qu’on va utiliser c’est de type 1 c’est-à-
dire on l’installe l’OS du xenserveur directement dans une machine

Figure n°1.1 : Hyperviseur de type 1

7
 c) Utilisation des logiciels comme NX et TLS

NX (Nomachines X):

La technologie NX est un protocole client-serveur permettant des connexions

graphiques X11 distance. Le protocole est basé à la fois sur SSH (pour la sécurité) et sur la
compression X (pour l’interface graphique et la rapidité).
TSE (Terminal Server Edition) :

 Présentation

Terminal Server Edition permet la prise en charge de plusieurs sessions utilisateurs sur le
même serveur.

6) Objectif et résultat attendu :

a) Objectif du projet :

L’objectif principal de ce projet de virtualisation des serveurs est la réduction de la

complexité d’administration des serveurs et la volonté de réduire les dépenses acquisition
de matériels. La virtualisation des serveurs doit aussi être synonyme d’économie sur la
machine et sur la surface qu’elles occupent, elle offre l’administration simplifiée de
l’ensemble des serveurs.

b) Résultat attendu :
Aujourd’hui les entreprises sont exposées à plusieurs enjeux dont la virtualisation
leurs trouve plusieurs solutions.

Parmi ces solutions : La réduction des coûts, gain de productivité, augmentation de la

sécurité. La diminution des coûts est généralement l’enjeu n°1 des entreprises, précisément
en période de crise économique ou la stratégie repose davantage sur l’adage « faire plus
avec moins », la virtualisation présente donc un moyen technologique de baisser les
dépenses.
• Réduction des coûts de matériel :

La virtualisation permet de minimiser le nombre de serveurs physiques du parc

informatique de l’entreprise.
L’entreprise diminue ses achats de machines en utilisant la virtualisation car un seul
serveur peut supporter plusieurs systèmes et applications.
8
• Diminution des coûts immobiliers :

L’entreprise améliore son espace disponible en réduisant le nombre de serveurs de son parc
informatique.
La virtualisation permet aux grandes entreprises d’améliorer leurs dépenses vers
d’autres départements et offre ainsi un gain de place.

• Réduction des coûts de maintenance :

La virtualisation facilite la tâche de l’administrateur de système d’information de

l’entreprise car il doit s’occuper d’un nombre limité de machine et son temps est ainsi
amélioré.
Les opérations de maintenance de chaque serveur sont devenues plus faciles grâce à la
virtualisation qui permet de mutualiser plusieurs serveurs sur une même machine.

 Réduction de la facture énergétique :

La facture d’électricité diminue lorsque le nombre de serveurs physiques dans l’entreprise

réduit.

• Augmentation de la sécurité :

La sécurité du système d’information des entreprises est optimisée grâce au rôle

principal qui joue la virtualisation.
L’impact des machines virtuelles sur la sécurité est notable à plusieurs niveaux :
-Lorsque on utilise le mécanisme de virtualisation les systèmes et les applications sont
divisés dans des unités fermées appelées machines virtuelles, et isolés des autres services,
des autres machines et du reste du réseau.
-Les machines virtuelles sont distinctes du système hôte, elles possèdent des adresses IP,
un système de fichier et leur propre accès au service.
Le serveur physique devient invisible sur le réseau et il reste que les machines virtuelles
visibles.
Le déplacement des machines virtuelles d’un serveur physique à un autre est possible sans
arrêt de service.

9
10
• Tests d’applications :

Les développeurs ont l’opportunité de tester et de déboguer leurs applications avant la

mise en production par suite de l’installation de plusieurs systèmes sur une seule machine.

La mise à disposition de plusieurs machines distinctes est nécessaire pour toutes ces
procédures.

• Amélioration de la disponibilité des services de l’entreprise :

La virtualisation permet de lier des machines virtuelles à des systèmes clés de

l’entreprise (comme le stockage) et d’y garantir en permanence l’accès.

Une autre machine virtuelle permet de préserver la qualité de service lorsqu’il ya une
défaillance.

Conclusion :

A travers ce chapitre nous avons dégagé les principaux problèmes sur les
entreprises ce qui nous aide de se placer dans le contexte général, les moyens et l’objectif
de notre projet.

11
 CHAPITRE I : LA PRINCIPE DE LA VIRTUALISATION :

1) Historique :

Dans le monde de l'informatique, on définit la virtualisation comme un ensemble

des techniques matérielles et/ou logiciels qui permettent de faire fonctionner sur une seule
machine plusieurs systèmes d'exploitation et/ou plusieurs applications, séparément les uns
des autres, comme s'ils fonctionnaient sur des machines physiques distinctes. Il s’agit donc
d’utiliser une seule machine physique en remplacement de plusieurs et d’utiliser les
possibilités offertes par la virtualisation pour démultiplier le nombre de machines
virtuelles. La virtualisation remonte aux années 1960. A l’époque, c’est la firme IBM qui
créé le premier système de virtualisation de serveur. Dans ce contexte, l’informatique est
peu présente et les rares sociétés qui possèdent des systèmes informatiques sont équipées
de gros calculateurs, les Mainframe. Au cours des années 80-90 apparaît l’architecture x86
et les PC se déploie auprès d’un grand nombre d’utilisateurs. Le besoin de virtualiser pour
optimiser les machines se fait moins sentir. Mais, dans les années 90-2000, VMware réussi
à virtualiser un poste x86. Ceci ouvre la porte à plus de possibilité et relance l’envie pour
les sociétés informatiques de développer de nouvelles fonctionnalités pour optimiser et
offrir plus de flexibilité. A l’heure actuelle, la virtualisation est très connue. On entend
parler de virtualisation de serveur, de VirtualBox, départemental (Citrix metaframe), mais
aussi de virtualisation de poste de travail, de VDI, et de virtualisation dans les jeux-vidéos
avec les émulateurs. En 2012, trois grandes sociétés se partagent le marché de la
virtualisation en entreprise :

 VMware qui est le leader ;

 Citrix, très fort dans la virtualisation de poste de travail ;

 Microsoft, qui s’aligne sur la concurrence

12
 Figure2.1 : L'apparition de virtualisation

2) Définition :

La virtualisation est l’ensemble de technologie matérielle et/ou logicielle qui

permettent de faire fonctionner plusieurs OS (Operating System) et/ou plusieurs
applications sur une même machine physique, séparément les uns des autres comme s’ils
fonctionnaient sur des machines physiques distinctes.

En d'autres termes, c'est une technique qui fait référence à l’abstraction des
caractéristiques physiques de ressources informatiques, processeurs, mémoires, stockages,
carte réseau, afin de les présenter à des systèmes, des applications ou des utilisateurs sous
une forme logique.

Les ressources logiques allouées à une machine virtuelle sont abstraites à 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.
L’ordinateur hôte voit ses machines virtuelles comme des applications auxquelles il
distribue ses ressources.

13
 La virtualisation est un mécanisme informatique qui repose sur le processus
suivant :

• Un système hôte c’est un système d’exploitation principal est installé sur un serveur
physique unique, ce système sert d’accueil à d’autres systèmes d’exploitation.
• Un Hyperviseur c’est un logiciel de virtualisation, il est installé sur le système
d’exploitation principal, il permet l’implémentation d’environnements sur lesquels
seront installés d’autres systèmes d’exploitation, ces environnements sont des
machines virtuelles.
• Chaque système installé dans une machine virtuelle fonctionne indépendamment
des autres systèmes d’autres machines virtuelles.
• Chaque machine virtuelle possède un accès aux ressources du serveur physique
(mémoire, espace disque…).

Figure 2.2 : La Figure montre l’architecture générale de la

virtualisation.

14
 3) Virtualisation dans les systèmes informatiques

Tout d’abord, il est essentiel de rappeler les différents types de techniques de

virtualisation utilisés dans les systèmes informatiques. Nous en distinguons trois familles :
virtualisation du stockage de données, virtualisation des serveurs et virtualisation des
applications multimédias.

a) Virtualisation du stockage de données

La virtualisation du stockage de données, comme l’a définie (Bonnet, 2002), est une
technique permettant de masquer la disparité des ressources de stockage (Ex. :
équipements, protocole d’accès) et à les présenter comme une unité de stockage virtuelle
homogène. En d’autres termes, cette technique crée une couche d’abstraction entre les
applications et les ressources de stockage physique. Pour être stocké, le trafic sortant des
applications est intercepté par le périphérique de stockage virtuel qui le redirige vers les
différents périphériques de stockage physiques (Ex. : disque dur externe, serveur de
stockage). Ainsi, le périphérique de stockage virtuel permet d’avoir une vision homogène
des différents périphériques de stockage et donc de simplifier la gestion du stockage des
données dans une entreprise. Il apporte aussi des fonctionnalités de réplication et de
reproduction de données indépendamment des périphériques et de leur constructeur
(Schmitt, 2008).

Figure 2.3 Virtualisation du stockage

15
 SAN Volume Controller (SVC) est un exemple de système de virtualisation de
stockage, développé par IBM, permettant d’identifier toutes les ressources de stockage
disponible au sein d’une entreprise et de veiller à ce que leur utilisation soit optimale
(IBM, 2011). Ce système permet de combiner virtuellement la capacité de différents
systèmes de stockage et permet de les gérer à partir d’une seule interface.

b) Virtualisation des serveurs

De nos jours, la majorité des entreprises utilisent des serveurs pour stocker leur base de
données et pour partager leurs applications. Les entreprises optent de plus en plus à réduire
le nombre de leurs serveurs à cause du coût important qu’engendre la maintenance, la mise
à jour et le fonctionnement de ces équipements (Pradeep Padala, 2007). Ce besoin de
réduire le nombre de serveurs a incité les chercheurs à mettre en place une technique
permettant de virtualiser les ressources d’un serveur. Cette technique consiste à
partitionner un serveur physique en plusieurs entités virtuelles séparées. Chaque entité
virtuelle peut avoir son propre système d’exploitation et ses propres applications.

Figure 2.4 Virtualisation des serveurs

16
 Un des avantages majeurs de cette technique est d’offrir la possibilité d’exécuter sur
le même serveur plusieurs applications qui ne sont pas faites pour coexister. Par exemple,
des applications qui requièrent des systèmes d’exploitation différents. Cette caractéristique
permet de réduire considérablement les coûts en diminuant le nombre de serveurs
physiques utilisés.

c) Virtualisation des applications

La virtualisation des applications, comme l’a définie (Gurr, 2008), est un procédé
permettant d’ajouter une couche d’abstraction entre le système d’exploitation et les
applications. Cette technique permet d’exécuter des applications sur un poste client sans
les installer sur ce poste. En effet, ces applications sont réellement installées sur un serveur
virtuel distant.

Figure 2.5 Virtualisation des applications

La virtualisation des applications permet d’exécuter des applications depuis un poste

client indépendamment du système d’exploitation. Ce procédé permet d’éliminer le
problème d’incompatibilité des applications.

17
 1) Virtualisation dans les environnements réseaux :

La virtualisation dans les environnements réseaux est un concept qui permet à

plusieurs instances virtuelles (ou réseaux virtuels) de coexister et de partager les ressources
d’une ou de plusieurs infrastructures physiques de réseaux. Comme l’a affirmé
(Chowdhury et Boutaba, 2010), ce concept de coexistence de plusieurs réseaux n’est pas
récent. En effet, plusieurs technologies existantes de réseau se basent sur ce concept.Dans
cette section, nous allons décrire certaines de ces techniques qui permettent de déployer
des réseaux virtuels à travers une même infrastructure réseau physique. Parmi ces
techniques, nous retrouvons : les réseaux locaux virtuels (VLAN-Virtual Local Area
Network), les réseaux privés virtuels (VPN-Virtual Privat Network), les réseaux de
recouvrement et les réseaux actifs et programmables.

a) Réseaux locaux virtuels

La technologie VLAN permet de diviser les réseaux locaux (LAN) en plusieurs réseaux
locaux logiques. Les ordinateurs appartenant au même réseau logique peuvent
communiquer directement entre eux comme dans un LAN. Cependant, deux ordinateurs
appartenant à des VLAN différents ne peuvent communiquer que par le biais d’un routeur.
Chaque VLAN constitue alors un domaine de diffusion (Broadcast domain) indépendant.
Cette technologie permet de confiner le trafic de diffusion à l’intérieur de chaque VLAN
ce qui réduit l’utilisation de la bande passante et améliore ainsi les performances du réseau.
Par ailleurs, la sécurité dans le réseau local est améliorée, car les utilisateurs de VLAN
différents ne peuvent communiquer ensemble directement (Zeng et Cheng, 2009). Les
VLANs peuvent être classés selon leur critère de commutation et la couche au niveau de
laquelle cette commutation s’effectue :

VLAN de niveau 1 (VLAN par port) :

Un nom est assigné à un groupe d’un ou plusieurs ports du commutateur. Pour que
deux ordinateurs connectés sur des ports de nom différents puissent communiquer, le trafic
doit être acheminé par un routeur (Zeng et Cheng, 2009).

18
VLAN de niveau 2 (VLAN MAC) :

Les trames sont classées par le commutateur selon leur adresse MAC source. En
effet, les adresses MAC des stations sont classées par l’administrateur du réseau dans des
listes appelées MAC-to-VLAN. Chaque liste correspond alors à un réseau logique
indépendant.

VLAN de niveau 3 (VLAN par sous-réseau) :

Les machines appartenant au même sous-réseau sont classées dans le même VLAN.

b) Virtual Private Network (VPN)

Un VPN est un réseau dédié permettant de connecter plusieurs sites à l’aide du principe
de tunnellisation (Diab, Tohme et Bassil, 2008). Ce dernier permet de transmettre des
données, via un tunnel virtuel, d’une manière plus sécurisée en utilisant des algorithmes de
cryptographie. Cette technologie est utilisée généralement pour interconnecter plusieurs
sites, d’une même entreprise, séparés géographiquement. Selon le protocole utilisé au
niveau du plan de données, la technologie VPN peut être classée en trois catégories : VPN
couche 1, VPN couche 2 et VPN couche 3.

VPN couche 3 (L3VPN) :

Il permet de connecter des sites géographiquement dispersés à travers le réseau

commuté par paquets d'un ou de plusieurs fournisseurs de services. En effet, chaque site
client détient un nombre d’équipements client de bord (Customer Edge-CE) connectés aux
équipements fournisseur de bord (Provider Edge-PE) dans le réseau cœur. Ce dernier
permet au trafic reçu de transiter entre les PE en utilisant ses routeurs internes. Le L3VPN
garantit aussi pour chaque utilisateur un trafic privé et séparé des autres utilisateurs
connectés au réseau cœur (Mohapatra, Metz et Yong, 2007).

VPN couche 2 (L2VPN) :

Il permet de transporter des trames de la couche 2 (Ex. : relais de trames, ATM)

entre les différents sites participants (Chowdhury et Boutaba, 2010).

VPN couche 1 (L1VPN) :

19
 Il utilise et renforce le contrôle et la gestion de L2VPN et de L3VPN. En effet, les
utilisateurs ont la possibilité de réguler leur trafic en appliquant des techniques d’ingénierie
de trafic (Dhaini, Pin-Han et Xiaohong, 2010). De plus, plusieurs technologies de transport
de la couche 1 peuvent être utilisées (Ex. : TDM, OTN).

c) Réseaux de recouvrement
Un réseau de recouvrement (overlay) est un réseau virtuel implémenté sur un ou
plusieurs réseaux physiques existants (Kawahara et al., 2011). La mise en place d’une telle
architecture n’affecte pas les fonctionnalités du réseau sous-jacent. Cette technique a été
alors utilisée pour implémenter plusieurs nouvelles fonctionnalités au réseau internet. Par
exemple, nous pouvons considérer la qualité de service comme une couche de
recouvrement au-dessus du réseau internet et qui utilise ses propres mécanismes pour
router l’information(Kawahara et al., 2009). Plusieurs autres couches de recouvrement ont
été proposées dans la littérature pour une meilleure gestion du routage (Elaoud et al.,
2005), garantir une protection contre les attaques par saturation (Beitollahi et Deconinck,
2008) et la distribution de données (Byers et al., 2004) ainsi que supporter la
multidiffusion (Jannotti et al., 2000). L’inconvénient des réseaux de recouvrement est
l’effort considérable nécessaire pour les créer et les maintenir. C’est pour cette raison que
seulement quelques-unes des nombreuses nouvelles architectures ont été testées sur des
réseaux de recouvrement (Anderson et al., 2005).

d) Réseaux actifs et programmables

Pour répondre aux besoins des nouvelles applications multimédias, il est parfois
nécessaire d’ajouter de nouveaux services ou de modifier les services réseau existants
(Ex. : Intégration des services différenciés au réseau internet afin d’améliorer la qualité de
service offerte). Cependant, ces changements sont généralement des processus longs et
coûteux.

L’objectif des réseaux actifs et programmables est donc de proposer des interfaces
programmables ouvertes (API) et standardisées (Campbell et al., 1999) permettant la
conception, l’implémentation et l’introduction de nouveaux services (Olivier FESTOR,
2000). Par exemple, le projet PIN 1650 (Biswas et al., 1998) de IEEE initié en 1997
propose un ensemble d’interfaces de programmation permettant, entres autres, de
programmer facilement des services pour la gestion de la qualité de service sur IP(Olivier
FESTOR, 2000).

20
 2) Projets de virtualisation de réseaux
Afin de valider une nouvelle architecture réseau, les chercheurs ont besoin de la
tester sur le réseau internet « réel » afin de déceler la moindre anomalie qui a pu échapper
aux simulateurs ou émulateurs dans les premiers tests réalisés. En revanche, les
fournisseurs d’accès Internet (FAI) ne veulent en aucun cas prendre le risque de perturber
le bon fonctionnement de leur réseau pour tester de nouveaux protocoles, car la moindre
interruption de service ou panne peut leur causer une perte considérable de revenu. Afin de
résoudre ce problème, des plateformes de test ont été implémentées dans le but de
permettre aux chercheurs de tester leurs nouvelles architectures sur une topologie et avec
un trafic internet « réels » sans affecter les performances de ce réseau (Spyropoulos, Fdida
et Kirkpatrick, 2007). Bien que leur but soit le même, les différentes plateformes
développées ont des architectures et des caractéristiques différentes. Elles peuvent être
classées selon les caractéristiques suivantes (Chowdhury et Boutaba, 2010):

Technologie du réseau :

Certaines architectures de virtualisation de réseaux ont été développées pour des

technologies de réseau spécifiques. Par exemple, X-Bone pour la technologie IP, Tempest
pour les réseaux ATM et GENI pour les réseaux multi technologiques (Chowdhury et
Boutaba, 2010).

Couche de virtualisation :
Les chercheurs ont été influencés par le modèle en couche du réseau Internet
existant. En effet, ils ont proposé des projets qui visent à virtualiser ces couches allant de la
couche physique (Ex. : UCLP) jusqu’à la couche application (Ex. : VIOLIN) (Chowdhury
et Boutaba, 2010).

21
Domaine architectural :

La plupart des projets ont mis l’accent sur un domaine architectural bien défini. Ce
domaine influence les choix de conception des architectures de ces projets ainsi que les
services qu’ils offrent. Par exemple, le projet VNRMS vise le domaine de gestion des
réseaux virtuels (Chowdhury et Boutaba, 2010).

Niveau de virtualisation : Le niveau de virtualisation veut dire le type de ressources

virtualisées dans un réseau (Ex. : nœuds, liens).

Par exemple, PlanetLab se base sur la virtualisation des nœuds tandis que UCLP se base s!
ur la virtualisation des liens (Chowdhury et Boutaba, 2010).

a) Technologie du réseau (X-Bone)

Plusieurs projets de virtualisation ont été conçus pour tester des technologies réseau
bien définies. Le X-Bone, par exemple, est la première infrastructure de réseaux virtuels
développée afin de permettre aux chercheurs de tester leurs protocoles et service dans des
conditions réelles sur des réseaux IP (Joe Touch 1998). Cette infrastructure permet de créer
des liens virtuels entre les routeurs et les hôtes virtuels en utilisant le principe de
tunnellisation. Elle coordonne la configuration et la gestion des différents réseaux virtuels
et permet la découverte et le déploiement des ressources physiques disponibles au niveau
des différents nœuds. X-Bone offre une abstraction entre les différents réseaux de
recouvrement ce qui permet de protéger le trafic et d’isoler ainsi les tests des différents
protocoles. Cette architecture de virtualisation supporte la concurrence, la récursion et la
revisitation. La concurrence permet la coexistence de plusieurs réseaux de recouvrement.
La récursion offre la possibilité de déployer un réseau de recouvrement à l’intérieur d’un
autre. La revisitation permet de réutiliser le même nœud par un réseau de recouvrement.
L’accès aux différentes fonctionnalités du réseau X-Bone se fait à partir d’une interface
web ou une interface XML (Chun et al., 2003) , (Carbone et Rizzo, 2009).

b) Couche de virtualisation (Emulab)

Les projets de virtualisation peuvent être classés selon les quatre couches du réseau IP
défini par IETF et dépendamment de leurs caractéristiques. Par exemple, Emulab
(Emulation Laboratory) est une plateforme de test au niveau liaison basée sur la
technologie de commutation VLAN. Cette plateforme utilise VLAN pour émuler des

22
réseaux à l’intérieur d’un réseau local (Chun et al., 2003). En effet, cette plateforme offre
aux chercheurs la possibilité de développer, de débuguer et d’évaluer leurs systèmes.
Emulab a été mis en place par le groupe de recherche Flux de l’Université Utah.
Actuellement, plusieurs centaines de nœuds ont été implémentés sur vingt-quatre sites à
travers le monde. Les utilisateurs peuvent utiliser les ressources des nœuds et des liens
Emulab en utilisant l’interface web Emulab. À travers cette interface, les utilisateurs
peuvent spécifier le type de nœuds, leur système d’exploitation ainsi que la nature des liens
reliant ces nœuds(Yuen, 2006).

c) Domaine architectural (CABO)

La gestion du réseau (Leon-Garcia et Mason, 2003), la conception, la création et le
déploiement d’architecture réseaux(Rooney et al., 1998), la création et le déploiement des
protocoles des réseaux actifs (da Silva, Yemini et Florissi, 2001) sont des domaines
architecturaux visés par plusieurs projets de virtualisation. CABO (Concurrent
Architectures are Better than One) est une architecture visant à faciliter le déploiement de
nouveaux services en séparant les fournisseurs d’infrastructure physiques (FIP) des
fournisseurs d’accès Internet (FAI).

En effet, actuellement les FAI gèrent leurs infrastructures physiques et fournissent en

même temps des services aux utilisateurs. Dans l’architecture d’internet actuel, un FAI doit
obtenir l’accord des autres FAI avant d’introduire le moindre changement au réseau.
Prenons par exemple le cas d’un FAI qui veut offrir de la qualité de service (QoS) à ses
clients. Étant donné que le trafic passera certainement par d’autres réseaux, le FAI, même
s’il a modifié son propre réseau, doit aussi convaincre les autres FAI à apporter les mêmes
modifications sur leurs réseaux respectifs. Ce problème bloque l’évolution du réseau
internet. Pour pallier ce problème, CABO propose de partager le rôle du FAI en deux
parties : d’une part la gestion de l’infrastructure physique et la virtualisation de ressources
réalisées par le FIF et d’autre part la fourniture de services et l’allocation de ressources
virtuelles réalisées par le fournisseur de service (FS)(Spyropoulos, Fdida et Kirkpatrick,
2007).

23
 d) Niveau de virtualisation (PlanetLab)

Planetlab (Planet NETwork Laboratory) est un projet qui se base sur la virtualisation
des nœuds (Peterson et al., 2003). En effet, PlanetLab est un réseau de recouvrement
implémenté en 2002 sur le réseau internet et composé actuellement d’environ mille nœuds
répartis partout dans le monde. L’accès aux nœuds est réservé aux personnes et aux
organismes affiliés. Chaque personne ou organisme se fait attribuer des parties des
ressources d’un nœud pour créer un environnement distribué virtualisé. Ces parties sont
des machines virtuelles instanciées au niveau des nœuds physiques de PlanetLab. Les
ressources physiques telles que le CPU, l’espace disque et la bande passante doivent être
partagées convenablement entre les machines virtuelles afin d’optimiser l’utilisation de ces
ressources et d’augmenter ainsi le nombre de parties assignées. Le réseau PlanetLab
comprend aussi un nœud central qui représente le cœur du système. En effet, ce nœud
comporte le logiciel de gestion de toute la plateforme ainsi que la base de données des
différents utilisateurs et nœuds du système (Chun et al., 2003) , (Carbone et Rizzo, 2009).

Figure2.6 :Répartion des nœuds PlanetLab dans le monde

Parmi les nouvelles architectures proposées certaines exigent des changements non
seulement au niveau matériel et logiciel mais elles exigent aussi d’établir des accords entre
les fournisseurs d’infrastructure IP pour implémenter de nouvelles fonctionnalités au
niveau architecture. CABO et le logiciel intégré de virtualisation de réseau 4Ward (AB,
2009) représentent deux exemples de telles architectures. Alors que l’architecture de

24
CABO établit une séparation entre les fournisseurs d’infrastructure et les fournisseurs de
service, celle de 4Ward définit trois rôles distincts :

1- fournisseurs d’infrastructures physiques,

2- fournisseurs de réseaux virtuels,

3- opérateurs de réseaux virtuels. Les fournisseurs d’infrastructures physiques gèrent

les ressources physiques. Les opérateurs de réseaux virtuels permettent de créer les réseaux
virtuels.

Les opérateurs de réseaux virtuels offrent des services aux usagers à travers les
réseaux virtuels. Un des défis majeurs pour la conception de telles architectures est de
mettre en place une stratégie de sélection et d’allocation de ressources qui permet d’utiliser
efficacement les ressources disponibles. Dans la section qui suit, nous présentons les
différentes stratégies proposées dans des travaux de recherches antérieures.

3) Intérêt de la Virtualisation :
A l’époque où les ordinateurs n’étaient capables de ne faire exécuter qu’un seul
processus en même temps, l’intérêt de se diriger vers un système supportant la gestion
multiprocessus était de pouvoir optimiser les ressources de calcul. La virtualisation va plus
loin encore, nous allons voir ici les différents intérêts qu’elle porte. Nous allons voir au
cours de cette partie différents avantages que la virtualisation peut apporter. Nous
aborderons différents points tels que la sécurité, le cout, ainsi que les performances.

a) La sécurité
La virtualisation va permettre une isolation des différents environnements logiciels
au niveau des ressources physiques. La communication entre les différentes machines
virtuelles sera uniquement possible via des connexions réseau de manière identique à la
communication entre deux machines physiques. L'isolation est telle que la compromission
d’un système invité par du code malicieux ne pourra pas se propager à d’autres systèmes
invités. Il sera donc tout à fait possible d'isoler chaque service sans devoir acheter un
nouveau serveur à chaque fois.

Un problème de sécurité pourrait apparaitre si un système invité avait la possibilité

de lire les données mémoire ou disque d'un autre système invité. De la même façon, si
deux applications de deux systèmes invités tentent d'accéder à une même ressource
25
physique, il se produira une interférence. Avec un système de virtualisation, il sera possible
de gérer les accès aux ressources physique de manière à éviter les conflits. Ceci pourra se
faire soit par l'allocation de temps d'accès soit par l'allocation exclusive. Une autre
application très intéressante pour les professionnels et les chercheurs en sécurité est
l'observation de logiciels malveillants à travers de systèmes d'exploitation invités
surveillés. Ce type d'utilisation permettra de suivre l'évolution de l'infection d'un système.
En outre, il sera possible de manipuler ces systèmes d'exploitation pour revenir en arrière
et expérimenter diverses techniques de désinfection et de détection.

b) Le coût
Actuellement, nous réalisons le fait que les serveurs sont largement sous utilisés. En
effet, une étude Gartner a montré qu'en moyenne les serveurs sont utilisés à 5% de leur
capacité. La sous-utilisation de serveurs empire avec la présence de serveurs en hot spare.
Un tel serveur est un serveur qui attend un dysfonctionnement du primaire pour prendre le
relais. En absence de dysfonctionnement, ce serveur n'effectue aucun travail alors qu'il
consomme de l'énergie et prend de la place en centre de données. Avec les coûts
grandissants des matières premières énergétiques et donc a fortiori l’électricité, les
gestionnaires de parcs serveurs se retrouvent contraints de se soucier des enjeux
d’optimisation de la consommation électrique. De plus, il est nécessaire de gérer des
contraintes liées au manque d’espace dans les centres de données dont le prix augmente à
cause de la demande croissante. Un hébergeur de serveurs va pouvoir bénéficier de la
virtualisation par le biais d'une gestion de ressources plus fine. Il va lui être possible de
gérer finement la répartition des ressources physiques entre les différents serveurs. Il va
également bénéficier de fonctionnalités de comptabilité de l'utilisation des ressources pour
pouvoir proposer une facturation plus adaptée à l'utilisation des ces clients.

26
 c) Criticité et performances
L'accumulation de systèmes invités sur un même système physique augmente sa
criticité. Une panne matérielle rendra indisponibles tous les systèmes invités. Pour pallier
la criticité accrue du système physique, des solutions ont été prévues.

La solution la plus basique est de prévoir la possibilité de faire des images des
systèmes invités. Des taches très longues à effectuer vont pouvoir être sauvegardés en
cours d’exécution. Il sera ensuite possible de relancer ces tâches à partir de ce point en cas
de panne. Un autre exemple de l’utilisation de ce procédé est le clonage de différentes
instances d’un invité. Par exemple, si plusieurs tâches nécessitent un même travail
préliminaire long, il sera possible de faire effectuer dans une première instance ce travail,
ensuite de la cloner autant de fois qu’il y a d’autres tâches et de les lancer séparément. Une
solution plus efficace pour palier à la criticité des serveurs de virtualisation est la migration
dynamique de systèmes invités. Le pré-requis est d’avoir un support de stockage accessible
en réseau. Un système invité est exécuté sur un premier serveur. Dans le cas d’une panne
matérielle ou d’une maintenance planifiée, il sera possible de migrer dans de très courts
délais ce système vers une autre machine tout en sauvegardant son état avant l'interruption.
Ce procédé permet à lui seul de réduire la criticité des systèmes individuels à un niveau
largement acceptable. Il fait reposer une plus grande criticité sur les systèmes de stockage
en réseau qui peuvent cependant être dédoublés. Une autre utilité de ce procédé en termes
de performances va être de pouvoir allouer des ressources à la volée aux systèmes invités.
Dans le cas d’une montée en charge d’un système invité, il sera possible de l’isoler sur un
serveur en déplaçant les autres systèmes présents à ces cotés sur d’autres serveurs moins
chargés. Ce procédé peut également être utile dans un objectif de réduction de la
consommation électrique d’un parc de serveur. Il est envisageable de n’utiliser que peu de
machines lorsque le système est soumis à une faible charge et d’allumer progressivement
les autres machines en fonction de la montée en charge. Ceci nécessite une gestion de
l’allumage électrique du serveur par le réseau mais bon nombre de serveurs récents
disposent de tels outils.

27
 4) Types de virtualisation :
a) La virtualisation au niveau du système d’exploitation

Ce type de virtualisation consiste à séparer le système d’exploitation (OS) d’une

machine en différents environnements utilisateurs distincts. Ainsi les utilisateurs de la
machine ne se voient pas entre eux, et l’accès aux données des autres n’est pas possible.
Les environnements utilisateurs sont entièrement cloisonnés. En effet ici le matériel et
l’OS sont les même pour tout le monde. On ne peut pas parler de « systèmes d’exploitation
invités » pour ces systèmes invités mais plutôt d'environnements utilisateur cloisonnés ou «
jails ». L’allocation des ressources entre les différents environnements utilisateurs est
possible. On donnera des quotas disque à ces espaces privés ainsi qu’une limite en termes
d’utilisation de puissance processeur. La mémoire vive disponible et la bande passante
réseau sont d’autres ressources que l’on peut limiter. Ce type de virtualisation est
essentiellement utilisé sur les systèmes Unix, Linux et BSD.

Au niveau de l’architecture du système virtualisé, nous avons le système hôte avec

ses invités au-dessus. Le système hôte sera ici l’OS qui supportera les environnements
utilisateurs invités. Ceuxci n’ont pas de noyau propre. Il n’y a qu’un seul noyau pour faire
fonctionner le système complet. Néanmoins les environnements utilisateurs croient être sur
des machines différentes (montages disques différents, adressage réseau différent). Un des
principaux intérêts de cette technique est que l’on peut facilement faire migrer à chaud un
processus d’un environnement utilisateur à un autre. L’exemple type serait qu’un
programme « A » requiert une certaine puissance, que celle-ci ne peut être délivrée dans
l'environnement utilisateur où il se situe. La solution est de le migrer à chaud vers un
environnement plus puissant. De plus ce type de virtualisation est utilisé chez les
hébergeurs web qui proposent des environnements privés à moindre coût pour que les
utilisateurs puissent gérer leurs sites web comme si ils possédaient chacun un serveur
personnel (Primet/Vicat-Blanc 14 Septembre 2007) (Wikipédia n.d.). Comme le montre la
figure 2, C’est une couche logicielle en plus du système d’exploitation qui va permettre la
séparation des environnements utilisateurs. A noter que le noyau est le même pour tous
(machines virtuelles, système hôte).

28
 Figure 2.7 : Virtualisation au niveau du système d'exploitation

b) La virtualisation totale

La virtualisation totale 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. Le concept de virtualisation totale est déjà bien ancré dans la littérature, mais ce
n’est pas toujours ce terme qui est employé (Wikipédia n.d.). La virtualisation partielle
peut être confondue avec. Nous allons voir dans les paragraphes qui suivent les définitions
de ces deux termes. En virtualisation totale, la machine physique qui va émuler le matériel
pour le système invité doit être doté d’un OS ainsi que d’une surcouche applicative. 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 OS que l’on désire
indépendamment de l’architecture du système hôte. On l’utilise essentiellement en milieu
industriel pour faire fonctionner des applications sur des architectures matérielles non
encore commercialisées (Primet/Vicat-Blanc 14 Septembre 2007). Il faut savoir que ce
type de virtualisation n’est que logiciel, aucune fonctionnalité matérielle de virtualisation
n’est utilisée. On peut voir sur la figure 2.4 que les 3 premières couches sont identiques à
la virtualisation au niveau de l’OS. Ici sur une 4ème couche on trouve l’émulation du
matériel désiré afin de pouvoir accueillir tout type d’OS en tant que machine virtuelle.

29
 Figure 2.8 : Virtualisation totale

La virtualisation partielle quant à elle n’a pas pour but de simuler de nouvelles
architectures pour les systèmes invités, mais uniquement une partie. En effet on va émuler
la partie matérielle qui nous intéresse pour faire fonctionner une application particulière.
Dans ce cas l’émulation d’une seule ressource peut être suffisante. On parle donc de
virtualisation partielle. L’intérêt est donc de ne pas resimuler tout le matériel de la
plateforme émulée.

Lorsqu’IBM a inventé ce terme, on appelait virtualisation partielle le fait de

cloisonner les utilisateurs dans des espaces d’adressages mémoire distincts. Ce terme n’est
plus employé aujourd’hui dans ce sens. En virtualisation totale la machine accueillant les
systèmes invités doit donc implémenter de façon logicielle une gestion complète du
matériel des invités. La gestion de la mémoire est un des facteurs les plus critiques en
termes de performances. Les performances de la machine virtuelle sont donc limitées par
les performances de la couche d’abstraction du système hôte et par la qualité de
l’émulation du matériel implémenté. La virtualisation totale est la technique qui s’éloigne
le plus des performances que peut avoir un système classique.

c) La virtualisation matérielle assistée

Ce type de virtualisation a pour but de faire fonctionner des systèmes invités dont
les OS peuvent être différents mais non modifiés. La différence avec la virtualisation totale
est qu’ici on tire pleinement partie du matériel et de sa puissance. La perte de performances
est minimum particulièrement au niveau du processeur. Cette technique de virtualisation a
été récemment implantée dans nos processeurs à base d’architecture x86 sous les noms de :
technologies Intel-VTx (32 bits) et Intel VT-i (64 bits) pour Intel, de AMD-V pour AMD,

30
Advanced Power Virtualization pour IBM et de Ultra SPARC T1 Hypervisor pour SUN.
Encore une fois on trouve plusieurs termes pour définir ce type de virtualisation, et ce sont
les entreprises qui le dénomment différemment. Xen l’appelle HVM (Hardware Virtual
Machine), Virtual Iron quand à lui la dénomme virtualisation native (Wikipédia n.d.). Le
but de ce type de virtualisation était de pouvoir faire fonctionner tout type d’OS non
modifié de façon parallèle sur une même machine sans perte de performance. L’utilisation
des fonctionnalités processeurs liées à la virtualisation a permis en partie cet exploit mais
les différentes sources ne sont pas en accord vis-à-vis du facteur de perte de performance
(Primet/Vicat-Blanc 14 Septembre 2007) (Wikipédia n.d.) (Nakajima n.d.). Cloud
d'Entreprises.

Figure 2.9 Architecture Intel-VT

Nous pouvons voir ci-dessus une figure représentant le fonctionnement de

l’architecture Intel-VT, nous avons en bas les composants matériels d’un ordinateur
(processeurs, mémoires, périphériques d’entrées, sorties). Au-dessus nous avons le VMM.
Le VMM est une application qui permet d’utiliser pleinement partie de la technologie
Intel-VT. Enfin en haut nous avons les machines virtuelles qui sont confinées chacune dans
leur propre environnement. Le VMM, Virtual Machine Monitor est un outil logiciel qui va
s’assurer de la répartition et de la division des ressources matérielles pour chacune des
machines virtuelles. Il est également capable de faire la distinction des interruptions

31
entrées/sorties émisses par les périphériques de la machine et de les relayer à destination
des différentes machines virtuelles (whatis.com n.d.). La virtualisation assistée matérielle
est donc une évolution de la virtualisation totale puisqu’elle émule toujours le matériel
nécessaire au bon fonctionnement des systèmes invités, mais avec une perte de
performances moindre.

En effet ici l’architecture matérielle est dotée de fonctionnalités spécifiquement

développées pour ce genre d’utilisation. La perte de performances est donc plus faible vis à
vis d’un système natif.

d) La paravirtualisation
Cette technique présente un logiciel en tant qu’intermédiaire entre le matériel et les
systèmes d’exploitation invités et non un système d’exploitation. La deuxième différence
par rapport aux techniques vues précédemment est que les systèmes invités sont modifiés.
Ils sont conscients du fait qu’ils sont virtualisés. L’application située entre le matériel est
les systèmes invités est appelée VMM comme en virtualisation matérielle assistée. Ici on
ne tire pas parti des instructions processeur liées à la virtualisation. Ce VMM aussi appelée
hyperviseur est le plus simple possible afin d’avoir le minimum de pertes de performances.

C’est lui qui est chargé d’appliquer la politique d’accès aux ressources matérielles
pour les systèmes invités. Etant donné des modifications apportées, ces systèmes ont été
adaptés au niveau de leur noyau afin qu’ils puissent communiquer avec l’hyperviseur.

Dans les systèmes natifs, il existe des instructions privilégiées. Ces instructions
processeurs permettent d’accéder directement à la mémoire physique du processeur sans
passer par la mémoire virtuelle. Une autre utilisation de ces instructions est la possibilité de
changer l’état de la machine dans le sens ou cela influe sur des processus.

En paravirtualisation cela pose un problème non négligeable puisque les machines

virtuelles n’ont pas accès directement au matériel et ne peuvent ainsi pas faire exécuter ces
instructions privilégiées. Ce problème ne s’était pas posé jusqu’alors puisque dans les
techniques vues précédemment, le processeur est émulé donc le système invité exécute ces
instructions privilégiées sur ce « faux » processeur.

Mais un jeu d’instruction appelé « hypercalls » existe pour fournir des

fonctionnalités similaires. Les applications n’étant pas modifiées, celles-ci émettrons des
appels systèmes privilégiés classiques. Ces appels seront captés par le noyau modifié du
système invité et seront transformés en hypercalls. Ceux-ci seront alors envoyés à

32
l’hyperviseur qui pourra donc les interpréter. Ce cheminement est expliqué par la figure ci-
dessous. Du coté de la virtualisation native ou virtualisation matérielle assisté on voit
clairement que les appels des MV sont directement captés par le noyau de la VMM. Nous
expliciterons la notion de noyau dans la partie concernant les pré-requis sur les systèmes
d'exploitation.

Figure 2.10 : Appels systèmes en para/native virtualisation

e) La virtualisation Hybride

La virtualisation hybride consiste à coupler la paravirtualisation avec la virtualisation

matérielle assistée. Elle permet de faire fonctionner des systèmes d'exploitation non
modifiés qui profitent en partie des instructions processeur Intel-VT ou AMD-V ainsi que
certaines extensions liées à la paravirtualisation. Dans ce cas la VMM ou hyperviseur est
capable d’accomplir les taches requises ar les 2 technologies de virtualisation.

33
 5) Les avantages de la virtualisation :
Il est difficile de trouver des informations à jour, mais on estime que la charge moyenne
processeur d'un serveur en production est inférieure à 15 % Il est évident donc que les serveurs
ne sont pas utilisés au maximum de leur capacité. Cela s'explique par le fait qu'il est parfois
délicat de faire cohabiter plusieurs applications sur la même machine, et que les administrateurs
préfèrent dédier une machine pour une application donnée. Voici les grandes lignes qui listent
les avantages d'une telle solution :

 Stabilisation et consolidation d’un parc de serveurs en entreprise : les entreprises ne sont

plus obligées d’acheter un serveur physique pour chaque application.
 Optimisation des coûts de matériels informatiques. L’installation de plusieurs systèmes
d’exploitation sur une même machine.
 La portabilité des serveurs : une machine virtuelle peut être déplacée d’un serveur
physique vers un autre.
 Accroissement d’applications en entreprise et des déploiements de systèmes.
 L’ensemble des serveurs est administré de façon simple.
 Baisse de la facture d’électricité, en minimisant le nombre de serveurs physiques
 Une reprise automatique lors des incidents : la virtualisation permet d’améliorer la
prévention et la gestion des pannes car les machines virtuelles sont des fichiers déplaçables, faciles
à sauvegarder pour une restauration ultérieure.
 Une optimisation de la sécurité des données
 Une facilité de migration : La virtualisation apporte la possibilité de migrer facilement un
environnement virtuel d’une machine physique vers une autre, facilitant ainsi l’évolutivité du
centre de donnée ou le remplacement de matériel défectueux.
 Un cloisonnement : la virtualisation permet de créer des environnements isolés et sécurisés
pour la séparation de la plateforme de test avec celle de la production lors de déploiement de
logiciels afin de ne pas déstabiliser les applications déjà en production.

34
 CHAPITRE II : LES HYPERVISEURS :

Dans cette section, nous allons spécifier les hyperviseurs et leurs fonctionnalités et les
différents types des hyperviseurs

1) Le fonctionnement des hyperviseurs

En informatique, un hyperviseur est une plate-forme de virtualisation qui
permet à plusieurs systèmes d'exploitation de tourner sur une même machine physique
en même temps.

L'hyperviseur est un noyau hôte allégé et optimisé pour ne faire tourner que des
noyaux d'OS invités adaptés et optimisés pour tourner sur cette architecture spécifique,
les OS invités ayant conscience d'être virtualités.

 Mécanisme des Hyperviseurs

Les hyperviseurs ont besoin d'isoler les interruptions et les accès à la mémoire.
C'est très coûteux quant aux performances, auparavant cette opération était réalisée par
un mécanisme de translation de code. Depuis quelques années, les fabricants de
processeurs ont ajouté des instructions spécialisées (Intel VT-x / EPT et AMD-V ) afin
de permettre la virtualisation assistée par le matériel. KVM + QEMU et VirtualBox,
utilisent ces instructions. Le procédé impose à l'hyperviseur d'exposer explicitement les
extensions de virtualisation du jeu d'instructions au système d'exploitation invité sous-
jacent.

 Architecture des hyperviseurs :

- Processeur :

L'utilisation d'un hyperviseur au-dessous du système d'exploitation diffère du schéma

habituel où le système d'exploitation est l'entité la plus privilégiée dans le système. Afin de
protéger l'hyperviseur de débordements du système d'exploitation invité et des domaines
les uns sur les autres, les OS invités doivent être modifiés pour fonctionner à un niveau de
privilège inférieur.

De nombreuses architectures de processeur ne fournissent que deux niveaux de

privilèges. Dans une virtualisation efficace, des niveaux de privilèges supplémentaires sont
disponibles sur x86, car il prend en charge quatre niveaux de privilèges distincts dans le
matériel.
35
 L'utilisation du processeur a des implications critiques sur les performances des autres
caractéristiques du système, à savoir sur la consommation d'énergie. L'implication ne se
limite pas au cas où le processeur fonctionne à 100 %. Plus la charge du processeur
augmente, plus la consommation de ce dernier est importante.

Dans l'évaluation des performances d'une machine virtuelle, les processus sont gérés
par la machine virtuelle à la place du système d'exploitation sous-jacent.
Les threads émulés des environnements multi-thread, en dehors des capacités du système
d'exploitation d'origine, sont gérés dans l'espace utilisateur à la place de l'espace noyau,
permettant le travail avec des environnements sans support natif des threads .

De bonnes performances sur un microprocesseur multi-cœur sont obtenues grâce à

l'implémentation de threads natifs pouvant attribuer automatiquement le travail à plusieurs
processeurs, ils permettent un démarrage plus rapide de processus sur certaines machines
virtuelles. Un thread a la possibilité de bloquer les autres threads pour effectuer une
opération d'entrée/sortie. Pour éviter le problème, les threads doivent utiliser des opérations
d'entrée/sortie asynchrones. La complexité accrue peut être cachée par la mise en œuvre
de processus d'entrée/sortie séparés natifs qui coopèrent avec les threads .

- Mémoire :

La mémoire virtuelle est la partie la plus difficile à créer avec la paravirtualisation :

L'architecture X86 ne possède pas de gestion logicielle du TLB (mémoire cache du

processeur); lorsque la place manque, les TLB sont nettoyées automatiquement par le
processeur en ré-écrivant sur la structure de la table de pages. Pour obtenir la meilleure
performance possible, toutes les traductions de page valides pour l'espace de l'adresse
actuelle doivent être présents dans la table de pages.

- Entrées/sorties et stockage

La virtualisation des entrées/sorties par un hyperviseur pose un problème complexe.

Les périphériques d'entrée/sortie sont généralement partagés entre toutes les machines
virtuelles dans une machine physique, l'hyperviseur doit vérifier que les accès des
périphériques sont légaux cela nécessite que l'hyperviseur ou un domaine privilégié doit
intervenir sur tous les accès d'entrée/sortie du client de machine virtuelle.

36
 L'intervention conduit à plus de latence aux entrées/sorties et plus de ressources CPU
en raison de changements de contexte entre les machines virtuelles invitées et
l’hyperviseur.

Les machines virtuelles hébergent un système d'exploitation, des applications, des services
et éventuellement des données. Elles exigent une grande place de stockage sur le disque.
Une quantité importante de l'activité d'entrée/sortie est réservée pour garder plusieurs
machines virtuelles vivantes sur un seul serveur. Les applications nécessitant une grande
quantité d'entrée/sortie, comme les serveurs de base de données, pourraient faire face à
d'importants ralentissements si les sous-systèmes d'entrée/sortie ne sont pas en mesure de
faire face à la charge accrue. Le stockage est une ressource clé pour un environnement
virtualisé. Après tout, une machine virtuelle est techniquement un ensemble de fichiers qui
peut contenir un système d'exploitation avec ses applications installées

2) Les différents types des hyperviseurs

Les hyperviseurs sont classés actuellement en deux types :

a) Les hyperviseurs de type 1

Un hyperviseur de type 1 est un logiciel qui s'exécute directement sur une
plateforme hardware. Il permet aux systèmes d'exploitation invités de rester
relativement près du matériel et donc de conserver des performances proches d'un
système de manière native.

Actuellement, c’est la méthode de virtualisation d'infrastructure la plus

performante mais elle a pour inconvénient d’être contraignante et onéreuse, bien que
permettant plus de flexibilité dans le cas de la virtualisation d'un centre de traitement
informatique.

Exemples
• VMware ESX ;

• XEN ;

• Oracle VM Server.

37
 Figure 2.11 : Hyperviseur de type 1

b) Les hyperviseurs de type 2

Un hyperviseur de type 2 est un logiciel généralement assez lourd qui s'exécute
à l'intérieur d'un système d'exploitation. Ce logiciel permet de lancer un ou plusieurs
OS invités. La machine virtualise le matériel pour les OS invités, ces derniers croient
dialoguer directement avec le matériel.

Les systèmes invités devront donc traverser deux couches logicielles avant
d'accéder au hardware. Les performances en sont donc considérablement réduites par
rapport à la paravirtualisation. Mais la facilité d'installation et de configuration de ce
type de système de virtualisation représente un gros avantage.

Les échanges entre les machines se font via les canaux standards de
communication entre systèmes d’exploitation (TCP/IP et autres protocoles réseau), un
tampon d’échange permet d’émuler des cartes réseaux virtuelles sur une seule carte
réseau réelle. Exemples :

• QEMU/KVM ;

• Microsoft Virtual Server ;

• Oracle VirtualBox ;

• VMware Player ;

• VMware Workstation.

38
 Figure 2.12 : Hyperviseur de type 2

3) Quelques exemples d’hyperviseur

a) VMWare vSphere Hypervisor

VMWare est présent sur le marché de la virtualisation depuis de nombreuses années, la

première version d’ESX Server datant de 2001. Une version gratuite de l’hyperviseur de
VMWare, VMWare vSphere Hypervisor(anciennement ESXi), est également proposée
depuis quelques années. Certaines des fonctionnalités d’ESX – rebaptisé vSphere depuis la
version 4.0 – ne sont toutefois pas disponibles dans la version gratuite.

Figure 2.13 logo d’un VMWare vSphere

39
  Fonctionnalité :

Tout comme vSphere (la solution de virtualisation payante de VMWare), vSphere

Hypervisor repose sur le microkernel VMkernel. C’est ce dernier qui accède directement
au processeur et à la mémoire de la machine hôte, utilisant au passage un mécanisme SBE
(Scan-Before-Execution) pour prendre en charge certaines instructions critiques,
privilégiées et/ou spéciales. Les autres ressources matérielles sont prises en charge par des
modules additionnels.

L’un des avantages de vSphere Hypervisor réside dans sa légèreté : l’hyperviseur n’occupe
quelques centaines de Mo d’espace disque. VSphere Hypervisor est toutefois – et c’est
logique – moins complet que vSphere.

Ainsi, on doit se contenter d’une console d’administration minimaliste en lieu et place

d’un véritable environnement. Tous les agents VMware sont par ailleurs exécutés
directement sur le VMkernel.

La version de vSphere améliore un certain nombre de caractéristiques de l’hyperviseur. Il

par exemple possible de migrer des VM à chaud entre deux Distributed Switch, entre deux
vSwitch ou d’un vSwitch vers un Distributed Switch (mais pas l’inverse) grâce à Cross
vSwitch vMotion. Il est également possible de migrer une VM d’un vCenter à un autre,
même s’ils ne partagent aucun Datastores. Il est en outre possible de mettre en place du
Fault Tolerance avec un maximum de 4 vCPU, contre 1 seul vCPU auparavant. Enfin,
vSphere Hypervisor 6 apporte le VM Hardware en version 11 et VSAN version.

b) Citrix Xenserveur
Citrix XenServer est une plateforme de virtualisation gratuite, basée sur l’hyperviseur
open-source Xen. Si l’hyperviseur Xen existe depuis de nombreuses années (la version 1.0
date d’octobre 2003), le rachat de XenSource par Citrix ne date que de 2007. XenServer
est disponible gratuitement, mais il faudra en revanche opter pour une licence annuelle (à
partir de 345 dollars par socket) ou perpétuelle (à partir de 763 dollars par socket).

40
 Figure 2.14 : Logo Citrix

 Fonctionnalité :

XenServer combine virtualisation matérielle et paravirtualisation. Ainsi, lorsque le système

d’exploitation invité ne peut pas être totalement paravirtualisé, l’hyperviseur fait appel aux
technologies de virtualisation matérielle Intel VT ou AMD-V.

Les interactions entre les machines virtuelles et le matériel sont gérés par le domaine de
contrôle « Domain 0 », lui-même une machine virtuelle dotée de privilèges spéciaux.
Hébergeant une instance optimisée de Linux, « Domain 0 » s’appuie sur les pilotes
standards open source de Linux, offrant ainsi une compatibilité matérielle très étendue.

c) Proxmox
Proxmox VE (pour Virtual Environment) est une solution open source basée sur
l’hyperviseur KVM et sur le système d’exploitation Debian 64 bits. Créé en 2008 par la
société Proxmox Server Solutions, Proxmox VE en est aujourd’hui à la version 4.1. Ici
aussi, si la version de base est gratuite, il faudra passer par un abonnement (au CPU et par
mois, entre 4,16 euros et 66,33 euros) pour bénéficier d’un support étendu (nombre annuel
de tickets de support, garantie de temps de réponse, …).

Figure 2.15 : Logo du Proxmox

41
  Fonctionnalité :

Proxmox VE propose, comme ses concurrents, une gestion optimisée de la

mémoire (Kernel Samepage Merging, Memory ballooning), des snapshots de machines
virtuelles, l’intégration et l’authentification avec un annuaire LDAP, le support du
bonding, la prise en charge des suavegardes et des restaurations ou encore la migration à
chaud.

4) Caractéristiques et utilisation des outils de virtualisation :

Outil de Mode de
Disponibilité Avantage
virtualisation virtualisation

Gestion de l'infrastructure
VMware Commercial Full virtualisation
virtuelle

Migration des machines

Xen Open source Para-virtualisation
virtuelles

Support des architectures

QEMU Open source Virtualisation natif
hétérogènes du matériel

Exécution d'OS invités

VNUML (Virtual
comme une application
Network User Open source Full virtualisation
normale au sein d'un
Mode Linux)
système Linux hôte

UML (User Mode

Open source Support des systèmes Linux Para-virtualisation
Linux)

Support des protocoles

Virtual Box Commercial distants pour la version Virtualisation natif
commerciale

Fonctionne en dessous d'un

VMware
Open source système d'exploitation open Full virtualisation
Workstation
source

VMware Vcenter Open source Fonctionne en dessous d'un Full virtualisation

42
 système d'exploitation open
Converter
source

Partitionnement des Virtualisation

OpenVZ Open source ressources, système de niveau système
containeur d'exploitation

Analyse des bugs sur les

Bochs Open source systèmes d'exploitation Emulateur
invités

Gratuit, non Fonctionne sur les plates-

VMware server Full virtualisation
open source formes Windows et Linux

Microsoft Virtual Support des logiciels

Commercial Full virtualisation
PC Microsoft

Exécution de plusieurs
systèmes invités, de plates-
Parallels Commercial Full virtualisation
formes différentes sur un
hôte

KVM (Kernel- Pour les serveurs Linux,

based Virtual Open source support processeur pour la Full virtualisation
Machine) virtualisation

Isolation de plusieurs
serveurs Linux sur une
VServer Open source Full virtualisation
même plate-forme
matérielle

Pour les systèmes hôte

LXC (Linux
Open source Linux, système de Para-virtualisation
Container)
containeur

Tableau 2.1: Caractéristique des outils de virtualisation

43
 PARTIE III : MATHODOLOGIE ET PRESENTATION DU XEN

CAPITRE I : METHODOLOGIE :

Introduction
Ce chapitre a permis de détailler les spécifications du projet, nous allons citer les différents
objectifs de la virtualisation des serveurs et l’identification des besoins fonctionnels et non
fonctionnels de notre solution ainsi que la description de leur système d’information.

1) Système d’information avant la virtualisation :

Dès son origine, une machine physique présente une couche matérielle qui
représente l’ensemble des périphériques matériels, conçue pour n’exécuter qu’un seul
système d’exploitation avec une ou plusieurs applications. Ainsi, il semble étrange de faire
cohabiter plusieurs OS sur une seule machine physique. En effet, un système d’exploitation
est conçu pour utiliser au mieux un matériel qui est entièrement sous son contrôle. La
réunion de plusieurs systèmes pour exploiter les mêmes ressources physiques d’une
machine hôte paraîtrait absurde.

Se rve ur de fic her Windows Se rve ur 2 0 1 2

De bian Active Dire ctory Ce ntOS
Se rveur We b

PC 01 PC 02 PC 03

Figure 3.1 Système informatique traditionnel

44
a) Inventaire des ordinateurs et des servers :
Par suite des Exemple que nous avons effectué aux différents entreprises, les résultats
des inventaires des micro-ordinateurs, des serveurs et des équipements réseaux sont
comme suit :

Nom Adresse IP Description OS

Debian 172.15.20.3 Serveur de fichier Linux
CentOS 172.20.15.7 Serveur Web Linux
Windows Server 172.20.15.10 Serveur Active directory Windows server
2012 R2
PC01 172.20.15.11 Windows 10 Windows
PC 02 172.20.15.16 Windows 10 Windows
PC03 172.20.15.17 Windows 10 Windows
Tableau 3.1 : Liste des Distributions Dans une Société

b) Inventaire des progiciels :

Nous présentons dans le Tableau 3.2 les différents progiciels, leur version et leur
fournisseur.

Progiciels Version Fournisseur

Microsoft Windows Server 2012 Microsoft

Microsoft Windows 10 Microsoft

Microsoft Office 2013 Microsoft

Microsoft SQL SERVER 2005 Microsoft

Tableau 3.2 : Tableau de progicielle installée

45
 2) Système informatique avec virtualisation

La virtualisation dépasse les limites des architectures traditionnelles en permettant

de faire fonctionner simultanément plusieurs systèmes invités et plusieurs applications sur
une même machine physique. Les machines virtuelles sont isolées les unes des autres tous
en partageant les mêmes ressources physiques de la machine hôte. Elles se comportent
comme des machines physiques ayant ses propres ressources matérielles qui ne sont alors
que des ressources logiques.

PC 01 PC 02 PC 03

Figure 3.2 : Système informatique avec virtualisation des serveurs

a) Solution adoptée :

Vu l’ensemble des difficultés rencontrées par l’entreprise lorsque le nombre des

serveurs augmente, il est nécessaire de trouver une solution. Grâce à la virtualisation des
serveurs l’entreprise peut exécuter simultanément plusieurs systèmes d’exploitation et
applications sur le même ordinateur/serveur en toute sécurité afin d’accroitre l’utilisation et
la flexibilité du matériel.

46
 Donc l’entreprise réduit le nombre d’ordinateurs sans pour autant réduire le nombre
d’applications installées.

Cela entraine des économies en termes de matériel, d’espace, de consommation

électrique et de partage d’information via groupe.

b) Les Besoins fonctionnels :

 Installation de Citrix XenServer :

XenServer est une solution qui virtualise les serveurs et réduit d’une façon
importante les coûts associés aux datacenters en rendant ces derniers plus simples et plus
dynamiques. Elle offre des fonctionnalités de gestion avancée qui permet d’automatiser et
d’intégrer la gestion des datacenters virtuels avec un coût moindre que celui des solutions
concurrentes. Elle est une solution d’infrastructure virtuelle permettant d’intégrer un
nombre sans limites de serveurs hôtes et de machines virtuelles invitées grâce à un
hyperviseur 64 bits. Elle assure aux entreprises une création et une gestion sécurisée d’un
nombre illimité de machines virtuelles et de serveurs à partir d’une console de gestion
unique XenCenter.

XenServer est une plate-forme de virtualisation sécurisée et très fiable, elle assure une
densité de machines virtuelles sans égales et des performances applicatives presque innées.

XenServer permet l’installation simple et rapide des ressources de stockage, du réseau et

des serveurs grâce à un assistant perceptible.

 Installation de XenCenter 7.0 :

Avec XenCenter, on peut gérer l’environnement XenServer , déployer et surveiller des

machines virtuelles à partir d’un PC de bureau Windows.

• Création d’un stockage partagé : établissement de référentiels de stockage

XenServer(SR) pour aboutir a un stockage partagé entre les serveurs gérés.

• Installation d’une machine virtuelle.

• Ajout d’un nouveau serveur : se connecter aux serveurs hôtes XenServer pour
ajouter la liste des ressources utilisées dans XenCenter.

• Exportation et importation de la liste des serveurs ou des Templates.

47
• Création d’un Pool : l’assistant New Pool permet d’associer les serveurs gérés
ensembles dans un Pool de ressources avec un stockage partagé.

 Installation de Windows 2012 server R2 :

Dans notre projet on va installer Windows Server 2012 R2.

C’est une édition destinée à des plateformes virtuelles.

Chaque licence couvre un nombre limité de machines virtuelles ainsi que des ressources.

Pour chacun de nos serveurs ont va installer des fonctionnalités selon les besoins.

 Installation d’Active Directory :

Active Directory (AD) est la mise en place par Microsoft des services d’annuaire
LDAP pour les systèmes d’exploitation Windows.

Il a comme base les standards TCP/IP et il existe dans le système d’exploitation

Microsoft Windows Server 2000.

Le but d’Active Directory est de procurer des services centralisés d’authentification

et d’identification à un réseau d’ordinateurs ayant comme système d’exploitation
Windows.

Active Directory permet aussi d’appliquer et d’attribuer des stratégies, de distribuer

des logiciels, et d’installer des mises à jour par les administrateurs.

 Installation de serveur Terminal Server :

Le serveur Terminal server « TSE » (service de bureau à distance) est un rôle de

Windows server, il permet la connexion de multiples clients sur un même serveur en
utilisant plusieurs sessions en même temps et de publier un ensemble d’applications à
distance. Cela nécessite une installation préalable d’Active Directory sur un autre serveur
du réseau.

Les applications tournent sur le serveur et le client reçoit en réalité qu’un « Stream
» de l’application.

48
Ceci permet l’économie de l’argent dans une entreprise en se procurant un gros serveur et
des clients légers pour les employés.

• Caractéristiques

C’est un composant qui est déjà inclus dans Windows 2000/2003/2008 Server mais qui
n’est pas installé par défaut. Il offre beaucoup de fonctionnalités comme :

o La possibilité pour l'administrateur de prendre la main sur une session

utilisateur. o La possibilité d'administrer à distance les ressources du réseau
o Une présentation uniforme des applications à des utilisateurs situés dans des
bureaux géographiquement dispersés, et l'obtention d'une interface graphique
pour les applications fonctionnant sur des ordinateurs en mode texte. En outre,
ils simplifient la prise en charge des ordinateurs et bureaux distants et offrent
une sécurité et une gestion centralisées.
o Ils permettent de jouer le rôle de multisession : chaque utilisateur peut se
connecter

sur un serveur au même moment avec des sessions différentes.

• Configuration requise

Les services Terminal Server ne monopolisent qu'un faible espace disque, requérants peu
de mémoire et leur configuration est aisée pour les clients.

 Installation de serveur NX (NoMachine)

• Présentation

La technologie NX est un protocole client-serveur permettant des connexions graphiques

X11 distance. Le protocole est basé à la fois sur SSH (pour la sécurité) et sur la
compression X (pour l’interface graphique et la rapidité).
• Editions

Il existe 3 versions du serveur NX : NX Server, FreeNX et 2X.

L’original, NX Server de la société NoMachines ; le serveur est gratuit mais limité à deux
(2) utilisateurs maximal et à deux(2) connexions simultanées.

2X est une version gratuite sans limite de nombre de clients.

Et enfin, la version « opensource », FreeNX. Elle n’est pas limitée.

49
 • Caractéristiques o NX est gratuit
o Il est bien sécurisé (il utilise ssh)

o Il ne nécessite pas de service spécial à démarrer (il n'est activé que lors
d'une connexion)

o Il utilise les mots de passe et utilisateurs déclarés sur le système.

o Il est très performant (l'affichage est beaucoup plus réactif que VNC ou
X sur ssh seul.)

o On peut redimensionner l'écran (les barres de menu s'adaptent)

o On peut fermer une session et la reprendre plus tard, même à partir d'une
autre connexion internet (nous retrouvons nos fenêtres telles qu'elles
étaient)

o Il est multisession : grâce à lui, beaucoup des clients peuvent se

connecter sur un serveur en même temps avec des sessions différents
indépendants les uns au autres.

Dans le système d’exploitation Windows, il y a TSE qui est un outil de bureau à

distance très performant, sous Linux NX ; c’est presque l’équivalent de TSE. NX Server a
besoin de ssh pour fonctionner (NX utilise ssh pour sécuriser la connexion). Le serveur ssh
doit être installé et démarré (Il doit être sur le port standard 22). Pour installer et démarrer
le serveur ssh, on tape : sudo apt-get install ssh

Le client NX existe en version pour Windows. Nous pouvons donc utiliser la

version Windows de NX pour nous connecter sur des serveurs NX, Windows TSE, VNC
et autres. Le serveur NX n'existe pas pour Windows (car le serveur NX se base sur le
protocole X de Linux/Unix).

Conclusion

D’après l’étude que nous avons faite, on a pu dégager facilement les difficultés
rencontrées par l’entreprise qui sont minimisées grâce à la solution de la virtualisation. La
détermination des besoins fonctionnels et non fonctionnels va nous permettre de clarifier
notre solution et de mettre au point nos objectifs, les fonctionnalités de notre solution en

50
précisant les différentes tâches à réaliser et on a cité la différence entre les différents
hyperviseurs existants sur le marché en terminant pour choisir la solution Citrix XenServer.

51
 CHAPITRE II : PRESENTATION DU XEN

Introduction
Après avoir présenté la virtualisation d’un point de vue global, nous allons étudier plus
spécifiquement le cas de la solution Xen. Le choix de cette solution a été largement
encouragé par le fait qu'elle cette solution soit open source et donc qu’il soit plus facile
d’obtenir des informations approfondies et précises à son sujet. Le projet Xen est soutenu
par une communauté très active mais également par un grand nombre d’industriels tels que
Novell, Sun, AMD, Cisco, Dell, HP, IBM, … Alors que de nombreuses autres solutions de
virtualisation existaient déjà, Xen a su s’imposer en implémentant pour la première fois la
paravirtualisation.

1) Les interactions entre l’hyperviseur, les applications, et le système d’exploitation

Tout d’abord, il est nécessaire de spécifier ce qu’est Xen. Xen est un hyperviseur de
virtualisation. L’hyperviseur est une couche logicielle présente entre le matériel physique
et les systèmes d’exploitation qui a pour but de traiter les instructions venant de ces
derniers. La définition de l’hyperviseur au sens du projet Xen est différente de la définition
de l’hyperviseur au sens d’autres projets tels que VMWare. Dans le dernier cas,
l’hyperviseur est un logiciel présent au-dessus d’un système d’exploitation permettant de
virtualiser des systèmes d’exploitation. L’hyperviseur Xen a pour but d’être minimaliste.
La raison derrière cela est qu’une erreur ou une faille dans ce dernier aurait des
conséquences sur tous les systèmes d’exploitation invités qui peuvent être nombreux. Au
fur et à mesure des versions, des fonctionnalités sont enlevées de l’hyperviseur et
transférées vers un des systèmes d’exploitation invités.

Le projet Xen a proposé de contourner le problème des instructions ne répondant

pas à la théorie de Popek et Goldberg en les supprimant des noyaux des systèmes
d’exploitation invités. En échange, ils furent remplacés par des « hypercalls » dans le
noyau Linux (CF 1.4.5.). Un hypercall est donc une instruction visant à remplacer une
instruction processeur problématique par une instruction s’adressant directement à
l’hyperviseur. Ceci est un changement par rapport aux solutions précédentes dans la
mesure où les systèmes d’exploitation invités de paravirtualisation sont conscients du fait
qu’ils se situent au-dessus d’une couche de virtualisation dénommée hyperviseur. Le
52
remplacement des instructions problématiques du noyau a été rendu possible par le fait que
les noyaux Linux et Unix soient open source.

Avec un système d’exploitation 32 bits, le noyau est exécuté dans l’anneau 0 qui est
celui doté d’un plus grand niveau de privilège, et les applications sont exécutées dans
l’anneau 3. Les anneaux 1 et 2 sont inutilisés dans la plupart des systèmes d’exploitation à
l’exception d’OS/2 et avec certaines configurations NetWare. Comme il a été dit
précédemment, l’hyperviseur a absolument besoin d’être exécuté dans l’anneau le plus
faible puisqu’il est l’intermédiaire exclusif avec le matériel. Ceci relègue donc les systèmes
d’exploitation invités à l’anneau1 (voir figure ci-dessous). Du fait que l’hyperviseur soit
dans le ring 0 et les systèmes d’exploitation invités soient dans le ring 1, il n’y a pas de
système d’exploitation hôte lorsque l’hyperviseur Xen est installé, ils sont tous
nécessairement virtualisés. Ceci illustre la différence de Xen avec les autres hyperviseurs
qui présentent tous un système d’exploitation hôte même si celui-ci est minimaliste.

Figure n°3.3 : Rings pour un système Xen en 32 bit

53
 Lorsqu’AMD a révisé l’architecture x86-32 dans le but de créer son architecture 64-
bits, connu sous le nom AMD64, des modifications ont été apportés au delà du passage en
64-bits. La modification qui nous intéresse le plus dans le cadre de la virtualisation est le
passage de quatre à deux anneaux. Cette modification a été motivée par le fait que les deux
anneaux intermédiaires n'étaient quasiment jamais utilisés comme vu précédemment. Ceci
pose un problème dans la mesure où dans l’architecture x86-32, l’hyperviseur a pu
simplement reléguer le noyau un anneau au-dessus pour s’assurer d’être le seul dans
l'anneau zéro. Or vu qu’il n’y a plus que deux anneaux dans l’architecture x86-64 et que
nous avons trois couches logicielles à exécuter (hyperviseur, noyau et applications), il
manque normalement un anneau. La solution a été de mutualiser l'anneau 1 pour les
applications et les noyaux

Figure 3.4: Rings pour un système Xen x86-64 sans extensions de

virtualisation

Une autre interaction primordiale entre l’hyperviseur et les systèmes

d’exploitation invités est la gestion du temps. Dans le cas d’un système d’exploitation
classique reposant sur un matériel, le système d’exploitation arrive à estimer le temps en
utilisant la fréquence du processeur et le nombre d’instructions effectuées. Or dans le cas
de la virtualisation, plusieurs systèmes d’exploitation invités se partagent les cycles
processeurs et ce, de manière irrégulière puisque pondérée en fonction des besoins
momentanés de chacun. Un dérèglement au niveau de l’horloge du système d’exploitation
peut poser de graves problèmes au niveau des communications réseau qui nécessitent
régulièrement un suivi précis du temps écoulé. Un exemple de ceci est le ping qui mesure
le temps écoulé entre le départ du message et son arrivée. D’autres applications en font
54
cependant un usage bien plus critique. Pour palier à ce problème, Xen doit très
régulièrement mettre à jour l’horloge interne des machines virtuelles dans le cas de la
paravirtualisation ou émuler une horloge système dans le cas de la virtualisation matérielle
assistée.

55
 2) Les domaines

Les systèmes d'exploitation invités que ce soit pour la paravirtualisation ou pour la

virtualisation assistée matérielle sont appelés domaines dans le cadre de Xen. Dans le cas
des autres produits de virtualisation, l’appellation de système d'exploitation invité reste
présente. La raison de cette différence est due au fait que tous les systèmes d’exploitation
sont virtualisés lorsque Xen est fonctionnel, même celui d’origine qui ne l’était pas avant
l’installation de Xen. Or nous avons vu précédemment qu’il est impossible d’accéder à
l’hyperviseur directement par le biais d’une interface graphique ou d’une interface en ligne
de commande à cause des risques liés à la sécurité. C’est pour cette raison qu’il existe
différents types de domaines disposant de différents droits.

a) Domaine privilégié

Le domaine privilégié est appelé domain 0 ou plus couramment dom0. Lors du

démarrage d’une machine disposant de Xen, la première application exécutée est
l’hyperviseur Xen ce qui est normal à la vue de sa situation dans les rings. La seconde
application est ensuite le domaine 0.

Le domaine 0 est un domaine essentiel pour Xen. Dans la mesure où il est

impossible d’accéder directement à l’hyperviseur pour y modifier des paramètres, le
domaine 0 endosse ce rôle à travers des outils et des fichiers de configuration. Le domaine
0 agit également en tant que VMM, c'est-à-dire, gestionnaire des machines virtuelles ou
plutôt gestionnaire des autres domaines. Toutes les données de disque des autres domaines
sont stockées dans le système de fichiers du domaine 0 qui y a totalement accès.

En ce qui concerne l’interaction avec le matériel, nous avons déjà vu que

l’hyperviseur était l’intermédiaire avec le processeur et la mémoire. Les autres
périphériques sont gérés par le domaine 0. La gestion des périphériques vidéo, de saisie, de
disque ou autres est effectué par des pilotes situés dans le système d’exploitation du
domaine 0. Le domaine 0 a un accès exclusif à ces périphériques par défaut. Cependant, les
versions récentes de Xen implémentent la possibilité de déléguer à un domaine non
privilégié l’accès exclusif à certains périphériques. L’interfaçage avec les domaines non
privilégiés se fait par le biais de pilotes standardisés, comme schématisé dans la figure 17
ce qui permet une très grande compatibilité.

56
 Figure 3.5 : Interactions domU/dom0/Xen

En ce qui concerne le réseau, le domaine 0 a pour rôle de centraliser toutes les

communications. Tous les paquets envoyés à partir des domaines non privilégiés passent à
travers la pile réseau du domaine 0 par le biais de diverses interfaces réseau virtuelles.
Grace à cette configuration, il est possible de configurer des architectures réseau
spécifiques avec les autres domaines tels que du NAT, du routage ou, plus simplement, un
pont. Il est également possible de mettre en place des règles de filtrage du trafic réseau en
fonction des fonctionnalités et du niveau de sécurisation souhaité.

En pratique, le domaine 0 est particulièrement sensible dans la mesure où il a accès

à toutes les données et contrôle tous les autres domaines. La mise en place sécurisée d’un
serveur de virtualisation Xen passe donc par une forte sécurisation du domaine 0. De plus,
une mauvaise modification au niveau de l’arborescence des fichiers utilisés par Xen rendra
le système inutilisable et mènera donc à l’indisponibilité de tous les domaines.

b) Domaines non-privilégiés

Les domaines non privilégiés sont appelés domaine U ou plus couramment domU
avec le U qui signifie unprivileged. Les domaines U sont exécutés par le domaine 0
automatiquement au démarrage de la machine la plupart du temps soit manuellement par le
biais d’outils. Un nombre théoriquement illimité de domaines non privilégiés peuvent être
exécutés dans la limite de la disponibilité de ressources telles que la mémoire vive ou
l’espace disque.

57
 En ce qui concerne les périphériques, les domaines non privilégiés y ont accès à
travers des pilotes standardisés pour Xen indépendamment du matériel sous-jacent. Le
référencement des périphériques auxquels ont accès les domaines non privilégiés se fait par
le biais du XenStore que nous évoquerons plus en détail par la suite. De nombreux
systèmes d’exploitation ont été modifiés pour rendre possible leur exécution en tant que
domaine non privilégié grâce à la simplification du support des pilotes de matériel. La
quasi-totalité de systèmes d’exploitation modifiés exécutables en tant que domaine non
privilégié de paravirtualisation sont des systèmes d’exploitation de type open source et un
support de la part de systèmes d’exploitation propriétaires n’est pas à prévoir avant
longtemps.

c) Domaines matériels assistés

Les domaines assistés matériels sont appelés domaines HVM et sont un type de
domaines non privilégiés. La différence avec les domaines non privilégiés classique est le
type de virtualisation. Dans le cas d’un domaine HVM, la virtualisation mise en œuvre est
la virtualisation assistée matérielle alors que dans le cas d’un domaine non privilégié, il
s’agit de la paravirtualisation.

Pour qu’un domaine HVM fonctionne correctement, Xen émule tout le matériel
pour que le système d’exploitation hôte puisse fonctionner correctement. Les pilotes qui
seront utilisés par le domaine HVM seront des pilotes capables de communiquer avec le
domaine 0 dans le but de pouvoir accéder au matériel même de manière indirecte. Le projet
Xen a choisi de ne pas redévelopper un module de virtualisation assistée matérielle mais a
choisi d’intégrer le projet QEMU. Par ailleurs, bien que le projet QEMU supporte la
virtualisation de systèmes d’exploitation non modifiés sans la présence des extensions
processeur adaptées, Xen a choisi de ne pas implémenter cette fonctionnalité. Il est donc
nécessaire que les extensions processeur de virtualisation soient présentes pour que Xen
puisse exécuter un domaine HVM.

Pour améliorer les fonctionnalités et les performances des domaines HVM, il est
possible de leur ajouter des pilotes de paravirtualisation ce qui contribue largement à
gommer la différence entre la paravirtualisation et la virtualisation assistée matérielle. Ces
pilotes vont permettre l'envoi d'hypercalls pour les systèmes propriétaires. De tels pilotes
sont disponibles pour Windows sous le nom de GPLPV Drivers. Pour communiquer avec
les domaines HVM, Xen utilise un périphérique PCI virtuel qui simplifie la

58
communication et le support des pilotes de paravirtualisation similairement à une carte de
calcul physique.

3) L’architecture du Xen en paravirtualisation

a) La gestion des informations système

Un système d'exploitation a besoin d'un certain nombre d'informations sur la machine

physique sous-jacente pour pouvoir fonctionner correctement. Ces informations vont
conditionner son fonctionnement par la suite. Des exemples d'informations nécessaires au
démarrage sont la quantité de mémoire vive, les périphériques, le type d'architecture ou
encore l'heure. Dans le cas d'un système d'exploitation classique installé directement sur
une machine physique, ces informations sont fournies directement par le BIOS.

Dans le cas de la virtualisation, un hyperviseur est ajouté entre les systèmes

d'exploitation invités et le matériel physique ce qui ne permet pas de gérer les informations
système de la même manière que lorsqu'il n'y avait pas d'hyperviseur interposé. La solution
va être de modifier le mécanisme de récupération des informations système. Ceci ne pose
pas de problème particulier dans le cas de la paravirtualisation puisque les noyaux sont
modifiés pour s'adapter à l'environnement de virtualisation. Dans le cas de la virtualisation
matérielle assistée, QEMU sera chargé d'utiliser ces informations pour créer
l'environnement virtuel. Les solutions qui seront exposées ici ne sont pas valables pour la
virtualisation matérielle assistée (HVM). Nous verrons ce cas plus en détail ultérieurement.

Xen met donc en place un mécanisme dénommé Shared Information Pages pour
pouvoir transmettre ces données aux domaines, que nous traduirons par pages
d'informations partagées. Il n'y a pas, au niveau de ces pages, de différence de
fonctionnement entre les domaines privilégiés et les domaines non privilégiés. Ces pages
d'informations partagées ne reprennent pas totalement les fonctionnalités du BIOS.
L'énumération des périphériques système qui est habituellement gérée par le BIOS est
remplacée par le mécanisme du XenStore que nous verrons plus en détail ultérieurement.
Le seul périphérique qui déroge à cette règle est le périphérique console. Ce dernier a été
inclut dans les pages d'informations partagées dans un but de débogage de sorte à pouvoir
obtenir des informations sur le lancement des domaines avant qu'ils accèdent au XenStore.

59
 Les pages d'information partagées sont placées dans l'espace d'adressage du domaine à
un endroit bien précis par le domain builder. Le domain builder est le logiciel qui va initier
et préparer l'exécution du nouveau domaine en interagissant avec l'hyperviseur. On parlera
de page d'information de démarrage dans le cas de la page d'information partagée
contenant les informations dont le domaine va avoir besoin lors de son lancement. Dès son
exécution le noyau va inspecter cette page pour pouvoir effectuer quelques vérifications
élémentaires. Une des vérifications qui sera effectué est un contrôle de l'environnement de
virtualisation afin de vérifier si le noyau en cours d'exécution est bien compatible avec la
version de l'hyperviseur Xen installé. Le projet Xen assure une rétrocompatibilité avec les
versions majeures à venir mais pas avec les versions mineures. Un exemple de paramètre
inscrit dans la page d'information de démarrage est la quantité de mémoire vive allouée au
noyau qui sera identifié dans le champ nr_pages. En ce qui concerne la gestion du
processeur, peu d'informations sont disponibles dans la page d'information de démarrage ce
qui fera que le domaine démarrera initialement sur un seul processeur virtuel et passera à
plusieurs à la suite de l'initialisation du système d'exploitation.

Le domaine va rapidement avoir besoin de plus d'informations sur son environnement

qui ne seront pas présentes dans la page d'information de démarrage. Cette dernière va
servir de support pour le référencement des pages d'informations suivantes. Ces références
sont des adresses de mémoire physique. Pour accéder à ces informations, le domaine
intéressé va devoir émettre un hypercall à l'hyperviseur pour adresser ces zones de la
mémoire physique dans ses zones de mémoire virtuelle. La première référence vers une
adresse de la mémoire physique de la machine pointe vers la page shared_info qui contient
de nombreuses informations intéressantes pour la suite de l'exécution du domaine.

La page shared_info est utilisée régulièrement lors de l'exécution du domaine.

Contrairement à la page d'information de démarrage, elle est mise à jour en permanence.
Elle contient des informations relatives à l'horloge du système, à l'architecture et aux
canaux d'événements que nous verrons par la suite.

60
 Figure 3.6 : Page shared_info

Le champ vcpu_info est un tableau de tableaux d'éléments de type vcpu_info_t. Leur

nombre dépend du nombre de processeurs virtuels alloués au domaine. Les trois attributs
de la table vcpu_info_t servent à informer le domaine sur le statut de ses processeurs
virtuels afin de pouvoir les gérer. Le domaine prend en compte le fait que le processeur ne
lui ait pas dédié et n'exécute pas que des instructions émanant de lui. Le tableau arch
permet de passer des informations sur l'architecture de la mémoire telle que l'adresse de la
dernière erreur de pagination (cr2). Le tableau time de type vcpu_time_info_t combiné avec
les attributs de préfixe wc_ permet la gestion de l'horloge système. La table arch_info_t
contient des informations spécifiques à l'architecture. Dans le cas d'x86, il contient les deux
attributs présents dans le schéma qui renseignent des références d'adressage entre la
mémoire du domaine et la mémoire physique.

b) La communication inter domaines

Précédemment, nous avions évoqué l'isolation des machines virtuelles comme un des
avantages de la virtualisation. Maintenant que nous nous intéressons à la virtualisation à un
niveau plus bas, il est intéressant de nuancer cette affirmation. Un isolement total des
domaines poserait de très sérieux problèmes puisqu'il ne leur serait possible d'accéder à des
périphériques systèmes émulés ou non. Il est donc essentiel de prévoir des mécanismes de
communication internes entre l'hyperviseur et les domaines mais aussi entre les domaines
et plus particulièrement entre les domaines U et le domaine 0.

Dans le cas d'un système d'exploitation sans virtualisation, les processus sont amenés à
communiquer entre eux qu'ils fassent parti de la même application ou non. Typiquement, il
sera très intéressant de donner la possibilité au noyau de communiquer avec les
applications directement pour pouvoir les couper en cas de surcharge du système ou en cas

61
de perte de réponse de l'application. Ceci est fait par le biais de zones de mémoire
partagées allouées par le noyau. Dans le cas où une application souhaite communiquer avec
une autre, une demande explicite sera faite au noyau qui allouera un espace mémoire
commun aux deux applications. Il sera ensuite possible à l'application d'inscrire diverses
données dans cette espace à destination de l'autre application. Une fois la communication
terminée, cette espace mémoire partagé sera réalloué pour des raisons de sécurité. On parle
donc d'IPC (InterProcess Communication).

L'hyperviseur Xen a choisi d'adopter un mode de fonctionnement similaire en mettant à

disposition de domaines souhaitant communiquer des zones de mémoire partagées.
L'utilisation de ces zones de mémoire partagées sera gérée par les domaines
communiquant. On parle dans ce cas-là d'IDC (InterDomain Communication). Dans un
système d'exploitation classique, elles sont dynamiquement réparties entre la mémoire vive
et les zones de pagination sur le disque dur (swap). L'hyperviseur Xen a choisi pour des
raisons de minimalisme de ne fournir des zones de mémoire partagées uniquement en
mémoire vive. La gestion de zones de pagination sur disque est entièrement déléguée aux
domaines. Les zones de mémoire partagées sont identifiées par un entier dénommé grant
reference que nous traduirons par référence d'allocation en Français.

L'interfaçage avec les mécanismes de zones de mémoire partagée de Xen se fait par
le biais de l'hypercall grant_table_op. Cet hypercall est effectué par le noyau du domaine
comme nous l'avons vu précédemment. Cet hypercall prend trois arguments : le type
d'opération à effectuer, un tableau contenant les opérations à effectuer et le nombres
d'opérations à effectuer. Nous verrons la structure de la table d'allocation par la suite. Cette
fonction est polymorphique dans la mesure où le type du second argument dépend du
premier argument. Deux types d'opérations sont possibles avec cet hypercall, l'allocation et
le transfert de zones. La différence entre ces deux opérations est qu'avec l'allocation, la
zone de mémoire partagée est laissée dans la zone de mémoire globale du domaine originel
alors que le transfert la supprime.

Le transfert de zones de mémoire partagées ne peut se faire que dans le cas où le

récepteur a manifesté un intérêt à recevoir un transfert. Cette contrainte est mise en place
pour sécuriser le transfert des zones et éviter qu'un domaine ne sollicitant pas de partage se
voit ajouter des zones de mémoires extérieures dont il ne connait ni la provenance ni la
fiabilité qui pourraient contenir du code malicieux. La manifestation de l'intérêt d'un
transfert de page se fait par le biais de la table d'allocation du domaine.

62
 Le transfert est un mécanisme efficace de transfert de données volumineuses entre
différents domaines puisqu'une fois que les données sont écrites, il n'y a plus qu'à mettre à
jour la table d'allocation de la mémoire vive. Ceci est cependant peu efficace dans le cas du
transfert de faibles volumes de données.

Une solution plus efficace peut être la copie à partir de la zone de mémoire propre
au domaine récepteur vers la zone de mémoire partagée. Ceci ne peut être intéressant que
dans la mesure où le partage est déjà mis en place puisqu'il n'est pas nécessaire de modifier
la table d'allocation. Dans le cas où le partage n'a pas été mis en place, il sera plus
intéressant de faire un transfert.

De plus, il est possible de faire un transfert entre deux domaines sans qu'aucun des
deux n'ait fait de demande. Par exemple, un domaine peut avoir un accès exclusif à la carte
réseau dans le but de limiter l'impact d'une erreur avec ce périphérique. Le domaine 0 sera
amené à faire des copies de données entre le domaine responsable de la carte réseau et
d'autres domaines nécessitant l'accès au réseau. Tout ceci sera parfaitement transparent
pour tous les domaines sauf le domaine 0.

c) La gestion du temps

La gestion du temps est un aspect important d'un système d'exploitation. Ce dernier en

a besoin constamment pour son bon fonctionnement. Des exemples sont l'exécution de
tâches programmées dans le temps, l'ordonnancement des processus, l'affichage d'horloges,
l'horodatage de systèmes de fichiers ou encore différents protocoles réseaux. L'utilitaire
ping est un bon exemple dans la mesure où il est nécessaire de connaitre l'heure de départ
et d'arrivée du paquet avec une précision de l'ordre du dixième de milliseconde. Un
problème dans la gestion du temps pourra résulter en un temps de latence négative ou,
inversement, un temps très grand alors que le paquet a été transmis promptement et
correctement.

Dans le cadre d'un domaine Xen, le temps peut s'écouler de deux manières différentes :
lorsque le domaine a des ressources de calcul à sa disposition et lorsqu'il est mis en attente.
Lorsqu'un domaine a des ressources de calcul à sa disposition, il reçoit un signal tous les 10
ms ce qui lui permet de gérer l'ordonnancement des différents processus en cours. On parle
donc dans ce cas de gestion du temps virtuel qui correspond au temps d'exécution effectif
du système. Le temps virtuel exclue donc toute période d'attente.

63
 Bien que le temps virtuel soit très utile pour l'ordonnancement des processus du
domaine, il est inefficace pour d'autres fonctionnalités telles que l'horodatage de fichiers ou
les protocoles de communication réseau. Le domaine va donc avoir besoin de connaitre le
temps réel. Pour obtenir le temps réel, le domaine va avoir accès à trois valeurs qui sont
contenus dans page shared_info vue précédemment.

La première valeur est l'heure initiale qui correspond à l'heure du lancement du

domaine. Cette valeur servira d'origine pour la suite de la gestion du temps réel. Elle est
contenue dans le champ comportant pour préfixe wc_ (abréviation de wall clock). La
seconde valeur est l'heure système qui correspond au temps écoulé depuis le démarrage du
domaine. Elle est mise à jour dès que des ressources de calcul sont allouées au domaine.
Cette valeur est également stockée dans le champ system_timede la page shared_info. La
troisième valeur est le TSC (Time Stamp Counter) qui correspond au nombre de "ticks"
depuis le démarrage. Il s'agit de l'unité de base du comptage du temps système. Le nombre
de ticks est mis à jour tous les cycles d'horloge. Dans le cas de processeurs plus récents tels
que le Core 2 Duo d'Intel, le TSC n'est mis à jour qu'une fois tous les quatre cycles
processeur. Cependant deux propriétés sont assurées : les valeurs augmentent de manière
monotone et l'augmentation est proportionnelle aux cycles du processeur. L'incrémentation
du TSC est effectuée par l'hyperviseur et est propagée aux domaines par le biais des pages
shared_info.

Les deux premières valeurs vont permettre un calcul approximatif mais simplifié de
l'heure. Ce calcul suffira dans le cas d'applications nécessitant peu de précision telle que
l'affichage d'une horloge.

Ce mode de calcul ne sera cependant pas suffisant dans le cas d'applications nécessitant
une forte précision. Dans ce dernier cas, les applications vont pouvoir bénéficier de l'apport
du TSC.

Finalement, les domaines disposent de deux grandeurs de temps : le temps virtuel et

le temps réel. Le temps virtuel est calculé par le domaine de manière autonome. Le temps
réel a cependant besoin de l'intervention de l'hyperviseur pour fournir des données plus
précises et nécessitant des informations système.

64
 d) La gestion de mémoire

i. Modèle de gestion de mémoire en para-virtualisation

Dans un système virtualisé on trouve 3 niveaux d’indirection de la mémoire.

L’indirection est le fait de ne pas accéder directement à l’espace d’adressage physique. Au
niveau le plus haut on retrouve l’application qui est lancé dans un système invité. Celle-ci
dispose d’un certain espace d’adressage mémoire. C’est le premier niveau d’indirection.
Cette application fonctionnant dans un système invité, celui-ci dispose de son espace
d’adressage propre. Nous avons ici le deuxième niveau d’indirection. Enfin puisque nous
sommes en paravirtualisation, ce système invité fonctionne au dessus d’un hyperviseur.
Celui-ci possède tous les droits pour manipuler la mémoire physique. C’est son rôle de lier
la mémoire allouée aux systèmes invités avec la mémoire physique. C’est le 3 ème niveau
d’indirection.

Figure 3.7 : Couches de gestion mémoire Xen

La question que l’on peut se poser est pourquoi avoir ajouté une couche
d’indirection mémoire. En effet il aurait pu être possible que les différents systèmes invités
existent dans l’espace d’adressage physique tout en faisant attention à ne pas n’accéder à
des segments appartenant à un autre système. Cette solution n’a pas été retenue car les
systèmes d’exploitation ont été développés de façon qu’ils soient seuls sur une machine
physique. De ce fait ils croient que leur espace d’adressage est continu. La seconde raison
qui justifie l’existence d’une 3ème indirection est la gestion de la migration à chaud. Il est
possible sous Xen de sauvegarder l’état complet d’une machine, de la mettre en pause pour
de la remettre en fonctionnement sur une autre machine physique. Les adresses physiques
des pages mémoire que la machine va se voir ré alloués seront à coup sur différentes. De ce
65
fait on est obligé d’avoir cette couche d’indirection entre les systèmes invités et
l’hyperviseur. Ainsi une fois le système migré, le nouvel hyperviseur réalloue un certain
espace d’adressage physique qui n’est pas forcement continu au système invité. Celui-ci
peut reprendre ces taches une fois que les pages mémoires seront chargées à nouveaux.

Nous avons parlé précédemment des tables LDT et GDT. Dans Xen les systèmes
invités ont accès aux LDT qui sont des espaces d’adressages mémoires dédiées aux
applications. Mais ils ne peuvent modifier les valeurs des espaces GDT que par un
hypercall spécifique. A chaque hypercall Xen doit pouvoir accéder à la mémoire dédiée à
l’hyperviseur ainsi qu’à l’espace d’adressage du système invité qui demande l’hypercall.
La solution retenue pour remplir cette tache est d’opérer un changement de contexte à
chaque hypercall.

C’est à dire que l’on met en attente d’exécution un processus par le processeur.
Ensuite on redirige les demandes d’accès aux pages d’adresses mémoire du système invité
vers l’espace d’adressage de l’hyperviseur comme le demande ce système via l’hypercall.

Ainsi grâce à l’hypercall on permet a système invité d’accéder à des informations

qu’il n’est pas censé obtenir sans augmentation de privilèges. Mais ceci n’est pas une tache
courante et heureusement car c’est très gourmant en ressources. Ceci peut nécessiter 500
cycles processeur sur un Pentium 4. Afin d’adresser ce type de demande, sur un système
x86-32Bits, Xen se réserve les 64 premiers Méga Octets de la mémoire vive. Les
descripteurs de segments qui permettent l’accès à ce type de mémoire ont le champ de
privilèges à 0 pour n’autoriser l’accès qu’a l’hyperviseur.

Les descripteurs de segments mémoire alloués aux noyaux dans un système Xen
retrouvent le champ lié aux privilèges à 1 dans ces descripteurs de segments. La lecture des
informations est possible par les systèmes invités mais pas leur modification. Seul le noyau
et l’hyperviseur peuvent modifier ces informations.

Pour résumer, lorsqu’un système invité désire accéder à des tables de pages (qui
permettent l’accès à la mémoire physique) qui ne sont pas dans son anneau de permissions,
un hypercall va permettre d’effectuer ce lien entre le système invité et l’hyperviseur.

66
 ii. Mise à jour de la table des pages

Comme dit précédemment en conclusion, lorsqu’un système invité « aussi appelé

guest » va vouloir mettre à jour ses tables de pages il devra passer par un hypercall. Plus
précisément pour tout accès en lecture dans l’espace d’adressage qui lui est propre, le guest
n’aura pas besoin de faire un hypercall ces manipulations de lecture sont autorisées.

Néanmoins pour tout autre accès, on pense bien évidemment à la mise à jour de ces
propres tables de pages il devra effectuer un hypercall. Cela permet d’être sûr qu’aucun
système invité ne puisse modifier un espace d’adressage sans mécanisme d’hypercall
validé par l’hyperviseur.

En effet un guest ne peut modifier ces tables directement, mais un hypercall

effectuera cette demande de mise à jour si celle-ci est fondée. Toute demande de
modification d’espace mémoire qui n’appartient pas au guest se soldera par un échec.

Du fait qu’un hypercall et bien plus gourmand en ressources qu’un simple accès
mémoire on va pouvoir passer dans un seul hypercall la mise à jour de multiples pages.

iii. La création d’un DomU : l’aspect mémoire

A l’initialisation d’un système d’exploitation invité, certaines choses doivent être

chargées dans sa mémoire. C’est le Dom0 qui sera chargé de cette tache vu que c’est par
son intermédiaire que l’on créée un nouveau DomU. Les informations à charger en
mémoire sont le noyau du guest et la start info page qui est l’équivalent de son bios. La
mémoire doit également contenir les accès nécessaires à la lecture de la table des pages.
Les instances de chaque pilote doivent également être chargées dans la mémoire.
Un Hypercall utilisé depuis le Dom0 appelé HYPERVISOR_memory_op permet de
configurer tous ces paramètres. Il permet également de définir l’espace mémoire initial
d’un DomU.

67
 iv. Les gestions des fautes de pages
Un défaut de page correspond à une série d'événements se déroulant lorsqu'un
programme essaie d'accéder à des données ou à un code qui se trouvent dans son espace
d'adressage mais ne sont pas actuellement placées dans la mémoire vive. Le système
d'exploitation doit traiter les défauts de pages en permettant, d'une manière ou d'une autre,
l'accès à la mémoire des données recherchées afin que le programme puisse continuer ses
opérations, comme si le défaut de page ne s'était jamais produit. (Red Hat Inc s.d.)

La première chose à faire en cas de faute de page est de trouvé l’adresse mémoire
qui a causé cet évènement. Sous x86 ces informations sont stockées dans un registre
nommé CR2. Sous Xen ces informations sont copiées dans l’élément cr2 de la structure
arch_vcpu_info (cf 4.1.1). Cette opération de copie est nécessaire car le mécanisme de
stockage des fautes de pages accède à la mémoire et peut lui aussi générer des fautes de
page. Si cela se produit, le contenu du registre CR2 est écrasé. Une fois l’adresse mémoire
qui a causé la faute de page retrouvée, il reste à mettre à jour son contenu. Une fois fait
l’hypercall HYPERVISOR_update_va_mapping va lier l’adresse virtuelle avec la nouvelle
adresse physique. (Chisnall 2007)

e) La gestion de l'ordonnancement

Nous avons déjà vu précédemment que le principe de la virtualisation consiste à

exécuter plusieurs systèmes invités sur une même machine physique. Cette propriété
essentielle implique la gestion de l'allocation de ressources de calcul parmi tous les
domaines. L'hyperviseur est responsable d'assurer cette répartition de ressources. Cette
répartition est très similaire à la répartition de ressources parmi des processus dans un
système d'exploitation classique.

Un processus présent dans un domaine va donc être amené à être géré par plusieurs
ordonnanceurs avant de pouvoir accéder à des ressources de calcul. Un ordonnanceur
(scheduler en anglais) est un algorithme qui va gérer selon divers critères l'allocation des
ressources de calcul à une entité demandeuse. Cette entité demandeuse peut être un
processus comme dans le cas d'un système d'exploitation classique ou bien un domaine
dans le cas de Xen.

Un processus exécuté dans un domaine va tout d'abord être géré par l'ordonnanceur
utilisateur qui a pour but d'envoyer le processus vers l'ordonnanceur du noyau. Celui-ci va
ensuite répartir les processus parmi les différents processeurs virtuels alloués au domaine
68
(VCPU). Finalement, l'hyperviseur va répartir les processeurs virtuels parmi les
processeurs physiques. Etant donné que l'ordonnanceur se retrouve au fond de la pile, il est
nécessaire qu'il soit prévisible puisque les ordonnanceurs au dessus vont être amenés à
faire des prévisions sur l'allocation de ressources.

Dans les versions actuelles de Xen, nous pouvons retrouver deux ordonnanceurs : le
SEDF (Simple Earliest Deadline First) et le Credit Scheduler que nous pouvons traduire
par ordonnanceur à crédit. Ce dernier a tendance à prendre le dessus du SEDF et est activé
par défaut.

L'ordonnanceur SEDF peut se traduire par ordonnanceur du plus urgent d'abord. Dans
le cas d'un ordonnanceur de processus dans un système d'exploitation, il n'est pas possible
de prévoir le temps d'exécution d'une tache ou la périodicité de son exécution. Dans le cas
du SEDF, le temps d'exécution et la périodicité sont définis. Par exemple, un domaine va se
voir alloué 5 ms de calcul toutes les 10ms.

Cet algorithme d'ordonnancement a le mérite d'être parfaitement déterminé et donc tout

autant prévisible. Il comporte cependant un inconvénient de taille. Si un domaine n'a pas
besoin de sa part de ressources, elle ne sera pas réalloué à un autre domaine. Ceci résulte
en une sous consommation de ressources processeur alors qu'un domaine n'en aura pas
suffisamment pour tout exécuter à temps. Une autre problématique de cet algorithme se
pose dans la configuration suivante1 :

• Domaine 1 : 20 ms toutes les 100 ms

• Domaine 2 : 2 ms toutes les 10 ms

• Domaine 3 : 5 ms toutes les 10 ms

Les domaines 2 et 3 se verront alloués des ressources de manière prioritaire puisque

leur exécution est la plus urgente étant donné qu'ils doivent être exécutés dans les 10 ms à
venir. Entre ces deux domaines, le domaine 3 sera exécuté en premier puisque le domaine
2 pourra encore attendre 8 ms. Il arrivera un moment où le domaine 1 sera le plus urgent à
exécuter. Il se pose donc un problème car si le domaine 1 est exécuté entièrement, les
domaines 2 et 3 ne pourront pas obtenir les ressources dont ils ont besoin. La solution à ce
problème est tout simplement de raccourcir le temps d'exécution du domaine 1 et de

1
69
prévoir une répartition du temps d'exécution du domaine 1 sur le temps laissé libre par les
deux autres domaines.

L'ordonnanceur nommé Credit Scheduler que nous pouvons traduire par

ordonnanceur à crédit est celui par défaut des versions actuelles de Xen. Pour qu'il puisse
fonctionner, il est nécessaire d'associer deux attributs à un domaine : le poids et la limite.
Le poids détermine la part des ressources de calcul qui sera allouée au domaine. La limite
détermine la part maximale des ressources qui pourra être allouée au domaine. Il est tout à
fait possible de ne spécifier aucune limite. Lorsqu'aucune limite n'est spécifiée, cet
ordonnanceur permet d'utiliser au maximum les ressources du processeur. A l'inverse, si la
somme des limites est inférieure à la totalité des ressources de calcul disponibles, le
processeur sera sous utilisé. Cet algorithme utilise un mélange d'autres algorithmes tels que
le tourniquet et l'ordonnancement à priorité.

Pour pouvoir expliquer plus clairement le fonctionnement de cet algorithme

d'ordonnancement, nous allons prendre l'exemple suivant :

• VCPU 1 : poids 64, limite 25%

• VCPU 2 : poids 64, pas de limite

• VCPU 3 : poids 128, pas de limite

Au début de l'exécution, chaque domaine se verra alloué un nombre de crédits

proportionnel à son poids. Les deux premiers VCPU auront par exemple 64 crédits alors
que le troisième VCPU aura 128 crédits. L'ordonnanceur va ensuite allouer des ressources
à chaque VCPU selon la méthode du tourniquet. Les deux premiers domaines vont donc
effectuer leurs calculs chacun leur tour jusqu'à l'épuisement de leurs crédits. Les crédits
sont décrémentés de manière régulière et linéaire tous les 10 ms. Le troisième domaine va
ensuite avoir le processeur pour lui seul jusqu'à épuisement de ses crédits.

70
 Dans le cas où le troisième domaine n'aurait pas de calcul à effectuer, les deux
premiers domaines se partageront le processeur de manière équitable jusqu'à ce que le
premier VCPU atteigne sa limite. Le second VCPU sera donc le seul à utiliser le
processeur. Il sera donc amené à utiliser plus de crédits que ce qu'il lui a été alloué
initialement mais vu qu'il est seul à vouloir accéder au processeur cela ne pose pas de
problème. Des nouveaux crédits sont alloués à chaque tour du tourniquet. Si une allocation
de crédit a lieu lorsque le premier VCPU est toujours bloqué par sa limite, les crédits
disponibles seront répartis entre les autres VCPU. Une fois que le troisième VCPU
souhaiterait à nouveau soumettre des calculs au processeur, le second VCPU ne pourra plus
dépasser son montant de crédit et les ressources de calcul seront allouées équitablement
entre ces deux VCPU. Au final, nous avons explicité la nécessité pour l'hyperviseur Xen
de disposer d'un ordonnanceur pour répartir les ressources de calcul de manière dynamique
entre les différents domaines et nous avons expliqué le fonctionnement des deux
ordonnanceurs présents dans les versions actuelles de Xen. La problématique des
applications synchrone et temps réel se pose donc. Par nature, la virtualisation ne favorise
pas ces applications puisque le temps de calcul est réparti parmi plusieurs environnements
logiciels ce qui ajoute un temps de latence entre les allocations de ressources. Une solution
va être de faire tendre le ratio de VCPU par processeur physique vers 1

4) Le réseau sous Xen

Le fonctionnement du réseau sous Xen utilise la méthode expliquée en 4.1.2. En
effet la communication inter domaine est utilisée dans la communication réseau dans Xen.

Toutes les communications réseau des DomU passent per le Dom0. Deux tunnels
sont établis entre le DomU qui veut communiquer avec l’extérieur et le Dom0. Le premier
est un tunnel de service et le second de données. Ces tunnels sont en réalité des zones de
mémoire partagées entre les domaines, à noter que celles-ci sont distinctes. Le mécanisme
de communication réseau inter domaine utilisé dans Xen est identique aux autres
mécanismes de communication système. La seule différence entre ce mécanisme de
communication et les autres, est le fait qu’ici il y a deux zones mémoire par type de tunnel,
une pour l’émission et une autre pour la réception.

Le tunnel de service comprendra les données qui vont permettre de localiser dans
les pages mémoires les « données brutes réseau » à transmettre.

71
 Lorsque le DomU veut transmettre des informations sur le réseau, il va faire une
demande dans un espace mémoire. L’action est faite via le « tunnel de service ». Une fois
la demande traitée par le Dom0, l’espace mémoire précédent va être remplacé par sa
réponse. Une fois l’échange fait, le paquet réseau peut être émit via le « tunnel de données
» puis retransmis sur le réseau via le Dom0.

Lorsqu’un paquet réseau arrive sur l’interface de la machine physique,

l’information arrive systématiquement au Dom0. Celui-ci adresse le paquet au DomU qui
convient, ceci par l’intermédiaire d’une zone mémoire commune.

La communication réseau entre les DomU d’une même machine physique est
gourmande en ressources processeur. Pour cela un allègement des trames de la couche
liaison a été effectué. Le champs checksum qui est le dernier champ de la trame réseau
n’est jamais calculé pour des communications réseau inter domaines. Ainsi une puissance
de calcul non négligeable est préservée, assurant ainsi de bonnes performances dans les
transferts réseau inter domaines. La disparition de ce champ de contrôle n’influe pas sur la
fiabilité des transmissions réseaux puisque toutes les communications ont lieu en mémoire.

Toutes les communications réseau passent par le DomO. Concernant celles qui vont
à l’extérieur de la machine, la segmentation de niveau réseau et transport sera assurée par
la carte réseau. Concernant les communications inter domaines, aucune segmentation n’est
effectuée. Ceci pour le simple fait que tout est écrit et lu en mémoire et que la segmentation
des paquets n’est plus nécessaire.

72
 PARTIE IV : SIMILATION ET IMPACT DU PROJET

Introduction :

Durant ce chapitre on va présenter les différentes phases de l'implémentation de

notre environnement virtualisé, les différents outils logiciels et matériels utilisés pour la
réalisation de notre solution.

On va aussi présenter les fonctionnalités des applications et quelques tests

permettant de démontrer le bon déroulement de leurs fonctionnalités.

4.1. Environnement de travail :

4.1.1. Matériels :
-Un PC portable Toshiba ayant les caractéristiques suivantes :

• Système d'exploitation : Windows 7 Professionnel.

• Processeur : Intel® Core™ i3 CPU M 330@2.13Ghz

• Mémoire : 4 GO

• Type de système : Système d’exploitation 32 bits

-Un serveur HP Proliant DL180 G6 ayant les caractéristiques suivantes

73
 Figure 4.1 : Spécifications techniques du serveur HP Proliant DL 180 G6

4.1.2. Logiciels :

• Citrix XenCenter :

XenServer est une plateforme open source leader sur le marché pour des infrastructures
virtuelles d’applications, de bureau, de nuages et de serveurs rentables. Elle permet aux
organisations de n’importe quelle taille ou type de consolider et de transformer les
ressources de calcul en charge de travail virtuel pour les besoins actuels des centres de
données, tout en assurant une voie transparente pour déplacer les charges de travail vers le
Cloud [5].

74
 • Windows 2012 Server R2 :

Anciennement connu sous le nom de code Windows Server8, est la seconde avant
dernière version du système d’exploitation réseau Windows Server .

4.2. Description de l’application :

4.2.1. Installation de Citrix XenServer :

L’installation de XenServer 7.0 est assez simple, un assistant d’installation avec une
interface utilisateur minimale rassemble les paramètres nécessaires tels que le nom d’hôte,
la configuration du réseau, le mot de passe, etc.

Une fois toutes les informations fournies, l’installation peut démarrer.

Les Figures 4.2, 4.3, 4.4, 4.5, 4.6 montrent quelques impressions du processus
d’installation :

Figure 4.2 : XenServer Setup

75
Figure 4.3 : Confirmation du mot de passe

Figure 4.4 : Configuration d’ XenServer

76
 Figure 4.5 : Installation d’XenServer

Figure 4.6 : Statut du serveur HP Proliant

Une fois l'installation est terminée, le système peut être géré à distance via XenCenter. Il
s'agit d'un logiciel de gestion graphique basé sur Windows, qui peut être téléchargé depuis
le XenServer lui-même; en tapant simplement l'adresse IP du serveur dans un navigateur
Web

77
 Figure 4.7 : Phase de recherche du logiciel de gestion graphique

4.2.2. Installation du XenCenter 7.0 :

On lance l’exécutable Xencenter.exe, puis nous allons suivre les étapes d’installation,
jusqu'à l’installation de « Citrix XenCenter » (Figure 4.8).

Figure 4.8 : Citrix XenCenter Setup

En exécutant l’application « Citrix XenCenter » après quelque seconde, l’écran d’accueil

qui se présente comme suit (Figure 4.9).

78
 Figure 4.9 : Ecran d’accueil du Citrix XenCenter

Dans le cadre de notre projet, nous allons donc poursuivre en ajoutant nos serveurs
« XenServer » à notre XenCenter, ainsi que leur adresse IP et leur authentification (Figure
4.10).

Figure 4.10 : Ajout d’un serveur sous Citrix XenServer

79
 4.2.3. Ajout d’une machine virtuelle :
Pour ajouter une machine virtuelle, on procède comme suit :

Tout d’abord on commence par le choix de notre système d’exploitation équivalant à notre
serveur et ses fonctionnalités.

Figure 4.11 : Ajout d’une machine virtuelle (VM)

Figure 4.12 : Choix du Windows Serveur 2012 R2 lors de l’installation d’ISO library
Après on configure la machine virtuelle (VM) selon les prérequis du serveur à
installer en précisant la taille de disque, les performances de processeur, les RAM et la
configuration des cartes réseaux (Figure 4.12).

Lorsqu’on termine toutes les informations nécessaires, notre machine virtuelle est
prête pour l’utilisation et on passe à l’installation de système d’exploitation qui est dans
notre cas Windows server 2012 R2.

80
4.2.4. Installation de Windows 2012 serveur :

La copie d’écran montre l’installation de la version de Windows server 2012 R2

Datacenter (Figure4.13).

Figure 4.13 : Installation de Windows 2012 Server R2

Nous choisissons une installation personnalisée, donc nous devons partitionner les disques
durs de notre machine virtuelle et lancer le début d’installation. (Figure 4.14).

81
 Figure 4.14 : Partition des disques durs
Cet écran nous permet de supprimer des éventuelles partitions existantes et permet de créer
une nouvelle partition.
NB : La taille du disque qui nous apparait c’est la taille du disque déjà choisi dans la
configuration précédente de la machine virtuelle (Figure 4.15).

Figure 4.15 : Précision de la taille du disque

Après l’ouverture de notre session, voici à quoi devrait ressembler notre écran (Figure
4.16).

82
 Figure 4.16 : Tableau de bord de gestionnaire de serveur

La figure 4.16 présente le tableau de bord de gestionnaire de serveur.

L’administrateur peut administrer et ajouter des rôles pour un serveur et pour les étapes
suivantes on va ajouter des rôles pour chacun des serveurs utilisés.

4.2.5. Installation d’Active Directory :

Le premier serveur à installer est le serveur AD (active directory), vue son
importance au niveau des services centralisés d’identification et d’authentification à un
réseau d’ordinateurs utilisant le système Windows.
On va poursuivre les étapes d’installation de la fonctionnalité AD DS selon la (Figure
4.17).

83
 Figure 4.17 : Choix du service Active Directory
Lorsqu’on termine l’installation on remarque que le service est bien installé mais le
domaine n’est pas encore créé.

Pour cela on va créer notre domaine.

On choisit le nom de domaine et on active le service DNS et un mot de passe sécurisé soit
pour l’administration soit pour la restauration des services AD (Figures 4.18, 4.19).

Figure 4.18 : Configuration post-déploiement

 Figure 4.19 : Configuration de déploiement

Dans la dernière étape, on peut vérifier que l’adresse IP correcte se trouve dans les
redirecteurs en utilisant la commande « nslookup » (Figure 4.20).

Figure 4.20 : Vérification de l’adresse IP

4.2.6. Installation de serveur bureau à distance (Terminal Server) sous Windows2012

R2 :

Notre destination c’est le gestionnaire de serveur, l’option « Ajouter des rôles et des
fonctionnalités » nous permet d’installer le Service bureau à distance (Figure 4.21).
 Figure 4.21 : Choix du service bureau à distance
Lorsqu’on termine l’installation il nous reste que de donner les accès pour les utilisateurs et
de les ajouter au groupe de bureau à distance comme l’explique la figure ci-dessous
(Figure 4.22).

Figure 4.22 : Ajout des utilisateurs au groupe de bureau à distance

 4.3 Simulations

4.3.1 Mise en œuvre a la solution Xen :

La mise en œuvre de la solutions Xen à vérifier les fonctions offertes par le serveur comme
:

 Changement des distributions sans éteindre l’ordinateur

 L’accès au dossier partagé

 Vérification des stratégies de groupe

 S’authentifier aux serveur Active Directory (Windows).

4.3.2 impact et solution du projet :

Le système d’exploitation et les applications sont rarement l’origine d’un problème

informatique. En effet, les causes de dysfonctionnement logiciel proviennent
essentiellement d’une charge de travail trop importante et il convient dans ce cas de
supprimer le goulot d’étranglement en répartissant les charges.

En revanche, côté matériel, un composant physique peut tomber en panne. Or la

défaillance d’une ressource critique (SPF : Single Point Of Failure) met hors service la
totalité du système informatique. On peut citer comme ressource critique :

 Processeur

 Carte mère

 Alimentation

 Interface réseau

 Disque, contrôleur de disque, câblage des systèmes de stockages

On supprime le caractère critique de ces ressources en faisant fonctionner plusieurs

de ces éléments au sein du même système. Ainsi, la redondance matérielle permet d’éviter
l’arrêt total du service. Dans le marché, des serveurs de moyennes gammes offrent déjà ces
solutions avec un prix raisonnable. De plus, si le service peut être rendu (simultanément ou
non) par plusieurs machines, le problème d’arrêt d’un serveur ne pose plus aucun
problème.

Qu'elles soient prévues ou imprévues, les interruptions de service engendrent des

coûts considérables. Cependant, les solutions assurant des niveaux élevés de disponibilité
sont généralement chères et difficiles à implémenter et à gérer.

La haute disponibilité présente les solutions permettant d’assurer la continuité de

service, pour donner suite à un dysfonctionnement de l’infrastructure, par une reprise
immédiate voire transparente de l’activité. Il permet de réduire les interruptions de service
prévues, d'éviter des interruptions de service imprévues et de récupérer rapidement pour
donner suite à des interruptions.
CONCLUSION GENERAL :

La virtualisation est principalement utilisée pour masquer l’hétérogénéité matérielle

et système. Un système d’exploitation virtualise les périphériques et une machine virtuelle
virtualise de plus le processeur. Les machines virtuelles concrètes virtualisent des
processeurs existants alors que les machines virtuelles abstraites définissent de nouveaux
processeurs abstraits. La virtualisation est un sujet essentiel et très étudié depuis ces
dernières années avec d’une part l’émergence d’Internet et le besoin d’uniformisation des
applications, et d’autre part la puissance des processeurs récents qui permettent de loger
plusieurs systèmes sur la même machine.

La première partie nous a permis de généraliser les raisons auxquelles le thème a

été choisi.

Puis nous avons faire un tour d'horizon des différentes techniques de virtualisation
de systèmes d'exploitation. Ceci nous a permis d'établir un arbre de classification de ces
dernières.

La troisième partie nous a ensuite permis d'établir les notions nécessaires à l'étude
en profondeur du fonctionnement d'un système d'exploitation. Grace à ces notions, nous
avons pu étudier le projet Xen. Nous avons étudié le fonctionnement de diverses
composantes telles que la mémoire, le temps, la communication entre les domaines et le
réseau

Enfin la dernière partie nous a permis de faire une simulation. Vu que la

technologie de la virtualisation est d’une étendue très vaste, l’analyse peut encore être
élargie de façon détaillée sur chacune des sections abordées dans ce mémoire. Pour
conclure, un approfondissement n’est surtout pas à exclure concernant les facteurs
matériels et logiciels qui influent la performance des serveurs virtuel