Qu’est-ce que l’équilibrage global de la charge des serveurs ?

L’équilibrage global de la charge des serveurs dirige les clients vers des points de terminaison situés dans différentes régions géographiques. Les décisions peuvent tenir compte de l’état de fonctionnement des points de terminaison, de la latence, de la capacité, des politiques ou de la localisation des utilisateurs.

Fonctionnement de l’équilibrage global de la charge des serveurs

L’équilibrage global de la charge des serveurs (GSLB) est un terme employé par les fournisseurs plutôt qu’un protocole. La RFC 3568 décrit la même tâche comme du routage de requêtes et classe les mécanismes connus en techniques DNS, de couche transport et de couche application. La forme DNS est courante, car tous les clients effectuent déjà la résolution des noms : un serveur de noms faisant autorité répond pour un même nom avec différentes adresses selon des politiques, des mesures ou les deux. L’adresse renvoyée est souvent une IP virtuelle placée devant un groupe régional qui effectue son propre équilibrage de charge local. Les autres formes interviennent plus tard. L’anycast annonce une même adresse depuis plusieurs sites et laisse le routage réseau choisir le site. Un équilibreur de couche application redirige le client, par exemple avec une réponse HTTP 302, ou relaie la requête en choisissant une région pour chacune. Les équilibreurs DNS et de couche application peuvent prendre en compte la proximité réseau ou la latence, la charge et la capacité, les résultats des contrôles d’état et des règles telles que la géographie ou les pondérations. L’anycast seul suit uniquement le routage réseau : la RFC 3568 indique que les protocoles de routage ne sont généralement pas sensibles à la charge et que la charge des serveurs n’est pas prise en compte. Un site continue de recevoir du trafic tant que sa route est annoncée, ce qui explique pourquoi la RFC 4786 juge souhaitable de lier l’annonce à la disponibilité du service.

Points clés

  1. À quelle vitesse le GSLB fondé sur le DNS détourne-t-il le trafic d’une région défaillante ? Progressivement, pas en une seule fois. La détection vient d’abord et dépend de l’intervalle entre les contrôles ainsi que du nombre d’échecs consécutifs requis par l’équilibreur (Route 53 appelle cela le seuil d’échec). Une fois la réponse faisant autorité modifiée, les recherches qui ne sont pas servies depuis un cache obtiennent la nouvelle réponse, tandis qu’un résolveur ayant mis l’ancienne réponse en cache peut continuer à l’utiliser pendant le reste de son TTL. La nouvelle réponse désigne une région qui réussit ses contrôles, s’il en existe une ; si aucune ne les réussit, la règle de repli de l’équilibreur s’applique. Route 53, par exemple, renvoie l’enregistrement principal lorsque les deux enregistrements d’une paire de basculement sont défaillants. Un TTL est la durée pendant laquelle un résolveur peut utiliser une réponse en cache avant de devoir interroger à nouveau le serveur, et l’équilibreur ne peut pas rappeler une réponse qu’il a déjà fournie. Un TTL plus court réduit cette fenêtre et augmente le volume de requêtes sur les serveurs DNS. Une réponse peut néanmoins continuer d’être utilisée au-delà de son TTL : la RFC 3568 indique que de nombreuses implémentations DNS ne respectent pas le TTL, et la RFC 8767 autorise un résolveur à continuer de servir une réponse expirée lorsque sa tentative d’actualisation échoue. Le projet k8gb rapporte une indisponibilité approximativement égale au TTL DNS lorsqu’un service derrière son GSLB tombe en panne ; il s’agit de l’observation d’un projet, pas d’une limite maximale. Modifier la réponse DNS ne déplace pas non plus les connexions déjà ouvertes : AWS précise, pour son basculement régional fondé sur le DNS, que les connexions existantes prennent du temps à se terminer, selon le comportement du client et la réutilisation des connexions. Cloudflare cite un basculement plus lent comme une limite de son équilibrage de charge fondé uniquement sur le DNS par rapport à son mode avec proxy.
  2. De qui une décision fondée sur le DNS utilise-t-elle la localisation ? Du résolveur récursif, sauf si celui-ci envoie l’option EDNS Client Subnet. Amazon Route 53 documente les deux cas : il utilise l’adresse IP source du résolveur lorsque celui-ci ne prend pas en charge l’option, et une forme tronquée de l’adresse de l’utilisateur dans le cas contraire. La RFC 7871, qui décrit cette option, recommande de la désactiver par défaut pour des raisons de confidentialité. Un équilibreur agissant comme proxy localise quant à lui le client à partir de la connexion de ce dernier.
  3. Que prouve la réussite d’un contrôle d’état ? Uniquement ce que le contrôle vérifie. Dans Route 53, un contrôle d’état TCP réussit dès qu’une connexion est établie, un contrôle HTTP ou HTTPS exige un code d’état 2xx ou 3xx, et un contrôle par recherche de chaîne exige en plus un texte donné dans le corps de la réponse ; les contrôles HTTPS ne valident pas le certificat. Une région dont le frontal accepte les connexions alors que l’application derrière lui est défaillante réussit un contrôle TCP. Faire porter le contrôle sur une URL qui sollicite les dépendances dont vos utilisateurs ont besoin est un choix de conception qui vous revient, pas quelque chose que l’équilibreur déduit.
  4. Anycast ou orientation par DNS ? Avec l’anycast, le système de routage choisit le site : le choix ne dépend donc pas des réponses DNS en cache, mais l’opérateur dispose d’un contrôle limité. La RFC 4786 décrit la répartition de charge entre les nœuds anycast comme généralement déséquilibrée et indique que la décision de routage doit rester stable plus longtemps qu’une transaction, car une interaction client-serveur doit habituellement rester sur le même nœud du début à la fin. C’est important pour les flux de longue durée, comme les téléchargements volumineux et la diffusion de médias en streaming. Le GSLB fondé sur le DNS peut renvoyer différentes adresses selon des politiques et hérite des limites de mise en cache décrites ci-dessus. Les deux sont également combinés, par exemple en attribuant une adresse anycast aux serveurs DNS chargés du routage des requêtes eux-mêmes.

Quand l’équilibrage global de la charge des serveurs est utile

Le GSLB devient utile lorsqu’un service fonctionne dans plusieurs régions et nécessite une règle pour déterminer la région utilisée par chaque client et le comportement en cas de défaillance d’une région. Le mécanisme que vous choisissez détermine la rapidité du déplacement du trafic et la précision de la localisation des clients : les réponses DNS sont mises en cache, et les politiques DNS fondées sur la localisation voient l’adresse du résolveur, sauf si celui-ci transmet une partie de l’adresse du client. Un équilibreur agissant comme proxy décide quant à lui pour chaque requête, mais toutes les requêtes passent par lui.

Références

Transformer vos connaissances sur les médias en une chaîne de traitement opérationnelle

Reliez les téléversements, le traitement, l’IA, le stockage et la diffusion via une seule API déclarative — la pile d’encodage, la montée en charge et l’évolution constante des formats sont prises en charge pour vous.

Essayer Transloadit gratuitement