Mémoire Marc AMOUZOUN Version Final

THÈME

CONCEPTION D’UNE PLATE-FORME DE SERVICES A LA DEMANDE

Sous la direction de

Dr. Samuel OUYA

Présenté et soutenu par

M. Marc AMOUZOUN

Promotion 2010 - 2012

Décembre 2013

TELEINFORMATIQUE

Mémoire de fin de cycle IGGT Téléinformatique CONCEPTION D’UNE PLATE-FORME DE SERVICES A LA DEMANDE

Promotion 2010 - 2012 Page I

DEDICACES

Je dédie ce travail à mon feu père AMOUZOUN Kéhounde

Et à ma mère EGBI Cécile


Promotion 2010 - 2012 Page II

REMERCIEMENT

Je ne saurais commencer ce mémoire sans remercier DIEU le PÈRE TOUT

PUISSANT, qui a toujours guidé mes pas vers le chemin de la connaissance, par sa protection et

sa bénédiction.

J’adresse également mes remerciements :

- A ma mère EGBI CECILE et mon feu père AMOUZOUN KEHOUNDE pour

avoir toujours cru en moi ;

- A mes sœurs Arsène, Roberte et à mes frères Bertin et Charles pour leurs conseils

et leurs soutiens ;

- Au Docteur Samuel OUYA, notre encadreur de stage, pour sa disponibilité et

ses multiples recommandations ;

- A Monsieur Jean DIOCH, pour sa disponibilité et son engagement à la

réalisation de ce travail ;

- A tout le personnel de (RTN), les professeurs de l’ESP et de l’ESMT pour avoir

assuré notre formation;

- Au groupe «FOXRIVERGROUPE» (SALEH, CHERIF, SOULEY) ;

- A tous mes amis et plus particulièrement Jean-Baptiste HOUNDENOU, Samuel

AKPAN pour leurs aides et soutiens ;

- A toutes les personnes qui de près ou de loin, ont contribué à la réalisation de ce

document ;

- A toute la promotion Téléinformatique 2010-2012.


Promotion 2010 - 2012 Page III

SOMMAIRE DEDICACES .............................................................................................................................. I

REMERCIEMENT .................................................................................................................... II

SOMMAIRE ............................................................................................................................. III

SIGLES ET ABREVIATIONS .................................................................................................. V

TABLE DES FIGURES ........................................................................................................... VI

TABLE DES TABLEAUX ..................................................................................................... VII

AVANT PROPOS.................................................................................................................. VIII

INTRODUCTION ......................................................................................................................1

CHAPITRE 1 : PRESENTATION GENERALE .........................................................................2

1.1. Historique .....................................................................................................................3

1.2. Présentation de l’entreprise Réseaux et Techniques Numériques ...................................3

1.3. Présentation du sujet .....................................................................................................8

CHAPITRE 2 : VIRTUALISATION ET STATION SANS DISQUE ........................................ 11

2.1 Avantages de la virtualisation...................................................................................... 12

2.2 Sécurité ....................................................................................................................... 14

2.3 Types de virtualisation ................................................................................................ 16

2.4 La virtualisation de serveurs ........................................................................................ 19

2.5 Station sans disque ...................................................................................................... 29

Chapitre 3 : Etude et mise en place des solutions proposées...................................................... 34

3.1 Coût de la solution ...................................................................................................... 35

3.2 Architecture de la solution proposée ............................................................................ 36

3.3 Openvz ....................................................................................................................... 37

3.4 LTSP .......................................................................................................................... 45

Conclusion ................................................................................................................................ 56

Bibliographie ............................................................................................................................ 58

Webographie ............................................................................................................................. 60


Promotion 2010 - 2012 Page IV

Annexes .................................................................................................................................... 62

Table des matières ..................................................................................................................... 64


Promotion 2010 - 2012 Page V

SIGLES ET ABREVIATIONS

Abréviations

Significations

DHCP Dynamic Host Configuration Protocol

DNS Domain Name System

EC2LT Centrale des Logiciels Libres et des Télécommunications

GDI Graphics Device Interface

LDM LTSP Display Manager

LTSP Linux Terminal Server Projec

NFS Network File System

PDU Protocol Data Unit

PROM Programmable Read Only Memory

PXE Preboot eXecution Environment

RDP Remote Desktop Protocol

RTN Réseaux et Techniques Numériques

SSH Secure Shell

TFTP Trivial FTP

TIC technologies de l’information et de la communication

VE Virtual Environment

VLAN Virtual Local Area Network

XDMCP X Display Manager Control Protocol


Promotion 2010 - 2012 Page VI

LISTE DES FIGURES

FIGURE 1.1 : ORGANIGRAMME DE RTN ..............................................................................7

FIGURE 2.1: ARCHITECTURE AVEC VIRTUALISATION .................................................. 16

FIGURE 2.2: ARCHITECTURE SANS VIRTUALISATION................................................... 16

FIGURE 2.3: LA VIRTUALISATION COMPLETE [W1] ....................................................... 20

FIGURE 2.4: HYPERVISEUR [W1] ........................................................................................ 21

FIGURE 2.5: ISOLATION ....................................................................................................... 23

FIGURE 2.6: FONCTIONNEMENT DU PXE.......................................................................... 30

FIGURE 3.1 : ARCHITECTURE PROPOSEE DANS LE DOMAINE SCOLAIRE ................. 36

FIGURE 3.2 : ARCHITECTURE PROPOSEE SUR LE PLAN PROFESSIONNEL ................. 37

FIGURE 3.3 : INTERFACE DE GESTION .............................................................................. 41

FIGURE 3.4 : CONFIGURATION DU CLIENT SANS DISQUE ............................................ 47

FIGURE 3.5 : DEMARRAGE DU CLIENT LINUX ETAPE 1................................................. 48



FIGURE 3.8 : CONFIGURATION DU SERVEUR WINDOWS 2003 ...................................... 54

FIGURE 3.9 : DEMARRAGE DU CLIENT WINDOWS ETAPE 1.......................................... 54

FIGURE 3.10 : DEMARRAGE DU CLIENT WINDOWS ETAPE 2 ........................................ 55


Promotion 2010 - 2012 Page VII

LISTE DES TABLEAUX

TABLEAU 2.1 : CHOIX DE LA TECHNOLOGIE PXE .......................................................... 33

TABLEAU 3.1 : TABLEAU EVALUATION DU COUT D’INSTALLATION DU SYSTEME

DANS LE DOMAINE SCOLAIRE ................................................................................... 35

TABLEAU 3.2 : TABLEAU EVALUATION DU COUT DE LOCATION D’UN VE.............. 36


Promotion 2010 - 2012 Page VIII

AVANT PROPOS

Soucieuse de la demande des entreprises évoluant dans le domaine de l’informatique et des

télécommunications, l’Ecole Supérieure Polytechnique (ESP) et l’Ecole Supérieure

Multinationale des Télécommunications (ESMT) ont ouvert une formation d’ingénieur

Technologue en Téléinformatique.

PRESENTATION DE l’ESMT

L’Ecole Supérieure Multinationale des Télécommunications (ESMT) est une institution

multinationale qui accueille 17 nationalités en formation initiale et continue liée au Sénégal par

un accord de siège qui lui confère un statut diplomatique.

L’ESMT recouvre plusieurs domaines dont :

les diplômes de Technicien Supérieur :

- diplôme de technicien supérieur en télécommunications : spécialités technique et

commerciale

- diplôme de technicien supérieur en téléinformatique : en partenariat avec l’Ecole

Supérieure Polytechnique de Dakar

- diplôme de technicien supérieur en réseaux et données

licence professionnelle :

- réseaux et services

les diplômes d’Ingénieur :

- diplôme d’ingénieur des travaux télécoms (IGTT) : spécialités technique et

commerciale

- diplôme d’ingénieur téléinformatique, en partenariat avec l’ESP de Dakar


Promotion 2010 - 2012 Page IX

- diplôme d’ingénieur de conception

les diplômes de Master :

- master en Radiocommunications & Services

- master en Réseaux & Multimédia

les diplômes de Mastères :

- mastère en gestion des télécommunications

- mastère en réseaux télécoms

- mastère en téléinformatique en partenariat avec l’ESP de Dakar

les certifications :

- CISCO

- GVF

- FOA

- NSOFT

- Alcatel-Lucent

PRESENTATION DE L’ESP

le département Génie Chimique

le département Génie Civil

le département Génie Electrique

le département de Gestion

le département Génie Mécanique


Promotion 2010 - 2012 Page X

le département Génie Informatique

Dans le cadre de la formation qui s’étale sur deux (02) ans, l’étudiant devra effectuer un

stage de quatre à six mois dans une entreprise ou un laboratoire où il mettra à profit ses acquis

théoriques à l’issu duquel il devra présenter un mémoire de fin de cycle qui est le fruit du travail

effectué dans la structure d’accueil.

C’est dans cette optique que nous avions effectué un stage de quatre (04) mois à RTN

(Réseaux et Techniques Numériques) qui nous a proposé le thème : conception d'une plate-forme

de services à la demande.


Promotion 2010 - 2012 Page 1

INTRODUCTION

L'entreprise est une unité de production dont l'objectif est de vendre sur un marché des

biens et des services en vue de réaliser un maximum de profit. Afin d'optimiser les performances

de l’entreprise, la réduction des charges est un levier important. Sur le plan informatique,

l’évolution de la technologie (comme les solutions de virtualisation) contribue à la réduction de

coût informatique et améliore la réactivité de leur organisation informatique face aux besoins de

l'entreprise.

Par exemple, le déploiement d'un système ou d'une application peut simplement se faire à

distance, alors que l'installation du système d'exploitation d'une machine requiert la plupart du

temps quelqu'un sur place au moins pour les premières étapes. De même, si la société dispose de

peu de personnel, l'économie d'un déplacement de ces applications dans un datacenter peut se

révéler très bénéfique. En effet, la virtualisation permet de réduire le nombre de machines

physiques à acheter, le coût de l’administration et la maintenance. Il y a donc une économie

financière, qui peut être substantielle si l'entreprise a besoin de beaucoup de serveurs pour son

activité. En plus du simple gain en nombre de machines physiques, les économies réalisées en

consommation d'électricité, de location d'espace dans un datacenter et de bande passante sont

aussi à prendre en compte.

C’est dans cet ordre d’idée, qu’il nous a été confié dans le cadre de notre stage de fin de

formation, de travailler sur le thème : « Conception d’une plate-forme de services à la demande

