Équilibrage de charge

La nécessité d’un équilibrage de charge en informatique résulte de deux exigences de base : En premier lieu, la haute disponibilité peut être améliorée par la réplication. En deuxième lieu, les performances peuvent être améliorées via un traitement parallèle. La haute disponibilité est la propriété d’un service disponible pendant près de 100 % du temps quand un client essaie d’y accéder. La qualité de service (QoS) d’un service particulier inclut généralement plusieurs considérations telles que les exigences de débit et de latence.

Qu’est-ce que l’équilibrage de charge ?

La forme la plus connue d’équilibrage de charge est le « DNS tourniquet (round robin) », que de nombreux grands services web utilisent pour équilibrer la charge des requêtes entre plusieurs serveurs. Plus précisément, plusieurs serveurs front-end, chacun avec une adresse IP unique, partagent un nom DNS. Pour équilibrer le nombre de requêtes sur chacun de ces serveurs web, les grandes entreprises comme Google conservent et organisent un pool d’adresses IP associées à une seule entrée DNS. Quand un client effectue une requête (par exemple auprès du domaine www.google.com), le DNS de Google sélectionne l’une des adresses disponibles dans le pool et l’envoie au client. La stratégie la plus simple pour distribuer des adresses IP consiste à utiliser une file d’attente tourniquet (round robin) où, après chaque réponse DNS, la liste d’adresses est permutée.

Avant l’arrivée du cloud, l’équilibrage de charge DNS était un moyen simple de réduire la latence des connexions longue distance. Le répartiteur du serveur DNS était programmé pour répondre avec l’adresse IP du serveur géographiquement le plus proche du client. Le moyen le plus simple d’y parvenir consistait à répondre avec l’adresse IP du pool qui était numériquement le plus proche de l’adresse IP du client. Bien entendu, cette méthode n’était pas fiable, car les adresses IP ne sont pas distribuées selon une hiérarchie globale. Les techniques actuelles sont plus sophistiquées et s’appuient sur un mappage logiciel d’adresses IP à des endroits basés sur des cartes physiques de fournisseurs de services Internet. Dans la mesure où ce mappage est implémenté sous forme de recherche logicielle coûteuse, cette méthode donne de meilleurs résultats, mais son calcul représente une dépense importante. Toutefois, le coût d’une recherche lente est amorti, car la recherche DNS se produit uniquement quand la première connexion à un serveur est effectuée par le client. Toutes les communications suivantes ont lieu directement entre le client et le serveur propriétaire l’adresse IP distribuée. La figure suivante illustre un exemple de schéma d’équilibrage de charge DNS.

Figure 4 : Équilibrage de charge dans un environnement d’hébergement cloud

Cette méthode présente un inconvénient : en cas de défaillance du serveur, le basculement vers une autre adresse IP dépend de la configuration du TTL (durée de vie) du cache DNS. En règle générale, les entrées DNS durent longtemps, et les mises à jour prennent plus d’une semaine pour se propager sur Internet. Cela signifie qu’il est difficile de « masquer » rapidement la défaillance d’un serveur au client. Pour améliorer cette situation, il est nécessaire de réduire la validité (TTL) d’une adresse IP dans le cache, mais cela se fait au détriment des performances tout en augmentant le nombre de recherches.

L’équilibrage de charge moderne fait souvent référence à l’utilisation d’une instance dédiée (ou d’une paire d’instances) qui dirige le trafic entrant vers les serveurs back-end. Pour chaque requête entrante sur un port spécifique, l’équilibreur de charge redirige le trafic vers l’un des serveurs back-end en fonction d’une stratégie de répartition. Ainsi, l’équilibreur de charge gère les métadonnées de requête, notamment les informations telles que les en-têtes de protocole d’application (par exemple les en-têtes HTTP). Dans ce cas, les informations périmées ne sont pas un problème, car chaque requête passe par l’équilibreur de charge.

Bien que tous les types d’équilibreurs de charge réseau transfèrent simplement les informations de l’utilisateur avec n’importe quel contexte aux serveurs back-end, lorsqu’il s’agit de répondre au client, ils peuvent utiliser l’une des deux stratégies de base :¹

• Proxysation : Dans cette approche, l’équilibreur de charge reçoit la réponse du back-end et la relaie au client. L’équilibreur de charge se comporte comme un proxy web standard et est impliqué dans les deux moitiés d’une transaction réseau, à savoir transférer la requête au client et retourner la réponse.
• Transfert TCP : dans cette approche, la connexion TCP avec le client est transférée au serveur back-end. Ainsi, le serveur envoie la réponse directement au client, sans passer par l’équilibreur de charge.

Figure 5 : Mécanisme de transfert TCP entre le répartiteur et le serveur back-end

Impact sur la disponibilité et le niveau de performance

