Solución de problemas de Azure HA vSocket

"Visión general"

Este artículo proporciona información sobre problemas comunes de implementación de Azure vSocket HA y ofrece pasos de solución de problemas para resolverlos. Esta guía tiene como objetivo ayudar a identificar y abordar posibles obstáculos durante y después de implementar la solución HA, ya sea a través del script HA o el Marketplace.

Síntomas

Al implementar Azure vSocket HA, puede encontrar los siguientes síntomas:

• Fallo del script HA

  • Fallo al ejecutar el script create_ha_settings en la implementación manual.

  • Problemas con la implementación del vSocket secundario a través del Marketplace.

• Fallo de conmutación por error HA

  • Fallo de las pruebas de HA API desde el Socket WebUI.

  • Falló la conmutación por error de HA, lo que resulta en que el tráfico no se redirija al vSocket secundario.

• Estado HA no listo

  • CMA muestra que el estado HA del sitio no está listo

Causas posibles

Las causas más frecuentes de fallos en la implementación de HA incluyen:

• Uso de DNS no público en Azure.

• La interfaz de gestión no tiene acceso a internet.

• Permisos insuficientes de cuenta de Azure.

• Configuraciones restrictivas de Grupo de Seguridad y Enrutamiento en Azure.

• Fallo al asignar la dirección IP flotante a la interfaz LAN.

• Problemas de conectividad LAN.

Solucionar el problema

Importante:

IMPORTANTE: Antes de comenzar a solucionar problemas, asegúrate de verificar todos los requisitos previos para el despliegue de Azure HA vSocket. Consulte Configurar HA para vSockets de Azure y Implementar Azure vSockets desde el Marketplace

Solucionar el fallo del script HA

El script de Azure HA (create_ha_settings) y la implementación del vSocket secundario a través del Marketplace verifican que la suscripción de Azure tenga dos vSockets válidos y luego asignan los Roles de Identidad que crean el mecanismo HA y de conmutación por error. Si la ejecución del script falla, siga estos pasos de solución de problemas:

Revisión de registros de actividad

• En Azure, los Registros de Actividad almacenan todos los eventos que sucedieron dentro de cada recurso de Azure. Revise estos registros si la implementación no es exitosa y no se asigna uno de los roles. Navegue a la VM o el NIC y seleccione el registro de actividad
  

Verificación de restricciones de nombres de Azure 

• Al ingresar el Nombre del vSocket en el script, asegúrese de que el nombre no incluya espacios o caracteres restringidos según se explica en Reglas y restricciones de nombres.

• Si ocurre un problema de nombre durante el despliegue, se mostrará el siguiente error en el registro de errores.

  El valor del parámetro disk.name es inválido. (Código: InvalidParameter, Objetivo: disk.name)

Verificación de la configuración de DNS de Azure

• Asegúrese de que un DNS público (o el DNS predeterminado de Azure) esté configurado tanto para la VNET como para los NIC asociados. Si un DNS público no está configurado en Azure en tanto la VNET como el NIC, la creación del Rol fallará.

• Para saber cuál es la configuración de DNS de Azure, consulte Resolver problemas de configuración de DNS 

Verificación de permisos de Azure

• Para ejecutar con éxito el script HA, asegúrese de que el usuario de Azure tenga permisos de propietario. Vaya a Grupo de Recursos > Control de Acceso IAM > Ver Mi Acceso, y verifique que la cuenta de usuario esté configurada como Propietario o un rol superior. Consulte Roles integrados de Azure.
  

Verificación de asignación de roles de Azure 

• Ejecute los pasos proporcionados en Verificación de asignación de roles de Azure para confirmar que el rol de identidad listado en el grupo de recursos esté asignado a los NIC LAN, subredes LAN, y a ambas máquinas virtuales vSocket.

Volver a ejecutar el script HA

• Como último recurso, el script HA (create_ha_settings) se puede volver a ejecutar una vez que se hayan verificado los pasos anteriores.

• Asegúrese de renovar el token de Azure y eliminar la Identidad Administrada de Azure si se creó durante la primera ejecución del script.

Solución de problemas de fallo de conmutación por error HA

Si el script HA se ejecuta correctamente pero la conmutación por error de vSocket HA no ocurre como se esperaba (por ejemplo, el tráfico no se enruta al vSocket secundario), siga estos pasos:

Ejecutar prueba de API HA

• Desde el Socket webUI, ejecute la herramienta de prueba de API desde ambos vSockets, la cual valida que la llamada API a Azure se pueda realizar con éxito. Aquí se pueden ver cualquier error con permisos o asignaciones de IP flotantes.
  

