Restructuration et consolidation de services informatiques par la virtualisation

Transcription

1 Restructuration et consolidation de services informatiques par la virtualisation Yann Dupont Michel Allemand Arnaud Abelard Jacky Carimalo CRI de l'université de Nantes 2, rue de la Houssinière, Nantes Yann.Dupont univ-nantes.fr CRI de l'université de Nantes 2, rue de la Houssinière, Nantes Arnaud.Abelard univ-nantes.fr CRI de l'université de Nantes 2, rue de la Houssinière, Nantes Michel.Allemand univ-nantes.fr CRI de l'université de Nantes 2, rue de la Houssinière, Nantes Jacky.Carimalo univ-nantes.fr Résumé Cet article est un retour d'expérience sur des techniques de virtualisation qui ont progressivement été introduites au CRI de l'université de Nantes. Les techniques utilisées concernent les systèmes (Linuxvserver, XEN), le stockage (EVMS), ainsi que le réseau et la disponibilité des systèmes (cluster Ultramonkey). Ces techniques ont permis d'augmenter la disponibilité de nos services, et d'en déployer de nouveaux. D'une manière générale, nous avons pu changer notre infrastructure de façon radicale. Néanmoins certaines de ces techniques peuvent induire des risques ou des difficultés, et il sera expliqué comment les prévenir. Mots clefs Le principe choisi est de partir des données utilisateurs qui sont considérées comme absolument vitales et placées comme élément central de notre réflexion. Les serveurs sont alors considérés uniquement comme un moyen d'accès ou de transformation de ces données. Les chemins doivent être nombreux, pour prévenir les pannes, et accéder rapidement aux informations. Ajouter ou remplacer un chemin (en clair, ajouter ou remplacer un serveur) doit être simple et rapide. Par exemple, dans le cadre du courrier électronique, il est préférable de perdre temporairement un des accès à ses données que de perdre temporairement ses données (mais avoir accès aux services). Cette idée de centralisation et de sécurisation des données a naturellement induit l'idée de s'équiper d'un SAN. Par rapport aux objectifs cités au paragraphe précédent, la solution choisie est de sur-simplifier les configurations des serveurs (principe du KISS1) ; pour cela, l'option choisie est de séparer tous les services entre eux, pour n'avoir plus qu'un seul service par serveur. La fiabilité des services va s'obtenir en déployant plusieurs serveurs ayant la même fonction. En tenant compte de ces volontés, se pose alors le problème de la forte augmentation prévisible du nombre de serveurs. Et inévitablement des coûts induits. Virtualisation, haute disponibilité, SAN, Linux. 1 Introduction En janvier 2003, le parc de machines du CRI se résumait à quelques machines obsolètes, de type PC, ainsi que quelques «vrais» serveurs. Les services étaient déployés de façon anarchique, souvent pour des raisons historiques. Le nombre de services à déployer était nettement plus important que le nombre de machines physiques, de nombreux services se trouvaient ainsi co-déployés sur des même machines et les effets de bord étaient monnaie courante. La sécurité était faible en cas de faille de sécurité d'un des services. Le manque de plate-forme de test était aussi ressenti. Certains serveurs étaient sous-utilisés et d'autres saturés, que ce soit au niveau de leur puissance de traitement ou au niveau de l'espace disque utilisé. Enfin, en cas de panne d'une des machines, de nombreux services devenaient indisponibles simultanément. Le besoin d'une restructuration profonde pour consolider nos services était donc très clair. 1.1 Objectifs Les objectifs tenaient en quelques points : Augmenter la fiabilité des services rendus. Augmenter le niveau de sécurité et de sûreté du système d'information. Isoler au mieux les services entre eux. Mieux partager la charge de travail entre les serveurs. Gérer au mieux les données sur l'espace disque, sans les cantonner à un serveur. Mettre en adéquation les serveurs avec les tâches qui leur sont confiées. Les caractéristiques des serveurs à prendre en compte étaient les suivantes: - génération (âge du serveur) et puissance. - capacité de redondance. - niveau de garantie. Respecter le budget du CRI Partir de problèmes concrets......pour une solution virtuelle Une solution compatible avec nos moyens passe par l'augmentation virtuelle du nombre de machines. Partant Keep It Simple, Stupid. 1