». Pour mieux appréhender les contours de ce thème, nous avons divisé le travail en trois grands

chapitres.

Le premier chapitre sera tout d’abord consacré à la structure d’accueil, à la problématique et

aux objectifs visés à travers cette étude. Le deuxième chapitre portera sur la notion de

virtualisation, puis sur une étude comparative des différentes techniques de virtualisation, en

mettant en avant ses points forts et faibles pour mieux appréhender ce domaine qui nous est

nouveau afin de porter un choix technologique. Le dernier chapitre sera une présentation en

détail des solutions retenues et enfin le déploiement de ces dernières.



CHAPITRE 1 : PRESENTATION GENERALE



Dans ce chapitre nous présenterons la structure d’accueil à travers sa mission et son

domaine d’activité. Ensuite, nous présenterons le contexte et la problématique de notre sujet

ainsi que les objectifs visés.

1.1. Historique

Créé en 2003, RTN (Réseaux et Techniques Numériques) était à l’origine un G.I.E dirigé

par une équipe de professionnels qualifiés, d'Ingénieurs, de Techniciens et de diplômés de 3ème

cycle en réseaux informatiques. Son premier siège se trouvait alors aux HLM HANN

MARISTES Immeuble L Appartement 22.

En 2005, RTN se dote de ses propres locaux et transfère son siège à Front de Terre, Zone

de captage immeuble N° 36 Dakar-Sénégal.

En 2006, RTN est transformé en une SARL au capital de 1.000.000 FCFA. La société

est immatriculée au Registre du Commerce sous le numéro RC : SN DKR 2006 B 16356,

NINEA 2652776 2R2.

En 2008, RTN crée une école supérieure de formation en télécommunications et réseaux

informatiques EC2LT (Ecole Centrale des Logiciels Libres et des Télécommunications), ayant

un profil d’école-entreprise.

Le corps administratif du groupe RTN/EC2LT s’occupe aussi bien des services liés à

l’activité principale de RTN et des questions pédagogiques liées à l’activité scolaire et

pédagogique d’EC2LT.

1.2. Présentation de l’entreprise Réseaux et Techniques Numériques

L’entreprise Réseaux et Techniques Numériques (R.T.N) est une société dirigée par une

équipe de professionnels qualifiés, spécialisée en logiciels libres et centrée sur les services

informatiques, techniques numériques et les télécommunications. La société offre une large

gamme de formations se basant sur des supports de cours, fruits de recherches approfondies. Ces

supports testés et avérés permettent aux apprenants d’être aussitôt opérationnels.



1.2.1. Mission de RTN

La mission de RTN vise à accroître la compétitivité de ses clients par la valorisation des

composantes informatiques, logicielles et réseaux constituant le système d'information de ces

derniers. Cela leur confère des gains importants en produisant plus et mieux à budget réduit,

grâce à l’exploitation de la puissance des logiciels libres existants et ceci, sans rupture des cycles

d'exploitation de services de ces entreprises et sans remise en cause organisationnelle. Leur

principal objectif est de conseiller et de former le personnel des entreprises qui veulent disposer

des logiciels libres et adaptés à leurs besoins minimisant ainsi les coûts d' investissements en

réseaux informatiques tout en leur apportant une sécurité avancée.

1.2.2. Domaine d’activités

La société RTN offre une palette de services dans le domaine des technologies de

l’information et de la communication (TIC). Les services de RTN sont orientés Open Source et

réalisés selon les besoins de l'entreprise. Elles répondent par conséquent aux problèmes réels.

RTN met également un accent sur le développement des services à valeurs ajoutées, et

l’interconnexion des réseaux Linux et Windows, participant ainsi à la cohabitation et

l’harmonisation des réseaux hétérogènes Linux-Windows.

RTN intervient également dans les domaines suivants :

Une expertise unique en développement d’application : Web, téléphonie, SVI …

Une expertise approfondie en logiciels libres

Une expertise en ingénierie des réseaux

Une expertise dans les plateformes de formation à distance (e-Learning)

Une expertise en virtualisation

RTN dispense des formations dont la liste est la suivante :



Formations initiales

o 1er cycle

Diplôme Supérieur de Technologie (DST) Services et

Réseaux

Licence Télécommunication et réseau administration des

logiciels libres (TRALL)

Licence professionnelle

o 2 ème cycle

Master 1 & 2 en Télécommunications & Réseaux

Master 1 & 2 en Administration Réseau et Ingénierie des logiciels

libres (ARILL)

Formations continues

Les réseaux d’opérateurs Frame Relay Asynchronous Transfer Mode Réseau Numérique à Intégration de Service GSM (OpenBTS) IP Multimedia Subsystem Réseau étendue

Téléphonie sur IP Mise en place de la ToIP avec l’IPX open source Asterisk

Mise en place de la ToIP avec le Call Manager de Cisco

Mise en place de la ToIP en environnement hybride (Cisco -

Asterisk)



Applications mobiles et service à valeur ajoutée

Service USSD (Mobicent) Kannel Android J2ME

Administration système et réseau

Certification LPIC1

Certification LPIC2

Certification Cisco exploration

Certification Cisco Voice

Messagerie collaborative

Service réseau



1.2.3. Organigramme

Figure 1.1 : Organigramme de RTN

CA

DG

Directeur Formation

Recherche EC2LT

Service acceuil, info, animation

scolaire

Bureau des étudiants

Service Ressource

Technique et Documentaire

Service scolarité, recouvrement et

caisseDépartements

Commissions permanentes ou

adhoc

Conseil de la vie scolaire et des études (DFR)

Service Recherche

déploiement & formation

Service comptabilité et

finance

Service marketing

communication & commerciales



1.3. Présentation du sujet

1.3.1. Contexte du sujet

L’évolution d’une entreprise entraîne la naissance de nouveaux besoins en terme de

personnels, de services, etc. Les services déployés sont parfois proportionnels ou plus importants

que le nombre de machines physiques. Plusieurs services ou applications se trouvent ainsi co-

déployés sur de mêmes machines. En cas de panne d'une des machines, de nombreux services

devenaient indisponibles simultanément. Le risque de sécurité est aussi un problème majeur

auquel s’ajoute le manque de plate-forme de test. Certains serveurs sont loin des limites

d’utilisation et d'autres sont surexploités, que ce soit au niveau de leur puissance de traitement

qu’au niveau de l'espace disque utilisé.

Dans le monde universitaire, compte tenu du coût élevé des équipements de salles

informatiques (pour les travaux pratiques), plusieurs universités éprouvent des difficultés à

mieux assurer le côté pratique de la formation.

Fort de toutes ces observations, la RTN pense que le besoin d'une restructuration pour la

consolidation des services est donc totalement justifié.

1.3.2. Problématique

Il est fréquent de constater dans les entreprises, la séparation physique des applications et

systèmes lorsque les prérequis des applications sont mutuellement exclusives. Autrement dit,

deux applications peuvent être dépendantes d’un même logiciel mais de différente version.

Toutefois, cette dispersion a un coût qui n’est pas nul pour l’entreprise, que ce soit en espace

occupé, en énergie pour l’alimentation des équipements ou en maintenance. 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. 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. De même, l’absence de salles adaptées pouvant

garantir la sécurité des équipements informatiques est à noter. Cela expose l’entreprise à des

pertes de données. A ces problèmes s’ajoutent les risques d’inondation, de vol, d’incendie, etc.



En 2012, une chutte de 17,8% a été enregistrée dans le marché de l’emploi. C’est le

constat d’une étude de la Mauritius Employers Federation (MEF). En effet les entreprises

ressentent l’impact de la crise financière internationale. Cela s’explique aussi par le déficit de

compétence de la part des candidats. Sur le plan des TIC, ce déficit de compétence puise une

grande partie de sa source dans le manque de moyens financiers des écoles pour associer la

théorie à la pratique. Par conséquent, les étudiants sont confrontés à d’énormes difficultés en

entreprise car, n’ayant pas suffisamment manipulés les outils informatiques et télécoms aux

cours de leur formation.

Pour faire face à ces problèmes, nous avons opté pour le thème « Conception d’une plate-

forme de services à la demande ».

1.3.3. Concept de service à la demande

Ce concept consiste à déporter sur des serveurs distants des traitements informatiques

traditionnellement localisés sur le poste client de l’utilisateur. Dans notre cas, d’une part nous

allons implémenter un environnement de démarrage d'ordinateurs en réseau et d’autre part

définir de multiples templates (ensemble de packages) ou sauvegarder l'état de plusieurs

machines virtuelles correspondant à des VE (Virtual Environment) types. L’intérêt est de

pouvoir :

- Créer plusieurs VE prêtes à l’utilisation en moins d’une minute avec quelques services de

base préinstallés.

- Exploiter judicieusement les capacités des machines ou des serveurs.

Services à déployer

Sur le plan professionnel

Dans ce cas, nous allons simuler les entreprises d’hébergement en mettant à la disposition

des clients des templates comportant de divers services de base tels qu’un serveur web (apache),

une base de données et un serveur de transfert de fichier. De même, cette technologie pourrait

être implémentée en interne par les structures. Par rapport à la disponibilité des données, nous



allons réaliser un script qui permettra de faire de la sauvegarde incrémentielle et qui s’exécutera

périodiquement. Afin de faciliter l’administration du système nous allons implémenter une

application pour la gestion graphique.

Sur le plan éducatif

Compte tenu des difficultés ci-dessus auxquelles sont confrontées les universités, nous

allons développer une application en vue de mettre en place un environnement de travaux

pratiques favorables, permettant ainsi aux apprenants des TIC d’avoir une formation complète.

A cet effet, nous allons implémenter une application qui consistera à démarrer un ou

plusieurs ordinateurs sans unité de stockage par l’interface réseaux filaire. Par rapport aux TP

LINUX, un environnement linux léger sera démarré pour permettre à chaque étudiant d’accéder

à son VE. Au préalable l’enseignant devrait créer les VE. Concernant les TP Windows, les

clients se connecteront à un serveur Windows par l’intermédiaire d’une application Linux.

1.3.4. Objectifs

Les objectifs principaux de ce travail consistent à :

- Rationaliser les évolutions en besoins matériels, en empilant plusieurs serveurs sur une

machine physique tout en augmentant la disponibilité de l’ensemble

- Concevoir de divers templates pour simplifier l’administration et le montage d’un

environnement de test

- Mettre à la disposition de Chaque étudiant plusieurs VE lui permettant de se familiariser

avec les différentes distributions de Linux

