Un usuario enrutado a un centro de datos distante paga el coste de ida y vuelta en cada petición.
Cuando el DNS entrega a todos los usuarios el mismo centro de datos sin importar dónde estén, los usuarios lejanos a ese DC cargan con una ruta de red más larga en cada petición. La distancia extra se traduce en un mayor tiempo de ida y vuelta, un establecimiento de conexión más lento y una experiencia degradada que ningún ajuste del backend en el destino puede recuperar.
El enrutamiento basado solo en el país ayuda, pero es tosco. Un usuario puede estar en el país correcto y, aun así, estar mucho más cerca de uno de los dos centros de datos del país que del otro, y una regla de fronteras nacionales no puede distinguirlos. La distribución que ignora por completo la proximidad —round-robin o aleatoria entre todos los DC— envía activamente a una fracción de los usuarios por el camino largo.
Delegar la decisión de proximidad a un servicio de geolocalización externo introduce sus propios problemas: el contexto de la consulta DNS sale de la organización, la capa de decisión depende de la disponibilidad de un tercero y las obligaciones de residencia de datos se vuelven difíciles de cumplir. Una decisión crítica de tráfico no debería depender de una API externa.
También hay una trampa de corrección. La proximidad al centro de datos más cercano solo es útil si ese centro de datos está realmente saludable. Dirigir a un usuario al DC más cercano mientras este está fallando es peor que enviarlo un poco más lejos a uno que funciona.
El Enrutamiento DNS por proximidad de TR7 aborda exactamente esto: elige el centro de datos saludable más cercano para cada solicitante usando datos de proximidad sin conexión, manteniendo la ruta corta sin filtrar el contexto de la consulta ni ignorar la salud del DC.
Nuestro enfoque
TR7 implementa la dirección por proximidad mediante el selector de cercanía, datos GeoIP sin conexión, conciencia de la subred del cliente y conjuntos de candidatos filtrados por salud.
El selector de cercanía elige el candidato más próximo en cada consulta
Cuando un registro DNS usa el algoritmo de balanceo de cercanía, GTM clasifica las respuestas candidatas según la proximidad del solicitante a cada centro de datos y devuelve la más cercana. La decisión se ejecuta por consulta, de modo que a cada solicitante se le responde con el centro de datos que minimiza su distancia de red.
Las bases de datos GeoIP sin conexión mantienen la consulta en el equipo
La proximidad se resuelve a partir de bases de datos de país, ciudad y ASN almacenadas localmente en el equipo. La decisión nunca envía el contexto de la consulta DNS a una API de geolocalización externa: la resolución geográfica permanece dentro de la infraestructura de la organización.
EDNS Client Subnet sigue al usuario real, no al resolver
Con EDNS Client Subnet, la decisión de proximidad puede basarse en la subred real del usuario en lugar de la IP del resolver de reenvío. Esto evita dirigir a los usuarios de resolvers públicos al centro de datos más cercano al resolver en vez de a ellos mismos.
Los centros de datos no saludables salen primero del conjunto de candidatos
El estado de los chequeos de salud filtra los registros candidatos antes de que se ejecute la decisión de proximidad. Un centro de datos en fallo se elimina del conjunto, de modo que la respuesta más cercana es siempre el centro de datos saludable más próximo: la proximidad nunca anula la disponibilidad.
Capacidades
El Enrutamiento DNS por proximidad convierte la proximidad en una decisión DNS por consulta, acotada a cada registro y decidida localmente.
La selección de cercanía por consulta acorta la ruta de red
El algoritmo de balanceo de cercanía evalúa cada registro candidato frente a la ubicación de la red solicitante y devuelve el centro de datos más próximo. Como una menor distancia geográfica suele significar un menor tiempo de ida y vuelta, los usuarios se mantienen en la ruta viable más corta hacia la aplicación sin ninguna configuración por usuario. La decisión se recalcula en cada consulta en lugar de fijarse en el momento de la configuración.
La proximidad se resuelve combinando datos de país, ciudad y ASN
GTM resuelve la ubicación del solicitante usando bases de datos sin conexión de país, ciudad y ASN. Los datos a nivel de ciudad permiten a la plataforma distinguir entre dos centros de datos dentro del mismo país, y los datos de ASN refinan la decisión según la red a través de la cual está conectado el solicitante. Esto es más granular que el enrutamiento por fronteras nacionales y sigue siendo una consulta local determinista.
EDNS Client Subnet mejora la precisión de la proximidad
Cuando el resolver suministra la subred del cliente, GTM basa la decisión de proximidad en la ubicación de red real del usuario en lugar de la del resolver. Esto importa sobre todo con clientes que usan resolvers públicos distantes, donde una decisión basada solo en el resolver podría enviar a un usuario a un centro de datos cercano al resolver en vez de cercano al usuario. La respuesta más cercana sigue dónde está realmente el usuario.
El filtrado por salud mantiene honesta la proximidad
Los registros candidatos se filtran según la salud del centro de datos antes de aplicar la decisión de cercanía. Un centro de datos no saludable no es elegible como respuesta más próxima, de modo que la plataforma nunca cambia disponibilidad por proximidad. Cuando un centro de datos cercano se recupera, vuelve a entrar en el conjunto de candidatos en la siguiente decisión automáticamente.
La proximidad se combina con reglas de topología
El selector de cercanía puede actuar como selector dentro de un conjunto de reglas de topología, de modo que un operador puede primero acotar los candidatos por red, país, ciudad, continente o ASN y luego elegir la respuesta más próxima entre las coincidencias. Así, las restricciones de cumplimiento o de operador y la dirección por proximidad operan en el mismo flujo de decisión.
Se configura por registro DNS, no globalmente
El algoritmo de balanceo se define en cada registro DNS. El mismo dominio puede responder un registro por proximidad y otro con una estrategia distinta, de modo que la dirección por proximidad se aplica exactamente donde aporta valor y los demás registros conservan su propio comportamiento. Los operadores ajustan el enrutamiento registro por registro.
Decisión en el equipo sin dependencia externa
Tanto la consulta de proximidad como la selección de registros se ejecutan en el equipo. No hay ninguna API de geolocalización externa en la ruta de la petición, lo que elimina una dependencia de disponibilidad de terceros y mantiene el contexto de la consulta DNS dentro de la organización. La decisión de proximidad sigue funcionando incluso cuando la conectividad saliente hacia servicios externos no está disponible.
Profundidad operativa
La dirección por proximidad se opera junto con el conjunto de bases de datos GeoIP, el campo de algoritmo de balanceo, los selectores de topología, el filtrado por salud y la recarga de configuración en vivo.
Conjunto de bases de datos GeoIP
Las decisiones de proximidad se nutren de tres bases de datos sin conexión en el equipo: una base de datos de ASN, una a nivel de ciudad y una a nivel de país. Juntas dan soporte a la proximidad consciente de país, ciudad y ASN. Como los datos son locales, las decisiones en tiempo de ejecución no dependen de un servicio externo; el flujo de actualización de las bases de datos se planifica por separado de la ruta de decisión en vivo.
Campo de algoritmo de balanceo
La proximidad se selecciona estableciendo el algoritmo de balanceo del registro en cercanía, uno de los algoritmos de balanceo de registros DNS disponibles junto a todos, primeros N, round-robin, round-robin ponderado, aleatorio y aleatorio ponderado. El campo se define por registro y los cambios se aplican a través del flujo de configuración.
Composición con el selector de topología
Dentro de un conjunto de reglas de topología, la cercanía puede usarse como selector aplicado a los registros que coinciden con una regla. Esto permite que la proximidad se ejecute después de que una restricción geográfica o de red ya haya acotado los candidatos, combinando el filtrado por política con la selección de la respuesta más próxima en un solo registro.
Candidatos filtrados por salud
El conjunto de candidatos entregado a la decisión de cercanía refleja la salud actual del centro de datos. Los registros de centros de datos no saludables se descartan antes de la selección, de modo que la proximidad se calcula solo sobre los centros de datos que realmente pueden servir tráfico. Este filtrado forma parte del flujo de decisión, no es una regla manual aparte.
Recarga de configuración en vivo
Los cambios en los algoritmos de los registros y en los conjuntos de candidatos entran en el flujo de regeneración de configuración y se aplican sin reiniciar el servicio. Las nuevas consultas reciben respuestas que reflejan la configuración actual; las respuestas ya cacheadas por los clientes viven hasta que expira su TTL, por lo que TTL más bajos hacen que los cambios de proximidad y salud surtan efecto más rápido.
Proximidad frente a señales de red en vivo
El selector de cercanía decide según la proximidad geográfica, que sirve como sustituto de la latencia en lugar de una medición en vivo de ella. Cuando una decisión debe reflejar la ruta de red en tiempo real o la carga del centro de datos, la selección de DC multifuente aporta señales en vivo de host, servicio y ruta del cliente que complementan la dirección por proximidad geográfica.
Cuándo utilizarlo
Dirigir a usuarios globales a la región más cercana
Para servicios con usuarios repartidos entre regiones, el selector de cercanía responde cada consulta con el centro de datos geográficamente más próximo, acortando la ruta de red y reduciendo el tiempo de ida y vuelta sin reglas por usuario.
Elegir entre dos centros de datos en un mismo país
Cuando un país aloja más de un centro de datos, la proximidad a nivel de ciudad distingue cuál está más cerca del solicitante, con más finura que una regla basada solo en el país que trataría ambos como equivalentes.
Dirección por proximidad con residencia de datos
Como la consulta de geolocalización se ejecuta sobre bases de datos sin conexión en el equipo, las organizaciones con obligaciones de residencia de datos o de privacidad de consultas obtienen un enrutamiento por proximidad sin enviar el contexto de la consulta DNS a un proveedor de geolocalización externo.
Proximidad dentro de una política de topología
Acote primero los candidatos por país, ASN o CIDR por motivos de cumplimiento o de operador y luego deje que el selector de cercanía elija la respuesta más próxima entre los centros de datos permitidos: política y proximidad en un solo registro.
Preguntas frecuentes
¿TR7 GTM mide la latencia en vivo desde el resolver hasta cada centro de datos?
¿Cómo se determina la ubicación del solicitante?
¿Por qué usar EDNS Client Subnet con el enrutamiento por proximidad?
¿Qué impide que una consulta se dirija al centro de datos más cercano mientras este está caído?
¿Puede combinarse el enrutamiento por proximidad con reglas de país o ASN?
¿El enrutamiento por proximidad se aplica a toda la zona o por registro?
Mantenga a cada usuario en la ruta más corta hacia un centro de datos saludable
Dirección DNS por proximidad decidida en sus propios equipos: GeoIP sin conexión, conciencia de la subred del cliente y filtrado por salud. Recorrámosla sobre su propia topología.