Solución

Elija el algoritmo correcto para cada carga de trabajo

Del round-robin clásico al Maglev hashing y el motor propietario Fastest+ en dos etapas de TR7 — 14 algoritmos incluidos

Diferentes cargas de trabajo merecen lógicas de enrutamiento distintas. ¿Un vService uniforme con servidores web idénticos? Round-robin. ¿Sesiones de larga duración donde la capacidad es determinante? Least-connections. ¿Escenarios de afinidad de caché? Consistent hash o Maglev. ¿Hardware heterogéneo o carga variable? Fastest+. TR7 ADC incluye cada algoritmo estándar — más tres variantes modernas de hash y un motor propietario — elegidos por vService, cambiados sin reinicio.

criterios de selección en Layer 7

planificadores en Layer 4

por vService

Elección de algoritmo — cambia en vivo sin reinicio

Por qué los patrones de tráfico exigen algoritmos diferentes

Cada algoritmo clásico se basa en una suposición sobre el vService al que sirve. Round-robin asume que los backends son intercambiables. Least-connections asume que el número de sesiones se correlaciona con la carga del backend. Source-IP asume stickiness usuario-backend sin persistencia explícita. Los hashes de afinidad de caché asumen que la clave de solicitud — URL, cabecera o sesión — es estable. Cuando la suposición es válida, el algoritmo es la respuesta correcta.

Los casos más difíciles son aquellos en los que esas suposiciones dejan de cumplirse: los backends derivan en rendimiento durante la jornada laboral, las generaciones de hardware se mezclan durante una actualización progresiva, la latencia regional varía solicitud a solicitud, o la propia carga de trabajo tiene ráfagas de consultas pesadas que no coinciden con el recuento bruto de solicitudes. En esos escenarios, elegir el backend realmente más rápido por solicitud — o usar un algoritmo hash diseñado para absorber cambios en los backends sin repartir todo de nuevo — es lo que preserva la latencia visible al usuario.

La respuesta correcta es hacer coincidir el algoritmo con la carga de trabajo — por vService, no de forma global.

Elección de algoritmo, por vService

Un vService en TR7 envuelve el listener del frontend, las reglas de tráfico, las comprobaciones de estado y el grupo de backends en un solo objeto de configuración — más amplio que el concepto clásico de pool que divide estos elementos en lugares separados. Cada vService elige su propio algoritmo en un menú desplegable — sin recompilación, sin reinicio. Combine como desee en una sola instancia de TR7: round-robin en el vService de activos estáticos, Fastest+ en el vService de API, Maglev hash en el vService de la capa de caché. El filtrado por tipo de servicio ocurre automáticamente; la interfaz solo muestra los algoritmos válidos para el protocolo del vService.

Algoritmo por vService

La elección del algoritmo vive en el objeto vService, no en la configuración global del ADC. Diferentes vServices ejecutan diferentes algoritmos en la misma instancia de TR7.

Filtrado por protocolo

La interfaz muestra solo los algoritmos que tienen sentido para el protocolo del vService — los vServices HTTP, TCP o de capa de red reciben cada uno el subconjunto relevante, sin necesidad de que el operador adivine.

Combinable con persistencia de sesión

El algoritmo selecciona el backend para la primera solicitud; la persistencia de sesión luego fija las solicitudes posteriores del mismo usuario. Ambas capas son configurables de forma independiente por vService.

Hot-swap (sin reinicio)

Cambie el algoritmo en un vService activo y el tráfico se desplaza inmediatamente a la nueva lógica. No se requiere reinicio del servicio ni drenado de conexiones.

14 algoritmos incluidos con TR7 ADC

Cada algoritmo clásico, dos variantes modernas de consistent hash, un algoritmo de menor retardo, más el motor propietario Fastest+ de TR7. Todos disponibles por vService — seleccione en un desplegable, sin código de configuración.

Round-robin (ponderado + estático)

Distribución uniforme entre el vService, ponderada o no. El estándar predeterminado para vServices uniformes donde todos los backends tienen capacidad idéntica.

Least-connections (ponderado)

Enruta al backend con el menor número de conexiones abiertas actualmente. Muy efectivo para sesiones de larga duración donde el número de sesiones se correlaciona con la carga del backend. La variante ponderada tiene en cuenta las diferencias de capacidad.

Menor tiempo de respuesta

Enruta al backend que responde más rápido en este momento, medido de forma continua y no por muestreo. Adecuado para pools con capacidad igual pero latencia variable por nodo: una caché calentándose, un nodo bajo presión de GC, un vecino ruidoso.

Menor ancho de banda

Enruta al backend que menos tráfico mueve en ese momento. Es el criterio correcto cuando las respuestas difieren en tamaño y no en número — medios, descargas de archivos, exportación de informes —, donde el número de conexiones no dice nada sobre la carga real.

First-available

