Étude d une architecture multi-sites, multi-services

Étude d une architecture multi-sites, multi-services 18 mai 2009

Résumé Ce document décrit la mise en place d une architecture d hébergement de services multisites. L architecture détaillée dans le présent document doit permettre d héberger différents éléments logiciels utilisés dans le cadre d un projet de grande envergure. Cette suite logicielle s appuie sur une architecture matérielle à la fois répartie géographiquement et au maximum centralisée (logiciellement) afin d en optimiser l administration. Suivant les services souhaités, les contraintes techniques varient entre les emplacements géographiques, et voire même au sein d un emplacement. L architecture établie permet d héberger tous les services et d assurer un support optimal des utilisateurs en nombre important.

Table des matières 1

Chapitre 1 Topologie de l installation Ce chapitre décrit l installation d un point de vue matériel, en prenant compte des contraintes pouvant amener à l installation d une telle infrastructure. 1.1 Topologie géographique La localiation géographique des centres serveurs est adaptée à l accueil de nombreux services en rapport avec l hébergement d un MMORPG 1 et devant être capable de supporter un grand nombre d utilisateurs, un des paramètres ayant été pris en compte est la localisation géographique. On distingue 2 grandes configurations : Installation centralisée en un seul lieu Pas d installation spare 2 ou installation située dans le même lieu. Installation spare situé dans un deuxième lieu. Installation fonctionnelle décentralisée sur n sites Installation spare dans des sites dédiés Mélange d installations principale et spare sur chaque site. La décision finale a été prise en fonction de plusieurs paramètres, parmi lesquels : humain : quelle présence humaine sur chaque zone, en combien de temps, etc... financier : coût d installation et de maintenance dans chaque centre par rapport à une installation centralisée technique : capacité d administration à distance? Interconnexion des centres? La configuration décrite dans ce document est donc celle répartissant l installation sur plusieurs sites. Dans un premier temps, seuls les services critiques 3 sont dupliqués ou sauvegardés. Cependant, l architecture multi-sites permettra d étendre à moindre coût les services spare des différents éléments. L installation est principalement déployée sur 2 sites, que nous appellerons centre 1 et centre 2. Afin de soutenir une charge plus importante ou de renforcer l accueil d un 1 Jeu en réseau massivement multi-joueurs 2 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 3 permettant le fonctionnement de l installation 2

zone ge ographique dans laquelle l audience est particulie rement forte, un autre centre sera de ploye sur le me me mode le. 1.2 Architecture mate rielle L architecture mate rielle est le premier e le ment pratique a prendre en compte, avant toute installation logicielle. La disposition physique des serveurs permettra d optimiser la re partition des services. Cette re partition tient compte de parame tres comme les performances du re seau sur chaque site. Nous posse dons 2 he bergements ayant chacun les caracte ristiques suivantes : Capacite d he bergement d une baie (40U) He bergement dans un datacenter professionnel, offrant une architecture capable de supporter la baie (e lectricite, refroidissement) Acce s 24h/24 7j/7 Connectivite 100Mbps ou 1Gbps pour une baie (baie relie e par fibre au re seau de l ope rateur) Chaque baie est configure e de la me me fac on. L he bergeur fourni suffisamment de PDU4 pour alimenter la totalite des e quipements de la baie ainsi que deux ports re seau sur un switch leur appartenant. Fig. 1.1 Baie ca ble e accueillant de ja quelques serveurs Un switch gigabit 48 ports est ensuite connecte au port fourni par l he bergeur. Un deuxie me switch, servant au re seau de monitoring (IPMI, Service Processor, KVM, etc...), 4 Power Distribution Unit 3