L’équilibrage de charge est une stratégie importante qui permet de masquer les défaillances d’un système. Tant que le client du système est exposé à un seul point de terminaison qui équilibre la charge sur plusieurs ressources, les défaillances des ressources individuelles peuvent être masquées au client en traitant simplement la requête sur une autre ressource. Toutefois, il est important de noter que l’équilibreur de charge est désormais un point de défaillance unique pour le service. En cas d’échec pour une raison quelconque, même si tous les serveurs back-end continuent de fonctionner, aucune requête cliente n’est traitée. Ainsi, pour obtenir une haute disponibilité, les équilibreurs de charge sont souvent implémentés par paires.

L’équilibrage de charge permet à un service de répartir les charges de travail entre plusieurs ressources de calcul dans le cloud. Avoir une seule instance de calcul dans le cloud présente plusieurs limitations. Nous avons déjà abordé la question de la limitation physique du niveau de performance, où davantage de ressources sont nécessaires pour répondre à l’augmentation des charges de travail. L’équilibrage de charge permet de répartir des volumes plus importants de charges de travail entre plusieurs ressources pour que chaque ressource puisse répondre à ses requêtes indépendamment et en parallèle, ce qui améliore ainsi le débit de l’application. Cela permet également d’améliorer les temps de réponse moyens, car il n’existe plus de serveurs pour traiter la charge de travail.

Les services de vérification et de supervision sont essentiels pour permettre la réussite des stratégies d’équilibrage de charge. Un équilibreur de charge doit garantir le traitement de chaque requête en vérifiant que chaque nœud de ressource est disponible. Sinon, le trafic n’est pas dirigé vers ce nœud spécifique. La supervision par test ping-echo est l’une des tactiques les plus populaires pour vérifier l’intégrité d’un nœud de ressource spécifique. En plus de l’intégrité d’un nœud, certaines stratégies d’équilibrage de charge nécessitent des informations supplémentaires telles que le débit, la latence et l’utilisation du processeur afin d’évaluer la ressource la plus appropriée pour diriger le trafic.

Les équilibreurs de charge doivent souvent garantir une haute disponibilité. La façon la plus simple de procéder consiste à créer plusieurs instances d’équilibrage de charge (chacune avec une seule adresse IP), et à lier chaque instance à une seule adresse DNS. En cas de défaillance d’une instance d’équilibreur de charge, celle-ci est remplacée par une nouvelle instance. De plus, l’ensemble du trafic est passé à l’instance de basculement avec un impact minime sur le niveau de performance. Simultanément, une nouvelle instance d’équilibreur de charge peut être configurée pour remplacer l’instance défaillante. Les enregistrements DNS doivent être immédiatement mis à jour.

Stratégies d’équilibrage de charge

Il existe plusieurs stratégies d’équilibrage de charge dans le cloud.

Répartition équitable

Il s’agit d’une approche statique de l’équilibrage de charge dans laquelle un simple algorithme tourniquet (round robin) permet de répartir le trafic entre tous les nœuds de manière uniforme. Cet algorithme ne prend pas en compte l’utilisation d’un nœud de ressource individuel dans le système ou le temps d’exécution d’une requête. Cette approche, qui est l’une des plus simples à implémenter, tente de maintenir occupé chaque nœud du système. Il existe un inconvénient important avec cette approche : les requêtes clientes lourdes peuvent s’agréger et atteindre les mêmes centres de données, ce qui entraîne une surcharge de quelques nœuds tandis que d’autres restent sous-utilisés. Toutefois, cela nécessite un modèle de charge très spécifique. De plus, la probabilité est très faible pour que cette situation se produise en pratique sur un grand nombre de clients et de serveurs avec une répartition et une capacité de connexion relativement uniformes. Néanmoins, cette stratégie complique l’implémentation de stratégies de mise en cache dans le centre de données, qui prennent en compte des considérations telles que la localisation spatiale (où vous effectuez une préextraction et une mise en cache des données à proximité des données extraites), car la prochaine requête du même client peut aboutir sur un autre serveur.

AWS utilise cette approche dans son offre ELB (Elastic Load Balancer). ELB d’AWS provisionne des équilibreurs de charge qui équilibrent le trafic entre les instances d’EC2 attachées. Les équilibreurs de charge sont essentiellement des instances d’EC2 avec un service spécifiquement destiné à router le trafic. À mesure que les ressources situées derrière l’équilibreur de charge font l’objet d’un scale-out, les adresses IP des nouvelles ressources sont mises à jour sur l’enregistrement DNS de l’équilibreur de charge. Ce processus prend plusieurs minutes, car il nécessite du temps pour la supervision et le provisionnement. Cette période de mise à l’échelle (temps d’attente avant que l’équilibreur de charge ne soit prêt à gérer une charge plus élevée) est appelée « préchauffage » de l’équilibreur de charge.

