Die meisten GSLB-Implementierungen treffen Entscheidungen zur Rechenzentrumsauswahl anhand einer einzigen Signalklasse. Die geografische Entfernung ist eine gängige Wahl; die Round-Trip-Zeit von den Messpunkten der Plattform eine weitere; statische Topologie-Lookups sind eine dritte. Jede erfasst eine nützliche Dimension und verfehlt die anderen.
Geografie ignoriert die Last — das nächstgelegene Rechenzentrum kann gleichzeitig dasjenige sein, das gerade unter Kapazitätsdruck steht. Latenz von den GSLB-Sonden ignoriert den Benutzer — der tatsächliche Netzwerkpfad des Benutzers ist nicht der Pfad, den die Sonde genommen hat. Statische Topologie geht davon aus, dass sich das Netzwerk seit der Konfiguration nicht verändert hat.
Produktive Entscheidungen brauchen alle drei Sichten zugleich: Ist die DC-Plattform gesund? Liefert die Anwendung auf dem DC aktuell Performance? Ist das Netzwerk vom Benutzer zum DC im Moment tatsächlich gut? Jede Sicht hat Signale, die die anderen nicht ersetzen können.
TR7 GTM stellt die drei Signalklassen — Host, Service, Client — als unabhängige Eingaben zur DC-Auswahl bereit, sodass Operatoren die Richtlinie beschreiben können, die tatsächlich zu ihrer Workload passt.
Die DC-Auswahl wird pro DNS-Record konfiguriert. Operatoren wählen, welche Signalquelle verwendet wird, welche konkrete Metrik innerhalb dieser Quelle, wie viele DCs ausgewählt werden und wie über die Auswahl verteilt wird.
Fünf auf der DC-Plattform gemessene Metriken: CPU, Speicher, Bandbreite, Status (Up/Down-Komposit) und Paketverlust. Nützlich, wenn der Druck auf der DC-Plattform das dominante Signal für Routing-Entscheidungen ist.
Acht pro Service gemessene Metriken: CPU, Speicher, Bandbreite, Requestrate, Verbindungsanzahl, neue Session-Rate, Status und healthyBackends. Leitet den Datenverkehr nach dem, was die Anwendung tatsächlich tut, nicht nur danach, ob der Host läuft.
Vier vom Netzwerkpfad zum anfragenden Client gemessene Metriken: Hops, MOS (Mean Opinion Score), Paketverlust und TTL. Erfasst die Benutzererfahrung, die DC-seitige Sonden nicht sehen können.
`pickDcCount` legt fest, wie viele DCs zurückgegeben werden. `balanceAlgorithm` verteilt über die Auswahl — alle, Top-N, Round Robin, gewichtetes Round Robin, Random, gewichtetes Random oder Closest.
Jeder DNS-Record im DC-Modus wählt unabhängig seine Signalquelle, sein Kriterium und sein Verteilungsverhalten.
Die DC-Host-Quelle stellt cpu, mem, bw, status und packetLoss bereit. Der Status ist der zusammengesetzte Erreichbarkeits-/Health-Zustand, berechnet aus den WAN- und LAN-Zugriffspunkten des DC. Nützlich, wenn die Kapazität auf Host-Ebene das dominante Routing-Signal ist.
Die Service-Quelle stellt cpu, mem, bw, request, connection, session_new, status und healthyBackends bereit. Die healthyBackends-Anzahl ist besonders tragend — sie leitet den Datenverkehr zum DC, an dem die Anwendung gerade die größte funktionierende Kapazität hat, nicht nur zum DC, dessen Plattform läuft.
Die Client-Quelle stellt hops (Pfadlänge), mos (Mean Opinion Score für VoIP/Echtzeit-Traffic-Qualität), packetLoss und ttl bereit. Diese Signale werden gegenüber dem Client-Netzwerk gemessen und erfassen die Benutzererfahrung, die DC-seitige Health-Sonden nicht sehen.
Der statische Modus umgeht die Multi-Source-Auswahl und weist DCs basierend auf vom Operator definierten Regeln zu. Nützlich für Legacy-DNS-Records, Compliance-getriebenes Routing (bestimmte DCs für bestimmte Clients) und Tests.
Das Auswahlkriterium wird vom Operator gesteuert: niedrigster Wert gewinnt, höchster Wert gewinnt, Wert gleich Zielwert oder Wert weicht um eine Marge ab. Dieselbe DSL steuert die Kriteriumsauswertung über alle drei Signalquellen hinweg.
`pickDcCount` ist standardmäßig 1, kann aber höher gesetzt werden, um in der DNS-Antwort mehrere DCs zurückzugeben. Das ermöglicht echtes Multi-DC-Load-Balancing statt eines Always-Pick-One-Routings — DNS-Clients erhalten mehrere Antworten und der clientseitige Resolver oder Stub wählt zwischen ihnen.
Sobald DCs ausgewählt sind, werden die Records innerhalb jedes DC gemäß `balanceAlgorithm` verteilt: all (jeden Record zurückgeben), top-1/2/3 (Top-N zurückgeben), Round Robin, gewichtetes Round Robin, Random, gewichtetes Random oder Closest (Nähe zum Anfrager). Der richtige Algorithmus hängt davon ab, ob Sie breite Verteilung, Top-N-Konzentration oder Stickiness wünschen.
Bei Verwendung der Service-Quelle geben Operatoren den Servicenamen an — verschiedene Anwendungen, die auf derselben DC-Flotte laufen, können unterschiedliche Routing-Regeln haben. Die healthyBackends-Anzahl für Service A und Service B kann separate DC-Auswahlen treiben.
Liefert die Auswahl kein gesundes DC, stellt die Fail-Safe-Liste des Records Last-Resort-Antworten bereit — vom Operator definierte IPs, die immer dann zurückgegeben werden, wenn alle Multi-Source-Signale ausfallen. Verhindert NXDOMAIN als letzte Antwort.
Die DC-Auswahl wird pro DNS-Record konfiguriert. Dieselbe Domain kann einen A-Record geroutet nach service.healthyBackends, einen MX-Record geroutet nach host.status und einen CNAME geroutet nach client.packetLoss haben. Operatoren stimmen jeden Record auf seine Workload ab.
Die Multi-Source-Auswahl arbeitet zusammen mit DC-Definitionen, Health-Check-Szenarien, gewichteten DNS-Algorithmen und Fail-Safe-Records.
Jede Signalquelle hat ihre eigene Messfrequenz. Host- und Service-Metriken werden im Metrik-Sammelzyklus des GTM aktualisiert (typischerweise alle 30–60 Sekunden). Client-Metriken werden pro Resolver-Session aktualisiert. Operatoren stimmen die Frequenz pro Quelle an die DC-Topologie an.
Die Auswahl verwendet pro Record jeweils eine Quelle. Wenn Operatoren möchten, dass Host-Signale Service-Signale gaten ("nur Service-Metriken berücksichtigen, wenn der Host gesund ist"), binden sie ein Host-basiertes Szenario an den Service-Source-Record. Das Layering ist explizit.
Die healthyBackends-Anzahl wird direkt aus der Load-Balancing-Schicht der Anwendung auf jedem DC gelesen, nicht aus externen Sonden geschätzt. Die Zahl spiegelt den tatsächlichen Pool gesunder Backends hinter dem Service in diesem Moment wider.
MOS wird aus Netzwerkqualitätsmessungen (Jitter, Paketverlust, Latenz) gegenüber dem anfragenden Client-Netzwerk berechnet. Er ist am genauesten für laufende Client-Sessions und konvergiert bei Erstanfragen innerhalb weniger Messfenster.
Ist `pickDcCount` größer als die Anzahl verfügbarer gesunder DCs, werden alle verfügbaren gesunden DCs zurückgegeben. Die Plattform erfindet niemals fiktive DCs, um die Zielanzahl zu erreichen — Operatoren sehen genau, welche realen DCs in Frage kamen.
Auswahl- und Verteilungsalgorithmen lassen sich zusammensetzen: Die Auswahl bestimmt die infrage kommenden DCs nach Kriterium; die Verteilung bestimmt, wie Records innerhalb jedes DC zurückgegeben werden. Ein Record kann 3 DCs nach service.healthyBackends auswählen und dann Records innerhalb jedes DC per weighted random zurückgeben.
Die Service-Quelle mit dem Kriterium healthyBackends leitet den Datenverkehr zum DC, an dem die Anwendung die größte funktionierende Kapazität hat. Vermeidet Hot-Spotting eines DC, dessen Host läuft, dessen Anwendungs-Backends jedoch degradiert sind.
Die Client-Quelle mit dem Kriterium packetLoss leitet jeden Benutzer zum DC mit dem saubersten Netzwerkpfad aus seinem Netzwerk. Nützlich für VoIP, Video, Gaming und Echtzeitanwendungen, bei denen Pfadqualität wichtiger ist als geografische Nähe.
Kombinieren Sie Pick-N (z. B. Top-3-DCs zurückgeben) mit weighted random distribution, um Traffic über mehrere gesunde Regionen zu teilen. Jeder DNS-Client erhält mehrere Optionen; Resolver und Stubs verteilen natürlich darauf.
Verwenden Sie ein Host-basiertes Szenario als Gate ("DC ist plattformgesund") und ein Service-basiertes Kriterium als Picker ("DC hat die höchste healthyBackends-Anzahl unter den freigegebenen DCs"). Kritische Workloads erhalten eine zweischichtige Auswahl ohne Skripting.
Testen Sie die Multi-Source-DC-Auswahl auf Ihrer eigenen Topologie: Host-Metriken, Service-Metriken und clientseitige Netzwerkmessungen, die dieselbe Routing-Entscheidung treiben.