est connecté sur le précédent. Chaque serveur est donc connecté au réseau principal via un lien gigabit, et suivant les possibilités, 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 des services tels qu un firewall, un serveur DHCP ou DNS. Dans le but de limiter les SPOF 5, un second serveur est positionné afin de parer à la panne du serveur central. Cela implique d activer un port supplémentaire sur le switch du fournisseur, afin de permettre une connexion la plus redondante possible. Chaque site est ensuite connecté au réseau Internet via la connexion du fournisseur (celui ci assurant une connexion symétrique de 100Mbps). La configuration matérielle des serveurs hébergés est variée, suivant les besoins auxquels ils doivent répondre. Les sites ne sont pas connectés entre eux de façon directe (une liaison physique dédiée a un coût exorbitant et, le plus souvent, est inutile). Cependant, comme nous souhaitons interconnecter les différents sites, 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. Par ailleurs, dans une baie sans équipement d aération spécial, il n est pas possible de remplir entièrement la baie car ceci entraînerait une surchauffe des équipements. En effet, 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. On estime donc que, sans équipement de ventilation adapté (plateau, porte ventilée), il est plus raisonnable de laisser un emplacement libre tous les 4 emplacements. 5 Single Point Of Failure 4

L architecture d un centre ressemblera donc à ceci : Fig. 1.2 Architecture réseau de chaque centre 5

Chapitre 2 Les services utilisés en interne La gestion d un réseau hétérogène (que ce soit du point de vue de l architecture matérielle ou géographique) nécessite l utilisation d un certain nombre d outils. Ces outils ont pour but d assurer le fonctionnement, l administration et la sécurité du réseau. Les services utilisés sont le VPN 1, le DNS 2 et le DHCP 3 pour l administration, Nagios et Munin pour la supervision. Par ailleurs, chaque site est sécurisé par un firewall logiciel installé sur les serveurs frontaux. 2.1 Systèmes d exploitation La totalité des machines sera équipée d un système d exploitation GNU/Linux. Suivant les besoins de chaque machine, les versions utilisées pourront varier. On considérera cependant la configuration type suivante : Système d exploitation Debian Lenny Noyau en version 2.6 2.2 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. L avantage d avoir un point de passage unique est de pouvoir effectuer un filtrage sur les communications. Deux types d actions sont effectuées sur les communications, la redirection et le filtrage. La redirection des communications Seule la passerelle est visible de l Internet. Pour pouvoir utiliser les serveurs internes, les communications doivent être redirigées. Pour cela, la reconnaissance des communications peut être effectuée sur plusieurs critères dont : 1 Virtual Private Network, réseau privé virtuel 2 Domain Name System, gestion des correspondances nom/ip 3 Attribution automatique des IP et de la configuration réseau 6

Adresse IP Port Service utilisé Chaque combinaison d un ou plusieurs de ces paramètres peut permettre de rediriger la communication vers un serveur du réseau interne, sur un port choisi. Ce système est appelé NAT 4. Fig. 2.1 Redirection basée sur l IP L avantage principal de la redirection par IP est que le serveur 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. Fig. 2.2 Redirection basée sur l IP et le port Par ailleurs, il est également possible de rediriger à un niveau supérieur de la communication : le niveau applicatif. Par exemple, l http 5. 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 6. Des applications permettant le système de proxy existent pour de nombreux 4 Network address translation 5 Protocole utilisé pour la visualisation des sites web 6 Système permettant une redirection au niveau applicatif 7

protocole. Cependant, seul l http est actuellement utilisé. Par ailleurs, 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. Fig. 2.3 Redirection au niveau applicatif L avantage de l utilisation d un proxy est que, de part 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 retenue, il reste possible d utiliser différentes ports pour les connexions http, ce qui est contraignant, car l utilisateur est obligé de spécifier le port à chaque fois 7. En résumé, on comptabilise donc 3 méthodes pour permettre la reconnaissance des communications : Identification Avantages Inconvénients 1 IP publique = 1 redirection Redirection simple et Consommation importante indépendante du service d adresse IP publiques 1 couple IP, port = 1 redirection Consommation plus faible Obligation du client de d adresse IP publiques spécifier le port 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 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 netfilter présent par défaut sur le système. On l utilisera à travers l interface iptables. Celle-ci n étant pas forcément 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 7 Par défaut, les ports 80 ou 443 sont utilisés pour les connexions http ou https 8