Siempre enruta al primer backend listado con capacidad disponible; pasa al siguiente solo cuando está sobrecargado. Útil para ordenación de backends caliente-frío o despliegues escalonados.

Random

Selección aleatoria entre backends saludables. Sin estado, estadísticamente uniforme — útil cuando el vService es grande y homogéneo. Admite random de potencia de dos para selección del menos cargado con baja sobrecarga.

Source-IP hash

La misma IP de cliente siempre enruta al mismo backend. Útil para flujos con estado cuando la aplicación no gestiona persistencia de sesión explícita.

URL hash (URI / URL-parameter)

Hash sobre un componente de URL — la longitud de URL, la ruta URI, o un parámetro de consulta específico (p. ej. ?user_id). Enruta la misma URL o usuario al mismo backend para afinidad de caché.

Header hash

Hash sobre una cabecera HTTP personalizada. Útil para enrutamiento multi-tenant (cabecera tenant-id), feature flagging o escenarios de A/B testing.

RDP cookie hash

Lee la cookie de sesión RDP para la selección de backend. Útil para gateways RDP y granjas de escritorio remoto donde se requiere afinidad de sesión.

Consistent hash

Modo de hash moderno que minimiza la disrupción cuando los backends se unen o abandonan el vService — solo una pequeña fracción de claves se redistribuye, no todo el vService. Indicado para capas de caché donde la rotación de backends no debe invalidar toda la caché.

Maglev hash

El algoritmo de consistent hashing de Google diseñado para balanceadores de carga software a escala. Menor varianza que el consistent hash clásico, determinista entre réplicas. Excelente para servicios sin estado que necesitan asignación predecible de backend.

SED — Shortest Expected Delay

Enruta al backend con el menor tiempo de espera esperado, teniendo en cuenta las conexiones activas y el peso por backend. Una alternativa consciente de la latencia frente a least-connections cuando las capacidades de los backends difieren significativamente.

Fastest

Enruta al backend con el menor tiempo de respuesta reciente. Una opción más sencilla consciente de la latencia cuando el tiempo de respuesta es la única señal que importa.

Fastest+

El motor propietario en dos etapas de TR7. El operador elige dos de ocho señales de servicio en vivo — tiempo de respuesta, tiempo de conexión, densidad de cola, tasas de error y más; Fastest+ acota los candidatos según la señal primaria y luego diferencia el empate con la secundaria. Consulte la sección de detalles más abajo.

Fastest+ — El motor en dos etapas, definido por el operador, de TR7

La mayoría de los algoritmos adaptativos observan una sola señal — tiempo de respuesta o número de conexiones. Fastest+ permite al operador elegir dos de ocho señales de servicio en vivo: la señal primaria acota los candidatos a los backends con la mejor puntuación, y la señal secundaria diferencia el empate entre ellos. Los backends en modo de mantenimiento o con un estado de salud no apto quedan fuera automáticamente, y existe un modo de señal única para cuando un solo criterio es suficiente. Estas son las ocho señales entre las que puede elegir:

Tiempo de respuesta

Latencia media de respuesta del backend, muestreada continuamente. La señal principal — un backend que tarda más en responder baja inmediatamente en el ranking.

Tiempo de conexión

Cuánto tarda en establecerse una conexión TCP/TLS. Un backend cuyo tiempo de conexión crece se está acercando a la saturación, incluso si su tiempo de respuesta todavía parece bien.

Tiempo de cola

Tiempo que las solicitudes pasan en cola antes de llegar al backend. Un tiempo de cola creciente es la advertencia más temprana de que un backend no puede mantener el ritmo.

Sesiones activas

Sesiones actualmente abiertas por backend. Enrutamiento consciente de la capacidad sin el ruido de los totales históricos.

Profundidad de cola activa

Solicitudes actualmente en espera. Un backend con 0 en cola se prefiere frente a uno igual de rápido con 50 en espera.

Errores de conexión

Conexiones fallidas recientes. Un backend que rechazó 3 de los últimos 10 intentos baja en el ranking antes de que una comprobación de estado lo detecte.

Cancelaciones del lado del servidor

Cancelaciones de sesión iniciadas por el backend en la ventana reciente. Captura el caso en que un backend está vivo pero falla a mitad de la operación.

Conexiones utilizadas

Utilización del pool de conexiones — qué tan cerca de su capacidad está el pool keep-alive de cada backend. Detecta el agotamiento del pool antes de que sea visible para el usuario.

DOS CAPAS, UNA POLÍTICA

Catorce en Layer 7, once a nivel de paquete

En Layer 7 la decisión se toma leyendo la petición: cabecera, ruta, cookie, tiempo de respuesta en vivo. En Layer 4 se toma sobre el paquete, antes de que el tráfico llegue a la capa de aplicación: ahí está el mayor rendimiento. En ambos casos el algoritmo se elige por servicio y cambia con el equipo en marcha.

