Virtualisation Réseau

1

Centre d’Enseignement et de Recherche en Informatique

Virtualisation Réseau

Rapport final du projet

Réalisé par : Encadré par :

HAMIDANE Azz el arab Pr. EL AZOUZI Rachid

EL HADIOUI Zakaria

LONCA Alexandre

Année universitaire 2014 - 2015

2

Sommaire

I. CHAPITRE 1: Présentation de projet... 4

Avant-propos ... 4

Définition d’une infrastructure de virtualisation de poste de travail ... 5

1) Définition : ... 5

2) Principe de fonctionnement du VDI : ... 5

3) Description technique d’une architecture VDI (type bureau hébergé 1 pour n) ... 6

II. CHAPITRE 2: Cahier des charges ... 9

1) Représentation du groupe du projet numéro 3 ... 9

2) Objectifs... 10

3) Périmètre ... 11

4) Parties prenantes ... 11

5) Contraintes ... 12

6) Exigences ... 12

III. CHAPITRE 3 : Réalisation Technique... 14

1. Présentation de la solution KVM ... 14

2. Gestion et configuration du KVM ... 15

3. Système d'authentification basé sur l'annuaire LDAP et PAM ... 15

4. Authentification PAM Linux... 16

5. Présentation de la solution « kimchi-project » ... 18

IV. CHAPITRE 4 : Organisation du projet ... 25

1) Ressources utilisées : ... 25

Smart Organiser : ... 25

Drop Box : ... 25

Site web : ... 25

2) Rencontres et réunions ... 26

Cadence des réunions : ... 26

Les aspects évoqués : ... 26

3) Planning et programmation des tâches ... 26

Planning: ... 26

4) Problèmes Rencontrés ... 27

Conclusion ... 28

Annexes ... 29

3

Introduction

Lors du Master 1 nous devons conduire un projet en deux étapes, une par semestre.

Notre groupe à choisie le sujet de la Virtualisation, car il nous semble évident que cela représente une technologie d'avenir.

En effet dans le monde de l'informatique professionnelle, tout le monde parle de virtualisation. Les avantages à en tirer sont énormes en terme d'économie d'énergie mais aussi de matériel (un seul serveur physique peut faire tourner plusieurs serveurs virtuels) ce qui entraîne des économies financières qui sont toujours les bienvenues pour les entreprises.

Nous avons donc dans un premier temps étudié les technologies qui sous tendent la virtualisation. Il était important pour nous de bien comprendre notre sujet. Nous avons découvert qu’ils existent plusieurs types (ou niveaux) de virtualisation.

En début de semestre I, notre tuteur (Mr EL AZZOUZI) nous a présenté une problématique autour de laquelle nous devions recentrer nos recherches.

Lors de différents rencontres qu’nous avons réalisé au cours des deux semestres il nous a guidé tant sur nos études de l'existant que sur les méthodes et buts de nos recherches ainsi que les différentes solutions utilisées.

Donc le plus gros de notre travail a été de trouver et mettre en place une solution open source qui pourrai s'approcher et donc nous aider dans notre problématique.

Nous ne nous somme pas contenté des solutions préexistantes et avons examiné les technologies parallèles à la virtualisation. Des technologies qui nous permettrons sans aucun doute d'arriver à nos fins !

Finalement il a été temps pour nous d’implémenter une solution qui répond aux exigences et aux besoins définis dans le cahier de charge.

4

I. CHAPITRE 1: Présentation de projet

Avant-propos

La virtualisation consiste à gérer de façon centralisée, un ensemble de ressources

partagées (Processeur, mémoire, disque dur, cartes réseau, vidéo,…) via une interface unique.

Grâce à des techniques matérielles ou logicielles, plusieurs systèmes d’exploitation et applications fonctionnent sur un seul ordinateur/serveur comme s’ils fonctionnaient sur des ordinateurs distincts.

La virtualisation, sous ses différentes formes, est une technologie en plein essor : les deux leaders du marché des logiciels de virtualisation et des infrastructures de Cloud Computing, Citrix et VMware, ont réalisé un chiffre d’affaires trimestriel de 673 et 675 millions de dollars