- Réduire les coûts de l’entreprise

- Améliorer la sécurité.



CHAPITRE 2 : VIRTUALISATION ET STATION SANS DISQUE



La virtualisation est l’ensemble des techniques matérielles et/ou logicielles 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. [W2]

2.1 Avantages de la virtualisation

Le premier avantage qui nous saute aux yeux lorsque nous parlons de la virtualisation est

de pouvoir faire fonctionner plusieurs OS sur le même environnement physique. Mais il y en a

plusieurs qui peuvent être présentés pour ainsi montrer que l'on peut réduire les dépenses en

terme de machine et être plus efficace.

2.1.1 Réduction des coûts de matériel informatique La réduction de coûts est souvent l'enjeu n° 1 des entreprises, notamment en période de

crise économique où la stratégie repose davantage sur l'adage « faire plus avec moins ». La

virtualisation offre ainsi un moyen technologique de diminuer les dépenses. Elle permet de

réduire le nombre de serveurs physiques d’un parc informatique. En virtualisant plusieurs

systèmes et applications sur un même serveur, l'entreprise minimise ses achats de machines.

2.1.2 Réduction des coûts immobiliers En diminuant le nombre de serveurs de son parc informatique, l'entreprise optimise son

espace disponible. La virtualisation offre ainsi un gain de place pour les PME et permet aux

grandes entreprises d'optimiser leurs dépenses vers d'autres départements.

2.1.3 Electricité et climatisation

Une chose qui est très souvent oublié lorsqu'on calcule le coût d'un centre de données est

l'électricité de la climatisation. Comme nous le savons tous, plusieurs serveurs demandent de

l'électricité et produisent énormément de chaleur. Donc la diminution du nombre de serveurs

physiques entraînera automatiquement la baisse du coût d'électricité, et si la production de

chaleur diminue, la climatisation ne coûtera pas aussi chère.



2.1.4 Rapidité pour déployer un nouveau Serveur

Lors d’un projet de déploiement de service, l'achat et l'installation d'un nouveau serveur

sont souvent des processus très long. Il faut commander le serveur physique et les licences OS,

attendre la réception du matériel, ensuite installer l'OS, faire les mises à jour afin que le serveur

soit prêt. Cette procédure peut prendre une semaine. Dans le monde virtuel, nous pouvons créer

des templates qui sont en fait des installations de base d'OS qui servent à créer des serveurs. Ces

templates peuvent être installés avec des mises à jour avant d'être répliqués. De plus, nous avons

déjà l'équipement physique ainsi nous bénéficierons du temps de réception de serveur en cas de

commande. Si nous regardons la charge qui est sur nos serveurs, nous pouvons ainsi prévoir une

surcharge et commander à l'avance une nouvelle machine. La durée de déploiement d’un

nouveau serveur se compte maintenant en minutes au lieu des jours ou des semaines.

2.1.5 Portabilité

Pour la machine physique, l'OS n'est qu'une suite de fichiers. De plus, cet OS peut être

déménagé sur n'importe quel type de hardware sans risque de faire des Blue Screen au

démarrage. Ces fichiers peuvent être téléchargés et déployés sur un nouveau serveur.

2.1.6 Recouvrement suite à un désastre

Grace à la portabilité des machines virtuelles tel que mentionné dans le point précédent, il

est très simple et rapide de remonter un centre de données suite à un désastre. Il suffira de faire la

restauration à partir du backup des machines virtuelles.

2.1.7 Environnement de test

Une fonction très utile de la virtualisation est la possibilité de faire des snapshots qui sont

en fait des photographies du système. Il est ensuite possible de revenir en arrière très rapidement

suite à une erreur ou autre. Cette fonction est très utile dans un environnement de test et de

développement où on peut se permettre de faire des erreurs sans avoir peur de détruire la

configuration de base du serveur.



2.1.8 Ecologie

En ces périodes de crises écologiques, il est évidemment nécessaire de se poser la

question si la virtualisation est un bien pour l’écologie. La quantité de matière utilisée pour le

serveur physique est partagée par les différentes instances et cela réduit la consommation en

matières premières et en produits chimiques de l’électronique particulièrement polluants. La

virtualisation est donc un bien pour l’écologie.

2.2 Sécurité

La sécurité informatique consiste à garantir que les ressources matérielles ou logicielles

d'une organisation soient uniquement utilisées dans le cadre prévu. Plusieurs types d'enjeux

doivent être maîtrisés : l'intégrité, la confidentialité, la disponibilité, la non-répudiation, et

l'authentification. Mais comme toute solution informatique, l’assurance de ces enjeux s’avère un

peu complexe. A cet effet, la virtualisation n’est donc pas totalement parfaite, notamment en ce

qui concerne la sécurité même si elle présente plusieurs avantages.

2.2.1 Intérêt de la virtualisation

La virtualisation présente plusieurs avantages comme la possibilité de configurer des

réseaux dédiés permettant ainsi aux administrateurs de réduire les risques liés à la propagation

d'une infection.

Si un programme malicieux est installé dans une machine virtuelle, il est relativement

facile de la restaurer à un état précédemment sain. Même si cela n'est pas toujours possible, ceci

est particulièrement utile dans le cas des machines virtuelles hébergeant des données comme les

serveurs web. L’isolation qui existe entre une machine virtuelle et le serveur hôte permet de

limiter significativement les dégâts causés par des programmes malicieux destinés à corrompre

les données d'un système.

La portabilité des machines virtuelles offre la possibilité de mettre en œuvre des

processus de restauration à moindres coûts et de réduire considérablement le temps nécessaire à

la remise en route d'un serveur.



Les nouvelles fonctions offertes par la virtualisation permettent de concevoir des

systèmes capables de basculer automatiquement sur un serveur de réplication en cas de

défaillance de l’hôte en production. Enfin, en consolidant des infrastructures complexes dans des

environnements et des réseaux virtuels séparés, les administrateurs peuvent configurer des règles

spécifiques à chaque environnement et maximiser la sécurité (Environnements de tests, de

développement, ou d’environnements de production).

2.2.2 Risques de la virtualisation

Si un atout de la virtualisation est l’utilisation plus intensive des ressources

informatiques, la panne d’une ressource commune pourra engendrer l'indisponibilité simultanée

de plusieurs systèmes. De même, une attaque en disponibilité du serveur dédié (ou plus

généralement sur une ressource commune) impactera potentiellement tous les services hébergés

sur la même machine.

Bien que les solutions de virtualisation mettent généralement en œuvre des mécanismes

de cloisonnement, des instances se partageant une même ressource, ces instances ne sont pas en

pratique totalement isolées. Dans certains cas, des flux existent entre les différentes instances

(systèmes d’exploitation, applications, systèmes de stockage de données, …), flux qui peuvent

engendrer des vulnérabilités. Autrement dit dans une architecture avec virtualisation, les

machines virtuelles peuvent par exemple communiquer sur des réseaux physiques par le biais

d’une carte unique appartenant à la machine physique qui les héberge. Les flux de données de

chaque machine virtuelle sont donc traités par cette unique carte réseau. Dès lors, il n’est pas

possible de garantir un cloisonnement des flux au niveau de la ressource partagée. La carte

réseau a la possibilité, en cas d’erreur ou de compromission, de mélanger les différents flux

d’informations.



Figure 2.1: Architecture avec virtualisation [B1]

Figure 2.2: Architecture sans virtualisation [B1]

D'une manière générale, nous ne devons pas négliger l'aspect critique des serveurs de

virtualisation. Si une personne non autorisée obtient l'accès au serveur dédié, il lui est alors

possible de copier l’ensemble des machines hébergées vers une autre destination et ainsi obtenir

l'ensemble des informations sensibles d'une infrastructure.

2.3 Types de virtualisation

2.3.1 La virtualisation de serveurs

La plupart des serveurs sont sous-utilisés et achetés de façon massive afin de pouvoir

disposer de plusieurs environnements par exemple, ou encore isoler des données ou des espaces

utilisateurs. La virtualisation de serveurs permet de regrouper sur une seule machine l'ensemble



des applications tournant sur plusieurs serveurs tout en conservant une isolation entre celles-ci.

Un autre avantage est de pouvoir assurer la continuité de service en transférant facilement les

serveurs virtuels d'une machine physique à l'autre. Cette solution permet d’économiser de

l'énergie grâce à la diminution du nombre de serveurs et ouvre la porte vers l'informatique à la

demande. Par exemple : Xen, HyperV, VMware, VirtualBox

2.3.2 La virtualisation des postes de travail

La virtualisation du poste de travail permet de centraliser dans un environnement idéal et

protégé les éléments sensibles des postes de travail, comme le disque dur par exemple. Toutes les

données se trouvent donc centralisées ce qui facilite grandement la sauvegarde. Cela évite donc

que des données sensibles qui auraient été stockées sur le poste de travail soient volées ou

perdues. De plus, les utilisateurs ne peuvent pas changer la configuration de leur PC, cela permet

de réduire considérablement les risques de panne.

Cette solution banalise le poste de travail ce qui fait que l'utilisateur retrouve tout son

environnement et ses données quel que soit le poste qu'il utilise. Pour cela, il est possible

d'utiliser des clients légers qui sont soit de petits terminaux démunis de disque dur, soit d'anciens

PC, souvent peu puissants, recyclés pour ne faire que de l'affichage déporté. Le déploiement de

nouveaux postes de travail devient alors extrêmement simple et rapide. De même cette solution

permet de prendre la main à distance sur chaque poste afin d'aider les utilisateurs dans leurs

tâches si nécessaire. Les coûts de maintenance et de support utilisateurs sont donc réduits. On

peut citer comme exemple : Minitel, VDI, Terminal Serveur ou RDS, vSphere, VirtualPC,

Parallels

2.3.3 La virtualisation d’application

Virtualiser des applications revient à les installer sur un serveur de publication qui va

alors les rendre disponible depuis les postes de travail. L'application n'est alors plus liée au

système d'exploitation du poste de travail. Il est alors aisé de mettre à jour les PC car cela ne

nécessitera pas la réinstallation de telles applications vu qu'elles n'y sont pas installées. De



même, la mise à jour de l'application virtualisée se fait de façon centralisée et donc ne nécessite

aucune intervention sur les PC, ce qui la simplifie de façon considérable. Cela facilite aussi la

gestion des licences

2.3.4 La virtualisation de réseau

La virtualisation du réseau consiste à combiner des ressources réseaux 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.

