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.
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.
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.
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.
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.
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.
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.
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 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 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.
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.
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.
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.
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.
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 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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.