¿Qué es la Alta Disponibilidad (HA) del Socket

Este artículo discute las configuraciones de Alta Disponibilidad (HA) y condiciones de conmutación por error para sitios que usan un par de Sockets físicos de Cato.

Descripción general de la Alta Disponibilidad de Socket para un Sitio

Para mejorar la resiliencia del sitio, Cato recomienda encarecidamente desplegar cada sitio con un par de Sockets que operen en modo de Alta Disponibilidad (HA). Este modo de operación asegura la continuidad del servicio para el sitio en caso de falla de un solo Socket. Durante una conmutación por error, el Cato Cloud mantiene el estado de los flujos y hay un impacto mínimo en la experiencia del usuario final.

Sitios con HA de Sockets Soportados

Cato admite HA de Sockets para los siguientes entornos:

  • Sitio con Socket Físico

  • Sitio AWS vSocket

  • Sitio Azure vSocket

Este artículo explica cómo funciona la HA para un sitio con Socket físico. Para más información sobre la configuración de Socket HA en unos pocos clics, consulte Uso de Sockets en un Despliegue HA.

Alta Disponibilidad de Socket y Diferentes Modelos de Socket

Los sitios HA de Sockets pueden usar dos Sockets del mismo tipo, X1500, X1600, X1600 LTE o X1700. Sin embargo, no se puede usar diferentes tipos de Sockets, por lo que un sitio con un Socket X1600 y un Socket X1700 no es admitido.

No puede usar un Socket X1600 y un Socket X1600 LTE en el mismo sitio HA.

Entendiendo la Alta Disponibilidad de Socket y el Failover

En un despliegue HA de Socket, se asignan dos Sockets de Cato a un sitio. El primer Socket asignado al sitio se identifica como el Socket primario, el segundo como el Socket secundario. Los Sockets operan en modo HA Activo/Espera. Durante la operación normal de un sitio, el Socket primario tiene el estado de HA Master, mientras que el Socket secundario tiene el estado de HA Standby. Solo el Socket con el estado de HA Master maneja el tráfico.

  1. El Socket secundario (en espera) monitorea continuamente el estado (vitalidad) del Socket Master escuchando los mensajes de keepalive periódicos que envía el Socket primario. Los mensajes de Keepalive se envían a través de la interfaz designada con el destino establecido en LAN & VRRP o VRRP (vea abajo Conectividad LAN y Socket HA).

  2. Una vez que el Socket secundario (en espera) detecta que el Socket primario está caído, cambia su estado HA a Master y comienza a manejar el tráfico. Esto sucede después de tres segundos de mensajes HA keepalive perdidos.  

  3. El Socket secundario envía un mensaje GARP a las redes LAN para acelerar la convergencia de Capa 2.

  4. Cuando el Socket primario se recupera y se restaura a su funcionalidad regular, entonces se convierte preventivamente en el Master y el Socket secundario vuelve al estado de espera.

La siguiente imagen muestra la página de configuración HA para Sockets X1500 en la aplicación de gestión de Cato en Red > Sitios > {site name} > Configuración del sitio > Socket:

image.png

Elemento

Descripción

1

Rol HA del Socket - Primario o Secundario

2

Estado HA del Socket - Master o En Espera

3

HA Estado - Listo o No Listo

4

Condiciones específicas para el estado HA global

  • Conectado - Conectividad WAN del Socket

    • GreenCheck.png- Tanto los Sockets primario como secundario tienen al menos un túnel operacional conectado al Cato Cloud

    • Red_X.png- El Socket no tiene túneles operacionales conectados al Cato Cloud

  • Keepalive - Estado del canal HA keepalive entre los Sockets

    • GreenCheck.png- El Socket secundario recibe mensajes HA keepalive del Socket primario

    • Red_X.png- El Socket secundario no recibe mensajes HA keepalive del Socket primario

  • Versión compatible - Tanto el Socket primario como el secundario están ejecutando versiones del sistema operativo del Socket compatibles

    • GreenCheck.png- Both Sockets are running compatible (the same major) Socket version, for example 14.0.13986 and 14.0.12764

    • Red_X.png- Sockets have different major Socket versions, for example 14.0.13986 and 13.0.48732

    Nota: La conmutación por error HA del Socket ocurre incluso si los Sockets están ejecutando diferentes versiones mayores. Sin embargo, el sitio podría experimentar problemas de funcionalidad si la versión secundaria del Socket no admite funciones que son compatibles con la versión principal del Socket.

    For example, if the primary Socket runs version 18.0 and the secondary Socket is running version 15.0, In the case of a failover, features that were released with versions 16 - 18 will not work while the secondary Socket is active.