Le résultat de la virtualisation du réseau est un réseau virtuel. Les réseaux virtuels sont

classés en deux grandes catégories : externe et interne. Les réseaux virtuels externes sont

composés de plusieurs réseaux locaux administrés par le logiciel comme une entité unique. Les

blocs de construction des réseaux virtuels externes sont le matériel de commutation et la

technologie logicielle VLAN. Les réseaux virtuels externes comprennent par exemple les grands

réseaux d'entreprise et les centres de données.

Les réseaux virtuels internes se composent d'un système utilisant des machines virtuelles

ou des zones configurées sur au moins une interface pseudo-réseau. Ces conteneurs peuvent

communiquer les uns avec les autres comme sur le même réseau local, fournissant un réseau

virtuel sur un seul hôte.

2.3.5 Choix technologique

Compte tenue des services que nous voulons implémenter, comme le regroupement de

plusieurs applications sur une machine, la suite de notre travail se basera principalement sur la

virtualisation de serveurs.



2.4 La virtualisation de serveurs

2.4.1 Etude comparative des différentes techniques de virtualisation de serveurs

La virtualisation a été brièvement définie dans l’introduction comme le moyen de faire

fonctionner sur une seule machine physique plusieurs systèmes d’exploitation ou plusieurs

applications. Cet objectif est atteint grâce à plusieurs technologies. Les technologies les plus

répandues sont :

– la virtualisation totale

– la paravirtualisation et hyperviseur

– la virtualisation assistée par le matériel

– le cloisonnement ou la virtualisation niveau noyau

2.4.1.1 La virtualisation totale

La virtualisation complète 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 logiciel

chargé d’émuler cette machine a pour rôle de transformer les instructions du système invité en

instructions pour le système hôte.

Il s'agit de la virtualisation la plus connue car elle est la plus facile à réaliser, même pour

un novice en informatique. Ce type de virtualisation fournit une abstraction totale du système

physique présent. Le logiciel émule tous les composants : processeur, bios, disque dur, carte

vidéo ... Il intercepte la plupart des instructions du système invité et les remplace par l'équivalent

sur le système hôte. Les machines n'ont pas conscience de l'émulation car elles sont virtualisées

sans aucun changement dans le système d'exploitation.

Ce genre de virtualisation, dont les outils sont principalement graphiques, servent dans le

cadre de tests pour les développeurs, ou pour tester un système temporairement. Il n'est pas

concevable d'héberger un serveur en production avec ce genre de virtualisation.

Exemple : bochs,VMware, Qemu, virtualbox, PearPC, Microsoft VirtualPC



Figure 2.3: la virtualisation complète [W1]

2.4.1.2 L’hyperviseur et la paravirtualisation La paravirtualisation est très proche du concept de la virtualisation complète, dans le sens

où c'est toujours un système d'exploitation complet qui s'exécute sur le matériel émulé par une

machine virtuelle, cette dernière s'exécutant au dessus d'un système hôte. Toutefois, dans une

solution de paravirtualisation, le système invité est modifié pour être exécuté par la machine

virtuelle. Les modifications effectuées visent à rendre le système émulé « au courant » du fait

qu'il s'exécute dans une machine virtuelle.

Tout comme la virtualisation complète, la paravirtualisation garde une séparation nette

entre le système invité et le système hôte. De ce fait, seul le système hôte à un accès direct et

exclusif au matériel. Le système invité doit donc toujours passer par la machine virtuelle pour

accéder au matériel, qui passe à son tour par la couche d'abstraction. On peut donc améliorer

davantage le processus en laissant au système invité, un accès direct au matériel mais contrôlé.

C'est le but des systèmes à hyperviseur.



L'hyperviseur est l'évolution de la paravirtualisation, si l'on recherche encore une

amélioration des performances. Dans les technologies précédentes, le système hôte était le seul à

avoir un accès direct au matériel. Avec un hyperviseur, le système hôte partage cet accès avec les

systèmes invités. Au démarrage de l'ordinateur, c'est normalement le système d'exploitation qui

prend la main et contrôle le matériel. Dans le cas de l'utilisation d'un hyperviseur, c'est un

