FLASH INFORMATIQUE FI



Server Load Balancing, le réseau s’en charge




Daniel GRANDJEAN

Georges AUBRY


Introduction

Cet article donne un aperçu de la technologie de répartition de charge et indique comment elle est utilisée pour offrir des services critiques sur notre réseau EPNET au moyen des équipements du constructeur Cisco. Ce dispositif de répartition de charge permet d’une part d’améliorer la performance des applications en utilisant plusieurs serveurs et d’autre part d’offrir une solution d’accès rapide et fiable aux services.

Terminologie

Nous utiliserons au cours de cet article l’acronyme SLB pour désigner le système de distribution de charge. Selon le fournisseur et la technologie utilisée, on rencontre les appellations assimilables suivantes :

  • System Load Balancer
  • Server Load Balancer
  • Content Switching
  • Content Distribution
  • Commutateur de services de contenus
  • Services de partage de charge
  • Répartiteur de charge.

Ces différents vocables recouvrent des services réseau qui s’étendent jusqu’à la couche OSI 7. Les buts sont d’améliorer des services dépendants du réseau pour plus de

  • fiabilité
  • performance
  • sécurité
  • aisance de gestion
  • aisance de (re)dimensionnement.

Principe de répartition de charge

Le concept est un serveur virtuel pour plusieurs serveurs réels. Le principe est simple, d’une part l’utilisateur devient client d’un serveur virtuel en contactant l’adresse IP virtuelle (VIP) correspondant à un service. D’autre part, sur le SLB, le serveur virtuel ayant l’adresse VIP est chargé de sélectionner un serveur réel pour lui transmettre la requête des clients. Le serveur réel sélectionné traite la requête et répond aux clients.

  • Les serveurs réels sont chacun dotés d’une adresse IP réelle (RIP). Les serveurs réels offrant un service identique sont regroupés dans des ensembles nommés fermes ou farms. Ne pas interpréter les notions de réel et de virtuel dans le sens utilisé chez VMware ou XEN. Ici un serveur réel peut parfaitement être une machine virtuelle VMware.
  • Le serveur virtuel est une entité logique qui représente plusieurs serveurs réels pour un type de service. Le serveur virtuel est accédé à travers son adresse IP virtuelle (VIP). Les caractéristiques de distribution du trafic vers les serveurs réels de la ferme sont associées au serveur virtuel.

  • Les clients n’ont à connaître que le nom IP du service qu’ils désirent contacter, ce nom est traduit en une adresse VIP par le DNS. Le client ignore la nature et les adresses des serveurs réels.

Que fait un SLB ?

  • Il intercepte le trafic destiné à un service.
  • Il divise le trafic en plusieurs requêtes individuelles et décide quel serveur (réel) traitera ces requêtes (distribution).
  • Il surveille les serveurs disponibles, s’assurant qu’ils répondent au trafic. Dans la négative, il écarte ces serveurs (inaptes au service) de la distribution.
  • Il offre de la redondance (et il est lui-même redondant).
  • Il offre une distribution dépendante du contenu. En lisant -par exemple- le contenu des URL, des cookies.
  • Il collecte des informations sur son propre usage.

Historique du projet SLB sur EPNET