respectivement. Dans la plupart des entreprises, la virtualisation permet de réduire le coût de gestion d’un parc informatique toute en diminuant les frais de maintenance et de pilotage, qui selon Microsoft, représente la partie de dépense majeur dans le coût de gestion d’un parc informatique dans une organisation :

5

Définition d’une infrastructure de virtualisation de poste de travail

1) Définition :

La virtualisation du poste de travail ou infrastructure de bureau virtuel, ou encore Virtual Desktop infrastructure (VDI) en anglais, est une pratique consistant, à héberger un système d’exploitation dans une machine virtuelle en cours d’exécution sur un serveur centralisé ou distant. Cette technique permet à un utilisateur d’accéder à l’intégralité de ses programmes, applications et données depuis n’importe quel poste client utilisé.

2) Principe de fonctionnement du VDI :

Plusieurs MVs équipées d’un système d’exploitation (Windows ou Linux), d’applications, de données s’exécutent sur un serveur particulier appelé « hyperviseur». Lorsqu’un utilisateur allume son ordinateur, il se connecte à l’une de ces machines et y ouvre une session.

L’affichage et le son de cette MV sont transférés sur le poste physique par l’intermédiaire du réseau. Suivant l’éditeur choisi, un protocole de déport d’affichage est utilisé pour accéder à la machine distante :

 RDP (Remote Desktop Protocol) pour Microsoft

 ICA (Independant Computing Architecture) pour Citrix

 PCoIP( PC over IP) pour VMware

 SPICE(Simple Protocol for Independent Computing Environnements) pour Red Hat Les leaders dans ce marché sont Citrix et VMware.

Les deux types de virtualisation de poste de travail les plus répandus sont:

 Session partagé : ou shared desktop (en anglais) Plus ancien appelé Server Based Computing, permet de fournir un bureau virtuel depuis un serveur Remote Desktop Services (RDS) ou un serveur XenApp. Ce type de virtualisation consiste à virtualiser les applications et non pas l’ensemble du système d’exploitation, permet aussi de répondre aux problèmes d’incompatibilité entre application et un système d’exploitation

; car l’utilisateur visualise et utilise sur son poste une image des applications réellement exécutées sur un serveur distant, et le système d’exploitation, lui tourne toujours sur le poste client. Lorsqu’un utilisateur demande une connexion, une session lui est assignée.

Cette session aura récupéré les informations du profile (documents, applications…) de l’utilisation afin de renvoyer ces données.

Avec ce type d’infrastructure, l’utilisateur ne retrouvera jamais les personnalisations qu’il aurait pu effectuer pendant sa connexion. En général les documents sont enregistrés sur un disque attaché (différent de :C\) à son profile qui le suit partout. Ce système permet donc de rendre disponible des applications diverses sans avoir à les installer dans chacun des postes clients qui le nécessitent.

L’avantage ici est que les mises à jour sont plus facilement applicables car appliqué sur le serveur. L’inconvénient est la synchronisation de tous les profiles entre les connexions, car à chaque connexion les profiles doivent être récupérer sur le serveur et chargé et à la

6 déconnexion, ils doivent être mise à jour et renvoyé vers le serveur. Qui dit session partagé dit partage de ressources, ce qui pourrait impacter le travail des utilisateurs suivant quel type d’application est utilisée.

 Bureau hébergé :ou Hosted Virtual desktop (en anglais) Dans ce cas, chaque utilisateur possède une MV attitré.

Ce type de virtualisation a deux variantes :

 Dans une première variante toutes les MV partageront le même disque dur, on parlera ici de modèle de provisioning ( 1 pour n). Ce modèle est souvent utilisé pour des utilisateurs standards avec les applications bureautiques et peu d’applications métiers, comme par exemple dans des centres de formation ou des écoles, car à la fin de l’utilisation d’une MV celle-ci sera détruite en quelques secondes.

 Dans une autre variante chaque MV possèdera son propre disque dur, On peut parler ici de modèle de provisioning ( 1 pour 1), dans ce cas toutes les personnalisations et les configurations que l’utilisateur fera pendant sa connexion à cette MV vont être gardées. Il retrouvera tout son univers (documents, fond d’écran, raccourcis, etc…) Les inconvénients ici sont, la taille du stockage qui devra être suffisamment grande pour contenir toutes les modifications au fur et à mesure, ce qui pourrait devenir un gros budget, et les mises à jour devront être appliquées à chaque MV ce qui pourrait prendre beaucoup de temps.