Ejemplo de Failover de Socket HA

Los siguientes diagramas muestran un ejemplo de un problema en el Socket primario que causa un cambio al Socket secundario. Cuando el Socket secundario descubre que el Socket primario está caído, entonces cambia su estado a Master. El Cato Cloud transfiere los flujos de tráfico a los enlaces WAN en el Socket secundario.

Socket_HA_Regular.png
Socket_HA_Failure.png

Socket HA y Condición de Split-Brain

Una condición de separación cerebral es cuando ambos Sockets tienen el rol de Master al mismo tiempo. Esto puede suceder debido a un problema de conectividad LAN entre los Sockets que crea una situación donde los mensajes HA keepalive no llegan al Socket secundario.

Puede identificar una condición de separación cerebral verificando la página del Socket (mostrada arriba) en la aplicación de gestión de Cato.

  • Los Sockets primario y secundario se mostrarán como estado Master (elemento 2)

  • La condición de Keepalive (en el elemento 4) se mostrará como Fallo y esto provoca que el Estado HA (elemento 3) se muestre como NO LISTO

Una vez resuelto el problema de conectividad LAN, el Socket secundario identifica que el Socket primario es el Master y el Socket secundario vuelve al estado de espera.

Tráfico del Sitio Durante la Condición de Split-Brain

El siguiente proceso asegura que durante una condición de separación cerebral, solo el Socket secundario maneje el tráfico para el sitio (incluso si hay una condición de separación cerebral).

  • Para tráfico descendente (del PoP al sitio):

    1. El PoP detecta que el Socket secundario ahora es el Master.

    2. El PoP establece la métrica preferida para los túneles del Socket secundario.

      El tráfico descendente ahora solo se enruta al Socket secundario.

  • Para tráfico ascendente (del sitio al PoP):

    1. Cuando el Socket secundario cambia el estado de HA de En Espera a Maestro, envía un mensaje GARP a la LAN para actualizar las tablas ARP y MAC indicando que ahora es el Maestro.

      El tráfico ascendente de la LAN ahora solo se enruta al Socket secundario.

Conectividad de Socket HA a la Nube de Cato

Ambos Sockets, el primario y el secundario, establecen túneles DTLS al mismo PoP de Cato Cloud en cada uno de los puertos WAN. En la dirección Ascendente, solo el Socket Maestro envía el tráfico al PoP. En la dirección Descendente, el PoP utiliza únicamente los túneles del Socket Maestro para enviar el tráfico al sitio. En caso de un evento de conmutación por error de HA Socket, el Socket secundario se convierte en el nuevo Maestro y el PoP transfiere el tráfico de los túneles del Socket primario fallido a los túneles del Socket secundario. El PoP mantiene el estado de flujo y el estado NAT para asegurarse de que todas las aplicaciones de usuario continúen operando durante y después de la conmutación por error.

A continuación se muestran ejemplos de topologías físicas y lógicas para el HA Socket:

PhysicalLogicalTopology.png

Para una conectividad WAN óptima, rendimiento y funcionalidad de HA, Cato requiere una disposición simétrica (espejo) del cableado para ambos Sockets. Por ejemplo, si el puerto WAN1 del Socket primario está conectado a ISP1 y el puerto WAN2 está conectado a ISP2, el Socket secundario debe tener los mismos puertos conectados a los mismos ISPs que el Socket primario.

Estas topologías simétricas pueden incluir conexiones directas a los enrutadores ISP o utilizar una pila de conmutadores.

WAN_Connectivity_Router_Switch.png

Nota

Nota: El uso de una topología asimétrica puede crear problemas y no está oficialmente soportado por Cato. Por ejemplo, cuando el puerto WAN1 del Socket primario está conectado a ISP1 y el puerto WAN1 del Socket secundario está conectado a ISP2.

Conectividad LAN y Socket HA

Cato requiere que tanto los Sockets primario como secundario tengan una disposición de cableado simétrica (en espejo) para la conectividad LAN. Por ejemplo, el puerto LAN 1 para ambos Sockets, el primario y el secundario, está conectado al conmutador LAN (o los puertos LAN 1 y 2 para configuraciones con múltiples puertos LAN).

Esta sección discute las siguientes opciones de conectividad LAN para HA Socket:

  1. Puerto LAN único

  2. Múltiples puertos LAN

  3. Agregación de enlace LAN (opción recomendada)

  4. Puerto dedicado para mensajes keepalive HA

Algunas de estas opciones requieren configuraciones adicionales del sitio en la Aplicación de Gestión Cato. Por ejemplo, el puerto LAN está configurado para LAN & VRRP o VRRP.

