Un VIP no es solo una dirección IP — debe vivir en la interfaz correcta, en el rol de clúster correcto y con la lógica de failover correcta.
El tráfico de producción generalmente comienza con DNS pero en última instancia fluye a direcciones IP. Cuando la gestión de VIP se trata como nada más que "vincular a una dirección", la topología de red real queda fuera de la imagen. Si VLAN, LACP, Bridge, V-ETH, V-ETH(peer), namespace, IPv6 y el comportamiento de failover del clúster no se consideran juntos, un VIP puede parecer operativo mientras el tráfico no llega por la ruta esperada.
En entornos con múltiples VLANs, el problema se vuelve más aparente. Un operador primero crea la VLAN en el lado de la red, luego ajusta las relaciones Bond o Bridge, y finalmente define el VIP en el ADC. Cuando estas piezas se gestionan de forma aislada, una etiqueta VLAN incorrecta, una discordancia de MTU, una selección incorrecta de interfaz padre o una comprobación de gateway faltante llevan a la clásica situación de "VIP activo pero sin tráfico".
Los enfoques clásicos de transición de VIP también son insuficientes en algunos escenarios. Un nodo puede parecer saludable, la comunicación del par VRRP puede continuar, pero el enlace relevante puede haber caído o el gateway puede haberse vuelto inaccesible. Si el VIP permanece en un dispositivo que no puede llegar al upstream, no se produce ningún failover y se produce una interrupción del servicio.
El modelo correcto vincula el VIP al clúster, no a un dispositivo físico. El tipo de interfaz, la relación de interfaz padre, la estructura VLAN o Bond, las direcciones IPv4/IPv6, el rol MASTER/BACKUP y el método de transición deben definirse todos juntos en el mismo modelo de configuración.
Los Escenarios VIP e IP de TR7 satisfacen esta necesidad: hace que los VIPs sean gestionables junto con la topología de red, la propiedad del clúster y la conciencia del estado del enlace/gateway.
Nuestro enfoque
TR7 construye la gestión de VIP sobre un modelo de interfaz, emparejamiento de comunicación VIP, distribución MASTER/BACKUP y composición de interfaz en múltiples capas.
Siete tipos de interfaz gestionados en un único modelo de red
Las interfaces Ethernet, VLAN, Bond, LACP, V-ETH, V-ETH(peer) y Bridge se definen todas a través del mismo enfoque de configuración. Solo se muestran las opciones relevantes para cada tipo, de modo que los operadores no pueden escribir el parámetro de red incorrecto en el campo incorrecto.
La propiedad del VIP se determina a través del emparejamiento de comunicación VIP
Se define un par de comunicación VIP para cada interfaz y los nodos del clúster se emparejan a través de esas direcciones. El VIP no está fijado a un solo nodo; se posee en el nodo que tenga el rol de clúster activo.
Las listas de VIP MASTER y BACKUP se gestionan por separado
Los VIPs se separan en listas master y backup. En despliegues Active-Active, un nodo mantiene la lista de VIP master y el par mantiene la lista de backup. Si un nodo falla, todos los VIPs convergen en el nodo saludable.
Las capas VLAN, Bond y Bridge pueden apilarse
Las relaciones de interfaz padre, los miembros Bond, los miembros Bridge y las asociaciones de interfaz virtual se definen todas en el mismo árbol. Las topologías del mundo real como VLAN sobre Bond, V-ETH dentro de un Bridge, o V-ETH(peer) conectado a un namespace están todas representadas en un único modelo.
Capacidades
Los Escenarios VIP e IP combinan la estructura de red física y virtual con la gestión de VIP consciente del clúster.
Siete tipos de interfaz soportan topologías de red físicas y virtuales
TR7 soporta los tipos de interfaz Ethernet, VLAN, Bond, LACP, V-ETH, V-ETH(peer) y Bridge. Las interfaces físicas, las sub-interfaces VLAN, Bond, LACP, Bridge, Ethernet virtual y pares de Ethernet virtual pueden incluirse todas en el mismo modelo de red. Esto convierte al ADC en un punto de gestión consciente de la topología de red en lugar de simplemente una capa de asignación de IP. Los operadores gestionan el diseño de red real de su entorno de producción desde la interfaz TR7.
Los VIPs IPv4 e IPv6 se definen dentro del mismo modelo de servicio
TR7 gestiona las familias de direcciones IPv4 e IPv6 juntas en la gestión de VIP. Las direcciones v4 y v6 pueden ejecutarse en paralelo para el mismo servicio o interfaz. Las comprobaciones de estado del gateway también pueden separarse por familia de direcciones. Esto trata la adopción de IPv6 como una extensión natural del modelo VIP existente en lugar de un proyecto separado.
Los VIPs basados en VLAN permiten la separación multi-tenant y multi-subred
Las interfaces VLAN pueden definirse con una interfaz padre Ethernet, Bond o LACP. Cada VLAN puede llevar su propia subred y su propio conjunto de VIPs. Esto es particularmente valioso para arquitecturas de proveedores de servicios, multi-tenant y orientadas a la segmentación. Diferentes clientes o zonas de seguridad se separan sobre el mismo enlace físico.
Bond y LACP proporcionan redundancia y capacidad en redes de producción
Las interfaces Bond y LACP permiten que múltiples puertos físicos operen como una única interfaz lógica. Bond cubre escenarios de redundancia como el modo active-backup; LACP cubre la agregación de enlaces 802.3ad. Los VIPs de producción colocados en estas interfaces lógicas se vuelven más resilientes a los fallos de un solo puerto o enlace. Una capa VLAN también puede ejecutarse sobre Bond o LACP para un diseño de topología flexible.
Bridge, V-ETH y V-ETH(peer) cubren las integraciones de red virtual
Bridge puede usarse para el comportamiento de bridging de Capa 2 en backplanes de red basados en VM o contenedores. V-ETH proporciona una interfaz Ethernet virtual a nivel MAC para entornos de virtualización. V-ETH(peer) crea un par de Ethernet virtual para el aislamiento de namespace y contenedores. Este soporte significa que TR7 opera de forma flexible en arquitecturas virtuales y cloud on-premises, no solo en appliances físicos.
El modelo de comunicación VIP desacopla los VIPs de los nodos individuales
Los VIPs se gestionan como direcciones de servicio propiedad del clúster en lugar de listas de IP locales en un solo nodo. Los pares de comunicación VIP y los objetos VIP se definen por interfaz. Cuando se produce un failover, la propiedad del VIP puede moverse al nodo par. Este modelo preserva las direcciones de servicio tanto en escenarios de mantenimiento como de fallo.
El método de transición VIP se elige entre cuatro modelos de decisión
TR7 ofrece cuatro métodos de transición por VIP: solo VRRP, comprobación de enlace TR7, comprobación de gateway TR7 y comprobación de enlace y gateway TR7. Solo VRRP usa el comportamiento clásico del protocolo; la comprobación de enlace TR7 monitoriza el estado del carrier de la interfaz física; la comprobación de gateway TR7 verifica la accesibilidad del upstream; la comprobación de enlace y gateway TR7 evalúa ambas señales juntas. Los VIPs críticos pueden por tanto moverse basándose en la accesibilidad de red real en lugar de solo en la disponibilidad del dispositivo. Este comportamiento — que típicamente requiere scripts de monitoreo personalizados en despliegues estándar — se ofrece como una selección de política desde la interfaz TR7.
La distribución VIP Active-Active mantiene ambos nodos transportando tráfico en vivo
La lista de VIP master y la lista de VIP backup se mantienen separadas. En una configuración Active-Active, un grupo de VIPs está activo en un nodo mientras el otro grupo está activo en el par. Si un nodo se cae, el nodo saludable toma la propiedad de ambos conjuntos de VIP. Esto significa que ambos dispositivos actúan como fuentes de tráfico activas en lugar de uno estar en espera inactiva.
Profundidad operacional
La gestión de VIP se planifica junto con la jerarquía de interfaces, los slots VRRP, la comunicación unicast, el namespace, la zona y las comprobaciones de gateway.
Jerarquía de interfaces
Las relaciones VLAN, Bond, LACP, Bridge, V-ETH y V-ETH(peer) se definen a través de los campos de interfaz padre e interfaz miembro. Esto permite modelar con precisión composiciones como VLAN sobre Bond, V-ETH dentro de un Bridge, o V-ETH(peer) conectado a un namespace. Los equipos de operaciones gestionan la estructura de red junto con sus dependencias en lugar de como piezas desconectadas.
Separación de slots VRRP
Se pueden generar dos slots VRRP — MASTER y BACKUP — por interfaz. En despliegues Active-Active, esta separación es la base de la distribución de VIP. Los valores de virtual_router_id se asignan automáticamente, reduciendo el riesgo de colisiones dentro de la misma subred.
Comportamiento unicast VRRP
TR7 puede usar un enfoque unicast para la comunicación del par VRRP. Esto proporciona un comportamiento más predecible en redes de centros de datos modernos donde el tráfico multicast está filtrado. La comunicación del nodo par se define explícitamente a través de los campos unicast_src_ip y unicast_peer.
Comprobación del monitor de gateway
La accesibilidad del gateway puede monitorizarse con una comprobación de estado por interfaz. Las familias IPv4 e IPv6 pueden comprobarse de forma independiente. Cuando se pierde el acceso al gateway y el método de transición es la comprobación de gateway TR7 o la comprobación de enlace y gateway TR7, la decisión de failover tiene en cuenta esta señal.
Conciencia de namespace y zona
Los VIPs pueden asociarse con un contexto de namespace y zona. Esto hace que la propiedad del VIP esté más claramente definida en despliegues multi-tenant o multi-zona. Se puede configurar aislamiento de red separado y gestión de VIP separada para cada tenant o zona.
Actualización ARP gratuito
Cuando un VIP hace failover, se envía un ARP gratuito para actualizar las tablas MAC de los switches en el lado de la red. Esto acelera la redirección del tráfico a nivel L2 hacia el nodo recién activo. Ayuda a reducir el tiempo de interrupción del servicio particularmente durante las transiciones de VIP dentro de la misma subred.
Cuándo utilizarlo
Arquitectura multi-VLAN de telecomunicaciones y proveedor de servicios
Los equipos de telecomunicaciones pueden definir muchas VLANs en un puerto trunk y ejecutar un conjunto de VIP separado para cada cliente o segmento de servicio. Múltiples subredes y separaciones de múltiples clientes se gestionan sobre un único enlace físico.
Redundancia de VIP de producción sobre LACP
Los equipos de operaciones pueden agregar múltiples puertos físicos en una única interfaz LACP y colocar los VIPs de producción en esa interfaz lógica. La continuidad del servicio se fortalece frente a fallos de enlace o demandas de capacidad.
Distribución de VIP en nodos Active-Active
En despliegues grandes, algunos VIPs pueden estar activos en un nodo mientras otros se ejecutan en el par. Ambos dispositivos transportan tráfico en vivo, y si un nodo falla el nodo saludable toma la propiedad del conjunto completo de VIP.
Aislamiento de red de tenant basado en namespace
En entornos multi-tenant, cada tenant puede colocarse en su propio namespace. Los VIPs se definen como pertenecientes a ese namespace y el tráfico del tenant se separa en el plano de red.
Preguntas frecuentes
¿Qué tipos de interfaz soporta TR7?
¿Qué es clusterIpMethod y qué opciones están disponibles?
¿Cómo funciona la distribución VIP Active-Active?
¿Pueden los VIPs IPv4 e IPv6 ejecutarse simultáneamente?
¿Cómo se redirige el tráfico de red durante un failover de VIP?
¿Cuándo debería usarse el VRRP unicast?
Integre la gestión de VIP con su topología de red
Siete tipos de interfaz, cuatro métodos de failover y propiedad de VIP a nivel de clúster. Le guiaremos en una configuración en vivo en su propio entorno.