2 du constat que ces technologies sont matures, que les machines du moment sont souvent 3 à 4 fois plus puissantes que les anciennes machines qu'elles remplacent, il semble raisonnable d'héberger 3 ou 4 serveurs virtuels dans une seule machine physique. Plusieurs techniques ont été testées et déployées. Toutes n'agissant pas au même niveau, elles seront détaillées. Après avoir entériné le choix de virtualisation des serveurs, le «découpage» du SAN en morceaux à assigner aux différents serveurs s'avère problématique. En effet, il n'est pas toujours facile d'évaluer l'espace qui sera occupé par un service. Pour le stockage aussi, un système de virtualisation a été adopté. Il sera présenté dans l'article. La seule multiplicité des serveurs ne suffit pas à apporter un service à forte disponibilité. Des techniques complémentaires doivent être déployées. Un paragraphe sera dédié aux tests que nous avons faits et aux solutions que nous avons adoptées. Le parc de serveurs du CRIUN est quasi-intégralement sous Linux/Debian, aussi, seules les techniques de virtualisation et haute disponibilité disponibles pour Linux ont été considérées. Le fait que ces développements soient open source est un plus auquel nous sommes particulièrement attachés. Parmi les techniques présentées, certaines sont disponibles sous d'autres systèmes. Il existe aussi des équivalents. Naturellement, cet article ne peut être exhaustif et n'est pas un comparatif entre les nombreuses solutions, parmi lesquelles des solutions commerciales et bien connues. Certaines ont probablement des avantages mais aussi des inconvénients par rapport à nos choix. 2 Techniques de virtualisation des serveurs Les techniques de virtualisation ne sont pas nouvelles : Il y a les émulations à proprement parler ; ce genre de produit existait au début des années 90 sur des machines de type Atari ST ou Amiga. Il existe aussi des produits de ce type sur macintosh. Dans le monde open source, QEMU [1] une émulation de PC. Créé récemment, cet émulateur est aussi capable d'utiliser un «accélérateur», qui est actuellement non open source. Avec cet accélérateur, l'émulation peut tourner à une vitesse respectable (50% d'une vitesse native selon l'auteur). PearPC [2] est lui un émulateur PowerPC, capable de faire fonctionner Mac OS X. Cependant, il reste lent, en effet, une émulation émule la totalité d'une machine, y compris ses composants internes et le processeur. Les émulations sont ainsi généralement lentes (en prenant des machines hôtes et cibles de même génération) ; leur intérêt est essentiellement pour mener des tests. L'émulation ne sera pas davantage considérée ici. La virtualisation de machine, elle, fonctionne sur le même type de matériel. Il n'y a plus de ce fait d'étape d'émulation de processeur, ce qui permet d'obtenir des performances proches, sinon celles de la machine originale dans les phases de calcul. Néanmoins, un certain nombre de composants ou pilotes de matériel sont virtualisés2, dégradant généralement les entrées/sorties, parfois de façon très significative. Cette technologie existe depuis fort longtemps sur de nombreuses architectures. IBM avait déjà introduit ces concepts au milieu des années 1960 et existe toujours dans leurs systèmes actuels (AIX 5L 5.2, OS400). Cette technologie est par contre récente sur les PC, car l'architecture IA-32 n'a pas été prévue pour cela. Des astuces techniques ont du être trouvées. Enfin, une autre catégorie existe ; il s'agit d'un partitionnement logique, ou serveur virtuel. Dans ce cas, il n'y a plus aucune émulation. C'est le noyau du système d'exploitation qui fait une isolation entre des machines logiques, tout comme il isole déjà les processus entre eux. Des exemples existent au moins sur FreeBSD (jails) et Solaris 10 (zones). Sous Linux, le projet Linux-vserver [3] représente cette catégorie. 2.1 Linux vserver Cette technologie open source est assez récente sous Linux. La version 0.0 date d'octobre Jacques Gélinas, canadien à l'origine de plusieurs projets bien connus sous Linux (linuxconf, umsdos) a démarré le projet. Cette solution est spécifique à Linux, mais non liée à la plateforme IA-32. Nous l'avons par exemple employée avec succès sur une plate-forme UltraSPARC 64. Le développement des versions s'est ralenti fin De nombreuses modifications ont alors fait leur apparition, et le projet s'est transformé en un projet communautaire. Le leader de ce projet est devenu Herbert Poetzl à partir d'octobre Depuis ce moment de nombreuses évolutions ont vu le jour. La version 1.0 est sortie le 1er novembre 2003, suivie de la version 1.2 le 5 décembre Cette branche est toujours active pour le noyau Linux 2.4 (version pour noyau ). La version 2.0 est sortie le 7 août 2005 pour le noyau Cette version apporte de nombreux perfectionnements. Fonctionnement Il s'agit d'une modification du noyau Linux (sous la forme d'un patch, le code n'étant pas actuellement intégré dans le noyau officiel). Ce patch est accompagné d'utilitaires pour configurer le système. Debian intègre depuis la version Sarge les utilitaires de gestion des vservers. L'intégration est donc assez simple. Concrètement, un vserver fonctionne par un système de contexte supplémentaire ajouté à chaque processus. Un exemple est donné sur la figure 1. C'est un système de virtualisation léger et peu intrusif. La machine physique démarre le noyau Linux. Tous les processus lancés par ce noyau (à partir d'init ) le sont avec un contexte 0, celui dédié à la machine hôte. Jusque là, tout se comporte strictement comme d'habitude. Le lancement d'un vserver se fait via la commande vserver nom_du_vserver start. Cette commande va lire un fichier de configuration via une couche d'adaptation, mais pas nécessairement une émulation complète. 2

3 correspondant au serveur virtuel à démarrer. Elle crée un contexte (un numéro), qui est unique à la machine physique. Ensuite, le processus change de racine ( chroot ). Les adresses IPv4 du vserver sont créées en tant qu'adresses secondaires de l'interface réseau de la machine physique, puis liées au contexte actuel par des règles de routage internes au noyau Linux. Ensuite la commande vserver se remplace par un processus unique (le programme init, qui est le processus standard de démarrage des UNIX). Ainsi démarre le serveur virtuel. Tous les processus ensuite démarrés par init sont dans le même contexte, et héritent de ses caractéristiques. Le contexte s'applique donc aux processus et aux adresses IP, qui sont ainsi isolés de tout ce qui n'appartient pas au contexte local. Ce sont les seuls éléments virtualisés. Il n'y a pas de virtualisation des couches réseaux ou de stockage. Le vserver se base sur la gestion de capabilities du noyau Linux, qui permet de descendre les privilèges d'une tâche (et des tâches héritées), et de limiter les appels systèmes possibles. Et ainsi sécuriser l'ensemble. Figure 1:Exemple d'un serveur hôte et deux vservers A l'intérieur d'un vserver, il est par exemple impossible de manipuler les adresses IP de l'interface, de manipuler iptables, ou encore d'utiliser mknod. Comme un vserver hérite d'une tâche unique, il est possible au lancement du serveur virtuel, de le limiter en nombre de processus, de lui donner une priorité (nice )... Cela est implémenté en interne via la commande ulimit. Il est facile de voir l'état des serveurs sur la machine : HighlandPark:~# vserver-stat CTX PROC VSZ M M M M M M RSS usertime systime UPTIME NAME 4.4K 1h33m03 11h29m48 62d48h33 root server 7.3K 1d25h17 2d56h18 62d48h32 VS_Archive 3.9K 0m50s84 2m14s60 62d48h32 MetroCible 2.7K 14h41m45 1d31h36 62d48h32 CloneNV 8K 1h40m46 2h58m34 62d48h32 Nagios 26K 3h49m38 15h19m26 62d48h32 Netvault Tableau 1:Un exemple d'états de vservers Sur le tableau 1 ci-dessus, le contexte de chaque vserver est indiqué. La consommation mémoire, ainsi que l'activité système y figure également. On peut y voir les ressources utilisées, modestes. La version 2.0 des vservers (disponible sur noyau 2.6 uniquement) permet de limiter plus nettement les ressources entre vservers au niveau du noyau, par exemple l'utilisation processeur (système de seau à jeton). Le pseudo système de fichiers /proc 3 est monté dans les Nécessaire que pour les utilitaires de type ps, netstat... fonctionnent. 3 vservers mais masque toute les entrées hors contexte, évitant ainsi des problèmes de sécurité possibles. Le pseudo système de fichiers /sys n'est par contre pas monté. Il n'est disponible que sur le serveur hôte. La principale limite est qu'il est impossible d'héberger un système autre que Linux puisque le noyau est partagé entre serveur hôte et ses vservers. Les processus d'un vserver ne sont que des processus standards, juste isolés et bridés sur les appels systèmes qu'ils peuvent utiliser. Les disques ainsi que la mémoire sont également partagés, ce qui permet une forte montée en charge, mais peut aussi compromettre la stabilité de l'intégralité du système, si on n'y prend garde. La racine d'un vserver se trouve dans un sous-répertoire du serveur maître /var/lib/vservers/nom_du_vserver Pour éviter tout débordement et tout effet de bord, il est souhaitable d'utiliser une partition dédiée pour chaque vserver (voire plusieurs). De cette façon, un vserver ne peut saturer le disque du serveur hôte. La création de nouveaux vservers peut se faire via une commande vserver build, qui est capable de gérer un certain nombre de distributions, dont DEBIAN (utilisation de la commande deboostrap pour installer un système de base DEBIAN) Quelques corrections sont ensuite apportées au serveur fraîchement installé (essentiellement un /dev quasiment vide), afin de fonctionner au mieux dans un vserver. Une fois cette commande terminée, un vserver de base est installé. Il peut être sauvegardé pour ensuite servir de patron (sous la forme d'un fichier tar.gz, qu'il suffit de décompresser ensuite, au besoin). Cela permet des déploiements «minute». Pour information, un serveur Debian Sarge de base «pèse» environ 180 Mo. Puisque l'objectif est de n'avoir qu'un seul service par serveur virtuel, de très nombreux vservers ne nécessitent réellement jamais plus de 1 à 2 Go de disque. Il est possible d'utiliser des distributions Linux différentes, serveur hôte DEBIAN et vserver Fedora, par exemple. En effet, les librairies ne sont pas partagées, chaque vserver aura son propre jeu de librairies4. Sur des machines X86-64, il est possible d'avoir l'hôte en architecture X86-64, certains vservers en X86-64, d'autres en IA-32. Particularités C'est la performance qui rend les vservers si attractifs. Puisqu'il ne s'agit pas d'un PC virtuel, mais plutôt de "serveurs Linux" virtuels. Cela peut simplement être vu comme un chroot amélioré. Les avantages sont des performances natives (pas de perte mesurable). A part la gestion du contexte, un processus dans un vserver a les mêmes caractéristiques qu'un processus d'une machine Linux standard. La consommation mémoire est légère (la mémoire est mutualisée entre le serveur hôte et les vservers et la mémoire demandée à l'hôte est celle réellement utilisée par les processus du vserver). La possibilité de mutualisation est donc ici très importante ; il est possible Ce qui augmente un peu l'utilisation mémoire globale. 4

4 de déployer plusieurs dizaines de vservers sur un serveur actuel correctement taillé. Sécurité De part les restrictions des appels systèmes que peut utiliser un vserver, un processus en son sein a moins de possibilités que celui d'un serveur standard. S'il y a intrusion dans un vserver, par une faille de sécurité d'un logiciel quelconque, le pirate ne pourra pas écouter les interfaces réseau, ou lancer des commandes comme nmap ; mais pour bloquer encore un peu plus un éventuel pirate, notre politique est de mettre systématiquement des firewall embarqués très restrictifs au niveau de l'hôte. Seul l'hôte à la possibilité de manipuler iptables. Les règles sont très restrictives, et correspondent strictement aux services déployés sur le vserver. Ceux-ci ne peuvent initier des connexions, hors celles nécessaires pour assurer le service. Ainsi un pirate, même root sur un vserver, restera enfermé car il ne pourra pas lancer de connexions vers l'extérieur. Un démon ssh installé sur un port non standard verra ses paquets refusés par le firewall de l'hôte. Il n'est pas possible d'accéder aux disques physiques de la machine (il est par contre possible d'effacer le volume du serveur virtuel). Un risque est constitué par l'escalade de privilège d'un vserver vers le serveur hôte. En effet, les vservers sont basés sur une couche de virtualisation logique assez fine. Par le passé, elle a été contournée une fois. Cet unique bug a été rapidement corrigé, mais prouve que le concept n'est pas à l'épreuve des balles. Si l'escalade arrive jusqu'à l'hôte, en tant que root, (ou si l'hôte fait tourner des services exploitables), alors la sécurité est mise à mal, puisque le serveur hôte a une vision complète de tous les fichiers des vservers, et peut accéder à chacun des processus de ceux-ci, ainsi que de s'y logguer en tant que root... Il ne s'agit plus cette fois d'un seul serveur piraté, mais de la totalité des vservers hébergés sur cet hôte. Il n'y a cependant actuellement pas de faille de ce type connue. Enfin, un seul noyau est partagé entre l'hôte et les vservers. Si un bug noyau existe, il peut être utilisé dans ou via un vserver, et provoquer un déni de service pour la machine hôte et par ricochet celui des autre vservers hébergés. Cela amène à un autre risque, qui est celui de la panne matérielle ; si la machine est en panne, ce sont tous ses vservers qui le sont. Déployer un vserver est dangereux si des services redondants ne sont pas prévus. Les précautions que nous prenons sont les suivantes : Tous les service importants déployés sur des vservers sont redondés. Les vservers co-hébergés sur une même machine hôte sont, autant que possible, avec des catégories d'usage et des contraintes de sécurité proches. Et bien sur, la règle primordiale est de ne faire tourner AUCUN service sur l'hôte à part SSH et les iptables. Limitations Chaque médaille a son revers... Vserver a l'inconvénient de ses avantages, c'est à dire sa légèreté. Dans un grand nombre de cas, son fonctionnement est tout à fait satisfaisant. Cependant, le noyau est partagé par toutes les instances de serveurs, et tous les drivers et couches de communication ne sont pas virtualisés ; les conséquences sont multiples : certains programmes nécessitant des privilèges élevés, ou manipulant directement le matériel ne pourront fonctionner correctement. Par exemple, le déploiement d'un serveur NFS kernel ne peut se faire qu'au niveau de l'hôte principal. Pas plus que démarrer un serveur X window n'est possible simplement... Dans un hôte il est possible de démarrer un démon NFS en privilège utilisateur5, mais les performances sont moins bonnes. La mutualisation de la couche réseau peut aussi entraîner des problèmes de routage complexes (un cas est exposé en annexe) et empêche IPv6 de fonctionner. Dans les déploiements envisagés, certaines de ces limitations sont gênantes. Il a donc été considéré que pour certaines applications, un système de virtualisation plus complet devait être déployé. 2.2 XEN Pour ces raisons, nous nous sommes tournés vers XEN [4], un autre logiciel open source. Il s'agit cette fois d'une technique de machine PC virtuelle. Cette technologie ne fonctionne que sur la plate-forme X86 (IA-32). La nouvelle version 3.06, est aussi capable de gérer l'architecture X8664. Par contre, XEN est actuellement porté sur Linux, NetBSD et plus récemment FreeBSD. XEN ne peut faire tourner un système d'exploitation standard : il nécessite des modifications (assez légères) au niveau des sources du système cible, ce qui implique un système d'exploitation open source. Le portage vers Windows est ainsi techniquement faisable, mais nécessite l'aval de Microsoft. Grâce aux nouvelles technologies de virtualisation introduites dans les processeur à sortir en 20067, ces modifications ne sont plus nécessaires. Fonctionnement XEN est constitué d'un programme superviseur, chargé d'implémenter la mécanique nécessaire pour gérer la virtualisation sur une architecture qui n'est pas prévue pour, et de patches à appliquer aux noyaux des systèmes d'exploitation supportés (Linux, NetBSD...), afin d'adapter leur fonctionnement avec le superviseur. Celui-ci est le programme chargé au démarrage de la machine (via grub, lilo..). Il ordonnance les machines virtuelles entre elles. XEN ne gère pas le matériel directement ; une des machines virtuelles a le privilège d'accéder au matériel : au lancement, le superviseur prend comme argument le noyau qui gérera cette machine virtuelle. Il va s'agir d'un noyau Linux avec le support XEN activé. Cette machine virtuelle privilégiée (domaine 0) gère les périphériques via les drivers standard de Linux, et implémente, en plus, un nouveau pilote appelé back-end. A part le fait que le superviseur a déjà été lancé et que le noyau est légèrement modifié, il s'agit d'un Linux traditionnel, qui démarre sur une partition du disque dur. Ce peut être n'importe quelle distribution Linux. Les autres machines virtuelles seront, elles, lancées à partir du domaine 0. Ce sont des machines de domaine U Unfsd3, par exemple. En phase Bêta en septembre technologies VT (VanderPool Technology) chez Intel, et Pacifica chez AMD. 5 6

