Le recours à une solution de réparation de charge (ou load balancing) permet de garantir la disponibilité d'un service Web dont l'accès est considéré critique par l'entreprise (comme dans le cas d'une activité de commerce en ligne par exemple)
L'une des fonctions partagées par l'ensemble des réparateurs de charge est d'ailleurs la redondance visant à assurer la continuité des transactions. Il existe deux façons d'aborder le domaine de la répartition de charge révélant deux stratégies d'action différentes mais complémentaires. Soit agir principalement au niveau de la couche
transport et de réseau comme TCP/IP, soit aller jusqu'au niveau applicatif correspondant à la couche 7 du modèle OSI, avec un relais ad-hoc intégrant des fonctions de load balancing.
Basculement en français.
Le Failover consiste à réaffecter automatiquement les tâches à un système de secours, de telle sorte que la procédure soit aussi transparente que possible pour l'utilisateur final. Ce basculement peut s'appliquer à n'importe quel aspect d'un système informatique. Ainsi, au sein d'un ordinateur personnel, il peut s'agir d'un mécanisme destiné à protéger la machine contre un processeur défaillant ; dans un réseau, le basculement peut s'appliquer à un composant ou à un système de composants, comme un chemin de connexions, un appareil de stockage ou un serveur Web. L'opération de retour vers le système de départ après sa restauration s'appelle le « Failback ».
Répartition de charge en Français.
Le load balancing permet une diminution de la charge des serveurs tout en améliorant les performances des applications. L'objectif est alors le même, maintenir une disponibilité des sessions d'applications et de réseaux ainsi qu'une très bonne fiabilité. Les requêtes sont alors envoyées au serveur capable de répondre à cette demande en un temps optimal.
Au sein d'un réseau, le chemin le moins engorgé est choisi afin de ne pas perdre des paquets et de maintenir une connexion optimale.
Son intégration s'effectue aux contrôleurs de diffusion d'applications contribuant à un renforcement de la sécurité et des performances.
Il existe cependant des cas bien particulier, où le load balancing n'est pas du tout recommandé, car il engendre des dysfonctionnements sur certains protocoles.
Lorsque le périphérique principal ne parvient pas à fournir une connexion, il passe en veille et permet au périphérique secondaire de prendre en charge le trafic réseau. Lorsque le lien principal est rétabli, le lien secondaire se met en veille et la connexion est rétablie sur le lien principal. En fonction des matériels utilisés, un temps de basculement peut être demandé et/ou réglé afin de s'assurer que le lien principal est stable.
Cette méthode crée une file d'attente pour les demandes entrantes. Ces dernières sont ensuite gérées par le répartiteur de charge, qui les distribue aux serveurs du cluster. Les requêtes sont assignées de manière séquentielle, selon la disponibilité des machines. Round Robin ne tient pas compte de l'urgence de la demande, ni de la charge qu'elle va représenter pour le serveur concerné. Il est donc adapté aux environnements où les serveurs disposent de ressources identiques. Mais dans une infrastructure où celles-ci diffèrent, il pourrait assigner des charges non adaptées à des machines moins puissantes… ce qui pourrait entraîner une surcharge.
Il s'agit de la méthode la plus classique. Elle sert de modèle aux autres algorithmes.
Contrairement au Round Robin « classique », cette méthode fonctionne en distribution pondérée. Une valeur est attribuée à l'avance à chaque serveur, selon ses capacités et sa puissance.
Par exemple, le plus puissant aura une valeur de 10 et le moins puissant une valeur de 1. Le load balancer attribuera alors davantage de charge à la machine la plus robuste. Cette méthode convient donc mieux à un environnement dont les ressources entre les serveurs diffèrent : la charge est optimisée en fonction de leurs capacités.
Les deux méthodes précédentes ne tiennent pas compte du nombre de connexions que les serveurs du cluster doivent gérer, lors de la distribution des tâches par le load balancer. Donc plusieurs connexions peuvent parfois s'accumuler sur un serveur et entraîner sa surcharge. Least Connections remédie à cela. Il tient compte en effet des demandes déjà existantes sur le serveur web durant la distribution. La machine avec le plus petit nombre de requêtes reçoit la prochaine sollicitation du load balancer. En revanche, cet algorithme ne tient pas compte des capacités techniques des serveurs. Il est par conséquent plus adapté aux environnements dont les ressources serveur sont identiques.
Cet algorithme complète celui de Least Connections. Au sein d'une infrastructure où les ressources des serveurs sont hétérogènes, il tient compte du volume de demandes pour chaque machine, ainsi que de leur pondération définie par l'administrateur. Comme pour Weighted Round Robin, le serveur le plus puissant a une pondération plus importante. Ceci permet de maintenir une répartition optimale des requêtes dans un cluster.
En effet, chaque nouvelle demande est assignée au serveur dont le rapport connexions actives-pondération est le plus faible.
Le Spill-over (débordement) est une méthode dans laquelle un seuil est défini pour une interface (en kbps) et si la quantité de bande passante du trafic dépasse le seuil, toute bande passante du trafic au-delà de ce seuil est envoyée via une autre interface.
Il peut être simple, de simplement prendre en compte le trafic sortant ou de sortie lors de la détermination d'un seuil, mais deux faits doivent être pris en considération :
Une simple requête sortant de l'interface peut recevoir une réponse avec beaucoup plus de données revenant de l'autre côté.
Les connexions Internet se présentent sous diverses configurations, dont beaucoup ont différents niveaux de capacité de bande passante autorisée entre les directions de téléversement (upload) et de téléchargement (download). Pour ces raisons, il est nécessaire de définir des seuils de sortie et d'entrée pour la bande passante.
La méthode Ratio vous permet de spécifier le pourcentage du trafic à affecter à n'importe quelle interface du groupe d'équilibrage de charge.
Lorsqu'une architecture réseau possède un réseau VOIP basé sur le protocole SIP, il est fortement déconseillé d'utiliser le Load Balancing, quel que soit le type choisi.
En effet, dans ce cas particulier, pour le routage du trafic sur des WAN, les paquets passent par des liens différents, avec des taux de latence différents. Ce qui engendre de fortes perturbations sur les communications. Des pertes de paquets qui occasionnent des trous dans la conversation : la conversation est hachurée et votre correspondant vous fait répéter plusieurs fois. Seul remède à ce problème, parler très lentement de façon à ce que tous les paquets empruntent le même chemin. Ce qui n'est pas viable dans le temps.
Donc, lors de la présence d'un réseau VOIP, oubliez le Load Balancing.
Lors de la connexion de sites en VPN (Site to Site), le Load Balancing ne peut pas être utilisé car le VPN est fait entre 2 adresses IP fixes (voir entre 1 ou 2 adresses en DYNDNS).
Pour que 2 sites puissent utiliser le load balancing, entre eux, il faut 2 WAN par site, soit 2 adresses distinctes par site de façon à créer 2 VPN. Ce qui a un coût non négligeable.
Les différents liens par site sont essentiellement là pour une continuité de service. En règle générale, on peut attribuer 2 IP par site pour 1 VPN (2 liens par VPN), c'est pour le Failover, et non pour le Load Balancing.
Le Failover est essentiel pour une entreprise quelle qu'elle soit, classique ou multi-sites, à condition d'avoir plusieurs liens WAN. Par contre le Load Balancing est à utiliser après analyse des solutions matérielles mises en place. Pour un Cluster, c'est essentiel, pour des liaisons WAN multiples sans VPN, c'est plus que conseillé, avec VPN ou VOIP c'est à proscrire.
Tout dépend de votre architecture réseau et de la disponibilité des sites. Une étude approfondie des sites doit être menée afin de définir les réelles améliorations que peut apporter le Load Balancing. Car toute mise en place de cette technologie, sans étude préalable, peut engendrer des coûts qui peuvent vite s'envoler.