High Availability (Active-Standby)
Resumen
Un solo BIG-IP es un punto único de falla. En Active/Standby dos equipos forman un par: el activo procesa todo el tráfico y el standby tiene la misma configuración (sincronizada con ConfigSync) y toma el control si el activo falla. La pieza clave es el traffic group: las floating self IPs y los VIPs viven en él y se mueven al equipo activo, igual que la IP virtual de HSRP. Esta nota arma el par paso a paso: direcciones de HA, device trust, device group, floating IPs, sincronización y pruebas de failover.
Requisitos previos
- Dos BIG-IP con la misma versión y licencia
- NTP sincronizado en ambos
- VLANs y self IPs no flotantes creadas en cada equipo (VLANs, Self IPs y Rutas)
- Una VLAN dedicada de HA (recomendado) con self IP en cada equipo
- Port Lockdown que permita UDP 1026 en la self IP de HA (Port Lockdown)
Conceptos clave
| Concepto | Qué es |
|---|---|
| Device trust | Confianza por certificados entre los equipos (peers) |
| Device group Sync-Failover | Sincroniza configuración y hace failover |
| Traffic group | Objetos flotantes que se mueven juntos (traffic-group-1) |
| ConfigSync address | Self IP usada para sincronizar |
| Failover addresses | Self IPs (y mgmt) para el heartbeat (UDP 1026) |
| Mirroring address | Self IP para copiar conexiones (TCP 1029–1155, un canal por traffic group) |
| TCP 4353 | Puerto de device trust y ConfigSync (CMI) |
| Sync status | In Sync, Changes Pending, Awaiting Initial Sync, Disconnected |
El efecto del failover en los usuarios
Las conexiones cortas (HTTP) se reconectan sin problema. Las largas (SSH, FTP, bases de datos) se cortan si no hay connection mirroring. Sin MAC masquerading puede haber un corte breve mientras los vecinos actualizan ARP.
Configuración (Ejemplo, Lab CBT Nuggets)
| bigip1 | bigip2 | |
|---|---|---|
| Gestión | 192.168.121.11 | 192.168.121.12 |
| internal (también usada para HA en el lab) | 10.10.101.11 | 10.10.101.12 |
| Floating external / internal | 172.16.101.13 / 10.10.101.13 | (sincronizadas) |
1. Direcciones de HA en cada equipo
En cada BIG-IP:
- Device Management > Devices > el equipo local (self) > ConfigSync > Local Address:
10.10.101.11> Update. - Failover Network > Add: Unicast Address
10.10.101.11(y la de gestión) > Finished. - Mirroring > Primary Local Mirror Address:
10.10.101.11> Update.
tmsh modify cm device bigip1.f5lab.int configsync-ip 10.10.101.11 mirror-ip 10.10.101.11
tmsh modify cm device bigip1.f5lab.int unicast-address { { effective-ip 10.10.101.11 effective-port 1026 ip 10.10.101.11 } { effective-ip management-ip effective-port 1026 ip management-ip } }
El nombre del dispositivo (bigip1.f5lab.int) es el que muestra tmsh list cm device. En el otro equipo repite con su nombre y sus IPs (.12).
2. Device trust (en un solo equipo)
Device Management > Device Trust > Device Trust Members > Add > Device Type: Peer > Device IP Address: 192.168.121.12 (gestión del otro) > usuario y contraseña admin > Retrieve Device Information > verifica certificado y nombre > Device Certificate Matches > Name > Add Device.
3. Device group (en un solo equipo)
Device Management > Device Groups > Create > Name: DG-Failover > Group Type: Sync-Failover > Members: ambos equipos > Sync Type: Manual (o Automatic) > Finished.
tmsh create cm device-group DG-Failover devices add { bigip1.f5lab.int bigip2.f5lab.int } type sync-failover auto-sync disabled
4. Sincronización inicial
Device Management > Overview > selecciona el equipo con la configuración buena > Sync (Push to group).
tmsh run cm config-sync to-group DG-Failover
5. Floating self IPs
En el equipo activo: Network > Self IPs > Create > IP 172.16.101.13 y 10.10.101.13 > Traffic Group: traffic-group-1 > Finished. Sincroniza. Los servidores usan 10.10.101.13 como gateway si no hay SNAT.
6. Probar el failover
Device Management > Devices > el equipo activo > Force to Standby. El otro pasa a activo y se lleva el traffic group.
tmsh run /sys failover standby
7. Mantenimiento: Force Offline
Device Management > Devices > el equipo > Force Offline > OK (no procesa tráfico ni puede ser activo). Para volver: Release Offline.
tmsh run /sys failover offline
tmsh run /sys failover online
Verificación
| Comando o lugar | Qué debes ver | Si no lo ves |
|---|---|---|
| Arriba a la izquierda | ONLINE (ACTIVE) / ONLINE (STANDBY) y In Sync | Ver Errores comunes |
tmsh show cm device all | Ambos equipos con su Device HA State | Revisa trust y failover addresses |
tmsh show cm sync-status | In Sync | Haz Sync to group |
tmsh show cm traffic-group | traffic-group-1 activo en un solo equipo | Split-brain: revisa heartbeat |
tmsh show cm failover-status | Estado y causa del último failover | — |
tail /var/log/sodlog o /var/log/ltm | Eventos de failover | — |
| Ping continuo al VIP durante el failover | 0–1 paquetes perdidos | Revisa MAC masquerading |
Errores comunes
Los equipos no se ven (Disconnected)
- Causa: no hay conectividad entre las IPs de ConfigSync/failover, certificados del trust distintos, o versiones diferentes.
- Revisa:
pingentre self IPs de HA,tmsh show cm device all,/var/log/ltm. - Solución: corrige red y versión; rehace el device trust si cambiaron certificados.
El estado queda en “Changes Pending”
- Causa: hubo cambios no sincronizados.
- Solución: Sync desde el equipo con la configuración correcta hacia el grupo.
Los dos equipos quedan activos (split-brain)
- Causa: no llega el heartbeat (UDP 1026 bloqueado por Port Lockdown o la red de HA caída).
- Solución: abre UDP 1026 y usa más de una failover address (HA y gestión).
Después del failover los servidores pierden su gateway
- Causa: usan la self IP no flotante.
- Solución: gateway = floating self IP.
Cambié algo en el standby y se perdió
- Causa: el siguiente sync desde el activo lo sobrescribió.
- Solución: haz los cambios en un solo equipo (normalmente el activo) y sincroniza.
El activo vuelve a cambiar solo cuando se recupera el otro
- Causa: auto-failback habilitado.
- Solución: déjalo deshabilitado (es el valor por defecto) y vuelve atrás manualmente en una ventana.