générer les règles pour 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. Lorsque l on souhaite autoriser une communication, il est nécessaire de rajouter explicitement cette autorisation dans les règles. Cela assure qu une communication ne peut passer que si elle y a été autorisée. 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 : web (http, https) ssh mail (pop(s), smtp(s), imap(s)) gestionnaire de sources (svn, git, mercurial) autres connexions à un serveur de jeu Shorewall découpe la configuration par hôte. Pour chaque hôte, un répertoire différent est utilisé, contenant 2 fichiers params et rules. Le premier défini les variables, le second les règles à appliquer : PUBLIC4= 1. 2. 3. 4 Listing 2.1 Fichier de définition des variables Listing 2.2 Fichier de définition des règles ACCEPT net $FW: ${PUBLIC4:.} DNAT net l o c : 1 9 2. 1 6 8. 2 5. 1 1 3 tcp http, https ${PUBLIC4:.} DNAT net l o c : 1 9 2. 1 6 8. 2 5. 1 1 0 : 2 2 tcp 22110 ${PUBLIC4:.} DNAT net l o c : 1 9 2. 1 6 8. 2 5. 1 1 4 : 2 2 tcp 22114 ${PUBLIC4:.} DNAT net l o c : 1 9 2. 1 6 8. 2 5. 1 1 5 : 2 2 tcp 22115 ${PUBLIC4:.} 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 INCLUDE dans le fichier /etc/shorewall/rules. Afin de permettre l utilisation du VPN, il est nécessaire d ajouter au firewall une interface utilisée pour le tunnel. Cela s effectue par l ajout de la ligne : l o c tun0 dhcp, t c p f l a g s, nosmurfs dans le fichier de configuration des interfaces. L interface tun0, créée par le client VPN, est ainsi reconnue comme faisant partie de la zone locale. C est donc cette interface qui sera utilisée pour la connexion au VPN. Il ne reste de plus à ajouter 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 : DNAT a l l + l o c : 1 9 2. 1 6 8. 2 5. 1 1 0 tcp ssh, http, https ${PUBLIC4:.} 9

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 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. 2.3 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 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). Fig. 2.4 Les communications entre les centres traversent l Internet 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 10

une augmentation de la complexité de configuration. De même, il serait souhaitable d utiliser des mécanismes d authentification des machines afin de parer à des attaques de type spoofing 8. 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é. Cela présente de nombreux avantages, dont : Toutes les communications sont automatiquement chiffrées Les passerelles de chaque centre sont authentifiées, pour empêcher tout intru de rejoindre le VPN 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!) Fig. 2.5 Les communications entre les centres traversent l Internet via un VPN En pratique, la configuration utilisée est la suivante : Premier centre : plage d IP 192.168.25.0/24 Deuxième centre : plage d IP 192.168.30.0/24 Serveur VPN : 192.168.181.19 Passerelles : 192.168.25/30.254 Passerelles spare : 192.168.25/30.253 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 9, disponibles dans /etc/openvpn/2.0. 8 Une personne tierce pourrait prétendre être 1.2.3.4 9 http ://openvpn.net/ 11

De plus afin de limiter la configuration sur le client, un fichier décrivant les règles de routage est créé par client et stocké dans /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. Listing 2.3 Configuration du routage par client push route 1 9 2. 1 6 8. 1 4. 0 2 5 5. 2 5 5. 2 5 5. 0 push route 1 9 2. 1 6 8. 2 5. 0 2 5 5. 2 5 5. 2 5 5. 0 push route 1 9 2. 1 6 8. 2 9. 0 2 5 5. 2 5 5. 2 5 5. 0 push route 1 9 2. 1 6 8. 1 8 1. 0 2 5 5. 2 5 5. 2 5 5. 0 Le fichier de configuration précédent permet ainsi l accès à 4 nouveaux réseaux à travers l interface du VPN. L avantage de l utilisation du mécanisme CCD 10 est qu il permet de n activer que certaines routes sur les clients, en plus de minimiser la configuration client. Pour qu un client puisse 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 /etc/openvpn/client.crt ainsi que le certificat du serveur dans /etc/openvpn/ca.crt, et enfin de spécifier le serveur distant via la directive remote-server dans /etc/openvpn/client.conf. Une fois ces manipulations effectuées, il suffit de simplement redémarrer le démon OpenVPN. Une interface tun0 est ainsi créée sur le système, et les routes définies dans la configuration client sont ajoutées avec cette interface par défaut. 2.4 DHCP Il existe deux possibilités de configuration du réseau sur un ordinateur : Configuration en dur sur chaque ordinateur Configuration distribuée à l aide d un serveur DHCP Chaque méthode a ses avantages et inconvénients. 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 2 serveurs ayant les mêmes paramètres. La configuration automatisée par DHCP permet quant à elle d avoir une gestion centralisée, donc plus facile à maintenir. En revanche, il est important de faire attention à la configuration de façon a assurer qu une même machine obtiendra toujours les mêmes paramètres réseau. Dans le cas contraire, de nombreux problèmes pourraient survenir, tant au niveau de la résolution de noms que de la configuration de la passerelle (qui se base sur les adresses IP internes). 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 injoingnable 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, 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 en revanche que le serveur DHCP n attribue pas les adresses IP utilisées pour les configurations statiques. 10 Client config directory 12

