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.
Para más información sobre AWS vSocket HA, consulte Configuración de HA para AWS vSockets
Para más información sobre Azure vSocket HA, consulte Configuración de Alta Disponibilidad para Azure vSockets
Alta Disponibilidad de Socket y Diferentes Modelos de Socket
Los sitios de HA de Socket pueden usar dos Sockets con el mismo tipo de Socket X1500, X1600, X1600 LTE, X1600 WiFi o X1700. Sin embargo, no se pueden usar diferentes tipos de Socket, por lo que un sitio con un Socket X1600 y un Socket X1700 no es soportado.
Puede usar en el mismo sitio HA:
Cualquier dos modelos de Socket X1500 A/B/C
Modelos de Socket X1700A y X1700B
Solo modelos de Socket X1700C
No puede usar un Socket X1600 LTE y un Socket X1600 WiFi 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.
El Socket secundario (en Respaldo) monitorea continuamente el estado (vitalidad) del Socket Maestro escuchando los mensajes periódicos de keepalive que envía el Socket primario. Los mensajes de keepalive se envían a través de la interfaz designada con el destino establecido a LAN & VRRP o VRRP (ver más abajo Conectividad LAN y Socket HA).
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.
El Socket secundario envía un mensaje GARP a las redes LAN para acelerar la convergencia de Capa 2.
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:
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
|
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 Maestro. Cato Cloud transfiere los flujos de tráfico a los enlaces WAN en el Socket secundario.
|
|
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):
El PoP detecta que el Socket secundario ahora es el Master.
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):
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 Socket HA, el Socket secundario se convierte en el nuevo Maestro, y el PoP cambia 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.
El despliegue predeterminado usa enrutadores entre el Socket y el ISP. Sin embargo, es posible personalizar el despliegue del sitio para conectar el Socket al PoP sin un enrutador - por favor contacte a su representante oficial de Cato para más información.
A continuación se muestran ejemplos de topologías físicas y lógicas para el HA Socket:
Para una conectividad WAN, rendimiento y funcionalidad HA óptimos, Cato recomienda un diseño de cableado simétrico (espejado) 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.
Nota:
Para configuraciones estándar de HA, Cato recomienda usar un diseño simétrico tanto para los Sockets Primarios como para los Secundarios.
Al usar LTE, hay escenarios en los que podría querer usar tarjetas SIM de diferentes operadores para asegurar una mejor cobertura o usar una tarjeta SIM solo en el Socket secundario.
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:
Puerto LAN único
Múltiples puertos LAN
Agregación de enlace LAN (opción recomendada)
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 conmutación por error de HA Socket (cuando el Socket secundario se convierte en el Maestro) solo ocurre cuando se cumplen ambas condiciones:
El Socket secundario deja de recibir los mensajes keepalive de HA del Socket primario durante un período de tres segundos.
El puerto LAN en el Socket secundario (que se utiliza para los mensajes keepalive de HA) 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.
El siguiente diagrama muestra una topología de HA Socket con un único puerto LAN en cada Socket conectado a un conmutador:
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 utiliza tanto para el tráfico keepalive HA como para el tráfico de usuarios. Los puertos LAN restantes solo transportan el tráfico de usuarios.
Puede elegir cualquier puerto LAN para el tráfico de keepalive HA cambiando el Destino 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 de keepalive HA y para el tráfico de usuario.
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 Socket (cuando el Socket secundario se convierte en el Maestro) solo ocurre cuando se cumplen ambas condiciones:
El Socket secundario deja de recibir los mensajes keepalive de HA del Socket primario durante un período de tres segundos.
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 primarios como los secundarios están conectados a los switches LAN a través de dos o más puertos LAN agrupados en una agregación de enlaces (LAG). Con esta configuración, deben usarse 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:
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.
Estas son las configuraciones de puerto dedicado:
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.
Via Switch – Con esta configuración, el puerto VRRP en ambos Sockets está conectado a un conmutador. El comportamiento de failover depende del estado del puerto VRRP del Socket secundario.
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.
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:
|
|
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 en un estado abajo basado en una de estas razones:
Fallo general de Socket o pérdida de energía
Conectividad VRRP (sin keepalive durante más de tres segundos)
Una pérdida de conectividad del lado LAN no desencadena un cambio a menos que se intercambien anuncios de VRRP a través del enlace LAN.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.
¿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:
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. | Red > Sitios |
Zócalo | 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.
Definición de notificaciones para conmutación por error en Alta Disponibilidad de Socket
Puede usar la página de reglas de salud de enlace (Red > Reglas de salud de enlace) para crear una regla de salud de conectividad para enviar notificaciones de los eventos de conmutación por error de la HA de Socket.
Las notificaciones se envían a todos los destinatarios definidos en el grupo de suscripción que configure en el CMA. Un Grupo de Suscripción puede incluir diferentes objetivos de notificación, tales como:
Listas de correo con direcciones de correo electrónico (incluidas las direcciones no asociadas con usuarios o administradores de Cato)
Integraciones de Webhook como Slack o Jira
Sistemas de notificación de terceros
Esto le permite gestionar todos los destinos de notificación desde una única ubicación y aplicarlos de manera consistente a través de múltiples reglas.
Este es un ejemplo de Regla de Salud de Conectividad para la conmutación por fallo de Socket:
Para más información sobre la configuración de una Regla de Salud de Conectividad, consulte Trabajando con Reglas de Salud de Enlace.