Les équilibreurs de charge ELB d’AWS supervisent également chaque ressource attachée pour la répartition de la charge de travail afin de maintenir un contrôle d’intégrité. Un mécanisme de test ping-echo permet de garantir l’intégrité de toutes les ressources. Les utilisateurs ELB peuvent configurer les paramètres de la vérification d’intégrité en spécifiant les retards et le nombre de nouvelles tentatives.

Répartition basée sur un code de hachage

Cette approche tente de garantir qu’à tout moment, les requêtes effectuées par un client via la même connexion aboutissent toujours sur le même serveur. De plus, pour permettre l’équilibrage de la répartition du trafic des requêtes, l’opération s’effectue dans un ordre aléatoire. Cette approche présente plusieurs avantages par rapport à l’approche de type tourniquet (round robin), car elle est utile pour les applications prenant en charge les sessions, où les stratégies de mise en cache et de persistance d’état peuvent être beaucoup plus simples. Elle est également moins vulnérable aux modèles de trafic qui entraînent un encombrement sur un seul serveur, car la répartition est aléatoire, mais le risque existe toujours. Toutefois, dans la mesure où chaque requête doit être évaluée au niveau des métadonnées de connexion pour permettre un routage vers le serveur approprié, elle introduit une petite quantité de latence à chacune de ces requêtes.

Azure Load Balancer utilise ce type de mécanisme de répartition basé sur un code de hachage pour répartir la charge. Ce mécanisme crée un code de hachage pour chaque requête en fonction de l’adresse IP source, du port source, de l’adresse IP de destination, du port de destination et du type de protocole, afin de garantir que chaque paquet provenant de la même connexion aboutisse toujours sur le même serveur. La fonction de hachage est choisie de telle sorte que la répartition des connexions aux serveurs soit relativement aléatoire.

Azure fournit des contrôles d’intégrité via trois types de sonde : Les sondes d’agent invité (sur les machines virtuelles PaaS), les sondes personnalisées HTTP et les sondes personnalisées TCP. Les trois sondes fournissent un contrôle d’intégrité des nœuds de ressource via un mécanisme de test ping-echo.

Autres stratégies populaires

Il existe d’autres stratégies pour équilibrer la charge entre plusieurs ressources. Chacune d’elles utilise des métriques distinctes afin d’évaluer le nœud de ressource le plus approprié pour une requête particulière :

• Stratégies basées sur le temps d’exécution de la requête : Ces stratégies utilisent un algorithme de planification prioritaire, où les temps d’exécution des requêtes permettent d’évaluer l’ordre de répartition de la charge le plus approprié. Dans cette approche, le principal défi consiste à prédire avec précision le temps d’exécution d’une requête particulière.
• Stratégies basées sur l’utilisation des ressources : Ces stratégies se basent sur l’utilisation du processeur sur chaque nœud de ressource pour équilibrer l’utilisation de chaque nœud. Les équilibreurs de charge gèrent une liste triée de ressources en fonction de leur utilisation, puis dirigent les requêtes vers le nœud le moins chargé.

Autres avantages

Le fait d’avoir un équilibreur de charge centralisé se prête à plusieurs stratégies qui permettent d’augmenter les performances du service. Toutefois, il est important de noter que ces stratégies fonctionnent uniquement tant que l’équilibreur de charge n’est pas soumis à une charge insurmontable. Sinon, l’équilibreur de charge lui-même devient le goulot d’étranglement. Certaines de ces stratégies sont listées ci-dessous :

• Déplacement SSL : Les transactions réseau via SSL sont associées à un coût supplémentaire, car elles doivent faire l’objet d’un chiffrement et d’une authentification. À la place du traitement de toutes les requêtes par SSL, la connexion cliente à l’équilibreur de charge peut être effectuée via SSL, tandis que les requêtes de redirection vers chaque serveur individuel peuvent être effectuées via HTTP. Cela réduit considérablement la charge sur les serveurs. De plus, la sécurité est maintenue tant que les requêtes de redirection ne sont pas effectuées sur un réseau ouvert.
• Mise en mémoire tampon TCP : Stratégie visant à déplacer les clients ayant des connexions lentes vers l’équilibreur de charge pour soulager les serveurs qui retournent des réponses à ces clients.
• Mise en cache : Dans certains scénarios, l’équilibreur de charge peut conserver un cache pour les requêtes les plus courantes (ou les requêtes qui peuvent être gérées sans accéder aux serveurs, par exemple du contenu statique) afin de réduire la charge sur les serveurs.
• Mise en forme du trafic : Pour certaines applications, vous pouvez utiliser un équilibreur de charge afin de retarder/classer par ordre de priorité le flux de paquets. Ainsi, le trafic peut être modelé en fonction de la configuration du serveur. Cela affecte la qualité de service (QoS) de certaines requêtes, mais garantit que la charge entrante peut être traitée.
  

Références

1. Aron, Mohit et Sanders, Darren et Druschel, Peter et Zwaenepoel, Willy (2000). Scalable content-aware request distribution in cluster-based network servers, Actes de la 2000 Annual USENIX Technical Conference