Fin 2001, dans une rafale d’annonces de projets pour regrouper les services Web de l’école, fournir des services de fichiers, des services WebDAV, de la bureautique, des espaces Web à tous les étudiants et le regroupement de services Web de département au niveau des facultés, le DIT-TI se penche sur les technologies SLB ; une mise en exploitation fiable et efficace d’une telle infrastructure requérant à terme de telles technologies.
Pour assurer ses propres services Web et en estimer les contraintes de déploiement (configuration, gestion et délégation), le DIT-TI introduit un sous-ensemble de ces technologies (serveur virtuel, reverse proxy, chiffrage SSL, compression, cache, redondance) sous la forme d’un service d’inspection des flux HTTP.
En 2005, les services à l’utilisateur gravitant autour de my.epfl réaniment la demande de fonctionnalités de distribution de charge. Le but du projet de la DIT-TI est de fournir ces fonctionnalités SLB dans le cadre de l’infrastructure EPNET.
Début 2006, le service de répartition de charge déployé sur des équipements Cisco entre en production.
Les contraintes qui s’appliquaient à l’élaboration de ce nouveau service furent :

  • Il ne doit pas poser de contraintes lourdes sur la configuration des fournisseurs de services (l’idéal étant de n’exiger du fournisseur qu’une définition claire du service).
  • Il n’exige aucune modification du client du service (transparence).
  • Il doit s’intégrer facilement dans l’infrastructure existante.
  • Il doit demander une gestion minimale.
  • Il est mutualisé entre les utilisateurs (fournisseurs de services).
  • Il ne doit pas dégrader l’offre existante.
  • Il reste simple et compréhensible (pour les gestionnaires et les utilisateurs).
  • Il ne sera pas biaisé pour satisfaire des requêtes en contradiction avec les points précédents.

Concrètement : un ou plusieurs serveurs fournissent un service. Un site Web est un bon exemple. Le fournisseur de service Web devient le client de notre offre SLB. Le client du service Web, qui visite le site avec son butineur profite des améliorations de ce service. Il n’est pas autrement concerné par les moyens mis en oeuvre pour offrir cette prestation.

Différents moyens de répartition de charge

Les techniques de distribution de charge visent tout ou partie de ces trois buts :

  • capacité ;
  • disponibilité ;
  • simplicité d’usage.

Selon la nature et la qualité du service à offrir, différentes approches sont envisageables : NLB, DNS Round Robin ou un équipement spécialisé.

Network Load Balancing (NLB)

Dans son offre de serveur propriétaire, Microsoft approche la distribution de charge par le biais de l’inondation au niveau OSI 2. Pour être fiable et sûre, cette méthode implique la création de domaines de broadcasts dédiés ou de table ARP statique. Au sortir de la boîte, elle expose indûment des trafics sur les ports d’un réseau commuté. Dans un environnement de machine virtuelle, elle altère les performances des commutateurs logiciels.

DNS Round Robin

Plus haut dans les couches OSI, la technique du DNS Round Robin est une bonne candidate pour augmenter la capacité d’un service et le distribuer géographiquement. Ce mécanisme d’équilibrage de charge consiste à utiliser une fonctionnalité du DNS pour associer une liste d’adresses IP de serveurs à un seul nom IP de service. À chaque résolution nom/adresse, l’adresse suivante dans la liste est utilisée. Le trafic est donc distribué par rotation. Bien que simple et efficace, à défaut d’autres solutions, cette façon de faire est rudimentaire et a ses limites. Pour démonstration, en voici quelques-unes :

  • Problèmes de cache : l’ajout ou la suppression d’un serveur demande une intervention au niveau des tables DNS et ne sera effectif que lorsque tous les clients du monde auront oublié l’ancienne table.
  • Problème de sécurité : la liste des serveurs fournissant un service est publiée et renseigne l’agresseur sur leur nombre et leur adresse réelle.
  • Problème de tolérance aux pannes : lors de la défection d’un serveur, son adresse IP doit être reprise par un des serveurs valides en attendant qu’une table DNS soit publiée sans cette adresse fautive. D’où une intervention au niveau des serveurs.
  • Problème de suivi de sessions : il n’y a aucune vision globale du trafic. Le couple client-serveur à un temps donné est imprévisible, ce qui complexifie la logique des sessions au niveau des serveurs.

Équipement CSM

La technique de répartition de charges est mise en oeuvre sur notre réseau grâce à un switch équipé d’un module CSM (Content Switching Module) de Cisco. Le module CSM permet d’atteindre des performances élevées et dispose de fonctions de transport et d’application (niveau OSI 4 à 7), pouvant offrir une solution d’accès aux services rapide et fiable. Il s’intègre parfaitement à la plate-forme logicielle IOS du commutateur.
Un répartiteur de charge basé sur un équipement spécialisé tel que le CSM dispose de nouvelles fonctionnalités et de puissance de traitement qui le rend beaucoup plus efficace que le DNS Round Robin.