système minimaliste (l'hyperviseur) qui prend le contrôle du matériel. Ensuite, il fait appel à un

système d'exploitation complet, qui sera donc exécuté par dessus l'hyperviseur. Ainsi, le système

d'exploitation doit passer par l'hyperviseur pour tout accès au matériel.

On peut donc très facilement instancier un deuxième système d'exploitation, qui passera

lui aussi par l'hyperviseur pour l'accès au matériel. Comme les systèmes d'exploitation doivent

obligatoirement passer par ce dernier pour tout accès au matériel, l'hyperviseur peut s'assurer

qu'ils accèdent aux ressources autorisées sans perturber le fonctionnement des autres systèmes.

Exemple : Xen, VMware ESX, Microsoft

Figure 2.4: Hyperviseur [W1]



2.4.1.3 La virtualisation assistée par le matériel 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 virtualisation assistée par 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.

2.4.1.4 Le cloisonnement ou la virtualisation au niveau du système d'exploitation

Une autre pratique répandue dans le domaine de la virtualisation est le cloisonnement.

Derrière ce nom se cachent plusieurs technologies visant à séparer fortement les processus

s'exécutant sur un même système d'exploitation. Le cloisonnement vise à isoler chaque processus

dans un conteneur. Un processus isolé de la sorte ne saura pas quels autres processus s'exécutent

sur le même système, et n'aura qu'une vision limitée de son environnement. Le but principal de

cette technologie est d'améliorer la sécurité du système d'exploitation et des applications.

Cette solution est très performante, du fait du peu d'overhead (chute de performance

conséquente de l'ajout des couches de virtualisation), mais les environnements virtualisés ne sont

pas complètement isolés, ils partagent en particulier le code du noyau. Cette solution est aussi

remarquablement économique en mémoire. Ces environnements sont donc bien adaptés au

déploiement de nombreux serveurs virtuels de test ou développements basés sur un même

système.

Exemple : FreeBSD Jail, Solaris Zones/Containers, Linux-VServer, OpenVZ, Virtuozzo



Figure 2.5: isolation

2.4.2 Choix technologique

Le choix de la bonne solution de virtualisation dans l’absolu est très difficile, et la

pléthore de projets de virtualisation disponibles ne facilite pas la décision.

2.4.2.1 VMware server

La société VMware édite plusieurs logiciels de virtualisation. Elle est leader dans le

marché de la virtualisation. Le produit à destination des entreprises est VMware Server, solution

de virtualisation complète pour serveur sous GNU/Linux et/ou Microsoft Windows. Les

performances et les fonctionnalités offertes par VMware Server le placent parmi les meilleures

solutions de virtualisation. On peut optionnellement activer des modules de paravirtualisation

pour augmenter davantage les performances. Mais sa licence est payante.



2.4.2.2 QUEMU

QEMU utilise la virtualisation totale. Il fonctionne sur les plates-formes : Microsoft

Windows, GNU/Linux, Mac OS X et est très simple d’utilisation. QEMU peut en option utiliser

un module d’accélération système pour améliorer les performances. Ce module s’appelle kqemu

(kernel-QEMU) et est disponible pour Windows et GNU/Linux. Il s’intègre au noyau (ou dans

les services dans le cas de Windows).

- Gestion du réseau

QEMU offre plusieurs modes de fonctionnement pour la connexion du système invité au

réseau. La première méthode est appelé user mode networking. Dans ce mode, QEMU offre un

réseau privé au système invité. Du point de vue du système invité, il y a un réseau privé simple,

avec un serveur DHCP qui attribue des adresses IP et une passerelle pour accéder à Internet. Ce

mode est totalement indépendant du système hôte, le DHCP et la passerelle sont émulés par

QEMU.

Le deuxième mode proposé est le mode TAP (ou tuntap). Dans cette configuration, une

interface réseau virtuelle est créée sur le système hôte. Cette interface virtuelle est ensuite reliée

à l’interface physique par un pont (bridge), qui servira à faire passer le trafic réseau de l’une vers

l’autre. QEMU relie alors le système invité à l’interface virtuelle. Dans ce mode de

fonctionnement, il y a donc une interface virtuelle assignée à une machine virtuelle. Chaque

machine virtuelle ainsi créée dispose donc de son adresse IP au sein du réseau. Ce

fonctionnement est toutefois un peu plus complexe à mettre en place que le mode précédent.

Une autre particularité intéressante de QEMU est la possibilité de relier les systèmes

invités entre eux, indépendamment du réseau physique sous-jacent. Chaque instance de QEMU

démarrée peut se voir assigner un numéro de VLAN (réseau virtuel). De cette manière, seules les

machines virtuelles partageant le même numéro de VLAN peuvent communiquer entre elles. On

peut ainsi relier les instances QEMU entre elles même.



- Communauté

L’activité autour de QEMU est toujours importante et les contributions externes sont

relativement régulières. QEMU dispose d’une forte communauté. Cette communauté est

rassemblée autour d’une liste de diffusion, de forum, wiki ...

- Licence

QEMU est diffusé sous la licence GNU/GPL. Jusqu’à récemment, le module d’accélération

kqemu était diffusé sous une licence interdisant la redistribution, mais il est dorénavant distribué

sous la même licence

- Inconvénients

Il sera difficile de comprendre et modifier les sources du programme, si jamais le besoin se

fait sentir, compte tenue de la grande complexité du code réalisant l’émulation du processeur.

L’évolution du projet est donc aux mains des personnes à même de comprendre l’architecture

bas niveau de QEMU.

Toujours au niveau du code, Quemu est dépendant de la version du compilateur GCC (GNU

Compiler Collection, le compilateur du projet GNU). Or, à chaque changement de version du

compilateur, le code généré change légèrement. C’est pourquoi il est nécessaire de compiler

QEMU avec des versions très précises de GCC. Cela devient problématique, car certaines

versions ne sont plus vraiment supportées à l’heure actuelle. Toutefois si l’on souhaite tester un

changement ou modifier les options de compilation, il est nécessaire d’installer une ancienne

version de GCC. Les performances de la machine virtuelle sont un autre facteur limitatif.

Comme toutes les solutions de virtualisation complète, QEMU pêche au niveau de la rapidité

des Entrées/Sorties. Le module d’accélération kqemu améliore certes les performances, mais on

reste loin des performances « natives ».

2.4.2.3 KVM

KVM est un projet de virtualisation complète basé sur QEMU. Il reprend toutes les

fonctionnalités de ce dernier, qui ont déjà été traitées précédemment. KVM offre la migration à



chaud des systèmes invités. Le processus de migration de systèmes invités de KVM est

actuellement plus performant que celui de QEMU.

- Communauté

KVM dispose d’une forte communauté. Cette communauté est rassemblée autour d’une liste

de diffusion, wiki. Le développement est principalement assuré par les employés de Qumranet

(notamment Avi KIVITY, mainteneur officiel), mais il y a des contributeurs externes réguliers.

On peut notamment citer Rusty RUSSELL, ou encore des employés d’Intel, d’AMD ou d’IBM.

- Licence

QEMU est diffusé sous la licence GNU/GPL

- Inconvénients

Étant basé sur QEMU, KVM souffre des mêmes inconvénients sur la complexité du code. Le

potentiel d’évolution de KVM est très élevé, mais le développement est, pour l’instant

ininterrompu. Même s’il n’a pas toutes les fonctionnalités nécessaires à l’heure actuelle. Il y a

donc un risque d’affronter des difficultés inattendues en utilisant KVM

2.4.2.4 LINUX-VSERVER

Le projet Linux-VServer est un projet de virtualisation par cloisonnement. C’est à dire qu’il

isole des instances du système d’exploitation par dessus un système hôte. Du point de vue

technique, il se compose de patches à appliquer sur le code source du noyau Linux. Linux-

VServer se base sur les fonctionnalités déjà implémentées au sein du noyau. Il y a un seul noyau

Linux, qui contrôle toujours l’accès au matériel, mais il est partagé entre plusieurs instances du

système, qui ont chacune un accès complet au noyau, sans connaissance des autres systèmes

invités. Comme le projet utilise une technologie de cloisonnement, il n’y a quasiment pas de

perte de performances par rapport à un système natif. Contrairement à QEMU et KVM, Linux-

VServer ne travaille pas avec une image disque du système, mais avec un simple ensemble de

fichiers dans un répertoire, qui représentera la racine du système invité. Cela implique une plus

grande facilité d’utilisation. En effet, il est possible avec ce mode de fonctionnement de modifier



des fichiers du système invité en les ouvrant depuis le système hôte, comme n’importe quel autre

fichier.

- Communauté

La communauté du projet Linux-VServer est moyennement active, centrée autour d’un

Wiki et d’une liste de diffusion.

- Licence

Le projet Linux-VServer est intégralement sous licence GNU/GPL.

- Inconvénients

La séparation entre les systèmes invités est trop faible, dans le sens où il y a un seul

noyau Linux pour plusieurs systèmes invités. Si un système invité trouve un moyen de

contourner les protections et affecte le noyau, tous les autres systèmes de la machine en subiront

les conséquences. C’est une faiblesse dont souffrent toutes les solutions de virtualisation utilisant

le cloisonnement.

Un autre problème majeur est la difficulté de maintenir le projet à jour. En effet, comme

le code de Linux-VServer est un patch pour le noyau Linux, il est possible et même très fréquent

qu’une nouvelle version du noyau casse la compatibilité du patch. Il faut alors attendre qu’une

nouvelle version du projet Linux-VServer sorte spécifiquement pour la nouvelle version du

noyau.

2.4.2.5 OPENVZ

OpenVZ est un projet de virtualisation par cloisonnement. Le principe de fonctionnement

d’OpenVZ est très similaire à celui de Linux-VServer, car ils se basent tous les deux sur une

modification du noyau Linux pour implémenter un système de cloisonnement au niveau du

système d’exploitation. OpenVZ modifie le noyau Linux plus en profondeur que le patch de

Linux-VServer. Il y a donc des fonctionnalités spécifiques à OpenVZ. Parmi ces nouvelles

fonctionnalités, on peut notamment citer l’ajout d’un niveau supplémentaire d’indirection pour

les ordonnanceurs du noyau. Ce nouveau niveau d’indirection permet de gérer les priorités entre

les systèmes invités.



Une fonctionnalité intéressante d’OpenVZ est la possibilité de migrer un système invité

à chaud. Il offre la possibilité de sauvegarder l’état complet du système invité dans un fichier sur

le disque, puis à le transférer sur une autre machine où l’état pourra alors être restauré. Au niveau

du contrôle des ressources, OpenVZ propose un ensemble de limites par système invité, que

l’administrateur peut configurer. Par exemple, il peut allouer un nombre maximal de processus

qu’un système invité aura le droit de créer, etc. Ces limites par système invité permettent un très

bon contrôle et garantissent qu’un système ne nuira pas aux autres. La connectivité réseau est

très similaire aux autres solutions, chaque système invité peut disposer de sa propre adresse IP et

le noyau modifié s’occupera de rediriger le trafic réseau vers le bon système.

- Communauté

La communauté d’OpenVZ est centralisée autour d’un wiki, de plusieurs listes de diffusion et

du site web de SWsoft. Dans l’ensemble, la communauté donne une impression de meilleure

organisation et de plus grande activité que celle de Linux-VServer. La documentation disponible

est par contre très bien fournie, et on peut très rapidement avoir une idée du produit, tant du point

de vue utilisation et administration que pour l’aspect technique.

- Licence

Le projet OpenVZ est distribué sous la licence GNU/GPL.

- Inconvénients

En effet, le projet libre dispose de moins de fonctionnalités que la version propriétaire et

payante. La version payante est montrée comme la version complète, alors que la version libre

est juste là pour appâter la communauté et attirer les contributions.

2.4.2.6 BILAN

Après une étude approfondie de quelques solutions de virtualisation, notre choix

technologique se portera sur OpenVZ, compte tenue de la documentation disponible, la facilité

d’installation et ses avantages cités ci-précédemment comparativement aux autres solutions.



Concernant l’interface de gestion, dans un premier temps, nous avons préféré concevoir

nous même une interface graphique pour faciliter l’administartion ou la gestion des VE. Au cour

de notre travail nous avions pris connaissance de l’environnement de virtualisation proxmox basé

sur OpenVZ et KVM. Cette solution offre l’opportunité de réaliser toutes les tâches d’OpenVZ

en interface graphique. Ainsi nous avons préféré proxmox pour la gestion graphique.

2.5 Station sans disque

Une station diskless est comme son nom l'indique, un poste de travail sans disque dur. La

logique qui prévaut au déploiement des stations diskless est essentiellement économique : il

s'agit de réduire le coût total de possession du poste de travail.

Dans la suite de notre travail nous allons essayer de porter un choix sur une application

diskless qui permettra de connecter de nombreuses stations clientes légères sur un serveur. En

effet les applications s’exécuteront sur le serveur. Les stations clientes vont envoyer les signaux

d'entrée de périphérique vers le serveur et affichent en retour le résultat donné par les

applications.

Enfin pour permettre aux machines légères l’accès à distance, nous utiliserons la

technologie PXE (Preboot eXecution Environment).

2.5.1 Application pre-boot eXecution Environment

Le PXE est un système permettant de démarrer un (ou plusieurs) ordinateur(s) avec ou

sans unité de stockage (disque dur, disquette) par l'interface réseau filaire. Suivant la

configuration, nous pouvons réaliser plusieurs actions: démarrage sur un disque dur à distance,

installation à distance d'un OS etc.

2.5.2 Fonctionnement

Le PXE est un protocole propriétaire d'Intel. Les machines dotées de cette fonctionnalité

possède une PROM et de RAM sur laquelle la machine va booter. Cette PROM contient les

premières instructions qui vont permettre d'effectuer une requête DHCP (Dynamic Host



Configuration Protocol) auprès du serveur afin d'obtenir une adresse IP sur le réseau. Le client

récupère ensuite le noyau linux par TFTP (Trivial FTP) et peut donc booter sur ce noyau.

Figure 2.6: Fonctionnement du PXE



2.5.3 Avantages

La technologie PXE présente plusieurs avantages à savoir :

- La réduction de coûts

- Une pleine exploitation des ressources matérielles

- La gestion centralisée, la portabilité, la sécurité

- Pas de répétition des installations dans le cas d’un parc de machines

- Pas de sauvegardes à faire pour chacun des postes

- La réutilisation de vieux postes

- La baisse de la consommation électrique

- Aucun achat de licence nécessaire

2.5.4 Inconvénient

Le point à améliorer du PXE est sa dépendance du réseau. C'est-à-dire en cas de

problème réseau, le client n'a plus accès à son environnement de travail.

2.5.5 Choix du seveur de clients légers

Technologies

Avantages

Inconvénients

THINSTATION

Stabilité du système: Le

système du client léger tourne

sur un filesystem en RAM

indépendant du réseau. Une

coupure ou congestion réseau

n'a donc aucun impact sur le

système (Après la phase de

boot, le PC est autonome)

Reconnaissance du matériel:

Thinstation étant une

distribution à part entière, il

faut que le matériel (carte

vidéo et carte réseau) soit

reconnu.



Peu de puissance matérielle

requise

LTSP

Reconnaissance du matériel:

LTSP n'est pas une

distribution. Le client léger

tourne sur le système exporté

par le serveur LTSP, qui est

une distribution quelconque

installée au préalable sur le

serveur. Le matériel est donc

reconnu au même titre que si

la distribution avait été

installée en local sur le PC.

Dépendance du réseau: En cas

de problème réseau, le client

n'a plus accès à son filesystem

FADDEF

Reconnaissance du matériel :

les applications sont

disponibles via NFS, la taille

du filesystem n'est donc pas

limitée par la mémoire vive.

Au démarrage, le PC utilise

les fonctionnalités de

reconnaissance de matériel de

la distribution Linux (carte

openGL, USB, etc.). De par

son coté client mi-lourd, les

applications exécutées

localement profitent de toute

la puissance du PC et de ses

périphériques.

Dépendance du réseau: en cas

de problème réseau, le client

n'a plus accès à son filesystem



Simple à mettre œuvre et à

déploiement

Tableau 2.1 : choix du serveur de client léger

Au regard des avantages et inconvénients de chaque technologie, nous avons préféré le

LTSP, parce que le client léger tourne sur le système exporté par le serveur LTSP, qui est une

distribution quelconque installée au préalable dans un environnement chrooté sur le serveur. Le

matériel est donc reconnu au même titre que si la distribution avait été installée en local sur le

PC. Contrairement à d’autre technologie qui nécessite d'avoir des postes matériellement

identiques.



Chapitre 3 : Etude et mise en place des solutions proposées



3.1 Coût de la solution

Le choix d’OpenVZ et de LTSP nous épargne des coûts de licences qu’on devrait payer avec

