Resolución de problemas de AWS HA vSocket

Visión general

Esta guía ofrece un marco detallado para la resolución de problemas comunes encontrados durante la implementación de la alta disponibilidad (HA) del AWS vSocket. Ya sea que se implemente manualmente o a través del AWS Marketplace, estos pasos tienen como objetivo ayudar a identificar y resolver problemas potenciales de manera efectiva.

Síntomas

Los problemas comunes en implementaciones de AWS vSocket HA pueden incluir:

• Fallo en el cambio por error de HA
  • Pruebas de API de HA fallidas desde el WebUI de vSocket.
  • Error en el cambio por error de HA, resultando en que el tráfico no se redirige al vSocket secundario.
• Estado de HA no listo
  • CMA muestra el status de HA del sitio como "No listo"

Causas posibles

Las fallas de implementación de HA a menudo se deben a lo siguiente:

• Uso de DNS no público en AWS.
• Interfaz de gestión sin acceso a internet.
• Mala configuración del rol de IAM.
• Configuración restrictiva del Grupo de Seguridad y enrutamiento en AWS.
• Fallo al asignar la interfaz de red adecuada a la tabla de enrutamiento de la LAN.
• Problemas de conectividad LAN.

Solución del problema

Resolución de fallo en el cambio por error de HA

Si el tráfico no se redirige al vSocket secundario durante el cambio por error, considere los siguientes pasos para resolver el problema:

Ejecutar la Prueba de API de HA

• Desde el WebUI de vSocket, ejecute la herramienta de Prueba de API para ambos vSockets.
• Esta herramienta valida que se pueda realizar exitosamente la llamada de API a AWS.
• Cualquier error relacionado con permisos o actualizaciones de la tabla de enrutamiento puede verse aquí.
  

Verificar la configuración de DNS de AWS

• Verifique que el servidor DNS de AWS predeterminado esté configurado para la VPC asociada. 
• Para verificar la configuración de DNS de AWS, consulte Resolver problemas de configuración de DNS
• Si se configura un servidor DNS personalizado (por ejemplo, un servidor DNS privado), asegúrese de que pueda resolver dominios públicos. Verifique que pueda resolver el FQDN ec2.<region>.amazonaws.com (por ejemplo, ec2.us-east-1.amazonaws.com), que es utilizado por la API.
• El Grupo de Seguridad asociado con la interfaz de MGMT debe permitir solicitudes DNS a 8.8.8.8 y 8.8.4.4, incluso si el servidor DNS de AWS predeterminado está configurado.

Verificando la Tabla de Enrutamiento LAN

• Para redirigir el tráfico al vSocket principal, AWS asigna la interfaz de red LAN del vSocket principal actual a la tabla de enrutamiento de LAN.
• Vaya a VPC > Tablas de rutas y seleccione la tabla de enrutamiento LAN. En la pestaña Rutas, verifique que la interfaz de red LAN del vSocket principal sea la puerta de enlace (objetivo) de la ruta predeterminada. Si no es así, continúe con los siguientes pasos.
• Tenga en cuenta que modificar manualmente la tabla de enrutamiento de LAN puede ser una solución rápida si el objetivo NIC no se cambió durante el cambio por error.

Verificando rol de IAM

• Durante la implementación de vSocket en AWS, se crea el rol de IAM HA y se asocia con ambos vSockets, primario y secundario.
• En la página de detalles de cada instancia, confirme que se haya asignado el IAM Role correcto.
• Haga clic en el enlace de rol de IAM y, en la pestaña de permisos, verifique que la política de IAM contenga la declaración correcta, como se muestra a continuación.

Nota: En caso de que falte un rol de IAM, una vez que se agregue el rol, los sockets deben reiniciarse para que los roles añadidos surtan efecto.

Verificación de configuraciones de IMDS

• Asegúrate de que ambas direcciones de vSockets usen configuraciones de IMDS coincidentes (opcional o requerido). Para más información, revisa documentación de AWS.
• A partir de la compilación vSocket 20.0.18221, se admite IMDSv2.
• Para modificar las configuraciones de IMDS, seleccione la instancia y, bajo acciones, haga clic en Configuración de la instancia > Modificar opciones de metadatos de la instancia.

Verificar el grupo de seguridad de la red.

• Asegúrese de que el grupo de seguridad de la red no esté bloqueando el tráfico saliente a la interfaz de gestión.
• Bajo EC2 > Interfaces de red, busque el Grupo de Seguridad asociado con la Interfaz de Gestión.
  
• Verifica que las reglas de salida del Grupo de Seguridad permitan los puertos 80, 443 y 53. En este caso, todo el tráfico saliente está permitido.
   
  

Verificación de la interfaz de MGMT para el tráfico de Internet.

• Si el tráfico de la interfaz de MGMT se redirige a través de un firewall de terceros en AWS, verifique que se permitan las conexiones salientes UDP/53, TCP/80 y TCP/443.
• Desde la página de la interfaz de red, haga clic en el ID de Subnet de la interfaz de MGMT.
  
• En la página de Subnet, seleccione la pestaña Tabla de Rutas. La captura de pantalla a continuación muestra la ruta predeterminada apuntando a la Puerta de enlace de Internet, por lo que un firewall no está bloqueando el tráfico.
  
