BAYE_O_FALL-SAIDOU_MBODJI-LabUT.pdf

RÉPUBLIQUE DU SENEGAL
Un Peuple- Un But- Une Foi
Ministère de l’Enseignement Supérieur, de la Recherche et de l’Innovation
Projet de Fin de Cycle pour l’obtention d’une
Licence Informatique, Réseaux et Télécommunications
Présenté par : Encadré par :
Baye Ousseynou FALL Docteur Moussa Déthié SARR
Saïdou MBODJI
Année Académique : 2020-2021
UNIVERSITE IBA DER THIAM DE THIES
UFR des Sciences et Technologies
Département Informatique
Etude et Mise en Place d’un Environnement
Virtuel Hautement Disponible

2020-2021 II BAYE OUSSEYNOU & SAIDOU MBODJI

2020-2021 III BAYE OUSSEYNOU & SAIDOU MBODJI
SOMMAIRE
INTRODUCTION GENERALE
I. CHAPITRE I : CADRE GENERAL DU PROJET
A. PRESENTATION DE L’ORGANISME D’ACCUEIL
B. ETUDE ET CRITIQUE DE L’EXISTANT
C. SOLUTION PROPOSEE
II. CHAPITRE II : VIRTUALISATION
A. HISTORIQUE DE LA VIRTUALISATION
B. NOTION DE VIRTUALISATION
C. LES TYPES DE SOLUTIONS DE VIRTUALISATION
D. LES HYPERVISEURS
E. CATEGORIES DE VIRTUALISATION
F. DOMAINES D’APPLICATION
III. CHAPITRE III : ETUDE COMPARATIVE DES SOLUTIONS DE
VIRTUALISATION
A. SOLUTIONS DE VIRTUALISATION
B. TABLEAU COMPARATIF DES SOLUTIONS DE VIRTUALISATION
C. JUSTIFICATION DU CHOIX DE LA SOLUTION
IV. CHAPITRE IV : MISE EN PLACE DE LA SOLUTION
A. VOCABULAIRE
B. LES BESOINS MATERIELS
C. ARCHITECTURE DE PROXMOX-VE POUR LA MISE EN PRATIQUE :
D. DEPLOIEMENT
E. TESTS ET UTILISATION
CONCLUSION

2020-2021 IV BAYE OUSSEYNOU & SAIDOU MBODJI
DEDICACES
Avec humilité, nous dédions ce modeste travail à
nos vaillants parents pour tout leur amour, leur
soutien et leur engagement sans faille. Cette
dédicace ne saurait être à la hauteur de leurs
sacrifices pour nous.
A tous les membres de nos adorables familles, ce
projet vous est également dédié. Votre assistance
et votre soutien nous ont alimentés tout le long
de notre parcours.
Par cette dédicace, trouvez la marque d’estime,
l’amour et le respect que nous vous témoignons.
Puisse notre Seigneur vous accorder Son soutien
tel que vous nous l’avez accordé.

2020-2021 V BAYE OUSSEYNOU & SAIDOU MBODJI
REMERCIEMENTS
Nous rendons grâce au Tout Puissant de nous avoir donné l’opportunité de réaliser ce
modeste projet.
Nous témoignons toute notre gratitude à Madame le Recteur de L’UIDT-THIES Professeur
Ramatoulaye Diagne MBENGUE, au Directeur de l’UFR-SET ainsi qu’à tout le personnel du
Département Informatique de l’UFR-SET pour nous avoir livré cette formation de haute
facture.
Nos chaleureux remerciements à notre encadreur Docteur Moussa Déthié SARR qui a mis à
notre disposition les ressources informatiques nécessaires pour le volet déploiement sans
compter ses efforts acharnés et son dévouement remarquable tout au long de ce travail.
Nous lui témoignons toute notre gratitude et notre reconnaissance ainsi qu’à l’ensemble des
Professeurs pour leur générosité en qualité d’enseignement et d’encadrement.
Sans oublier nos camarades de promotion, nous les remercions pour les moments de partage,
de communion et d’entraide.
Nous remercions ainsi toute personne qui, de près ou de loin, a contribué à la réussite de ce
travail.

2020-2021 VI BAYE OUSSEYNOU & SAIDOU MBODJI
LISTE DES FIGURES
Figure 1: ARCHITECTURE UIDT-THIES...................................................................................................... 3
Figure 2: Isolation.................................................................................................................................... 6
Figure 3: Paravirtualisation ..................................................................................................................... 7
Figure 4: Virtualisation complète............................................................................................................ 8
Figure 5: Hyperviseur de type 1 .............................................................................................................. 9
Figure 6: Hyperviseur de type 2 ............................................................................................................ 10
Figure 7: Logo xen ................................................................................................................................. 15
Figure 8: Architecture Xen..................................................................................................................... 16
Figure 9: Logo VMware ......................................................................................................................... 18
Figure 10: Architecture VMware VSphere ............................................................................................ 19
Figure 11: Logo Hyper-V........................................................................................................................ 20
Figure 12: Architecture Hyper V............................................................................................................ 21
Figure 13: Logo Proxmox....................................................................................................................... 22
Figure 14: Architecture de Proxmox ..................................................................................................... 23
Figure 15: Architecture de topologie réseau......................................................................................... 28
Figure 16: Installation Proxmox............................................................................................................. 29
Figure 17: Attribution d'adresse au PVE1.............................................................................................. 29
Figure 18: PVE2 Information ................................................................................................................. 30
Figure 19: Interface de Connexion au Proxmox VE............................................................................... 32
Figure 20: Démarrage de la Machine Virtuelle ..................................................................................... 32
Figure 21: Démarrage de la Console ..................................................................................................... 33
Figure 22: Instance wordpress démarré en mode CLI........................................................................... 33
Figure 23: Instance wordpress démarré en mode GUI ......................................................................... 34
Figure 24: Page de connexion admin de l’instance Wordpress ............................................................ 34
Figure 25: Les stockages disponibles..................................................................................................... XII
Figure 26: Upload des ISO ..................................................................................................................... XII
Figure 27: Boite de Dialogue pour upload............................................................................................ XIII
Figure 28: Images Iso Debian 10 .......................................................................................................... XIII
Figure 29: Création puis Lancement du VM......................................................................................... XIII
Figure 30: Création snapshot: ..............................................................................................................XIV
Figure 31: Représentations des snapshots...........................................................................................XIV
Figure 32: Cloner un VM........................................................................................................................XV
Figure 33: Migration à froid...................................................................................................................XV
Figure 34: Migration en mode redémarrage.........................................................................................XV
Figure 35: Migration à chaud ...............................................................................................................XVI
Figure 36: Sortie Migration ..................................................................................................................XVI
Figure 37: Transformation d’une VM en Template..............................................................................XVI
Figure 38: Ajout d'un Template...........................................................................................................XVII
Figure 39: Création d’un Conteneur...................................................................................................XVIII
Figure 40: Partage NFS sur le NAS1....................................................................................................XVIII
Figure 41: Partage NFS sur le NAS2...................................................................................................... XIX
Figure 42: Sauvegarde des VMs ........................................................................................................... XIX

2020-2021 VII BAYE OUSSEYNOU & SAIDOU MBODJI
Figure 43: Création Cluster.................................................................................................................... XX
Figure 44: Ajout du noeud au Cluster.................................................................................................... XX
Figure 45: Gestion de la HA.................................................................................................................. XXI
Figure 46: Vue globale de la HA ........................................................................................................... XXI
Figure 47: Interface de connexion TrueNas ....................................................................................... XXII
Figure 48: TrueNas Dashboard............................................................................................................ XXII
Figure 49: Céeation pool .................................................................................................................... XXIII
Figure 50: RAID-NAS1......................................................................................................................... XXIII
Figure 51: RAID-NAS1 Créé.................................................................................................................XXIV
Figure 52: Vue Globale d’un pool.......................................................................................................XXIV
Figure 53: Ajout d'un Dataset..............................................................................................................XXV
Figure 54: Création d'un Dataset.........................................................................................................XXV
Figure 55: Editer les Permissions........................................................................................................XXVI
Figure 56: Ajout Du Partages NFS.......................................................................................................XXVI
Figure 57: NFS Permissions ...............................................................................................................XXVII
Figure 58: NFS Services......................................................................................................................XXVII
Figure 59: RSYNC Service...................................................................................................................XXVII
Figure 60: Ajout du Module Rsync ...................................................................................................XXVIII
Figure 61: Rsync Mode Pull (Server) ................................................................................................XXVIII
Figure 62:RSYNC mode Push (Client) ................................................................................................. XXIX
Figure 63: Task Rysnc Start................................................................................................................. XXIX

2020-2021 VIII BAYE OUSSEYNOU & SAIDOU MBODJI
LISTE DES TABLEAUX
Tableau 1: Comparaison des solutions de virtualisation....................................................................... 25
Tableau 2: Expression de besoins.......................................................................................................... 28

2020-2021 IX BAYE OUSSEYNOU & SAIDOU MBODJI
SIGLES ET ABREVIATIONS
UIDT Université Iba Der Thiam
UFR Unité de Formation et de Recherche
SET Sciences Et Technologies
SES Sciences Economiques et Sociales
SI Sciences de l’Ingénieur
ENSA Ecole Nationale Supérieure d’Agriculture
IUT Institut Universitaire de Technologie
HA High Availability (Haute Disponibilité)
IT Information Technology
TP Travaux Pratiques
IBM International Business Machine
MIT Massachusetts Institute of Technology
CP/CMS Control Program/Cambridge Monitor System
VM/CMS Virtual Machine/Conversational Monitor System
OS Operating System (Système d’Exploitation)
PC Personal Computer
NES Nintendo Entertainment System
SNES Super Nintendo Entertainment System
AES Advanced Entertainment System
KVM Kernel Virtual Machine
QEMU Quick EMUlator
CPU Central Process Unit
AMD Advanced Micro Devices
ESX Elastic Sky X
ESXi ESX integrated
HVD Hosted Virtual Desktop
VDl Virtual Desktop Infrastructure
SDN Software-Defined Network
NFV Network Function Virtualization
NSX NameSpace eXtension
ACI Access Control Information
WAN Wide Area Network
VNF Virtualized Network Functions
SCSI Small Computer System Interface
iSCSI Internet Small Computer System Interface
NFS Network File System
CIFS Common Internet File System
VDS Virtual Dedicated Server
API Application Programming Interface
XAPI eXperience API
E/S Entrée/Sortie
RBAC Role-Based Access Control
GUI Graphic User Interface
CLI Command Line Interface
DRS Distributed Ressources Scheduler