5 (comme Unprivilegied ou Unmodified). Il est possible d'en démarrer autant que nécessaire, à concurrence de la mémoire disponible sur la machine physique. Le noyau de la machine virtuelle est également un noyau patché. Ce noyau ne gère plus de périphériques8, à part un pilote 'front-end'. La distribution est une distribution Linux standard. Les machines XEN sont étanches. Les machines virtuelles en domaine U ont accès à des périphériques (disque dur, interface réseau). Ces périphériques sont gérés par le driver 'front-end', qui communique avec le driver 'back-end' de la machine en domaine 0. Il s'agit ni plus ni moins des extrémités d'un canal de communication, très simple et donc très rapide. Pour communiquer entre elles les machines doivent utiliser un protocole réseau (comme entre des machines physiques). Il faut utiliser des commutateur réseaux virtuels (le support bridge de Linux, géré dans le domaine 0). (cf illustration n 13 en annexe) quasi équivalentes au système natif, tout en proposant une forte virtualisation. Limitations Le support X86-64 n'est pas complet dans la version 2.x. Individuellement, les serveurs hébergés (domaines 0 et U) ne fonctionnent qu'en mode mono processeur, même si le serveur physique les hébergeant est multi processeur. Cependant, si plusieurs machines virtuelles fonctionnent en simultané, l'utilisation de tous les processeurs de la machine hôte sera possible. Le changement de taille mémoire assignée à un serveur est possible à chaud, mais pas automatique. Il n'y a pas mutualisation de la mémoire. Une taille mémoire doit être donnée au démarrage de la machine virtuelle. 3 Virtualisation stockage de l'espace de La mise en place du SAN nous a conduit à réfléchir à une meilleure façon de stocker les données. En effet, il est désormais possible d'assigner une quantité arbitraire d'espace de stockage à un serveur. Tout d'abord une baie RAID est généralement découpée en plusieurs disques virtuels RAID (0,1,5 ou plus). En général, un par contrôleur, ou par canal. Cela permet de flécher les flux d'entrées/sorties, et de les optimiser différemment10. Ce canal est attaché au réseau fibre channel, appelé fabrique. Ces disques virtuels sont ensuite partitionnés. Ces partitions sont alors publiées en tant que LUN SCSI. Figure 2: Même exemple avec XEN Sécurité XEN offre intrinsèquement la même sécurité qu'une machine physique. Les tâches qui lui sont confiées sont alors les mêmes qu'une machine physique. Cependant la problématique d'escalade de privilège, déjà évoquée avec les vservers reste également valable. Si une brèche de sécurité de la machine de domaine 0 est exploitée, alors, les autres domaines U sont compromis. Néanmoins, XEN semble plus résistant. l'étanchéité entre machines virtuelles est censée être totale. L'ensemble XEN peut résister à une attaque (ou le plantage) d'un noyau de domaine U. iptables et ebtables 9 peuvent être appliqués sur les commutateurs virtuels, ce qui renforce la sécurité. Particularités Une migration à chaud des machines virtuelles est possible entre différentes machines. Un processus de copie est intégré à l'utilitaire de gestion de XEN, xm, et via le serveur WWW associé. Par rapport à des concurrents de catégorie similaire, XEN a l'avantage d'être capable de délivrer des performances Il est néanmoins possible de donner directement un périphérique PCI à gérer dans un domaine U pour des besoins spécifiques. 9 Filtrage au niveau 2, c'est à dire sur des adresses MAC 8 Figure 3: Application de zonage de fabrique Selon les modèles et constructeurs de baies, le nombre de disques virtuels, de partitions disponibles et de LUN publiables varient. Pour assigner un LUN à un serveur, il faut procéder de la sorte : 1. Zoner la fabrique. Une zone est un ensemble ou chaque membre se «voit» et peut se connecter. Dans une configuration simple, une zone est constituée d'un serveur, d'une baie RAID (un de ses canaux), et éventuellement d'un robot de sauvegarde. cf figure 3. (mode de cache et optimisation pour fichier à accès séquentiel ou non) 10

