Cómo resolver el fallo de conmutación por error de HA Activo-Pasivo en la nube de AWS

Este artículo se centra en un escenario de conmutación por error activa-pasiva en un clúster HA de FortiGate-VM en la nube de AWS. Entender cómo funciona esta configuración es crucial para asegurar que la continuidad del servicio no se vea afectada durante fallos en el sistema. A continuación, se proporcionará una guía paso a paso para diagnosticar y solucionar problemas relacionados con este tipo de implementación.

Descripción del problema

En un entorno de alta disponibilidad (HA), es crucial que la conmutación por error entre los dispositivos FortiGate funcione sin inconvenientes, pues esto garantiza la disponibilidad continua del servicio. Un fallo en la sincronización entre los dispositivos primario y secundario puede llevar a interrupciones en el tráfico de red y afectar la seguridad y el rendimiento.

Alcance

Este artículo se aplica específicamente a la implementación de FortiGate-VM en un clúster de HA dentro de la misma zona de disponibilidad de AWS.

Diagnóstico paso a paso

1. Verifique la configuración del clúster HA y asegúrese de que ambos dispositivos estén correctamente sincronizados.
2. Revise los registros de eventos de FortiGate para identificar cualquier fallo durante la conmutación por error.
3. Confirme que las interfaces de gestión HA estén configuradas en subredes públicas, lo que facilitará la comunicación con la API de AWS.

Solución recomendada

Topología:

En este ejemplo:

La arquitectura de FortiGate HA es el conector SDN HA Activo-Pasivo. Dentro de la VPC, hay una Zona de Disponibilidad 1.

• FGT-1 y FGT-2 están desplegados como un clúster HA Activo-Pasivo dentro de la Zona de Disponibilidad 1.
• FGT-1 es el FortiGate Primario y FGT-2 es el FortiGate Secundario.

Durante la conmutación por error:

1. Las direcciones IP secundarias configuradas en el puerto 1 y puerto 2 del FGT-1 se trasladan a los puertos 1 y 2 del FGT-2.
2. Se asigna la IP Elástica (Dirección Secundaria) al puerto 1 del FGT-1 y se traslada al puerto 1 del FGT-2.
3. Se realiza una actualización de ruta en la tabla de enrutamiento de la subred privada donde está alojada la instancia EC2. Inicialmente, el tráfico se enruta a través del ENI (puerto 2) del FGT-1, pero tras la conmutación por error, se enrutará el tráfico a través del ENI (puerto 2) del FGT-2.
4. El FGT-2 realiza actualizaciones del SDN de AWS enviando llamadas API a través de la interfaz de gestión HA (puerto 4).
5. Desde la interfaz de gestión HA (FGT-2 puerto 4), las llamadas API se envían a través del gateway de internet de AWS hacia Internet.

Nota: Asegúrese de que las interfaces de gestión HA estén en subredes públicas, ya que las llamadas API de EC2 de AWS se acceden públicamente. Después de una conmutación por error, el FGT-2 se convierte en el primario al tomar el control del FGT-1.

Comandos CLI utilizados

show system ha
get syscall ha status
show active
                

Buenas prácticas y recomendaciones

Asegúrese de realizar pruebas de conmutación por error periódicas y actualizar la documentación de su arquitectura HA. Verifique regularmente las configuraciones y mantenga actualizados los registros para facilitar auditorías y diagnósticos futuros.

Notas adicionales

Siempre que realice cambios en la configuración del clúster HA, es recomendable documentar a fondo el proceso para futuras referencias. Mantener las versiones de firmware consistentes entre el FGT-1 y FGT-2 también es esencial para evitar problemas de compatibilidad.