El proceso de conmutación por error del FireCluster es el mismo para un clúster activo/activo o para un clúster activo/pasivo. Con ambos tipos de clústers, cada miembro del clúster mantiene la información de estado y sesión en todo el momento. Cuando ocurre la conmutación por error, las conexiones de filtro de paquetes, túneles de VPN de sucursal y sesiones de usuario del dispositivo con fallas hacen la conmutación por error de forma automática hacia el otro dispositivo en el clúster.
Un Firebox es el clúster principal y el otro dispositivo es el principal de respaldo. El principal de respaldo usa la interfaz del clúster primario para sincronizar la información de sesión y conexión con el clúster principal. Si la interfaz del clúster primario falla o está desconectada, el principal de respaldo usa la interfaz del clúster de respaldo para comunicarse con el clúster principal. El clúster principal también usa tanto la interfaz del clúster primario y la del clúster de respaldo para enviar un paquete de latido una vez por segundo al respaldo principal. Recomendamos que siempre configure tanto la interfaz del clúster principal como la del clúster de respaldo.
Eventos que desencadenan una conmutación por error
Hay tres tipos de eventos que pueden desencadenar una conmutación por error del clúster.
El índice de salud del clúster principal es menor que el índice de salud del respaldo principal
Cada miembro del clúster tiene un índice de salud calculado que indica la salud general del dispositivo. Si el índice de salud del clúster principal es menor que el índice de salud del respaldo principal, esto dispara una conmutación por error del clúster principal.
Para más información acerca del índice de salud del clúster, consulte Monitorizar salud de FireCluster.
Latido perdido del clúster principal
El clúster principal envía un paquete de latido a través de las interfaces del clúster primaria y de respaldo una vez por segundo. Si el respaldo principal no recibe tres latidos consecutivos del clúster principal, esto dispara una conmutación por error del clúster principal. El umbral predeterminado para los latidos perdidos es tres. Puede aumentar el umbral de latido perdido que dispara una conmutación por error en las configuraciones Avanzadas de FireCluster.
Para más información acerca del umbral de señal de monitorización perdida, consulte Configurar los Ajustes avanzados de FireCluster.
El clúster recibe el comando de Conmutación por error del principal
En Firebox System Manager, cuando selecciona Herramientas > Clúster > Maestro de Conmutación por Error, fuerza una conmutación por error del clúster maestro al maestro de respaldo.
Para más información sobre este comando, consulte Forzar una Conmutación por Error del Clúster Principal.
Qué ocurre cuando sucede una conmutación por error
Cuando ocurre una conmutación por error del clúster principal, el principal de respaldo se convierte en el clúster principal. A continuación, el clúster principal original se vuelve a unir con el clúster como el principal de resguardo. Cuando ocurre una conmutación por error, el clúster mantiene todas las conexiones de filtro del paquete, los túneles de VPN de sucursal y sesiones de usuario. Ese comportamiento es el mismo para un FireCluster activo/activo o activo/pasivo.
En un clúster activo/activo, si el principal de respaldo falla, el clúster principal mantiene todas las conexiones de filtrado de paquetes, túneles de VPN de sucursal y sesiones de usuario. Las conexiones proxy y de Mobile VPN pueden ser interrumpidas, tal como se describe en esta lista. En un clúster activo/pasivo, si el principal de respaldo falla, no hay interrupción de conexiones o sesiones, porque no se asigna tráfico al principal de respaldo.
| Tipo de Conexión/Sesión | Impacto de un evento de conmutación por error |
|---|---|
| Conexiones de filtrado de paquetes | Las conexiones son conmutadas por error a otro miembro del clúster. |
| Túneles VPN de sucursal | Los túneles son conmutados por error a otro miembro del clúster. |
| Sesiones de usuario | Las sesiones son conmutadas por error a otro miembro del clúster. |
| Conexiones de proxy | Las conexiones asignadas al dispositivo con fallas (principal o principal de respaldo) deben ser reiniciadas. Las conexiones asignadas a otro dispositivo no son interrumpidas. |
| Access Portal | Las sesiones de usuario de Access Portal y las conexiones a las aplicaciones web de Access Portal permanecen activas después de una conmutación por error. Las conexiones RDP y SSH iniciadas a través del Access Portal son desconectadas después de una conmutación por error. |
| Mobile VPN with IPSec | Si el clúster principal conmuta por error, todas las sesiones deben ser reiniciadas. Si el principal de respaldo falla, sólo las sesiones asignadas al principal de respaldo deben ser reiniciadas. Las sesiones asignadas al clúster principal no son interrumpidas. |
| Mobile VPN with SSL | Si cualquiera de los dispositivos conmuta por error, todas las sesiones deben ser reiniciadas. |
| Mobile VPN with L2TP | Todas las sesiones de L2TP son asignadas al clúster principal, incluso para un clúster activo/activo. Si el clúster principal conmuta por error, todas las sesiones deben ser reiniciadas. Si hay una falla del principal de respaldo, las sesiones de L2TP no son interrumpidas. |
| Mobile VPN with IKEv2 | Si el clúster principal conmuta por error, todas las sesiones deben ser reiniciadas. Si el principal de respaldo falla, sólo las sesiones asignadas al principal de respaldo deben ser reiniciadas. Las sesiones asignadas al clúster principal no son interrumpidas. |
Conmutación por error y balance de carga del servidor del FireCluster
Si usa el balance de carga del servidor para balancear las conexiones entre sus servidores internos, cuando ocurre un evento de conmutación por error del FireCluster, no ocurre la sincronización en tiempo real. Después de una conmutación por error, el nuevo clúster principal envía las conexiones a todos los servidores en la lista de balance de carga en el servidor para descubrir cuáles servidores están disponibles. Entonces aplica el algoritmo de balance de carga en el servidor a todos los servidores disponibles.
Para más información sobre el balance de carga en el servidor, consulte Configurar el Balance de Carga del Servidor.
Conmutación por error de FireCluster y Dynamic Routing
Al habilitar el enrutamiento dinámico en un FireCluster, solo el maestro del clúster participa directamente en el dominio de enrutamiento dinámico. El clúster principal sincroniza la información de dynamic routing al otro miembro del clúster. Cuando ocurre la conmutación por error, el nuevo clúster principal usa inicialmente las rutas dinámicas que obtuvo anteriormente. El nuevo clúster principal después participa en el dominio de enrutamiento dinámico y usa el protocolo de enrutamiento dinámico configurado para determinar las rutas más recientes a todas las redes de destino. Cuando el nuevo clúster principal descubre las rutas dinámicas actualizadas, las rutas dinámicas se purgan y reemplazan con las nuevas.
El tiempo que tardan el nuevo clúster principal y todos los enrutadores conectados para coincidir en un conjunto de rutas en común (tiempo de convergencia) depende del protocolo de enrutamiento dinámico.
Para RIPv1 y RIPv2
El enrutador de punto RIP no detecta el evento de conmutación por error de FireCluster si la conexión no se interrumpe durante la conmutación por error.
OSPFv2
El enrutador de punto detecta el evento de conmutación por error de FireCluster. El tiempo de convergencia para OSPF es de 10 a 40 segundos. El tiempo de convergencia puede ser más breve, porque el nuevo clúster principal usa un conjunto de rutas dinámicas sincronizado desde el clúster principal anterior hasta que determina las rutas dinámicas actualizadas.
BGPv4
El enrutador de punto detecta el evento de conmutación por error de FireCluster. El tiempo de convergencia para BGP es de 1 a 3 minutos. El tiempo de convergencia puede ser más breve, porque el nuevo clúster principal usa un conjunto de rutas dinámicas sincronizado desde el clúster principal anterior hasta que determina las rutas dinámicas actualizadas.
Monitorizar el Clúster Durante una Conmutación por Error
El rol de cada dispositivo en el clúster aparece después del nombre del miembro en la pestaña Panel Delantero del Firebox System Manager. Si mira la pestaña Panel Delantero durante una conmutación por error del clúster principal, puede ver el rol de ese clúster pasar de un dispositivo al otro. Durante una conmutación por error, se ve:
- El rol del principal de respaldo anterior cambia de principal de respaldo a principal.
- El rol del clúster principal antiguo cambia a inactivo y después ocioso mientras el dispositivo se reinicia.
- El rol del clúster principal antiguo cambia a principal de respaldo después de que se reinicia el dispositivo.
Para más información, consulte Monitorizar y Controlar Miembros de FireCluster.
Conmutación por error de FireCluster y Servicios de Suscripción
Si habilita los servicios de suscripción con licencia para su FireCluster, los servicios siguen operando después de la conmutación por error, siempre y cuando haya adquirido los servicios de suscripción requeridos para miembros de FireCluster. Los requisitos son diferentes para un FireCluster activo/activo y para un FireCluster activo/pasivo.
- Activo/Activo — Debe tener los mismos servicios de suscripción habilitados en las llaves de licencia para ambos miembros del clúster. Cada miembro del clúster aplica los servicios en su propia llave de licencia.
- Activo/Pasivo — Debe habilitar los servicios de suscripción en la llave de licencia de solo un miembro del clúster. El miembro del clúster activo usa los servicios de suscripción que están activos en la llave de licencia de uno de los clústers miembros.
Para más información acerca de las llaves de licencia para FireCluster, consulte Acerca de las Llaves de Licencia y FireCluster.