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

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 hasta el 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 nombres durante la implementación, se mostrará el siguiente error en el registro de errores

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

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

• Asegúrese de que el DNS predeterminado de Azure esté configurado tanto para la VNET como para los NIC asociados. Si el DNS predeterminado no está configurado en Azure tanto en la VNET como en el NIC, la creación de roles fallará.
• Para verificar cuál es la configuración de DNS de Azure, vea Solución de 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 Verificando la 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
  

Haciendo ping al IP flotante

• Desde el Socket WebUI, utilice la herramienta de Ping, seleccione la interfaz LAN y haga 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 

• 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 se asigna a los diferentes recursos virtuales que están conectados al vSocket. Los componentes en la infraestructura de Azure que utilizan 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 se puede verificar en Seguridad > Identidad > Asignado por usuario como puede ver en la captura de pantalla a continuación. No se debe asignar ningún rol asignado por el sistema a la VM.
• Si el rol de identidad HA no está instalado en ninguno de los recursos anteriores, es posible que el proceso de implementación haya fallado en hacerlo. Puede ejecutar el script de HA de Cato otra vez si el rol falta en cualquiera de los recursos involucrados. Alternativamente, se puede re-deploy el vSocket secundario de Azure, el 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 de DNS, consulte Solución de 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.

• 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 a continuación no muestra ningún NSG asignado, por lo que el tráfico de salida no está bloqueado.

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

• 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 a continuación muestra la ruta para el tráfico de internet utilizando Internet como el "Tipo de siguiente salto", por lo 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 revisar las páginas WebUI de ambos vSockets para confirmar el estado 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. Envía un ticket de soporte para informar de 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 cerebral ocurre cuando ambos vSockets tienen el rol de Maestro, lo cual puede suceder debido a problemas de conectividad LAN entre los vSockets que crean 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 la WebUI de ambos vSockets e identifique si los keepalives enviados por el primario están siendo recibidos por 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 de 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á utilizando la opción Predeterminado o un servidor DNS público. Apague la VM para realizar 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 Redecorar sitios de alta disponibilidad de vSocket
• 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 anteriores. Por favor incluya la siguiente información en el ticket:

• Una descripción clara del problema, 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 las IP flotantes asignadas y roles de identidad configurados.
• Capturas de pantalla del registro de actividad de Azure, incluyendo cualquier error encontrado.