Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

retour

Répartition de charge de niveau TCP

Répartition de charge de niveau TCP

Quelques rappels

On l’a vu, presque tous les échanges sur une plateforme web s’appuient sur des protocoles construits sur IP et le plus souvent sur TCP/IP.

TCP est un protocole de niveau 4, de niveau transport. Il implique l’établissement d’une connexion entre deux serveurs, puis l’échange bidirectionnel de messages sur cette connexion, puis la fermeture de la connexion. Chacun des message est ensuite décomposé en paquets IP, et chaque paquet est routé indépendamment. TCP se charge de réémettre les paquets perdus, le cas échéant, et de les remettre dans l’ordre à l’arrivée si besoin.

Le protocole HTTP est construit au dessus de TCP. C’est à dire que les requêtes et réponses HTTP sont échangées sur une connexion TCP. Le navigateur ouvre une connexion TCP, envoie une requête, par exemple une requête GET portant sur une URL donnée, puis attend la réponse sur la même connexion. Avec HTTP 1.0, la connexion TCP est fermée une fois la réponse reçue. Avec HTTP 1.1, la connexion peut être maintenue ouverte pour une autre requête.

Le protocole HTTP est, à la base, un protocole sans état, c’est à dire qu’il n’y a pas d’information conservée relativement aux échanges précédents, chaque couple requête/réponse est indépendant des précédents. Cela du moins du point de vue du protocole, car le besoin de gérer des sessions conduit parfois à construire une notion d’état au dessus du protocole, au niveau applicatif.

Répartition de charge TCP

La répartition de charge TCP, ou encore « de niveau 4 », permet de faire apparaître N serveurs comme une seule adresse IP vue de l’extérieur. La répartition de charge est associée à une translation d’adresse (NAT), qui permet de totalement décorréler les adresses IP internes de celles qui sont vues de l’extérieur. Sur le réseau interne, chaque serveur dispose de sa propre adresse IP.

La répartition de charge de niveau TCP intervient dans la phase d’établissement de la connexion. Une demande de connexion est adressée par un serveur ; elle parvient à l’équipement de répartition de charge, qui détermine le serveur auquel il va affecter la connexion, parmi les serveurs disponibles. Une fois la connexion TCP établie, l’équipement de répartition de charge devient pratiquement transparent : il pousse les paquets IP de la connexion vers le serveur sélectionné, dans un sens et dans l’autre. Ceci jusqu’à fermeture de la connexion.

Les algorithmes de répartition

Il existe une variété d’algorithmes pour gérer la répartition de charge, c’est à dire choisir le serveur lorsqu’une nouvelle connexion est à affecter.

  • Round-robin . L’expression signifie une ronde, une permutation circulaire. Il s’agit d’une affectation cyclique : A puis B puis C puis A puis B puis C, ...
  • Weighed round-robin . Une affectation cyclique avec pondération. La pondération permet de prendre en compte la capacité différente des serveurs. Si un serveur a une capacité 1,5 par rapport aux autres, il est sélectionné 1,5 fois plus souvent. Les plateformes ne sont pas toujours mises en place d’un seul coup, et il est donc courant que des serveurs de puissance différentes soient utilisés.
  • Least-connection . Affectation au serveur qui a le moins de connexions ouvertes, c’est à dire donc en équilibrant le nombre de connexions entre les serveurs.
  • Weighed-least-connection . Même principe, mais avec pondération selon la capacité du serveur.
  • Priority activation . Une logique selon laquelle certains serveurs ne sont utilisés que si les serveurs principaux dépassent une charge définie comme seuil.
  • Algorithmes basés sur l’IP source . Un algorithme de hashage est appliqué à l‘IP source pour déterminer le serveur cible. Une même IP est toujours connecté au même serveur. On pourrait penser que cela procure une répartition de charge avec affinité de serveurs, mais il existe des cas où un internaute peut changer d’adresse IP.
  • Aléatoire . Une répartition purement aléatoire, qui peut donner un équilibrage satisfaisant, sur des volumes importants.

Notons que le round-robin, comme le weighed-round-robin, a le mérite de la simplicité, mais peut en théorie répartir médiocrement la charge car la durée de vie des connexions TCP peut être très variable, entre quelques centièmes de secondes et plusieurs heures. Si le hasard fait que l’un des serveurs reçoit plusieurs connexions de longue durée, il se retrouve avec un bien plus grand nombre de connexions ouvertes. Mais ce n’est pas tout, sur une connexion ouverte, il peut y avoir plus ou moins de trafic, de messages échangés, de sorte que même l’équilibrage des connexions peut être imparfait. Et enfin, les requêtes peuvent solliciter plus ou moins les ressources du serveur.

Néanmoins, sur un serveur web, ces subtilités théoriques sont le plus souvent balayées par la loi des grands nombres et la relative homogénéité du trafic, de sorte que les algorithmes les plus simples conviennent.

Si l’on cherchait à amener chaque serveur au plus près de sa capacité, alors le parfait équilibre pourrait être important. Mais ce n’est pas le cas. Il faut garder à l’esprit que, sur une plateforme bien dimensionnée, les serveurs ne dépassent pratiquement jamais 30% de leur capacité, avec de très brèves crêtes à 70-80%, lors de phénomènes transitoires planifiés (redémarrage, vidage de cache, opération d’exploitation), ou non planifiés. On ne cherche jamais à utiliser les serveurs au maximum en les chargeant au delà de 50-70% car alors la moindre crête transitoire se traduirait par une saturation et donc indisponibilité.

C’est pourquoi, si un phénomène transitoire dans la répartition amène un serveur à 25% et l’autre à 35% pendant quelques secondes ou minutes, cela ne pose aucun problème.