6 2. Utiliser la fonction de masquage de LUN des baies considérées, afin d'assigner le LUN au serveur. Si cette étape n'est pas faite, celui-ci verrait tous les LUN publiés par la baie, ce qui poserait des gros soucis de sécurité. 3.1 Stratégie d'allocation de l'espace disque aux serveurs La granularité d'assignation d'espace disque s'arrête donc à la taille d'un LUN. Une baie sur laquelle seuls deux grands LUNs seraient créés ne pourrait servir que deux machines11. Cela peut convenir si les baies ont été affectées à des tâches bien précises. Mais ce n'est pas notre objectif. Stratégiquement, pour poursuivre l'objectif de grande versatilité et d'utilisation maximale de nos ressources, il a été choisi de faire un grand nombre de LUNs. Les trois premières baies ont été ainsi découpées en 2 disques virtuels Raid 5, chacun partitionné en 8 LUN. Soit 16 LUN par baies. La 4ème baie installée plus récemment et bénéficiant de l'expérience acquise, a elle été découpée en deux disques virtuels Raid 5, chacun partitionné en 16 LUNs. En fonction des baies, cela donne des LUNs de 75 à 200 Go environ. 3.2 Gérer la pléthore de disques Sur les premiers déploiements sur trois baies, 48 LUNS étaient disponibles pour 7 serveurs. La quatrième baie a porté ce total à 80 LUNs. La façon dont Linux découvre ses disques devient alors problématique. En effet, au démarrage, Linux observe ses canaux SCSI (ou fibre channel), et énumère séquentiellement, en fonction de ses découvertes, les périphériques : /dev/sda,/dev/sdb, etc... Autant cette solution est viable pour un système SCSI intégré au serveur, autant cela est problématique sur un SAN. Notre politique de versatilité fait qu'il nous est très aisé et rapide d'assigner un LUN supplémentaire à un serveur. Les conséquences sont simples, les disques sont renumérotés, changent donc de nom, et le /etc/fstab du serveur, qui conditionne le montage n'est plus valable. La machine aura des problèmes au prochain démarrage. Puisque nos déploiements se font sur des serveurs virtuels, il est souhaitable d'utiliser un seul disque. Même avec 80 LUNs, la limite peut être rapidement atteinte. D'autant plus que la plupart des vservers se contentent d'un espace de 2 Go. A l'inverse, pour certains serveurs, même des LUNs de 200 Go sont insuffisants, un espace linéaire de l'ordre de 1 To serait plus utile (cas des miroirs FTP). 3.3 EVMS L'applicatif EVMS [5] répond à ces problèmes. Ce logiciel open source est développé par IBM. Il est désormais basé Sauf à dessein, pour un système de fichiers cluster, capable de partager des disques. 11 sur la couche «device mapper» [6] du noyau Linux, tout comme LVM2 [7]. Cette couche standard, introduite officiellement dans le noyau 2.6, permet de masquer la réalité des disques physiques et de présenter des disques logiques. LVM2 ne sera pas présenté. Il est plus connu qu'evms, qui a notre préférence. Ces deux logiciels sont similaires dans leur but, et ont un certain degré de compatibilité entre eux, puisqu'une grande partie du travail est effectué par le module device mapper sous-jacent. Figure 4 : Allocation d'un LUN dans un conteneur LVM2 Dans l'exemple donné sur la figure 4, un LUN de 150 Go a été assigné au serveur A. Ce serveur a besoin de plusieurs espaces distincts dans cet espace, par exemple pour des vservers. Il est possible de partitionner ce LUN comme un disque SCSI traditionnel (partitions classiques dans l'architecture MS/DOS avec fdisk ). Mais ce schéma est rigide, et s'accommode, lui aussi, mal de modifications régulières. EVMS peut faire mieux. Fonctionnement Une fois le LUN assigné au serveur, le noyau Linux le voit (/dev/sdb, par exemple). EVMS le détecte également, et le classe comme ressource disponible. L'étape suivante est d'intégrer ce LUN dans un «conteneur» de type LVM2 (LVM1 est aussi supporté). Ce conteneur est nommé et sera désormais accessible à tout moment par la machine. Le disque /dev/sdb ne sera désormais plus utilisé directement. EVMS attache un identifiant unique à tout élément qu'il utilise. Ce point est important, car EVMS est capable de retrouver tous ses éléments, même si la topologie (et donc, l'ordre de découverte des disques) a été changée. Dans ce conteneur, des régions vont être créées. Sur la figure 4, 2 régions de 80 et 30 Go ont été créées. Chacune de ces régions porte également un nom. Il reste 40 Go utilisable dans ce conteneur. Ensuite, chacune de ces régions va contenir un volume. Ce volume a la même taille que la région. Il est également nommé. C'est le volume qui est utilisé par l'utilisateur. L'exemple de la figure 4 fera apparaître deux nouveaux

7 /dev/evms/mail périphériques (80 Go) et /dev/evms/logs (30 Go). Il n'y a plus qu'à formater ce périphérique avec le système de fichiers de son choix, et de modifier le fichier /etc/fstab, afin de monter ce disque virtuel au démarrage de la machine. Toutes ces opérations se font via une interface graphique ou textuelle. Il est alors très simple de faire coïncider un serveur virtuel avec un disque virtuel. C'est ce qu'illustre la figure 5. Figure 5 : Un exemple de déploiement d'evms EVMS dispose de nombreuses autre fonctions. Il est par exemple possible d'agrandir à chaud des disques virtuels, ce qui est pratique lorsque un serveur commence à prendre plus de place que prévu. Il suffit de demander à EVMS d'ajouter de la place à un volume donné, et il le fait automagiquement. L'opération prend seulement quelques secondes, et l'espace est immédiatement disponible. En réalité EVMS fait jouer de nombreux mécanismes en interne mais les masque à l'utilisateur. Tout d'abord, il faut qu'il reste de la place dans le conteneur qui gère le volume a étendre. EVMS va prendre cette place libre, l'ajouter de façon transparente à la région qui gère le volume concerné. Puis, le volume lui même va être étendu. Le dernier traitement à faire est le plus compliqué. Il faut informer le système de fichiers qu'il a désormais de l'espace supplémentaire. La plupart des systèmes de fichiers peuvent le faire, mais à froid (c'est à dire en démontant le volume temporairement, donc en interrompant le service). XFS et Reiserfs3, par exemple, sont capables de le faire à chaud, mais pas EXT3. s'ils font des optimisations en fonction de la linéarité supposée d'un fichier (un seul bloc de secteurs contigus12 au niveau du système de fichiers, mais pas au niveau du disque physique). Il est possible de migrer des données à chaud d'une baie à une autre, cf la figure 7. Ici une région est migrée au sein d'un même conteneur LVM2. Le cas traité sur cette figure est possible d'une manière plus saine, en migrant le volume (et non plus la région) vers une AUTRE région de taille identique, mais dans un conteneur différent. Voir pourquoi à la rubrique sécurité. Figure 7 : Migration à chaud d'une région ou d'un volume. Enfin EVMS est capable de déclencher des snapshots13, ce qui est pratique pour les sauvegardes, et de gérer le RAID logiciel (entre autre). Il est ainsi possible de combiner 2 LUNs de baies différentes, de les agréger logiquement en un agrégat RAID1, et d'intégrer le résultat dans un conteneur LVM2. Ce conteneur est alors utilisable de façon standard (création de régions, puis de volumes). Avec un SAN il est ainsi possible de redonder géographiquement les données, si les LUNs constituant cet ensemble sont hébergés sur des baies éloignées géographiquement. Potentiellement, un serveur peut accéder à 20 To de stockage, sur des agrégats Raids 0,1 ou 5 (les plus courants), sur des baies de performances et technologies différentes (PATA, SATA, Fibre Channel). Cela nous donne une bonne latitude d'évolution. Particularités Figure 6 : Accroissement des volumes et ajout d'un LUN supplémentaire EVMS est également capable de réduire la taille d'un volume. Seuls EXT3 et Reiserfs3 supportent ce mécanisme. Et seulement à froid, car ce mécanisme implique souvent une défragmentation et des déplacements de données. C'est un processus coûteux. Si la région n'a plus de place disponible, il suffit alors simplement de rajouter un LUN supplémentaire dans le conteneur. C'est ce qui a été fait sur l'illustration 6.Un des défauts qui y est d'ailleurs visible est la fragmentation du disque virtuel dans le conteneur. Dans les faits ce n'est pas spécialement un problème de performance, mais peut tromper le système d'exploitation et le système de fichiers, EVMS est une application utilisateur et ne réside pas dans le noyau. Il communique avec celui-ci via le service device mapper, qui est la partie du noyau qui implante une bonne partie de la virtualisation. Si le système veut démarrer sur un volume EVMS, c'est possible, à condition de charger un ramdisk initial contenant EVMS. En effet, EVMS a besoin d'être lancé après le lancement du noyau, mais avant le montage des disques, afin de pouvoir énumérer les disques qui lui sont propres. Ce qui rend EVMS attractif, c'est son architecture de plugins, qui permet, à partir d'une interface simple, d'enchaîner de nombreuses commandes en interne, et de masquer les détails complexes à l'utilisateur. extent. Cliché instantané de l'état d'un disque, sans copie de contenu, et utilisable à postériori 12 13