• Abra la Tabla de Rutas relacionada y verifique que todas las subredes de MGMT estén listadas como subredes asociadas. En el caso de zona de disponibilidad dual, existirán dos subredes de MGMT, una para cada vSocket, como se explica en Creación de una subred para las interfaces LAN del vSocket secundario.
• En la pestaña Mapa de Recursos del VPC, se representan visualmente para fácil referencia todas las subredes asociadas y sus configuraciones de enrutamiento.
• Confirme que una IP elástica esté asociada con la interfaz de MGMT. Esto puede verse desde la pestaña de red de la instancia. La interfaz de MGMT puede identificarse por su índice de dispositivo de 0. Las interfaces WAN y LAN deben estar asociadas con índices de dispositivo 1 y 2, respectivamente.

Verificando registros de CloudTrail

• Habilite AWS CloudTrail para registrar llamadas de API a AWS para depurar modificaciones fallidas de la tabla de enrutamiento de LAN durante el cambio por error de HA.
• Puede seguir el proceso para crear un rastro, definir el bucket S3 para almacenar los registros y seleccionar eventos de gestión que incluyan actividad de API. Consulte Crear un rastro.
  

Resolución de estado de HA no listo

Si CMA muestra que el Estado de HA no está listo y ambos vSockets están funcionando, ambos vSockets asumirán el rol de Maestro (escenario de cerebro dividido). Esto puede ocurrir debido a:

• Ambos vSockets están ejecutando diferentes versiones de firmware
• Los mensajes de Keepalive de HA no llegan al vSocket secundario

Se recomienda verificar las páginas de WebUI de ambos vSockets para confirmar el estado de HA de cada uno de ellos. Un escenario de cerebro dividido se manifestará si tanto el vSocket primario como el secundario están en el rol de Maestro. El WebUI mostrará el rol actual en la parte superior de la página principal de Monitoreo.

Verificación de versiones de firmware

Para cumplir con los criterios de versión compatible, ambos vSockets deben ejecutar la misma versión PRINCIPAL, por ejemplo, v17.xx.yy o v18.xx.yy. Los vSockets realizan una actualización inicial después de ser desplegados por primera vez. Si uno de los vSockets no se actualiza, este problema debe ser solucionado. Enviar un ticket de soporte para informar sobre este problema.

Verificación de Keepalives de HA

Los paquetes de Keepalive utilizan el puerto UDP/20480 para AWS vSocket y solo serán enviados desde el vSocket Maestro al vSocket en espera. La condición de cerebro dividido ocurre cuando ambos vSockets tienen el rol de Maestro, lo que puede suceder debido a problemas de conectividad LAN entre los vSockets que generan una situación en la que los mensajes Keepalive de HA no llegan al vSocket secundario. 

Ejecute las siguientes verificaciones para confirmar la conectividad LAN:

• Comprueba si el Grupo de Seguridad de la Red está bloqueando el puerto UDP/20480. Una forma rápida de comprobar las reglas del NSG es ir a cada interfaz de red LAN en AWS y verificar las reglas entrantes y salientes como se explica en Comprueba si el Grupo de Seguridad de Red está bloqueando el tráfico saliente.
• Confirma que ambas direcciones de interfaces LAN están asociadas con diferentes subredes LAN.
• Ejecute una captura de paquetes desde el WebUI de ambas direcciones de vSockets e identifique si el vSocket secundario está recibiendo los keepalives enviados por el primario.

Resolución de problemas descubiertos

Solucionar problemas de configuración de DNS

• Para solucionar problemas de configuración de DNS, verifique que el servidor DNS de AWS predeterminado esté configurado para la VPC.
• En los detalles de VPC, encuentre el conjunto de opciones DHCP configurado para él.
• Abra el conjunto de opciones DHCP y verifique que el servidor de nombre de dominio definido sea AmazonProvidedDNS.
• No es posible cambiar los servidores de nombre de dominio existentes. Para eso, cree un nuevo conjunto de opciones DHCP, que usará AmazonProvidedDNS por defecto.

Desregistrar y volver a implementar un AWS vSocket

• Si después de seguir todos los pasos de solución de problemas mencionados, el cambio por error de HA sigue fallando, es posible desregistrar y volver a implementar uno o ambos vSockets. Consulte Volver a implementar sitios vSocket de alta disponibilidad
• Es importante eliminar la máquina virtual pero retener las interfaces de red, IPs públicas asociadas y el rol de IAM antes de volver a implementar un vSocket.
• Además, recuerde reanexar el rol de IAM correcto al vSocket seleccionando la instancia de vSocket > Seguridad > Adjuntar rol de IAM y asignando el rol AWS-HA.

Creación de casos para el soporte de Cato

Envíe un ticket de soporte con los resultados de los pasos de solución de problemas anteriores. Por favor incluya la siguiente información en el ticket:

• Una descripción clara del problema, incluidos errores.
• Configuración DNS en el VPC.
• Resultados de la prueba de API.
• Capturas de pantalla de la tabla de enrutamiento LAN y los roles IAM configurados.
• Si es posible, archivos de registro de CloudTrail en el momento del fallo del cambio por error.