Socket HA con un único Puerto LAN

Existen configuraciones que utilizan un único puerto LAN para conectar los Sockets primario y secundario al conmutador LAN. Con esta configuración, se debe usar el mismo número de puerto en ambos Sockets. El tráfico de usuario y los mensajes keepalive de HA se ejecutan sobre un único enlace. Esta topología no proporciona redundancia de enlace LAN.

El siguiente diagrama muestra una topología de HA Socket con un único puerto LAN en cada Socket conectado a un conmutador:

HA_LAN_switch.png

Socket HA con Múltiples Puertos LAN

Esta sección versa sobre cuando tanto los Sockets primario como secundario están conectados a los conmutadores LAN a través de dos o más puertos LAN independientes. Con esta configuración, se deben usar los mismos puertos en ambos Sockets para la conectividad LAN.

Por defecto, el puerto LAN con el número más bajo se usa tanto para el tráfico keepalive de HA como para el tráfico de usuario. Los puertos LAN restantes solo transportan el tráfico de usuario.

Puede elegir cualquier puerto LAN para el tráfico keepalive de HA cambiando la Destination del puerto de LAN a LAN & VRRP.  La siguiente captura de pantalla muestra el puerto 3 para el tráfico de usuario LAN y el puerto 4 para el tráfico keepalive de HA y el tráfico de usuario.

LAN_VRRP.png

Para más información sobre el cambio del puerto LAN para el tráfico de Keepalive HA, consulte Uso de Sockets en un Despliegue HA. Esta topología no proporciona redundancia de enlace LAN.

El conmutación por error de HA del Socket (donde el Socket secundario se convierte en el Maestro) solo ocurre cuando se cumplen ambas condiciones:

  1. El Socket secundario deja de recibir los mensajes keepalive de HA del Socket primario durante un período de tres segundos.

  2. El puerto LAN & VRRP en el Socket secundario está en el estado CONECTADO.

Si el puerto LAN del Socket Secundario está DESCONECTADO, no se convertirá en el Maestro para evitar una posible condición de cerebro dividido.

Socket HA con Agregación de Enlaces LAN (Configuración Recomendada)

Tanto los Sockets primario como secundario están conectados a los conmutadores LAN a través de dos o más puertos LAN agrupados en una agregación de enlace (LAG).  Con esta configuración, se deben usar los mismos puertos en ambos Sockets para la conectividad LAN. Esta topología ofrece redundancia de enlaces LAN tanto para el tráfico de usuario como para los mensajes keepalive de HA. Si uno de los puertos miembros del LAG falla, los otros puertos miembros continuarán transportando el tráfico de usuario y el tráfico keepalive de HA.

Esta topología proporciona tanto resiliencia de enlace como resiliencia de Socket y se considera una mejor práctica.

Para aprender más sobre LAG LAN, consulte Configuración de la Agregación de Enlaces para un Socket.

El siguiente diagrama es un ejemplo de topología de conectividad LAN para HA Socket utilizando un LAG LAN con una pila de conmutadores:

SocketHA_LAG.png

Puerto Dedicado para el Tráfico de Keepalive HA

En esta configuración, aísla el tráfico keepalive de HA del tráfico LAN. Puede asignar un único puerto (puertos LAN, WAN o USB) solo para el tráfico keepalive de HA mientras utiliza uno o más de los puertos LAN restantes para el tráfico LAN.

Para establecer el puerto LAN dedicado para el tráfico keepalive de HA, ajuste la Destination del puerto a VRRP. Luego, ajuste la opción HA link between sockets a Directo o Via Switch.

Direct_HA_Link.png

Estas son las configuraciones de puerto dedicado:

  1. Directo (cableado back-to-back entre los Sockets) – Con esta configuración, si el Socket secundario deja de recibir los mensajes keepalive de HA, se convierte en el Maestro, independientemente del estado del puerto VRRP.

  2. Via Switch – Con esta configuración, el puerto VRRP en ambos Sockets está conectado a un conmutador. El comportamiento de conmutación por error depende del estado del puerto VRRP del Socket secundario:                                                             

    1. Cuando el estado del puerto del Socket secundario está Conectado pero no recibe mensajes de keepalive, el Socket secundario se convierte en el Maestro.

      El Socket secundario asume que el estado es causado por una falla del Socket primario.

    2. Cuando el estado del puerto del Socket secundario está Desconectado, el Socket Secundario no se convierte en el Maestro (suponiendo que es un problema local entre él mismo y el conmutador).

      El Socket secundario asume que el Socket primario está operando correctamente y no se convierte en el Maestro para evitar una posible condición de cerebro dividido.