L’avantage est que l’utilisateur retrouvera toujours son bureau comme il l’a laissé.

3) Description technique d’une architecture VDI (type bureau hébergé 1 pour n)

Figure 2 – Exemple d’architecture VDI

7 Côté clients

Les postes clients (il pourrait s’agir d’un client léger, d’un ordinateur, d’une tablette…) servent uniquement à se connecter aux postes virtuels et à en récupérer l’affichage.

Les performances du poste physique sont donc presque sans rapport avec les performances constatées par l’utilisateur, car le VDI permet de dissocier le bureau virtuel et la machine physique. En effet le BV créé englobe les capacités du matériel et des logiciels du serveur utilisé, et le poste physique permet de visualiser le bureau.

Côté Broker

Lorsque plusieurs utilisateurs veulent obtenir une connexion à une MV, il faut pouvoir gérer leurs requêtes, les orienter vers une MV allumée et disponible, et au besoin en allumer de nouvelles ; C’est le rôle du « connexion Broker ». Les utilisateurs ne peuvent pas allumer ou éteindre à distance les MVs, ils peuvent seulement réclamer une connexion à un BV auprès du broker. Ce dernier intègre donc des fonctions pour démarrer ou éteindre automatiquement des

MVs.

Le nombre de MVs allumées et inactives peut être variable en fonction par exemple de l’heure de la journée, du jour de semaine, du nombre d’utilisateurs, des besoins d’un domaine

d’activé, Les machines excédentaires sont éteintes par le broker pour économiser de l’énergie.

Les machines virtuelles :

Cas 1 pour n:(une VM model pour tout les autre VM):

Dans le modèle de provisioning (1 pour n), les MV partagent toutes le même disque dur, ce qu’on appelle généralement un clonage lié, il s’agit de faire copie du disque dur de la machine modèle (OS, mises à jour, éventuellement des applications déjà installées) et de l’utiliser comme leur disque dur local pour des machines filles, les écritures sont faites dans un cache individuel.

Les mises à jour s’effectuent donc de manière centralisée et sont déployées en quelques

dizaines de minutes sur tous les postes.

Ces MVs sont stockées sous forme de fichiers, ce qui rend la gestion plus simple(le fichier peut être copié, sauvegardé ou supprimé en quelques minutes). Ces machines sont créées et stockées sur l’hyperviseur.

Cas 1 pour 1:

Dans le modèle de provisioning (1 pour 1), chaque MV possède son disque dur, on fera ici un simple clone (une copie du disque dur de la machine modèle). Les mises à jour sont ensuite effectuées sur chacune des MV.

8 Avantages :

Les principaux avantages du VDI sont :

- Création simple et rapide de nouveaux postes de travail, en faisant un clone - Facilité de déploiement de nouvelles applications

- L’utilisateur n’est plus dépendant de son poste physique et peut se connecter à son bureau depuis différents terminaux, ce qui peut s’avérer très pratique pour les utilisateurs nomades.

-Facilité de mise à jour des postes

-Meilleure sécurisation des données car elles sont centralisées.

Inconvénients :

Les principaux inconvénients du VDI sont :

- Complexité et coûts élevés du déploiement et la gestion suivant le projet et la solution VDI choisi

-Risque potentiel pour la sécurité si le réseau n’est pas correctement géré7 - Pour certains protocoles d’affichage, des limites constatés de certains flux, en particulier la vidéo en cas de faiblesse de bande passante.

- Les coûts de stockage peuvent être très élevés .

Au vu des besoins exprimés par notre tuteur MR El Azzouzi Rachid et la définition d'un VDI, la mise en place d’une telle infrastructure pour répondre aux problématiques rencontrées dans les salles réseaux, s’avère être une solution tout à fait adaptée.

Il existe des solutions connu sur le marché tel que :

 XenDesktop et XenApp, produit par Citrix.

 VMware View produit par VMware .

 RDSH (Remote Desktop Session Host) produit par microsoft .

 Red Hat Enterprise Virtualization (RHEV) produit par Red Hat .

 Oracle Virtual Desktop Infrastructure produit par Oracle .

 Neocoretech Desktop Virtualisation produit par Neocoretech.

