Virtualisation du service de soumission de messages
Didier Benza
SEMIR, Centre de Recherche INRIA de Sophia-Antipolis
2004, route des lucioles - BP 93 – 06902 Sophia-Antipolis
didier.benzainria.fr
Denis Joiret
MIRIAD, Centre de Recherche INRIA de Rocquencourt
Rocquencourt
Denis.Joiretinria.fr
Résumé
Les applications réseau requièrent souvent une grande fiabilité et une haute disponibilité parce que le service qu'elles rendent est jugé critique. Le service de soumission de messages électroniques est un exemple des applications perçues comme tel par les utilisateurs eux-mêmes. Si des mécanismes existent pour fiabiliser la transmission des messages entre serveurs SMTP, ce n'est pas le cas de la soumission initiale de courriels par les logiciels clients de messagerie. Ces clients ne disposent généralement pas de mécanismes permettant de traiter efficacement l'indisponibilité d'un serveur, ce qui pénalise fortement les usagers lors d'une panne. Ce document présente l'implémentation d'une solution permettant de fiabiliser le service de soumission des messages électroniques. La solution est basée sur plusieurs mécanismes réseau, dont la technologie SLB (Server Load Balancing) qui rend virtuelle l'adresse IP d'un service ou la possibilité, offerte par RENATER, d'annoncer avec le protocole BGP un préfixe /32 sur plusieurs sites avec des poids différents. Sont également décrits ici les différents tests effectués pour valider la solution retenue, la méthodologie de déploiement et les outils de supervision du service. Enfin, le bilan d'une année d'exploitation est fait et des éléments d'appréciation de services éligibles à cette solution de «virtualisation IP» sont proposés.
Mots clefs
Server Load Balancing (SLB), Route Health Injection (RHI), Vues DNS, BGP, Communautés BGP, DNS
La haute disponibilité du service de messagerie électronique est désormais jugée nécessaire par les usagers, notamment par les directions des organismes. Cette exigence rend délicate la moindre intervention ou panne sur les serveurs qui hébergent ce service. Pour leurs échanges, les serveurs SMTP consultent les enregistrements MX (Mail eXchanger) du DNS afin d'obtenir une liste de serveurs auxquels ils relayeront un message à délivrer. En cas d'échec de connexion à un serveur, le serveur suivant dans la liste est contacté. Si l'ensemble des serveurs est indisponible, le message est conservé sur le dernier serveur joint qui réitère la tentative de connexion à intervalles réguliers. Ces mécanismes sont complètement transparents pour l'usager qui a réussi à soumettre son message. De son point de vue, le service est rendu. En revanche, aucun mécanisme normalisé ne permet de fiabiliser la soumission de messages par un poste client. Le protocole utilisé entre le client et le serveur est identique (SMTP), mais les enregistrements MX du DNS ne sont pas utilisés dans ce contexte. Les clients s'appuient sur une résolution DNS afin d'obtenir l'adresse IP du serveur et il est d'usage de fournir plusieurs adresses IP en réponse à cette requête afin de fiabiliser le service. Les serveurs DNS renvoient la liste d'adresses dans un ordre différent à chaque requête, suivant un algorithme de type Round Robin qui vise à permettre une répartition équilibrée des clients entre les différents serveurs. Coté client de messagerie, la gestion de cette liste se fait souvent de façon inefficace : la première adresse est souvent la seule utilisée. En cas d'échec à joindre une adresse, le repli éventuel vers une adresse alternative de la liste est très aléatoire et dépendant de l'application cliente et du système d'exploitation qui l'héberge. Certaines combinaisons ont des comportements très pénalisants pour l'utilisateur final. L'envoi d'un message dans le cas d'une panne d'un seul serveur peut s'avérer quasiment impossible, même si plusieurs autres serveurs sont disponibles.
Depuis 2007, le service de relais, soumission et filtrage de messagerie électronique de l'INRIA est opéré au niveau national. L'infrastructure matérielle du service est constituée de 4 boîtiers (appliances IronPort1). Deux de ces boîtiers sont hébergés par le site de Rocquencourt et les deux autres par le site de Sophia-Antipolis. Les deux sites ont une connexion directe sur RENATER. Ces boîtiers sont utilisées à la fois pour l'acheminement des messages, via le port TCP 25 et pour la soumission des messages via le port TCP 587. La technique d'enregistrements multiples pour un même nom DNS (smtp.inria.fr) a été utilisée afin de répartir les clients de messagerie entre les boîtiers. Des blocages ont été observés sur certains environnements clients suite à l'indisponibilité d'un seul boîtier.
La DSI INRIA a donc lancé le projet «Virtualisation du service de soumission de messages » avec mission d'identifier et déployer un dispositif opérationnel assurant l'accessibilité et la disponibilité du service de soumission de messages, en cas de panne d'un boitier ou d'un site hébergeur, sans aucune intervention humaine. La coupure des connexions en cours était considérée comme acceptable, ainsi qu’une éventuelle plage d'indisponibilité du service de quelques minutes.
La note de cadrage du projet décrivait par ailleurs quelques impératifs forts. Le projet devait être réalisé dans un délai de quelques mois. Il fallait privilégier l’utilisation d’équipements déjà acquis ou ne demandant pas de procédure d’acquisition longue. Il s'agissait de trouver un bon compromis entre le temps d’indisponibilité du service en cas de panne et la simplicité de la solution. L'équipe-projet devait être réduite à 2 ou 3 personnes issues impérativement des sites hébergeant les boîtiers afin de faciliter la phase de réalisation et disposant de compétences en routage réseau ainsi qu'en mécanismes de haute disponibilité.
Les technologies suivantes ont été utilisées et combinées dans le cadre de ce projet :
Les communautés BGP
IOS Server Load Balacing
Route Health Injection
Les vues DNS
Les routeurs BGP peuvent appliquer des décisions de routage qui tiennent compte de la valeur de l'attribut optionnel community qu'on utilise généralement pour permettre le regroupement de plusieurs destinations. Cet attribut est normalement conservé lors de la traversée des différents AS. Les communautés s'écrivent sous la forme standardisée N° d'AS:Valeur. Sur un routeur Cisco, on utilise des route-maps pour prendre des décisions de routage en fonction d'une communauté. Les route-maps peuvent aussi être utilisées pour affecter une valeur de communauté à une annonce.
RENATER a mis en place différentes communautés BGP de service2 qui peuvent être utilisées pour les annonces de préfixes des établissements. Deux de ces communautés nous intéressent plus particulièrement dans le cadre de ce projet :
la communauté 2200:610 permet d'annoncer un chemin primaire dans le cas d'un réseau avec plusieurs attachements sur RENATER
la communauté 2200:590 permet d'annoncer un chemin secondaire dans le cas d'un réseau avec plusieurs attachements sur RENATER
Lorsque les équipements de RENATER doivent acheminer un paquet vers un préfixe avec plusieurs attachements, ils choisissent en priorité la route du préfixe marqué avec la communauté 2200:610.
Ce service peut être utilisé dans le contexte de ce projet car les deux sites sont directement raccordés à RENATER. Il est à noter que le service peut aussi être utilisé par des sites raccordés sur des réseaux régionaux différents interconnectés par RENATER. Il suffit pour cela que ces réseaux régionaux soient transparents pour les communautés BGP.
La fonction Server Load Balancing permet de fiabiliser et de répartir la charge d'un service applicatif sur plusieurs serveurs. Le service réel est hébergé sur plusieurs serveurs dont la véritable adresse est masquée à l'application cliente. Cette dernière référence un serveur virtuel configuré sur un équipement (ou appliance). Ce serveur virtuel répartit les requêtes qu'il reçoit entre les différents serveurs réels. Différents algorithmes permettent de choisir le serveur auquel la requête est envoyée (par exemple le serveur le moins utilisé).
Dans le cadre de ce projet, les composants suivants ont été exploités : composants logiciels IOS SLB disponibles avec la licence Advance IP Services sur les plateformes Cisco Catalyst 6500 ou les routeurs 7200.
La configuration d'un Load Balancer de type IOS se fait en 3 étapes :
Configuration des sondes qui permettent de tester si un serveur réel répond. Une sonde peut, au minimum, tester le port UDP ou TCP sur lequel un service est rendu. La fréquence des tests est paramétrable.
Configuration de la ferme de serveurs. Elle regroupe les serveurs réels en une entité logique. Elle exploite une sonde (ou plusieurs) pour déterminer l'état des serveurs. Elle peut aussi contrôler qu'un paquet SYN envoyé par un poste client est correctement acquitté par le serveur auquel il est transmis. Le nombre de paquets SYN sans réponse provoquant un retrait temporaire d'un serveur de la ferme est paramétrable. Lorsque tous les serveurs ont étés invalidés, la ferme passe dans l'état hors-service. La ferme peut être configurée pour utiliser la technologie NAT sur les adresses des serveurs ou des clients.
Configuration du serveur virtuel qui associe une adresse IP de service à une ferme de serveurs. Une ferme de secours peut être configurée pour pallier la défaillance de la ferme principale. Lorsque toutes les fermes de serveurs associées à un serveur virtuel sont indisponibles, le serveur lui-même devient indisponible. On peut définir une limite de nouvelles connexions par intervalle de temps, cela permet d'éviter une attaque DoS contre la CPU du routeur. On peut activer le mécanisme Route Health Injection (RHI) qui conditionne l'installation d'une route statique dans la table de routage du routeur à l'état du serveur virtuel. Si le serveur virtuel devient indisponible, la route vers ce serveur virtuel est retirée de la table de routage du routeur.
Les vues DNS servent à différencier les réponses aux requêtes DNS en fonction du client. L'un des usages de ces vues consiste, par exemple, à autoriser le mode récursif seulement pour les clients du réseau local. Dans le contexte de ce projet, les vues nous ont servies à présenter une information différente aux clients locaux d'un site de celle présentée à des clients externes.
Le déploiement de cette solution n'a jamais été envisagé, mais c'est une brique de base de la solution déployée. Imaginons que nous souhaitions mettre en place ce mode de haute-disponibilité (HA) pour l'adresse smtp.inria.fr qui est configurée dans les logiciels de messagerie de tous les postes clients de l'INRIA : le service doit être principalement rendu par les boîtiers installées sur le site de Sophia. En cas de panne de ces boîtiers ou en cas de coupure réseau du site de Sophia, on souhaite que les boîtiers de Rocquencourt continuent à assurer le service sans impact perceptible pour les usagers, qu'ils soient localisés sur un Centre de Recherche INRIA ou en déplacement. Les postes clients de Rocquencourt utilisent normalement les boîtiers de ce site. Ils n'utilisent les boîtiers de Sophia qu'en cas de panne de ceux de Rocquencourt. Ci-après, on se limite à décrire la configuration nécessaire sur Sophia pour mettre en place ce mode de HA, la configuration des équipements de Rocquencourt étant similaire.
1. On modifie les agréments RENATER des deux sites. On indique que le préfixe 192.134.164.146/32 est un préfixe multi-site qui sera annoncé sur les sites de Rocquencourt et de Sophia-Antipolis.
2 On configure le routeur de Sophia-Antipolis
|
Configuration
d'une sonde nommée SUBMISSION
chargée de tester l'accessibilité du port TCP
587.
Ce test est réalisé toutes les 60 secondes. |
ip slb probe SUBMISSION TCP port 587 interval 60 |
|
|
ip slb serverfarm IRONPORTS nat server probe SUBMISSION ! real 192.134.164.104 reassign 2 faildetect numconns 8 numclients 1 inservice ! real 192.134.164.105 reassign 2 faildetect numconns 8 numclients 1 inservice |
Création d'une ferme de serveurs nommée IRONPORTS qui utilise les deux boîtiers du site. On active la technologie NAT afin que le routeur remplace l'adresse de destination par l'adresse du boîtier qui devra traiter le paquet. On exploite la sonde SUBMISSION définie précédemment pour tester la présence des serveurs. On exploite aussi les connexions des clients eux-mêmes afin de tester le service : la ferme vérifie qu'il y a bien un paquet SYN+ACK renvoyé par les boîtiers pour chaque paquet SYN envoyé par les clients à chaque serveur. Après 8 paquets SYN de différents clients sans réponse, le serveur est considéré comme défaillant (faildetect). La ferme n'utilise pas plus de deux paquets SYN du même client (reassign). Au-delà de cette valeur, la longueur du délai de soumission devient perceptible pour celui qui tente de soumettre un message.
L'utilisation d'une sonde permet de détecter qu'un serveur
est rétabli, y compris en l'absence de trafic des postes
clients. |
|
|
Configuration d'un serveur virtuel nommé VS qui répond à l'adresse IP 192.134.164.146. Ce serveur virtuel utilise la ferme de serveurs définie précédemment. Le mécanisme RHI (advertise) est activé pour conditionner à l'état du serveur virtuel la présence de l'adresse 192.134.164.146 dans la table de routage du routeur SLB. |
ip slb vserver VS virtual 192.134.164.146 TCP 0 serverfarm IRONPORTS advertise active inservice
|
|
|
route-map set-BGP-community-slb-ironport permit 10 set community 2200:610 router BGP 776 ... address-family ipv4 ... neighbor 193.51.181.138 send-community network 192.134.164.146 mask 255.255.255.255 route-map set-BGP--community-slb-ironport ... exit-address-family |
Configuration d'une route-map nommée set-BGP-community-slb-ironport chargée de positionner la communauté du préfixe 192.134.164.146/32 à la valeur 2200:610. Le routeur est configuré pour annoncer les communautés au routeur de RENATER. Le routeur de Rocquencourt est configuré à l'identique, excepté :
|
|
Le mécanisme RHI, couplé à l'utilisation d'une sonde permet de rétablir le routage vers le site principal dès qu'un serveur réel de ce site redevient opérationnel. Imaginons que les deux boîtiers de Sophia sont hors service : cela signifie que tous les flux des postes clients sont redirigés sur Rocquencourt. Sans les tests de la sonde et en l'absence de flux provenant des postes clients, on ne peut pas tester les boîtiers et donc rien ne peut provoquer le retour du routage vers Sophia sauf une intervention humaine sur le routeur de site.
3. On configure enfin les serveurs DNS de l'INRIA pour associer l'adresse 192.134.164.146 au nom smtp.inria.fr.
L
Figure 1:
Solution théorique en mode actif/actif asymétrique
e routeur de Sophia annonce une route vers le
préfixe 192.134.164.146/32
avec une communauté 2200:610,
le routeur de Rocquencourt annonce le même préfixe avec
la communauté 2200:590.
RENATER connaît donc deux routes différentes pour
atteindre ce préfixe, mais privilégie la route vers
Sophia (priorité du 610).
La figure 1 représente le cheminement des flux dans la
solution mise en place. Le service SLB
répartit les connexions entre les deux boîtiers du
site. Toutes les connexions de soumission de messages des clients
sont routées vers Sophia, excepté les connexions
depuis des clients du site de Rocquencourt qui sont acheminées
vers le serveur virtuel hébergé par le routeur de
site. En effet, le routeur de Rocquencourt connaît une route
locale vers l'adresse 192.134.164.146,
celle du serveur virtuel qui lui est configuré.
Scénarios de pannes :
♦ Si l'un des boîtiers de Sophia tombe, le routeur SLB de Sophia le détecte (test par sonde ou paquets SYN sans réponse) et le boîtier est retiré de la liste des serveurs actifs. Les connexions suivantes sont dirigées vers le boîtier de Sophia encore opérationnel.
♦ Si le second boîtier tombe également (pas de chance...), il est retiré de la liste des serveurs actifs. La liste des serveurs est vide, le service SLB retire alors de la table de routage la route vers le préfixe 192.134.164.146/32. Comme le préfixe disparaît, le routeur de Sophia ne l'annonce plus à RENATER. RENATER ne connait plus alors qu'une route vers ce préfixe : celle de Rocquencourt et route donc tout le trafic à destination du 192.134.164.146/32 vers ce site. Rien ne change pour les flux des postes clients de Rocquencourt.
♦ Si un troisième boîtier, l'un de ceux de Rocquencourt, tombe en panne (vraiment pas de chance...), tous les paquets seront envoyés vers le dernier boîtier par le service SLB de Rocquencourt.
♦ Inversement si tous les boîtiers de Rocquencourt tombent en panne alors que les boîtiers de Sophia sont en service, la route vers le préfixe 192.134.164.146/32 est retirée de la table locale et les paquets des postes clients de Rocquencourt sont acheminés vers la route par défaut, c'est-à-dire vers RENATER qui les achemine vers la seule route qu'il connaît alors : le site de Sophia.
Cette solution résiste donc de façon automatisée à la perte de 3 boîtiers sur 4 et aussi à la perte de connectivité de l'un des deux sites sans aucun impact sur le service de soumission de messages pour les utilisateurs. Lors des opérations de résolution des pannes, les administrateurs peuvent se focaliser sur les causes des pannes, car ils savent que le retour en production de l'équipement en panne dans la solution de haute-disponibilité se fera sans intervention humaine.
Dans ce modèle d'organisation, la charge n'est pas répartie équitablement entre les équipements puisqu'en situation normale (4 boîtiers opérationnels), ceux du site de Rocquencourt ne traitent que les seules connexions des clients du site.
Figure 2:
Solution théorique actif/actif symétrique
Cette solution est obtenue par combinaison de
deux modes asymétriques : un mode asymétrique
avec l'adresse 192.134.164.146,
Sophia étant le site principal et Rocquencourt le site
secondaire de secours et un mode asymétrique avec une seconde
adresse, 192.134.164.145,
Rocquencourt étant le site principal et Sophia le site
secondaire de secours. Chaque routeur de site héberge donc
deux SLB
et annonce les deux préfixes : l'un avec la communauté
2200:610
et l'autre avec la communauté 2200:590.
Les serveurs DNS
de l'INRIA sont configurés afin qu'ils renvoient les deux
adresses lorsqu'ils sont interrogés pour résoudre le
nom smtp.inria.fr.
Les clients se répartissent (par mécanisme de round
robin DNS)
entre les boîtiers de Sophia et de Rocquencourt, exception
faite des clients des sites hébergeurs qui utilisent les
boîtiers locaux. La figure 2 permet de voir les flux vers
chacun des deux préfixes en fonction de la localisation d'un
poste client.
Lorsque les deux boîtiers d'un site sont hors service, le routeur du site n'annonce plus à RENATER les adresses pour lesquelles il est primaire et secondaire. Les flux sont donc immédiatement routés par RENATER vers le site de secours, sans aucun impact pour les postes clients.
Afin de valider le fonctionnement de la solution, nous avons réalisé une maquette sur les routeurs des sites de Rocquencourt et de Sophia-Antipolis permettant d'accéder, sur chaque site, à une ferme de deux serveurs web. Les serveurs ont été réalisés en configurant des machines avec la distribution Linux Turnkey LAMP3. Pour ces tests, la sonde utilisée dans chaque routeur a été configurée pour tester le port 80.
Un protocole de test a été mis au point pour vérifier et valider le comportement de la solution. Pour chaque test, un résultat ou un comportement précis était attendu. Une machine connectée en ADSL permettait de vérifier le comportement d'un client nomade ou hors site hébergeur. Il a été vérifié que les connexions des clients sur les sites hébergeurs vers les adresses des serveurs virtuels de Rocquencourt ou de Sophia (respectivement VR ou VS par la suite) atteignaient toujours la ferme locale de boîtiers et que les connexions depuis la machine ADSL vers les adresses VR et VS étaient bien routées respectivement sur les fermes des sites de Rocquencourt et Sophia-Antipolis.
♦ Suite à l'arrêt provoqué des serveurs virtuels sur l'un des sites hébergeurs, les deux adresses virtuelles ont bien étés routées par RENATER vers l'autre site. Le client sur la machine en ADSL n'a pas subi de rupture de service. Le trafic des clients du site sur lequel les serveurs virtuels ont été arrêtés a bien été redirigé vers l'autre site hébergeur. Il n'y a pas eu d'impact pour le site hébergeur sur lequel les services web sont restés actifs. Après remise en service des deux serveurs virtuels arrêtés, le routage du trafic est revenu à l'état initial.
♦ L'arrêt simultané d'un serveur web réel sur chaque site n'a pas eu d'impact sur les annonces BGP car il restait un serveur fonctionnel sur chaque site. Il n'y a donc pas eu d'impact pour les sites hébergeurs et la machine ADSL.
♦ Lorsqu'on a arrêté les deux serveurs web réels de l'un des sites hébergeurs, les deux adresses virtuelles ont bien été routées par RENATER vers l'autre site et donc la machine ADSL a continué à accéder au service, quelle que soit l'adresse virtuelle utilisée. Il n'y a pas eu de changement pour le site hébergeur sur lequel les serveurs web réels sont restés actifs. En revanche, les clients du site où les services ont été arrêtés ont perdu l'accès au service. Une analyse a permis d'identifier une prévalence du mécanisme SLB sur le mécanisme de routage du routeur de sortie : alors que les routes vers VR et VS n'étaient plus dans la table de routage, le routeur SLB continuait à intercepter les adresses virtuelles et à envoyer les connexions vers la ferme locale de serveurs. Après redémarrage des services web, la situation est revenue à la normale.
♦ L'instabilité (flapping) de l'adresse VR a été simulée par l'arrêt et le démarrage à plusieurs reprises du serveur virtuel correspondant à VR sur le site de Rocquencourt. Cela a conduit à l'augmentation de la pénalité associée à l'annonce de VR sur RENATER et finalement l'annonce de Rocquencourt n'a plus été prise en compte (dampening). En revanche, l'annonce de VR par Sophia-Antipolis est devenue active sur RENATER. Il n'y a donc pas eu d'impact, aussi bien sur les sites hébergeurs que pour la machine ADSL. Après un délai assez long (plusieurs dizaines de minutes), la pénalité de l'annonce a disparue et la situation est revenue à l'état initial. Lors de ces modifications d'annonces BGP la convergence du routage sur RENATER a été très rapide au point qu'aucune interruption de service n'a été observée depuis le client raccordé en ADSL.
Figure 3: Impact du SLB sur la CPU
D'autres tests ont été effectués pour évaluer l'impact de la fonction SLB sur la CPU des routeurs. Nous avons développé un script utilisant un outil de simulation de trafic web du domaine public4. Le script relevait la valeur de la variable CPU 1 minute en utilisant le protocole SNMP puis lançait un scénario de charge qui durait 90 secondes. Le script relevait ensuite de nouveau la variable SNMP CPU1 et attendait 90 secondes avant de générer un nouveau scénario et de procéder à un nouveau test. Cela permettait d'éliminer toute possibilité de cumul de la charge CPU d'un test sur l'autre. On a considéré que, puisque le test durait 90 secondes, la différence entre les deux valeurs CPU relevées était principalement imputable à la charge engendrée par le SLB.
Comme le montre la figure 3, l'impact du SLB sur la CPU est significatif à partir de plusieurs centaines de connexions par seconde. Des résultats similaires ont été observés sur l’équipement de Rocquencourt.
Pour réduire l'impact de la fonction SLB sur la CPU du routeur (et d'éventuels effets induits sur des fonctions vitales, comme le routage lui-même), une limitation du nombre de connexions par seconde a été décidée. Pour fixer une valeur réaliste, le nombre de connexions aux boîtiers sur le port de soumission a été mesuré durant 24 heures. Le taux de connexion observé était de l'ordre d'une connexion toutes les 8 secondes. Sur ces bases, la valeur de 80 connexions maximum par seconde vers chaque serveur virtuel a été retenue. Cette limitation a été réalisée par l'ajout d'une directive synguard dans la définition des deux serveurs virtuels.
Le problème de la prévalence du routage SLB décrit au chapitre 4.1 restait à résoudre. Après quelques recherches vaines d'une solution purement réseau, notamment à base de route statique, une solution basée sur la configuration de fermes de secours et de vues DNS a finalement été retenue.
Dans chaque routeur SLB une seconde ferme de serveurs est configurée utilisant les deux serveurs réels de l'autre site hébergeur. Cette ferme est destinée à pallier la panne des deux serveurs locaux. Elle est installée comme ferme de secours dans la configuration du serveur virtuel secondaire.
Les serveurs DNS locaux de chaque site hébergeur ont été configurés pour renvoyer l'adresse du serveur virtuel secondaire lorsqu'un client du site demande l'adresse IP de smtp.inria.fr. Par exemple à Sophia-Antipolis, le serveur DNS local renvoie l'adresse VR (192.134.164.145) en réponse à une requête locale de résolution d'adresse pour smtp.inria.fr. Lorsque la requête provient d'un autre réseau, le serveur DNS renvoie les adresses VR et VS avec la technique de Round Robin. En cas de panne des deux boîtiers du site de Sophia-Antipolis, un client local utilise alors automatiquement la ferme de serveurs de secours. Pour un client d'un autre réseau, les adresses VR et VS sont toujours routées par RENATER sur Rocquencourt, comme c'était déjà le cas précédemment.
Voici la configuration modifiée sur le routeur de Sophia-Antipolis :
|
ip slb serverfarm IRONPORTS-BAK nat server ! real 192.134.164.82 reassign 2 faildetect numconns 8 numclients 1 inservice ! real 192.134.164.83 reassign 2 faildetect numconns 8 numclients 1 inservice
|
Création
d'une ferme de serveurs nommée IRONPORTS-BAK
qui utilise les deux boîtiers
de l'autre site hébergeur (ici les boîtiers
de Rocquencourt). La ferme n'utilise aucune sonde de test
des serveurs car il s'agit de serveurs de secours.
Le reste de la configuration est identique à celle de la
ferme IRONTPORT
précédemment définie. |
|||
|
|
Modification du serveur virtuel VR (correspondant au préfixe de Rocquencourt) en lui ajoutant la ferme de secours. On ajoute la directive synguard pour la protection du routeur |
|
ip slb vserver VR virtual 192.134.164.145 TCP 0 serverfarm IRONPORTS backup IRONPORTS-BAK advertise active synguard 80 100 inservice |
|
Les travaux ont été menés en collaboration étroite avec l'équipe opérationnelle (ET Mail5) INRIA qui gère les boîtiers et administre la messagerie au niveau de l'Institut. Il s'agissait notamment d'effectuer les tests de qualification les plus exhaustifs possibles avant la mise en production.
Cette phase a consisté à mettre en place la configuration symétrique décrite ci-dessus et à enregistrer dans le DNS les adresses 192.93.164.145 et 192.134.164.146 avec le nom smtp test.inria.fr. Un groupe de volontaires, pris dans les Services Informatiques de tous les sites INRIA a été sollicité pour configurer cette adresse comme serveur de soumission des messages dans son logiciel de messagerie électronique. Aucun problème n'a été signalé pendant cette phase de tests qui a duré 2 semaines.
Après les tests des différents cas de pannes réalisés sur la maquette web, il était important de vérifier que la solution fonctionnait correctement avec les boîtiers de messagerie. Il fallait pouvoir provoquer des pannes pendant la transmission de messages afin d'en évaluer l'impact. L'ET Mail a mis en service un listener supplémentaire sur chacun des boîtiers sur le port 588 pour les besoins des tests et les sondes des routeurs ont été modifiées pour tester ce port au lieu du port 587. La simulation de la panne d'un boîtier était effectuée en stoppant ce listener. Tous les tests de panne ont été déroulés sur les deux sites (1, 2 ou 3 boîtiers en panne dans toutes les combinaisons et dampening d'un des préfixes). Lors de chaque simulation de panne, des courriers de taille importante étaient émis depuis différents clients de messagerie (Outlook, Thunderbird, exmh, etc.) et depuis tous les sites INRIA. Durant tous les tests et simulations de pannes effectués, aucune perte de message n'a été constatée. Une panne sur RENATER (lors de la migration RENATER 5) est intervenue pendant la séance des tests. Lors de cette panne, le site de Sophia n'a plus été connecté à l'Internet que par sa liaison sur le réseau régional SHERPAA. Cette panne n'a pas provoqué de coupure de service.
La mise en service opérationnel de la solution s'est effectuée par modifications successives du DNS afin de maîtriser la montée en charge du trafic sur les routeurs et d'évaluer l'impact sur leur ressource CPU. En cas d'impact imprévu, le retour arrière pouvait s'opérer sans difficulté. La configuration initiale du DNS contenait les 4 enregistrements A associés au nom smtp.inria.fr qui correspondaient aux adresses respectives des 4 boîtiers. Après avoir baissé le TTL de ces enregistrements, un des 4 enregistrements a été remplacé par l'adresse de VR. Le serveur virtuel de Rocquencourt s'est mis à recevoir 25% des connexions sans impact sur le service. Un second enregistrement initial a été remplacé par l'adresse VS, 50% des connexions ont alors transité par les deux serveurs virtuels. À la suppression d'un troisième enregistrement, la charge s'est répartie comme prévu à raison d'un tiers entre les trois adresses restantes, toujours sans impact notable sur les routeurs supportant le SLB. Le dernier enregistrement a donc été supprimé et la charge s'est répartie équitablement entre les deux serveurs virtuels VR et VS. Comme prévu, compte tenu de la charge modeste du trafic opérationnel, aucun impact n'a été observé sur les CPU des routeurs des sites hébergeurs.
Avec la mise en place de la solution technique, l'équipe projet a livré les composants suivants :
une documentation qui décrit le fonctionnement de la solution déployée, la configuration des équipements sur chacun des sites, les commandes de base permettant d'évaluer l'état des serveurs virtuels et les procédures d'arrêt.
un portail web qui permet d'accéder rapidement aux informations les plus utiles : état du routage BGP (issu du looking glass de RENATER6), état du routeur avec des courbes produites par Cacti7 (charge CPU, nombre de connexions par minute sur chaque serveur virtuel, charge du lien avec RENATER), les logs du routeur pour la journée en cours. Une interface réalisée avec AjaxTerm8 permet de se connecter au routeur dans un environnement restreint grâce à un compte non privilégié qui n'est autorisé qu'à visualiser (commandes IOS show …)
une description des périmètres de responsabilité respectifs entre l'ET Mail et les équipes réseau des sites hébergeur. L'ET Mail gère les boîtiers, les équipes réseau gèrent les routeurs et agissent en « MOE » de l'ET Mail sur toute modification de la configuration des routeurs
Les contraintes initiales du projet ont toutes été respectées. Le projet a été réalisé en 130 jours pour une charge de 45 hommes-jours. Les équipements utilisés étaient déjà présents et opérationnels. La solution ne peut pas être qualifiée de « simple », mais aucune des technologies utilisées n'est complexe en elle-même. La solution permet de résister à la perte de 3 boîtiers sur 4, sans impact sur le service rendu à l'usager. L'équipe en charge de la messagerie peut dorénavant faire la plus grande partie des opérations de maintenance courantes sans intervention dans la gestion de la virtualisation et sans opérations préalables sur le DNS. La solution a été observée en production pendant une année. Chacun des deux sites hébergeurs a connu des coupures de l'accès Internet sans impact sur le service. Les appliances Ironport ont fait l'objet de mises à jour pendant les heures ouvrées sans annonce préalable et sans impact sur les usagers. En une année d'exploitation, aucune indisponibilité ou coupure de service n'a été enregistrée.
La solution de virtualisation de services IP décrite ici n'est pas spécifique au service de soumission de messages. D'autres services IP pourraient en bénéficier avec quelques ajustements ou adaptations de paramétrage.
Les applications réseau sans état où le client et le serveur ne conservent pas d'informations d'états intermédiaires sont éligibles a priori. Le service DNS, par exemple, semble correspondre à ces critères. La résolution de noms est sans état et certains resolvers gèrent mal le repli vers un serveur DNS secondaire. Cela peut entraîner des ralentissements importants pour les applications utilisateurs, voire sur des serveurs.
La virtualisation des services IP peut aussi être employée pour des applications à états, mais dans ce cas la panne d'un serveur impactera le service : le client, redirigé automatiquement vers un nouveau serveur, adressera des informations d'état (identifiants de session, cookies...) que le nouveau serveur ne saura pas exploiter. Le serveur ne connaissant pas l'état du client, celui-ci se trouvera de facto déconnecté de l'application. Il devra reprendre la transaction depuis le début. Pour un grand nombre d'applications, on peut juger que cet évènement rare est acceptable, le service restant disponible sans intervention humaine. Il faut noter que pour des applications à états, le mode sticky doit être utilisé dans la configuration SLB, lors de la définition des serveurs virtuels. Dans ce mode, un client est toujours dirigé vers le même serveur réel.
Le service décrit ici a été déployé avec une implémentation logicielle des fonctions SLB. Cela a été possible, car la charge induite par le trafic était très faible. Pour un service engendrant un grand nombre de connexions, des équipements spécialisés devraient être utilisés.
3 Linux Trunkey Lamp : http://www.turnkeylinux.org/appliances/lamp
4 Curl-loader : http://curl-loader.sourceforge.net/
5 ET : Équipe Transversale. Il s'agit d'équipes d'ingénieurs provenant des différents centres en charge de l'exploitation d'une solution nationale
6 URL du looking glass de Renater : https://noc.cssi.renater.fr/-l-g-v-6-/lg.pl
7 URL de la page d'accueil de Cacti : http://www.cacti.net/
8 URL de la page d'accueil d'AjaxTerm : http://antony.lesuisse.org/software/ajaxterm/