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.
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.
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.
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.
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 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.
Los Escenarios VIP e IP combinan la estructura de red física y virtual con la gestión de VIP consciente del clúster.
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.
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.
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.
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 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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.