El tráfico empresarial no se compone solo de aplicaciones HTTP. DNS, SIP, RADIUS, NTP, los servicios TCP en crudo, los protocolos de túnel y los flujos de streaming de alto volumen se comportan de forma distinta. En estos servicios, en lugar del procesamiento de contenido, son más críticos la baja latencia, el bajo consumo de CPU, la decisión rápida y la ruta de retorno correcta.
Cuando el balanceo de carga L4 y L7 se gestiona como productos separados, consolas separadas o niveles de licencia separados, la operación se complica. Un equipo se ve obligado a gestionar un componente de red aparte para los servicios DNS y UDP, un ADC aparte para las aplicaciones web y una capa aparte para la seguridad. En el momento de un problema, hasta la pregunta de qué tráfico pasó por qué producto hace perder tiempo.
El tráfico UDP requiere especial atención. Como el estado de conexión no es tan evidente como en TCP, la persistencia, el comportamiento de la IP de origen, el efecto del NAT y la ruta de respuesta del backend deben diseñarse correctamente. En protocolos como SIP, la sesión debe permanecer en el mismo servicio, mientras que en servicios como DNS y NTP destaca la menor latencia posible.
Modos como direct return e IP tunnel aportan una gran ventaja cuando se configuran correctamente; pero generan problemas si los requisitos de red no se conocen con claridad. En el modo direct routing, los ajustes de VIP loopback alias, comportamiento ARP y ruta de retorno deben hacerse correctamente en los backends. De lo contrario, en lugar de la ganancia de rendimiento, surge un problema de accesibilidad.
Los modos L4 de TR7 reúnen la distribución de tráfico de baja latencia a nivel de kernel, la selección de modo adecuada a las distintas topologías de red y la operación mixta L4+L7 bajo un único modelo de gestión ADC.
TR7 procesa el tráfico L4 a nivel de kernel mientras ofrece de forma centralizada la gestión de modo, algoritmo, health check y servicio mixto.
TR7 aprovecha la infraestructura LVS/IPVS de Linux para el balanceo de carga L4. Este enfoque reduce el coste de procesamiento en el espacio de usuario y permite una decisión rápida en el tráfico TCP y UDP.
Para cada pool de servicio L4 se configuran el protocolo, el algoritmo, la lista de backends, el peso, el límite de conexiones y el health check. La capa de orquestación L4 de TR7 convierte esa configuración en un comportamiento de balanceo L4 ejecutable.
Los modos NAT, SNAT, direct routing, IP tunnel y de reenvío de protocolo genérico sirven a distintas necesidades. El operador elige el modo adecuado según la ruta de retorno del tráfico, la preservación de la IP de origen y la ubicación del backend.
En el mismo TR7, los servicios L7 basados en HTTP/TCP y los servicios L4 basados en IPVS pueden correr lado a lado. Así, sobre una sola VIP, distintos puertos pueden enrutarse a distintos motores de procesamiento.
Los Modos L4 de TR7 ofrecen opciones de balanceo flexibles para distintos protocolos, topologías de red y comportamientos de servicio.
TR7 soporta los modos NAT, SNAT, direct routing, IP tunnel y de reenvío de protocolo genérico. En el modo NAT, el tráfico de retorno pasa a través del balanceador de carga. En el modo direct routing, la ruta de retorno fluye directamente del backend al cliente. El modo IP tunnel puede usarse en escenarios que requieren una ubicación remota o un paso de red distinto.
El pool de servicio L4 puede definirse con el protocolo TCP o UDP. Los servicios UDP como DNS, SIP, RADIUS y NTP pueden balancearse sin forzarlos por el pipeline de procesamiento L7. Los servicios TCP, en cambio, pueden usarse para una distribución de baja latencia basada en puerto. Cada pool funciona de forma sencilla y predecible con una lógica de un solo protocolo.
TR7 soporta los algoritmos round robin, weighted round robin, least connection, weighted least connection, source hash y destination hash. Los algoritmos ponderados pueden usarse para enviar más tráfico a los backends más potentes. Los algoritmos basados en hash facilitan que la misma fuente o el mismo destino se enrute al mismo servicio. Estos algoritmos funcionan en los pools L4 de forma independiente de los algoritmos L7.
Para la persistencia basada en IP de origen puede definirse un valor de timeout. El enfoque por defecto hace que, durante un periodo determinado, la misma fuente se enrute al mismo backend. En el tráfico SIP puede usarse el motor de persistencia basado en call-id. Esta estructura ayuda a evitar la ruptura de los comportamientos de sesión basados en UDP.
Los pools de servicio L4 pueden gestionarse junto con el health check. El mecanismo de health check L4 puede sacar de la distribución los backends que no estén disponibles. Mediante un check basado en HTTP puede monitorizarse la API de gestión o un endpoint de salud personalizado. Así, las decisiones L4 se toman no solo según la definición de puerto, sino según la disponibilidad real del servicio.
Para cada backend puede definirse un valor de weight y, en los algoritmos ponderados, la proporción de tráfico se determina en consecuencia. Con el límite de conexiones puede acotarse la sobrecarga de un solo backend. Esta característica permite un uso más equilibrado en el mismo pool de servicios con distinta capacidad. El equipo de operaciones gestiona de forma más controlada los procesos de añadir servicios y aumentar la capacidad.
El mecanismo de VRRP failover permite que la VIP se traslade entre la pareja HA. Ante la pérdida de un nodo ADC, la VIP puede asumirse en el otro nodo. En los servicios UDP, una breve pérdida de sesión es aceptable en la mayoría de los escenarios, mientras que en los servicios TCP el comportamiento de failover debe evaluarse según la estructura de la aplicación y de la sesión. Este modelo permite vincular los servicios L4 a la arquitectura de alta disponibilidad.
A través de las estadísticas de IPVS pueden monitorizarse las proporciones de conexión, paquete y ancho de banda. Pueden seguirse los valores instantáneos de CPS, la proporción de paquetes de entrada/salida y el ancho de banda de entrada/salida. TR7 puede producir estas estadísticas de forma compatible con la estructura de monitorización de la plataforma. El equipo de operaciones puede ver cómo transportan realmente el tráfico los pools L4.
El modo de protocolo genérico puede usarse en escenarios de reenvío L3 genérico para protocolos distintos de TCP y UDP. En tipos de tráfico como ESP, GRE o ICMP, el modelo L4 clásico basado en puerto puede no bastar. En este modo, las estadísticas de conexión detalladas son limitadas; la visibilidad se proporciona mediante contadores de bytes básicos. Constituye una opción de reenvío práctica para pasos de red especiales.
Con el ajuste de namespace L4, el pool de servicio L4 puede ejecutarse en un contexto de network namespace aparte. Esta estructura es importante para las organizaciones que quieren separar distintos tenants o zonas de red. En el mismo appliance, varios contextos de red pueden gestionarse de forma más controlada. El aislamiento mejora la seguridad operativa en los diseños de despliegue mixto.
Para que los modos L4 funcionen correctamente, el seguimiento de conexiones, el comportamiento de failover, los requisitos de direct routing, los límites de las estadísticas y la gestión del servicio deben planificarse de forma explícita.
El balanceo de carga L4 basado en IPVS es adecuado para los servicios que requieren baja latencia y alto throughput. En el modo direct routing, como el tráfico de retorno se salta el balanceador de carga, aporta ventaja especialmente en los servicios que generan respuestas de alto volumen. La capacidad real depende de la tarjeta de red, la CPU, la selección de modo y la topología del backend.
En los servicios UDP y L4 intensos, el tamaño de la tabla conntrack de Linux se vuelve crítico. Los valores por defecto pueden no bastar para el tráfico a gran escala; deben planificarse según el volumen de tráfico.
La VIP puede trasladarse entre la pareja HA con VRRP. Ante la pérdida de un nodo, el servicio continúa en el otro nodo. Como los servicios UDP suelen ser stateless, se recuperan con más facilidad, mientras que en las sesiones TCP el comportamiento de interrupción debe evaluarse según la tolerancia de la aplicación.
En el modo direct routing, el backend debe reconocer la VIP como loopback alias. Para el comportamiento ARP es importante configurar correctamente los ajustes arp_ignore y arp_announce. Si no se cumplen estos requisitos, en lugar de la ventaja de la ruta de retorno puede surgir un problema de acceso.
En el modo de reenvío de protocolo genérico, los detalles por conexión son limitados. Este modo cubre más bien la necesidad de un reenvío L3 especial y se monitoriza con contadores de bytes básicos. En los servicios que requieren un análisis de conexión profundo, los modos TCP o UDP pueden ser más adecuados.
Las estadísticas de los pools L4 pueden recopilarse y adaptarse al formato general de monitorización de la plataforma. Los valores de conexión, paquete y ancho de banda pueden escribirse en los sistemas de registro histórico. Esto facilita que los servicios L4 se monitoricen en el mismo panel de operación que los servicios L7.
En el tráfico SIP UDP, el uso de NAT puede afectar al comportamiento de la IP de origen y de la ruta de retorno. Si el backend quiere generar la respuesta directamente al cliente, la selección de modo debe hacerse con cuidado. Las opciones de persistencia SIP y direct routing pueden proporcionar un mejor diseño en este tipo de escenarios.
Para cada pool L4 puede monitorizarse el servicio de orquestación L4 asociado. El estado del servicio, el tiempo de actividad y el último cambio de estado son valiosos para la auditoría operativa. Esta información da soporte en los cambios de configuración L4 y en las revisiones de failover.
Una telco o un proveedor de servicios puede balancear varios backends de DNS recursor sobre UDP 53. Al desactivar la persistencia, se logra una distribución DNS de baja latencia y equilibrada.
Una organización puede enrutar el tráfico UDP 1812 y 1813 con el algoritmo source hash para dirigir al mismo cliente al mismo servicio de autenticación. Esta estructura proporciona una selección de servicio consistente en el flujo de autenticación.
En un entorno de telecomunicaciones, el tráfico SIP UDP 5060 puede balancearse con persistencia basada en call-id. Que el mismo flujo de llamada vaya al mismo backend ayuda a preservar el comportamiento de la sesión.
En un escenario de medios o CDN, el tráfico TCP 80/443 puede ejecutarse en modo direct routing. Como el tráfico de retorno fluye directamente del backend al cliente, se reduce la carga de retorno sobre el balanceador de carga.
En los servicios de infraestructura, el tráfico NTP UDP 123 puede distribuirse a los backends de forma equilibrada y de baja latencia con round robin. Para este tipo de tráfico, que no tiene necesidad de persistencia, basta con una definición de pool sencilla.
Sobre la misma VIP, los puertos 80 y 443 pueden enrutarse al motor de procesamiento L7 y el puerto 53 al motor L4 IPVS. Bajo una sola licencia y una sola consola, se logra una optimización aparte para los distintos tipos de tráfico mixto.
Balanceo de carga L4 de baja latencia y basado en modos para servicios como DNS, SIP, RADIUS, NTP y streaming. Le hacemos un recorrido en una instalación en vivo con sus propios servicios.