il ya d'autre solutions souvent commerciale avec un coût assez élevé.

La solution recherchée dans notre projet doit être gratuite , c’est la raison pour laquelle nos recherches ont été orienté Open Source.

9

II. CHAPITRE 2: Cahier des charges

1) Représentation du groupe du projet numéro 3

HAMIDANE Azz El Arab: 22 ans, étudiant en informatique au CERI d’Avignon.

M1 RISM

azz-el-arab.hamidane@alumni.univ-avignon.fr

Alexandre LONCA : 34 ans, étudiant en informatique au CERI d’Avignon.

M1RISM

alexandre.lonca@alumni.univ-avignon.fr

Zakaria EL HADIOUI : 22 ans, étudiant en informatique au CERI d’Avignon.

M1RISM

zakaria.el-hadioui@alumni.univ-avignon.fr

10

2) Objectifs

Le projet en Master 1 a évidement pour but dans un premier temps de donner une première approche du travail en mode projet. C'est à dire un travail en groupe avec des contraintes et un référent de type client qui exprime des besoins.

Le projet «Virtualisation» quand à lui vise à étudier, comprendre, trouver et surtout créer une solution de virtualisation pour une salle informatique type du CERI, contenant une vingtaine de PCs.

Ces PCs devrons au démarrage permettre aux élèves :

● De s'authentifier.

● De choisir une machine virtuelle (VM) parmi une liste pertinente.

● De charger la dite VM.

● D'utiliser le système d'exploitation qui en résultera.

● De sauvegarder leur travail ou au contraire de l’effacer.

L'administration et la création des VMs sera dans cette solution seulement accessibles aux professeurs et chargés de TPs, le tout en ligne de commande pour facilité le travail

(notamment en terme de création de la solution).

Les administrateurs devrons pouvoir :

● S'authentifier.

● Créer les VMs adéquates pour les TPs.

● Charger ces mêmes VMs pour éventuellement leur ajouter des logiciels ou configurations particulières.

● Sauvegarder et stocker ces VMs.

● Effacer ces VMs.

Les avantages de se projet sont multiples :

● Les ordinateurs sont utilisable de suite avec les logiciels nécessaires au bon déroulement des travaux pratiques.

● A la moindre fausse manipulation le système d'exploitation peut-être rechargé sans grand effort et sans temps d'attente excessif pendant la session même.

● Les salles informatiques sont utilisée par de nombres groupes d'élèves qui doivent travailler sur des systèmes d'exploitations et des logiciels différents avec des rotations de l'ordre d'au maximum une fois par heure et demi. Avec cette solution les salles gagnent en polyvalence.

● Les groupes d'élèves qui utilisent une salle implémentant cette solution n'ont plus à s’inquiéter des configurations parfois farfelus laissés par les groupes précédents.

11

3) Périmètre

● Cible : Étudiants et aussi chargés de TP

● Contexte : le projet doit amélioré les sessions de travaux pratiques (exemple :TPs d'administration de système d'exploitation, ou de réseaux) dans les salles

informatiques.

● Enjeux :

○ Facilité les Tps, chaque image peut être créé avec les logiciels adéquates ou les configurations adapté au TP.

○ Sécurisé les machines utilisés, au moindre problème on peux recharger une image propre.

○ Sauvegarde et réutilisation du travail accompli dans une sessions avec un groupe d’élèves.

○ Enchaîné les sessions différentes avec des groupes d’élèves eux aussi différents.

● Freins et leviers :

○ Il n'existe pas de solution toute faite qui réponde à nos besoin.

○ Une solution serra peut-être longue à produire ou du moins à concrétiser.

○ La vitesse de chargement des images de machine virtuelle serra peut-être trop longue pour être viable dans une session de TP d'une heure et demi.

4) Parties prenantes

● Qui est concerné par la mise en place du projet ?

○ Le tuteur / client du projet : Mr EL AZZOUZI.

○ Les élèves du groupe de projet (en l’occurrence des deux groupes de projet

«Virtualisation»).

● Quelles sont les spécificités de chaque acteur ?

○ Mr EL AZZOUZI

■ Rôle : tuteur / client.

■ Objectifs : apprentissage des élèves de projet et possible aboutissement du projet.

