La plupart des implémentations GSLB prennent les décisions de sélection de centre de données à partir d'une seule classe de signal. La distance géographique est un choix courant ; le temps aller-retour depuis les points de mesure de la plateforme en est un autre ; les recherches topologiques statiques en sont un troisième. Chacun capture une dimension utile et manque les autres.
La géographie ignore la charge — le centre de données le plus proche peut aussi être celui actuellement sous pression de capacité. La latence depuis les sondes du GSLB ignore l'utilisateur — le chemin réseau réel de l'utilisateur n'est pas celui qu'a pris la sonde. La topologie statique suppose que le réseau n'a pas changé depuis que la configuration a été écrite.
Les décisions en production ont besoin des trois vues à la fois : la plateforme du DC est-elle saine ? L'application sur le DC est-elle performante en ce moment ? Le réseau de l'utilisateur jusqu'au DC est-il réellement bon maintenant ? Chaque vue a des signaux que les autres ne peuvent pas remplacer.
TR7 GTM expose les trois classes de signaux — host, service, client — comme entrées indépendantes de la sélection DC, permettant aux opérateurs de décrire la politique qui correspond réellement à leur charge de travail.
La sélection DC est configurée par enregistrement DNS. Les opérateurs choisissent quelle source de signal utiliser, quelle métrique spécifique au sein de cette source, combien de DC sélectionner et comment distribuer sur les sélections.
Cinq métriques mesurées au niveau de la plateforme DC : CPU, mémoire, bande passante, statut (composite up/down) et perte de paquets. Utile quand la pression de la plateforme DC est le signal dominant pour les décisions de routage.
Huit métriques mesurées par service : CPU, mémoire, bande passante, taux de requêtes, nombre de connexions, taux de nouvelles sessions, statut et healthyBackends. Route le trafic selon ce que fait réellement l'application, pas seulement selon que le host est up.
Quatre métriques mesurées depuis le chemin réseau jusqu'au client demandeur : sauts, MOS (Mean Opinion Score), perte de paquets et TTL. Capture l'expérience côté utilisateur que les sondes côté DC ne peuvent pas voir.
`pickDcCount` choisit combien de DC renvoyer. `balanceAlgorithm` distribue sur les sélections — tous, top-N, round-robin, round-robin pondéré, aléatoire, aléatoire pondéré ou le plus proche.
Chaque enregistrement DNS en mode DC sélectionne indépendamment sa source de signal, son critère et son comportement de distribution.
La source host DC expose cpu, mem, bw, status et packetLoss. Status est l'état composite accessibilité/santé calculé à partir des points d'accès WAN et LAN du DC. Utile quand la capacité au niveau host est le signal de routage dominant.
La source service expose cpu, mem, bw, request, connection, session_new, status et healthyBackends. Le compte healthyBackends est particulièrement porteur — il route le trafic vers le DC où l'application a le plus de capacité opérationnelle en ce moment, pas seulement vers le DC dont la plateforme est up.
La source client expose hops (longueur du chemin), mos (Mean Opinion Score pour la qualité de trafic VoIP/temps réel), packetLoss et ttl. Ces signaux sont mesurés contre le réseau client, capturant l'expérience utilisateur que les sondes de santé côté DC ne voient pas.
Le mode statique contourne la sélection multi-source et assigne des DC selon des règles définies par l'opérateur. Utile pour les enregistrements DNS legacy, le routage piloté par la conformité (DC spécifiques pour clients spécifiques) et les tests.
Le critère de sélection est contrôlé par l'opérateur : valeur la plus basse gagne, valeur la plus haute gagne, valeur égale à la cible, ou valeur différant d'une marge. Le même DSL pilote l'évaluation de critères sur les trois sources de signal.
`pickDcCount` est par défaut à 1 mais peut être défini plus haut pour renvoyer plusieurs DC dans la réponse DNS. Cela permet un véritable équilibrage de charge multi-DC plutôt qu'un routage toujours-un-seul — les clients DNS reçoivent plusieurs réponses et le résolveur ou le stub côté client sélectionne entre elles.
Une fois les DC sélectionnés, les enregistrements au sein de chaque DC sont distribués selon `balanceAlgorithm` : all (renvoyer chaque enregistrement), top-1/2/3 (renvoyer les N premiers), round-robin, round-robin pondéré, aléatoire, aléatoire pondéré, ou le plus proche (proximité du demandeur). Le bon algorithme dépend de votre objectif : distribution large, concentration top-N ou stickiness.
Lors de l'utilisation de la source service, les opérateurs spécifient le nom du service — différentes applications tournant sur la même flotte de DC peuvent avoir des règles de routage différentes. Le compte healthyBackends pour les services A et B peut piloter des choix de DC distincts.
Si la sélection ne renvoie aucun DC sain, la liste fail-safe de l'enregistrement fournit des réponses de dernier recours — des IP définies par l'opérateur qui sont toujours renvoyées lorsque tous les signaux multi-source échouent. Empêche un NXDOMAIN comme réponse finale.
La sélection DC est configurée par enregistrement DNS. Le même domaine peut avoir un enregistrement A routé par service.healthyBackends, un enregistrement MX routé par host.status et un CNAME routé par client.packetLoss. Les opérateurs ajustent chaque enregistrement à sa charge de travail.
La sélection multi-source fonctionne conjointement avec les définitions DC, les scénarios de health-check, les algorithmes DNS pondérés et les enregistrements fail-safe.
Chaque source de signal a sa propre cadence de mesure. Les métriques host et service se rafraîchissent sur le cycle de collecte de métriques du GTM (typiquement toutes les 30-60 secondes). Les métriques client se mettent à jour par session de résolveur. Les opérateurs ajustent la cadence par source en fonction de la topologie DC.
La sélection utilise une source à la fois par enregistrement. Quand les opérateurs veulent que les signaux host conditionnent les signaux service (« ne considérer les métriques de service que si le host est sain »), ils lient un scénario basé sur le host à l'enregistrement source service. La superposition est explicite.
Le compte healthyBackends est lu directement depuis la couche d'équilibrage de charge de l'application sur chaque DC, et non approximé par des sondes externes. Le nombre reflète le pool réel de backends sains derrière le service à ce moment-là.
Le MOS est calculé à partir de mesures de qualité réseau (gigue, perte de paquets, latence) contre le réseau client demandeur. Il est le plus précis pour les sessions client en cours et converge en quelques fenêtres de mesure pour les clients de première fois.
Si `pickDcCount` est supérieur au nombre de DC sains disponibles, tous les DC sains disponibles sont renvoyés. La plateforme n'invente jamais de faux DC pour atteindre l'objectif de compte — les opérateurs voient exactement quels DC réels étaient éligibles.
Les algorithmes de sélection et de distribution se composent : la sélection choisit les DC éligibles par critère ; la distribution détermine comment les enregistrements au sein de chaque DC sont renvoyés. Un enregistrement peut sélectionner 3 DC par service.healthyBackends, puis renvoyer les enregistrements au sein de chaque DC par aléatoire pondéré.
La source service avec critère healthyBackends route le trafic vers le DC où l'application a le plus de capacité opérationnelle. Évite de surcharger un DC dont le host est up mais dont les backends applicatifs sont dégradés.
La source client avec critère packetLoss route chaque utilisateur vers le DC offrant le chemin réseau le plus propre depuis son réseau. Utile pour la VoIP, la vidéo, le jeu et les applications temps réel où la qualité du chemin importe plus que la proximité géographique.
Combinez pick-N (par exemple renvoyer les 3 meilleurs DC) avec une distribution aléatoire pondérée pour partager le trafic entre plusieurs régions saines. Chaque client DNS reçoit plusieurs options ; résolveurs et stubs se distribuent naturellement entre elles.
Utilisez un scénario basé sur le host comme gate (« DC est sain en plateforme ») et un critère basé sur le service comme sélecteur (« DC a le compte healthyBackends le plus élevé parmi les DC validés »). Les charges critiques obtiennent une sélection à deux couches sans scripting.
Essayez la sélection DC multi-source sur votre propre topologie : métriques host, métriques service et mesures réseau côté client pilotant la même décision de routage.