Compartir vía

Solución de problemas de estado y disponibilidad de entrada de los recursos

  • Artículo

Este artículo sirve de guía para investigar los problemas que afectan a la disponibilidad de la IP de front-end y los recursos de back-end del equilibrador de carga.

La comprobación de Resource Health (RHC) para Azure Load Balancer se usa para determinar el estado del equilibrador de carga. Esta funcionalidad analiza la métrica de disponibilidad de la ruta de acceso de datos para determinar si los puntos de conexión de equilibrio de carga y las combinaciones de puertos de front-end e IP de front-end con reglas de equilibrio de carga están disponibles.

Nota: RHC no se admite para el equilibrador de carga de SKU básica

En la tabla siguiente se describe la lógica de RHC que se usa para determinar el estado de mantenimiento del equilibrador de carga.

Estado de mantenimiento de los recursos Descripción
Disponible El recurso de equilibrador de carga está listo y disponible.
Degradado El equilibrador de carga tiene eventos iniciados por el usuario o la plataforma que afectan al rendimiento. La métrica de disponibilidad de la ruta de acceso a los datos ha informado un mantenimiento de menos del 90 %, pero superior que el 25 %, durante al menos dos minutos. Es posible que esté experimentando una degradación del rendimiento de moderada a grave.
No disponible El recurso del equilibrador de carga no es correcto. La métrica de disponibilidad de la ruta de acceso a los datos ha informado un mantenimiento de menos del 25 % durante al menos dos minutos. Es posible que esté experimentando una degradación significativa del rendimiento o una falta de disponibilidad de la conectividad entrante. Puede haber eventos de usuario o plataforma que generan la falta de disponibilidad.
Unknown El estado de mantenimiento del recurso del equilibrador de carga no se ha actualizado ni ha recibido información sobre la disponibilidad de la ruta de datos en los últimos 10 minutos. Este estado puede ser transitorio o es posible que el equilibrador de carga no admita RHC.

Supervisión de la disponibilidad del equilibrador de carga

Las dos métricas que se van a usar son la disponibilidad de la ruta de acceso de datos y el estado de sondeo de estado, y es importante comprender su significado para obtener información correcta.

Disponibilidad de la ruta de acceso a datos

La métrica de disponibilidad de la ruta de acceso a datos se genera mediante un ping de TCP cada 25 segundos en todos los puertos de front-end que tienen configuradas reglas de equilibrio de carga. Este ping TCP se enruta a cualquiera de las instancias backend sanas (sondeadas). La métrica es una tasa de éxito porcentual agregada de pings de TCP en cada combinación IP:puerto de front-end para cada una de las reglas de equilibrio de carga, en un período de tiempo de ejemplo.

Situación de sondeo de estado

La métrica de estado del sondeo de estado se genera mediante un ping del protocolo definido en el sondeo de estado. Este ping se envía a cada instancia del grupo de back-end y del puerto definido en el sondeo de estado. En el caso de sondeos HTTP y HTTPS, un ping correcto requiere una respuesta HTTP 200 Correcto, mientras que en los sondeos TCP, cualquier respuesta se considera correcta. El estado de cada instancia de back-end se determina cuando el sondeo ha alcanzado el número de éxitos consecutivos o errores necesarios, en función de la configuración de la propiedad de umbral de sondeo. El estado de mantenimiento de cada instancia de back-end determina si la instancia de back-end puede recibir tráfico o no. De forma similar a la métrica de disponibilidad de la ruta de acceso a datos, la métrica de estado del sondeo de estado agrega el promedio de pings correctos o totales durante el intervalo de muestreo. Este valor del estado de sondeo de estado indica el estado del back-end en aislamiento del equilibrador de carga, mediante el sondeo de las instancias de back-end sin enviar tráfico a través del front-end.

Importante

El estado de sondeo de estado se muestra cada minuto. Esto puede dar lugar a fluctuaciones menores en un valor que, en otro caso, sería constante. Por ejemplo, en escenarios activos/pasivos donde hay dos instancias de back-end, una sondeada como correcta y otra como incorrecta, el servicio de sondeo de estado puede capturar 7 muestras para la instancia correcta y 6 para la instancia incorrecta. Esto hará que un valor 50, previamente constante, se muestre como 46,15 para un intervalo de un minuto.