Revisión del registro de actividades

• En Azure, los Registros de Actividad almacenan todos los eventos que sucedieron dentro de cada recurso de Azure. Revise estos registros para identificar si el IP flotante no se pudo enviar al NIC LAN o si la prueba de API no tuvo éxito. Navegue al NIC y seleccione el registro de actividad
  

(Opcional) Haciendo ping al IP Flotante

• Desde un host dentro de la red LAN, utiliza la herramienta Ping y haz ping a la Dirección IP Flotante. Si esta prueba no tiene éxito, continúe con Verificando la asignación de IP flotante
  

Verificando la asignación de IP flotante

• Para enrutar el tráfico al vSocket maestro, Azure asigna el IP flotante al NIC LAN del vSocket maestro actual. Vaya a la VM principal del vSocket NIC LAN > Configuración de IP y verifique que el IP flotante exista como "Secundario". Si no es así, continúe con los siguientes pasos.  

Verificación de asignación de roles de Azure 

La Identidad Gestionada HA debe estar correctamente asociada con todos los recursos de Azure que participan en el failover.

• Durante la implementación de Azure vSocket, el Rol de Identidad HA se crea y almacena en Azure Identidades Administradas.

• Solo un rol asignado por usuario debe ser asignado a cada recurso. Si una política agrega identidades asignadas por el sistema en Azure, los vSockets deben ser excluidos de ella.

• Este rol está asignado a los diversos recursos virtuales conectados al vSocket. Los componentes en la infraestructura de Azure que usan el rol son:

  • Interfaz de Red (NIC) LAN para cada vSocket

  • La subred LAN asociada con los NICs LAN

  • Ambas máquinas virtuales vSocket

• La asignación de roles para los NICs se puede verificar en Control de acceso > Asignaciones de Roles y debe ser asignada tanto para los NICs LAN principal como secundario.
  

• La asignación de roles para la subred LAN se puede verificar en VNET > Subred, luego seleccionar la subred LAN y hacer clic en Gestionar usuarios > Asignaciones de Roles.
  

• Para cada VM de vSocket, el rol de identidad puede comprobarse en Seguridad > Identidad > Asignado a usuario, como se muestra en la captura de pantalla abajo.

• No system-assigned role should be assigned to the VM. Para verificar esto, navegue a Seguridad > Identidad > Asignado por el sistema y asegúrese de que la opción de Estado esté ajustada a Off para cada VM de vSocket.

• Si el rol de identidad HA no está instalado en ninguno de los recursos mencionados, el proceso de despliegue puede haber fallado en hacerlo. Puede ejecutar el script de HA de Cato otra vez si falta el rol en cualquiera de los recursos involucrados. Alternativamente, el vSocket secundario de Azure se puede re-deploy , lo cual instalará los roles de identidad HA faltantes.

Verificando que la interfaz de gestión tenga acceso a DNS e internet

• Verifique que la interfaz de gestión tenga acceso a internet y pueda conectarse al servidor DNS configurado.

• Verifique la resolución de DNS para management.azure.com desde el portal de Azure. La llamada API de HA usa este FQDN.

  • Vaya a la Máquina virtual > vSocket > Ejecutar comando > RunShellScript

  • Ingrese dig management.azure.com en el cuadro de texto

  • Haga clic en Ejecutar

• La salida de dig se mostrará en el portal con una respuesta DNS.
  

• Si no hay resolución DNS, consulte Resolver problemas de configuración de DNS.

• Desde la misma página, intente acceder a cualquier recurso de internet para confirmar el acceso a internet. Por ejemplo, ping -c 4 8.8.8.8 Si el ping no tiene éxito, continúe con los próximos pasos.
  

Verifique si el Grupo de Seguridad de la Red está bloqueando el tráfico saliente.

Nota:

Si se implementa la solución de 2-NICs en los vSockets. Realice este paso de solución de problemas en la interfaz WAN.

• Una forma rápida de verificar es ir a la interfaz de red MGMT en Azure y hacer clic en "Reglas de seguridad efectivas" en la parte inferior izquierda de la pantalla.

• La captura de pantalla abajo muestra que no hay NSG asignado, por lo que el tráfico saliente no está bloqueado.

Verifique el enrutamiento de la interfaz MGMT para el tráfico de Internet.

Nota:

Si se implementa la solución de 2-NICs en los vSockets. Realice este paso de solución de problemas en la interfaz WAN.

