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.

eZHumanCAPTCHACode reload
retour

Répartition de charge de niveau 7

Répartition de charge de niveau 7

Répartition avec affinité de serveur

Les échanges sur une même connexion TCP, une fois établie, sont bien sûr avec le même serveur. Mais le protocole HTTP utilise de nombreuses connexions TCP pour la session d’un même internaute. De sorte que, avec la répartition TCP décrite plus haut, les requêtes d’un même internaute sont réparties entre les différents serveurs.

Certaines applications sont construites de telle manière qu’elles exigent que les requêtes d’un même utilisateur soient adressées à un même serveur. Généralement parce que les applications conservent en mémoire des informations relatives à la session, par exemple le contenu du panier dans un site de e-commerce. Pour construire des plateformes à très haute capacité d’accueil, c’est une pratique qui est à éviter, mais il arrive souvent que la conception des applications ne prenne pas en compte les exigences d’architecture.

On appelle « répartition avec affinité de serveur », une répartition de charge qui dirige toutes les requêtes d’une même session d’un internaute, à un même serveur. On parle parfois de « sticky sessions », des sessions « collantes ».

La solution la plus utilisée pour parvenir à une répartition de ce type consiste à utiliser un identifiant de session placé dans un cookie. Soit l’application a placé un cookie identifiant la session applicative et l’équipement de répartition lit ce cookie, puis affecte toutes les requêtes portant ce cookie au même serveur. Soit l’équipement insère lui-même son cookie pour reconnaître les requêtes de la même session.

Principe de la répartition niveau 7

« Niveau 7 » signifie niveau « application » en référence au modèle OSI. En fait, dans la pile TCP/IP on distingue moins de niveaux que dans le modèle OSI, et donc on passe directement du niveau 4, transport, au niveau 7, application. HTTP, comme SMTP, POP, SSH, Telnet et bien d’autres sont donc des protocoles de niveau 7.

La répartition de niveau 7 est une répartition dont les mécanismes impliquent l’analyse des requêtes HTTP. On a vu plus haut que le niveau 4 n’intervenait pratiquement qu’à l’établissement de la connexion TCP. Une fois la connexion établie, il suffit de transférer les paquets.

Dans un mécanisme de répartition de niveau 7, on analyse le contenu de chaque requête, pour décider du routage. En pratique, deux choses sont recherchées et analysées :

  • Les cookies, qui figurent dans l’entête HTTP.
  • L’URI, c’est à dire l’URL et l’ensemble de ses paramètres.

L’analyse de l’URI permet de mettre en place une répartition avec spécialisation des serveurs ; nous y reviendrons. Elle permet aussi d’assurer l’affinité de serveur, dans le cas où un jeton de session est inséré dans l’URI.

Notons que la différence entre niveau 4 et niveau 7 n’est pas négligeable. Pour intervenir au niveau 7, on doit scruter tout le contenu des échanges, et analyser chaque message pour identifier les requêtes HTTP, puis analyser encore la requête pour trouver le cookie. C’est un travail bien plus important que d’aiguiller des paquets. Et ce n’est pas tout, s’il ne peut pas aiguiller la requête avant de savoir ce que contient le cookie, il induit forcément un délai supplémentaire.

 

Spécialisation des serveurs

L’affinité de serveur n’est pas la seule raison de gérer la répartition de charge au niveau 7. Une utilisation courante consiste à répartir la charge au moyen d’une analyse de l’URL, de manière à ce que les requêtes portant sur les mêmes ressources soient adressées aux mêmes serveurs. Cette affectation peut être définie soit de manière explicite, par des expressions régulières portant sur l’URL, soit de manière automatisée, en utilisant un hashage sur l’URL. Dans le premier cas, l’administrateur maîtrise la répartition, dans le second, la répartition est indifférente, mais elle est stable, un même serveur reçoit toujours les mêmes URLs.

A quoi sert ce type de répartition ? Dans le cas d’une répartition explicite, on peut définir une spécialisation des serveurs, correspondant à des configurations spécifiques. Par exemple les serveurs délivrant les images ou autres petits fichiers statiques pourront avoir une configuration parfaitement dédiée à cet usage. Mais la spécialisation des serveurs a aussi des inconvénients, et complique en particulier la question de la tolérance aux pannes.

Dans une répartition automatique par hashage, chaque serveur doit pouvoir répondre à toute forme de requête, mais les requêtes semblables tendent malgré tout à être adressées aux mêmes serveurs. On a donc une bonne flexibilité et une gestion satisfaisante de la tolérance aux pannes. A quoi bon cette affinité ? Principalement pour permettre aux caches des serveurs de se spécialiser. Si l’on dispose de 5 serveurs ayant chacun un cache d’une capacité de 2 GO, mais un volume total de contenus de 10 GO pour 80% des pages, alors on aura un hit-ratio trop faible sur chacun des serveurs. Si on parvient à séparer le trafic en 5 sous-ensembles de 2 GO chacun, on obtiendra au contraire un excellent hit-ratio sur chacun d’entre eux. C’est un peu comme si l’on avait mis en commun les 5 fois 2 GO au lieu de les laisser se disperser.

Répartition de charge et SSL

Lorsque la session est sécurisé, en HTTP-S ou SSL, alors le contenu des échanges HTTP est totalement crypté. Il est impossible de gérer une répartition de charge de niveau 7 sur une session cryptée, alors que l’on peut gérer une répartition au niveau 4.

Il est donc nécessaire de commencer par terminer la session SSL, en amont du load-balancer. Quitte le cas échéant à établir une nouvelle session sécurisée en aval, mais en général on considère que au sein du datacenter le besoin de sécurisation est moindre.

Dans ce cas, on combine généralement les deux fonctions, terminaison SSL et load-balancing, sur le même équipement frontal. En outre, cela décharge un peu de la CPU du serveur.