2020-2021 X BAYE OUSSEYNOU & SAIDOU MBODJI
VSB VMware Consolidate Backup
VSP Virtualization Service Provider
VSC Virtualization Service Client
VMBus (Microsoft) Virtual Machine Bus
WMI Windows Management Instrument
VMMS Virtual Machine Management Service
KVM Kernel Virtual Machine
GmbH Abréviation allemande qui signifie Limited Liability Company
LXC LinuX Containers
BSD Berkeley Software Distribution
PVE Proxmox Virtual Environment
VE Virtual Environment
AGPL (GNU) Affero General Public License
GNU Gnu is Not Unix
VLAN Virtual Local Area Network
LVM Logical Volume Manager
RAM Random Access Memory
VHD Virtual Hard Disk
To Tera octet
SAN Storage Area Network
NAS Network Attached Stotrage
RAID Redundant Array Independant Disk
PRA Plan de Reprise d’Activité
PCA Plan de Continuité d’Activité

2020-2021 XI BAYE OUSSEYNOU & SAIDOU MBODJI
AVANT PROPOS
L’Université Iba Der Thiam de Thiès (UIDT-Thiès), plus particulièrement l’Unité de Formation et de
Recherche des Sciences et Technologies (UFR-SET), s’est donnée comme sacerdoce répondre aux
objectifs de professionnalisation des différents domaines tels que l’Informatique, les Mathématiques,
l’Hydraulique, etc.
Dans cette même optique, le Département Informatique développe des activités de transfert de
technologies, de valorisation des connaissances issues de la recherche, d’appui à l’innovation et à la
création d’entreprises, de diffusion de la culture informatique.
Dans le cadre d’une formation basée sur le système LMD, chaque étudiant/étudiante dudit
département est tenu, à la fin de son cycle de Licence, de choisir un sujet de mémoire sur lequel il/elle
fera une étude large et approfondie voire même une mise en pratique si nécessaire grâce à aux
compétences acquises et aux recherches en vue de sanctionner la formation des trois années de
Licence.
Ayant déjà fait une étude et mise en place du Cloud Privé Interne à l’ISEP-Thiès l’année précédente,
nous avons décidé de suivre cette logique en s’orientant, cette année, vers la mise en place d’une
Infrastructure Hautement Disponible avec la solution de virtualisation Proxmox-VE.

2020-2021 1 BAYE OUSSEYNOU & SAIDOU MBODJI
INTRODUCTION GENERALE
Depuis plusieurs années, le terme HA (High Availability) ou HD (Haute Disponibilité) en français est un
concept qui prend de plus en plus de l’ampleur dans le jargon informatique. Même si beaucoup
utilisent cette appellation dans le cadre pédagogique sans même bien maîtriser le concept, les
entreprises, elles, ont bien compris l’importance et même la nécessité d’assurer une haute
disponibilité de leur infrastructure.
De surcroît, le souci de sous-utilisation et de surutilisation des ressources informatiques mènent les
sociétés vers l’adoption d’environnement virtuels à des fins aussi diverses qu’intéressantes. La jonction
du concept HA et de la technologie de Virtualisation, autrement dit un environnement virtuel
hautement disponible, permet aux administrateurs IT une meilleure gestion de leurs ressources et de
mieux satisfaire les utilisateurs.
La virtualisation a révolutionné le domaine de l’IT en permettant aux entreprises de ne plus avoir
besoin de lourds investissements dans les ressources (physiques) encore moins une gestion onéreuse
de cesdites ressources. Par ailleurs, elles, ces entreprises, auront la possibilité de disposer des
ressources logicielles suffisantes dont elles ont besoin en faisant fonctionner des environnements
virtuels sur des machines physiques.
Quant à la haute disponibilité, elle permettra de mettre en place des actions et des paramètres
techniques, pour qu’une infrastructure informatique soit toujours en mesure de répondre à la requête
d’un utilisateur. Cela est possible en appliquant certaines règles, comme la sauvegarde, la répartition
de la charge, la réplication des données, la redondance, etc., pour restreindre l’indisponibilité d’un
système d’information. Au vu de telles offres et possibilités, un environnement virtuel HA se présente
comme une option prometteuse pour l’éradication d’une bonne vague de problèmes jadis sans
solution rencontrée dans les systèmes d’information.
Dans l’optique d’un bon déroulement des travaux pratiques, les étudiants du département
informatique se verraient être avantagés par l’utilisation des ressources des machines virtuelles
(puissance de calcul, stockage, etc.) que nous proposons dans l’environnement virtuel hautement
disponible.
Dans ce rapport, nous traiterons essentiellement quatre chapitres. Dans le premier chapitre intitulé «
Cadre général du projet » nous présenterons l’organisme d’accueil et l’étude de l’existant. Ensuite nous
étudierons la virtualisation dans le deuxième chapitre. Dans la troisième partie, nous ferons une étude

comparative des solutions de virtualisation et justifierons le choix de Proxmox. Enfin dans le quatrième
et dernier chapitre, nous allons faire une implémentation de la solution virtualisation « Proxmox » suivi
d’un test d’utilisation. Pour terminer, nous rappellerons dans la Conclusion le cadre de ce projet et la
méthode choisie pour sa réalisation. Des perspectives seront énoncées pour faire l’objet de futurs
projets d’étude.
I. CHAPITRE I : CADRE GENERAL DU PROJET
A. PRESENTATION DE L’ORGANISME D’ACCUEIL : UIDT-Thiès
L’Université Iba Der Thiam de Thiès est un établissement public d’enseignement supérieur ayant une
forte orientation professionnelle avec six (06) établissements répartis en :
4 Unités de Formation et de Recherche
• UFR Sciences Economiques et Sociales (UFR SES)
• UFR Sciences Et Technologie (UFR SET)
• UFR Sciences de la Santé (UFR Santé)
• UFR Sciences de l’Ingénieur (UFR SI)
Une (01) Ecole supérieure
• L’Ecole Nationale Supérieure d’Agriculture (ENSA)
Un (01) Institut
• L’Institut Universitaire de Technologie (IUT).
L’Université de Thiès est structurée en 4 pôles de formation et de recherche :
Pôle technologique
• UFR SI
• UFR SET
• IUT
Pôle agronomique
• ENSA
Pôle santé
• UFR Santé
Pôle économique et social
• UFR SES
Source : https://www.univ-thies.sn/index.php/presentation
Ci-dessous, un schéma qui illustre l’infrastructure du réseau de l’UIDT de Thiès en 2022.

Figure 1: ARCHITECTURE UIDT-THIES
B. ETUDE ET CRITIQUE DE L’EXISTANT
Dans l’infrastructure informatique de l’UIDT, une plateforme de formation à distance est mise à la
disposition des étudiants et des professeurs pour y déposer des cours et des travaux, y faire des
évaluations etc. Cela aide beaucoup dans le cadre d’un apprentissage à distance.
Dans les locaux de l’UFR des Sciences et technologies, un laboratoire de TP à distance est mis en
place pour diversifier les modalités d’enseignement-apprentissage en milieu universitaire, augmenter
la valeur ajoutée dans le domaine des TP ou le numérique était en vigueur dans les établissements,
en orientant la recherche vers les « e-TP », entre autres.
Tous ces efforts dont le mérite revient à la DSI et aux autorités pédagogiques de l’Université, sont
certes à saluer. Cependant les conditions d’étude des étudiants de l’UFR-SET, particulièrement ceux
du Département Informatique, sont toujours à améliorer. En effet les étudiants du département
informatique n’ont pas tous un ordinateur à leur disposition. Sinon leurs machines ne sont pas toutes

dotées des capacités optimales pour une bonne mise en pratique des connaissances théoriques
acquises.
C. SOLUTION PROPOSEE
Face à cette réalité, nous comptons d’abord étudier la virtualisation et les différentes solutions de
virtualisations. Ensuite nous procéderons au déploiement de la solution de virtualisation qu’on aura
choisie. Ce laboratoire virtuel mettra à la disposition des étudiants des machines virtuelles assez
performantes avec une politique de stockage en réseau hautement disponible pour des TP.
II. CHAPITRE II : VIRTUALISATION
A. HISTORIQUE DE LA VIRTUALISATION
Les années 70 : une bonne part des travaux sur la virtualisation fut développée au centre scientifique
de Cambridge d’IBM en collaboration avec le MIT, où fut mis au point le système expérimental CP/CMS,
devenant ensuite le produit (alors nommé Hyperviseur) VM/CMS. Par la suite, les mainframes
(serveurs IBM) ont été capables de virtualiser leurs systèmes d’exploitation avec des technologies
spécifiques et propriétaires, à la fois logicielles et matérielles. En 1979 fut annoncé par exemple sur les
IBM 4331 et 4341 un accélérateur VM optionnel et microcode.
Les années 80-90 : dans la deuxième moitié des années 1980 et au début des années 1990, on a créé
des embryons de virtualisation sur des ordinateurs personnels. Ces solutions pouvaient être soit
purement logicielles, soit couplées à du matériel additionnel (ajout de processeur, carte réseau, etc.).
Et c’est sur des ordinateurs Amiga équipé de processeur hétérogène comme le 80386 et 80486, 68xxx,
et PPC qu’il était possible de lancer d’autres OS comme un Windows, Mac OS, voire des solutions Linux.
Le tout en multitâche sous AmigaOS. Pour les PC, il y avait des émulateurs comme le SideCar et PC
Task. Sur Macintosh, Emplant et ShapeShifter.
Fin des années 90, début 2000 : dans la seconde moitié des années 1990, les émulateurs sur x86 des
vieilles machines des années 1980 ont connu un énorme succès, notamment les ordinateurs Atari,
Amiga, Amstrad et les consoles NES, SNES, Neo-Geo AES.
La société VMware développa et popularisa à la fin des années 1990 et au début des années 2000 un
système propriétaire de virtualisation logicielle des architectures de type x86 pour les architectures de
type x86. Les logiciels libres Xen, KVM, QEMU, Bochs, Linux-VServer, Virtual Box et les logiciels
propriétaires mais gratuits VirtualPC, Virtual Server et VMware Server ont achevé la popularisation de
la virtualisation dans le monde x86.