Layer 7 — 14 criterios de selección

Round robin — por turnos, ponderado o estrictamente igual

Round robin ponderado — se respetan las diferencias de capacidad

Menos conexiones — gana el que tiene menos conexiones abiertas

Menor tiempo de respuesta — el backend que responde más rápido ahora

Menor ancho de banda — el backend que menos tráfico mueve ahora

Primero disponible — llenar un backend antes de tocar el siguiente

Aleatorio — estadísticamente plano, sin estado

Fastest — una señal en vivo, gana el valor más bajo

Fastest+ — dos señales: la primera acota, la segunda desempata

IP de origen — mismo cliente, mismo backend

URI — misma ruta, mismo backend; la caché sigue caliente

Parámetro de URL — enrutar por un valor del query string

Cabecera — enrutar por cualquier cabecera, incluida la suya

Cookie RDP — las sesiones de escritorio caen en su broker

Layer 4 — 11 planificadores a nivel de paquete

rr — round robin

wrr — round robin ponderado

lc — menos conexiones

wlc — menos conexiones ponderado

lblc — menos conexiones por localidad

lblcr — lo mismo con replicación

sh — hash de origen

dh — hash de destino

sed — menor retardo esperado

nq — nunca encolar

mh — hash Maglev: mínimo remapeo cuando cambia el pool

Cuándo brilla cada algoritmo

vServices uniformes

Backends idénticos, capacidad idéntica — round-robin mantiene la matemática simple y la carga simétrica. Añada random para vServices grandes y sin estado.

Sesiones de larga duración

WebSockets, servicios de streaming, videollamadas — las sesiones permanecen abiertas durante minutos u horas. Least-connections o SED rastrea la carga activa mucho mejor que el recuento de solicitudes.

vServices de capa de caché

La rotación de backends no debe invalidar toda la caché. Consistent hash o Maglev redistribuye solo una pequeña fracción de claves cuando los backends cambian.

Carga heterogénea o variable

Hardware mixto, despliegues progresivos, varianza de latencia regional — Fastest+ puntúa los backends en vivo para que el enrutamiento elija el realmente más rápido, no el teóricamente mejor.

Preguntas frecuentes

¿Puedo cambiar el algoritmo sin reiniciar el servicio?

Sí. El algoritmo es un desplegable por vService. Cámbielo en un vService activo y el tráfico se desplaza inmediatamente a la nueva lógica — no se requiere reinicio del servicio ni drenado de conexiones.

¿Cómo se relaciona Fastest+ con least-connections?

Least-connections es muy efectivo para muchos vServices — especialmente sesiones de larga duración donde el número de sesiones refleja de cerca la carga del backend. Fastest+ amplía la imagen al permitirle elegir entre ocho señales de servicio en vivo — densidad de cola, tiempo de respuesta reciente, tiempo de conexión, tasas de error y más — y decidir sobre dos de ellas en una selección en dos etapas. Los casos de uso difieren: least-connections suele ser la elección correcta para vServices uniformes con formas de sesión predecibles; Fastest+ brilla cuando el número de sesiones por sí solo no captura qué tan ocupado está realmente un backend — tiempos de consulta variables, generaciones de hardware mixtas o despliegues progresivos.

¿Cuándo debería elegir Consistent hash frente a Maglev hash?

Ambos minimizan la redistribución cuando los backends cambian. Consistent hash es el algoritmo clásico — simple, predecible, bien comprendido. Maglev es la variante de Google construida para balanceadores de carga software a escala — menor varianza en la distribución de carga, determinista entre réplicas. Para la mayoría de las cargas de trabajo, consistent hash es suficiente; elija Maglev cuando necesite uniformidad de carga estricta o cuando ejecute múltiples instancias de TR7 que deben acordar el enrutamiento.

¿Qué hace SED que least-connections no hace?

SED (Shortest Expected Delay) tiene en cuenta tanto las conexiones activas como el peso por backend para estimar qué backend responderá más rápido a la siguiente solicitud. Es un refinamiento de weighted least-connections — útil cuando las capacidades de los backends difieren significativamente y se desea que el enrutamiento lo tenga en cuenta sin la complejidad completa de Fastest+.

¿La elección de algoritmo requiere monitoreo externo o integración APM?

No. Todas las señales — incluida cada entrada de Fastest+ — son medidas por TR7 a partir del tráfico que ya está enviando como proxy. Sin agente, sin hook APM, sin pipeline de métricas externo.

¿Cuál es el algoritmo predeterminado?

Round-robin es el predeterminado por compatibilidad con despliegues existentes. Cambiar a un algoritmo diferente es un cambio de un solo desplegable en la configuración del vService.

Haga coincidir el algoritmo con la carga de trabajo

Vea cómo TR7 ADC le permite configurar el algoritmo por vService — y cómo Fastest+ gestiona las cargas de trabajo que los demás no pueden.