\documentclass[11pt]{report} \usepackage[french]{babel} \usepackage{ucs} \usepackage[utf8x]{inputenc} \usepackage{vmargin} %left, top, right, bottom \usepackage{graphicx} \usepackage[hypertexnames=false, colorlinks=true, urlcolor=black, linkcolor=black]{hyperref} % Packages pour les url cliquables \usepackage{url} \usepackage[gen]{eurosym} \urlstyle{sf} \usepackage{pdfpages} \usepackage{fancyhdr} \pagestyle{plain} \usepackage{listings} \usepackage{bigcenter} \usepackage[Lenny]{fncychap} \usepackage{hyperref} \hypersetup{ pdfpagemode=UseOutlines, % UseOutlines, UseThumbs, None, FullScreen : agencement au démarrage pdfstartview=Fit, % Fit, FitH, FitB, FitBH : vue de la page au départ (pleine largeur...) pdffitwindow=true, % bool: Maximiser pdfpagelayout=SinglePage,% SinglePage, TwoColumnsRight/Left, OneColumn : affichage des pages pdftoolbar=true, % bool: Affichage de la barre d'outils pdfmenubar=true, % bool: Affichage de la barre de menus bookmarksopen=false, % bool: Dépliement des signets bookmarksnumbered=true, % bool: Numérotation des signets colorlinks=true, % bool: Liens colorés pdfauthor={Maxence Dunnewind}, % Auteur pdftitle={Architecture multi-sites, multi-services}, % Titre pdfcreator=PDFLaTeX, % pdfproducer=PDFLaTeX, % linkcolor=black, % Couleur des liens urlcolor=blue, % url anchorcolor=black, % du texte citecolor=green, % Couleur de citation frenchlinks=true, % bool: Utiliser des petites majuscules pour les liens, plutôt que de la couleur pdfborder={0 0 0} % Ne pas encadrer les liens } \title{Architecture multi-sites, multi-services} \author{Maxence Dunnewind} \begin{document} \lstset{frame=single,basicstyle=\footnotesize} \maketitle Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:\\ \begin{itemize} \item Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. \item Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. \item The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. \end{itemize} \\ THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. \clearpage \begin{abstract} Ce document décrit la mise en place d'une architecture d'hébergement de services multi-sites. Elle est conçue pour proposer des services variés (aussi bien du courrier électronique qu'un serveur de jeu) à de nombreux utilisateurs simultanés. Le matériel est réparti sur plusieurs sites géographiques, tant pour la sécurité que cela apporte que pour une meilleure réactivité du réseau. Des méthodes et outils ont été choisis pour minimiser la force de travail nécessaire à la maintenance et au déploiement. A partir de la configuration minimum (un site géographique, un administrateur) la croissance de l'audience est suivie par l'ajout de matériel et de nouveaux sites avec un temps de réaction qui évite la mobilisation de ressources inutiles. Un soin particulier a été apporté à l'utilisation de techniques largement répandues, déjà éprouvées et dont la maintenance évolutive est assurée par des équipes externes dynamiques. L'architecture tire profit, au fil des mois, des nouvelles versions. L'administrateur ayant pour tâche première d'assurer la stabilité de l'ensemble. \end{abstract} \tableofcontents \clearpage \chapter{Topologie de l'installation} \section{Topologie géographique} La localisation géographique des centres serveurs est adaptée à l'accueil des services nécessaires à l'hébergement d'un MMORPG\footnote{Jeu en réseau massivement multi-joueurs} et capable de supporter un grand nombre d'utilisateurs. Les deux configurations possibles sont :\\ \begin{itemize} \item Installation centralisée en un seul lieu \begin{itemize} \item Pas d'installation spare\footnote{Un élément dit 'spare' est utilisé en cas de panne de l'élément principal dans le but d'assurer une continuité de service} ou installation située dans le même lieu. \item Installation spare situé dans un deuxième lieu. \end{itemize} \item Installation fonctionnelle décentralisée sur $n$ sites \begin{itemize} \item Installation spare dans des sites dédiés \item Mélange d'installations principale et spare sur chaque site.\\ \end{itemize} \end{itemize} Le choix d'une configuration se fait sur les paramètres suivants :\\ \begin{itemize} \item audience : nombre d'utilisateurs simultanés, bande passante totale consommée, etc. \item humain : quelle présence sur chaque zone, en combien de temps, etc. \item financier : coût d'installation et de maintenance dans chaque centre par rapport à une installation centralisée \item technique : capacité d'administration à distance ? Interconnexion des centres ?\\ \end{itemize} La configuration décrite ici est celle répartissant l'installation sur plusieurs sites. Le cas mono-site peut en être déduit. Les services critiques\footnote{permettant le fonctionnement de l'installation} sont dupliqués ou sauvegardés. Cependant, l'architecture multi-sites permettra d'étendre les services 'spare' des différents éléments, pour des raisons d'efficacité (meilleur temps de réponse, plus de bande passante) et non d'intégrité du service. L'installation est déployée sur 2 sites : \emph{centre 1} et \emph{centre 2} dans la suite du document. Afin de soutenir une charge plus importante ou de renforcer l'accueil d'un zone géographique dans laquelle l'audience est particulièrement forte, les centres additionels seront déployés sur le même modèle. \section{Architecture matérielle} La disposition physique des serveurs permettra d'optimiser la répartition des services. Cette répartition tient compte de paramètres comme les performances du réseau sur chaque site. Nous possédons 2 hébergements ayant chacun les caractéristiques suivantes :\\ \begin{itemize} \item Capacité d'hébergement d'une baie (40U) \item Hébergement dans un datacenter professionnel, offrant une architecture capable de supporter la baie (électricité, refroidissement) \item Accès 24h/24 7j/7 \item Connectivité 100Mbps ou 1Gbps pour une baie (baie reliée par fibre au réseau de l'opérateur)\\ \end{itemize} Chaque baie est configurée de la même façon. L'hébergeur fournit suffisamment de PDU\footnote{Power Distribution Unit} pour alimenter la totalité des équipements de la baie ainsi que deux ports réseau sur un switch leur appartenant. \begin{figure}[!h] \center \includegraphics[width=0.5\linewidth]{exemple_baie.png} \caption{Baie câblée accueillant douze serveurs} \end{figure} Un switch gigabit 48 ports est connecté au port fourni par l'hébergeur. Un deuxième switch, servant au réseau de 'monitoring' (IPMI, Service Processor, KVM, etc.) est connecté sur le précédent. Chaque serveur est connecté au réseau principal via un lien gigabit, et au réseau de supervision, via un câble dédié.\\ La liaison entre le réseau gigabit et le switch fourni par l'opérateur passe par un serveur dédié, permettant de centraliser les transferts entre le réseau interne et l'extérieur (connexions distantes, accès web). Ce serveur héberge les services tels que le firewall, le serveur DHCP et le DNS secondaire. Dans le but de limiter les SPOF\footnote{Single Point Of Failure}, un second serveur est positionné afin de parer à la panne du serveur central. Un port supplémentaire est requis sur le switch du fournisseur pour assurer la redondance.\\ Chaque site est ensuite connecté au réseau Internet via la connexion du fournisseur (celui-ci assurant une connexion symétrique au minimum de 100Mbps symétriques). Les sites ne sont pas connectés entre eux de façon directe (une liaison physique dédiée est chère et inutile). Cependant, comme les différents sites doivent être interconnectés pour les besoins d'administration, des outils logiciels sont utilisés afin d'abstraire la présence d'Internet et de simuler l'existence d'un seul réseau local.\\ Dans les baies qui ne disposent pas d'équipement d'aération spécial, on évite de remplir entièrement la baie car ceci entraînerait une surchauffe des équipements. Les systèmes de refroidissements fournis par l'hébergeur (aération par le sol) sont insuffisant dans le cas d'une baie entièrement équipée. Sans équipement de ventilation adapté (plateau, porte ventilée), on laisse un emplacement libre tous les 4 emplacements. \clearpage L'architecture d'un centre correspond au schéma ci-dessous :\\ \begin{figure}[!ht] \center \includegraphics[width=\linewidth]{topo_reseau.png} \caption{Architecture réseau de chaque centre} \end{figure} \chapter{Les services utilisés en interne} Certain nombre d'outils sont requis pour la gestion de ce réseau hétérogène (que ce soit du point de vue de l'architecture matérielle ou géographique). Ils ont pour but d'assurer le fonctionnement, l'administration et la sécurité du réseau. Les services utilisés sont le VPN\footnote{Virtual Private Network, réseau privé virtuel}, le DNS\footnote{Domain Name System, gestion des correspondances nom/IP} et le DHCP\footnote{Attribution automatique des IP et de la configuration réseau} pour l'administration, Nagios et Munin pour la supervision. Chaque site est aussi sécurisé par un firewall logiciel installé sur les serveurs frontaux. \section{Systèmes d'exploitation} La totalité des machines sont équipées d'un système d'exploitation GNU/Linux. Suivant les besoins de chaque machine, les versions utilisées varient (par exemple sur les machines utilisant des containers LXC une Debian/sid avec un kernel 2.6.29 est requise alors que sur les machines à base de KVM tourne une Debian/lenny avec un kernel 2.6.26). La majorité des machines sont dans configuration type suivante :\\ \begin{itemize} \item Système d'exploitation Debian Lenny \item Noyau en version 2.6.26\\ \end{itemize} \section{Firewall} \hypertarget{firewall}{Les serveurs} d'un site physique communiquent sur Internet à travers une passerelle unique, c'est-à-dire qu'un seul serveur accède réellement à Internet. Dans le cas d'un serveur spare, la configuration est dupliquée à partir du serveur principal. Le point de passage unique permet de filtrer les communications et d'assurer la sécurité du réseau interne. Deux types d'actions contrôlent toutes les communications: la redirection et le filtrage. \subsubsection{La redirection des communications} Seule la passerelle est visible de l'Internet. Pour pouvoir utiliser les serveurs internes, les communications sont redirigées. Pour cela, la reconnaissance des communications est effectuée sur plusieurs critères dont :\\ \begin{itemize} \item Adresse IP \item Port \item Service utilisé\\ \end{itemize} Chaque combinaison d'un ou de plusieurs de ces paramètres permet de rediriger la communication vers un serveur du réseau interne, sur un port choisi. Ce système est appelé NAT\footnote{Network address translation}. \begin{figure}[!h] \center \includegraphics[width=0.8\linewidth]{nat_ip.png} \caption{Redirection basée sur l'IP} \end{figure} La redirection par IP est utilisée lorsque le serveur interne correspondant possède une IP pour lui seul. Cela diminue les problèmes liés au fait d'avoir plusieurs instances du même service sur une même IP. \begin{figure}[!ht] \center \includegraphics[width=0.8\linewidth]{nat_ip_port.png} \caption{Redirection basée sur l'IP et le port} \end{figure} La redirection à un niveau supérieur de la communication (applicatif) sert au demultiplexage des services associés à une IP unique. Par exemple, l'http\footnote{Protocole utilisé pour la visualisation des sites web}. Ce type de redirection au niveau applicatif nécessite qu'une connexion soit déjà en place avec la passerelle. On parle alors de proxy\footnote{Système permettant une redirection au niveau applicatif}. Afin de limiter l'utilisation de la passerelle à son but premier (gestion des communications), l'instance du serveur web Apache qui est utilisé en tant que proxy n'est pas localisée sur la passerelle, mais sur une machine virtuelle séparée. \begin{figure}[!h] \center \includegraphics[width=0.8\linewidth]{nat_dns.png} \caption{Redirection au niveau applicatif} \end{figure} L'avantage de l'utilisation d'un proxy est que, de par son utilisation sur la couche applicative, il ne nécessite pas d'utiliser plusieurs IPs. Si l'on se place au niveau connexion, la passerelle n'a pas connaissance de la présence éventuelle d'un nom de domaine dans la communication, elle ne peut donc pas rediriger la communication en se basant sur cet élément. Bien que ce ne soit pas la solution mise en oeuvre, il reste possible d'utiliser différents ports pour les connexions http, ce qui est contraignant, car l'utilisateur est obligé de spécifier le port à chaque fois\footnote{Par défaut, les ports 80 ou 443 sont utilisés pour les connexions http ou https}. En résumé, on utilise 3 méthodes pour la reconnaissance des communications : \begin{bigcenter} \begin{tabular}{|p{5cm}|p{5cm}|p{5cm}|} \hline Identification & Avantages & Inconvénients\\ \hline 1 IP publique = 1 redirection & Redirection simple et indépendante du service & Consommation importante d'adresses IP publiques\\ \hline 1 couple IP, port = 1 redirection & Consommation plus faible d'adresses IP publiques & Obligation du client de spécifier le port\\ \hline 1 Nom de domaine = 1 redirection & 1 seule adresse IP nécessaire & Obligation d'un proxy par application sur la passerelle\\ && Difficulté d'identification pour les autres services\\ \hline \end{tabular} \end{bigcenter} \subsubsection{Le filtrage des communications} Afin de sécuriser les accès au réseau interne, on profite de la centralisation des communications sur la passerelle pour y configurer un outil de filtrage. L'outil utilisé est le logiciel \emph{netfilter} présent par défaut sur le système. On l'utilise à travers l'interface \emph{iptables}. Celle-ci n'étant pas très ergonomique (une suite de règles n'est pas très lisible), on utilise le logiciel Shorewall, qui permet de décrire de manière plus compréhensible la configuration, en découpant celle-ci par hôte. A chaque lancement, celui-ci se chargera de générer les règles pour \emph{iptables}. Les serveurs hébergeant des services de confiance, tout le trafic sortant est autorisé par défaut. Le but du filtrage est de sécuriser au maximum les connexions aux serveurs du réseau. Pour cela, on se base sur le principe de la liste blanche : toute communication entre Internet et le réseau interne est interdite par défaut. Les communications autorisées sont rajoutées explicitement dans les règles. Cependant, même si c'est une première sécurité, cela ne permet pas de sécuriser, par exemple, les failles applicatives. Les services standards (ils sont complétés en fonction du déploiement) autorisées sont:\\ \begin{itemize} \item web (http, https) \item ssh \item mail (pop(s), smtp(s), imap(s)) \item gestionnaire de sources (svn, git, mercurial) \item autres connexions à un serveur de jeu\\ \end{itemize} Shorewall découpe la configuration par hôte. Pour chaque hôte, un répertoire différent est utilisé, contenant 2 fichiers \emph{params} et \emph{rules}. Le premier défini les variables, le second les règles à appliquer : \begin{lstlisting}[caption=Fichier de définition des variables] PUBLIC4=1.2.3.4 \end{lstlisting} \begin{lstlisting}[caption=Fichier de définition des règles] ACCEPT net $FW:${PUBLIC4:-.} DNAT net loc:192.168.25.113 tcp http,https - ${PUBLIC4:-.} DNAT net loc:192.168.25.110:22 tcp 22110 - ${PUBLIC4:-.} DNAT net loc:192.168.25.114:22 tcp 22114 - ${PUBLIC4:-.} DNAT net loc:192.168.25.115:22 tcp 22115 - ${PUBLIC4:-.} \end{lstlisting} Ces fichiers de configuration attribuent l'adresse IP publique 1.2.3.4 à l'hôte, et mettent en place 4 règles de redirection. Tous ces fichiers sont inclus via la directive \emph{INCLUDE} dans le fichier \emph{/etc/shorewall/rules}. Afin de permettre l'utilisation du VPN, on ajoute au firewall une interface utilisée pour le tunnel. Cela s'effectue par l'ajout de la ligne : \begin{lstlisting} loc tun0 - dhcp,tcpflags,nosmurfs \end{lstlisting} dans le fichier de configuration des interfaces. L'interface \emph{tun0}, créée par le client VPN, est ainsi reconnue comme faisant partie de la zone locale. Pour faciliter l'administration, on ajoute une règle permettant d'utiliser les adresses publiques à partir du réseau privé. Cela revient à autoriser une connexion du LAN vers le LAN, en passant par les interfaces publiques. Cela s'effectue par l'ajout d'une règle de la forme : \begin{lstlisting} DNAT all-+ loc:192.168.25.110 tcp ssh,http,https - \${PUBLIC4:-.} \end{lstlisting} Ceci précise que, si l'on essaie d'accéder à l'adresse définie dans la variable PUBLIC4, on sera redirigé sur l'adresse interne \emph{192.168.25.100} (comme c'était déjà le cas précédemment). La directive 'all-+' permet de préciser que cette règle doit également être appliquée lorsqu'on essaie d'utiliser les adresse IP publiques à partir du LAN. \section{VPN} \hypertarget{VPN}{Les serveurs} de chaque site ont une adresse IP privée et constituent un LAN (Local Area Network). Ces réseaux, privés, sont interconnectés entre eux au travers de l'Internet. Pour communiquer entre deux serveurs situés dans deux centres différents, il est nécessaire d'utiliser les connexions publiques, ce qui complique les communications. Il serait en outre impossible d'utiliser les noms d'hôtes ou les IP internes. De même, pour accéder à des fonctionnalités étendues, il serait nécessaire de définir de nombreuses règles supplémentaires sur les firewalls. Par exemple, si l'on souhaite sauvegarder des informations contenues sur un serveur du premier centre sur un des serveurs du deuxième centre, tout en interdisant l'accès à ce serveur de sauvegarde à partir de l'Internet, il faudra rajouter une règle dans les firewalls afin d'autoriser \emph{seulement} les transferts venant du centre 1. Ceci pose également le problème que si, au sein d'un même centre, plusieurs serveurs essaient d'accéder au serveur de sauvegarde, il devient compliqué de n'en autoriser que certains, car tous les serveurs du premier centre seront vus comme un seul serveur sur l'Internet (à moins d'attribuer plusieurs IP publiques). \begin{figure}[!h] \center \includegraphics[width=\linewidth]{fw_sans_vpn.png} \caption{Les communications entre les centres traversent l'Internet} \end{figure} Dans le schéma ci-dessus, on voit bien que pour le deuxième centre, la seule IP connue est 1.2.3.4, il est donc difficile de n'autoriser que certains des serveurs présents dans le premier centre, car ils partagent tous la même IP. Cela oblige de restreindre les accès en sortie sur le firewall du centre 1. Un autre problème du point de vue de la sécurité est que tout transfert d'informations entre les deux centres se fait à travers Internet. Il est donc nécessaire de chiffrer chaque communication entre les deux centres, ce qui représente une augmentation de la complexité de configuration. Il serait en plus souhaitable d'utiliser des mécanismes d'authentification des machines afin de parer à des attaques de type spoofing\footnote{Une personne tierce pourrait prétendre être 1.2.3.4}. Afin de remédier à ces divers problèmes (complexité de mise en oeuvre, regroupement des serveurs sous une même IP, etc), on utilise un VPN. Ce système permet de créer une connexion chiffrée et permanente entre les deux centres (plus exactement, entre les deux passerelles), et d'y faire communiquer les serveurs de chaque centre de façon transparente. Cela revient à abstraire l'existence d'Internet, on se retrouve alors dans la même situation que si tous les serveurs étaient dans le même réseau privé. L'utilisation d'un VPN présente les avantages suivants :\\ \begin{itemize} \item Toutes les communications sont automatiquement chiffrées \item Les passerelles de chaque centre sont authentifiées, pour empêcher tout intrus de rejoindre le VPN \item Les adresses internes sont communiquées de part et d'autre du réseau (on peut donc identifier chaque serveur / machine virtuelle individuellement via son adresse privée)\\ \end{itemize} \begin{figure}[!h] \center \includegraphics[width=0.85\linewidth]{fw_avec_vpn.png} \caption{Les communications entre les centres traversent l'Internet via un VPN} \end{figure} En pratique, la configuration utilisée est la suivante :\\ \begin{itemize} \item Premier centre : plage d'IP 192.168.25.0/24 \item Deuxième centre : plage d'IP 192.168.30.0/24 \item Serveur VPN : 192.168.181.19 \item Passerelles : 192.168.25/30.254 \item Passerelles "spare" : 192.168.25/30.253\\ \end{itemize} Chaque passerelle est authentifiée à l'aide d'une clé RSA unique. Un utilisateur extérieur qui souhaiterait se connecter au VPN se verra rejeté, même dans l'hypothèse où il usurpe l'adresse IP d'une passerelle. Cette clé est générée par les outils fournis avec l'utilitaire OpenVPN\footnote{http://openvpn.net/}, disponibles dans \emph{/etc/openvpn/2.0}. Afin de limiter la configuration sur le client, un fichier décrivant les règles de routage est créé par client et stocké dans \emph{/etc/openvpn/ccd}. Il contient la liste des routes devant être ajoutées sur le poste se connectant au VPN. Ces configurations sont ensuite récupérées et installées dynamiquement au démarrage du client VPN. \begin{lstlisting}[caption=Configuration du routage par client] push "route 192.168.14.0 255.255.255.0" push "route 192.168.25.0 255.255.255.0" push "route 192.168.29.0 255.255.255.0" push "route 192.168.181.0 255.255.255.0" \end{lstlisting} Le fichier de configuration précédent donne accès à 4 nouveaux réseaux à travers l'interface du VPN. Le mécanisme CCD\footnote{Client config directory} permet de n'activer que certaines routes sur les clients, en plus de minimiser la configuration client. Lorsqu'un nouvel administrateur réseau est recruté et doit se connecter au VPN, il lui suffit de récupérer la configuration fournie par défaut, de copier la clé qui lui aura été attribuée dans \emph{/etc/openvpn/client.crt} ainsi que le certificat du serveur dans \emph{/etc/openvpn/ca.crt}, et enfin de spécifier le serveur distant via la directive \emph{remote-server} dans \emph{/etc/openvpn/client.conf}. Une fois ces manipulations effectuées, il suffit simplement de redémarrer le démon OpenVPN. L'opération est la même pour ajouter un nouveau centre au VPN. Une interface \emph{tun0} est créée sur le système, et les routes définies dans la configuration client sont ajoutées sur cette interface. \section{DHCP} Le réseau de chaque machine est configuré soit:\\ \begin{itemize} \item Configuration en dur \item Configuration distribuée à l'aide d'un serveur DHCP\\ \end{itemize} La méthode manuelle assure que la configuration réseau correspondra à celle explicitement décrite dans le fichier de configuration. Elle implique cependant de se souvenir de la configuration de chaque serveur afin de ne pas se retrouver avec deux serveurs ayant les mêmes paramètres. La configuration automatisée par DHCP permet d'avoir une gestion centralisée, donc plus facile à maintenir. Utiliser le protocole DHCP pour la configuration du réseau au démarrage nécessite de plus qu'un service soit capable d'assurer la communication avec le serveur DHCP. Dans le cas contraire, la machine physique risquerait de se retrouver hors du réseau, et donc injoignable pour l'administration, ce qui impliquerait le déplacement d'un personnel. Afin de limiter ce risque, les machines physiques sont configurées de façon à ne pas utiliser le DHCP. En revanche, toutes les machines virtuelles utilisent ce service. En effet, même en cas de panne du client DHCP, il est toujours possible pour l'administrateur de se connecter à la machine physique, et donc d'administrer les machines virtuelles. Cela implique que le serveur DHCP n'attribue pas les adresses IP utilisées pour les configurations statiques (des plages sont réservées à cet effet). \begin{figure}[!h] \center \includegraphics[width=\linewidth]{dhcp.png} \caption{La configuration DHCP est centralisée et versionnée} \end{figure} Afin de limiter la problématique due à la maintenance de multiples configurations tout en assurant un minimum d'indépendance des différents serveurs DHCP (chaque instance doit en effet être capable de fonctionner même sans la présence du ou des serveurs maîtres), nous utilisons l'outil de gestion de sources Mercurial\footnote{http://www.selenic.com/mercurial}. Il permet de versionner l'évolution de fichiers au fil du temps. Décentralisé, il est capable de posséder plusieurs copies du dépôt à plusieurs endroits, et de les synchroniser entre elles. Les copies du dépôt servant de référence pour la configuration DHCP sont partagées via un export NFS\footnote{Protocole permettant l'export d'un répertoire à travers le réseau}. Il suffit d'ajouter une ligne de configuration sur les "clients"\footnote{Le système étant décentralisé, la notion de serveur et de client est conventionelle} pour pouvoir synchroniser la version locale et la version distante, sans avoir à posséder une authentification sur le serveur distant. Cette opération est faite une seule fois, à l'installation d'un nouveau centre. Le partage NFS passe par le VPN ce qui permet de n'autoriser que les adresses du réseau local et empêche toute connexion directe à partir d'une IP publique (venant de l'Internet). La configuration du serveur DHCP ressemble à : \begin{lstlisting} group { option routers rentre.tld.; option domain-name-servers rentre.tld; subnet 192.168.29.0 netmask 255.255.255.0 { } host dnsslave.rentre { hardware ethernet 52:26:84:A3:28:19; fixed-address dnsslave.rentre.tld.; } host pokme.rentre { hardware ethernet 00:fa:70:47:9d:7d; fixed-address pokme.rentre.tld.; } host jaula.rentre { hardware ethernet 00:aa:b9:f2:3e:b5; fixed-address jaula.rentre.tld.; } host proxy.rentre { hardware ethernet 00:7f:78:8e:78:dc; fixed-address proxy.rentre.tld.; } } \end{lstlisting} Dans cet exemple, on voit que le sous-réseau 192.168.29.0/24 est utilisé pour la machine \emph{rentre.tld}. Chaque machine virtuelle est identifiée par une section \emph{host}, spécifiant l'adresse matérielle de l'interface virtuelle ainsi que son nom de domaine complet. Ceci assure qu'une même machine virtuelle possédera toujours une même IP. La directive \emph{fixed-address} recherche (soit dans le fichier \emph{/etc/hosts}, soit via une requête DNS) une correspondance nom de domaine / IP existante pour le nom associé. Si cette association existe, alors le DHCP attribue l'adresse IP correspondante à cet hôte. En définissant seulement la correspondance nom de domaine / IP dans la configuration du serveur DNS, on assure une configuration réseau par DHCP ainsi qu'une résolution de nom correcte. Cette configuration est stockée sur un dépôt Mercurial partagée sur différents hôtes via NFS. Le montage du partage NFS s'effectue, via la commande \emph{mount}, seulement lorsque l'administrateur en a besoin. Ce montage est configuré dans le fichier \emph{/etc/fstab} : \begin{lstlisting} rentre.tld:/etc/dhcp3 /mnt/rentre.tld/etc/dhcp3 nfs tcp,noauto 0 0 snif.tld:/etc/dhcp3 /mnt/snif.tld/etc/dhcp3 nfs tcp,noauto 0 0 \end{lstlisting} Les deux répertoires de configuration des serveurs "maîtres" sont montés dans \emph{/mnt/$<$hote$>$/etc/dhcp3}, ce qui permet ensuite la synchronisation des configurations via Mercurial. \section{DNS} Lorsqu'un grand nombre d'ordinateurs/serveurs sont utilisés, il devient difficile de nommer chaque serveur par son adresse IP. Pour éviter cela, un service DNS\footnote{domain name system} est utilisé. Celui-ci permet d'associer l'adresse IP de chaque serveur à un nom, en suivant une hiérarchie de nommage. La configuration est la suivante : le TLD\footnote{top level domain, le nom de domaine de plus haut niveau} utilisé est \emph{tld.}. Ensuite, chaque machine posséde un nom unique, l'associant à son adresse IP. Son nom complet est donc de la forme \emph{nommachine.tld}. Les machines hébergeant des machines virtuelles, possédant leur propre adresse IP, ont un enregistrement supplémentaire par machine virtuelle, de la forme \emph{machinevirtuelle.machine.tld}. On trouve donc dans la configuration DNS des informations sous la forme : \begin{lstlisting} rentre IN A 192.168.29.1 dnsslave.rentre IN A 192.168.29.2 proxy.rentre IN A 192.168.29.3 pokme.rentre IN A 192.168.29.4 jaula.rentre IN A 192.168.29.5 \end{lstlisting} Ces informations correspondent aux machines virtuelles dont la configuration DHCP a été décrite précédemment. On voit donc ici que la machine principale \emph{rentre.tld} possède l'adresse IP \emph{192.168.29.1}. Les machines virtuelles hébergées sur le serveur \emph{rentre} possédent les adresses \emph{192.168.29.2} à \emph{192.168.29.5}. Si le DNS permet de faire l'association nom de domaine $\rightarrow$ IP, il doit aussi permettre de faire l'association inverse. En effet, on peut avoir plusieurs noms de domaine par IP, ou plusieurs IP pour un nom de domaine. Pour cela, on configure les enregistrements inverses : \begin{lstlisting} 192.168.29.1 IN NS rentre 192.168.29.2 IN NS dnsslave.rentre 192.168.29.3 IN NS proxy.rentre 192.168.29.4 IN NS pokme.rentre 192.168.29.5 IN NS jaula.rentre \end{lstlisting} On sait alors que l'adresse IP \emph{192.168.29.2} correspond à l'hôte \emph{dnsslave.rentre.tld}. Toujours dans l'optique de la centralisation des configurations préservant la disponibilité du service, nous utilisons les capacités de réplication proposées par le serveur DNS BIND. La configuration pour la totalité du réseau VPN est hébergée sur un serveur DNS global. Chaque centre d'hébergement fait tourner son propre serveur DNS, qui se contente de synchroniser sa configuration sur le serveur maître. Cela permet , même en cas de coupure de liaison avec le serveur DNS principal, d'obtenir l'information depuis le DNS esclave fonctionnel sur chaque centre. Chaque passerelle (\emph{192.168.25/30.254} et \emph{192.168.25/30.253}) possède une instance du serveur BIND utilisable uniquement par son réseau interne. Afin d'éviter l'exploitation du serveur BIND pour des attaques de type déni de service, la récursion\footnote{Un serveur DNS peut résoudre les domaines qu'il ne connaît pas en délégant la requête aux serveurs ayant autorité sur les TLD correspondant} a été désactivée. En cas de panne du serveur DNS maître, le serveur DNS esclave est sollicité. Il est déclaré dans les enregistrement DNS pour la zone, il sera automatiquement utilisé si le serveur maître est injoignable. Le serveur maître synchronise les informations sur les noms de domaines directement via un protocole interne. La configuration de la zone d'un serveur esclave utilisé dans le VPN est : \begin{lstlisting} zone "tld." { type slave; file "tld"; masters { 192.168.181.19; }; }; \end{lstlisting} \section{Les outils de supervision} Il est impossible pour un administrateur réseau de superviser manuellement la totalité des ressources. Il lui faut un mécanisme d'alerte et un moyen de visualiser l'évolution des ressources. \subsection{Nagios} L'ordonnanceur de tâches Nagios a été choisi pour sa robustesse. Il permet à l'administrateur de programmer le lancement de tests à intervalle régulier sur les hôtes souhaités. Si jamais un résultat indiquant une défaillance est détecté, l'administrateur est averti par email, SMS, Jabber, IRC, etc. Les tests sont effectués en local (nombre de processus, d'utilisateurs connectés, charge processeur/mémoire, etc.) ou à distance (connectivité du serveur web, disponibilité d'un site ou d'une page web, fonctionnement d'un serveur mail, etc.). Des tests ont également été développés pour tester des services plus particuliers, dans le cas de protocoles spécifiques à des serveurs de jeu. On utilise au minimum les tests suivants :\\ \begin{itemize} \item Présence de la connectivité réseau (ping) \item Fonctionnement d'un serveur Web \item Fonctionnement du serveur DNS \item Fonctionnement du serveur mail \item Charge d'un serveur \item Accès ssh \item Serveur rsync \item Fonctionnement du serveur DHCP\\ \end{itemize} \begin{figure}[!ht] \center \href{http://www.soplo.cl/wp-content/uploads/2007/08/nagios_grande.jpg}{\includegraphics[width=\linewidth]{nagios.png}} \caption{Le serveur de supervision Nagios permet de monitorer l'intégralité du réseau} \end{figure} Chacun de ces tests est effectué sur un ou plusieurs serveurs, en fonction des services à tester. Suivant la fonction testée, les tests peuvent être effectués soit via le réseau interne (VPN), soit via l'accès externe (Internet). Cette deuxième solution est utilisée pour tester la vivacité d'un service accessible au public. Le VPN apporte, dans le cas de la première solution, une grande facilité d'administration, en permettant l'utilisation des noms d'hôtes et des IPs privées même entre les 2 sites distants. Si une erreur est détectée, une notification est émise à un contact à travers Jabber. Si le problème n'est pas réglé dans les 30 minutes, une notification par email est alors envoyée. Si cette configuration est ici utilisée pour tous les tests, il n'en reste pas moins possible de l'ajuster différemment pour chaque test. Nagios gère la hiérarchie réseau d'un site : si la passerelle d'un des sites tombe en panne, la totalité des services est interrompue. Nagios détecte cette situation et notifie l'administrateur seulement de la chute de la passerelle, évitant ainsi l'envoi massif de notifications pour chacun des services indisponibles. \subsection{Munin} En complément du superviseur Nagios, qui teste l'état des services à un moment donné, Munin garde un historique de l'état des systèmes. Il enregistre périodiquement les informations du système, telles que la charge système, l'occupation mémoire, le trafic réseau, mail ou web, etc. Un serveur est configuré sur le réseau et vérifie, périodiquement, la liste des noeuds sur lesquels il récupére des informations. Chaque noeud fournit des statistiques via un démon qui se charge d'envoyer les informations souhaitées à chaque connexion du serveur. Le serveur génère ensuite périodiquement les graphiques présentés sous forme de page web. Ce service utilise exclusivement les adresses internes, via le VPN, ce qui permet d'éviter la transmission de ces informations sur Internet. \begin{figure}[!ht] \center \href{http://waste.mandragor.org/munin_tutorial/overview.png}{\includegraphics[width=\linewidth]{munin.png}} \caption{Statistiques réseau présentées par Munin} \end{figure} %%% \chapter{La virtualisation} La virtualisation permet \og 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 \fg\footnote{http://fr.wikipedia.org/wiki/Virtualisation}. Suivant l'isolation souhaitée (isolation simple ou émulation du système), deux solutions ont été retenues. Une simple isolation crée juste un système dans un répertoire. Des services sont ensuite lancés au sein de ce système. Il n'y a pas de virtualisation du système, mais seulement un cloisonnement des applications. Pour utiliser ce cloisonnement, nous nous basons sur le service lxc\footnote{http://lxc.sourceforge.net/}. \begin{figure}[!ht] \center \href{http://dev.opennebula.org/attachments/35/arch.jpg}{\includegraphics[width=0.8\linewidth]{libvirt.png}} \caption{Fonctionnement du projet libvirt} \end{figure} Le principal inconvénient de cette technologie est la difficulté à gérer les ressources CPU et mémoire. On peut en effet souhaiter limiter précisément la quantité de ressources allouée à un système et aux applications y tournant. Avec les technologies de virtualisation, ce n'est plus le système qui est émulé, mais le serveur. Ceci permet une meilleure gestion de la séparation des processus et de la répartition de la charge. Pour cette technologie, les logiciels de virtualisation Xen et KVM sont utilisés. Dans les deux cas (machine virtuelle ou simple cloisonnement), l'application dispose d'une machine dédiée, et posséde un accès total sans risquer de mettre en danger les autres systèmes (hôtes ou hébergés) tournant sur la même machine physique. A quelques rares exceptions près (passerelle/firewall), les machines physiques hébergées ne servent qu'à gérer des machines virtuelles, qui hébergent les services. L'utilisation de Xen ou de KVM dépend des processeurs intégrés à la machine hôte. Les processeurs les plus récents possèdent un jeu d'instruction VT\footnote{Instructions optimisées pour la virtualisation}. Dans ce cas, on utilise le virtualiseur réel KVM. Dans le cas contraire, on utilise un paravirtualiseur (Xen). La gestion des machines virtuelles est effectuée à l'aide de la librairie \emph{libvirt}, qui implémente une API permettant de gérer des systèmes de virtualisation indépendemment du (para)virtualiseur utilisé. L'espace disque est géré via LVM\footnote{Gestionnaire de volumes logique}. Grâce à LVM on redimensionne dynamiquement une partition/un système de fichiers pour suivre la croissance des services. Le jour où une machine virtuelle nécessite un espace plus important que ce qui lui avait été alloué, il suffit - après éventuellement l'ajout d'un disque - de redimensionner sa partition, et ce de façon totalement transparente. Les fonctionnalité de 'snapshot' de LVM, sont utilisés pour faire des sauvegardes instantanées des systèmes. \chapter{Services utilisés sur les machines} \section{Serveur Web} L'application utilisée pour héberger les services web est Apache. Celui-ci peut donc héberger différents sites sur une même installation, et possède également des fonctionnalités plus poussées (interprétation des différents langages de scripts, utilisation en tant que proxy pour relayer les communications entre différents serveurs, etc). L'identification de chaque site se fait via son nom de domaine. Ceci est appelé une configuration par vhosts\footnote{hôte virtuel}. \section{Serveur de mail} Un serveur de mail permet de centraliser la gestion des mails des développeurs en leur fournissant une boîte mail propre au projet. Par ailleurs, un outil de gestion de liste de diffusion (mailman) est utilisé pour les listes de support et de développement. Le serveur de mail est un ensemble de plusieurs logiciels :\\ \begin{itemize} \item Serveur SMTP (postfix) : il permet la communication des mails entre les différents serveurs disponibles sur Internet \item Serveur POP/IMAP (dovecot) : ces protocoles permettent aux personnes (utilisateurs ou administrateurs) possédant un compte Web de visualiser leurs mails, que ce soit à l'aide d'un webmail ou via un client distant (thunderbird, evolution) \item Antispam : greffé sur le serveur SMTP, il permet le filtrage des spams. Le logiciel spamassassin est utilisé. La technologie du greylisting\footnote{Le mail est systématiquement refusé la première fois. Seuls les serveurs correctement configurés (ce qui est rarement le cas des serveurs de spam) renverront le mail} est utilisée lors de la réception d'un mail, ce qui permet de réduire grandement le nombre de spam à traiter. \item Antivirus : Le logiciel clamav analyse le contenu des mails et des pièces jointes, et détecte les éventuels virus.\\ \end{itemize} \clearpage \begin{figure}[!ht] \center \includegraphics[width=\linewidth]{mail.png} \caption{Récupération du serveur de mail pour un domaine} \end{figure} Afin d'éviter l'interruption de service en cas de panne du serveur mail primaire, un serveur secondaire est mis en place. L'organisation des serveurs mails se définit dans les enregistrement DNS. Une priorité est associée à chaque enregistrement de serveur. Le serveur avec la priorité la plus faible est utilisé tant qu'il est fonctionnel. Sinon, le serveur ayant la priorité supérieure sera utilisé. \clearpage \section{Base de données} Les bases de données sont nécessaires aux applications pour le stockage d'informations (serveur de jeu, compte email, compte système, statistiques, etc.) et l'interrogation rapide. Le SGBD\footnote{Système de gestion de base de données} utilisé est MySQL. Pour les applications nécessitant d'importantes ressources, le serveur MySQL est situé sur un serveur indépendant du serveur s'y connectant. Afin de tolérer une panne sur le serveur SQL, un serveur esclave est installé. Celui-ci se contente de synchroniser les données avec le serveur maître. Dans le cas d'une panne du serveur maître, un mécanisme de détection de panne\footnote{heartbeat + CARP} et de redondance permet au serveur de secours de prendre la place du serveur maître. \begin{figure}[!ht] \center \href{http://www.phpmyadmin.net/home_page/images/screenshots/main-page-small.png}{\includegraphics[width=\linewidth]{phpmyadmin.png}} \caption{PhpMyAdmin : l'administration d'une base de donnée via une interface Web} \end{figure} \clearpage \section{Serveur IRC} L'IRC\footnote{Internet relay chat} est un système de communication instantanée. Un réseau IRC est hébergé sur un serveur. Sur ce réseau, des utilisateurs s'enregistrent, communiquent entre eux ou parlent en groupe dans des salons de discussion. Coté administration, des limitations d'accès sont définies et des opérateurs au niveau de chaque canal contrôlent la participation aux salons de discussion. Certain d'entre eux ont le contrôle de la totalité du réseau. Ce réseau IRC sert à héberger des salons de support et de développement. \begin{figure}[!ht] \center \href{http://www.xchat.org/files/screenshots/xchat-269-winxp-clist.png}{\includegraphics[width=\linewidth]{xchat.png}} \caption{XChat - un des nombreux clients IRC} \end{figure} \clearpage \section{Autres services} En plus de ces services principaux, d'autres services viennent compléter l'installation. On peut noter les installations suivantes :\\ \begin{itemize} \item Serveur Wiki (outil de travail et d'expression communautaire) \item Serveur de fichier, distribution des fichiers à mettre à disposition du public (nouvelle release de logiciel) \item Serveur de jeu, permettant la gestion des inscrits, des parties, etc.\\ \end{itemize} \begin{figure}[!ht] \center \href{http://fr.wikipedia.org}{\includegraphics[width=\linewidth]{wikipedia.png}} \caption{Wikipedia : un projet communautaire autour d'un Wiki} \end{figure} \section{Sauvegarde} La sauvegarde permet, en cas de problème, de redémarrer les services dans un temps le plus court possible et aussi d'éviter les pertes de données. Les principaux paramètres pris en compte pour les sauvegardes sont la fréquence souhaitée et la quantité d'informations à sauvegarder. En dehors des technologies de réplication intégrées dans les logiciels (BIND, MySQL, etc.), nous utilisons 2 outils de sauvegardes :\\ \begin{itemize} \item Rsync \item DRBD\\ \end{itemize} Rsync est un outil permettant d'effectuer de la sauvegarde incrémentielle. Exécuté à intervalle régulier, il sauvegarde les fichiers ayant été modifiés depuis la dernière exécution. Avec l'option \emph{--link-dest}, un répertoire contenant l'intégralité du contenu est obtenu. En réalité, seuls les fichiers modifiés sont sauvegardés, les autres sont seulement reliés par des liens durs à la dernière version du fichier dans les sauvegardes précédentes. DRBD agit au niveau \emph{block device}\footnote{En dessous du système de fichiers}. Il synchronise deux partitions distantes (à travers le réseau) en temps réel, et de façon totalement transparente pour le système de fichier et, a fortiori, pour l'utilisateur. Si la partition est fréquemment utilisée (beaucoup d'écritures), la bande passante consommée peut être importante. La latence du réseau doit donc être la plus faible possible, dans ce cas DRBD est configuré en réseau local pour tirer parti du lien gigabit. Si la partition est faiblement utilisée la partition distante est placée sur un site physique différent afin de minimiser les pertes en cas d'accident. \chapter{Architecture} L'ensemble des techniques décrites dans les chapitres précédents font émerger des propriétés importantes de l'ensemble de l'installation. La politique de sécurité, par exemple, est induite des méthodes mises en place pour exploiter le VPN et les firewalls. Il est aussi possible de tirer des conclusions sur le matériel, les prestations et le travail nécessaire à la mise en place et à la maintenance de l'installation. \section{Postes de coût} Comme brièvement expliqué dans le début du document, l'installation d'une infrastructure réseau implique plusieurs postes de dépenses. Chaque poste est estimé proportionnellement à la dimension de l'infrastructure (avoir une seule baie n'a pas les mêmes implications que d'avoir 2 baies à 1200km d'écart). Les postes les plus importants sont au nombre de 4. Le premier est l'emploi d'un administrateur système. On estime qu'un administrateur est capable de gérer une baie, soit jusqu'à 40 serveurs. Dans l'infrastructure précédente, cela représente jusqu'à 400 machines virtuelles, qui doivent être capables de supporter 25 000 utilisateurs simultanés. Il est donc nécessaire d'avoir au moins un administrateur par site. Le deuxième point est intrinsèquement lié au premier, puisqu'il concerne la gestion des interventions sur site. Il est en effet important d'être capable de quantifier le temps passé à l'administration régulière des machines. En plus de ce temps, il faut pouvoir évaluer les probabilités de pannes impliquant de fait une intervention (distante ou locale) de l'administrateur, ce qui peut se calculer avec des variables telles que le MTBF\footnote{Temps moyen entre pannes, \href{http://fr.wikipedia.org/wiki/Temps_moyen_entre_pannes}{http://fr.wikipedia.org/wiki/Temps\_moyen\_entre\_pannes}}. Les deux derniers postes de dépenses concernent l'équipement matériel. On compte d'une part le coût de l'hébergement chez le fournisseur d'accès, et d'autre part le coût du matériel en lui-même (serveurs, switchs, cables, ventilations, etc.). \section{Gestion des risques} Une telle infrastructure a pour but de permettre à l'utilisateur d'exploiter un ou plusieurs services. Dans l'idéal, la disponibilité des services est permanente. Cependant, en pratique, plusieurs cas mènent à une interruption de service, dont :\\ \begin{itemize} \item Panne logicielle (ex : un processus est tué par le système suite à une fuite mémoire trop importante) \item Panne matérielle (ex : une alimentation tombe en panne) \item Piratage (ex : suite à l'exploitation d'une faille applicative, une machine virtuelle a été compromise) \item Sinistre (ex : un des centres prend feu, est inondé) \\ \end{itemize} \begin{figure}[!ht] \center \href{http://continuitysolutionsgroup.com/yahoo_site_admin/assets/images/fire.43112853.jpg}{\includegraphics[width=0.8\linewidth]{fire.png}} \caption{Un datacenter ayant pris feu} \end{figure} Dans chacun de ces cas, nous devons être capables de remettre en fonctionnement les services le plus rapidement possible. Une partie des processus est automatisée. Comme vu précédemment, la quasi-totalité des systèmes est répliquée. Les méthodes de réplications sont classées en 2 catégories :\\ \begin{itemize} \item Méthodes intégrées au logiciel (MySQL, BIND) \item Méthodes externes (DRBD, Rsync, Mercurial, LVM)\\ \end{itemize} \'Voici une sélection de scénarios de panne de différentes services. \subsection{Panne de BIND} Comme détaillé dans la section DNS, BIND possède son propre système de réplication, ainsi que sa propre gestion des priorités. Un serveur BIND est déclaré maître pour une zone, et d'autres serveurs (1 par centre) s'y synchronisent. En cas de panne du serveur BIND maître, l'évolution de la configuration sera impossible. Cependant, les serveurs esclaves seront automatiquement utilisés. Ils posséderont alors soit la dernière configuration, soit une des précédentes configurations enregistrées dans une période inférieure au TTL\footnote{Une zone DNS possède un paramètre TTL, permettant de spécifier la période entre deux mises à jour du client}. Tant que chaque réseau local a accès à au moins 1 serveur DNS, il n'y aura pas d'interruption de service. \subsection{Un serveur MySQL tombe} MySQL possède sont propre système de synchronisation et de réplication. Il est ainsi possible de paramétrer un nombre quelconque de serveurs se synchronisant automatiquement au serveur maître. Cependant, MySQL ne gère pas le balancement si jamais le serveur maître tombe en panne. L'application Heartbeat est utilisée : elle va détecter la chute du serveur et déclencher le mécanisme de balancement (via une IP partagée au travers de CARP). Le balancement est fait en quelques secondes, assurant une indisponibilité minimale. Lors du retour du serveur maître, le balancement inverse devra être effectué à la main, avec une synchronisation des serveurs. \begin{figure}[!ht] \center \href{http://upload.wikimedia.org/wikipedia/commons/thumb/c/c2/Clustering_mysql.png/250px-Clustering_mysql.png}{\includegraphics[width=0.4\linewidth]{mysql.png}} \caption{Architecture MySQL redondante} \end{figure} \subsection{La liaison entre les centres est coupée} Il est possible, pour une raison quelconque, que la liaison entre les différents centres soit coupée, sans pour autant que les centres soient déconnectés d'Internet. Cela implique que les services sont toujours accessibles publiquement, mais que chaque centre doit être capable de fonctionner de façon indépendante. Comme détaillé précédemment, les services critiques (DNS et DHCP) possèdent des instances sur les passerelles de chaque centre, ce qui assure une continuité de fonctionnement sur ce point. De même, tous les services de sauvegarde (snapshot LVM, DRBD ou Rsync) ne fonctionneront plus s'ils travaillaient avec un centre distant. Ceci n'empêchera pas le bon fonctionnement des services, mais entraînera une absence de sauvegarde récente en cas de panne d'un service. Dans la majorité des cas, les services refonctionneront d'eux-même. Cependant, dans certains cas (comme le serveur SQL vu ci-dessus), il pourra être nécessaire d'effectuer une synchronisation manuelle. De même, si des configurations sauvegardées via Mercurial sont modifiées, il faudra resynchroniser les différentes versions entre elles. On est alors dans une situation dite de \emph{split-brain}: à la suite d'une rupture de connexion, chacun des hôtes se considère comme le maître, et écrit donc de nouvelles données. Lors du retour de la connectivité, il est donc nécessaire de resynchroniser tous les sites entre eux, ce qui est infaisable de façon automatique. Une intervention humaine est nécessaire. Par ailleurs, suivant la panne, une intervention plus ou moins longue de l'administrateur sera nécessaire, afin au minimum de diagnostiquer le problème et, éventuellement, de remettre le système dans son état initial. \section{Gestion de la sécurité des réseaux} Tout système informatique est soumis, un jour ou l'autre, à des tentatives d'attaques visant soit à en prendre le contrôle, soit à en modifier le comportement / les données. Afin de minimiser ce risque de corruption, les serveurs sont isolés. L'utilisation conjointe d'un \hyperlink{firewall}{firewall} et du \hyperlink{VPN}{VPN} permet de minimiser les communications susceptibles d'être acceptées à partir d'Internet. Par ailleurs, le cloisonnement des applications dans les machines virtuelles assure que, même si une application est compromise, seule sa machine virtuelle risquera d'être modifiée, assurant la continuité de fonctionnement des autres éléments. Enfin, le système de sauvegarde par snapshot de LVM permettra de réinstaller la machine virtuelle dans un état cohérent sauvegardé avant la compromission. \end{document}