des solutions propriétaires.

Le tableau ci-dessous nous présente une facture pro forma de la solution proposée.

Domaine scolaire Caractéristiques Quantité Prix(FCFA) Prix total

Machine

Serveur

mémoire RAM (512Mo +

50*256) pour le serveur openvz

mais pour mesure de prévention

on prendra 32Go

carte réseau (Giga-Ethernet)

compatible PXE

nombre de processeur (intel): 1

disque dur 1Terra

marque HP

2

550.600

1.101.200

Machine

cliente

Mémoire RAM de 256Mo

carte réseau 100Mb compatible

PXE

processeur x86 type Pentium 3

pas de disque dur

50

50.000

2.500.000

TOTAL = 3.601.200 FCFA

Tableau 3.1 : Tableau évaluation du coût d’installation du système dans le domaine scolaire



professionnel

- Client

Caractéristique du serveur dédiées coût - Disque dur 4 To

- RAM 32Go

- Bande passante garantie : 200Mbps

26.200 FCFA/mois

Tableau 1.2 : Tableau évaluation du coût de location d’un VE

3.2 Architecture de la solution proposée

Figure 3.1 : Architecture proposée dans le domaine scolaire



Figure 3.2 : Architecture proposée sur le plan professionnel

3.3 Openvz

OpenVZ est un projet de virtualisation par cloisonnement géré par la société SWsoft. Le

modèle commercial de SWsoft consiste en une offre propriétaire (et payante) nommée

Virtuozzo, qui se base sur le projet libre OpenVZ. Les clients souhaitant un support technique de

qualité et de performances très élevées se tournent vers le produit Virtuozzo, les clients préférant

utiliser une technologie libre et pouvant se contenter du support fourni par la communauté utilise

OpenVZ.

3.3.1 Principe de fonctionnement d’Openvz

OpenVZ est un système de virtualisation particulière. Ce type de virtualisation n'émule

aucun matériel. Autrement dit, openVZ repose sur une modification du noyau Linux sous la

forme d'un patch parce que le code n'est pas intégré dans le noyau officiel. Ce patch est

accompagné d'utilitaires indispensables pour administrer les machines virtuelles.



OpenVZ permet de faire tourner de multiples machines virtuelles partageant un seul

kernel patché. Cette technique est donc limitée à des machines (hôte ou invité) tournant sous

linux. En contrepartie les performances sont particulièrement élevées. Les serveurs virtualisés

partagent le même noyau de la machine hôte (qui n'est donc plus dupliqué, comme pour les

autres types de virtualisation), et ne nécessitent que très peu de ressources. C'est un système de

virtualisation léger et peu intrusif.

Au démarrage de la machine physique, chaque processus est taggué avec un numéro de

contexte, permettant de savoir à quelle machine il appartient. Ainsi, l'utilisateur d'un serveur

virtualisé sera lui-même taggué et ne pourra interagir qu'avec les processus de son contexte.

Cette façon de fonctionner assure un niveau de sécurité supplémentaire au cas où un individu

réussirait à remonter un serveur virtualisé.

3.3.2 Implémentation de la solution Installation d’OpenVZ

#apt-get install linux-image-openvz-686

Création d’une machine virtuelle

# vzctl create 101 - - ostemplate debian.tar.gz

# vzctl set 101 - - hostname serveur1 - - save

# vzctl set 101 - - ipadd 10.0.0.1 - - save

#vzctl start 101

Ou

# vzctl create 101 -- ostemplate debian.tar.gz -- hostname "serveur1"- - ipadd 10.0.0.1 # vzctl start 101

Se connecter à une machine virtuelle

# vzctl enter 101



Lister les machines virtuelles

# vzlist –a

Supprimer une machine virtuelle

#vzctl destroy 101

Dans le cadre d’une entreprise

Autorisation de la machine virtuelle à accéder au réseau externe

#echo

# iptables -t nat -A PREROUTING -i eth0 -d 192.168.0.1 -p tcp --dport 22 -j DNAT --to-

destination 10.0.0.2

# iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE

# iptables-save

#echo 1 > /proc/sys/net/ipv4/ip_forward

Création de Template

// arreter la machine virtuelle

# cd /var/lib/vz/private/101

# tar –zcf /var/lib/vz/template/cache/nom_template.tar.gz .

Configuration du DNS

(Voir annexe 1)

Configuration d’apache comme proxy pour l’accès par nom aux machines virtuelles (selon l’url)

# cd /etc/apache/site-enabled

- Serveur 1

#vim serveur1.ec2lt.sn



<VirtualHost 192.168.0.1:80>

ServerAdmin root@ ec2lt.sn

ProxyRequests off

ServerName serveur1.ec2lt.sn

<Proxy *>

order deny,allow

allow from all

</Proxy>

ProxyPass / http://10.0.0.1/

ProxyPassReverse / http://10.0.0.1/

DocumentRoot /var/www

<Directory />

Options FollowSymLinks

AllowOverride None

</Directory>

<Directory /var/www/>

Options Indexes FollowSymLinks MultiViews

AllowOverride None

Order allow,deny

allow from all

</Directory>

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

<Directory "/usr/lib/cgi-bin">

AllowOverride None

Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch

Order allow,deny

Allow from all

</Directory>

ErrorLog ${APACHE_LOG_DIR}/error.log

# Possible values include: debug, info, notice, warn, error, crit,



# alert, emerg.

LogLevel warn

CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

- Serveur 2

(Voir annexe 2)

Interface de gestion

Figure 3.3 : interface de gestion

Dans le cadre des universités

Configuration des interfaces pour permettre aux machines virtuelles d’être dans le même

réseau que le serveur hôte. Ainsi chaque étudiant pourra accéder à sa machine virtuelle par SSH.

Installation des utilitaires et activation de la gestion de bridge

#apt-get install bridge-utils



#echo EXTERNAL_SCRIPT="/usr/sbin/vznetaddrbr" /etc/vz/vznet.conf

Création d’un bridge sur l’hôte

#vim /etc/network/interfaces auto vz0 iface vz0 inet manual bridge_ports eth0

Effacer les adresses IP des machines virtuelles. (Au cas où les machines virtuelles

ne sont pas dans le même réseau que le serveur hôte)

Il s’agit du fichier /etc/vz/conf/machineVirtuelle.conf. Dans notre cas

/etc/vz/conf/101.conf

Ajout des interfaces aux machines virtuelles

#brctl addbr vz0 #vzctl set 101 --netif_add eth0 --save //(l'interface eth0 sera ajouter à la machine virtuel) #vzctl set 102 --netif_add eth0 –save #brctl addif vz0 veth102.0 #brctl addif vz0 veth102.0

Paramètres réseaux

// pour la machine hôte #dhclient vzo // pour les machines clientes #vzctl enter 101 #dhclient eth0



3.3.3 Sauvegarde des VE

Dans le cas des entreprises, nous avons prévu un script de sauvegarde

Sur la machine client ou serveur de production (openvz.ec2lt.sn) Installation du serveur SSH

#apt-get install openssh-client

Génération des clés publique et privée

#ssh-keygen –t rsa // En réponse à cette commande, on vous demandera successivement de renseigner le dossier pour sauver les clefs, et une passphrase. Appuyez à chaque fois sur « Entrée »

Déploiement de la clé privé

NB : les clés publique (id_rsa.pub) [A COPIER SUR LE SERVEUR] et privée (id_rsa) seront

créées dans le fichier caché « $HOME/.ssh »

# cd $HOME/.ssh

#mkdir identity

# mv id_rsa identity/

Sur le serveur de sauvegarde (save.ec2lt.sn) Installation du serveur SSH

#aptitude install openssh-server

Déploiement de la clé publique (id_rsa.pub) : A récupérer sur le client par clé

USB ou SSH ...

# cd $HOME/.ssh //renommer la clé publique #mv id_rsa.pub authorized_keys



//veiller a ce que le paramètre "AuthorizedKeysFile" dans le fichier "/etc/ssh/sshd_config" porte le chemin du fichier authorized_keys //mettre le paramètre "PasswordAuthentication" à "no" pour désactiver la demande mot de passe //activer l’authentification par clé avec le paramètre "PubKeyAuthentication=yes"

Voir les logs en cas de problème

#tail -f /var/log/auth.log

Déployer le script sous le serveur de sauvegarde

#!/bin/bash IP_SERVER_BACKUP=192.168.0.21 ### ADAPTER LES 2 VARIABLES CI DESSOUS A VOTRE SYSTEME ### FILE_BACKUP="/vz/private" #dossier à sauvegarde DEST_BACKUP="/home/backup" #dossier de destination des sauvegardes #file_ctrl contient la liste des backups CONTROLE=''$DEST_BACKUP'/file_ctrl' a=$(date '+%Y_%m_%d') b='_backup' c=$a$b #nom du fichier sera sous la forme AAAA_MM_JJ_backup LAST_LINE=$(tail -1 $CONTROLE) if [ "$c" != "$LAST_LINE" ]; then echo $c >> $CONTROLE fi # compter le nombre de ligne NBRE_LINE=$(cat backup/file_ctrl | wc -l) rsync -r --delete $IP_SERVER_BACKUP:$FILE_BACKUP $DEST_BACKUP/$c #suppression du dernier backup if [ $NBRE_LINE -gt 3 ]; then FILE_DEL=$(head -1 backup/file_ctrl) DEL=''$DEST_BACKUP$FILE_DEL'' rm -rf $DEL sed -i '/'$FILE_DEL'/d' $CONTROLE fi



Enfin nous allons rendre périodique l’exécution du script de sauvegarde tous les jours à

00h.

#crontab –e * 24 * * * bash /home/backup.sh

3.4 LTSP

LTSP ou Linux Terminal Server Project va permettre à plusieurs personnes d’exploiter

simultanément les ressources d’un seul ordinateur. Cela est réalisé par la mise en place d'un

réseau informatique composé d'un serveur sous LINUX, d’un serveur Windows et de clients

légers.

3.4.1 Les différents modes d’environnement du LTSP

Il y a trois modes d'environnement possibles sur LTSP :

- Le mode classique,

- Le mode localapp

- Le mode autonome

Le mode classique

Le mode «classique» est celui par défaut, c'est un environnement minimaliste qui ne

contient que les fichiers ou exécutables nécessaires au fonctionnement du client. Dans ce mode,

toutes les applications fonctionnent sur le serveur.

Le mode localapp

Ce mode consiste à améliorer le mode «classique» en installant dans l'environnement des

