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) de 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 durante un intervalo de 2 minutos 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 Standard Load Balancer está listo y disponible.
Degradado El equilibrador de carga estándar 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. Experimenta una degradación moderada a grave del rendimiento.
No disponible El recurso del equilibrador de carga estándar no está en buen estado. 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. Experimenta 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 salud del recurso del equilibrador de carga estándar no se ha actualizado ni ha recibido información sobre la disponibilidad de la ruta de datos en los últimos 10 minutos. Este estado debe ser transitorio y reflejará el estado correcto en cuanto se reciban dichos datos.

Acerca de las métricas que se van a usar

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 mantenimiento, y es importante comprender su significado para obtener información correcta.

Disponibilidad de la ruta de acceso de datos

La métrica de disponibilidad de la ruta de acceso de datos se genera mediante un ping de TCP cada 25 segundos en todos los puertos de front-end que tienen configuradas reglas NAT de entrada y de equilibrio de carga. Este ping TCP se enruta a cualquiera de las instancias backend sanas (sondeadas). Si el servicio recibe una respuesta al ping, se trata de una respuesta correcta y la suma de la métrica se itera una vez. Si no hay respuesta, no se produce ninguna iteración. El recuento de esta métrica es 1/100 del total de pings de TCP por período de muestra. Por lo tanto, queremos considerar la media, que es el promedio de suma/conteo para el periodo de tiempo. La métrica de disponibilidad de la ruta de acceso de datos agregada por promedio nos ofrece un porcentaje de tasa de éxito para los pings de TCP en la dirección IP:puerto de front-end para cada una de las reglas NAT de entrada y de equilibrio de carga.

Estado del sondeo de mantenimiento

La métrica de estado del sondeo de mantenimiento 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. Los éxitos o errores consecutivos de cada sondeo determinan el estado de la instancia de back-end y si el grupo de back-end asignado puede recibir tráfico. De manera similar al caso de la disponibilidad de la ruta de acceso de datos, usamos la agregación de promedio, que nos indica el promedio de pings correctos y totales durante el intervalo de muestreo. Este valor del estado de sondeo de mantenimiento 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 mantenimiento se muestra cada minuto. Esto puede dar lugar a fluctuaciones menores en un valor que, en otro caso, sería constante. Por ejemplo, si 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 mantenimiento o alertas de disponibilidad de ruta de acceso de 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 de 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 NAT de entrada y de equilibrio de carga, y se puede ver cuánto tiempo ha durado este impacto.

Lo siguiente que necesitamos mirar es nuestra métrica de estado de sondeo de mantenimiento 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

Supongamos que comprobamos el estado de sondeo de mantenimiento y encontramos que todas las instancias aparecen como incorrectas. Esto explica por qué nuestra ruta de acceso a datos no está disponible, ya que el tráfico no tiene ninguna instancia a la que ir. Debemos recorrer la siguiente lista de comprobación para descartar los 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.
    • Validar que la aplicación es 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.

Si ha recorrido esta lista de comprobación y todavía se producen errores de sondeo de estado, puede haber problemas de plataforma poco frecuentes que afecten al servicio de sondeo para las instancias. En este caso, Azure le respaldará. Se envía una alerta automatizada a nuestro equipo para resolver rápidamente todos los problemas de la plataforma.

Pasos siguientes