La alta disponibilidad no es solo añadir un segundo dispositivo — es asegurarse de que el VIP correcto permanezca en el nodo correcto.
Tener un segundo dispositivo en una capa ADC no significa por sí mismo alta disponibilidad. Las preguntas críticas son qué nodo posee el VIP durante un fallo, si ambos nodos comparten la misma configuración, y si las stick tables y los contadores de seguridad sobreviven a un failover. Cuando estas piezas no funcionan juntas, el failover ocurre — pero la experiencia del usuario y el comportamiento de seguridad se rompen.
El VRRP clásico es suficiente para la mayoría de los escenarios, pero no resuelve todos los problemas. Un nodo puede parecer estar funcionando, un par VRRP puede seguir activo, pero la interfaz relevante puede haber perdido su enlace o el gateway puede haberse vuelto inaccesible. Si el dispositivo continúa manteniendo el VIP en ese estado, el tráfico fluye a un nodo que parece activo pero no puede llegar al mundo exterior.
En despliegues gestionados manualmente, la sincronización de configuración es un riesgo separado. Si un cambio realizado en un nodo se llevó al otro, si los conjuntos de certificados y reglas son iguales, o qué dispositivo conservó los logs — todo esto requiere comprobación constante. Si no hay una respuesta clara a "¿son los dos nodos verdaderamente idénticos?", el clúster no es una construcción fiable sino un punto de fallo diferido.
La discordancia de hardware es uno de los fallos silenciosos más peligrosos. Un nodo renovado con un nombre de interfaz de red diferente, un conjunto de núcleos de CPU diferente o una capacidad de memoria diferente puede romper el comportamiento del clúster en el peor momento posible. Estas diferencias deben detectarse en el momento de unirse al clúster, no durante un evento de failover.
HA Clustering de TR7 aborda todos estos riesgos juntos: failover de VIP, decisiones de enlace/gateway controladas por TR7, sincronización, flujo de trabajo de mantenimiento controlado y comprobaciones de compatibilidad de hardware — todo gestionado en un modelo.
Nuestro enfoque
TR7 implementa el clustering de dos nodos con un plano VIP, monitoreo activo, sincronización, validación de hardware y gestión controlada de cambios trabajando juntos.
Dos nodos se gestionan como un único ADC lógico
La configuración del clúster se define con una topología compartida entre ambos nodos. La interfaz de gestión muestra este nodo y el nodo par en el mismo modelo; los cambios de reglas, certificados y servicios se gestionan teniendo en cuenta el comportamiento del clúster.
El failover de VIP se determina por VRRP y las opciones de monitoreo de TR7
La propiedad del VIP puede gestionarse con VRRP clásico o complementarse con las decisiones de monitoreo de enlace, gateway o enlace+gateway de TR7. Esto permite el failover basado en la accesibilidad real de la red en lugar de solo en la disponibilidad del par.
La compatibilidad de hardware se valida al unirse al clúster
La lista de núcleos de CPU, los nombres de interfaces de red y el tamaño de la memoria se comparan entre ambos nodos. Las discordancias de hardware se detectan cuando un nodo se une al clúster — no se dejan para que afloren durante un evento de failover.
El modo de sincronización manual permite cambios de mantenimiento controlados
La sincronización automática puede pausarse temporalmente. El operador realiza un cambio en un nodo, prueba el resultado y, una vez verificado, envía deliberadamente todos los cambios al nodo par.
Capacidades
HA Clustering gestiona el comportamiento de alta disponibilidad local — desde la propiedad del VIP hasta la replicación de estado — en una única interfaz.
El failover de VIP basado en VRRP mantiene estables las direcciones de servicio
TR7 usa un modelo VRRP para gestionar qué nodo mantiene cada dirección VIP. El comportamiento MASTER y BACKUP se genera automáticamente para cada interfaz relevante. Cuando el nodo activo se desconecta, el VIP se mueve al par y el tráfico de usuarios continúa en la misma dirección. Este modelo hace que la infraestructura Linux probada esté disponible a través del modelo de gestión TR7.
El modo de conmutación se elige por servicio, no por equipo
Una pareja de equipos TR7 no tiene por qué tener una única personalidad. Una aplicación sensible a la latencia puede correr en activo-activo sobre ambos nodos mientras la aplicación heredada ligada a licencia que tiene al lado corre en activo-pasivo — mismo clúster, misma consola. Eso es lo que hace llevadera una migración: los servicios pasan a activo-activo de uno en uno, cada uno después de demostrarse, en vez de que todo el parque cambie de comportamiento en una noche y todos se enteren a la vez de si funcionó.
El monitoreo de enlace y gateway cierra los puntos ciegos de VRRP
TR7 no restringe el failover de IP del clúster solo a VRRP; también están disponibles los métodos de enlace, gateway o enlace+gateway. En el modo de enlace, se evalúa el estado del carrier de la interfaz; en el modo de gateway, se comprueba la accesibilidad del upstream. En el modo enlace+gateway, ambas señales se evalúan juntas para una decisión de failover más sólida. Esto ayuda a evitar que un VIP permanezca en un nodo que parece activo pero tiene una ruta de red rota.
Las topologías Active-Passive y Active-Active se ejecutan en el mismo modelo de clúster
En Active-Passive, un nodo lleva los VIPs del servicio mientras el otro espera en espera. En Active-Active, diferentes VIPs pueden distribuirse entre ambos nodos para que ambos dispositivos lleven tráfico en vivo. Cuando un nodo falla, el otro toma la propiedad de sus VIPs. Este enfoque permite que la estrategia de failover y la utilización de la capacidad del dispositivo se moldeen según la preferencia arquitectónica.
Los cambios de configuración y datos se propagan automáticamente al par
Con la sincronización automática habilitada, cada operación de inserción, actualización y eliminación se envía al nodo par. Los operadores no necesitan escribir automatización separada, realizar copias manuales de archivos o programar trabajos de sincronización. Mantener las configuraciones de reglas, certificados y servicios coherentes en ambos nodos se vuelve sencillo. Esto reduce la ambigüedad de "¿es el par verdaderamente el mismo?" en el momento del failover.
Las stick tables y los contadores se preservan mediante la replicación al par
Las stick tables, los contadores de limitación de tasa y el estado de IP de origen pueden replicarse al nodo par. Cuando se produce un failover, el comportamiento del usuario no se reinicia desde cero. Las decisiones de captcha, límite de tasa o enrutamiento de sesión continúan de forma más coherente después de un evento de fallo. Esta función tiene como objetivo no solo la transferencia del VIP sino también la preservación del estado de decisión.
Las discordancias de hardware se detectan de forma temprana al unirse al clúster
El conjunto de núcleos de CPU, las interfaces de red y la RAM de los nodos que se unen al clúster se comparan. Un nombre de interfaz diferente, una NIC faltante o una discordancia de memoria se trata como un error desde el principio. Esto ayuda a evitar que las diferencias silenciosas de hardware afloren durante un failover. Reduce el riesgo operativo particularmente durante los ciclos de actualización de hardware y reemplazo de nodos de repuesto.
El modo de sincronización manual abre un espacio de prueba seguro para el mantenimiento planificado
Cuando se habilita la sincronización manual, se pausa la propagación automática de cambios. El operador puede probar una nueva regla, certificado o comportamiento de servicio en un nodo. Una vez completada la validación, el cambio se envía al par mediante un flujo syncAll o requestSyncAll. Este modelo evita que un cambio incorrecto se propague instantáneamente por todo el clúster.
Las IPs de gestión del clúster se mantienen separadas del tráfico de usuarios
Se asigna una IP de la red de gestión 241.0.1.0/24 para cada ID de clúster. La comunicación intraclúster se separa conceptualmente del tráfico del servicio de usuarios. El valor del ID de clúster se usa en el rango 1-254, con cada ID correspondiendo a una IP de gestión dedicada. Esta separación hace que el tráfico de sincronización y comunicación de pares sea más predecible de gestionar.
Profundidad operacional
El clustering HA se planifica junto con los slots VRRP, la comunicación unicast, los pares de IP de gestión, el diff de configuración, el comportamiento de failback y la integración con GTM.
Gestión de slots VRRP
En escenarios Active-Active, se pueden generar 2 slots VRRP que representan el comportamiento MASTER y BACKUP por interfaz. Los valores de virtual_router_id y priority se establecen según el rol del clúster. Esta estructura permite que la propiedad del VIP dentro de la misma subred se gestione sin conflictos.
VRRP unicast
En las redes de centros de datos modernos, el tráfico VRRP multicast puede ser filtrado por ciertas políticas de switches. TR7 mitiga esto gestionando la información del nodo par a través de un enfoque de par unicast. El tráfico VRRP fluye entonces de forma controlada a través de la IP del nodo par esperado.
Modo de decisión de enlace y gateway
El método de IP del clúster puede establecerse como vrrp, link, gw o link+gw. El método link decide basándose en el estado de la interfaz, gw basándose en la accesibilidad del gateway y link+gw basándose en la combinación de ambas señales. Estas opciones hacen que el comportamiento del VIP sea más realista en diferentes diseños de red.
Par de IP de gestión
La sincronización del clúster se ejecuta sobre un par de IP definido para cada interfaz. Estas IPs se tratan por separado de los VIPs de producción. Esto separa operacionalmente el tráfico de sincronización del tráfico de usuarios.
Comportamiento de failback controlado
El modo nopreempt evita que el VIP regrese automáticamente al antiguo master cuando vuelve en línea. Esto evita el failover tipo ping-pong en escenarios que implican una recuperación temporal seguida de otro fallo. La decisión de failback la toma deliberadamente el operador.
Clúster local e integración con GTM
El clúster local proporciona failover de VIP dentro del mismo centro de datos. Si todo el centro de datos se desconecta, la capa GTM puede redirigir el DNS a un centro de datos remoto. Esto permite que el fallo del nodo local y el fallo del centro de datos se gestionen en dos niveles distintos.
Cuándo utilizarlo
Propiedad ininterrumpida de VIP en aplicaciones financieras
Las instituciones financieras pueden ejecutar VIPs de banca móvil e internet en una configuración de alta disponibilidad en dos nodos TR7 ADC. Cuando un nodo se desconecta por mantenimiento o debido a un fallo, el otro nodo toma la propiedad del VIP y el acceso al servicio continúa en la misma dirección.
Transferencia inteligente de VIP en pérdida de gateway
Los equipos de red pueden garantizar que el VIP se mueva al otro nodo cuando se pierde el acceso al gateway — incluso si el nodo en sí todavía está funcionando. En este escenario, el failover se basa en la accesibilidad real del upstream en lugar de solo en la disponibilidad del dispositivo.
Cambios seguros durante el mantenimiento planificado con sincronización manual
Las agencias gubernamentales u operadores críticos para el negocio pueden habilitar el modo de sincronización manual y probar un cambio en un nodo primero. Después de la validación, el cambio se envía al par, evitando la propagación descontrolada a todo el clúster.
Comprobación de compatibilidad durante la actualización de hardware
Los equipos de operaciones pueden ver las diferencias de CPU, interfaz y memoria en el momento de unirse al clúster al retirar un nodo antiguo y añadir nuevo hardware. Se produce una advertencia antes de que un servidor con especificaciones incorrectas entre en el clúster, reduciendo el riesgo de failover.
Preguntas frecuentes
¿Cuál es la diferencia entre las topologías Active-Active y Active-Passive?
¿Qué puede usarse cuando VRRP solo no es suficiente?
¿Cómo funciona la sincronización de configuración?
¿Se preserva el estado de sesión y límite de tasa durante un failover?
¿Qué sucede al añadir un nuevo nodo de hardware al clúster?
¿Cómo funciona el failover cuando se usa junto con GTM?
Ejecute su clúster ADC en un único modelo de gestión
Failover de VIP VRRP, sincronización de configuración, validación de hardware y flujo de trabajo de mantenimiento controlado — explorémoslo todo juntos en una configuración en vivo.