applications complémentaires qui tourneront sur le client pour alléger le serveur. Il permet de

diminuer les besoins en ressources du serveur.



Le mode autonome

Le mode autonome, consiste à faire fonctionner l'ensemble des applications sur le client.

C'est le cas le plus intéressant car les ressources du serveur sont moins importantes même avec

un grand nombre de clients connectés.

3.4.2 Sous linux

3.4.2.1 Fonctionnement

LTSP permet de transformer un PC en client léger. Le client démarre en chargeant par

TFTP une image système Linux minimale disponible sur le serveur LTSP. Le système qui tourne

sur le client léger permet ensuite d'établir une connexion X vers un serveur LTSP. Par défaut, les

connexions utilisent LDM, qui est un gestionnaire de session X. Il est également possible

d'utiliser la connexion XDMCP. Le client monte ensuite une arborescence de répertoires depuis

le serveur LTSP qui l'exporte par NFS (filesystem) et le charge. A ce stade le client pourra

accéder aux applications via XDMCP. Le PC tourne donc avec un filesystem distant, monté par

NFS.

L'ensemble de la procédure de démarrage du client léger prend la forme suivante :

Requête DHCP : adresse IP, adresse du serveur TFTP, nom des fichiers à télécharger

Requête TFTP : téléchargement du noyau, d'un initrd et d'un fichier lts.conf

Le CL boote sur l'initrd

Montage par NFS ou NBD d'une image de /

Le CL effectue un chroot sur le nouveau /

Le CL lance un gestionnaire de connexion LDM ou XDMCP

L'utilisateur se connecte au serveur de sessions interactives

3.4.2.2 Implémentation

Installation des paquets

#apt-get install ltsp-server-standalone openssh-server #ltsp-build-client // ltsp-build-client est un script qui se chargera de configurer dhcpd, tftpd, et nfs



Configuration des clients linux

#vim /etc/ltsp/dhcp.conf

Configuration des clients Windows

#vim /var/lib/tftpboot/ltsp/i386/lts.conf [Adresse MAC_Machine client windows] screen_07 = xfreerdp rdp_server= 192.168.0.20

Configuration et démarrage du client linux

Il suffira d’activer la fonction de PXE dans le bios. Mais dans notre cas nous avons utilisé

virtualbox comme client test. La figure ci-dessous montre la configuration du client.

Cocher l’option ‘’Réseau’’

Figure 3.4 : Configuration du client sans disque



Figure 3.5 : Démarrage du client linux étape 1





3.4.3 Sous Windows

3.4.3.1 Etapes de montée de la session

3.4.3.1.1 Connexion Initiation

L’échange de ces paquets X.224 permet d’initier la connexion. Tous les paquets échangés

par la suite seront encapsulés dans des paquets de données X.224. Le premier paquet contient la

liste des protocoles de sécurité supportés par le client, sous la forme d’un champ de bits,

autorisant le choix des flags suivants :

- PROTOCOL_RDP : Standard RDP Security

- PROTOCOL_SSL : TLS 1.0

- PROTOCOL_HYBRID : CredSSP

La réponse du serveur contient sa décision sur le mécanisme sélectionné (Standard ou

Enhanced RDP Security). Dans ce cadre :



si Enhanced RDP Security a été sélectionné (CredSSP ou TLS), une session TLS est

montée entre le client et le serveur, et les messages suivants sont donc échangés sous la

protection de cette session

si Standard RDP Security a été sélectionné, les échanges continuent en clair jusqu’à la

fin de la négociation.

3.4.3.2 Basic Settings Exchange

Ces deux paquets T.125 sont encodés en ASN.1. Les données utilisateurs transportées

dans le premier paquet (émis par le client) contiennent notamment des informations sur la

machine cliente (taille de l’écran, type de clavier, layout, etc). Le protocole de sécurité

sélectionné précédemment par le serveur y est également répété (Standard RDP Security ou

Enhanced RDP Security).

Par ailleurs, les données utilisateurs transportées par le paquet client incluent également,

via le champ encryptionMethod, les combinaisons d’algorithmes et de tailles de clés supportées

par le client pour le mode Standard RDP Security :

- clés de 40 bits pour RC4 et le MAC;



- triple DES avec clés de 168 bits et HMAC-SHA1 (Mode FIPS).

Le choix de la méthode de protection (algorithme et taille de clés) sélectionnée par le

serveur dans le second paquet dépend de sa configuration (niveau low, client-compatible, high

ou FIPS). Ce paquet intègre également pour le mode Standard RDP Security le nonce serveur (32

octets, émis en clair) à utiliser pour la dérivation de clé, ainsi que la clé publique “signée” du

serveur. Cette clé sera utilisée par le client à l’étape 3.4.3.4 pour la transmission chiffrée de son

nonce (32 octets), participant également à la dérivation de clé.



3.4.3.3 Channel Connection

Les 3 premiers paquets sont associés au protocole T.125. Chaque échange de MCS

Channel Join Request PDU et MCS Channel Join Confirm PDU permet au client RDP de

l’utilisateur de joindre les canaux virtuels de son choix. Suite à cette étape, l’ensemble des

messages échangés entre le client et le serveur sont des MCS Send Data Request (pour le client)

et MCS Send Data Indication (pour le serveur). Pour le moment, si le Standard RDP Security a

été choisi, les PDU échangées ne sont toujours pas protégées.

3.4.3.4 RDP Security Commencement

Ce paquet transmis par le client contient son nonce (32 octets) chiffré avec la clé

publique transmise précédemment par le serveur. Après la transmission de ce paquet, les

échanges sont protégés avec les clés dérivées des nonces. La sécurité de la session dépend donc

de l’impossibilité pour un attaquant de remonter au nonce transmis chiffré par le client. Cette

sécurité est donc directement liée à la taille de clé RSA utilisée (512 bits jusqu’à Windows

Server 2003, 2048 bits pour les versions plus récentes), et indirectement à l’authentification.



3.4.3.5 Secure Settings Exchange

Ce paquet est donc le premier paquet chiffré. Le client y passe des informations comme

le nom de l’utilisateur, le domaine. Une option du client RDP permet de retenir le mot de passe;

dans ce cas, celui ci transite dans ce paquet pour l’authentification de l’utilisateur sur le système

distant, pour permettre l’autologon.

3.4.3.6 Licensing

Ce message est utilisé pour le transfert d’une licence du serveur au client, dans le cas où

RDP est utilisé avec un serveur de licence.

3.4.3.7 Capabilities Exchange

Cet échange permet au client et au serveur de se synchroniser sur les fonctionnalités

supportées (taille de buffer de compression MPPC, niveau de support GDI+, etc). Après cet

échange, le client peut commencer à émettre vers le serveur des entrées souris et clavier.



3.4.3.8 Connection Finalization

Ces échanges permettent notamment la synchronisation graphique. Après réception du

paquet Font List PDU, le serveur peut commencer l’émission de données graphiques au client.

3.4.4 Implémentation

Configuration du serveur Windows

Démarrer -> Propriété sur Ordinateur -> Utilisation à distance et cocher "autoriser les

utilisateurs à se connecter à distance"



Figure 3.8 : Configuration du serveur Windows 2003

Configuration et démarrage des clients Windows - Configuration (voir figure 11) - Démarrage du client Windows

Figure 3.9 : Démarrage du client Windows étape 1



Figure 3.10 : Démarrage du client Windows étape 2



Conclusion

La qualité de la formation dans le domaine des TIC est une question préoccupante, tant

pour les écoles de formations, que pour les entreprises. Autrement dit, les étudiants en fin de

formation doivent acquérir une bonne formation sur le plan théorique que pratique. Alors que, la

plupart des écoles de formations et des universités africaines, pour faute de moyens ne joignent

pas suffisamment la pratique à la théorie. Cela dit, les étudiants ne se retrouvent pas en entreprise

car n’ayant pas manipulé assez les outils informatiques et télécoms au cours de leur formation.

En plus du manque de moyen financier, certaines universités éprouvent la volonté de payer les

équipements malgré leurs chertés, mais comme nous sommes dans un milieu d’apprentissage les

étudiants font des manipulations qui, de bonne ou de mauvaise fois peuvent endommager un

équipement cher. Alors les décideurs se demandent s’il faut faire des TP que dans les classes

supérieures, du faite qu’à ce stade les étudiants sont murs. Pour faire face à ces problèmes, nous

avons pensés à la virtualisation qui va permettre à un ensemble d’apprenant, lors des TP,

d’utiliser les templates contenant les prérequis pour éviter les détails, d’aller à l’essentiel,

d’exploiter judicieusement la capacité des serveurs … d’où l’intituler de notre thème :

conception d’une plate-forme de services à la demande.

Pour mener à bien ce travail nous avons fait une étude des différentes solutions de

virtualisation avant de porter notre choix technologique. Cette démarche, nous a permis de

choisir OpenVZ. Les raisons qui nous ont poussées à choisir OpenVZ sont nombreuses. On peut

citer : la disponibilité de la documentation, la licence qui est sous GNU GPL, la facilité

d’utilisation, sa performance en terme de mémoire etc.

Avec la disponibilité des personnels de l’entreprise d’accueil (RTN) qui nous ont

accompagnés tout au long de ce projet, nous sommes arrivés à des résultats concluants. Cela dit,

ces résultats nous ont permis d’atteindre les objectifs suivants :

- Mise à disposition de Chaque étudiant, de plusieurs VE lui permettant de se familiariser

avec les différentes distributions de système d’exploitation

- Réduction des coûts d’achat des équipements

- Amélioration de la sécurité



- Exploitation judicieuse des capacités des machines ou des serveurs.

- Rationalisation de l’évolution des besoins matériels, en empilant plusieurs serveurs sur

une machine physique tout en augmentant la disponibilité de l’ensemble

- Conception de divers templates pour simplifier l’administration et le montage d’un

environnement de test

Nous noterons que la virtualisation a des avantages mais aussi des inconvénients.

Autrement dit une mauvaise gestion de projet de virtualisation et la non prise en compte de

certains paramètres pourraient ralentir l’activité de l’entreprise et même engendrer tout un lot de

problèmes. En matière de sécurité par exemple, Les risques dans un environnement virtualisé

peuvent être bien pires.

Enfin Comme pour de nombreux types de technologie, la virtualisation est un outil très

puissant. Si elle est utilisée correctement, les entreprises bénéficieront de plusieurs avantages

cités ci-dessus. Alors pour une structure qui veut implémenter une solution de virtualisation, nous