B. NOTION DE VIRTUALISATION
La virtualisation permet de faire fonctionner simultanément plusieurs OS (Windows, Linux, Mac OS,
etc.) sur une seule et même machine physique. Dans l’idée, il faut s’imaginer plusieurs VM (Windows
10, ou un serveur Windows 2016 par exemple) sur une seule machine physique, les VM se partagent
alors les ressources matérielles du serveur physique.
La virtualisation respecte deux principes fondamentaux qui sont le cloisonnement et la transparence.
Le cloisonnement : chaque système d’exploitation a un fonctionnement indépendant, et ne peut
interférer avec les autres en aucune manière.
La transparence : le fait de fonctionner en mode virtualisé ne change rien au fonctionnement du
système d’exploitation et des applications.
On distingue trois grands types de solutions de virtualisation qui sont l’isolateur, la paravirtualisation
et la virtualisation complète.
C. LES TYPES DE SOLUTIONS DE VIRTUALISATION
1. L’ISOLATION :
L'isolation (aussi appelé cloisonnement) est une technique qui intervient au sein d’un même système
d'exploitation.
Elle permet de séparer un système en plusieurs contextes ou environnements. Chacun d'entre eux est
régi par l'OS hôte, mais les programmes de chaque contexte ne sont capables de communiquer qu'avec
les processus et les ressources associées à leur propre contexte. Il est ainsi possible de partitionner un
serveur en plusieurs dizaines de contextes, presque sans ralentissement.
L'isolation est utilisée sous Unix pour protéger les systèmes. Via des mécanismes comme chroot ou jail
il est possible d'exécuter des applications dans un environnement qui n'est pas celui du système hôte,
mais un mini système ne contenant que ce dont l'application a besoin, et n’ayant que des accès limités
aux ressources. Il est possible également de lancer des programmes dans une autre distribution que
celle du système principal.
Avec l’isolation, l’espace noyau n’est pas différencié, il est unique, partagé entre les différents
contextes. Mais on définit de multiples espaces utilisateurs cloisonnés. C’est ainsi que l’on peut faire
cohabiter différentes distributions de système d’exploitation, à condition qu’elles partagent
le même noyau.

L’isolation des contextes est une solution légère, tout particulièrement dans les environnements Linux.
Mais pour les besoins les plus courants de la virtualisation, la simplicité de mise en oeuvre et le faible
overhead sont d’excellents arguments.
La principale solution pour l’isolation est Linux-VServer, la plus mature et la plus avancée. OpenVZ est
une alternative, qui se présente de la même façon et propose quasiment les mêmes fonctionnalités.
Elle est à la base du produit commercial Virtuozzo.
Figure 2: Isolation
2. LA PARAVIRTUALISATION :
La paravirtualisation et la virtualisation complète sont assez proches. Elles s’appuient sur une couche
hyperviseur, qui gère totalement l’interface avec les ressources matérielles, et sur laquelle on peut
installer différents systèmes d’exploitation.
La paravirtualisation présente au système d’exploitation une machine générique spéciale, qui requiert
donc des interfaces spéciales intégrées aux systèmes invités, sous la forme de drivers.
La paravirtualisation est une technique de virtualisation de plus bas niveau que l'isolation. Elle partage
avec cette dernière la nécessité d'utiliser un OS modifié. Plus précisément, en paravirtualisation ce
n'est plus seulement l'OS hôte qui doit être modifié mais également les OS appelés à s'exécuter sur les
environnements virtuels.
Le cœur de la paravirtualisation est un hyperviseur fonctionnant au plus près du matériel, et
fournissant une interface qui permet à plusieurs systèmes hôtes d'accéder de manière concurrente
aux ressources.

Chaque système virtuel doit être modifié de façon à utiliser cette interface pour accéder au matériel.
Contrairement à l'isolation, plusieurs OS de familles différentes peuvent fonctionner sur un même
serveur physique. Il est ainsi possible de faire fonctionner Linux, NetWare, Solaris (et d'autres)
simultanément sur une même machine.
Chaque OS aura alors accès à ses propres périphériques de stockage, sa propre mémoire, sa ou ses
propres interfaces réseau, son ou ses propres processeurs, chaque ressource matérielle virtualisée
étant partagée avec les autres environnements.
La nécessité de petites modifications au système d’exploitation invité exclut le support de systèmes
fermés, et en particulier de Microsoft Windows.
Figure 3: Paravirtualisation
3. LA VIRTUALISATION COMPLETE :
La virtualisation complète, c’est un système d’exploitation qui exécute un logiciel nommé hyperviseur.
L’hyperviseur va permettre l’exécution de plusieurs machines virtuelles sur la machine physique. Il
gère les accès mémoire, l’allocation du CPU et toutes les ressources nécessaires aux machines
virtuelles.
Dans la virtualisation complète, l’hyperviseur gère l’ensemble des requêtes des machines virtuelles ce
qui permet aux machines virtuelles de fonctionner sans aucune modification de leur noyau.
Autrement dit, les machines virtuelles ne savent pas qu’elles s’exécutent de manière virtuelle.
Le produit le plus connu est VMware Infrastructure. Au boot de la machine, un linux se lance pour
d’une part charger la console d’administration de la machine et d’autre part l’OS dédié à l’hyperviseur.

VMware propose également VMware Server tournant soit sous Windows soit sous Linux.
Microsoft propose Virtual Server tournant sous Windows 2003 Server et bientôt Hyper-V intégré à
serveur Windows 2008.
Figure 4: Virtualisation complète
D. LES HYPERVISEURS
1. Les hyperviseurs de type 1
Par abus de langage, lorsque l'on parle d'hyperviseur on parle généralement de ce type d'hyperviseur.
Un hyperviseur de Type 1, ou natif, voire "bare metal" (littéralement "métal nu"), est un logiciel qui
s’exécute directement sur une plateforme matérielle ; cette plateforme est alors considérée comme
outil de contrôle de système d’exploitation. Un système d’exploitation secondaire peut, de ce fait, être
exécuté au-dessus du matériel. L’hyperviseur type 1 est un noyau hôte allégé et optimisé pour ne faire
tourner initialement que des noyaux de systèmes d’exploitation invités adaptés et optimisés à cette
architecture spéciﬁque, ces systèmes invités ayant "conscience" d’être virtualisés. Sur des processeurs
ayant les instructions de virtualisation matérielle (AMD-V et Intel VT), le système d’exploitation invité
n’a plus besoin d’être modiﬁé pour pouvoir être exécuté dans un hyperviseur de type 1. Quelques
exemples de tels hyperviseurs plus récents sont Xen, Oracle VM, ESX Server de VMware.

Figure 5: Hyperviseur de type 1
Avantages : Un maximum de ressources peut être alloué aux machines virtuelles car ce type
d'hyperviseur est directement lié à la couche matérielle.
Inconvénients : Il n'est possible d'exécuter qu'un seul hyperviseur à la fois. Cette
problématique n'est toutefois pas vraiment impactante puisque dans la grande majorité des
cas, un seul et même hyperviseur est capable de gérer tous les applicatifs d'une entreprise.
Usage de ce type d'hyperviseur : Les hyperviseurs de type 1 peuvent être utilisés pour
virtualiser des serveurs de fichiers, de bases de données, de messageries, etc... Ce type
d'hyperviseur est à privilégier lorsque l'on souhaite exécuter des applicatifs en continu. La
quasi-totalité des serveurs peut être virtualisée via un hyperviseur de type 1.
Compatibilité avec les serveurs : Un hyperviseur devra être compatible à deux niveaux :
✓ Compatibilité avec le matériel sur lequel il s'exécute (constructeurs et
composants) ;
✓ Compatibilité avec les OS qui sont supportés dans les VM.
Afin d'assurer la stabilité du système, il est indispensable de valider cette double
compatibilité.
Bien que les hyperviseurs de type 1 soient le plus souvent utilisés sur des serveurs, ils
permettent également de virtualiser des postes de travail.
Exemple : une entreprise souhaitant centraliser ses postes de travail en les virtualisant pour
répondre à des problématiques de coûts et de gestion, pourra s'appuyer sur un hyperviseur de
type 1. L'accès aux postes de travail virtuels se fera alors généralement via des clients légers
(substantiellement moins onéreux que des PC physiques).
2. Les hyperviseurs de type 2
Un hyperviseur de Type 2 est un logiciel qui s’exécute à l’intérieur d’un autre système d’exploitation.
Un système d’exploitation invité s’exécutera donc en troisième niveau au-dessus du matériel. Les