■ Problématiques liés à son poste : ne pas amené de solutions ou de réponses toutes faites aux élèves de projet mais au contraire les pousser à la remis en cause, au questionnement et à la recherche de pistes d'études en lien avec le projet.

12

■ Besoins particuliers : Réalisation du projet.

■ Domaine d’expertise : informatique, mathématique, réseaux et sans doute plus !

○ Élèves du groupe de projet 3

■ Rôle : études préalables, élaboration d'un cahier des charges, mise en place de la solution finale.

■ Objectifs : Apprendre et découvrir les technologies de la virtualisation. Rédiger un cahier des charges pour la future réalisation du projet au semestre 2.

■ Problématiques liés à notre situation : Ne pas faire de hors sujet. Bien cerner les objectifs de notre tuteur / client.

■ Besoins particuliers : Trouver une solution qui réponde aux exigences du projet.

■ Domaine d’expertise : en formation...

5) Contraintes

1. Le projet utilisera le matériel déjà présent dans les locaux du CERI.

2. Le projet «Virtualisation» ne devrait représenter aucun coût financier pour le CERI.

3. Le délai pour la réalisation du projet, du moins pour notre groupe, s'étend sur tout le deuxième semestre du Master 1 2014/2015 (le projet en lui-même sera assurément continué et amélioré lors des années suivantes).

4. Le support utilisateur et technique, la maintenance et la formation des

utilisateurs ne pourra être imputé aux élèves et devra sans doute demander l'implication des professeurs du CERI.

6) Exigences

1 Toutes solutions, technique ou technologie mise en œuvre lors du projet doit être open source.

La désignation open source, ou «code source ouvert», s'applique aux logiciels dont la licence respecte des critères précisément établis par l'Open Source Initiative, c'est-à-

13 dire les possibilités de libre redistribution, d'accès au code source et de création de travaux dérivés.

«Open source» désigne un logiciel dans lequel le code source est à la disposition du grand public, et c'est généralement un effort de collaboration où les programmeurs améliorent ensemble le code source et partagent les changements au sein de la communauté ainsi que d'autres membres peuvent contribuer.

2. Les éléments de solution éventuellement créés seront évidement eux aussi open source, de licence GPLv3 (fournie en ANNEXE 3).

3. Les serveurs seront des serveurs Linux accompagnés des dépôts logiciels adéquats.

4. Les scripts produits, le seront si possible en Bash (Bourne-again shell).

5. Toute production devra être documentée pour le bien de l'avancement éventuel du projet lors d'années suivantes.

6. Les serveurs devront être assez puissants pour implémenter la solution sélectionnée.

7. Ils devront aussi avoir des processeurs à architectures x86 disposant des instructions de Virtualisation Intel VT ou AMD-V.

14

III. CHAPITRE 3 : Réalisation Technique

1. Présentation de la solution KVM

KVM, Kernel Virtual Machine, est intégré depuis le noyau 2.6.20 et permet une virtualisation matérielle et donc une accélération de la virtualisation de système d’exploitation.

C'est un système optimisé pour la virtualisation de poste de travail. Pour virtualiser des systèmes de type desktop, KVM semble en effet plus performant en consommation de processeur mais plus lent pour l'émulation du périphérique graphique. KVM est préférer pour sa meilleure compatibilité avec des système d'exploitations anciens ou peu populaires.

Néanmoins, KVM est complètement libre, performant et très facile à installer et à utiliser.

L'interface graphique virt-manager pourra aider les néophytes à paramétrer KVM et pourra rendre la vie plus simple aux administrateurs réseaux.

Les serveurs de virtualisation doivent disposer d’un processeur qui supporte la virtualisation tels que Intel VT ou AMD-V.

 Architecture du serveur KVM

 Donc la solution que nous avons implémentée pour répondre aux exigences et aux besoins définis dans le cahier de charge est la solution citée ci-dessus KVM.

 Nous avons utilisé le système linux Ubuntu version 14.04 pour installer et configurer notre serveur de virtualisation KVM dessus.

Figure 3 . Architecture de module KVM

15

2. Gestion et configuration du KVM

 L’hyper viseur KVM et mangeable à travers l’outil graphique « Gestionnaire de machine virtuelle » permettant de gérer les machines virtuelles, cette outil permet de lister les différentes machine virtuelles tournant sur l’hyper viseur ainsi que

