El round-robin DNS clásico distribuye las direcciones IP bajo el mismo registro aproximadamente por igual. Ese modelo puede ser adecuado para un reparto de carga simple, pero no proporciona el control requerido para los despliegues de nuevas releases, pruebas A/B, cutovers blue/green o migraciones de centro de datos. Los equipos de operaciones suelen querer enviar solo el 5 % del tráfico a un nuevo destino y dejar el resto en el sistema existente.
Sin pesado a nivel DNS, la división de tráfico debe resolverse en el nivel de aplicación o en una capa separada de traffic splitting. Eso significa arquitectura adicional, monitorización adicional, gestión de certificados adicional y puntos de fallo adicionales. Cuando la decisión puede tomarse en la respuesta DNS, el cliente es dirigido al destino correcto desde la primerísima consulta.
Los escenarios de mantenimiento y drain también son toscos cuando se gestionan borrando registros. Eliminar una IP de un registro DNS es eficaz para las nuevas consultas, pero no aborda la necesidad de reducir gradualmente la cuota de tráfico o retirar un destino de rotación de forma controlada. También debe tenerse en cuenta el comportamiento de la caché del cliente y de los resolvers intermedios sobre la ventana del TTL.
El modelo correcto es asignar un peso separado a cada registro DNS y elegir el algoritmo para el escenario. Weighted round-robin se adapta a una distribución balanceada y ordenada; weighted random proporciona selección estadística basada en porcentaje. Un peso de 0 coloca al destino en modo drain efectivo, retirándolo de las nuevas respuestas DNS.
TR7 Weighted DNS entrega distribución de tráfico controlada en la capa DNS mediante pesos por registro, weighted round-robin, weighted random, recarga de configuración en vivo y comportamiento de drain con peso=0.
TR7 saca la respuesta DNS de una lista estática de registros y la convierte en una decisión de distribución de tráfico gobernada por valores de peso y algoritmos seleccionables.
Se define un peso entero para cada IP o miembro de registro. El algoritmo weighted round-robin usa estos pesos para distribuir las respuestas DNS proporcionalmente entre el pool.
El algoritmo weighted random realiza una selección aleatoria proporcional al peso en cada consulta. Con volúmenes altos de consultas, la distribución de tráfico observada converge hacia las proporciones de peso definidas.
Los cambios de peso entran en el pipeline de recarga de configuración en vivo y las nuevas consultas reciben inmediatamente la distribución actualizada. Como las respuestas previamente cacheadas viven hasta que su TTL expire, la planificación del TTL es esencial en escenarios de transición rápida.
Cuando el peso de un registro se pone a 0, se retira de la lista de candidatos activos. Este comportamiento proporciona un drain controlado para mantenimiento, rollback o decomisionado de un centro de datos.
Weighted DNS gestiona los valores de peso por registro junto con la selección de algoritmo, las actualizaciones en vivo, la integración con topología y los escenarios de mantenimiento.
En TR7, cada miembro de registro puede tener su propio valor de peso. Este valor determina su cuota relativa en la distribución de tráfico — pesos de 5 y 2 apuntan a una proporción aproximada de 5:2. Si se proporciona un float, se redondea a entero antes de su uso. El modelo hace sencillo dar a destinos de mayor capacidad una cuota mayor y a los destinos de prueba una menor.
Weighted round-robin selecciona los registros en rotación según sus proporciones de peso. Es la opción preferida cuando se espera una distribución balanceada y el uso secuencial de los registros es aceptable. Es un algoritmo práctico para canary releases, despliegues graduales y reparto de tráfico proporcional a la capacidad. Los operadores reconfiguran la distribución simplemente cambiando los valores de peso.
Weighted random produce una selección aleatoria proporcional al peso en cada consulta DNS. Pueden aparecer pequeñas desviaciones en ventanas cortas de tiempo; con volúmenes altos de consultas la distribución converge hacia las proporciones definidas. Está bien adaptado para pruebas A/B y routing de tráfico experimental. Los nuevos destinos con un peso bajo pueden probarse con seguridad dentro del mismo pool de registros.
Cuando cambian los valores de peso, la configuración del GTM entra en el proceso de recarga en vivo. Un mecanismo de debounce coalesce los cambios sucesivos rápidos, reduciendo re-renders innecesarios; la latencia típica de la recarga en vivo es de unos 3 segundos. Las nuevas consultas DNS reciben la distribución de peso actualizada. Las respuestas previamente cacheadas en cachés de cliente y resolver permanecen hasta que su TTL expire.
Cuando cambia un peso DNS, el sistema actualiza las nuevas respuestas inmediatamente; sin embargo, las respuestas DNS ya emitidas viven en las cachés intermedias hasta que su TTL expire. Para escenarios canary, blue/green o de rollback rápido, el TTL debería mantenerse bajo. Valores en el rango de 5-60 segundos permiten que las transiciones surtan efecto más rápidamente. Un TTL más alto es apropiado durante periodos operativos estables.
Cuando el peso de una IP o miembro de registro llega a 0, ese destino se retira de las nuevas respuestas DNS. Esto hace posible drenar un registro para mantenimiento sin borrarlo. Las respuestas cacheadas existentes siguen usando la respuesta antigua hasta que su TTL expire; las nuevas consultas ya no reciben el destino. Es un método controlado y reversible para mantenimiento, rollback o decomisionado de centro de datos.
En TR7, la distribución no se confina a un único nivel de IP — la lógica de peso de grupo de centro de datos y de miembro de registro pueden trabajar combinadas. Primero se selecciona el centro de datos o grupo candidato adecuado; los registros dentro de ese grupo se distribuyen luego por peso. Este modelo ayuda a tener en cuenta capacidad y ubicación en la gestión global de tráfico. En despliegues grandes, la distribución se vuelve más en capas y manejable.
Cuando se usa selección basada en geo o topología, primero se identifica el grupo candidato apropiado. La distribución de peso se aplica luego dentro de ese conjunto de candidatos. Los usuarios europeos, por ejemplo, son dirigidos al grupo de centros de datos europeo, mientras que las IPs dentro de ese grupo se ponderan. La decisión de topología y la de peso se aplican secuencialmente sin interferir entre sí.
Los registros que no requieren distribución ponderada pueden usar selección round-robin o random clásicas. Round-robin distribuye los registros por igual; random selecciona al azar. Estos algoritmos son suficientes para escenarios simples y se gestionan a través del mismo modelo de registro, así que cambiar a algoritmos ponderados no requiere cambios estructurales. Los operadores eligen el comportamiento de distribución adecuado para cada registro DNS.
El algoritmo closest está disponible para registros A y AAAA que requieren selección por proximidad de IP. A diferencia de la distribución ponderada, se centra en seleccionar el destino más cercano o adecuado para el cliente. Topología, closest y peso pueden servir como capas de decisión distintas en la gestión global de tráfico. El resultado es una respuesta DNS consciente del contexto en lugar de meramente aleatoria.
Weighted DNS se opera junto con el formato del peso, la selección de algoritmo, la latencia de recarga en vivo, el impacto del TTL y el comportamiento de selección de registros.
El peso se define como un número y se usa como entero. Si se proporciona un float se redondea. Las proporciones de peso representan cuotas relativas entre registros, no porcentajes absolutos.
Los algoritmos weighted round-robin y weighted random usan la lista de registros junto con un mapa de pesos. Se generan valores de peso indexados para cada registro. Esta estructura es evaluada por la función selector durante la generación de la respuesta DNS.
Los cambios de configuración pasan por un proceso de recarga en vivo con debounce. El valor típico de debounce es de 3 segundos; puede aplicarse un límite de espera máximo durante ráfagas de cambios sucesivos rápidos. Este comportamiento reduce operaciones de re-render frecuentes innecesarias.
Un cambio de peso surte efecto en las nuevas consultas DNS. Los clientes o resolvers que ya recibieron una respuesta anterior siguen usando el registro cacheado hasta que su TTL expire. Por esta razón, el TTL es un parámetro operativo tan importante como el peso al planificar transiciones.
El peso 0 se usa para retirar un registro de la lista de candidatos activos. Esto hace posible realizar mantenimiento o migración sin borrar el registro por completo. Para restablecer el registro, vuelva a poner el peso en un valor positivo.
En ciertos escenarios, puede proporcionarse un número en lugar de un algoritmo para seleccionar los primeros N registros de la lista de candidatos. Este comportamiento es útil para limitación simple y determinista de registros. Es una opción práctica para casos especiales donde no se requiere distribución ponderada.
La IP de la nueva release recibe un peso bajo; la release actual recibe uno alto. La nueva versión empieza con aproximadamente el 5 % del tráfico; según las métricas se ven sanas, el peso se eleva incrementalmente. Si aparece un problema, la nueva release se drena poniendo su peso a 0.
Mientras el entorno blue está activo, el entorno green se prueba con un peso bajo. En el cutover, el peso de blue se reduce a 0 y green se convierte en el único destino activo. Cuando se necesita un rollback, los pesos se invierten para volver al entorno anterior.
Se definen dos landing pages o dos variantes de servicio con registros de IP separados. Los pesos pueden ponerse 1:1 para una prueba igualitaria o 9:1 para un experimento limitado. Basándose en el análisis de resultados, la proporción de tráfico se ajusta en el nivel DNS.
El centro de datos antiguo empieza con un peso alto; el nuevo se introduce con un peso bajo. El equipo de operaciones desplaza el tráfico al nuevo centro mediante una reducción escalonada como 100 → 80 → 50 → 20 → 0. Cuando el TTL se mantiene bajo, el impacto de cada paso se observa más rápidamente.
Los backends de mayor capacidad reciben un peso mayor; los recursos más limitados reciben uno menor. La distribución de tráfico se vuelve proporcional a la capacidad del servidor. Los operadores reconfiguran la distribución solo actualizando los valores de peso.
El peso del backend que entra en mantenimiento se reduce a 0. Las nuevas consultas DNS ya no se enrutan a ese destino; las respuestas previamente cacheadas se siguen usando hasta que su TTL expire. Cuando el mantenimiento termina, el peso se restaura a un valor positivo y el backend vuelve a servicio.
Pesos por registro y recarga en vivo para canary releases, cutovers blue/green, pruebas A/B y migraciones de centro de datos. Hagamos un recorrido en vivo en su entorno.