• En caso de que el tráfico de la interfaz MGMT se enrute a través de un firewall de terceros en Azure, verifique que se permitan las conexiones salientes UDP/53 y TCP/443.

• La tabla de enrutamiento se puede revisar en la página de interfaz de gestión en Azure haciendo clic en la opción "Rutas efectivas".

• La captura de pantalla abajo muestra la ruta del tráfico de Internet usando Internet como "Tipo de siguiente salto", de modo que un firewall no está bloqueando el tráfico.
  

Revisando el siguiente salto de la tabla de rutas

• Confirme que la tabla de enrutamiento LAN apunte al IP flotante. Cambie la dirección IP de siguiente salto según sea necesario.  

Solucionar problemas de estado HA no listo

Si CMA muestra que el estado HA no está listo y ambos vSockets están en funcionamiento, ambos vSockets asumirán el rol de Maestro (escenario de división de cerebro). Podría haber dos problemas asociados:

• Ambos vSockets están ejecutando diferentes versiones de firmware

• Los mensajes HA Keepalive 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 división de cerebro se manifestará si tanto el vSocket primario como el secundario están en un rol de Maestro. El webUI mostrará el rol actual en la parte superior de la página principal de Monitoreo.

Revisión de versiones de firmware

Para satisfacer los criterios de versión compatible, ambos vSockets deben ejecutar la misma versión MAYOR, por ejemplo, v17.xx.yy o v18.xx.yy. Los vSockets realizan una actualización inicial tras ser desplegados por primera vez. Si uno de los vSockets no logra actualizarse, este problema debe solucionarse. Enviar un ticket de soporte para informar sobre este problema.

Verificación de HA Keepalives

Los paquetes de Keepalive usan el puerto UDP/20480 para Azure vSocket y serán enviados solo desde el vSocket Maestro al vSocket en Espera. La condición de división de la red ocurre cuando ambos vSockets tienen el rol de Maestro, lo cual puede suceder debido a problemas de conectividad LAN entre los vSockets, creando una situación en la que los mensajes de Keepalive de HA no llegan al vSocket secundario.

Ejecute las siguientes verificaciones para confirmar la conectividad LAN:

• Verifique si el Grupo de Seguridad de Red está bloqueando el puerto UDP/20480. Una manera rápida de verificar las reglas de NSG es ir a cada interfaz de red LAN en Azure y hacer clic en "Reglas de seguridad efectivas" en la parte inferior izquierda de la pantalla.

• Confirme que ambas interfaces LAN están asociadas con la misma subred LAN.

• Ejecute una captura de paquetes desde el WebUI de ambos vSockets e identifique si los keepalives enviados por el primario se reciben en el vSocket secundario.

Resolución de problemas descubiertos

Renovación de token de Azure

• Si se utiliza Azure Cloud Shell para implementar el script de HA, abra una nueva sesión y vuelva a autenticar. Esto renovará el token utilizado para consultar la API.
  

Corrección de problemas de configuración de DNS

• Para corregir la configuración DNS de Azure y establecerla en el valor predeterminado, vaya a Red virtual > Servidores DNS y a Interfaz de red > Servidores DNS, y asegúrese de que está usando la opción Predeterminado o un servidor DNS público. Apague la VM para hacer cualquier cambio relacionado con DNS y luego vuelva a encenderla.
  

Desregistro y rediseño de un vSocket de Azure

• Si después de seguir todos los pasos de solución de problemas anteriores, el script de HA o el conmutador por error de HA continúan fallando, es posible anular el registro y rediseñar uno o ambos vSockets. Consulte Redistribuir sitios de vSocket de alta disponibilidad

• Es importante seguir las directrices y eliminar la máquina virtual, interfaces de red, IPs públicas asociadas e identidad gestionada antes de volver a implementar un vSocket.

• Si solo se redistribuye la instancia primaria de vSocket, debe ejecutar el script dedicado de HA (create_ha_settings) para vincular ambas instancias de vSocket para HA.

Presentación de casos al soporte de Cato

Envíe un ticket de Soporte con los resultados de los pasos de solución de problemas mencionados anteriormente. Incluya la siguiente información en el ticket:

• Una descripción clara de los problemas, incluyendo cualquier mensaje de error.

• Resultados de la prueba de DNS para management.azure.com

• Resultados de la prueba de API.

• Capturas de pantalla de la IP flotante asignada, rol de identidad activo, rutas efectivas y reglas de seguridad efectivas.

• Capturas de pantalla del registro de actividad de Azure, incluyendo cualquier error encontrado.