l’utilisation du CPU de chaque VM et représente des statistiques de l’état de chaque domaine.

 L’outil de gestion VMM permet aussi la création et la suppression des machines virtuelles, et offre aux administrateurs du serveur la possibilité d’avoir un accès au bureau de chaque VM à travers des protocoles d’interaction tels que VNC ou SPICE.

3. Système d'authentification basé sur l'annuaire LDAP et PAM

 Mise en place d'un serveur LDAP :

Figure 3. Gestionnaire de machine virtuelle

16 LDAP ( Lightweight Directory Access Protocol) est un protocole d'accès à un annuaire. Un annuaire électronique est une base de données spécialisée, dont la fonction première est de retourner un ou plusieurs attributs d'un objet grâce à des fonctions de recherche multicritères.

Contrairement à un SGBD, un annuaire est très performant en lecture mais l'est beaucoup moins en écriture. Dans notre cas nous avons mit en place un serveur LDAP pour la gestion des comptes utilisateurs les données de ce serveur serons utilisées dans l'authentification des clients afin d'accédé au machines virtuelles.

Le but principale de la mise en place d'un serveur LDAP de nombreuses applications nécessitant une authentification sont capables d'interroger un annuaire LDAP et d'y vérifier l'identité d'un utilisateur grâce à un couple login / mot de passe.

Dans notre cas la solution que nous avons proposé Kimchi utilise PAM pour authentifier les utilisateurs de sorte que nous pouvons se connecter avec le même nom d'utilisateur et mot de passe que nous utilisons pour se connecter à la machine elle-même.

Donc nous avons appuyé sur l'utilisation de PAM en le relions avec LDAP afin que la solution Kimchi utilise notre annuaire LDAP pour authentifier les utilisateurs

4. Authentification PAM Linux

La bibliothèque PAM est une API généralisée pour les services relevant de l'authentification permettant à un administrateur système d'ajouter une nouvelle méthode d'authentification en ajoutant simplement un nouveau module PAM, ainsi que de modifier les règles

d'authentification en modifiant sur les fichiers de configuration.

Le principe que nous avons utilisé pour que notre solution Kimchi arrive à authentifier les utilisateurs repose sur l'architecture suivante :

Figure 4. PAM

17 dans la réalisation de cette tache tout d'abord nous avons configuré notre annuaire LDAP avec des comptes utilisateurs ces derniers représentent les utilisateurs des machines virtuelles

également nous avons installé un module LDAP sert pour relier l'annuaire avec le système PAM se module s'appelle libnss-ldap.

chaque compte utilisateur contient des informations utiliser par notre système d'authentification de PAM

dans un deuxième temps nous avons configuré le système PAM pour qu’il se serve des données contenues dans LDAP et nous avons effectuées la configuration sur les fichier suivants

/etc/pam.d/common-account :

account required pam_unix.so account sufficient pam_ldap.so /etc/pam.d/common-session:

session required pam_unix.so session optional pam_ldap.so /etc/pam.d/common-auth:

auth required pam_unix.so nullok_secure auth sufficient pam_ldap.so use_first_pass

18 /etc/pam.d/common-passwd:

password required pam_unix.so nullok obscure min=4 max=8 md5 password sufficient pam_ldap.so use_authtok

le cache des données utilisateurs

nous avons mit en place un cache des données utilisateurs on utilisons un module s'appel nscd

ce module sert a limiter les requêtes vers LDAP , il met en cache les requêtes faites à la libc auprès des services de nom et d'authentification . car la récupération des données NSS depuis un serveur LDAP est relativement coûteuse et demande des ressources ,

alors le module nscd peut accélérer de façon importante des accès consécutifs aux mêmes données et améliorer les performances globales du système

Les options de configuration sont dans le fichier /etc/nscd.conf.

Voici un exemple :

enable-cache passwd yes positive-time-to-live passwd 600 negative-time-to-live passwd 20 suggested-size passwd 211 check-files passwd yes persistent passwd yes shared passwd yes

5. Présentation de la solution « kimchi-project »

Kimchi est outil développé en HTML5 et Python permettant la gestion du module KVM, kimchi utilise un plugin qui interagit avec KVM, et qui permet gérer l’hôte à travers le

