Le round-robin DNS classique distribue le trafic à parts égales ; les déploiements modernes exigent un contrôle par pourcentage.
Le round-robin DNS classique distribue les adresses IP sous le même enregistrement à peu près à parts égales. Ce modèle peut être adéquat pour un simple partage de charge, mais il ne fournit pas le contrôle requis pour les déploiements de nouvelle version, les tests A/B, les bascules blue/green ou les migrations de centre de données. Les équipes d'exploitation veulent typiquement envoyer seulement 5 % du trafic vers une nouvelle destination et laisser le reste sur le système existant.
Sans pondération au niveau DNS, le partage de trafic doit être résolu dans la couche applicative ou dans une couche séparée de traffic-splitting. Cela signifie architecture supplémentaire, monitoring supplémentaire, gestion de certificat supplémentaire et points de défaillance supplémentaires. Quand la décision peut au lieu de cela être prise dans la réponse DNS, le client est dirigé vers la bonne destination dès la première requête.
Les scénarios de maintenance et de drain sont également brutaux quand ils sont gérés en supprimant des enregistrements. Retirer une IP d'un enregistrement DNS est efficace pour les nouvelles requêtes, mais cela ne répond pas au besoin de réduire progressivement la part de trafic ou de retirer une cible de la rotation de manière contrôlée. Le comportement de cache client et résolveur intermédiaire sur la fenêtre TTL doit aussi être pris en compte.
Le bon modèle consiste à attribuer un poids distinct à chaque enregistrement DNS et à choisir l'algorithme pour le scénario. Le weighted round-robin convient à une distribution équilibrée et ordonnée ; le weighted random fournit une sélection statistique basée sur le pourcentage. Un poids de 0 place la cible en mode drain effectif, la retirant des nouvelles réponses DNS.
TR7 Weighted DNS livre une distribution de trafic contrôlée au niveau DNS via des poids par enregistrement, weighted round-robin, weighted random, rechargement de configuration en direct et comportement de drain à poids=0.
Notre approche
TR7 sort la réponse DNS d'une liste statique d'enregistrements et la transforme en une décision de distribution de trafic gouvernée par des valeurs de poids et des algorithmes sélectionnables.
Le weighted round-robin fait tourner les enregistrements en proportion de leurs poids
Un poids entier est défini pour chaque IP ou membre d'enregistrement. L'algorithme weighted round-robin utilise ces poids pour distribuer les réponses DNS proportionnellement à travers le pool.
Le weighted random fournit une sélection statistique basée sur le pourcentage
L'algorithme weighted random effectue une sélection aléatoire proportionnelle au poids à chaque requête. À fort volume de requêtes, la distribution observée du trafic converge vers les ratios de poids définis.
La mise à jour en direct prend effet sur les nouvelles requêtes DNS sans délai
Les changements de poids entrent dans le pipeline de rechargement de configuration en direct et les nouvelles requêtes reçoivent immédiatement la distribution mise à jour. Comme les réponses précédemment mises en cache vivent jusqu'à l'expiration de leur TTL, la planification du TTL est essentielle dans les scénarios de transition rapide.
Le poids 0 déclenche le comportement de drain, retirant la cible des réponses
Quand le poids d'un enregistrement est mis à 0, il est retiré de la liste de candidats actifs. Ce comportement fournit un drain contrôlé pour la maintenance, le rollback ou la mise hors service d'un centre de données.
Capacités
Weighted DNS gère les valeurs de poids par enregistrement avec la sélection d'algorithme, les mises à jour en direct, l'intégration topologique et les scénarios de maintenance.
Un poids entier distinct est attribué à chaque enregistrement DNS
Dans TR7, chaque membre d'enregistrement peut avoir sa propre valeur de poids. Cette valeur détermine sa part relative dans la distribution de trafic — des poids de 5 et 2 ciblent un ratio d'environ 5:2. Si un nombre flottant est fourni, il est arrondi à un entier avant utilisation. Le modèle facilite l'attribution d'une part plus large aux cibles de plus grande capacité et d'une part plus petite aux cibles de test.
Le weighted round-robin fournit une distribution contrôlée et équilibrée
Le weighted round-robin sélectionne les enregistrements en rotation selon leurs ratios de poids. C'est le choix préféré quand une distribution équilibrée est attendue et que l'usage séquentiel des enregistrements est acceptable. C'est un algorithme pratique pour les déploiements canary, les rollouts progressifs et le partage de trafic proportionnel à la capacité. Les opérateurs remodèlent la distribution simplement en changeant les valeurs de poids.
Le weighted random effectue une sélection de trafic statistiquement proportionnelle
Le weighted random produit une sélection aléatoire proportionnelle au poids à chaque requête DNS. De petites déviations peuvent apparaître sur de courtes fenêtres temporelles ; à fort volume de requêtes la distribution converge vers les ratios définis. Il convient bien aux tests A/B et au routage de trafic expérimental. De nouvelles cibles avec un faible poids peuvent être testées en toute sécurité au sein du même pool d'enregistrements.
Les changements de poids se propagent aux nouvelles requêtes via le live reload
Quand les valeurs de poids changent, la configuration GTM entre dans le processus de rechargement en direct. Un mécanisme de debounce fusionne les changements successifs rapides, réduisant les re-renders inutiles ; la latence typique du live reload est d'environ 3 secondes. Les nouvelles requêtes DNS reçoivent la distribution de poids mise à jour. Les réponses précédemment mises en cache dans les caches client et résolveur restent jusqu'à l'expiration de leur TTL.
La planification du TTL est critique pour les transitions et rollbacks rapides
Quand un poids DNS change, le système met à jour les nouvelles réponses immédiatement ; cependant, les réponses DNS déjà émises vivent dans les caches intermédiaires jusqu'à l'expiration de leur TTL. Pour les scénarios canary, blue/green ou rollback rapide, le TTL doit être maintenu bas. Des valeurs dans la plage 5-60 secondes permettent aux transitions de prendre effet plus rapidement. Un TTL plus élevé est approprié pendant les périodes de fonctionnement stable.
Mettre le poids à 0 place un enregistrement en mode drain effectif
Quand le poids d'une IP ou d'un membre d'enregistrement atteint 0, cette cible est retirée des nouvelles réponses DNS. Cela permet de drainer un enregistrement pour la maintenance sans le supprimer. Les réponses cachées existantes continuent à utiliser l'ancienne réponse jusqu'à l'expiration de leur TTL ; les nouvelles requêtes ne reçoivent plus la cible. C'est une méthode contrôlée et réversible pour la maintenance, le rollback ou la mise hors service d'un centre de données.
Les poids au niveau du centre de données et de l'IP peuvent être évalués ensemble
Dans TR7, la distribution n'est pas confinée à un seul niveau d'IP — la logique de poids de groupe de centre de données et de membre d'enregistrement peut fonctionner en combinaison. Le centre de données ou groupe candidat approprié est sélectionné d'abord ; les enregistrements au sein de ce groupe sont ensuite distribués par poids. Ce modèle aide à tenir compte à la fois de la capacité et de la localisation dans la gestion globale du trafic. Dans les grands déploiements, la distribution devient plus en couches et plus gérable.
Après une correspondance topologique, le poids s'applique au sein du bucket sélectionné
Quand la sélection basée sur la géo ou la topologie est en usage, le groupe candidat approprié est identifié d'abord. La distribution de poids est ensuite appliquée au sein de cet ensemble de candidats. Les utilisateurs européens, par exemple, sont routés vers le groupe de centres de données européens, tandis que les IP au sein de ce groupe sont pondérées. La décision topologique et la décision de poids sont appliquées séquentiellement sans interférer entre elles.
Les algorithmes round-robin et random classiques sont aussi disponibles dans le même modèle
Les enregistrements qui ne nécessitent pas de distribution pondérée peuvent utiliser le round-robin ou la sélection aléatoire classique. Le round-robin distribue les enregistrements à parts égales ; le random sélectionne au hasard. Ces algorithmes sont suffisants pour les scénarios simples et sont gérés via le même modèle d'enregistrement, afin que basculer vers des algorithmes pondérés ne nécessite aucun changement structurel. Les opérateurs choisissent le comportement de distribution approprié pour chaque enregistrement DNS.
L'algorithme closest offre une sélection basée sur la proximité pour les enregistrements A et AAAA
L'algorithme closest est disponible pour les enregistrements A et AAAA qui nécessitent une sélection par proximité IP. Contrairement à la distribution pondérée, il se concentre sur la sélection de la cible la plus proche ou la plus appropriée pour le client. Topologie, closest et poids peuvent servir comme couches de décision distinctes dans la gestion globale du trafic. Le résultat est une réponse DNS consciente du contexte plutôt que simplement aléatoire.
Profondeur opérationnelle
Le DNS pondéré est exploité conjointement avec le format de poids, la sélection d'algorithme, la latence du live reload, l'impact du TTL et le comportement de sélection d'enregistrement.
Format du poids
Le poids est défini comme un nombre et utilisé comme un entier. Si un flottant est fourni il est arrondi. Les ratios de poids représentent des parts relatives entre enregistrements, pas des pourcentages absolus.
Comportement de rendu des algorithmes pondérés
Les algorithmes weighted round-robin et weighted random utilisent la liste d'enregistrements avec une carte de poids. Des valeurs de poids indexées sont générées pour chaque enregistrement. Cette structure est évaluée par la fonction de sélecteur pendant la génération de réponse DNS.
Latence du live reload
Les changements de configuration passent par un processus de live reload avec debounce. La valeur de debounce typique est de 3 secondes ; une limite d'attente maximale peut être appliquée pendant les rafales de changements successifs rapides. Ce comportement réduit les opérations de re-render fréquentes inutiles.
Impact du TTL
Un changement de poids prend effet sur les nouvelles requêtes DNS. Les clients ou résolveurs qui ont déjà reçu une réponse précédente continuent à utiliser l'enregistrement en cache jusqu'à l'expiration de son TTL. Pour cette raison, le TTL est un paramètre opérationnel aussi important que le poids lors de la planification des transitions.
Comportement de drain
Le poids 0 est utilisé pour retirer un enregistrement de la liste de candidats actifs. Cela permet d'effectuer la maintenance ou la migration sans supprimer totalement l'enregistrement. Pour réinstaurer l'enregistrement, remettez le poids à une valeur positive.
Sélection des N premiers
Dans certains scénarios, un nombre peut être fourni à la place d'un algorithme pour sélectionner les N premiers enregistrements de la liste de candidats. Ce comportement est utile pour un limit déterministe et simple d'enregistrements. C'est une option pratique pour les cas spéciaux où la distribution pondérée n'est pas requise.
Quand l'utiliser
Donner à une nouvelle version une petite part de trafic en déploiement canary
L'IP de la nouvelle version reçoit un faible poids ; la version courante reçoit un poids élevé. La nouvelle version démarre à environ 5 % du trafic ; à mesure que les métriques paraissent saines, le poids est augmenté incrémentalement. Si un problème apparaît, la nouvelle version est drainée en mettant son poids à 0.
Routage DNS contrôlé pendant une bascule blue/green
Pendant que l'environnement bleu est actif, l'environnement vert est testé à un faible poids. À la bascule, le poids de bleu est réduit à 0 et le vert devient la seule cible active. Quand un rollback est nécessaire, les poids sont inversés pour revenir à l'environnement précédent.
Distribution proportionnelle entre deux cibles pour test A/B
Deux landing pages ou deux variantes de service sont définies avec des enregistrements IP distincts. Les poids peuvent être mis à 1:1 pour un test égal ou 9:1 pour une expérience limitée. Sur la base de l'analyse des résultats, le ratio de trafic est ajusté au niveau DNS.
Transfert progressif de trafic pendant une migration de centre de données
L'ancien centre de données démarre à un poids élevé ; le nouveau centre de données est introduit à un faible poids. L'équipe d'exploitation déplace le trafic vers le nouveau centre via une réduction par paliers telle que 100 → 80 → 50 → 20 → 0. Quand le TTL est maintenu bas, l'impact de chaque étape est observé plus rapidement.
Équilibrage de charge proportionnel à la capacité
Les backends à plus grande capacité reçoivent un poids plus élevé ; les ressources plus contraintes reçoivent un poids plus faible. La distribution de trafic devient proportionnelle à la capacité du serveur. Les opérateurs remodèlent la distribution purement en mettant à jour les valeurs de poids.
Drain de maintenance sans interruption de service
Le poids du backend mis en maintenance est réduit à 0. Les nouvelles requêtes DNS ne routent plus vers cette cible ; les réponses précédemment mises en cache continuent à être utilisées jusqu'à l'expiration de leur TTL. Quand la maintenance est terminée, le poids est restauré à une valeur positive et le backend ré-entre en service.
Questions fréquentes
Quelle est la différence entre weighted round-robin et weighted random ?
Quelle est la différence entre mettre le poids à 0 et supprimer l'enregistrement ?
Quand un changement de poids prend-il effet ?
Quelle valeur de TTL est recommandée pour un déploiement canary ?
Le routage basé sur la topologie et le poids peuvent-ils être utilisés ensemble ?
Un flottant peut-il être entré comme valeur de poids ?
Prenez le contrôle de votre pourcentage de trafic au niveau DNS
Poids par enregistrement et live reload pour les déploiements canary, bascules blue/green, tests A/B et migrations de centres de données. Parcourons un déploiement en direct dans votre environnement.