systèmes d’exploitation invités n’ayant pas conscience d’être virtualisés, ils n’ont pas besoin d’être
adaptés. Quelques exemples de tels hyperviseurs sont VMware Workstation, VMware Fusion,
l’hyperviseur open source QEMU, les produits Microsoft Virtual PC et Virtual Server, VirtualBox
d’Oracle, de même que Parallels Workstation de SWsoft et Parallels Desktop.
Avantages : Il est possible d'exécuter plusieurs hyperviseurs en même temps car ceux-ci ne
s'installent pas directement sur la couche matérielle.
Inconvénients : Ce type d'hyperviseur ne peut pas fournir autant de ressources matérielles
que les hyperviseurs de type 1 puisqu'ils sont installés sur un système d'exploitation, lui-même
consommateur de ressources.
Usage de ce type d'hyperviseur : Les hyperviseurs de type 2 sont utilisés pour virtualiser
des OS sur des PC, la plupart du temps afin de procéder à des tests de compatibilité et/ou de
sécurité.
Il existe également un environnement dans lequel ce type d'hyperviseur est particulièrement
utilisé : pour les utilisateurs Mac OS X ayant besoin d'utiliser Windows (en raison d'applicatifs non
compatibles).
Figure 6: Hyperviseur de type 2
Peut-on mixer les hyperviseurs ?

Concernant les hyperviseurs de type 1 : On constate depuis quelques années que de plus en plus
d'entreprises utilisent deux hyperviseurs d'éditeurs différents. Pour deux raisons principales :
• Trouver une alternative financière
Pour des raisons économiques (prix des nouvelles licences, coût du renouvellement du contrat
de support) les entreprises installent de plus en plus un hyperviseur alternatif moins onéreux.
• Réduire les coûts de licence pour des applicatifs ayant des problématiques de support
Certains applicatifs, c'est le cas d'Oracle, incitent à l'utilisation de leur hyperviseur, de leur système
d'exploitation, voir même de leur hardware. Une entreprise avec une ferme de 100 serveurs VMware
pourra très bien décider d'installer une ferme de 5 ou 6 serveurs sous l'hyperviseur d'Oracle
uniquement pour faire tourner les applicatifs idoines.
Concernant les hyperviseurs de type 2 :
Dans le cadre de développements logiciels, il arrive très souvent de devoir tester des applicatifs sur
différentes plateformes. On pourra alors utiliser des hyperviseurs différents.
E. CATEGORIES DE VIRTUALISATION
Les catégories de virtualisation sont nombreuses. Toutefois, la grande famille de la virtualisation
regroupe celles qui sont le plus utilisées. Nous pouvons en citer tels que la virtualisation des serveurs,
la virtualisation de stockage, la virtualisation des postes de travail.
1. VIRTUALISATION DE SERVEURS
Le principe de base de la virtualisation de serveurs consiste à mettre en place sur une seule machine
physique plusieurs systèmes d’exploitation qui fonctionnement en même temps. La plate-forme
physique fonctionne toujours sous un seul système d’exploitation Windows ou Linux par exemple, mais
ce système permet l’accueil d’autres systèmes d’exploitation en mettant en place sur ce système
d’exploitation hôte un ou plusieurs environnements (machines virtuelles) pour faire fonctionner
d’autres systèmes d’exploitation.
On peut se demander à juste titre pourquoi utiliser une seule machine physique pour en simuler
plusieurs, puisque nous utilisons, dans une conception traditionnelle, un seul matériel pour un seul
système d'exploitation. De plus, le fait d'utiliser de la virtualisation sur un même serveur physique ne
va-t-il pas le pousser dans ses derniers retranchements en consommant toutes ses ressources ? Mais
dans un premier temps, parlons des faits : il s'est avéré que dans bon nombre d'entreprises, il est

fréquent de trouver des serveurs utilisés en moyenne à 15% de leur capacité, même si la puissance en
réserve est nécessaire en cas de charge irrégulière… Les conséquences pour une entreprise sont un
investissement coûteux, et une maintenance assez lourde, tout cela pour des performances loin d'être
optimales. De plus, on peut également constater qu'un serveur tournant à 15 % de ses capacités n'est
pas moins gourmand en énergie qu'un serveur utilisant tout son potentiel. Ainsi, il ne paraît pas
aberrant de vouloir regrouper plusieurs machines sur un seul serveur physique, si l'on est sûr que les
pics de charge de chaque serveur ne soient pas synchrones, bien que la virtualisation en elle-même
constitue une partie des charges.
2. VIRTUALISATION DES POSTES DE TRAVAIL
Le principe de la virtualisation du poste de travail consiste à afficher sur un, des dizaines, centaines
voire des milliers de postes physiques, une image virtuelle du poste utilisateur qui est en fait
réellement exécutée sur un serveur distant. Derrière ce principe, on trouve cependant plusieurs
formes de virtualisation du poste de travail.
• La virtualisation d'applications centralisée (également dénommée Server-Based-Computing),
consistant à virtualiser les applications mais pas l'ensemble du système d'exploitation. Alors
que l'utilisateur visualise (et utilise) sur son poste une image des applications réellement
exécutées sur un serveur distant, le système d'exploitation, lui, tourne toujours sur le poste
client. Une variante existe qui est celle de la virtualisation d'applications par isolation.
• La virtualisation du poste de travail peut également s'apparenter à du streaming de système
d'exploitation. Dans cette configuration, le système cible démarre à partir d'un disque installé
sur le réseau et charge de façon sélective les contenus et applications souhaitées par
l'utilisateur depuis des volumes logiques installés sur un serveur ou un espace de stockage
distant.
• Enfin, la dernière forme que revêt la virtualisation du poste de travail. Il s'agit de l'architecture
VDI pour Virtual Desktop Initiative, également dénommée Hosted Virtual Desktop (HVD). Cette
dernière peut s'apparenter à la virtualisation "totale" du poste de travail, c'est-à-dire tant aux
applications qu'au système d'exploitation, permettant de s'affranchir de la nature même du
poste client sur lequel sera affiché l'image.
La virtualisation du poste de travail est également la plus complète et celles dont les perspectives de
déploiement sont les plus importantes. Ainsi avant de déployer une infrastructure VDI, il convient de
déterminer sur quels clients physiques seront utilisés les postes de travail virtuels. Et pour cela, le choix
ne manque pas : clients lourds, clients légers, zéros clients, entre autres.

 Clients lourds : Il est possible d’utiliser des clients lourds pour la virtualisation du poste de
travail. Mais de nombreuses organisations s’en abstiennent parce que cela ne permet pas de
réduire les dépenses de matériel et nécessite une installation locale de logiciels. L’utilisation
de PC traditionnels pour accéder à des postes de travail virtuels ne permet pas de retirer tous
les bénéfices du VDI, tels qu’une consommation d’électricité réduite, une administration
pleinement centralisée et une sécurité renforcée.
 Clients légers : les postes de travail virtuels sont hébergés au sein du centre de calcul et le
client léger sert simplement de terminal d’accès au serveur. Les clients légers sont
généralement faciles à installer, simplifient l’accès aux applications, améliorent la sécurité, et
réduisent les besoins en matériels en permettant aux administrateurs de redéployer les
anciens PC.
 Zéros Clients : Les zéros clients gagnent en popularité sur le marché du VDI parce qu’ils sont
encore plus amincis et plus économiques que les clients légers. Ils ne nécessitent aucune
configuration et ne stockent aucune donnée. Ils sont notamment fabriqués par Dell Wyse,
Fujitsu, HP et Pano Logic.
 Les autres voies du VDI : Mais il existe d’autres options pour les postes clients d’une
infrastructure VDI. A l’heure de la mobilité, certains commencent à utiliser ainsi leurs
smartphones ou leurs tablettes.
3. VIRTUALISATION DE RESEAUX
La virtualisation du réseau consiste à combiner des ressources réseau matérielles et logicielles
dans une seule unité administrative. L'objectif de la virtualisation du réseau est de fournir aux
systèmes et utilisateurs un partage efficace, contrôlé et sécurisé des ressources réseaux.
On distingue des types de réseaux virtuels faciles à confondre (SDN, NFV).
❖ SDN (Software Defined Network ou Réseau Défini par Logiciel) :
Un réseau défini par logiciel consiste à séparer la couche de gestion des flux de la couche de
données qui transmet le trafic réseau, l'objectif de cette dissociation étant de créer un réseau
centralisé et programmable. Certaines implémentations SDN utilisent une plate-forme de gestion
basée sur un logiciel pour contrôler des matériels réseaux standards comme Big Switch Networks
ou Vmware NSX. D'autres solutions sont basées sur une approche matérielle et logicielle intégrée
(Cisco ACI). Cette technologie est essentiellement utilisée dans les datacenters d'entreprise pour
les clients qui veulent des solutions réseaux plus flexibles que ce que permettent les architectures

réseaux traditionnelles. Le SDN peut également se décliner en sous-catégories, comme le réseau
étendu WAN (Wide Area Network) défini par logiciel. Enfin, le SDN peut également servir à
segmenter le trafic pour accroître la sécurité.
❖ NFV : (Network Function Virtualization ou virtualisation des fonctions réseaux) :
A l’origine, la virtualisation des fonctions réseaux a été conçue par un consortium de fournisseurs de
télécommunications qui voulaient contrôler plus facilement leur offre de services réseaux aux clients.
Le principe fondamental du NFV consiste à virtualiser les services réseaux pour se débarrasser des
matériels dédiés. Généralement, les déploiements NFV utilisent des serveurs standards pour faire
tourner des logiciels de services réseaux anciennement basés sur le matériel. Ces services basés sur le
logiciel portent le nom de services de virtualisation des fonctions réseaux ou Virtual Network Functions
(VNF). Ils fonctionnent dans un environnement NFV. Ces services VNF incluent le routage, les fonctions
pare-feu, l'équilibrage de charge, l'accélération WAN et le cryptage. En virtualisant ces services
réseaux, les fournisseurs peuvent offrir aux clients des services dynamiques à la demande.
4. VIRTUALISATION DE STOCKAGES
La virtualisation de stockages consiste à masquer la disparité des ressources de stockage, et à les
présenter comme un volume logique homogène. Cette couche d'abstraction intermédiaire agit comme
un courtier (broker) de capacité : elle fournit de l'espace de stockage aux applications, fait cohabiter
des environnements hétérogènes dans une même représentation, permet l'adjonction de capacité à
la volée, et laisse l'administrateur appliquer une politique unifiée de gestion des données.
La couche de virtualisation exploite des technologies de mapping de ressources physiques sur une
représentation logique intermédiaire. Elle intègre les méthodes propres à l'administration du stockage
(mirroring, restauration, sauvegarde, snapshot, réplication...), ainsi que des traducteurs pour les
protocoles et les environnements (FC, SCSI, iSCSI, Hippi, Escon, Fips, NFS, CIFS...). Au moins six
technologies cohabitent aujourd'hui : baies de virtualisation, logiciels hôtes de masquage d'unités
logiques, métacontrôleurs de redirection de données, serveurs de virtualisation dédiés, serveurs de
domaines de stockage, commutateurs de virtualisation.
Il existe deux types de virtualisation du stockage. Tout d’abord, il y a la virtualisation symétrique qui
utilise le client, le stockage et le serveur de virtualisation du stockage. Ici, les données du client sont
envoyées sur le serveur qui s’occupe de les transmettre au stockage. Le second type de virtualisation
du stockage est la virtualisation asymétrique. Dans ce cas de figure, la virtualisation est en contact
direct avec le stockage.