module libvirt, l’interface de gestion permet l’accès à travers le web en utilisant un navigateur qui supporte HTML.

Kimchi se compose de deux partie, la première permet à l’administrateur du serveur de vitualisation de gérer ce dernier et ses différents composants, la deuxième partie permet à un utilisateur d’ouvrir une session et travailler sur les différentes VMs.

19

 Chaque utilisateur dispose d’un espace web dédié pour travailler sur les VMs disponible, donc l’utilisateur s’authentifier auprès du serveur LDAP mis en place, une session est crée à l’utilisateur qui peut travailler sur plusieurs SE en même temps.

 L’utilisateur une fois connecté il dispose d’une interface web qui liste les différentes VMs qui lui sont attribuées par l’administrateur et selon les droits de l’utilisateur.

 L’utilisateur peut travailler sur les deux SE Windows 7 ou Linux Ubuntu ou d’autres systèmes d’exploitation gérer par l’administrateur du serveur de virtualisation.

Figure 5. Authentification d’un utilisateur

20 L’utilisateur peut consulter les espaces du stockage ainsi que l’état de son quota de stockage à travers l’interface suivante :

Figure 6. Espace utilisateur

Figure 7. Stockage

21 L’utilisateur de la solution de virtualisation de poste d travail peut également consulter l’état, le type et l’espace d’adressage qui utilise sur ses différentes machines virtuelles.

La figure ci-dessous montre qu’un utilisateur peut travailler sur deux systèmes d’exploitation en même temps :

En utilisant le protocole SPICE l’utilisateur peut travailler sur les différentes VMs sur son navigateur préférer, dans la figure ci-dessous on voit une session de Linux Ubuntu :

Figure 8. Réseau

Figure 9. Machines Virtuelles

22 Une deuxième session pour l’utilisateur avec le système d’exploitation Windows 7.

Figure 10. VM Linux Ubuntu

Figure 11. VM Windows 7

23

L’administrateur :

L’administrateur gère le serveur de virtualisation à travers l’interface web, il dispose d’une vue de l’ensemble des statistiques système telles que (CPU, Mémoire, l’état du réseau, Etc)

L’administrateur dispose d’une session web lui permettant de gérer le serveur de virtualisation, ainsi que les différentes machines virtuelles par exemple la création et la suppression de VMs la gestion du stockage et du réseau du serveur.

Figure 12. Hôte

Figure.13 VMs interface administrateur

24 L’administrateur a la possibilité de faire la création des VMs à l’aide d’un modèle qui lui permet de réduire le temps de mise en place d’un nouveau système d’exploitation.

L’administrateur dispose d’une interface web qui lui permettre de gérer les différents types de stockage (dir,NFS,iSCSI,Canal Fibre SCSI, Etc) sur le serveur de virtualisation.

Figure.14 Modèle de création de VM

Figure 15. Gestion de stockage

25 La définition et la création de différents types de réseau au sein du serveur KVM, se fait grâce au module suivant :

IV. CHAPITRE 4 : Organisation du projet

1)

Nous avons utilisé l’outil Smart Organiser, pour organiser chaque rendez-vous. Cet outil nous a permis de gérer l'ensemble de nos informations personnelles ainsi que visualiser

rapidement et clairement les disponibilités de chacun d’entre nous afin de trouver les dates qui conviennent à tous les membres du groupe.

Drop Box :

Nous avons travaillé avec l’outil Drop box, qui nous a permis de disposer d’un espace de gestion de fichiers, avec cet outil nous avons pu partager différents documents : les documents qui contiennent les informations pertinentes pour le projet, les comptes rendus de chaque réunion, les supports techniques du projet.

Site web :

Durant le premier semestre l'un des premiers travaux que nous avons réalisé est la mise en Figure 16. Gestion de réseau

26 place de plusieurs pages web, qui seront enrichies au fur et à mesure de l'évolution du projet.

Sur le site web nous déposons les fichiers de comptes rendus ainsi que le support technique de notre projet .Ces pages web seront conservées à la fin de notre projet et elles sont mises à disposition sur le site web officiel du CERI pour les futurs étudiants ou les partenaires du CERI (notamment les entreprises).