Techniques utilisées par le CSM

Méthodes de répartition

Il y a différentes méthodes de répartition de charge qui permettent d’optimiser au mieux ce procédé selon les besoins de l’application.

Ces méthodes sont :

  • Round Robin : choix rotatif d’un nouveau serveur parmi l’ensemble de serveurs Weighted Round Robin : Round Robin pondéré pour mieux gérer des serveurs ayant différentes capacités de traitement.
  • Least connections : sélection du serveur ayant le moins de connexion active à un moment donné, pas forcément le moins utilisé en ressources.
  • Weighted least connections : amélioration de l’algorithme least connections en ajoutant des poids de performance pour chaque serveur.
  • Source IP hash : sélection du serveur en fonction de l’adresse IP du client.
  • URL hashing : sélection du serveur en fonction du contenu de la requête.

Surveillance des serveurs

Le répartiteur de charges a besoin de connaître l’état d’un service ou d’un serveur, et, en cas de panne, de sortir ce serveur du groupe. Cette tâche de surveillance est exécutée à des intervalles réglables, au moyen de probes ou sondes créées sur le répartiteur de charges. La vérification de la connectivité à ces serveurs peut simplement consister à un contrôle par un ICMP ping du serveur ou un test de connexion au port de service pour voir s’il répond. Il est préférable, si possible, de compléter cette surveillance par un contrôle de contenu. Pour un serveur Web en testant le code de retour d’une requête HTTP, pour un service applicatif, tel le DNS, en testant la résolution d’un nom en adresse IP. Différentes sondes peuvent être combinées pour contrôler un même service. Toutefois, identifier le dysfonctionnement d’un service sur un serveur réel est complexe. Les seules sondes du répartiteur ne suffisent pas toujours. Dans certains cas il est préférable de compléter la surveillance par un service conçu par le développeur de l’applicatif. En effet, seule cette personne est à même de déterminer l’état des composants de son application. Le SLB interrogera ce service de surveillance pour en déduire l’état du serveur.
Suite à une panne ou une maintenance d’un composant, lors du rétablissement d’un serveur réel, ce dernier est automatiquement réintégré par le répartiteur.
Le processus de surveillance est un élément clé qui doit être particulièrement soigné pour garantir un bon fonctionnement de la répartition de charge.

Persistance des sessions utilisateurs

Pour certaines applications, il est important que toutes les connexions d’une session d’un utilisateur soient traitées par un même serveur réel. Cette approche simplifie la logique du service, car il n’est plus nécessaire de partager l’état des sessions en cours entre les serveurs, qui peuvent ainsi être totalement disjoints. C’est le cas pour des serveurs fournissant des contenus dynamiques. Lors de connexion à une base de données, il faut maintenir le client pendant toute la durée de la session sur le même serveur qui a été choisi lors de la première requête. Il existe différentes façons d’assurer cette persistance. Faire créer un cookie par le répartiteur ou par le serveur, ce cookie sera ensuite détecté pour identifier la session. Si l’usage d’un cookie n’est pas acceptable, le répartiteur utilise l’adresse IP du client pour déterminer la persistance de la session.

Gestion et contrôle des flux de trafic

Prenons l’exemple du client qui désire visiter le site my.epfl.ch :


  1. Le client effectue la requête http://my.epfl.ch.
  2. Une requête est envoyée au serveur DNS pour connaître l’adresse IP associée à l’URL.
  3. Le serveur DNS répond en donnant l’adresse IP virtuelle (VIP) du répartiteur de charges.
  4. Le client utilise l’adresse VIP pour envoyer la requête HTTP au répartiteur de charges (CSM).
  5. Le répartiteur CSM choisit selon l’algorithme prédéfini et leur disponibilité, l’un des serveurs. Ici, par exemple, le serveur X.
  6. Le répartiteur CSM effectue une translation (NAT) de l’adresse IP. L’adresse de destination (adresse VIP) est remplacée par l’adresse IP du serveur réel X. La requête est acheminée au serveur X.
  7. Le serveur traite la requête et envoie sa réponse à l’adresse du client. Ce paquet réponse est rerouté au CSM qui effectue le NAT inverse de l’adresse source, et l’achemine au client. Cette redirection du trafic de retour est accomplie par un routage politique (Policy Based Routing).