lui conseillons OpenVZ.



Bibliographie

[B1] Secrétariat général de la défense et de la sécurité nationale / agence nationale de la sécurité

des systèmes d’information, Problématiques de sécurité associées à la virtualisation des systèmes

d’information, 1343/ANSSI, Paris, 2012

[B2] SOLUCON, virtualisation et cloud computing, synthèses solucom 37, France, 2010

[B3] Antoine Benekemoun / Romain Hinfray, AC - étude de la virtualisation et du

fonctionnement de la solution libre xen, France, 2008

[B4] M. LIbes / T. Dotes, virtualisation avec openvz, journees thematiques SIARS, 2009

[B5] mehdi nabi - romain quarre, ‘’Les enjeux économiques de la virtualisation’’, Mémoire de

recherche, Ecole supérieure de génie informatique (esgi), France, 08,2009

[B6] lucas bonnet – bearstech, Etat de l’art des solutions libres de virtualisation pour une petite

entreprise, France

[B7] YAKETE-OULIKETTEGloria Gihanne Agnes, ’’virtualisation d’un réseau informatique

avec netkit’’, Mémoire de fin de cycle licence asrall, Ecole centrale des logiciels libres et des

télécommunications, SENEGAL, 2012

[B8] kirill kolyshkin, Virtualization in linux, 2006

[B9] CHABANI MOHAMED HADI / JESUS PEREIRA RIVAS / DJEDDI SAMIR / BEN

YEMNA Mohamed Ramzi, Virtualisation : Intérêts et état technologique, France

[B10] alain devarieux, virtualisation de serveur : Solutions open source, 2009

[B11] nicolas fillot / julien vaubourg ,La virtualization, Exposé technique, licence pro.

A.S.R.A.L.L., IUT Charlemagne de NANCY, 2009

[B12] jacquelin charbonnel / philippe depouilly / françois ducrot - zouhir hafidi, introduction

aux stations de travail diskless, Preparation au TP des Journees Matthrice, Angers, 2009

[B13] pierre nerzic iut de lannion, stations sans disques sous linux, GSR-Module UE142, 2005

[B14] Rigo,gideon romm, ltspv5 on ubuntu, Symbio Technologie, 2009

[B15] Aurélien Bordes / Arnaud Ebalard / and Raphaël, Sécurité de RDP



[B16] Le Bris Carole Breton Clément, Mise en place d'un système de virtualisation, Projet

tuteuré, 2012

[B17] François Ducrot, Mise en place de clients légers sous LTSP 5, Université d'Angers



Webographie

[W1] http://systeme.developpez.com/tutoriels/virtualisation/livre-blanc-lucas-bonnet/#LI

(Consulter le 05 juin 2013)

[W 2] http://www.guvirt.org/dsi-et-architecture/33-architecture/25-virtualisation-et-securite-du-

si-les-pieges-a-eviter.html (Consulter 05 juin 2013)

[W3] http://docs.oracle.com/cd/E26919_01/html/E25832/gfkbw.html (Consulter le 07 juin 2013)

[W4] http://fr.wikipedia.org/wiki/Xen#Pr.C3.A9sentation (Consulter le 10 juin 2013)

[W5] http://fr.wikipedia.org/wiki/Hyperviseur#Types_d.27hyperviseurs (Consulter le 20 juin

2013)

[W6] http://fr.wikipedia.org/wiki/OpenVZ#Noyau (Consulter le 02 juillet 2013)

[W7] http://openvz.org/Quick_installation#Requirements (Consulter le 20 juillet 2013)

[W8] http://doc.mandriva.com/fr/mes5/Enterprise-Server-Manual-FR.html/CS-install-pxe.html

(Consulter le 20 juillet 2013)

[W9] http://www.freebsd.org/doc/fr_FR.ISO8859-1/books/handbook/network-diskless.html

(Consulter le 20 juillet 2013)

[W10] http://wiki.ltsp.org/wiki/LTSPedia (Consulter le 25 juillet 2013)

[W11] http://wiki.ltsp.org/wiki/Configuration#Server (Consulter le 25 juillet 2013)

[W12] http://dmesg.fr/categorie-installation/103-dossier-installer-serveur-ltsp-avec-debian-gnu-

linux-6-squeeze (Consulter le 25 juillet 2013)

[W13] http://fr.wikipedia.org/wiki/Linux_Terminal_Server_Project#Utilisation (Consulter le 03

août 2013)

[W14] http://www.galoula.net/fr/GaloulaPXE/Windows/ (Consulter le 04 août 2013)

[W15] http://doc.ubuntu-fr.org/ltsp (Consulter le 04 août 2013)



[W16] http://doc.ubuntu-fr.org/ltsp_version_5.x (Consulter le 09 août 2013)

[W17] http://docs.oracle.com/cd/E26919_01/html/E25832/gfkbw.html# (Consulter le 09 août

2013)

[W18] http://www.ovh.com/fr/serveurs_dedies/ (Consulter le 10 août 2013)



Annexes Annexe 1 : configuration du DNS

#vim /etc/bind/ec2lt.ec2lt.sn ec2lt.sn. IN SOA ec2lt.ec2lt.sn. root.ec2lt.sn. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; ec2lt.ec2lt.sn. IN NS ec2lt.ec2lt.sn. serveur1.ec2lt.sn. IN A 192.1680.1. serveur2. ec2lt.sn. IN A 192.168.0.1 vim /etc/bind/named.conf.default-zones zone "ec2lt.sn" { type master; file "/etc/bind/direct.ec2lt.sn"; };

Annexe 2 : Configuration du serveur proxy (sreveur2)

<VirtualHost 192.168.0.1:80> ServerAdmin root@ ec2lt.sn ProxyRequests off ServerName serveur2.ec2lt.sn <Proxy *> order deny,allow allow from all </Proxy> ProxyPass / http://172.16.0.2/ ProxyPassReverse / http://172.16.0.2/ DocumentRoot /var/www <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny



allow from all </Directory> ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ <Directory "/usr/lib/cgi-bin"> AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>



Table des matières DEDICACES .............................................................................................................................. I

REMERCIEMENT .................................................................................................................... II

SOMMAIRE ............................................................................................................................. III

SIGLES ET ABREVIATIONS .................................................................................................. V

TABLE DES FIGURES ........................................................................................................... VI

TABLE DES TABLEAUX ..................................................................................................... VII

AVANT PROPOS.................................................................................................................. VIII

INTRODUCTION ......................................................................................................................1

CHAPITRE 1 : PRESENTATION GENERALE .........................................................................2

1.1. Historique .....................................................................................................................3

1.2. Présentation de l’entreprise Réseaux et Techniques Numériques ...................................3

1.2.1. Mission de RTN .....................................................................................................4

1.2.2. Domaine d’activités ..............................................................................................4

1.2.3. Organigramme .......................................................................................................7

1.3. Présentation du sujet .....................................................................................................8

1.3.1. Contexte du sujet ...................................................................................................8

1.3.2. Problématique ........................................................................................................8

1.3.3. Concept de service à la demande ............................................................................9

1.3.4. Objectifs .............................................................................................................. 10

CHAPITRE 2 : VIRTUALISATION ET STATION SANS DISQUE ........................................ 11

2.1 Avantages de la virtualisation...................................................................................... 12

2.1.1 Réduction des coûts de matériel informatique ...................................................... 12

2.1.2 Réduction des coûts immobiliers .......................................................................... 12

2.1.3 Electricité et climatisation .................................................................................... 12

2.1.4 Rapidité pour déployer un nouveau Serveur ........................................................ 13

2.1.5 Portabilité ............................................................................................................ 13

2.1.6 Recouvrement suite à un désastre ......................................................................... 13



2.1.7 Environnement de test .......................................................................................... 13

2.1.8 Ecologie ............................................................................................................... 14

2.2 Sécurité ....................................................................................................................... 14

2.2.1 Intérêt de la virtualisation ..................................................................................... 14

2.2.2 Risques de la virtualisation................................................................................... 15

2.3 Types de virtualisation ................................................................................................ 16

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

2.3.2 La virtualisation des postes de travail ................................................................... 17

2.3.3 La virtualisation d’application .............................................................................. 17

2.3.4 La virtualisation de réseau .................................................................................... 18

2.3.5 Choix technologique ............................................................................................ 18

2.4 La virtualisation de serveurs ........................................................................................ 19

2.4.1 Etude comparative des différentes techniques de virtualisation de serveurs .......... 19

2.4.1.1 La virtualisation totale ..................................................................................... 19

2.4.1.2 L’hyperviseur et la paravirtualisation ................................................................ 20

2.4.1.3 La virtualisation assistée par le matériel ............................................................ 22

2.4.1.4 Le cloisonnement ou la virtualisation au niveau du système d'exploitation ....... 22

2.4.2 Choix technologique ............................................................................................ 23

2.5 Station sans disque ...................................................................................................... 29

2.5.1 Application pre-boot eXecution Environment ...................................................... 29

2.5.2 Fonctionnement ................................................................................................... 29

2.5.3 Avantages ............................................................................................................ 31

2.5.4 Inconvénient ........................................................................................................ 31

2.5.5 Choix du seveur de clients légers ......................................................................... 31

Chapitre 3 : Etude et mise en place des solutions proposées...................................................... 34

3.1 Coût de la solution ...................................................................................................... 35

Le choix d’OpenVZ et de LTSP nous épargne des coûts de licences qu’on devrait payer avec des solutions propriétaires. ..................................................................................................... 35

Le tableau ci-dessous nous présente une facture pro forma de la solution proposée. ............... 35

3.2 Architecture de la solution proposée ............................................................................ 36

3.3 Openvz ....................................................................................................................... 37



3.3.1 Principe de fonctionnement d’Openvz .................................................................. 37

3.3.2 Implémentation de la solution .............................................................................. 38

3.3.3 Sauvegarde des VE .............................................................................................. 43

3.4 LTSP .......................................................................................................................... 45

3.4.1 Les différents modes d’environnement du LTSP ...................................................... 45

3.4.2 Sous linux ............................................................................................................ 46

3.4.3 Sous Windows ..................................................................................................... 49

3.4.4 Implémentation .................................................................................................... 53

Conclusion ................................................................................................................................ 56

Bibliographie ............................................................................................................................ 58

Webographie ............................................................................................................................. 60

Annexes .................................................................................................................................... 62

Table des matières ..................................................................................................................... 64

Documents

Mémoire Marc AMOUZOUN Version Final