the last commit enfin on espere!!!

[rapport_i2l.git] / Virtualisation.tex

\chapter{Virtualisation}
La virtualisation est une technique qui permet de faire fonctionner sur une seule machine plusieurs syst\`emes d'exploitation, s\'epar\`ement les uns des autres, comme s'ils fonctionnaient sur des machines physiques distinctes. L'outil de virtualisation que nous utilisons est Xen qui est un des logiciels libres de virtualisation les plus aboutis. 

\section{Pr\'esentation des outils}
\subsection{Xen}
Xen est un logiciel libre de virtualisation, plus pr\'ecis\'ement un hyperviseur de machine virtuelle.

Il est d\'evelopp\'e par l'universit\'e de Cambridge au Royaume-Uni. Xen permet de faire fonctionner plusieurs syst\`emes d'exploitation virtuels (invit\'es) sur une seule machine h\^ote.

Xen permet de faire tourner plusieurs syst\`emes d'exploitation (et leurs applications) de mani\`ere isol\'ee sur une m\^eme machine physique. Les syst\`emes d'exploitation invit\'es partagent ainsi les ressources de la machine h\^ote.

\subsubsection{Architecture de Xen}
Avant Xen 3.0, Xen etait un ``paravirtualiseur'' ou un ``hyperviseur'' de machines virtuelles (voir figure \ref{XenInf3}). Les syst\`emes d'exploitation invit\'es avaient ``conscience'' du Xen sous-jacent, ils avaient besoin d'\^etre ``port\'es'' (adapt\'es) pour fonctionner sur Xen. Linux, NetBSD, FreeBSD (portage en cours) et Plan 9 pouvaient fonctionner sur Xen.

\begin{figure} [htbp]
\begin{center}
\begin{tabular}{|c|c|c|c|c|c|c|}
\cline{1-1} \cline {3-3} \cline{5-5} \cline {7-7}
Logiciels de contr\^ole Xen& &User space& &User space& &User space\\
\cline{1-1} \cline {3-3} \cline{5-5} \cline {7-7}
Xeno-Linux& &Linux& &NetBSD& &FreeBSD\\
\cline{1-1} \cline {3-3} \cline{5-5} \cline {7-7}
Pilotes Xen& &Pilotes Xen& &Pilotes Xen& &Pilotes Xen\\
\cline{1-1} \cline {3-3} \cline{5-5} \cline {7-7}
\multicolumn{7}{c}{ } \\
\hline
\multicolumn{7}{|c|}{Xen} \\
\hline
\multicolumn{7}{|c|}{Mat\'eriel : processeur, m\'emoire, stockage, r\'eseau, etc. } \\
\hline
\end{tabular}
\end{center}
\caption{Xen $< 3.0$ ou sans la technologie VT}
\label{XenInf3}
\end{figure}
Avec les technologies Intel Vanderpool et AMD Pacifica, ce portage n'est plus n\'ecessaire et tous les syst\`emes d'exploitation sont support\'es; Xen 3.0 (voir figure \ref{XenSup3}) peut faire tourner des syst\`emes non modifi\'es sur des processeurs supportant la technologie VT \footnote{Virtualization Technology, anciennement Vanderpool}. Avec cette technologie, seul le systeme h\^ote a besoin d'un noyau modifi\'e pour Xen (qui est disponible dans la plupart des distributions), les syst\`emes invit\'es n'ont pas besoin de modification, on peut donc avoir des machines virtuelles avec Windows. 

\begin{figure}[!ht]
\begin{center}
\begin{tabular}{|c|c|c|c|c|c|c|c|c|}
\cline{1-1} \cline {3-3} \cline{5-5} \cline {7-7}\cline{9-9}
Logiciels de contr\^ole Xen& &User space& &User space& &User space& &User space\\
\cline{1-1} \cline {3-3} \cline{5-5} \cline {7-7}\cline{9-9}
Xeno-Linux& &Linux& &NetBSD& &FreeBSD & &Windows\\
\cline{1-1} \cline {3-3} \cline{5-5} \cline {7-7}\cline{9-9}
\multicolumn{9}{c}{ } \\
\hline
\multicolumn{9}{|c|}{Xen avec noyau Xen} \\
\hline
\multicolumn{9}{|c|}{Mat\'eriel : processeur, m\'emoire, stockage, r\'eseau, etc. } \\
\hline
\end{tabular}
\end{center}
\caption{Xen $>  3.0$ avec la technologie VT}
\label{XenSup3}
\end{figure}



Les architectures x86, x64, IA-64, PowerPC et SPARC sont support\'ees. Le multiprocesseur (SMP) et partiellement l'Hyper-Threading sont support\'es.

\subsubsection{Comparaison avec d'autres solutions de virtualisation}
G\'en\'eralement, la virtualisation n\'ecessite un syst\`eme d'exploitation h\^ote install\'e sur le mat\'eriel, et optionnellement une couche interm\'ediaire. Un ou plusieurs syst\`emes d'exploitation invit\'es peuvent alors \^etre install\'es en parall\`ele.

\begin{itemize}
\renewcommand{\labelitemi}{$\bullet$}
\item Les logiciels de virtualisation de type QEMU, VMWare Workstation/GSX ou VirtualPC sont des machines virtuelles compl\`etes pour les syst\`emes d'exploitation invit\'es, incluant m\^eme un BIOS logiciel (``firmware''). Le syst\`eme d'exploitation invit\'e ``croit'' tourner sur un mat\'eriel, or il est ``virtuel'' ou ``simul\'e'' par le logiciel de virtualisation, l'OS invit\'e n'a pas ``conscience'' d'\^etre virtualis\'e. La surcharge introduite par l'empilage du syst\`eme d'exploitation h\^ote et de la machine virtuelle en font des solutions peu satisfaisantes pour des besoins en performance. Ils sont toutefois les plus simples \`a mettre en \oe uvre.

\item Les logiciels de virtualisation de type VMWare ESX permettent d'avoir des machines compl\`etement virtualis\'ees pour les syst\`emes d'exploitation invit\'es, incluant m\^eme un bios. Mais, \`a la diff\'erence des machines virtuelles compl\`etes pr\'ec\'edemment cit\'ees, il y a empilage l\'eger, la machine virtuelle se repose sur un noyau l\'eger nomm\'e vmkernel. C'est une architecture tr\`es similaire \`a Xen.

\item Les logiciels de type chroot, Linux-VServer, OpenVZ ou BSD Jail ne font qu'isoler certains aspects ou ressources du syst\`eme d'exploitation h\^ote comme les syst\`emes de fichiers ou les espaces m\'emoire. Ces solutions sont tr\`es performantes, du fait du peu de surcharge (pas d'empilage d'OS h\^ote et d'un logiciel de virtualisation), mais les environnements virtualis\'es (on ne peut pas parler de machine ou syst\`emes d'exploitation virtuels) sont peu ou pas compl\`etement isol\'es.

\item User Mode Linux (d'acronyme UML) est un noyau Linux compil\'e pour fonctionner en espace m\'emoire utilisateur (en dehors de l'espace noyau privil\'egi\'e). Il se lance donc comme une application dans le syst\`eme d'exploitation h\^ote. UML peut lancer et g\'erer ses applications de mani\`ere isol\'ee des autres UML qui tournent sur la m\^eme machine. Solution tr\`es peu performante, car deux noyaux sont empil\'es, elle sert surtout au d\'eveloppement du noyau ou \`a la r\'ealisation de pot de miel\footnote{Un honeypot (en fran\c{c}ais pot de miel) est un ordinateur ou un programme volontairement vuln\'erable destin\'e \`a attirer et \`a pi\'eger les pirates informatiques}.
\end{itemize}
Du fait de cette ``paravirtualisation'' (adaptation du syst\`eme d'exploitation invit\'e) et de sa l\'eg\`eret\'e, Xen est un outil de virtualisation des plus performants.

\subsection{LVM}
\subsubsection{Pourquoi utiliser un gestionnaire de volume logique ?}
Sur un syst\`eme Linux traditionnel, le d\'ecoupage de l'espace disque se fait habituellement par la cr\'eation de partitions physiques de taille fixe lors de l'installation du syst\`eme. Le syst\`eme de fichiers (structure logique abritant les fichiers et les r\'epertoires, vos donn\'ees en l'occurrence) prenant place \`a l'int\'erieur d'une partition.

Prenons l'exemple d'un disque dur point\'e par le fichier sp\'ecial /dev/hda qui contient une partition /dev/hda2 pour le swap, /dev/hda5 pour le /home et /dev/hda6 pour le root (utilisation de la commande syst\`eme ``\textit{sfdisk -l}'' pour lister les partitions de la machine). Chaque partition poss\`ede un type (par exemple, 0x82 pour le swap ou 0x83 pour des partitions Linux) et contient en dehors du swap un syst\`eme de fichiers (par exemple Ext3 ou Reiserfs).

\lstset{language=csh}
\lstset{basicstyle=\small,commentstyle=\textit}
\begin{lstlisting}
 

# sfdisk -l

Disk /dev/hda: 608 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls   #blocks   Id  System
/dev/hda1   *    101     607     506   4060144    5  Extended
/dev/hda2          0+    100     100-   802400+  82  Linux swap
/dev/hda3          0       -       0         0    0  Empty
/dev/hda4          0       -       0         0    0  Empty
/dev/hda5        101+    151      50-   401200+  83  Linux
/dev/hda6        152+    324     172-  1380128   83  Linux

\end{lstlisting}

La partition \'etendue est une contrainte du format de partition de type dos dans lequel on ne peut cr\'eer plus de quatre partitions primaires mais o\`u l'on peut, par une partition \'etendue, cr\'eer un grand nombre de partitions logiques :

\begin{figure}[!ht]
\begin{center}
\includegraphics{partition_dos.jpg}
\caption{Partitionnement standard de type DOS}
\end{center}
\end{figure}

Ce mode de mise en oeuvre est simple et efficace mais permet difficilement d'\'etendre l'espace disponible en cas de saturation d'une partition : par exemple pour ajouter 2 Go au syst\`eme de fichiers /home, il n'y a pratiquement pas d'autre possibilit\'e que de r\'einstaller la machine en choisissant un nouveau d\'ecoupage lors de l'installation. Et si le disque dur ne suffit pas, il faudra en ajouter un second mais en il faudra toujours une r\'einstallation du syst\`eme.

Pour r\'esumer le probl\`eme, puisqu'il faut cr\'eer une partition sur un disque dur avant de pouvoir mettre en place un syst\`eme de fichiers, ce dernier sera statique et impossible \`a \'etendre car il est impossible nativement de cr\'eer des partitions, et donc un syst\`eme de fichiers, qui couvrent plusieurs disques durs.

\subsubsection{Introduction \`a LVM}
LVM, dont l'acronyme anglo-saxon signifie Logical Volume Manager, est un gestionnaire de volumes logiques qui apportent une vision abstraite du stockage de la machine. La partition physique devient un composant \'el\'ementaire et ne va plus directement supporter le syst\`eme de fichiers. Entre ces deux couches de bas et de haut niveau (successivement, la partition et le syst\`eme de fichiers), vont s'intercaler une premi\`ere couche regroupant les partitions physiques (appel\'ee ``volume groupe'') et une deuxi\`eme couche dans laquelle seront cr\'e\'es les syst\`emes de fichiers (appel\'es ``volumes logiques'') mais qui seront dynamiquement retaillables (indiff\'eremment en r\'eduction ou en extension).
\begin{figure}[!ht]
\begin{center}
\includegraphics{partition_lvm.jpg}
\caption{D\'ecoupage des donn\'ees sous LVM}
\end{center}
\end{figure}

L'int\'er\^et principal de cette approche est \`a la fois de pouvoir \'etendre facilement un volume groupe en ajoutant des partitions physiques (par exemple, un nouveau disque dur) et de changer la taille \`a chaud des volumes logiques sachant que ces derniers ne poss\`edent pas un emplacement pr\'ecis sur un volume groupe et ne sont repr\'esent\'es que par leur nom et leur taille.

Pour \^etre pr\'ecis, nous allons parler de volumes physiques comme composant \'el\'ementaire du stockage (un disque dur, une partition, un volume Raid logiciel, un device bloc r\'eseau voire un device en loopback), de volumes groupes comme abstraction de l'espace disque (compos\'es de un ou plusieurs volumes physiques pr\'esents ou non sur le m\^eme disque dur) et de volumes logiques dans lesquels nous allons cr\'eer nos syst\`emes de fichiers.

\begin{figure}[!ht]
\begin{center}
\includegraphics[width=12cm]{lvm_partition_small.jpg}
\caption{Couches d'abstractions du mod\`ele LVM}
\end{center}
\end{figure}

Nous allons appeler \textbf{PV} un volume physique (Physical Volume), \textbf{VG} un volume groupe (Volume Group) et \textbf{LV} un volume logique (Logical Volume). Le nommage des volumes groupes et logiques est libre m\^eme si la convention habituelle est de pr\'efixer un volume groupe par ``vg\_'' et un volume logique par ``lv\_''.

Tout l'espace disponible dans un volume groupe peut ne pas \^etre utilis\'e dans les volumes logiques. Cela permet de garder en r\'eserve de l'espace disque pour l'ajouter aux volumes logiques qui en auront besoin.


\subsubsection{Un peu d'histoire}
LVM (dont les principes ont \'et\'e d\'evelopp\'es par l'Open Software Foundation) est notamment un ticket d'entr\'ee incontournable dans le monde de l'entreprise actuel. Il faut bien comprendre que les gros Unix propri\'etaires poss\`edent tous leurs propres gestionnaires de volumes : Aix, Solaris, HP-UX, Tru64, ... (l'impl\'ementation actuelle LVM de Linux est tr\`es proche de celle de HP-UX). Linux n'est donc pas un pr\'ecurseur en la mati\`ere mais disposer d'un LVM est un enjeu primordial pour les d\'ecideurs informatiques souhaitant traiter des volumes de donn\'ees cons\'equents.

LVM 1.0.x (d\'evelopp\'e principalement par la soci\'et\'e Sistina) est directement impl\'ement\'e au niveau du noyau Linux depuis sa version 2.4 (avec possibilit\'e d'impl\'ementation \`a partir du 2.2.17) ; la version 2.6 int\`egre la version 2.0 de LVM. Cette derni\`ere version repose sur une nouvelle couche du noyau, le ``device mapper'', qui rationalise l'impl\'ementation de drivers supportant des devices virtuels en mode blocs comme par exemple le Raid logiciel.

Pour la petite histoire, il s'en est fallu de peu que le LVM Linux ne soit supplant\'e par un \'equivalent d\'evelopp\'e par IBM, appel\'e du doux acronyme de EVMS, et qui avait pour ambition de modifier la vision que l'on pouvait avoir du stockage de donn\'ees sous Linux en f\'ed\'erant l'essentiel des couches dans un m\^eme outil : partition, LVM, Raid logiciel, etc. (concept qui avait tout pour s\'eduire). Les d\'eveloppeurs du noyau Linux ont finalement tranch\'e en faveur du LVM2 de la startup Sistina plut\^ot que de choisir l'outil novateur (peut \^etre un peu trop) du g\'eant IBM : cela est la preuve, s'il en est besoin, de l'approche d\'emocratique et mature du d\'eveloppement du noyau Linux.

Autant \^etre honn\^ete, les fonctionnalit\'es du driver EVMS restent tr\`es all\'echantes \`a l'heure qu'il est ; la preuve en est que le projet continue d'\^etre d\'evelopp\'e comme on peut le constater sur le site officiel chez IBM. Peut-\^etre entendrons-nous un jour reparler de cet outil sous une forme diff\'erente ?


\subsubsection{Utilisation des snapshots}
Un dernier point \`a aborder (et non des moindres) : la notion de snapshot.

Imaginons qu'il faille sauvegarder des fichiers poss\'edant une forte d\'ependance entre eux et modifi\'es quasiment en temps r\'eels (comme les fichiers syst\`emes d'une base de donn\'ees) : le fichier A est synchronis\'e avec le fichier B, si le fichier B est sauvegard\'e 5 minutes plus tard que le fichier A, les donn\'ees ne pourront \^etre restaur\'ees car consid\'er\'ees comme inconsistantes.

Pour traiter ce cas, il faut arr\^eter l'applicatif, lancer la sauvegarde et attendre la fin de la sauvegarde pour red\'emarrer l'applicatif : d'o\`u l'interruption du service que l'on aimerait pouvoir \'eviter ou r\'eduire.

Les snapshots LVM sont la solution : cela cr\'ee un volume logique virtuel (snapshot) qui sera la copie conforme en lecture seule de celui \`a sauvegarder \`a un instant T. Si un fichier est supprim\'e dans le volume logique initial, celui-ci sera toujours pr\'esent dans le volume logique virtuel. A l'inverse, si un fichier est ajout\'e, ce dernier sera absent du snapshot. En cas de modification des donn\'ees sur le volume initial, les donn\'ees resteront consistantes sur le volume virtuel.

Pourtant, un snapshot LVM n'est pas une copie int\'egrale des donn\'ees pr\'esentes dans un volume logique. Il n'a m\^eme pas besoin de disposer de la m\^eme quantit\'e d'espace disque. L'astuce est qu'un snapshot ne contient absolument rien, en dehors de la liste des Extends Logiques (LE) modifi\'es dans le volume initial. Les blocs modifi\'es ne sont donc pas supprim\'es mais simplement r\'ef\'erenc\'es dans le volume virtuel : apr\`es la suppression du snapshot, ces derniers seront d\'efinitivement recycl\'es.

Ce fonctionnement permet de pouvoir tranquillement lancer la sauvegarde sur les donn\'ees du volume virtuel et imm\'ediatement apr\`es (sans attendre la fin), relancer l'applicatif : quelques secondes d'interruption en somme.

Un snapshot est cr\'e\'e avec une taille initiale dont la volum\'etrie est calcul\'ee en estimant la quantit\'e de donn\'ees (LE) qui va \^etre modifi\'ee durant toute la dur\'ee du snapshot. C'est \`a peu pr\`es la seule contrainte en dehors du fait qu'un snapshot n'est pas persistant (supprim\'e apr\`es red\'emarrage de la machine).

Voici un exemple de mise en oeuvre d'un snapshot sur un volume logique vl\_data sachant que le volume logique virtuel nouvellement cr\'e\'e sera obligatoirement pr\'esent dans le m\^eme volume groupe :

\lstset{language=csh}
\lstset{basicstyle=\small,commentstyle=\textit}
\begin{lstlisting}
# lvcreate --size 600M --snapshoot -n lv_snap /dev/vg01/vl_data
# mkdir /lv_snap
# mount /dev/vg01/lv_snap /lv_snap

[sauvegarde des donnees]

# umount /lv_snap
# lvremove /dev/vg01/lv_snap
\end{lstlisting}

\subsection{XEN + LVM}
Le couplage de Xen  et des partitions LVM a un grand inter\^et dans le domaine de la production.\\
Le but de ce couplage de technologies est de permettre la sauvegarde des machines virtuelles sans arr\^eter la production. 

En effet, le syst\`eme de snapshot de LVM permet d'avoir une ``photo'' d'un volume logique \`a un instant \textbf{t} et ce quasi instantan\'ement. Ainsi, en installant une machine virtuelle sur un Volume Logique, on peut sauvegarder celle-ci facilement en utilisant le syst\`eme de snapshot.

Pour sauvegarder une machine virtuelle qui est install\'ee sur un ou plusieurs Volumes Logiques, il suffit de respecter la proc\'edure suivante:
\begin{itemize}
\renewcommand{\labelitemi}{$\bullet$}
\item 1 ) Mettre la machine virtuelle en pause.
\item 2 ) Cr\'eer un snapshot par volume logique utilis\'e par la machine virtuelle.
\item 3 ) Enlever la pause.
\item 4 ) Copier le snapshot dans un fichier (avec un dd par exemple).
\end{itemize}
La machine virtuelle n'aura \'et\'e fig\'ee (non pas stop\'ee) que de l'\'etape 1 \`a l'\'etape 3, ce qui ne repr\'esente qu'une fraction de secondes. Ainsi, durant la proc\'edure de sauvegarde, rien n'est arr\^et\'e.\\
Ceci peut \^etre tr\`es utile notamment sur un seveur de base de donn\'ees, de t\'el\'ephonie, ou encore des serveurs web etc\dots 
 
\section{Cas Pratique: "Label Vie"}
Suite \`a la demande d'un client d\'esirant refaire son parc informatique et sous-traiter la maintenance, nous avons opt\'e pour une solution de virtualisation comportant :
\begin{itemize}
\renewcommand{\labelitemi}{$\bullet$}
\item Un serveur debian : routeur, firewall, proxy.
\item Un serveur windows 2003.
%\item Un sesveur debian pour la t\'el\'ephonie (Asterisk).
\end{itemize}
Chaque serveur \'etant sauvegard\'e localement chaque nuit et dupliqu\'e sur un serveur distant, pour une reprise rapide en cas de panne.   

\subsection{Installation du Dom0}

Le Dom0 est un syst\`eme debian etch qui est entièrement d\'edi\'e \`a la virtualisation.
L'installation se fait comme un syst\`eme normal, il suffit ensuite de rajouter les paquets xen suivants :
\begin{itemize}
\renewcommand{\labelitemi}{$\bullet$}
\item xen-hypervisor-i386 (pour les processeurs supportant la technologie VT)
\item xen-hypervisor-i386-pae (pour les processeurs ne supportant pas la technologie VT)
\item xen-utils
\item xen-docs-3.0
\item linux-image-xen-686
\item xen-ioemu-3.0.3-1 (pour la virtualisation compl\`ete)
\item bridge-utils
\end{itemize}
~\par
Une fois ces paquets install\'es, il faut  red\'emarrer sur le noyau Xen, et on peut utiliser xen. \\
Dans notre cas, nous avons d\^u faire une l\'eg\`ere modification de la configuration de xen afin de pouvoir avoir plusieurs cartes r\'eseaux au sein des machines virtuelles.

Il faut aussi une partition de type LVM afin de pouvoir installer les machines virtuelles sur des volumes logiques ce qui nous permet de cr\'eer rapidement des snapshots pour pouvoir sauvegarder les machines sans les arr\^eter. Nous reviendrons plus tard sur le m\'ecanisme de sauvegarde des machines. 

Pour g\'erer les machines virtuelles, nous disposons des commandes classiques de Xen comme \textit{xm create}, \textit{xm list} ... 
Pour faciliter la gestion des DomU, nous avons d\'evelopp\'e un pluggin WebMin qui permet de lancer les commandes simples de xen (lister les machines, d\'emarrer, arr\^eter ou rebooter une machine) via une interface web. Ceci permet en cas de besoin de pouvoir g\'erer les machines virtuelles sans avoir acc\`es \`a la machine et sans connexion ssh, un simple navigateur web suffit.

\begin{figure}[!ht]
\begin{center}
\includegraphics[height=90mm]{webmin_xen.png}
\caption{Plugin Webmin pour Xen}
\end{center}
\end{figure}

\subsection{Installation des DomU}
Il existe deux fa\c{c}ons de virtualiser des machines avec XEN, soit en para-virtuallisation, soit en virtualisation compl\`ete.\\
La para-virtuallistion utilise le noyau de la machine h\^ote (le Dom0), alors que la machine utilisant la vitualisation compl\`ete a son propre bios et son propre noyau. Cela permet ainsi d'avoir des noyaux diff\'erents par machine, mais \'egalement de d\'eplacer la machine virtualis\'ee quelle que soit la machine h\^ote (Dom0).

Installer une machine virtuelle utilisant la para-virtualisation se fait simplement en utilisant la commande xen-create-image qui appelle debootstrap permettant d'installer un syst\`eme Debian de base en une seule commande. Cela cr\'ee le fichier de configuration de la machine, et les disques qu'ils soient fichiers ou LVM.

Pour installer une machine compl\`etement virtualis\'ee, il faut cr\'eer les disques et le fichier de configuration \`a la main, puis d\'emarrer la machine en utilisant l'image (au format iso par exemple) de la distribution que l'on souhaite installer. Pour l'installation, il faut utiliser SDL ou VNC afin d'avoir un affichage, il est donc n\'ecessaire d'avoir un serveur X sur la machine h\^ote. Cette m\'ethode permet \'egalement d'installer un Windows.\\
Cependant avec cette m\'ethode, il nous est impossible de r\'ecup\'erer la console du DomU en utilisant la commande ``\textit{xm console}''

Pour des raisons de non-d\'ependance des machines virtualis\'ees envers la machine h\^ote, nous avons donc choisi cette seconde solution. Ainsi, on peut d\'eplacer les DomU vers un autre serveur en cas de panne.

\subsubsection{Le serveur virtualis\'e (routeur, firewall, proxy)}

Le premier serveur que nous avons install\'e sur la machine h\^ote est une machine servant de routeur, firewall et de proxy, cette machine sert \`a g\'erer toute la partie r\'eseau de l'entreprise.\\
Elle comporte deux cartes r\'eseaux, l'une \'etant reli\'ee \`a internet et la seconde au r\'eseau local.
Sur ce serveur nous avons install\'e Webmin ce qui permet de configurer facilement les divers programmes notamment iptable qui sert de routeur et de firewall.

\begin{figure}[!ht]
\begin{center}
\includegraphics[height=90mm]{webmin_iptable.png}
\caption{Plugin Webmin pour iptable}
\end{center}
\end{figure}

Ensuite, nous avons install\'e le proxy squid. Le proxy n'a pour r\^ole que de servir de cache et de log afin de surveiller l'utilisation d'internet par les utilisateurs. Il est configur\'e de fa\c{c}on \`a tout autoriser une fois l'utilisateur authentifi\'e.\\
Cette authentification est v\'erifi\'ee \`a travers Active Directory qui est sur le serveur windows que nous pr\'esenterons par la suite.\\
Afin de ne pas avoir \`a configurer les navigateurs du client, nous voulions installer le proxy en ``transparent'' (en redirigeant le port 80 vers le port du proxy). Cependant, cette m\'ethode ne permet pas l'authentification. Nous avons donc install\'e le proxy classiquement pour pouvoir conserver l'authentification qui permet d'identifier les utilisateurs afin de pouvoir contr\^oler l'utilisation d'internet.

Afin de consulter l'utilisation d'internet, il faut pouvoir analyser les logs, pour cela, nous avons choisi deux logiciels: webalizer, et SARG (Squid Analysis Report Generator), tous deux administrables depuis webmin.\\
Webalizer permet d'avoir une vue d'ensemble de l'utilisation d'internet avec des graphiques et autres statistiques et SARG permet d'avoir une vue d\'etaill\'ee par utilisateur, ce que ne permet pas d'avoir webalizer.

\begin{figure}[!ht]
\begin{center}
\includegraphics[height=90mm]{webalizer.png}
\caption{Webalizer}
\end{center}
\end{figure}
Cette machine a aussi un serveur OpenVPN permettant de dialoguer avec le site distant plus facilement. Nous avons choisi d'installer le VPN sur le routeur car les machines du sous r\'eseau auront alors un acc\`es totalement transparent au VPN \`a travers le routeur.\\
Pour le Vpn, nous avons voulu utiliser IPSec mais cela n'a pas pu \^etre possible car les livebox du client ne laisse pas passer IPSec du fait d'un port reserv\'e. Nous avons donc utilis\'e openVPN qui permet de cr\'eer des VPN ind\'ependamment du type de connexion utilis\'e.
\begin{figure}[!ht]
\begin{center}
\includegraphics[height=90mm]{Diagramme_VPN.png}
\caption{Reseau VPN avec OpenVPN}
\end{center}
\end{figure}
~\par
On peut remarquer ici que OpenVpn cr\'ee une interface suppl\'ementaire (tun0) avec une IP de type 10.8.0.X, cette interface est directement reliée par le biais d'une connexion s\'ecuris\'ee aux autres interfaces tun0 des client VPN . Ainsi OpenVPN cr\'ee un r\'eseau s\'ecuris\'e entre le seveur et les clients.\\
Nous avons choisi d'installer OpenVpn sur les routeurs des deux sites afin de pouvoir relier les deux sous-r\'eseaux en ne configurant qu'une seule machine par site. En effet, si l'on configure bien OpenVpn, celui-ci peut cr\'eer automatiquement les routes permettant d'acc\'eder aux diff\'erents sous-r\'eseaux. 
\subsubsection{Virtualisation d'un serveur 2003}  
Pour le besoin du client nous avons install\'e un serveur 2003. Ce serveur n'est pas utilis\'e directement, il n'est utilis\'e qu'avec les TSE (bureaux distants) en g\'en\'eral \`a partir de boitiers l\'egers. Cette utilisation se pr\^ete donc bien \`a la virtualisation car nous n'avons pas besoin d'acc\'es direct \`a la machine windows.

Pour virtualiser un windows, nous sommes oblig\'es de faire de la virtualisation compl\`ete. En effet, il est impossible de faire tourner un windows en para-virtualisation car il ne peut cohabiter avec le noyau du syst\`eme h\^ote. De plus, le processeur du serveur doit supporter la technologie VT.
Une fois ces conditions remplies, le windows s'installe normalement.\\
Il faut simplement lancer la machine virtuelle en lui indiquant de d\'emarrer sur son lecteur CD, lecteur qui est \'emul\'e par xen en indiquant juste l'iso du CD d'installation de windows, par la suite le windows s'installe de fa\c{c}on classique.  

Cependant, il est \`a noter qu'il faut obligatoirement un serveur X install\'e sur le Dom0, ce qui est normal pour l'installation du windows (il faut bien pouvoir cliquer), mais m\^eme une fois la machine virtuelle install\'ee, le windows ne pourra se lancer sans serveur X. En effet, il a besoin soit de VNCServer soit de SDL sur le Dom0 pour \^etre d\'emarr\'e.

\begin{figure}[!ht]
\begin{center}
\includegraphics[height=100mm]{screenshot-2003.png}
\caption{Windows 2003 serveur virtualis\'e}
\end{center}
\end{figure}

\begin{figure}[!ht]
\begin{center}
\includegraphics[height=100mm]{screenshot2-2003.png}
\caption{\'Ecran bleu virtualis\'e}
\end{center}
\end{figure}
\newpage

\subsection{Syst\`eme de backup des DomU }  
Nous devions pr\'evoir une sauvegarde journali\`ere automatique de l’ensemble des machines virtuelles de mani\`ere \`a pouvoir relancer rapidement une machine en cas de panne. Pour plus de s\'ecurit\'e, cette sauvegarde devait se faire \`a la fois en locale mais \'egalement sur une machine distante.

Il fallait \'egalement arr\^eter les machines \`a sauvegarder le moins longtemps possible. Nous avons donc utilis\'e les snapshots lvm.

Il \'etait n\'ecessaire \'egalement de pouvoir garder le plus d’historique possible dans les sauvegardes. De ce fait, nous avons utilis\'e le principe des fichiers diff\footnote{Fichier de diff\'erence entre deux fichiers} . La sauvegarde utilise 3 scripts \'ecrits en Perl.

Le premier script se lance sur la machine locale (contenant les machines virtuelles \`a sauvegarder). Premi\`erement, il v \'erifie si la taille de l’ensemble des fichier diffs de chaque machine ne d\'epasse pas la taille maximum autoris\'ee d\'efinie. Si c’est le cas, alors le nombre n\'ecessaire de fichiers diff est supprim\'e. Ensuite, le script va proc\'eder de la fa\c{c}on suivante pour chaque machine :
\begin{itemize}
\renewcommand{\labelitemi}{$\bullet$}
\item Premi\`erement la machine virtuelle est mise en pause. Puis un snapshot de chaque disque utilis\'e par la machine est cr\'e\'e et enfin on relance la machine virtuelle. Cela ne prend que tr\`es peu de temps.\\
\item Le script lance alors un second script qui est ex\'ecut\'e sur la machine distante et qui va  \'egalement v\'erifier la taille de l’ensemble des fichiers diffs et en supprimer si n\'ecessaire.\\
\item Ensuite, le script v\'erifie si une premi\`ere sauvegarde de chaque disque existe. Si ce n’est pas le cas, alors cette sauvegarde est cr\'e\'ee puis le script s’arr\^ete pour la machine concern\'ee. Par contre si cette sauvegarde existe alors on la renomme en ancienne sauvegarde et on cr\'ee la nouvelle \`a l’aide de l’outil dd.\\
\item Une fois les sauvegardes de chaque disque de la machine virtuelle effectu\'ees, le script va cr\'eer deux fichiers diff. Le premier entre le fichier de sauvegarde de la veille et celui de la sauvegarde juste cr\'ee, puis le second dans l’autre sens. Les fichier diffs sont cr\'e\'es \`a l’aide de l’outils xdelta3 qui permet de cr\'eer des fichiers diffs entre deux fichiers binaires.\\
\item Ces deux fichiers diffs sont ensuite envoy\'es \`a la machine distante. On peut ensuite supprimer le fichier diff cr\'e\'e entre la sauvegarde actuelle et la sauvegarde de la veille.\\
\item Une fois ces fichiers cr\'e\'es et envoy\'es pour chaque machine virtuelle, le troisi\`eme script est ex\'ecut\'e sur la machine distante.\\
Ce script a pour but de recr\'eer la sauvegarde \`a l’image de celle qui vient d’\^etre cr\'e\'ee sur la machine locale. En effet, la taille des disques (et en cons\'equent des sauvegardes) faisant plusieurs gigas octets, il \'etait impossible d’envoyer la sauvegarde compl\`ete par internet, d’o\`u l’utilisation du deuxi\`eme fichier diff. A l’aide de ce fichier et de la sauvegarde de la veille, le script va recr\'eer la sauvegarde du jour.
\end{itemize}
Apr\`es chaque sauvegarde des machines virtuelles effectu\'ee, un email est envoy\'e r\'ecapitulant toutes les actions effectu\'ees et les erreurs \'eventuelles. Il est ainsi possible de corriger ces erreurs  rapidement(dues \`a l’utilisation et non au d\'eveloppement bien-s\^ur).
\clearpage