Diagnóstico de equilibradores de carga degradados y no disponibles

Como se indica en el artículo sobre el estado de los recursos, un equilibrador de carga degradado es aquel que muestra entre un 25% y un 90% de disponibilidad de la ruta de datos. Un equilibrador de carga no disponible es uno con menos del 25 % de disponibilidad de la ruta de acceso de datos, durante un período de dos minutos. Se pueden seguir estos mismos pasos para investigar los errores observados en cualquier estado de sondeo de estado o alertas de disponibilidad de ruta de acceso a datos que haya configurado. Exploraremos el caso en el que comprobamos el mantenimiento de los recursos y encontramos que el equilibrador de carga tiene una disponibilidad de la ruta de acceso a datos del 0 %; es decir, nuestro servicio está inactivo.

En primer lugar, vamos a la vista de métricas detalladas de nuestra página de información del equilibrador de carga en Azure Portal. Acceda a la vista desde la página de recursos de su equilibrador de carga o desde el enlace del mensaje de estado de sus recursos. Después, vaya a la pestaña de disponibilidad de front-end y back-end y revise una ventana de treinta minutos del período de tiempo en el que se produjo el estado de degradación o de no disponibilidad. Si vemos que la disponibilidad de la ruta de acceso a los datos ha sido del 0 %, sabemos que hay un problema que impide el tráfico para todas nuestras reglas de equilibrio de carga, y se puede ver cuánto tiempo ha durado este problema.

Lo siguiente que necesitamos mirar es nuestra métrica de estado de sondeo de estado para determinar si la ruta de acceso a los datos no está disponible porque no tenemos instancias de back-end correctas para atender el tráfico. Si tenemos al menos una instancia de back-end correcta para todas nuestras reglas de equilibrio de carga y de entrada, sabemos que no es nuestra configuración la causa de que las rutas de acceso de datos no estén disponibles. Este escenario indica un problema de la plataforma Azure. Aunque los problemas de la plataforma son poco frecuentes, se envía una alerta automatizada a nuestro equipo para resolver rápidamente todos los problemas de la plataforma.

Diagnóstico de errores de sondeo de estado

Si la métrica de estado del sondeo de estado refleja que las instancias de back-end son incorrectas, se recomienda seguir la siguiente lista de comprobación para descartar errores de configuración comunes:

  • Compruebe el uso de la CPU de los recursos para determinar si están bajo una carga alta.
  • Si se usa una comprobación de sondeo HTTP o HTTPS, si la aplicación es correcta y responde.
    • Valida que la aplicación sea funcional accediendo directamente a las aplicaciones a través de la dirección IP privada o la dirección IP pública de nivel de instancia asociada a la instancia de back-end.
  • Revise los grupos de seguridad de red que se aplican a nuestros recursos de back-end. Asegúrese de que no existen reglas de prioridad superior a AllowAzureLoadBalancerInBound que bloqueen la sonda de salud.
    • Para ello, visite la hoja de redes de las máquinas virtuales de back-end o Virtual Machine Scale Sets.
    • Si existe este problema de NSG, mueva la regla de permiso existente o cree una nueva regla de prioridad alta para permitir el tráfico de AzureLoadBalancer.
  • Compruebe el sistema operativo. Asegúrese de que las máquinas virtuales están escuchando en el puerto de sondeo y revise las reglas de firewall del sistema operativo para asegurarse de que no estén bloqueando el tráfico de sondeo procedente de la dirección IP168.63.129.16.
    • Puede comprobar los puertos de escucha ejecutando netstat -a desde un símbolo del sistema de Windows o netstat -l desde un terminal de Linux.
  • Asegúrese de que esté utilizando la dirección URL correcta. Por ejemplo, se produce un error en un sondeo mediante HTTP para sondear un puerto que escucha una aplicación que no es HTTP.
  • Azure Firewall no debe colocarse en el grupo de back-end de equilibradores de carga. Consulte Integración de Azure Firewall con Azure Standard Load Balancer para integrar correctamente Azure Firewall con el equilibrador de carga.

Pasos siguientes