Estos son diagramas de las configuraciones de puerto dedicado directas y vía conmutador:

Socket_HA_-_Direct_Port_for_HA_Traffic.png
Socket_HA_-_via_Switch_Port_for_HA.png

Condiciones de Failover para la Alta Disponibilidad de Socket

La sección describe las condiciones que provocan una conmutación del Socket primario al Socket secundario.

Failover debido a la Falla del Socket Principal

Este escenario de conmutación es causado por una falla en el Socket primario. El Socket se considera que está en un estado de caída basado en una de estas razones:

  • Fallo general de Socket o pérdida de energía

  • Conectividad LAN (sin keepalive por más de tres segundos)

  • Sin conectividad a Internet por más de diez segundos

Failover debido a la Falla de Keepalive

También hay un escenario de conmutación por fallo que se produce cuando el Socket secundario no recibe mensajes keepalive del Socket primario durante un período de tres segundos.

Cuando el Socket secundario descubre que el Socket primario está caído, entonces cambia su estado a Maestro. Cato Cloud transfiere los flujos de tráfico a los enlaces WAN en el Socket secundario. El diagrama siguiente muestra este escenario.

Socket_HA_LAN_Failure.png

¿Los Problemas de Conectividad a Internet Causan un Failover del Socket?

Las Sockets utilizan un mecanismo de sondeo para determinar el estado de conectividad a Internet. Si el Socket primario determina que la conectividad a Internet está caída en todos los enlaces de Internet (enlaces Cato) durante más de 10 segundos, entonces deja de transmitir los mensajes keepalive HA. Esto provoca una conmutación por fallo al Socket secundario.

Nota

Nota: Es posible una situación donde el Socket primario tiene conectividad a Internet, sin embargo, todos los túneles DTLS están en estado DESCONECTADO. Debido a que las Sockets tienen mecanismos de recuperación de Internet y WAN, esta situación no desencadena una conmutación por fallo al Socket secundario. Estos mecanismos de recuperación permiten que el Socket se reconecte a un PoP diferente en el Cato Cloud.

Monitoreo de la Alta Disponibilidad de Socket

Esta sección discute diferentes páginas en la Cato Management Application que puedes usar para monitorear el estado y eventos para HA de Socket.

Mostrar el Status HA de Socket

Hay diferentes páginas en la Cato Management Application que muestran el estado de HA de la Socket para un sitio.

Nombre de la Página

Descripción

Ruta

Sitios

Muestra todos los sitios en la cuenta. La columna HA Status muestra el estado de HA de la Socket para cada sitio.

Network > Sites

Socket

Muestra los detalles de HA de la Socket para un sitio. Vea arriba Entendiendo la Alta Disponibilidad de Socket y el Failover.

Network > Sites > <site name> > Configuración del Sitio > Socket

Network Analytics

Muestra los datos de la red para un sitio y el HA Status.

Network > Sites > <site name> > Monitoreo del Sitio > Network Analytics

Eventos de Failover de Socket HA

Cada vez que ocurre una conmutación por fallo de Socket, cuando el Socket secundario está activo durante más de 35 segundos, se genera un evento de Conmutación por Fallo de Socket. Por ejemplo, si el Socket primario se actualiza a una nueva versión de Socket y el proceso de actualización dura 20 segundos, entonces no se genera un evento de Conmutación por Fallo de Socket porque el Socket secundario solo estuvo activo durante 20 segundos.

Puedes ver el evento en la Cato Management Application en la página Inicio > Eventos. Aquí hay un evento de ejemplo que muestra una conmutación por fallo del Socket primario al Socket secundario.

Failover.png

Definición de Notificaciones por Correo Electrónico para el Failover de Alta Disponibilidad de Socket

Puedes usar la página de Reglas de Salud de Enlaces (Network > Link Health Rules) para crear una Regla de Salud de Conectividad para enviar notificaciones por email para los eventos de conmutación por fallo de Socket HA. Las notificaciones por email se envían a todos los destinatarios en la Lista de Distribución que configures en la Cato Management Application. La Lista de Distribución puede incluir direcciones de email que no están definidas para usuarios y administradores en la Cato Management Application.

Este es un ejemplo de Regla de Salud de Conectividad para la conmutación por fallo de Socket:

Socket_Failover_Alert.png

Para más información sobre la configuración de una Regla de Salud de Conectividad, consulte Trabajando con Reglas de Salud de Enlace.

¿Fue útil este artículo?

Usuarios a los que les pareció útil: 15 de 17

0 comentarios