Fig. 2.6 La configuration DHCP est centralisée et versionnée 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 11. Simple à installer, 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 entres elles de façon plus ou moins automatique. Cependant, la synchronisation à distance oblige à posséder un compte sur la machine distante, ce qui a pour effet d alourdir l administration. Pour faciliter l utilisation et l installation éventuelle de serveurs supplémentaires, les copies du dépôt servant de référence sont partagées via un export NFS 12. Ainsi, il suffit d ajouter une ligne de configuration sur les clients 13 pour pouvoir synchroniser la version locale et la version distante, sans avoir à posséder une authentification sur le serveur distant. Là encore, le VPN apporte un avantage, car il permet par exemple de n autoriser que les adresses du réseau local à utiliser les exports NFS, ce qui empêche toute connexion directe à partir d une IP publique (venant de l Internet). La configuration du serveur DHCP ressemble à : group { option r o u t e r s r e n t r e. t l d. ; option domain name s e r v e r s r e n t r e. t l d ; subnet 1 9 2. 1 6 8. 2 9. 0 netmask 2 5 5. 2 5 5. 2 5 5. 0 { } host d n s s l a v e. r e n t r e { hardware e t h e r n e t 5 2 : 2 6 : 8 4 : A3 : 2 8 : 1 9 ; f i x e d address d n s s l a v e. r e n t r e. t l d. ; } host pokme. r e n t r e { hardware e t h e r n e t 0 0 : f a : 7 0 : 4 7 : 9 d : 7 d ; f i x e d address pokme. r e n t r e. t l d. ; } 11 http ://www.selenic.com/mercurial 12 Protocole permettant l export d un répertoire à travers le réseau 13 Le système étant décentralisé, la notion de serveur et de client est purement symbolique 13

host j a u l a. r e n t r e { hardware e t h e r n e t 0 0 : aa : b9 : f 2 : 3 e : b5 ; f i x e d address j a u l a. r e n t r e. t l d. ; } } host proxy. r e n t r e { hardware e t h e r n e t 0 0 : 7 f : 7 8 : 8 e : 7 8 : dc ; f i x e d address proxy. r e n t r e. t l d. ; } Ici, on voit que le sous réseau 192.168.29.0/24 est utilisé pour la machine rentre.tld. Chaque machine virtuelle est identifiée par une section 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 fixed-address recherche (soit dans le fichier /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 donc 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 mount, seulement lorsque l administrateur en a besoin. Ce montage est configuré dans le fichier /etc/fstab : r e n t r e. t l d : / e t c /dhcp3 /mnt/ r e n t r e. t l d / e t c /dhcp3 n f s tcp, noauto 0 0 s n i f. t l d : / e t c /dhcp3 /mnt/ s n i f. t l d / e t c /dhcp3 n f s tcp, noauto 0 0 Les deux répertoires de configuration des serveurs maîtres sont montés dans /mnt/<hote>/etc/dhcp3 ce qui permet ensuite la synchronisation des configurations via Mercurial. 2.5 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 14 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 15 utilisé est tld.. Ensuite, chaque machine posséde un nom unique, l associant à son adresse IP. Son nom complet est donc de la forme 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 machinevirtuelle.mamachine.tld. On trouve donc dans la configuration DNS des informations sous la forme : r e n t r e IN A 1 9 2. 1 6 8. 2 9. 1 d n s s l a v e. r e n t r e IN A 1 9 2. 1 6 8. 2 9. 2 proxy. r e n t r e IN A 1 9 2. 1 6 8. 2 9. 3 pokme. r e n t r e IN A 1 9 2. 1 6 8. 2 9. 4 j a u l a. r e n t r e IN A 1 9 2. 1 6 8. 2 9. 5 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 rentre.tld posséde 14 domain name system 15 top level domain, le nom de domaine de plus haut niveau 14

l adresse IP 192.168.29.1. Les machines virtuelles hébergées sur le serveur rentre possédent les adresses 192.168.29.2 à 192.168.29.5. Par ailleurs, si le DNS permet de faire l association nom de domaine 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, il est nécessaire de configurer les enregistrements inverses : 1 9 2. 1 6 8. 2 9. 1 IN NS r e n t r e 1 9 2. 1 6 8. 2 9. 2 IN NS d n s s l a v e. r e n t r e 1 9 2. 1 6 8. 2 9. 3 IN NS proxy. r e n t r e 1 9 2. 1 6 8. 2 9. 4 IN NS pokme. r e n t r e 1 9 2. 1 6 8. 2 9. 5 IN NS j a u l a. r e n t r e On sait alors que l adresse IP 192.168.29.2 correspond à l hôte dnsslave.rentre.tld. Toujours dans l optique de la centralisation des configurations, nous utilisons les capacités de réplication proposées par le serveur DNS BIND. La configuration pour la totalité du réseau est hébergée sur un serveur DNS global. Chaque centre d hébergement possède 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, de posséder un service DNS fonctionnel sur chaque centre. En pratique, le DNS maître est situé sur la même machine que le serveur du VPN. Chaque passerelle (192.168.25/30.254 et 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 16 a été désactivée. En cas de panne du serveur DNS maître, un serveur DNS esclave existe. Celui ci étant déclaré dans les enregistrement DNS, 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 est assez simple : zone t l d. { type s l a v e ; f i l e t l d ; masters { 1 9 2. 1 6 8. 1 8 1. 1 9 ; } ; } ; 2.6 Les outils de supervisions Il est impossible pour un administrateur réseau de superviser manuellement la totalité d un tel système. Il lui faut un mécanisme d alerte et un moyen de visualiser l évolution des ressources. 2.6.1 Nagios L ordonnanceur de taches Nagios a été choisi car c est un des outils de supervisions les plus connus et robustes. Il permet à l administrateur de programmer le lancement de différents tests à intervalle régulier sur les hôtes souhaités. Si jamais un résultat indiquant 16 Un serveur DNS peut résoudre les domaines qu il ne connait pas en délégant la requête aux serveurs ayant autorité sur les TLD correspondant 15

une défaillance est détecté, l administrateur peut être averti par divers moyens (email, SMS, Jabber, IRC,etc...). Il existe des tests pour à peu près tous les services étant susceptibles de tourner sur un serveur. Ces tests peuvent être 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. On utilise au minimum les tests suivants : Présence de la connectivité réseau (ping) Fonctionnement d un serveur Web Fonctionnement du serveur DNS Fonctionnement du serveur mail Charge d un serveur Accès ssh Serveur rsync Fonctionnement du serveur DHCP Fig. 2.7 Le serveur de supervision Nagios permet de monitorer l intégralité du réseau 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 lorsqu il est nécessaire de tester la vivacité d un service 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. Dans le cas où 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 est par ailleurs capable de gérer la 16

hiérarchie réseau d un site. Si la passerelle d un des sites tombe en panne, la totalité des services est interrompue. Cependant, Nagios est capable de détecter cette situation, et de notifier l administrateur seulement de la chute de la passerelle, évitant ainsi l envoi massif de notification pour chacun des services indisponibles. 2.6.2 Munin En complément du superviseur Nagios, qui se contente de tester l état des services, le logiciel Munin permet de garder un historique de l état du système. Il permet de façon simple d enregistrer 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. Celui ci vérifie, périodiquement, la liste des noeuds sur lesquels il doit récupérer des informations et se connecte sur chacun d eux. Chaque noeud devant fournir des statistiques doit simplement posséder un démon à tourner, qui se chargera d envoyer les informations souhaitées à la 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. Fig. 2.8 Statistiques réseau présentées par Munin 17

Chapitre 3 La virtualisation La virtualisation permet 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 1. Suivant l isolation souhaitée (isolation simple ou émulation du système), deux solutions existent. 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 2. 1 http ://fr.wikipedia.org/wiki/virtualisation 2 http ://lxc.sourceforge.net/ Fig. 3.1 Fonctionnement du projet libvirt 18

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. Il existe pour cela 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 administrateur système a l impression de posséder une machine dédiée, et peut posséder un accès total sans risquer de mettre en danger les autres systèmes (hôtes ou hébergés). 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 3. Dans ce cas, l utilisation d un réel virtualiseur tel KVM est possible. Dans le cas contraire, l utilisation d un paravirtualiseur (Xen) sera plus adéquate. La gestion des machines virtuelles est effectuée à l aide de la librairie libvirt, qui propose une API permettant de gérer des systèmes de virtualisation indépendemment du (para)virtualiseur utilisé. L espace disque est quant à lui géré via LVM 4. Celui ci permet de dynamiquement redimensionner une partition/un système de fichiers. 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 returndimensionner sa partition, et ce de façon totalement transparente. LVM possède des fonctionnalité de snapshot, permettant des sauvegardes instantanées d un système. 3 Instructions optimisées pour la virtualisation 4 Gestionnaire de volumes logique 19

Chapitre 4 Services utilisés sur les machines 4.1 Serveur Web Une des premières applications d un serveur est souvent d héberger du contenu disponible via le protocole http (sites web). L application utilisé dans ce but est le logiciel Apache. Celui ci permet donc d héberger simplement 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, le plus souvent, via son nom de domaine. Ceci est appelé une configuration par vhosts 1. 4.2 Serveur de mail Un serveur de mail permet de centraliser la gestion des mails des développeurs en leur fournissant une boite 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 : Serveur SMTP (postfix) : il permet la communication des mails entre les différents serveurs disponibles sur Internet Serveur POP/IMAP (dovecot) : Ces protocoles permettent aux personnes possédant un compte Web de visualiser leurs mails, que ce soit à l aide d un webmail ou via un client distant (thunderbird, evolution) Antispam : Greffé sur le serveur SMTP, il permet le filtrage des spams. Le logiciel spamassassin est utilisé. La technologie du greylisting 2 est utilisée lors de la réception d un mail, ce qui permet de grandement réduire le nombre de spam à traiter. Antivirus : Le logiciel clamav permet d analyser le contenu des mails et des pièces jointes, afin de détecter des éventuels virus. 1 hôte virtuel 2 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 20

Fig. 4.1 Récupération du serveur de mail pour un domaine 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 avec la priorité supérieur sera utilisé. 21

4.3 Base de données Les bases de données sont les systèmes les plus utilisés pour le stockage d informations (compte email, compte système, statistiques, etc...). Le SGBD 3 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 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 4 et de redondance permet au serveur de secours de prendre la place du serveur maître. Fig. 4.2 PhpMyAdmin : l administration d une base de donnée via une interface Web 3 Système de gestion de base de données 4 heartbeat + CARP 22

4.4 Serveur IRC L IRC 5 est un système de communication instantanée assez répandu. Un réseau IRC est hébergé sur un serveur. Sur ce réseau, il est possible d enregistrer des utilisateurs et des salons de discussion. Chaque salon peut alors être rejoint par un nombre quelconque de personnes. Il est également possible d utiliser le réseau pour des communications privées (2 personnes). Coté administration, nou avons la possibilité de définir des limitations d accès et des opérateurs au niveau de chaque canal ainsi que sur la totalité du réseau. Ce réseau IRC sert donc à héberger des salons de support et de développement. Fig. 4.3 XChat - un des nombreux clients IRC 5 Internet relay chat 23

4.5 Autres services En plus de ces services principaux, d autres services viennent compléter l installation. On peut noter les installations suivantes : Serveur Wiki (outil de travail et d expression communautaire) Serveur de fichier, permet une gestion des fichiers à mettre à disposition du public Serveur de jeu, permettant la gestion des inscrits, des parties, etc... Fig. 4.4 Wikipedia : un immense projet communautaire autour d un Wiki 4.6 Sauvegarde La sauvegarde est un des points importants de tout système. Elle permet, en cas de problème, de redémarrer les services dans un temps le plus court possible et, surtout, d éviter les pertes de données. Le principal paramètre pris en compte pour la sauvegarde est la fréquence souhaitée et la quantité d information à sauvegarder. En dehors des technologies de réplication intégrées dans les logiciels (BIND, MySQL, etc...), nous utilisons 2 outils de sauvegardes : Rsync DRBD 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 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 liés par des liens dur à la dernière version du fichier dans les sauvegardes précédentes. DRBD agit au niveau block device 6. Il est capable de synchroniser 2 partitions distantes 6 En dessous du système de fichiers 24

(à travers le réseau) en temps réel, et de façon totalement transparente pour le système de fichier et, à fortiori, pour l utilisateur. Cependant, 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. Pour toute ces raisons, il est nécessaire de l utiliser soit en réseau local (lien gigabit), soit à distance mais sur une partition à faible fréquence d écriture. 25

Chapitre 5 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. 5.1 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 doit être 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 capable de supporter 25000 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 1. 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...). 5.2 Gestion des risques Une telle infrastructure a pour but de permettre à l utilisateur d utiliser un ou plusieurs services. Dans l idéal, la disponibilité des services est permanente. Cependant, en pratique, plusieurs cas peuvent amener à une interruption de service, dont : 1 Temps moyen entre pannes, http ://fr.wikipedia.org/wiki/temps moyen entre pannes 26

Panne logicielle (ex : un processus est tue par le syste me suite a une fuite me moire trop importante) Panne mate rielle (ex : une alimentation tombe en panne) Piratage (ex : Suite a l exploitation d une faille applicative, une machine virtuelle a e te compromise) Sinistre (ex : Un des centre prend feu, est inonde ) Fig. 5.1 Un datacenter ayant pris feu Dans chacun de ces cas, nous devons e tre capable de remettre en fonctionnement les services le plus rapidement possible. Une partie des processus est automatise e. Comme vu pre ce demment, la quasi totalite des syste mes est re plique e. Les me thodes de re plications sont classe es dans 2 cate gories : Me thodes inte gre es au logiciel (MySQL, BIND) Me thodes externes (DRBD, Rsync, Mercurial, LVM) E tudions donc brie vement ce qu il se passera en cas de panne de diffe rentes services. 5.2.1 Panne de BIND Comme de taille dans la section DNS, BIND posse de son propre syste me de re plication, ainsi que sa propre gestion des priorite s. Un serveur BIND est de clare 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 e volution de la configuration sera impossible. Cependant, les serveurs esclaves seront automatiquement utilise s. Ils posse deront alors soit la dernie re configuration, soit une des pre ce dentes configurations enregistre es dans une pe riode infe rieure au TTL2. 2 Une zone DNS posse de un parame tre TTL, permettant de spe cifier la pe riode entre deux mises a jour du client 27

Tant que chaque réseau local a accès à au moins 1 serveur DNS, il ne devrait donc pas y avoir d interruption de ce service. 5.2.2 Un serveur MySQL tombe La base de donnée est une des pièces maîtresse des architectures publiques. Une fois encore, ce SGBD possède sont propre système de synchronisation. 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 alors utilisée. Elle va permettre de détecter la chute du serveur, et de déclencher le mécanisme de balancement (via, par exemple, une IP partagée au travers de CARP). Le balancement peut être fait en quelques secondes, en assurant une perte de données minimale. Cependant, lors du retour du serveur maître, le balancement inverse devra être effectué à la main, avec une synchronisation des serveurs. Fig. 5.2 Architecture MySQL redondante 5.2.3 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 instantes 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 si ils travaillaient avec un centre distant. Ceci n empêchera cependant 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 certain 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. Il existe également des situations dites split-brain. Celles ci apparaissent quand, à la suite d une rupture de 28

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. Tout ceci implique donc, au minimum, une configuration adéquate des systèmes pour assurer un fonctionnement le plus permanent possible. Par ailleurs, suivant la panne, une intervention plus ou moins longue de l administrateur sera nécessaire, afin d au minimum diagnostiquer le problème, et éventuellement de remettre le système dans son état initial. 5.3 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 au maximum. En effet, l utilisation conjointe d un firewall et du 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. 29