Lorsque le client se trouve dans le même sous-réseau que les serveurs réels, il est nécessaire d’effectuer un NAT de l’adresse IP du client. Sinon la réponse du serveur réel serait directement retournée au client sans passer par le CSM. De ce court-circuit découlerait l’interruption de la connexion par le client recevant une réponse ne provenant pas de l’adresse du service interrogé.

Redirection de trafic HTTP

Il est possible de configurer le CSM pour qu’il réponde lui-même au navigateur du client. Ce mode de fonctionnement est par exemple utile pour déclencher une redirection de HTTP vers HTTPS, rediriger le trafic sur une ferme de serveurs de backup ou vers l’annonce d’indisponibilité d’un service débordé.

Sécurité

Vue du réseau, la VIP d’un service n’est ’perméable ’ que pour les ports correspondant au service accessible à cette adresse. L’attaquant ne peut déduire l’architecture réelle mise en place pour assurer le service. Le SLB assure divers niveaux de protection contre des attaques DoS. À bas niveau c’est le SLB qui gère l’initialisation des connexions TCP pour se prémunir des SYN-FLOOD, déchargeant les serveurs réels de cette tâche improductive. À plus haut niveau, la distribution peut, par exemple, dépendre du format de l’URL requise par le client.

Architecture matérielle et haute disponibilité

Le coeur du réseau de l’EPFL étant composé essentiellement d’équipement Cisco 6500, les cartes de répartition de charge CSM (Content Switching Module) offrent intégration, maitrise des fonctionnalités SLB et fonctions évoluées d’interconnexion de réseaux. Le module de service CSM est installé dans un switch de services Catalyst 6509. Pour assurer les fonctions de cryptage et de décryptage SSL, un module Cisco SSL est installé dans le même châssis.


Afin d’assurer la haute disponibilité du service de répartition de charge, une même paire de cartes CSM et SSL est installée dans un second Catalyst 6509 redondant. Le mode de redondance est actif/passif pour les modules CSM, alors qu’il est actif/actif pour les modules SSL. Lorsqu’un des CSM tombe en panne, l’autre module prend le relais, ce qui laisse le temps au support du réseau de remédier à une éventuelle panne matérielle. Le module défectueux peut être extrait et remplacé, sans interruption de service. Cette redondance limite l’impact d’interruptions planifiées (mise à jour logicielle) ou non, aux sessions actives lors du basculement.
Pour utiliser toute la puissance disponible, les 2 modules SSL sont configurés en mode actif/actif. Si l’un d’eux venait à dysfonctionner, nous perdrions alors la moitié de notre capacité de chiffrement. Ce couple de modules :

  • Décharge les serveurs de production du travail de chiffrement. Le temps d’établissement de la connexion chiffrée est indépendant de la performance du serveur réel. La ressource de calcul cryptographique est mutualisée entre les services.
  • Simplifie le dépannage des services chiffrés.
  • Intègre les flux cryptés dans l’infrastructure SLB. Nous avons vu que des décisions de distribution peuvent être basées sur le contenu du trafic. Dans le cas de flux chiffrés, le contenu est par définition inaccessible. L’introduction d’un module SSL termine le tunnel encrypté à l’intérieur de l’infrastructure SLB. Ce dernier peut alors accéder aux informations pertinentes à sa tâche. Il est tout à fait possible ensuite, si la confidentialité l’exige, d’établir de nouveaux tunnels SSL vers les serveurs réels.
  • Centralise la gestion des clefs cryptographiques. Le certificat émis pour le serveur, ou le nom IP correspondant à la VIP, est installé une seule fois dans le module SSL. Ainsi, les certificats ne traînent pas sur plusieurs serveurs réels. Pour les plus paranoïaques, la clef secrète peut être générée par le module SSL sans être exportable. Elle sera par contre définitivement perdue en cas de défaillance matérielle du module.

