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.
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.
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.
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.
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.
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.
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.
Distribución uniforme entre el vService, ponderada o no. El estándar predeterminado para vServices uniformes donde todos los backends tienen capacidad idéntica.
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.
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.
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.
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.
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é.
Hash sobre una cabecera HTTP personalizada. Útil para enrutamiento multi-tenant (cabecera tenant-id), feature flagging o escenarios de A/B testing.
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.
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é.
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.
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.
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.
El motor adaptativo propietario de 8 señales de TR7. Combina tiempo de respuesta, tiempo de conexión, profundidad de cola, sesiones activas, tasas de error y más en una puntuación de rapidez por solicitud. Consulte la sección de detalles más abajo.
La mayoría de los algoritmos adaptativos observan una sola señal — tiempo de respuesta o número de conexiones. Fastest+ muestrea continuamente 8 señales de rendimiento independientes por backend y las combina en una única puntuación de rapidez, calculada de nuevo para cada solicitud entrante.
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.
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 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 actualmente abiertas por backend. Enrutamiento consciente de la capacidad sin el ruido de los totales históricos.
Solicitudes actualmente en espera. Un backend con 0 en cola se prefiere frente a uno igual de rápido con 50 en espera.
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 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.
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.
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.
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.
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.
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.
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.