F. DOMAINES D’APPLICATION
La virtualisation permet de mettre en place des serveurs virtuels dédiés (VDS) afin d’offrir un
hébergement permettant le partage de ressource, l’autonomie et le contrôle totale du serveur
contrairement aux offres traditionnelles qui sont l’hébergement dédié (serveur à disposition
configurés selon les besoins) et l’hébergement mutualisé (le même serveur sert pour plusieurs clients,
pas de contrôle de ressource, pouvoir limiter). La virtualisation intervient aussi pour améliorer la
disponibilité des serveurs ou des services. On parle de répartition de charge et de reprise automatique.
La virtualisation a permis de démocratiser les Appliance. Les Appliance se sont des boîtiers (routeurs,
pare-feu, solutions sécurités…) prêts à l’emploi qui nécessitent peu de configuration. Ces solutions
allègent le travail des administrateurs. La virtualisation complète permet d’alléger les coûts (matériels
et d’exploitations) pour les développements et les tests. Sur une seule machine physique, on peut
installer plusieurs systèmes d’exploitation afin de tester les différents scénarii.
III. CHAPITRE III : ETUDE COMPARATIVE DES SOLUTIONS DE
VIRTUALISATION
A. SOLUTIONS DE VIRTUALISATION
1. XEN
Créé par des chercheurs de l'Université de Cambridge, Xen est un hyperviseur de type 1 qui fonctionne
dans le mode du processeur le plus privilégié (c’est-à-dire l’anneau 0). Il peut fonctionner à la fois en
mode de paravirtualisation et de virtualisation assistée par matériel. Xen appartient à Citrix.
Néanmoins, une version non payante est toujours disponible en tant que projet Xen (Xen Project).
Figure 7: Logo xen

a. Les composants de la virtualisation Xen :
Les composants clé de la virtualisation Xen sont les suivants :
• L’hyperviseur Xen : est l’hyperviseur de type 1, open-source ;
• Le domaine de contrôle : également appelé domaine 0, ou dom0, est une machine virtuelle
Linux sécurisée et privilégiée qui exécute les outils de gestion de l’hyperviseur Xen connue
sous le nom de XAPI. Cette machine virtuelle Linux est basée sur une distribution
CentOS.Dom0 exécute également les pilotes de périphériques physiques pour la mise en
réseau, le stockage, etc. Le domaine de contrôle peut parler à l'hyperviseur pour lui demander
de démarrer ou d'arrêter les machines virtuelles invitées.
• La pile d'outils, ou XAPI : est la pile logicielle qui contrôle les opérations du cycle de vie, la
mise en réseau des hôtes et des VMs, le stockage des VMs et l'authentification des utilisateurs.
Il permet également la gestion des pools de ressources de l’hyperviseur Xen.
• Les domaines invités : sont des machines virtuelles créées par les utilisateurs qui demandent
des ressources à dom0.
• Les outils VM : fournissent des services d'E/S de haute performance sans le surcroît de travail
que représente l'émulation traditionnelle de périphériques.
Figure 8: Architecture Xen
b. Les fonctionnalités de XenServer :
Ses fonctionnalités sont entre autres :