2) Rencontres et réunions Cadence des réunions :

Les réunions se sont déroulées généralement à une fréquence d’une par mois. Cependant, nous avons eu quelques soucis au début du semestre pour avoir des dates fixe aux réunions, en raison d’un problème au niveau de la communication.

Les aspects évoqués :

Le déroulement des réunions ont suivi un schéma bien déterminé, au début généralement nous commençons par un bref rappel de ce qui a été fait antérieurement. Nous présentons sur quoi nous avons avancé depuis la réunion précédente puis nous discutons de ce qu’il serait

intéressant de garder, d’ajouter ou de modifier puis nous terminons en faisant un dernier point sur les travaux à réaliser pour la réunion suivante.

3)

Voici les diagrammes de Gantt que nous avons utilisé afin de planifier notre projet lors des semestres :

27 Le premier semestre consisté à définir les exigences et les besoins du projet ainsi que la rédaction du cahier de charges, Durant ce semestre nous avons rencontré notre tuteur à quatre reprises pour proposer des solutions et pour cerner les exigences du projet,

4) Problèmes Rencontrés

Premièrement et c’est un apprentissage en soit il est très difficile d’obtenir et de tenir des rendez- vous avec les emplois du temps très chargés de tout un chacun, auquel se rajoute les aléas de la vie.

Ensuite le CERI n’est pas assez fournie en machines utilisables pour les projets de Master RISM, c’est un fait auquel nous nous sommes confrontés dès le début du semestre et qui nous a

fortement ralentis. Sur les quatre machines aux spécifications très précises que nous devions avoir seul une était en état de marche et il a encore fallu que nous utilisions notre propre matériel pour palier à un de ses manques (pas assez de mémoires RAM). Nous avons obtenus une autre machine en fin de semestre.

De plus ces machines ne nous auraient été accessibles que lors de sessions au planning très restreint si notre tuteur ne nous avez pas permis de prendre la machine principale chez l’un d’entre nous pour travailler (en accès distant pour les autres).

Le réseau du CERI assujetti à un portail captif pour authentification nous a causé aussi quelques soucis en début de semestre. Problème résolu par la solution déjà vu plus haut.

Le projet en lui-même c’est avéré plus ardu que nous ne l’avions prévu et nous avons dû revoir nos espérances et ambitions à la baisse.

28

Conclusion

Il est évidement encore possible d’améliorer grandement ce projet. Pour l’instant notre solution est empruntée, open source certes, mais pas encore assez personnalisée. Le design pourrait être adapté pour refléter son utilisation au sein du CERI. L’affichage des machines virtuelles pourrait être aussi amélioré.

Lors du semestre dernier nous avons approfondi notre connaissance de la virtualisation, ses différentes technologies et approches.

Il en est ressorti que nous n'aurions pas de solution toute faite et répondant parfaitement au cahier des charges que nous avions écrit. Les solutions étudiés étaient très intéressantes mais évidement pas parfaites pour différentes raisons.

Lors de ce semestre nous avons travaillé dans l’optique d’obtenir une solution se rapprochant le plus possible du cahier des charges du premier semestre. Et dans les faits nous en sommes très proches. La solution n’est visuellement pas parfaite mais répond plutôt bien aux spécifications du premier semestre.

Nous savons que ce projet sera continué par les futurs étudiants du CERI et sommes très curieux de ce qu’ils pourront trouver et, où inventer ! Une petite suggestion de notre part pour eux faites des groupes de projet mixte. En effet l’ajout d’un membre ILSEN au groupe nous aurait bien aidé

29

Annexes

(Les différentes Annexes .PDF sont sur le site du projet)

 Site projet : http://projets-gmi.univ-avignon.fr/projets/proj1415/p03/

 ANNEXE 1 – QEMU.pdf

 ANNEXE 2 – KVM.pdf

 ANNEXE 3 - GPL v3.odt

 ANNEXE 4 - HYPERVISEUR.pdf

 ANNEXE 5 – PARAVIRTUALISATION.pdf

 ANNEXE 6 -MACHINE VIRTUELLE.pdf

 ANNEXE 7 - http://www.virtu-desk.fr/pages/la-virtualisation/

 ANNEXE 8 - http://www.linux-kvm.org/page/Main_Page

30