8 Sécurité RIEN N'EMPECHE d'utiliser des LUNs provenant de baies différentes dans un même conteneur LVM2. Les LUNs inclus dans le conteneur peuvent avoir des tailles différentes et utiliser des baies différentes, c'est ce qui est illustré sur la figure 7. Cependant, des problèmes de performance peuvent survenir14. Et, SURTOUT, les RISQUES sont alors fortement multipliés, car il suffit qu'un seul des LUNs soit en panne pour que la totalité du conteneur soit cassé. Avec un SAN, cela peut avoir de multiples causes (problème de zoning, maintenance d'une baie, mauvais contact sur une fibre optique...). C'est donc quelque chose à proscrire. Limitations Certains systèmes de fichiers (reiser4, OCFS2) ne sont pas pour l'instant directement gérés par EVMS. Heureusement, EVMS fonctionne via un système de plugins. Ces limitations seront facilement contournées par le développement de plugins appropriés. 4 Balance de disponibilité charge et haute Le chapitre 1, explique que le choix pour améliorer la disponibilité des services a été d'augmenter le nombre de serveurs. Pour certains services, cette augmentation est immédiatement bénéfique : Figure 8 : Balance de charge via round robin DNS Enfin, le problème est pire lorsque le serveur est encore en fonctionnement, mais son service ne répond plus ou mal ; le service est alors dégradé ou incorrect. Après plusieurs mois de ce fonctionnement, il est clair que cette technique est insuffisante. Ce système ne nous permet pas non plus de faire simplement des mises à jour des systèmes. Tout doit être planifié, en supprimant les machines une à une du roundrobin (le TTL est réglé à 500 secondes). Malgré tout, même si les nouvelles connexions sont bien dirigées vers les serveurs restants, les connexions déjà ouvertes restent sur le serveur qui doit être redémarré pour maintenance. Néanmoins, cette technologie est simple et continue de nous servir ; voir un exemple en annexe. 4.2 Ultramonkey Sous ce nom se cache un système à haute disponibilité assimilé à un cluster. Ultramonkey [8] est un ensemble de trois logiciels open source qui fonctionnent ensemble : Les MX, par exemple, ou les DNS publics bénéficient immédiatement d'une telle augmentation, car le protocole est prévu pour fonctionner avec plusieurs machines. Même dans le cas des DNS, la partie résolution des postes clients nécessite une modification de la configuration des clients15, ce n'est donc pas immédiat, ni sans effort. 4.1 Round Robin DNS Pour certains services, la mise en place d'un nom unique renvoyant vers plusieurs serveurs a été effectuée. Cette technique, connue comme le Round Robin DNS est simple à mettre en œuvre. Les serveurs perdition1 et perdition2 sont gérés ainsi dans le DNS: Imap Perdition IN IN IN CNAME A A Perdition.univ-nantes.prive Comme le montre la figure 8, cela donne de bons résultats : les courbes IMAP et POP des deux serveurs sont quasiment superposées. Mais c'est une technique de balance de charge, pas de haute disponibilité. Si un des serveurs tombe en panne, le DNS pointe toujours sur la machine en panne. Il a rapidement été vu que certains clients se sortaient assez bien du problème (si un des serveurs ne répond pas, l'autre est essayé). Mais d'autres clients partent en dépassement de temps, induisant des lenteurs, voire des pertes de service. Par exemple, cas de disques issus de technologie différentes (sata et fibre channel) ou avec un niveau de raid différent (raid1 et raid5) 15 Si le poste client n'est pas configuré par DHCP 14 Figure 9 : Principe de fonctionnement d'ultramonkey le premier est LVS (Linux virtual server) - à ne pas confondre avec les vservers-. C'est un module du noyau Linux, intégré depuis les noyaux 2.6. LVS tourne sur une machine Linux, dédiée à cette tâche, appelée directeur. LVS est un système de balance de charge. Contrairement au DNS, il n'y a qu'une seule adresse IP associée au service. Il n'y a donc pas besoin de changer la configuration des clients utilisant ces services. La figure 9 détaille une des topologies possibles : ici une topologie utilisant le masquerading. LVS s'appuie sur les modules de NAT internes au noyau pour modifier dynamiquement l'adresse IP de destination. Dans le reste du document, les termes serveurs réels ou nœuds du cluster signifieront la même chose. Contrairement à ce qui est possible avec le DNS, la balance de charge obéit à des politiques : RR,WRR (Weighted Round Robin), LC, WLC (Weighted Least-Connection) ainsi que d'autres plus spécialisées. La politique WLC tente d'égaliser le nombre de connexions simultanées vers les

9 serveurs réels. Ces politiques, ainsi que la liste des serveurs réels à joindre se gèrent par la commande ipvsadm. présente pas plus de risque qu'un système Firewall déployé sous Linux. Par contre, les serveurs déployés derrière un LVS en mode masquerading (notre exemple) sont intrinsèquement protégés, comme derrière un firewall. En effet, ces serveurs ne sont pas routables et ne peuvent être joints que via le directeur, sur un port assurant un service bien précis. La connexion vers l'extérieur n'est valable que la durée de la transaction. Les serveurs ne peuvent initier eux même de connexions vers l'extérieur. C'est pourtant souvent nécessaire, (consultation de DNS, LDAP, etc..) et peut être assuré par une seconde interface réseau16, conduisant à l'intranet, avec une sécurisation standard à la clef. Limitations Figure 10 : Cheminement d'une requête La figure 10 montre, pas à pas, le fonctionnement du système, pour un service donné (ici, un service de webmail). Puisque toutes les requêtes passent par une unique machine, se pose la question de la disponibilité de celle-ci. Le logiciel Heartbeat est le deuxième logiciel de la suite Ultramonkey. Il permet de surveiller l'état de deux machines. Si la première tombe en panne, la seconde prend immédiatement le relais (mode actif/passif). Une adresse IP virtuelle est déclarée sur les deux machines ; seule la machine active a cette adresse IP activée. Les services gérés par LVS sont activés sur cette adresse virtuelle. Le problème de disponibilité du directeur réglé, reste le problème des serveurs réels ; en effet LVS distribue les requêtes en fonction des règles entrées par ipvsadm. La distribution est dynamique, mais les règles sont entrées statiquement. En cas de panne d'un des serveurs réels, le directeur continuera d'y distribuer des connexions, ce qui engendre une perturbation du service. En l'état, ce n'est pas une progression par rapport à ce qui est fait avec le DNS... Pour contourner ce problème, le troisième logiciel d'ultramonkey intervient : il s'agit de ldirectord. Ce logiciel permet de surveiller régulièrement l'état des nœuds du cluster, en tentant une connexion au service (port 80 pour le webmail). Si la machine ne répond plus, elle est automatiquement retirée de l'ensemble des serveurs réels éligibles. Néanmoins, ce cas gère la panne matérielle, mais pas la panne logique (erreur de configuration, perte de données). ldirectord est capable de gérer plus finement certains protocoles ; dans le cas d'un service WWW, il est capable de demander une page précise, et de vérifier si le serveur répond correctement. Sécurité Un directeur est une machine Linux. A ce titre, il doit être protégé comme n'importe quelle autre machine Linux, particulièrement au niveau des démons qui fonctionnent. (Il ne devrait y avoir que SSH, heartbeat et ldirectord. Tous devront être protégés par un firewall interne). Le noyau utilisé est standard, et peut donc être vulnérable lui aussi. Le processus LVS lui même est assimilable à un NAT et ne La limitation du système est sur plusieurs plans : au niveau de la performance : le directeur doit réécrire tous les paquets entrant à la volée, et selon les topologies utilisées, également ceux qui repartent. Les couches réseaux de Linux sont heureusement rapides, mais selon la puissance de la machine, la capacité de traitement en paquets par seconde est bornée. Au niveau des protocoles utilisables : ma réécriture de certains paquets ne peut se faire facilement selon les protocoles ; un exemple classique est FTP où le suivi de connexion est complexe. Des modules de traitement spéciaux existent pour cela. Il semblerait que des protocoles tels H323 ou SIP soient problématiques. Enfin, Ultramonkey ne supporte pas IPv6. Heartbeat est capable de le gérer, mais pas LVS. Il n'y a actuellement pas d'informations sur un éventuel développement en ce sens. 4.3 Synchronisation des disques Au niveau de la solution Ultramonkey, il est essentiel que les configurations des directeurs soient synchronisées. Au niveau des nœuds du cluster, il est aussi intéressant que les serveurs soient entièrement ou en partie synchronisés. Un temps essayé, DRBD [9] ne peut nous convenir car il n'autorise qu'un fonctionnement en mode passif/actif, avec uniquement une machine ayant l'accès en écriture. D'autre part DRBD fonctionne en mode bloc, ce qui ne garantit en aucune manière la cohérence du système de fichiers lorsqu'une seconde machine prend la main et que le système de fichiers actif bascule dessus ; en effet, la plupart des systèmes de fichiers fonctionnent en mode asynchrone ; d'autre part, même les systèmes de fichiers journalisés ne garantissent que la cohérence des méta-données, pas des données elles mêmes. Par exemple, avec XFS, seule la commande xfs-freeze garantit la cohérence du disque à un moment donné. Le seul système de fichiers qui garantit l'atomicité d'une transaction, et pourrait être utilisé sainement ainsi est reiser4, qui est actuellement en stade bêta. Aussi, nous nous sommes repliés sur un système simple, qui fonctionne au niveau des fichiers: rsync [10]. Par contre cette solution n'est pas synchrone et requiert de la puissance à chaque invocation (une fois par heure). Une solution par marquage des paquets au niveau des serveurs réels plus NAT sur le directeur, en sortie, est possible, mais complexe... 16

10 D'autres solutions comme csync2 [11] sont évaluées, mais la portée de ces solutions se réduit aux fichiers de configuration, pas aux fichiers utilisateurs. Il apparaît évident que la vraie solution se fera par l'utilisation d'un système de fichiers cluster, de type GFS2 [12]ou OCFS2 [13]. 4.4 Problèmes annexes Rien n'est jamais parfait, et les solutions déployées ne dérogent pas à la règle. La plupart des limitations techniques ont déjà été citées ; mais ce ne sont pas les seules à prendre en compte. Gérer efficacement la ferme de serveurs Le problème principal rencontré vient de l'augmentation importante du nombre de serveurs, qui est une conséquence directe de nos choix. Actuellement, notre ensemble est encore relativement cohérent, car tous les serveurs partent d'un patron commun. Mais de nombreuses divergences commencent à apparaître au fil de la vie de ces serveurs (reconfigurations, patches de sécurité, modifications de paramétrage, etc...). Une vraie stratégie de gestion d'une ferme de serveurs de cette taille (plus de 150 serveurs, réels et virtuels) doit être construite. L'objectif à atteindre est de rendre la gestion d'une centaine de serveurs aussi simple que celle d'une dizaine de serveurs, et d'avoir un ensemble toujours cohérent, que ce soit au niveau des révisions des logiciels, des configurations ou de la sécurité. Pour cela, des solutions existent, mais ne sont pas encore mises en place. Nous avons des outils de surveillance et métrologie, mais essentiellement sur des points clés de l'architecture, pas sur la globalité. La sauvegarde est systématique, mais pourrait aussi être raffinée. L'idée est de disposer d'un outil de gestion de configuration qui nous permette de gérer efficacement l'ensemble du parc, et de centraliser les configurations en un point d'administration unique. Rdist [14] peut être utilisé, mais un système plus complet est recherché. Actuellement cfengine [15] est évalué. Alimentations électriques et redondance géographique Sur les deux dernières années, le bilan est simple : La partie électrique est de très loin la partie la plus faible de notre système. Bien que ce sujet ne soit pas directement lié à l'informatique, il s'agit d'un point crucial. Une grande attention doit être portée sur les alimentations électriques. En effet, bien que notre salle machine soit ondulée via de multiples sources, nous avons été plusieurs fois touchés par des coupures de courant importantes, réduisant à néant tous les efforts de haute disponibilité. L'autre question est que 10 To de données sont stockées au même endroit. Bien que sauvegardées, un sinistre majeur peut avoir des conséquences désastreuses... 5 Évolutions et déploiements futurs La virtualisation a vraiment permis de remodeler notre organisation informatique. Ce qui est actuellement mis en place est un avancement important, mais nous gardons comme objectif d'augmenter encore la disponibilité et la possibilité de mise à l'échelle de nos systèmes. Le prochain gros projet à mettre en œuvre est le stockage unifié des étudiants. Ce projet va voir sa première phase aboutir en Janvier 2006 avec 20 To de données déployées. Les techniques déjà utilisées vont nous aider dans ce déploiement, et de nouvelles seront testées. Systèmes de fichiers cluster Dans certaines situations, les données ne sont pas accessibles sans point de panne unique. C'est le cas, par exemple, du stockage des courriers électroniques, ou des données personnelles des utilisateurs. Il est possible de mettre ces données à disposition de plusieurs machines, via NFS, par exemple. Mais l'unicité du serveur NFS continue à poser problème (sans parler de ses performances médiocres). Pourtant, dans le cadre d'un SAN, il est possible de partager un même LUN entre plusieurs serveurs. Mais les systèmes de fichiers standard ne sont pas prévus pour ce cas. Utiliser simultanément un même système de fichiers sur deux serveurs via un média partagé est le meilleur moyen de ruiner son contenu. Les systèmes de fichiers cluster sont prévus pour ce cas. OCFS2, d'oracle, et GFS2 de RedHat, en sont deux représentant actuels que nous considérons. OCFS2 est désormais intégré dans le noyau standard. Les tests préliminaires sont encourageants. Si la solution est validée, elle pourrait être intégrée au cœur du stockage du courrier électronique des étudiants en janvier Lustre [16] est un autre système de fichiers cluster agissant plutôt au niveau réseau (stockage réparti), sans point de panne unique. Nous le testons également dans le cadre du stockage unifié pour les étudiants. Redondances Enfin, il est prévu de commencer à gérer une deuxième salle machine, située à l'autre extrémité de Nantes. Dans ce deuxième centre seront déployés un minimum de machines : directeur de secours, ainsi que quelque nœuds de cluster. Ce deuxième lieu est bien entendu totalement indépendant du premier au niveau de l'électricité, et aura également un déport de baies de stockages, ce bâtiment étant directement raccordé au réseau fibre channel qui se déploie dans le dernier trimestre Conclusion La politique de 1 service = 1 machine est une réalité depuis plus d'un an et demi. Les machines virtuelles déployées sont elles mêmes dotées de disques virtuels qui sont taillés en fonction de leurs besoins. Les services déployés n'étant plus couplés avec les serveurs matériels les hébergeant, il devient possible de faire évoluer simplement l'architecture. N'ayant plus de dépendances ni sur l'emplacement des services, ni sur l'emplacement des données, les services peuvent migrer rapidement, à chaud (cas de XEN ou de services rendus via Ultramonkey), ou à froid pour les services non critiques, de serveurs en serveurs. Les données peuvent aussi migrer à chaud avec EVMS (de baies à baies) ou à froid avec rsync. L'incorporation de nouveau matériel est donc extrêmement aisée, et les vieux matériels (sortie de garantie) peuvent

11 immédiatement être réaffectés à des tâches moins cruciales (serveurs de tests). L'introduction de nouvelles technologies est également simplifiée, leur impact étant limité. Les deux techniques de virtualisation de serveurs (vservers et XEN) utilisées s'avèrent complémentaires. Actuellement, environ 140 vservers sont déployés, sur une trentaine de machines physiques. La moitié d'entre elles sont reliées au SAN, qui totalise actuellement 10 To de données. Plus récemment, une dizaine de machines XEN ont été déployées, essentiellement pour nos deux derniers déploiements décrits en annexe. Ce déploiement important nous a permis de redonder pratiquement tous nos services cruciaux. La maintenance du parc est aussi simplifiée, il est possible de mettre à jour les serveurs beaucoup plus simplement. Annexe Les cas qui suivent sont des exemples de déploiements effectués récemment. Messagerie unifiée pour les étudiants Ce déploiement date de fin août Après le déploiement du courrier électronique unifié pour le personnel, il nous a été demandé de reconduire cette opération, mais cette fois pour les étudiants. L'expérience nous a conduit à essayer de résoudre les points faibles du précédent système déployé. L'architecture générale reste la même que pour le courrier électronique unifié, sauf qu'au lieu d'utiliser le Round-Robin DNS pour répartir la charge, un système ULTRAMONKEY a été utilisé. Un temps évalué, le stockage des courriers sur un système de fichiers clusterisé a été temporairement reporté, nous n'avions pas l'assurance de stabilité et de performances suffisantes. L'exemple est une configuration Ultramonkey complexe. c'est pourtant une simplification de ce qui est actuellement déployé... L'idée maître ici est de pouvoir gérer la plupart des pannes pouvant survenir, y compris une panne d'un routeur, d'un commutateur réseau où d'une bonne partie de l'installation électrique. Deux réseaux sont considérés ici : xx (U11) et xx (U12). U11 et U12 sont routés par des routeurs différents. Figure 11 : La solution haute disponibilité adoptée pour la messagerie des étudiants Chaque réseau dispose de deux directeurs en mode actif/passif (gestion par heartbeat). Les 4 directeurs sont gérés dans des machines XEN, intégrées dans deux machines physiques, reliées aux 2 réseaux considérés par vlan 802.1Q. Les deux machines physiques XEN ne sont pas reliées au même commutateur et les alimentations électriques sont également de sources différentes. Les nœuds du cluster sont eux, des vservers17 intégrés sur plusieurs machines physiques. Ces machines hébergent un certain nombre de services liés comme les LDAP, Webmails... Le service IMAP, rendu par le serveur perdition [17], est par exemple, installé sur 4 vservers déployés sur 4 machines physiques différentes, réparti en deux vlans (C11 et C12). Bien entendu, les alimentations électriques et les attachements aux commutateurs réseaux sont différents entre les machines physiques. Ce service est joignable par deux réseaux différents. Pour pouvoir simplement gérer ces deux adresses, nous utilisons à nouveau le Round-Robin DNS. La différence est que cette fois, les deux adresses gérées sont normalement toujours en fonctionnement, puisque qu'elles aboutissent sur un système à haute disponibilité. Théoriquement, seul un problème de routage peut rendre inaccessible une de ces adresses. Ce système fonctionne correctement et peut être vu comme le début d'un système de cluster généralisé. Malheureusement, pendant la mise en place de ce système, une des limitations des vservers au niveau du routage a été observée : cf l'exemple sur la figure 12. Selon le vocabulaire habituellement utilisé dans LVS, nos serveurs virtuels sont des serveurs réels... 17

12 Figure12 : Problème de ré-entrance de notre solution Prenons le cas d'un étudiant allant sur le webmail pour lire ses mails. La connexion se fait sur une des adresses d'ultramonkey, ici, : 443. Le traitement de LVS amène la requête sur un vserver Webmail-2, La réponse se fait, jusque là pas de problème. Maintenant, le vserver a lui même besoin d'aller interroger des serveurs tiers (serveur LDAP). Ces services sont eux mêmes gérés par Ultramonkey. Sur la l'illustration 12, la requête est figurée. La requête (1) va arriver sur le directeur, celui-ci va choisir un nœud du cluster et translater la destination. Si, par chance, la requête est envoyée sur un serveur maître différent (3a), tout va bien (4a,5a,6a). Si par contre, l'hôte choisi est le MÊME que celui dont vient la requête (mais depuis un vserver différent) (3b), tout va mal. En effet le vserver Ldap dispose d'une route locale vers Le paquet sera routé en direct, et ne reviendra pas par le directeur (4b). Le paquet sera ignoré car Webmail-2 attendait une réponse provenant du directeur , pas de Ce cas n'a pas de réponse simple. Il est dû au fait que les vservers partagent la table de routage locale du noyau. La solution adoptée a été d'appliquer un NAT en sortie des nœuds du cluster, pour maquiller la source du paquet. Ainsi, la réentrance dans le cluster est possible dans tous les cas. Firewall/ routeur IPv6 de l'université. Un cas plus simple. Cette réalisation date de Juillet Un besoin exprimé depuis longtemps était de redéployer IPv6 à l'université de Nantes Nous avions participé aux phases pilotes de Renater -. Notre routeur d'extrémité supporte IPv6, mais pas les routeurs de cœur de notre réseau, et ceux-ci ne seront remplacés que fin Nous ne voulions pas attendre davantage, tout en souhaitant le redéployer dans de bonnes conditions, avec entre autres pré-requis, le déploiement d'un firewall de site en mode restrictif, avec suivi de connexion. Nos firewall PIX ne répondent pas non plus à ces critères. Aussi nous avons décidé de démarrer un projet qui remplacerait les éléments qui nous manquent pour l'instant, un routeur interne, un firewall à suivi d'état, quelques services de base, et éventuellement un routeur multicast Ipv6. Figure 13 : Ensemble firewall et routeurs IPv6 Comme d'habitude, les fonctions ont été découpées au mieux, afin de pouvoir remplacer chaque élément par du matériel dédié lorsque cela sera possible. La figure 13 montre le découpage effectué. Cette machine est redondée par une seconde machine identique, qui peut prendre le relais si heartbeat constate une panne sur la machine primaire. Le routeur de site se charge de faire les annonces BGP IPv6, et dispose d'un route statique IPv6 vers notre système qui gère actuellement le /48 de l'université. IPv6 prend un chemin différent qu'ipv4 au niveau du routeur d'entrée, et arrive sur un ensemble de machines XEN virtuelles. Les 3 machines virtuelles XEN (le routeur, le firewall et les services) ne fonctionnent pas avec la même version du noyau Linux. En effet, le module de suivi de connexions netfilter n'existe pas en standard dans le noyau Linux. Le firewall fonctionne donc avec un noyau spécial. Un temps, un système BSD avait même été pressenti pour cette tâche. Afin que les réseaux de l'université souhaitant avoir une connectivité IPv6 puissent être routés, nous déportons les vlans nécessaires jusqu'au routeur, où ces vlans sont ensuite décapsulés en autant d'interfaces virtuelles. Ces interfaces, de type eth0.num_vlan sont ensuite utilisées directement par le processus de routage, qui est ici quagga. Le routage multicast, en phase de test, sera assuré par mrd6. Bibliographie [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] QEMU : PearPC : Le projet Linux-Vserver : XEN : EVMS : Device mapper : LVM2 : Ultramonkey : DRBD : Rsync : Csync2 : GFS/GFS2 OCFS2 : Rdist : cfengine : Lustre : Perdition :