Performance

Le CSM permet d’établir jusqu’à 165’000 nouvelles connexions TCP par seconde et peut traiter jusqu’à 1’000’000 connexions simultanées. Le débit global du CSM peut aller jusqu’à 4 Gigabits par seconde.
La capacité de traitement SSL d’un seul module SSLM peut atteindre jusqu’à 3000 nouvelles connexions par seconde, jusqu’à 60’000 connexions simultanées et un débit de 300 Mbits par seconde.

Intégration dans notre infrastructure réseau

Parmi les différentes possibilités de déploiement et de configuration des modules CSM et SSLM, la difficulté a consisté à faire le choix optimum en termes de modes de fonctionnement des modules, plan d’adressage IP et cheminement des flux du trafic. Il s’agissait de choisir la configuration qui s’adapte le mieux à notre architecture réseau redondante et qui soit la plus transparente possible pour les administrateurs des serveurs réels :

  • Parmi les différentes topologies réseau envisageables pour implémenter le module CSM : Bridged, Routed et one-armed, c’est ce dernier mode qui a été retenu pour des raisons d’efficacité. Dans ce mode le CSM n’est pas configuré en ligne, un seul VLAN est utilisé pour communiquer avec lui. Seul le trafic qui exige d’être loadbalancé passe par le CSM, l’autre trafic le contourne.
  • Cette configuration n’implique aucun changement des paramètres réseau des serveurs réels, leur configuration IP reste conforme au standard EPNET.
  • Tous les serveurs réels sont placés dans un même sous-réseau réservé à cet effet, ceci pour simplifier les règles de gestion des flux de trafic et de cloisonnement.

Lorsqu’un service implémente d’office un mécanisme de redondance, notre configuration va l’utiliser pour parer à une éventuelle défaillance du SLB. Par exemple, dans la liste des serveurs DNS de notre campus, le premier est un service du SLB et devrait donc être toujours disponible. Le second, par contre, est indépendant de l’infrastructure de distribution de charge.

Nom du service Description du service Ports de service
CALENDARS Agendas partagés HTTP, HTTPS
DNS Résolution noms et adresses IP DNS, DNS ZONEXFER
DOCUMENTS Stockage et partage de fichiers HTTP, HTTPS
EWA Service de messagerie Exchange HTTP, HTTPS, IMAP, IMAPS, POP3, POP3S
GRANTS Portail pour chercheurs de l’EPFL HTTP
LDAP Annuaire LDAP LDAP, LDAPS
MAIL Service de messagerie (messages sortants) SMTP, SMTPS
MAILBOX Boîtes e-mail centralisées HTTP, IMAP, IMAPS, POP3, POP3S
MOODLE Plate-forme pédagogique en ligne HTTP
MY.EPFL Portail personnalisé HTTP, HTTPS
RADIUS Service RADIUS (authentification, autorisation et accounting) RADIUS-AUTH, RADIUS-ACCT
SCOLDAP Annuaire LDAP collaboratif LDAP, LDAPS
SEARCH Moteur de recherche HTTP
TEQUILA Service d’identification et d’authentification HTTP, HTTPS

Ils utilisent aujourd’hui le SLB

Conclusion


L’offre d’un service SLB illustre parfaitement la quête permanente de notre équipe pour un réseau plus performant, maîtrisable et hautement disponible.
La prise en charge de fonctionnalités plus évoluées par le réseau offre aux concepteurs et fournisseurs de nouveaux services un socle de ressources sophistiquées leur permettant de se concentrer sur leur domaine d’expertise.
Il faut garder à l’esprit que la distribution de charge facilite la multiplication des objets, réels ou virtuels, intervenant dans la fourniture d’un service. Le challenge pour le développeur est de bien gérer cette croissance.



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.