La mayoría de las implementaciones GSLB toman las decisiones de selección de centro de datos a partir de una sola clase de señal. La distancia geográfica es una elección común; el tiempo de ida y vuelta desde los puntos de medida de la plataforma es otra; las búsquedas de topología estática son una tercera. Cada una captura una dimensión útil y pierde las demás.
La geografía ignora la carga — el centro de datos más cercano puede ser también el que esté actualmente bajo presión de capacidad. La latencia desde las sondas del GSLB ignora al usuario — el camino real de red del usuario no es el camino que recorrió la sonda. La topología estática asume que la red no ha cambiado desde que se escribió la configuración.
Las decisiones de producción necesitan las tres vistas a la vez: ¿está la plataforma del DC sana? ¿La aplicación en el DC está actualmente rindiendo? ¿La red desde el usuario hasta el DC es realmente buena en este momento? Cada vista tiene señales que las otras no pueden sustituir.
TR7 GTM expone las tres clases de señales — host, servicio, cliente — como entradas independientes a la selección de DC, permitiendo a los operadores describir la política que de verdad se ajusta a su carga de trabajo.
La selección de DC se configura por registro DNS. Los operadores eligen qué fuente de señal usar, qué métrica concreta dentro de esa fuente, cuántos DCs seleccionar y cómo distribuir entre los seleccionados.
Cinco métricas medidas en la plataforma del DC: CPU, memoria, ancho de banda, estado (composite up/down) y pérdida de paquetes. Útil cuando la presión sobre la plataforma del DC es la señal dominante para las decisiones de routing.
Ocho métricas medidas por servicio: CPU, memoria, ancho de banda, tasa de peticiones, conteo de conexiones, tasa de nuevas sesiones, estado y healthyBackends. Dirige el tráfico según lo que la aplicación está haciendo realmente, no solo según si el host está up.
Cuatro métricas medidas desde el camino de red hasta el cliente que solicita: saltos, MOS (Mean Opinion Score), pérdida de paquetes y TTL. Captura la experiencia del lado del usuario que las sondas en el lado del DC no pueden ver.
`pickDcCount` elige cuántos DCs devolver. `balanceAlgorithm` distribuye entre los seleccionados — all, top-N, round-robin, weighted round-robin, random, weighted random o closest.
Cada registro DNS en modo DC selecciona de forma independiente su fuente de señal, su criterio y su comportamiento de distribución.
La fuente de host del DC expone cpu, mem, bw, status y packetLoss. Status es el estado compuesto de alcanzabilidad/salud calculado a partir de los puntos de acceso WAN y LAN del DC. Útil cuando la capacidad a nivel de host es la señal dominante de routing.
La fuente de servicio expone cpu, mem, bw, request, connection, session_new, status y healthyBackends. El contador de healthyBackends es especialmente relevante — dirige el tráfico al DC donde la aplicación tiene ahora mismo la mayor capacidad operativa, no solo al DC cuya plataforma está up.
La fuente de cliente expone hops (longitud del camino), mos (Mean Opinion Score para calidad de tráfico VoIP/tiempo real), packetLoss y ttl. Estas señales se miden frente a la red del cliente, capturando la experiencia de usuario que las sondas del lado del DC no ven.
El modo estático omite la selección multi-fuente y asigna DCs según reglas definidas por el operador. Útil para registros DNS heredados, routing por cumplimiento (DCs concretos para clientes concretos) y pruebas.
El criterio de selección lo controla el operador: gana el valor más bajo, gana el más alto, el valor iguala al objetivo o el valor difiere en cierto margen. El mismo DSL gobierna la evaluación de criterio en las tres fuentes de señal.
`pickDcCount` está por defecto en 1 pero puede ajustarse a más para devolver varios DCs en la respuesta DNS. Esto habilita verdadero balanceo de carga multi-DC en lugar del routing pick-one — los clientes DNS reciben varias respuestas y el resolver o stub del lado del cliente elige entre ellas.
Una vez seleccionados los DCs, los registros dentro de cada DC se distribuyen según `balanceAlgorithm`: all (devolver cada registro), top-1/2/3 (devolver los N primeros), round-robin, weighted round-robin, random, weighted random o closest (proximidad al solicitante). El algoritmo correcto depende de si se busca distribución amplia, concentración en top-N o pegajosidad.
Al usar la fuente de servicio, los operadores especifican el nombre del servicio — aplicaciones distintas corriendo en la misma flota de DCs pueden tener reglas de routing distintas. El conteo de healthyBackends para el servicio A y el servicio B puede gobernar elecciones de DC independientes.
Si la selección no devuelve ningún DC sano, la lista fail-safe del registro proporciona respuestas de último recurso — IPs definidas por el operador que siempre se devuelven cuando todas las señales multi-fuente fallan. Evita que la respuesta final sea NXDOMAIN.
La selección de DC se configura por registro DNS. El mismo dominio puede tener un registro A enrutado por service.healthyBackends, un registro MX enrutado por host.status y un CNAME enrutado por client.packetLoss. Los operadores ajustan cada registro a su carga de trabajo.
La selección multi-fuente trabaja junto con las definiciones de DC, los escenarios de health-check, los algoritmos DNS ponderados y los registros fail-safe.
Cada fuente de señal tiene su propia cadencia de medida. Las métricas de host y servicio se refrescan en el ciclo de recolección de métricas del GTM (típicamente cada 30-60 segundos). Las métricas de cliente se actualizan por sesión de resolver. Los operadores ajustan la cadencia por fuente según la topología de DC.
La selección usa una fuente por registro a la vez. Cuando los operadores quieren que las señales de host condicionen a las de servicio ("solo considerar métricas de servicio si el host está sano"), vinculan un escenario basado en host a un registro de fuente de servicio. La estratificación es explícita.
El conteo healthyBackends se lee directamente del nivel de balanceo de carga de la aplicación en cada DC, no se aproxima con sondas externas. El número refleja el pool real de backends sanos detrás del servicio en ese momento.
MOS se calcula a partir de medidas de calidad de red (jitter, pérdida de paquetes, latencia) frente a la red del cliente que solicita. Es más preciso para sesiones de cliente en curso y converge en pocas ventanas de medida para clientes nuevos.
Si `pickDcCount` es mayor que el número de DCs sanos disponibles, se devuelven todos los DCs sanos disponibles. La plataforma nunca inventa DCs ficticios para alcanzar el objetivo — los operadores ven exactamente qué DCs reales eran elegibles.
Selección y distribución se componen: la selección elige los DCs elegibles por criterio; la distribución determina cómo se devuelven los registros dentro de cada DC. Un registro puede elegir 3 DCs por service.healthyBackends y luego devolver los registros dentro de cada DC mediante weighted random.
La fuente de servicio con criterio healthyBackends dirige el tráfico al DC donde la aplicación tiene la mayor capacidad operativa. Evita sobrecargar un DC cuyo host está up pero cuyos backends de aplicación están degradados.
La fuente de cliente con criterio packetLoss dirige a cada usuario al DC con el camino de red más limpio desde su red. Útil para VoIP, vídeo, gaming y aplicaciones en tiempo real donde la calidad del camino importa más que la proximidad geográfica.
Combine pick-N (por ejemplo, devolver los 3 mejores DCs) con distribución weighted random para repartir tráfico entre varias regiones sanas. Cada cliente DNS recibe varias opciones; los resolvers y stubs distribuyen de forma natural entre ellas.
Use un escenario basado en host como filtro ("el DC tiene plataforma sana") y un criterio basado en servicio como selector ("el DC tiene el mayor healthyBackends entre los DCs filtrados"). Las cargas críticas obtienen una selección en dos capas sin scripting.
Pruebe la selección multi-fuente de DC sobre su propia topología: métricas de host, métricas de servicio y medidas de red del lado del cliente impulsando la misma decisión de routing.