Répartition de charge DNS : méthodes, avantages, limites

La répartition de charge DNS distribue les requêtes en renvoyant une ou plusieurs adresses pour un nom d'hôte, en sélectionnant parfois des réponses différentes selon l'emplacement, l'état de santé ou une politique. Elle peut répartir le trafic entre régions, orienter les utilisateurs vers une infrastructure proche et offrir une couche simple de basculement. Le comportement exact dépend du fournisseur DNS et des caches des résolveurs. Les réponses DNS standard ne sont pas réévaluées à chaque requête HTTP : une décision prise lorsqu'un résolveur rafraîchit son cache peut donc rester en vigueur jusqu'à l'expiration du TTL. Le DNS convient ainsi à un pilotage grossier du trafic, mais diffère d'un répartiteur de charge qui évalue chaque nouvelle connexion en temps réel.

Stratégies courantes de distribution DNS

Le round-robin peut faire tourner l'ordre des adresses au sein d'un pool. Le DNS géographique ou basé sur la latence peut renvoyer des points de terminaison régionaux selon l'emplacement apparent d'un résolveur récursif. Le routage pondéré peut favoriser un point de terminaison par rapport à un autre, ce qui est utile pour un déploiement contrôlé ou une répartition de capacité. Les configurations de basculement peuvent cesser de renvoyer un point de terminaison après qu'un contrôle de santé a détecté un problème. Chaque fonctionnalité a ses spécificités propres au fournisseur : intervalles de contrôle de santé, seuils d'échec, déduction de l'emplacement du résolveur et comportement du TTL influencent tous ce que voient les utilisateurs finaux. Lisez le guide d'implémentation du fournisseur et testez depuis des réseaux représentatifs avant de vous appuyer sur ce comportement.

L'emplacement du résolveur est une subtilité importante. Un service DNS sensible à la géographie voit souvent l'adresse du résolveur récursif, et non celle de l'appareil de l'utilisateur. EDNS Client Subnet peut fournir un contexte de localisation supplémentaire dans certains systèmes, mais il n'est pas envoyé partout et soulève des questions de confidentialité. En conséquence, un résolveur public peut représenter de nombreux utilisateurs et recevoir une réponse régionale unique en leur nom. Observer des réponses DNS différentes depuis des emplacements distincts est attendu dans certains déploiements, mais cela ne prouve pas qu'un visiteur donné a été dirigé vers le serveur physique le plus proche.

Les décisions DNS sont mises en cache

Un TTL DNS fixe la durée pendant laquelle un résolveur peut mettre une réponse en cache avant de la rafraîchir. Des TTL plus bas peuvent rendre les changements planifiés visibles plus tôt une fois les caches expirés, mais ils augmentent le volume de requêtes et ne garantissent pas une propagation instantanée. Un résolveur peut utiliser une réponse déjà en cache jusqu'à la fin de sa durée de vie restante, et les applications peuvent avoir leur propre cache ou des connexions persistantes. Si un point de terminaison tombe, le basculement par DNS peut donc être plus lent que le retrait de ce point de terminaison au sein d'un répartiteur de charge conscient des connexions. Tenez compte à la fois du temps de reprise critique et des couches de cache attendues avant de choisir le DNS comme unique mécanisme de basculement.

• Définissez ce qui rend un point de terminaison sain et testez l'ensemble du chemin applicatif.
• Vérifiez comment le fournisseur évalue la géographie des résolveurs et l'état de santé.
• Fixez les TTL selon les besoins opérationnels, et non en partant du principe que plus bas est toujours mieux.
• Utilisez un répartiteur de charge applicatif ou réseau pour des décisions de connexion rapides et sensibles à l'état de santé.
• Surveillez les utilisateurs depuis plusieurs régions pour détecter les différences de routage.

Planifier et valider les changements de trafic

Avant un transfert de trafic, confirmez que chaque destination est prête à servir le même nom d'hôte, le même certificat et le même comportement applicatif. Procédez à un changement progressif lorsque le fournisseur prend en charge la pondération, examinez les journaux et les taux d'erreur, puis augmentez le trafic uniquement lorsque les résultats sont sains. Pour le retour arrière, sachez combien de temps les caches peuvent conserver la réponse précédente et gardez l'ancien environnement fonctionnel pendant cette période. Ne vous fiez pas à une seule recherche DNS pour confirmer la part des utilisateurs réels qui atteignent chaque serveur backend ; utilisez la télémétrie du service, les analyses du fournisseur ou des sondes contrôlées qui correspondent aux chemins réels des clients.

Le DNS est un plan de contrôle global efficace lorsque ses forces et sa latence sont bien comprises. Il complète les répartiteurs de charge et les contrôles de santé applicatifs sans les remplacer. Lisez le round-robin DNS expliqué pour le modèle de pool d'adresses le plus simple et le TTL DNS expliqué pour le comportement du cache. Une recherche DNS publique montre ce qu'un résolveur peut récupérer à un instant donné ; pour déterminer si le trafic atteint une infrastructure saine, les équipes d'exploitation devraient associer cet élément à une surveillance réelle des connexions et des applications.

Mesurer l'expérience utilisateur au niveau applicatif

Une politique DNS n'est réussie que si elle améliore le service que les utilisateurs reçoivent réellement. Suivez la latence, les taux d'erreur et la disponibilité au niveau du point de terminaison applicatif dans chaque région, et comparez ces métriques aux réponses DNS que renvoie le fournisseur. Le résolveur le plus proche n'est pas toujours l'utilisateur le plus proche, et le serveur le plus proche n'est pas toujours le moins chargé ni le plus sain. Incluez des contrôles synthétiques depuis des réseaux représentatifs, mais examinez aussi la télémétrie du trafic réel pour repérer les valeurs aberrantes. Si une politique de routage envoie les utilisateurs vers une région défaillante, ajustez le signal de santé ou le repli plutôt que de simplement modifier le TTL. Un déploiement bien instrumenté fournit aux opérateurs des éléments sur le comportement de la pondération et de la sélection régionale dans des conditions de cache réelles.