• Récupération de site : Conçu pour permettre aux utilisateurs de récupérer les VMs et/ou les
applications virtuelles en cas de défaillance matérielle catastrophique des couches calcul,
stockage et/ou réseau. Cette fonctionnalité n’est pas intégrée à la version gratuite.
• Protection contre les pannes d'hôte : la haute disponibilité permet la récupération des VMs
et/ou des applications virtuelles en cas de panne matérielle de l'infrastructure. Cette
fonctionnalité n’est pas aussi incluse dans la version gratuite de XenServer.
• Gestion multi-serveurs : elle est faite à travers l'interface graphique XenCenter qui est une
interface basée sur Windows. Elle permet la gestion des hôtes et des pools de ressources
(collections d'hôtes) d'une manière simple et évolutive.
• Contrôle dynamique de la mémoire : ajuste automatiquement la quantité de mémoire
disponible pour être utilisée par le système d'exploitation d'une VM invitée. Elle n’est pas
incluse dans la version gratuite.
• Intégration Active Directory : permet aux utilisateurs de se connecter à un groupe d'hôtes
XenServer en utilisant leurs identifiants de domaine Windows. Elle n’est pas incluse dans la
version gratuite non plus.
• Administration et contrôle basés sur les rôles (RBAC) : permet d'attribuer des utilisateurs,
des rôles et des autorisations pour contrôler qui a accès aux hôtes XenServer. Cette
fonctionnalité n’existe que dans les versions payantes.
• Pools de ressources mixtes avec masquage du processeur : Cette fonctionnalité permet
d'ajouter de nouveaux hôtes et de nouvelles versions de CPU aux pools existants, avec la prise
en charge de toutes les fonctionnalités de niveau VM telles que la migration.
• Contrôleur de commutateur virtuel distribué : Il s'agit d'une interface graphique utilisée pour
la configuration et la gestion des infrastructures basées sur Open vSwitch (un commutateur
virtuel).
• Migration et stockage de VM en direct XenMotion.
2. VMware vSphere :
VMware vSphere est un logiciel d’infrastructure de Cloud computing de l’éditeur VMware, c’est un
hyperviseur de type 1 (Bare Metal), basé sur l’architecture VMware ESXi. VMware vSphere nécessite
une conﬁguration matérielle restreinte précisée dans le guide de comptabilité VMware. La gestion de
ce serveur hôte peut se faire via plusieurs possibilités : par le navigateur Web avec une connexion
directe, par une console cliente avec une connexion directe ou par un outil de gestion centralisée
nommé VMware vCenter Server qui permet d’administrer l’ensemble des machines virtuelles, des

hôtes physiques, de leurs ressources et des options de l’environnement (High Availability, vMotion,
Storage vMotion, Distributed Resource Scheduler, Fault Tolerance) depuis une seule console.
Figure 9: Logo VMware
a. Les composants de vSphere
VMware vSphere est une suite logicielle qui comprend des composants tels que ESXi, vCenter
Server, vSphere Client, etc.
• ESXI : est un hyperviseur de type 1. Il abstrait des ressources comme le processeur, la
mémoire, le stockage et la mise en réseau à provisionner sur plusieurs machines virtuelles.
• VCenter Server : une plate-forme de gestion permettant de gérer les machines virtuelles et
les hôtes ESXi de manière centralisée.
• VSphere Update Manager : un package complémentaire pour vCenter Server aide à conserver
les hôtes ESXi et les machines virtuelles avec les dernières mises à jour.
• VSphere Web Client : est l’interface utilisateur Web utilisée pour gérer une infrastructure
virtuelle.
• VSphere Client : une application Windows installée localement avec une interface utilisateur
graphique (GUI) pour toutes les tâches de gestion quotidiennes et pour la configuration
avancée d'une infrastructure virtuelle.
A ces composants clés s’ajoutent :
• VMware High Availability (HA) : il fournit une haute disponibilité pour les applications
exécutées sur des machines virtuelles. En cas de défaillance du serveur, les machines virtuelles
affectées sont automatiquement redémarrées sur d'autres serveurs de production disposant
d'une capacité de réserve
• VMware Distributed Resource Scheduler (DRS) : Il alloue et équilibre intelligemment la
capacité de calcul de manière dynamique entre les collections de ressources matérielles pour
les machines virtuelles

• VMware Consolidated Backup : fournit une fonction centralisée et facile à utiliser pour la
sauvegarde des machines virtuelles. Il simplifie l'administration des sauvegardes et réduit la
charge sur les installations des serveurs ESXi. Il est à noter qu’un commutateur virtuel nommé
vSwitch relie les machines virtuelles entre elle et permet également une connexion entre
celle-ci et un réseau externe.
Figure 10: Architecture VMware VSphere
3. HyperV
Lancé en 2008, Microsoft Hyper-V est un hyperviseur de type 1 développé par Microsoft. Il favorise
une utilisation efficace du matériel, améliore la continuité des activités, rend le développement et les
tests plus efficaces.Hyper V s’appuie sur la virtualisation complète. Il prend en charge l'isolation en
termes de partition. L’hyperviseur Microsoft doit avoir au moins une partition parente, ou racine,
exécutant Windows. Cette dernière abritera le centre de gestion de la virtualisation et aura un accès
direct aux ressources matérielles. Les machines virtuelles sont abritées dans des partitions émanant

de la partie parente. Ces partitions sont appelées des « partitions enfants » et sont créés à travers des
APIs venant de la partition parente.
Figure 11: Logo Hyper-V
a. Architecture avec Hyper V
Les composants clé d’une architecture avec l’hyperviseur Hyper sont les suivants :
• Hyperviseur Hyper V : situé entre le matériel et un ou plusieurs systèmes d'exploitation. Son
travail principal est de fournir des environnements d'exécution isolés appelés partitions.
• Mécanisme de communication basé sur les canaux (VMBus) : il est utilisé pour la
communication entre les partitions et l'énumération des périphériques sur les systèmes avec
plusieurs partitions virtualisées actives. Le VMBus est installé avec les services d'intégration
Hyper-V.
• Partition parente : elle gère les fonctions au niveau de la machine telles que les pilotes de
périphérique, la gestion de l'alimentation et l'ajout ou la suppression de périphériques. La
partition racine (ou parente) est la seule partition qui a un accès direct à la mémoire physique
et aux périphériques.
 Fournisseur de service de virtualisation (VSP) : il réside dans la partition racine (parente) et
fournit une prise en charge de périphérique aux partitions enfants à travers le bus de machine
virtuelle (VMBus).
 Fournisseur WMI : il permet aux développeurs de créer rapidement des outils, des utilitaires
et des améliorations personnalisés pour la plate-forme de virtualisation. Les interfaces WMI
peuvent gérer tous les aspects des services Hyper-V.
 Centre de gestion des machines virtuelles (VMMS) : il est responsable de la gestion de l'état
de toutes les machines virtuelles dans les partitions enfant.

• Client de service de virtualisation (VSC) : c’est une instance de dispositif qui réside dans la
partition enfant. Les VSCs utilisent des ressources matérielles fournies par les fournisseurs de
services de virtualisation (VSP) dans la partition mère.
• Partition enfant : c’est une partition qui héberge un système d'exploitation invité. Tous les
accès à la mémoire physique et aux périphériques par une partition enfant sont fournis via le
bus de machine virtuelle (VMBus) ou l'hyperviseur.
Figure 12: Architecture Hyper V
b. Les fonctionnalités de hyper V
Les principales fonctionnalités sont entre autres :
• Prise en charge de la mémoire persistante : elle contribue à réduire considérablement la
latence des transactions de base de données ou à réduire les temps de récupération pour les
bases de données à faible latence en cas de panne.
• Mises à jour de VM protégées : offrent aux VMs les mêmes capacités de sécurité que celles
dont bénéficient les machines physiques, par exemple le démarrage sécurisé, le cryptage des
disques, etc.
• Clusters simples à deux nœuds : pour créer facilement deux nœuds de piles de serveurs.
• Déduplication ReFS : elle permet de reconnaître et trouver les données identiques qui existent
dans le disque et de se débarrasser des copies supplémentaires de celles-ci.

• Améliorations directes des espaces de stockage : pour assurer la réplication des données dans
la technologie de stockage.
• Centre d'administration Windows : pour la création et la gestion des VMs.
• Sous-réseaux chiffrés : permettent de crypter le trafic des réseaux virtuels entre les machines
virtuelles.
4. Proxmox
Développé pour la première fois par la société Proxmox Server Solutions GmbH en 2008, Proxmox
Virtual Environment est une solution de virtualisation libre basée sur Debian GNU/Linux. Cette solution
permet de gérer deux technologies de virtualisation : KVM (Kernel-based Virtual Machine) pour les
machines virtuelles et LXC pour les conteneurs avec une seule interface web. Elle intègre également
des outils prêts à l'emploi pour configurer la haute disponibilité entre les serveurs, le stockage défini
par logiciel, la mise en réseau et la reprise après sinistre.
Figure 13: Logo Proxmox
a. Les Composants de Proxmox
Proxmox supporte 2 technologies de virtualisation, à savoir la LXC et la KVM. Elles sont toutes les deux
excellentes, mais il existe quelques différences entre les deux liées aux fonctionnalités et aux
performances.
❖ LXC
LXC s’appuie sur le noyau et le système d’exploitation de la machine hôte pour fonctionner.
Pour cette raison, certaines fonctionnalités sont limitées, telles que :
• L’utilisation de Windows et d’autres systèmes d’exploitation,

• L’installation de nouveaux noyaux,
• La modification des valeurs du noyau du système.
L’utilisation de LXC présente également des avantages :
• Peut-être plus performant que KVM car il n’y a pas de surcharge d’hyperviseur.
• Étant donné que les frais généraux sont inférieurs, le coût global d’hébergement des
conteneurs est inférieur à KVM.
❖ KVM
Lorsque vous utilisez KVM, vous ne rencontrerez généralement pas de fonctionnalités qui ne
sont pas prises en charge, comme dans le cas de LXC. Les serveurs KVM exécutent leur propre
système d’exploitation, avec son propre noyau et son matériel virtuel. Ceci permet :
• L’utilisation de systèmes d’exploitation Windows ou BSD,
• L’exécution de systèmes d’exploitation spécialisés, tels que le routage, le pare-feu et
d’autres systèmes d’exploitation centrés sur le réseau,
• L’utilisation de votre propre technologie de conteneur telle qu’OpenVZ, LXC, Docker
ou bien d’autres.
Figure 14: Architecture de Proxmox

b. Les Fonctionnalités de Proxmox
Nombreux sont les caractéristiques qui peuvent dépeindre la solution PVE. On peut en citer :
• Migration directe : cela permet de déplacer une machine virtuelle en cours d’exécution d’un
serveur physique à un autre, sans interruption.
• Haute disponibilité : en mode cluster Proxmox. Lorsqu’un nœud tombe en panne, les
machines virtuelles restantes sont déplacées vers un nœud fonctionnel pour garantir une
interruption de service minimale.
• Open source : il est entièrement open source, sous General Public License, version 3 (GNU
AGPL, v3). Cela signifie que vous pouvez librement visualiser, modifier et supprimer le code
source, et distribuer votre propre version, tant que vous respectez les termes de la Licence.
• Mise en réseau pontée : Proxmox VE permet à un utilisateur de créer un réseau privé entre
les machines virtuelles. Des options VLAN sont également disponibles.
• Modèle de système d’exploitation : Proxmox VE permet aux utilisateurs de créer leur propre
modèle de système d’exploitation pour un déploiement ultérieur. Bien sûr, il est également
possible pour les utilisateurs de télécharger un fichier modèle depuis Internet et d’importer ce
fichier dans leur système
• Stockage flexible : une large gamme d’options de stockage est disponible, y compris des
technologies de stockage locales et basées sur le réseau telles que LVM, iSCSI, NFS, le système
de fichiers Gluster et le système de fichiers CEPH.
• Sauvegarde planifiée : une interface utilisateur est fournie aux utilisateurs afin qu’ils puissent
configurer leur propre stratégie de sauvegarde. Les fichiers de sauvegarde peuvent être
stockés localement ou sur n’importe quelle option de stockage prise en charge que vous avez
configurée.
• Outil de ligne de commande (CLI) et une interface Web (GUI) : Proxmox VE fournit différents
outils de gestion CLI et une interface web GUI, permettant aux utilisateurs d’accéder au
conteneur de la machine virtuelle, de gérer les ressources, etc
B. TABLEAU COMPARATIF DES SOLUTIONS DE VIRTUALISATION
Pour le tableau ci-dessous, nous comptons comparer les solutions citées plus haut, suivant les
performances, maturité, le prix, la capacité de migration et les systèmes d’exploitation invités qui y
sont supportés.

Tableau 1: Comparaison des solutions de virtualisation
XenServer vSphere Hyper-V Proxmox
Année de Création 2008 2009 2003 2008
Coût de la licence
Libre.
Partie payante à
1149 $ par socket
de processeur
6220 $ par an
pour 1 CPU,32
Cores /Support
2999 $ par processeur,
illimité licences guest
OS incluses
Libre.
Partie Payante à
950 $ par socket
de processeur
Backup/Restore OUI OUI OUI OUI
Migration à froid OUI OUI OUI OUI
Migration à chaud OUI OUI OUI OUI
Snapshot OUI OUI OUI OUI
Template and Clone OUI OUI OUI OUI
Clustering et failover OUI OUI OUI OUI
Réplication de VM OUI OUI OUI OUI
CLI & GUI OUI OUI OUI (NON CLI) OUI
RAM / hôte 5 To 12 To 24 To 12 To
RAM / VM 1.5 To 6 To 12To (2e
générations) 6 To
1To (1er
génération)
Processeurs / VM 32 128 240 (2e
générations) 240
64 (1er
génération)
Disque VM 2 To 62 To 64 To (format VHDX) 10 To
2048 Go (format VHD)
OS invité supportés
Windows Server
2008 (ou >)
Windows Vista
(ou >)
• Windows
• Linux
• MacOS
Windows Server 2008
(ou >)
Windows Vista (ou >)
Linux
• Windows
• Linux
• Unix

Linux 3.4(ou >)
C. JUSTIFICATION DU CHOIX DE LA SOLUTION
Pour le choix de la solution de virtualisation, nous nous sommes basés sur les fonctionnalités des
hyperviseurs, leur intégration dans l’infrastructure existante, la maturité, le coût, la documentation et
les systèmes d’exploitation supportés.
 Le coût : Dans le but d’amoindrir les charges financières, le système à choisir devrait être
accessible à bas prix.
 La maturité : ce critère de choix est important. Une technologie mature est utilisée longtemps
pour que la plupart de ses défauts initiaux et de ses problèmes inhérents puissent être
supprimés ou réduits.
 Les fonctionnalités : la technologie choisie devrait avoir les fonctionnalités de virtualisation de
serveur, et de pouvoir assurer une haute disponibilité des ressources.
 La documentation : Une bonne documentation présente en détail le fonctionnement de
l’hyperviseur, l’installation et la configuration.
 Les OS invités supportés : le système à choisir devrait supporter les OS Windows et Linux au
minimum.
Analyse
En tenant compte du coût, Proxmox est gratuit sous licence Open Source, intégré dans le Kernel du
système Linux. Les autres solutions ont une partie gratuite avec des fonctionnalités restreintes.
Concernant la maturité, XenServer est la plus ancienne des solutions. Cependant vSphere et Hyper-V
sont les plus utilisés sur le marché. Les fonctionnalités sont presque les mêmes au niveau de Proxmox
et vSphere.
Toutes ces solutions sont bien documentées. Par contre, le support technique est assuré par les
entreprises comme Microsoft au niveau de l’utilisation de la solution Hyper-V ou VMware pour
vSphere. Pour Proxmox et la partie gratuite de XenServer, l’appui en cas de problème est géré par la
communauté notamment les forums.
Pour sa gratuité, les OS supportés, son forum accessible aux utilisateurs et sa fonction de High
Availability HA, la solution choisie est Proxmox.

IV. CHAPITRE IV : MISE EN PLACE DE LA SOLUTION
A. Vocabulaire
Dans le cadre de notre déploiement, nous utiliserons des concepts importants à rappeler. Dans les
lignes suivants nous allons expliquer ces concepts.
Cluster : un cluster est un ensemble de serveurs regroupés artificiellement ensemble pour permettre
la gestion globale de ceux-ci, et éventuellement la mise en place d'un système de haute disponibilité.
Nœuds : un nœud est le nom donné à un serveur à l'intérieur d'un cluster.
Snapshot : Un snapshot est une photographie à un instant T d'une VM. Après la création d'un snapshot,
à chaque modification du disque virtuel, chaque bloc d'origine est d'abord copié dans le snapshot avant
d'être modifié. Il est donc possible de revenir à un état initial ou d'utiliser celui-ci pour une sauvegarde.
Clonage : Cloner une VM permet d'en faire une copie. Cette copie sera alors autonome par rapport à
sa source. Celle-ci aura sa propre vie et les mêmes réglages que la VM source, du moins tant que vous
ne les changez pas.
Haute disponibilité : la haute disponibilité (High Availability, ou HA en anglais) consiste à assurer un
service continu aux utilisateurs/clients, même en cas de panne matérielle.
Quorum : un quorum correspond au nombre minimal de votants (nœuds) nécessaire pour valider une
décision. Dans le cas d'un cluster, il faudra que + de 50 % des votants soient présents (ou disponibles)
pour que le cluster puisse continuer à fonctionner et pour e faire il faut disposer d'un nombre impair
de nœuds pour permettre le fonctionnement du quorum.
Fencing : Le fencing consiste à pouvoir isoler chaque nœud du cluster pour être sûr qu'elle ne reviendra
pas inopinément. C'est dire qu'il évite des situations où les services tournent sur deux parties du cluster
indépendantes.
Failover : Le Failover consiste à réaffecter automatiquement les tâches à un nœud de secours, de telle
sorte que la procédure soit aussi transparente que possible pour l'utilisateur final.
NAS : Un NAS, ou stockage réseau (Network-Attached Storage) est simplement un serveur fournissant
leurs fichiers à d’autres serveurs par le réseau.
NFS : NFS (Network file storage) est le standard universel pour l’accès aux fichiers sur un réseau, c’est
le protocole le plus utilisé dans les NAS.

SAN : Un SAN, ou réseau de stockage (Storage Area Network), est un réseau sur lequel circulent les
données entre un système et son stockage.
RAID : la technologie RAID (Redundant Array of Independent Disks ou regroupement redondant de
disques indépendants) permet de répartir des données sur plusieurs disques durs afin d'améliorer soit
les performances, soit la sécurité ou la tolérance aux pannes de l'ensemble du ou des systèmes.
Plan de Reprise d'Activité : Le Plan de Reprise d'Activité (PRA) est la procédure mise en place
justement pour permettre une continuité de service.
B. Les Besoins Matériels
Tableau 2: Expression de besoins
Désignation Quantité Caractéristique (de préférence)
PVE 2 • 08 Go RAM
• CPU 16 Cores
• Disque 500 Go
NAS 2 • 16 Go RAM
• CPU 08 Cores
• 2 disques (Raid1)
C. ARCHITECTURE DE PROXMOX-VE POUR LA MISE EN PRATIQUE
Figure 15: Architecture de topologie réseau

D. DEPLOIEMENT
Le déploiement du laboratoire virtuel concerne principalement l’installation des PVE et des NAS pour
le stockage partagé.
Figure 16: Installation Proxmox
On attribue au PVE1 l’adresse 10.157.10.171/24 avec la passerelle et le DNS qu’il lui faut.
Figure 17: Attribution d'adresse au PVE1
On fait de même avec PVE2 : 10.157.10.172/24

Figure 18: PVE2 Information
Figure 19: Console installer Truenas
Figure 20: Console Setup install

Figure 21: Definition d’un password
Figure 22: Boot Mode
Figure 23: Console TrueNas
E. TESTS D’UTILISATION
Pour l’utilisation du laboratoire, nous allons connecter à l’interface d’admin de Proxmox et en suite
tester deux machines : une machine qui se base sur KVM et une autre avec la containerisation sur LXC
(sous forme de Template).

Figure 24: Interface de Connexion au Proxmox VE
Pour démarrer une machine virtuelle, il suffit de se placer sur la VM apparaissant à gauche, et de
cliquer bouton de droite démarrer :
Figure 25: Démarrage de la Machine Virtuelle
Une fois celle-ci démarrée, on peut voir la console en cliquant « console », ou ouvrir une fenêtre de
console en allant dans le menu console → NoVNC (NoVNC est un client et une bibliothèque VNC en
JavaScript) :

Figure 26: Démarrage de la Console
NB : Certains réglages pourront être modifiables à chaud, mais d'autres nécessiteront l'arrêt de la
VM.
Par la même procédure que cette dernière, on démarre une instance (container) Wordpress. Ci-
dessous les images de Wordpress
Figure 27: Instance wordpress démarré en mode CLI

Figure 28: Instance wordpress démarré en mode GUI
Figure 29: Page de connexion admin de l’instance Wordpress
CONCLUSION
L’objectif de notre projet de fin d’études était la mise en place d’un laboratoire virtuel au sein de l’UFR-
SET. La première étape était de donner une idée générale sur la Virtualisation, les types de
virtualisation, les domaines d’application entre autres. Nous avons fait par la suite une étude sur
différentes solutions open source et propriétaires de la Virtualisation. Laquelle étude nous a permis de
choisir la solution qui nous a le plus convenu : Proxmox. Ainsi nous avons modélisé une architecture
que nous avons ensuite déployée et testée.

Ce projet a été pour nous une chance et une formidable opportunité de découvrir un environnement
informatique nouveau, complexe et vaste, ce qui nous a permis d'acquérir de l'expérience en
administration systèmes et réseaux et d'approfondir nos connaissances dans le domaine de la
Virtualisation et du stockage en réseau mais surtout d’acquérir les bons réflexes que doit avoir tout
administrateur systèmes et/ou réseaux. Cependant il est important de noter que cette architecture
est déployée juste pour montrer la gamme de possibilités dont on peut bénéficier avec l’utilisation de
Proxmox. A chaque administrateur alors de conceptualiser, selon ses ressources et ses besoins,
l’architecture qui lui convient.
Vu la complexité de ce thème, l’on ne saurait, en un seul projet, exploiter toutes les possibilités qu’offre
Proxmox avec un stockage en réseau. Ainsi beaucoup d’autres avantages pourront être exploités et
faire l’objet d’autres perspectives de projet tel que l’utilisation de Proxmox avec une réplication à
distance du stockage.

2020-2021 XII BAYE OUSSEYNOU & SAIDOU MBODJI
Annexe :
Avant de créer une VM, nous allons commencer par uploader un fichier ISO qui nous permettra de
procéder à l’installation de notre OS virtualisé depuis un média d'installation. Si nous cliquons sur
l’onglet « Stockage » de notre datacenter, nous verrons un Stockage Partages (NFS) un stockage local,
et un stockage local-lvm.
Figure 30: Les stockages disponibles
Pour pouvoir uploader un ISO, il faut se rendre depuis le menu de gauche dans datacenter → pve1 ou
pve2 → le stockage partagé, puis images iso, et enfin cliquer sur « uploader » :
Figure 31: Upload des ISO
Une boite de dialogue vous demandera de sélectionner le fichier ISO.

2020-2021 XIII BAYE OUSSEYNOU & SAIDOU MBODJI
Figure 32: Boite de Dialogue pour upload
L'ISO sera alors disponible et visible.
Figure 33: Images Iso Debian 10
On peut débuter la création de la machine en cliquant sur « Créer VM » dans la barre en haut ou via le
bouton droit sur le nom de votre serveur à gauche ensuite définir les paramètres de la machines .
Figure 34: Création puis Lancement du VM

2020-2021 XIV BAYE OUSSEYNOU & SAIDOU MBODJI
Pour faire un snapshot sous Proxmox, il faut cliquer sur la VM, puis sur snapshot à droite :
Figure 35: Création snapshot:
La valeur « NOW » correspond à la position actuelle de la VM par rapport aux différents snapshots.
Cela prendra son sens quand des snapshots seront présents.
Figure 36: Représentations des snapshots
Nous pourrons ensuite restaurer un état antérieur depuis un snapshot, ou supprimer le snapshot de
votre choix.
Pour cloner une VM, il faudra cliquer sur le bouton droit sur le nom de la VM puis cloner ensuite
l'écran suivant :

2020-2021 XV BAYE OUSSEYNOU & SAIDOU MBODJI
Figure 37: Cloner un VM
Il vous faudra choisir le stockage cible, le nom de la VM, et éventuellement le nœud ou nous souhaitons
effectuer la copie sur un autre nœud.
Pour Migrer une VM, il faudra cliquer sur le bouton droit sur le nom de la VM ensuite vous aurez l’écran
suivantes :
Figure 38: Migration à froid
Figure 39: Migration en mode redémarrage

2020-2021 XVI BAYE OUSSEYNOU & SAIDOU MBODJI
Figure 40: Migration à chaud
Figure 41: Sortie Migration
Pour transformer une VM en Template, il faudra cliquer dessus via le bouton droit et sélectionner
convertir en Template :
Figure 42: Transformation d’une VM en Template

2020-2021 XVII BAYE OUSSEYNOU & SAIDOU MBODJI
Avant de pouvoir créer un conteneur, il vous faut un Template qui servira de modèle :
Vous pourrez en récupérer en cliquant « template » en allant dans le serveur (pve1 dans notre cas)
→ NFS-SHARE →CT Modèles :
Figure 43: Ajout d'un Template
Les templates proposés sont divisés en deux sections :
La section system va contenir des images telles que Centos8, Debian 10, Fedora34...
La section turnkeylinux va contenir des images telles que Moodle, Tomcat Apache, Nextcloud, c'est-à-
dire des Templates tout faits prêts à utilisation.
Une fois le template uploadé, vous pourrez le voir et éventuellement le supprimer depuis l'espace de
stockage.
La création du conteneur se fera par le clic en haut à droite à côté de créer VM ensuite définir les
caractéristiques de l’instance.

2020-2021 XVIII BAYE OUSSEYNOU & SAIDOU MBODJI
Figure 44: Création d’un Conteneur
Pour stocker au niveau des Nas nous allons monter les disques RAID 0 (Mirroring) puis le Partager en
NFS.
Figure 45: Partage NFS sur le NAS1

2020-2021 XIX BAYE OUSSEYNOU & SAIDOU MBODJI
Figure 46: Partage NFS sur le NAS2
Pour planifier des sauvegardes, il faut se rendre dans datacenter → sauvegardes
Figure 47: Sauvegarde des VMs

2020-2021 XX BAYE OUSSEYNOU & SAIDOU MBODJI
Pour Créer un Cluster il vous faudra aller sur datacenter → cluster puis « créer un cluster » sur le
premier nœud :
Figure 48: Création Cluster
Une fois le cluster créé, on peut joindre les autres nœuds au cluster.
Figure 49: Ajout du noeud au Cluster
Pour activer la haute disponibilité pour une VM, il vous faudra depuis celle-ci cliquer sur le menu « Plus
», puis gérer la HA (pour high availability).

2020-2021 XXI BAYE OUSSEYNOU & SAIDOU MBODJI
Figure 50: Gestion de la HA
La gestion globale de la haute disponibilité s'effectuera dans datacenter → HA :
Figure 51: Vue globale de la HA
Si vous n'avez que deux serveurs, vous n'aurez pas de quorum, et vous aurez le message d'erreur
suivant lors de la tentative de sortie du nœud
Proxmox permet l'authentification via un serveur LDAP ou Active Directory. Pour cela, il faudra aller
dans datacenter → Permissions → Authentification, ajouter.Mais vu que ces services ne gèrent que
l'authentification, pas les autorisations. Il vous faudra donc créer une correspondance en créant des
droits (utilisateurs/groupes).

2020-2021 XXII BAYE OUSSEYNOU & SAIDOU MBODJI
Configuration TrueNas
Après saisir l'adresse IP du NAS dans le navigateur Internet afin d'accéder à la page de connexion puis
renseigner "root" comme identifiant et le mot de passe que vous avez définie pendant l'installation.
Figure 52: Interface de connexion TrueNas
On est maintenant sur l'interface web de notre TrueNas
Figure 53: TrueNas Dashboard

2020-2021 XXIII BAYE OUSSEYNOU & SAIDOU MBODJI
Configuration d'un RAID : Sélectionnez "Create new pool" puis cliquez sur "Create pool" :
Figure 54: Céeation pool
Saisissez le nom de votre "RAID", ici cela sera "RAID-NAS1".
Figure 55: RAID-NAS1
Cochez les disques (1) puis cliquez sur le petit triangles (2) pour choisir le mode de RAID, ici nous
choissirons "Mirror" (3) pour faire un RAID 1 puis cliquez sur "CREATE" (4).

2020-2021 XXIV BAYE OUSSEYNOU & SAIDOU MBODJI
Figure 56: RAID-NAS1 Créé
Voilà notre RAID est actuellement opérationnel sur le TrueNAS.
Figure 57: Vue Globale d’un pool

2020-2021 XXV BAYE OUSSEYNOU & SAIDOU MBODJI
Créer un dossier à partager (Dataset) : Dans "Storage" => "Pool", allez tout à droite du disque et
cliquez sur les 3 petits points.
Figure 58: Ajout d'un Dataset
Puis cliquez sur "Add Dataset".
Figure 59: Création d'un Dataset

2020-2021 XXVI BAYE OUSSEYNOU & SAIDOU MBODJI
Puis cliquez sur "SAVE".
Configuration des droits d'accès sur le partage réseau :
Figure 60: Editer les Permissions
Activation et Configuration du NFS :
Cliquez sur NFS puis ADD
Figure 61: Ajout Du Partages NFS

2020-2021 XXVII BAYE OUSSEYNOU & SAIDOU MBODJI
Figure 62: NFS Permissions
Allez dans "Service" puis activer le service "NFS" pour un partage
Figure 63: NFS Services
Configuration RSYNC entre les Nas : dans "Service" puis activer le service "RSYNC" pour la
Synchronisation des 2 Nas
Figure 64: RSYNC Service

2020-2021 XXVIII BAYE OUSSEYNOU & SAIDOU MBODJI
Figure 65: Ajout du Module Rsync
Puis Aller dans Task ensuite RSYNC Task
Figure 66: Rsync Mode Pull (Server)

2020-2021 XXIX BAYE OUSSEYNOU & SAIDOU MBODJI
Figure 67:RSYNC mode Push (Client)
Figure 68: Task Rysnc Start

2020-2021 XXX BAYE OUSSEYNOU & SAIDOU MBODJI
WEBOGRAPHIE
https://www.proxmox.com/en/proxmox-ve/comparison
https://chrtophe.developpez.com/tutoriels/proxmox/#L4
https://www.howtoforge.com/tutorial/how-to-configure-a-proxmox-ve-4-multi-node-cluster
https://pve.proxmox.com/wiki/Main_Page
https://pve.proxmox.com/pve-docs-6
https://www.smarthomebeginner.com/proxmox-vs-esxi
https://www.rippleweb.com/vmware-vs-
proxmox/#:~:text=VMWare%20has%20more%20features%20overall%20than%20Proxmox%2C%20al
though,to%20use%20the%20shared%20storage%20from%20its%20cluster.
https://www.proxmox.com
https://www.vmware.com
https://www.citrix.com
https://www.redhat.com

2020-2021 XXXI BAYE OUSSEYNOU & SAIDOU MBODJI
TABLE DES MATIERES
INTRODUCTION GENERALE ..................................................................................................................... 1
I. CHAPITRE I : CADRE GENERAL DU PROJET ...................................................................................... 2
A. PRESENTATION DE L’ORGANISME D’ACCUEIL : UIDT-Thiès........................................................ 2
B. ETUDE ET CRITIQUE DE L’EXISTANT ............................................................................................ 3
C. SOLUTION PROPOSEE.................................................................................................................. 4
II. CHAPITRE II : VIRTUALISATION........................................................................................................ 4
A. HISTORIQUE DE LA VIRTUALISATION .......................................................................................... 4
B. NOTION DE VIRTUALISATION ...................................................................................................... 5
C. LES TYPES DE SOLUTIONS DE VIRTUALISATION........................................................................... 5
1. L’ISOLATION :........................................................................................................................... 5
2. LA PARAVIRTUALISATION :...................................................................................................... 6
3. LA VIRTUALISATION COMPLETE : ............................................................................................ 7
D. LES HYPERVISEURS ...................................................................................................................... 8
1. Les hyperviseurs de type 1 ...................................................................................................... 8
2. Les hyperviseurs de type 2 ...................................................................................................... 9
E. CATEGORIES DE VIRTUALISATION............................................................................................. 11
1. VIRTUALISATION DE SERVEURS............................................................................................. 11
2. VIRTUALISATION DES POSTES DE TRAVAIL............................................................................ 12
3. VIRTUALISATION DE RESEAUX............................................................................................... 13
4. VIRTUALISATION DE STOCKAGES .......................................................................................... 14
F. DOMAINES D’APPLICATION....................................................................................................... 15
III. CHAPITRE III : ETUDE COMPARATIVE DES SOLUTIONS DE VIRTUALISATION............................ 15
A. SOLUTIONS DE VIRTUALISATION............................................................................................... 15
1. XEN ........................................................................................................................................ 15
a. Les composants de la virtualisation Xen : ..................................................................... 16
b. Les fonctionnalités de XenServer : ................................................................................ 16
2. VMware vSphere :................................................................................................................. 17
a. Les composants de vSphere .......................................................................................... 18
3. HyperV................................................................................................................................... 19
a. Architecture avec Hyper V............................................................................................. 20
b. Les fonctionnalités de hyper V ...................................................................................... 21

2020-2021 XXXII BAYE OUSSEYNOU & SAIDOU MBODJI
4. Proxmox................................................................................................................................. 22
a. Les Composants de Proxmox......................................................................................... 22
b. Les Fonctionnalités de Proxmox.................................................................................... 24
B. TABLEAU COMPARATIF DES SOLUTIONS DE VIRTUALISATION ................................................. 24
C. JUSTIFICATION DU CHOIX DE LA SOLUTION.............................................................................. 26
IV. CHAPITRE IV : MISE EN PLACE DE LA SOLUTION ....................................................................... 27
A. Vocabulaire................................................................................................................................ 27
B. Les Besoins Matériels................................................................................................................ 28
C. ARCHITECTURE DE PROXMOX-VE POUR LA MISE EN PRATIQUE .............................................. 28
D. DEPLOIEMENT ........................................................................................................................... 29
E. TESTS D’UTILISATION................................................................................................................. 31

BAYE_O_FALL-SAIDOU_MBODJI-LabUT.pdf

Contenu connexe

Tendances

Similaire à BAYE_O_FALL-SAIDOU_MBODJI-LabUT.pdf

Dernier

BAYE_O_FALL-SAIDOU_MBODJI-LabUT.pdf