Ein Benutzer, der an ein entferntes Rechenzentrum geleitet wird, zahlt bei jeder Anfrage die Kosten des Round-Trips.
Wenn DNS jedem Benutzer unabhängig von seinem Standort dasselbe Rechenzentrum zuweist, tragen Benutzer, die weit von diesem Rechenzentrum entfernt sind, bei jeder einzelnen Anfrage einen längeren Netzwerkpfad. Die zusätzliche Distanz zeigt sich als höhere Round-Trip-Zeit, langsamerer Verbindungsaufbau und eine verschlechterte Erfahrung, die durch noch so viel Backend-Optimierung am Ziel nicht aufgefangen werden kann.
Reines Routing allein nach Land hilft, ist aber grob. Ein Benutzer kann sich im richtigen Land befinden und dennoch einem von zwei im Land gelegenen Rechenzentren wesentlich näher sein als dem anderen, und eine Regel auf Basis nationaler Grenzen kann sie nicht unterscheiden. Eine Verteilung, die Nähe gänzlich ignoriert — Round-Robin oder zufällig über alle Rechenzentren —, schickt einen Teil der Benutzer aktiv den langen Weg.
Die Auslagerung der Näherungsentscheidung an einen externen Geolokalisierungsdienst bringt eigene Probleme mit sich: DNS-Anfragekontext verlässt die Organisation, die Entscheidungsschicht hängt von der Verfügbarkeit eines Dritten ab, und Verpflichtungen zur Datenresidenz werden schwer erfüllbar. Eine kritische Verkehrsentscheidung sollte nicht von einer externen API abhängen.
Es gibt zudem eine Korrektheitsfalle. Nähe zum nächstgelegenen Rechenzentrum ist nur dann nützlich, wenn dieses Rechenzentrum tatsächlich gesund ist. Einen Benutzer zum nächstgelegenen Rechenzentrum zu leiten, während dieses ausfällt, ist schlechter, als ihn etwas weiter zu einem funktionierenden zu schicken.
TR7 Latenzbasiertes DNS-Routing adressiert genau dies: Es wählt für jeden Anfragenden anhand offline verfügbarer Näherungsdaten das nächstgelegene gesunde Rechenzentrum aus und hält den Pfad kurz, ohne Anfragekontext preiszugeben oder die Gesundheit der Rechenzentren zu ignorieren.
Unser Ansatz
TR7 setzt Näherungssteuerung über den Selektor für die nächstgelegene Auswahl, offline verfügbare GeoIP-Daten, Client-Subnet-Bewusstsein und gesundheitsgefilterte Kandidatenlisten um.
Der Selektor für die nächstgelegene Auswahl wählt pro Anfrage den nächstgelegenen Kandidaten
Wenn ein DNS-Eintrag den Balancing-Algorithmus für die nächstgelegene Auswahl verwendet, bewertet GTM die Kandidatenantworten nach der Nähe des Anfragenden zu jedem Rechenzentrum und gibt das nächstgelegene zurück. Die Entscheidung läuft pro Anfrage, sodass jeder Anfragende mit dem Rechenzentrum beantwortet wird, das seine Netzwerkdistanz minimiert.
Offline verfügbare GeoIP-Datenbanken halten die Abfrage auf dem Gerät
Die Nähe wird aus lokal auf der Appliance gespeicherten Land-, Stadt- und ASN-Datenbanken aufgelöst. Die Entscheidung sendet niemals DNS-Anfragekontext an eine externe Geolokalisierungs-API — die geografische Auflösung bleibt innerhalb der Infrastruktur der Organisation.
EDNS Client Subnet folgt dem realen Benutzer, nicht dem Resolver
Mit EDNS Client Subnet kann die Näherungsentscheidung auf dem tatsächlichen Subnetz des Benutzers statt auf der IP des weiterleitenden Resolvers basieren. Das vermeidet, dass Benutzer öffentlicher Resolver an das Rechenzentrum geleitet werden, das dem Resolver statt ihnen selbst am nächsten liegt.
Ungesunde Rechenzentren verlassen die Kandidatenliste zuerst
Der Status der Gesundheitsprüfung filtert die Kandidaten-Einträge, bevor die Näherungsentscheidung läuft. Ein ausfallendes Rechenzentrum wird aus der Liste entfernt, sodass die nächstgelegene Antwort stets das nächstgelegene gesunde Rechenzentrum ist — Nähe setzt sich niemals über Verfügbarkeit hinweg.
Fähigkeiten
Latenzbasiertes DNS-Routing macht Nähe zu einer DNS-Entscheidung pro Anfrage, auf jeden Eintrag begrenzt und lokal entschieden.
Die nächstgelegene Auswahl pro Anfrage verkürzt den Netzwerkpfad
Der Balancing-Algorithmus für die nächstgelegene Auswahl bewertet jeden Kandidaten-Eintrag gegen den Standort des anfragenden Netzwerks und gibt das nächstgelegene Rechenzentrum zurück. Da eine kürzere geografische Distanz in der Regel eine niedrigere Round-Trip-Zeit bedeutet, werden Benutzer ohne jegliche benutzerspezifische Konfiguration auf dem kürzesten gangbaren Pfad zur Anwendung gehalten. Die Entscheidung wird für jede Anfrage neu berechnet, statt zur Konfigurationszeit festgelegt zu werden.
Die Nähe wird aus Land-, Stadt- und ASN-Daten gemeinsam aufgelöst
GTM löst den Standort des Anfragenden anhand offline verfügbarer Land-, Stadt- und ASN-Datenbanken auf. Daten auf Stadtebene erlauben es der Plattform, zwischen zwei Rechenzentren innerhalb desselben Landes zu unterscheiden, und ASN-Daten verfeinern die Entscheidung anhand des Netzwerks, über das der Anfragende verbunden ist. Das ist feiner granular als ein Routing nach nationalen Grenzen und bleibt zugleich eine deterministische lokale Abfrage.
EDNS Client Subnet verbessert die Genauigkeit der Nähe
Wenn der Resolver das Client-Subnetz übermittelt, basiert GTM die Näherungsentscheidung auf dem realen Netzwerkstandort des Benutzers statt auf dem des Resolvers. Das ist am wichtigsten für Clients, die entfernte öffentliche Resolver nutzen, wo eine reine Resolver-Entscheidung einen Benutzer an ein Rechenzentrum nahe dem Resolver statt nahe dem Benutzer leiten könnte. Die nächstgelegene Antwort folgt dem tatsächlichen Standort des Benutzers.
Gesundheitsfilterung hält die Nähe ehrlich
Kandidaten-Einträge werden nach der Gesundheit des Rechenzentrums gefiltert, bevor die Entscheidung für die nächstgelegene Auswahl angewendet wird. Ein ungesundes Rechenzentrum kommt nicht als nächstgelegene Antwort infrage, sodass die Plattform niemals Verfügbarkeit gegen Nähe eintauscht. Wenn sich ein nahegelegenes Rechenzentrum erholt, tritt es bei der nächsten Entscheidung automatisch wieder in die Kandidatenliste ein.
Nähe lässt sich mit Topologieregeln kombinieren
Der Selektor für die nächstgelegene Auswahl kann als Selektor innerhalb eines Topologie-Regelwerks fungieren, sodass ein Operator die Kandidaten zunächst nach Netzwerk, Land, Stadt, Kontinent oder ASN eingrenzen und dann unter den Treffern die nächstgelegene Antwort wählen kann. So können Compliance- oder Carrier-Vorgaben und Näherungssteuerung in derselben Entscheidungs-Pipeline arbeiten.
Pro DNS-Eintrag konfiguriert, nicht global
Der Balancing-Algorithmus wird auf jedem DNS-Eintrag gesetzt. Dieselbe Domain kann einen Eintrag nach Nähe und einen anderen nach einer anderen Strategie beantworten, sodass Näherungssteuerung genau dort angewendet wird, wo sie Mehrwert bietet, und andere Einträge ihr eigenes Verhalten behalten. Operatoren stimmen das Routing Eintrag für Eintrag ab.
Entscheidung auf dem Gerät ohne externe Abhängigkeit
Sowohl die Näherungsabfrage als auch die Auswahl des Eintrags laufen auf der Appliance. Es gibt keine externe Geolokalisierungs-API im Anfragepfad, was eine Abhängigkeit von der Verfügbarkeit eines Dritten beseitigt und den DNS-Anfragekontext innerhalb der Organisation hält. Die Näherungsentscheidung funktioniert auch dann weiter, wenn die ausgehende Konnektivität zu externen Diensten nicht verfügbar ist.
Operative Tiefe
Die Näherungssteuerung wird zusammen mit dem GeoIP-Datenbanksatz, dem Feld für den Balancing-Algorithmus, Topologie-Selektoren, Gesundheitsfilterung und Live-Konfigurations-Reload betrieben.
GeoIP-Datenbanksatz
Näherungsentscheidungen stützen sich auf drei offline verfügbare Datenbanken auf der Appliance: eine ASN-Datenbank, eine Datenbank auf Stadtebene und eine Datenbank auf Landesebene. Zusammen unterstützen sie eine Nähe, die Land, Stadt und ASN berücksichtigt. Da die Daten lokal vorliegen, hängen Laufzeitentscheidungen nicht von einem externen Dienst ab; der Aktualisierungsablauf der Datenbank ist getrennt vom Live-Entscheidungspfad geplant.
Feld für den Balancing-Algorithmus
Die Nähe wird ausgewählt, indem der Balancing-Algorithmus des Eintrags auf die nächstgelegene Auswahl gesetzt wird, einen der verfügbaren Balancing-Algorithmen für DNS-Einträge neben all, first-N, Round-Robin, gewichtetem Round-Robin, zufällig und gewichtet zufällig. Das Feld wird pro Eintrag gesetzt und Änderungen werden über die Konfigurations-Pipeline angewendet.
Kombination mit Topologie-Selektoren
Innerhalb eines Topologie-Regelwerks kann die nächstgelegene Auswahl als Selektor verwendet werden, der auf die Einträge angewendet wird, die einer Regel entsprechen. So kann die Nähe laufen, nachdem eine geografische oder Netzwerk-Vorgabe die Kandidaten bereits eingegrenzt hat, und so Richtlinienfilterung mit der Auswahl der nächstgelegenen Antwort in einem einzigen Eintrag kombinieren.
Gesundheitsgefilterte Kandidaten
Die der Entscheidung für die nächstgelegene Auswahl übergebene Kandidatenliste spiegelt die aktuelle Gesundheit der Rechenzentren wider. Einträge für ungesunde Rechenzentren werden vor der Auswahl entfernt, sodass die Nähe nur über Rechenzentren berechnet wird, die tatsächlich Verkehr bedienen können. Diese Filterung ist Teil der Entscheidungs-Pipeline, keine separate manuelle Regel.
Live-Konfigurations-Reload
Änderungen an Eintrags-Algorithmen und Kandidatenlisten gelangen in die Pipeline zur Konfigurations-Regenerierung und werden ohne Neustart des Dienstes angewendet. Neue Anfragen erhalten Antworten, die die aktuelle Konfiguration widerspiegeln; Antworten, die von Clients bereits zwischengespeichert wurden, bleiben bis zum Ablauf ihrer TTL bestehen, sodass niedrigere TTLs Nähe- und Gesundheitsänderungen schneller wirksam werden lassen.
Nähe gegenüber Live-Netzwerksignalen
Der Selektor für die nächstgelegene Auswahl entscheidet nach geografischer Nähe, die als Indikator für Latenz dient und keine Live-Messung derselben ist. Wenn eine Entscheidung den tatsächlichen Echtzeit-Netzwerkpfad oder die Auslastung eines Rechenzentrums widerspiegeln muss, liefert die mehrquellenbasierte DC-Auswahl Live-Signale zu Host, Dienst und Client-Pfad, die die geografische Näherungssteuerung ergänzen.
Wann es zu verwenden ist
Globale Benutzer an die nächstgelegene Region leiten
Für Dienste mit über Regionen verteilten Benutzern beantwortet der Selektor für die nächstgelegene Auswahl jede Anfrage mit dem geografisch nächstgelegenen Rechenzentrum, verkürzt den Netzwerkpfad und reduziert die Round-Trip-Zeit ohne benutzerspezifische Regeln.
Zwischen zwei Rechenzentren in einem Land wählen
Wenn ein Land mehr als ein Rechenzentrum beherbergt, unterscheidet die Nähe auf Stadtebene, welches dem Anfragenden näher liegt — feiner als eine reine Land-Regel, die beide als gleichwertig behandeln würde.
Näherungssteuerung mit Datenresidenz
Da die Geolokalisierungsabfrage auf offline verfügbaren Datenbanken auf dem Gerät läuft, erhalten Organisationen mit Verpflichtungen zur Datenresidenz oder zur Vertraulichkeit von Anfragen ein näherungsbasiertes Routing, ohne DNS-Anfragekontext an einen externen Geolokalisierungsanbieter zu senden.
Nähe innerhalb einer Topologie-Richtlinie
Grenzen Sie die Kandidaten zunächst aus Compliance- oder Carrier-Gründen nach Land, ASN oder CIDR ein und lassen Sie dann den Selektor für die nächstgelegene Auswahl unter den zulässigen Rechenzentren die nächstgelegene Antwort wählen — Richtlinie und Nähe in einem Eintrag.
Häufig gestellte Fragen
Misst TR7 GTM die Live-Latenz vom Resolver zu jedem Rechenzentrum?
Wie wird der Standort des Anfragenden bestimmt?
Warum EDNS Client Subnet beim Näherungsrouting verwenden?
Was verhindert, dass eine Anfrage an das nächstgelegene Rechenzentrum geleitet wird, während dieses ausgefallen ist?
Kann Näherungsrouting mit Land- oder ASN-Regeln kombiniert werden?
Wird Näherungsrouting auf die gesamte Zone oder pro Eintrag angewendet?
Halten Sie jeden Benutzer auf dem kürzesten Pfad zu einem gesunden Rechenzentrum
Näherungsbasierte DNS-Steuerung, die auf Ihren eigenen Appliances entschieden wird — offline verfügbares GeoIP, Client-Subnet-Bewusstsein und Gesundheitsfilterung. Lassen Sie uns das auf Ihrer eigenen Topologie durchgehen.