ortographe de la partie virtualisation

[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'outils 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 disponnible dans la plupart des distributions), les syst\`emes invit\'es n'on pas besoins de modification, on peut donc avoir des machine virtuelles avec Windows. 

\begin{figure}[htbp]
\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}
(http:/lionel.tricon.free.fr/Articles/lvm/lvm\_article.html)\\
(Article publi\'e dans le GNU/Linux Magazine France, num\'ero 54 (Octobre 2003).)
\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}[htbp]
\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'autres possibilit\'es 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 sacrifiant toujours \`a une r\'einstallation du syst\`eme.

Pour r\'esumer le probl\`eme, puisque 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\'eer les syst\`emes de fichiers (appel\'es ``volumes logiques'') mais qui seront dynamiquement retaillables (indiff\'eremment en r\'eduction ou en extension).



\begin{figure}[htbp]
\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}[htbp]
\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 sauvegardez des fichiers poss\'edant une forte d\'ependance entres 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 restor\'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 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\'esentent 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}

\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}
\item Un serveur debian : routeur, firewall, proxy.
\item Un serveur windows 2003.
\item Un seveur debian pour la t\'el\'ephonie (Asterisk).
\end{itemize}
Chaque seveur \'etant sauvegard\'e localement chaque nuit et dupliqu\'e nuit sur un autre serveur de secours, 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}
\item xen-hypervisor-i386 (pour les processeur supportant la technologie VT)
\item xen-hypervisor-i386-pae (pour les processeur 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}
Une fois ces paquets install\'es il faut  red\'emarer sur le noyau Xen, et on peut utiliser xen. \\
Dans notre cas nous avons du faire une l\'eg\`ere modification de la configuration de xen afin de pouvoir avoir plusieurs cartes r\'eseaux au sein les machines virtuelles.

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

Pour g\'erer les machines virtuelles nous disposons des commandes classique de Xen comme \textit{xm create}, \textit{xm list} ... 
Pour faciliter la gestion des DomU, nous avons developp\'e un pluggin WebMin qui permet de lancer les commandes simple de xen (lister les machine, d\'emarrer, arr\^eter o\`u 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=80mm]{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 utiliant la vitualisation compl\`ete a son propre bios et son propre noyau. Cela permet ainsi d'avoir des noyaux diff\'erents par machines, mais \'egalement de d\'eplacer la machine virtualis\'ee quelque 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 confguration de la machine, et les diques qu'ils soient fichier 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'iamge (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 machne 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\'ependances 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 pannes.

\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.\\
Cette machine comporte deux cartes r\'eseaux, l'une \'etant reli\'ee \`a internet et la seconde au r\'eseau local.
Sur se serveur nous avons install\'e Webmin ce que permet de configurer facilement les divers programmes notemment iptable qui sert de routeur et de firewall.

\begin{figure}[!ht]
\begin{center}
\includegraphics[height=80mm]{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'utilisiation d'internet par les utilisateurs. Il est configur\'e de fa\c{c}on \`a tout autoriser une fois l'utilisateur autentifi\'e.\\
Cette autentification est verifi\'ee \`a travers Active Directory qui est sur le seveur 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 installer 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 analiser 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 detail\'ee par utilisateur, ce que ne pemet pas d'avoir webalizer.

\begin{figure}[!ht]
\begin{center}
\includegraphics[height=80mm]{webalizer.png}
\caption{Webalizer}
\end{center}
\end{figure}
Cette machine a aussi un serveur OpenVPN avec le site distant. 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 \`atravers le routeur.\\
Pour le Vpn nous avons voulu utiliser IPSec mais cela n'a pas p\^u \^etre possible car les livebox du client ne laisse pas passer IPSec \`a cause d'un port reserv\'e. Nous avons donc utiliser openVPN qui peut cr\'ees des VPN ind\'ependament du type de connexion utilis\'ee.

\begin{figure}[!ht]
\begin{center}
\includegraphics[height=80mm]{Diagramme_VPN.png}
\caption{Reseau VPN avec OpenVPN}
\end{center}
\end{figure}

On peut remarquer ici que OpenVpn cr\'e une interface suplementaire (tun0) avec une ip de type 10.8.0.X cette interface et directement relié par le biais d'une connexion securis\'ee aux autres interfaces tun0 des client VPN . Ainsi on OpenVPN cr\'ee un r\'eseau securis\'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\'eseau avec en ne configurant qu'une seulle machine par site. En effet si l'on configure bien OpenVpn, celui-ci peut rajouter automatiquement les routes permettant d'acc\'eder aux differents sous reseaux. 

\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 virtualtion car nous n'avons pas besoin d'acc\'es direct \`a la machine windows.

Pour virtualiser un windows nous sommes obliger de faire de la virtualisation compl\`ete, en effet il est impossible de faire touner 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 suporter la t\'echnologie 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 classiquement.  

Cependant il est \`a not\'e qu'il faut obligatoirement un serveur X install\'e sur le Dom0, ce qui est normal pour l'installation, 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 demarr\'e.

screenshot.

\subsection{Syst\`eme de backup des DomU }  


%citation
%\cite{Motclef1}.
%note de pied de page
%titit \footnote{Par exemple, on peut faire un pied de page}
\clearpage