Active-Active y failover avanzado

Resumen

En Active/Active cada equipo del par es activo para un traffic group distinto, así los dos procesan tráfico en lugar de tener uno parado. Esta nota crea un segundo traffic group y lo mueve al otro equipo, y agrega las funciones que hacen el failover más rápido y predecible: MAC masquerading, connection mirroring, HA groups, gateway fail-safe y la política de auto-failback.

Requisitos previos

• Par HA Active/Standby funcionando (High Availability (Active-Standby))
• IPs libres para las nuevas floating self IPs y VIPs
• Capacidad: cada equipo debe poder con el 100 % del tráfico si el otro falla

Conceptos clave

Concepto	Qué es
traffic-group-2	Segundo grupo de objetos flotantes, activo en el otro equipo
MAC Masquerade	MAC virtual compartida por traffic group (como la MAC virtual de HSRP)
Connection Mirroring	Copia el estado de las conexiones al peer (solo para sesiones largas)
HA group	Puntaje según salud de pools/trunks; el de mayor puntaje queda activo
Gateway fail-safe	Failover si cae el router de salida
VLAN fail-safe	Acción si una VLAN deja de recibir tráfico (failover, reboot o restart all; por defecto Reboot)
Auto-failback	Volver solo al equipo preferido al recuperarse (deshabilitado por defecto)

Configuración (Ejemplo, Lab CBT Nuggets)

1. Crear el segundo traffic group

Device Management > Traffic Groups > Create > Name: traffic-group-2 > Create Traffic Group.

tmsh create cm traffic-group traffic-group-2

2. Floating self IPs del nuevo grupo

Network > Self IPs > Create > IP 172.16.101.14 (external) y 10.10.101.14 (internal) > Traffic Group: traffic-group-2 > Finished.

3. VS de la segunda aplicación

Local Traffic > Virtual Servers > Create > Source 0.0.0.0/0 > Destination 172.16.101.30 > Service Port 80 > pool > Finished. Luego en Virtual Address List > 172.16.101.30 > Traffic Group: traffic-group-2 > Update.

tmsh modify ltm virtual-address 172.16.101.30 traffic-group traffic-group-2

4. Mover el traffic group al otro equipo

Device Management > Traffic Groups > traffic-group-2 > Force to Standby (en el equipo que lo tiene activo). Sincroniza.

tmsh run /sys failover standby traffic-group traffic-group-2
tmsh run cm config-sync to-group DG-Failover

Resultado: bigip1 activo para traffic-group-1, bigip2 activo para traffic-group-2.

5. MAC masquerading

Device Management > Traffic Groups > traffic-group-1 > MAC Masquerade Address: 02:01:d7:93:35:08 > Update. Usa una MAC distinta por traffic group (localmente administrada, empieza con 02).

tmsh modify cm traffic-group traffic-group-1 mac 02:01:d7:93:35:08

6. Connection mirroring (solo donde haga falta)

Virtual Servers > el VS de una app con sesiones largas > Configuration: Advanced > Connection Mirroring: Enabled > Update. En el perfil de persistencia: Mirror Persistence.

tmsh modify ltm virtual VS-DB1 mirror enabled

7. Gateway fail-safe

Contenido complementario

No se vio en mis lecciones.

Pendiente: validar en el lab

Este contenido no salió de mis clases. Probar estos comandos y pasos en BIG-IP VE antes de usarlos en un trabajo real, y corregir lo que difiera en mi versión.

1. Pool pool_gw con el router como miembro (172.16.101.1:0) y monitor gateway_icmp.
2. System > High Availability > Fail-safe > Gateway > Add: Pool pool_gw, Device: el equipo, Threshold (miembros mínimos): 1, Action: Failover (por defecto) > Add.

tmsh create ltm pool pool_gw members add { 172.16.101.1:0 } monitor gateway_icmp
tmsh modify ltm pool pool_gw gateway-failsafe-device bigip1.f5lab.int min-up-members 1 min-up-members-checking enabled min-up-members-action failover

min-up-members-action failover (el valor por defecto; también existen reboot y restart-all) hace que solo ese equipo pase a standby cuando el pool del gateway baja del mínimo. Cada equipo vigila únicamente su propio gateway pool.

8. HA group

Contenido complementario

No se vio en mis lecciones.

Pendiente: validar en el lab

Este contenido no salió de mis clases. Probar estos comandos y pasos en BIG-IP VE antes de usarlos en un trabajo real, y corregir lo que difiera en mi versión.

System > High Availability > HA Group List > Create > Name: hg_core > Pools: pool_app1_80 (peso 30) > Trunks: trunk_core (peso 50) > Finished. Device Management > Traffic Groups > traffic-group-1 > Failover Method: HA Score > HA Group: hg_core > Update.

tmsh create sys ha-group hg_core pools add { pool_app1_80 { attribute percent-up-members weight 30 } } trunks add { trunk_core { attribute percent-up-members weight 50 } }
tmsh modify cm traffic-group traffic-group-1 failover-method ha-score monitor { ha-group hg_core }

El peso va de 10 a 100 (por defecto 10) y se multiplica por el porcentaje de miembros up. En versiones antiguas se usaba ha-group hg_core directamente en el traffic group; está obsoleto desde la v13.

Los HA groups no se sincronizan (la asociación con el traffic group es local de cada equipo): crea el mismo HA group y asócialo en cada equipo del par.

9. Auto-failback

Device Management > Traffic Groups > el grupo > Auto Failback: déjalo deshabilitado (por defecto). Si lo habilitas, el equipo preferido recupera el tráfico apenas vuelve, lo que provoca un segundo failover. Auto-failback no se puede combinar con un HA group en el mismo traffic group.

Verificación

Comando o lugar	Qué debes ver	Si no lo ves
tmsh show cm traffic-group	traffic-group-1 activo en bigip1 y traffic-group-2 en bigip2	Paso 4
Device Management > Overview	Cada equipo con sus grupos activos	—
tmsh list cm traffic-group traffic-group-1 mac	La MAC configurada	Paso 5
tmsh show sys ha-group	Puntaje de cada equipo	Paso 8
Ping continuo al VIP + Force to Standby	Sin pérdida o 1 paquete	Revisa MAC masquerade

Errores comunes

Al caer un equipo, el otro se satura

• Causa: cada uno estaba al 70–80 % en Active/Active.
• Solución: dimensiona para que uno solo soporte todo el tráfico.

El VIP nuevo no se mueve con el traffic group

• Causa: la virtual address quedó en traffic-group-1.
• Solución: cámbiala a traffic-group-2 en Virtual Address List.

Failovers inesperados

• Causa: HA group con pesos mal calculados, gateway fail-safe con un monitor demasiado sensible, o heartbeat intermitente.
• Revisa: /var/log/ltm y /var/log/sodlog a la hora del evento, tmsh show sys ha-status.
• Solución: ajusta pesos y monitores; agrega failover addresses redundantes.

El mirroring sube mucho la CPU

• Causa: mirroring en VS de HTTP con muchas conexiones cortas.
• Solución: úsalo solo en apps con sesiones largas.