Compartir vía

Sondeos de estado de Azure Load Balancer

  • Artículo

Un sondeo de estado de Azure Load Balancer es una característica que detecta el estado de mantenimiento de las instancias de la aplicación. Envía una solicitud a las instancias para comprobar si están disponibles y responden a las solicitudes. El sondeo de estado se puede configurar para usar distintos protocolos, como TCP, HTTP o HTTPS. Es una característica importante porque ayuda a detectar errores de aplicación, administrar la carga y planear el tiempo de inactividad.

Las reglas de Azure Load Balancer requieren un sondeo de estado para detectar el estado del punto de conexión. La configuración del sondeo de estado y las respuestas de sondeo determinan qué instancias del grupo de back-end reciben nuevas conexiones. Use sondeos de estado para detectar el error de una aplicación. Genere una respuesta personalizada a un sondeo de estado. Use el sondeo de estado para el control de flujo para administrar la carga o el tiempo de inactividad planeado. Cuando se genere un error en el sondeo de estado, el equilibrador de carga dejará de enviar nuevas conexiones a la instancia con estado incorrecto respectiva. La conectividad saliente no se ve afectada, solo la entrante.

Protocolos de sondeo

Los sondeos de estado admiten varios protocolos. La disponibilidad de un protocolo específico de sondeo de estado varía en función de la SKU de Load Balancer. Además, el comportamiento del servicio varía según la SKU de Load Balancer, como se muestra en esta tabla:

SKU Protocolo de sondeo Comportamiento de sondeo inactivo
Estándar TCP, HTTP, HTTPS Todos los sondeos inactivos y todos los flujos TCP continúan.
Básico TCP, HTTP Todos los sondeos inactivos y todos los flujos TCP expiran.

Propiedades del sondeo

Los sondeos de estado tienen las siguientes propiedades:

Nombre de la propiedad de sondeo de estado Detalles
Nombre Nombre del sondeo de estado. Se trata de un nombre que se va a definir para el sondeo de estado
Protocolo Protocolo de sondeo de estado. Este es el tipo de protocolo que desearía que utilizara el sondeo de estado. Las opciones son: TCP, HTTP y HTTPS
Port Puerto del sondeo de estado. El puerto de destino que desea que utilice la sonda de estado cuando se conecte a la máquina virtual para comprobar su estado
Intervalo (segundos) Intervalo de sondeo de estado. La cantidad de tiempo (en segundos) entre sondeos diferentes en dos intentos consecutivos de comprobación de estado de la máquina virtual
Usado por Lista de reglas del equilibrador de carga que utilizan este sondeo de estado específico. Debe tener al menos una regla con el sondeo de estado para que sea eficaz

Configuración de sondeo

La configuración del sondeo de estado se compone de los siguientes elementos:

Configuración del sondeo de estado Detalles
Protocolo Protocolo de sondeo de estado. Este es el tipo de protocolo que desearía que utilizara el sondeo de estado. Las opciones disponibles son: TCP, HTTP, HTTPS
Port Puerto del sondeo de estado. El puerto de destino que desea que utilice el sondeo de estado cuando se conecta a la máquina virtual para comprobar el estado de mantenimiento de la máquina virtual. Debe asegurarse de que la máquina virtual también escucha en este puerto (es decir, el puerto está abierto).
Intervalo Intervalo de sondeo de estado. Cantidad de tiempo (en segundos) entre los intentos de comprobación de estado consecutivos en la máquina virtual

Protocolo de sondeo

El protocolo que usa el sondeo de estado puede configurarse con una de las siguientes opciones: TCP, HTTP o HTTPS.

Escenario Sondeo TCP Sondeo HTTP/HTTPS
Información general Los sondeos TCP inician una conexión mediante la realización de un protocolo de enlace TCP abierto de tres vías con el puerto definido. Los sondeos TCP terminan una conexión con un protocolo de enlace TCP cerrado de cuatro vías. HTTP y HTTPS emiten una incidencia HTTP GET con la ruta especificada. Ambos sondeos admiten rutas de acceso relativas para la solicitud HTTP GET. Los sondeos HTTPS son lo mismo que los sondeos HTTP con Seguridad de la capa de transporte (TLS) añadida. Los sondeos HTTP/HTTPS pueden ser útiles si desea implementar su propia lógica para quitar instancias del equilibrador de carga si el puerto de sondeo es también el agente de escucha para el servicio.
Comportamiento del error de sondeo Un sondeo TCP genera un error cuando:
1. El agente de escucha TCP de la instancia no responde durante el período de tiempo de expiración. El sondeo se marca como inactivo en función del número de solicitudes de sondeo con tiempo de espera expirado, que se configuraron para quedarse sin respuesta antes de marcar el sondeo como inactivo.
2. El sondeo recibe un restablecimiento de TCP de la instancia.		 Un sondeo HTTP / HTTPS genera un error cuando:
1. El punto de conexión de sondeo devuelve un código HTTP de respuesta distinto de 200 (por ejemplo, 403, 404 o 500).
2. El punto de conexión de sondeo no responde durante el intervalo de sondeo mínimo y un período de tiempo de espera de 30 segundos. Es posible que no se respondan varias solicitudes de sondeo antes de que el sondeo se marque como que no se está ejecutando, hasta que se haya alcanzado la suma de todos los intervalos de tiempo de espera.
3. El punto de conexión de sondeo cierra la conexión mediante TCP Reset.
Comportamiento del sondeo activo Los sondeos de estado TCP se consideran en buen estado y marcan el punto de conexión de back-end como tal en los casos siguientes:
1. El sondeo de estado es correcto después de arrancar la máquina virtual.
2. Cualquier punto de conexión de back-end en un estado correcto se considera apto para recibir nuevos flujos.		 El sondeo de estado se marca cuando la instancia responde con un código de estado 200 de HTTP dentro del período de tiempo de espera. Los sondeos de estado HTTP/HTTPS se consideran en buen estado y marcan el punto de conexión de back-end como tal en los casos siguientes:
1. El sondeo de estado es correcto después de arrancar la máquina virtual.
2. Cualquier punto de conexión de back-end en un estado correcto se considera apto para recibir nuevos flujos.

Nota:

El sondeo HTTPS requiere el uso de certificados con un hash de firma mínimo de SHA256 en toda la cadena.

Comportamiento de sondeo inactivo

Escenario Conexiones TCP Datagramas UDP
Sondeos de instancia única inactivos Se realizan nuevas conexiones TCP correctamente al punto de conexión de back-end en buen estado. Las conexiones TCP establecidas a este punto de conexión de back-end continúan. Los flujos de UDP existentes se mueven a otra instancia en buen estado en el grupo de back-end.
Todas las instancias sondean hacia abajo No se envían nuevos flujos al grupo de back-end. Standard Load Balancer permite que los flujos de TCP establecidos continúen, dado que un grupo de back-end tiene más de una instancia de punto de conexión. Basic Load Balancer termina todos los flujos de TCP existente en el grupo de back-end. Todos los flujos UDP existentes finalizan.

Intervalo de sondeo y tiempo de espera

El valor de intervalo determina la frecuencia con la que el sondeo de estado comprobará una respuesta de las instancias del grupo de back-end. Si se produjera un error en el sondeo de estado, las instancias del grupo de back-end se marcarán inmediatamente como incorrectas. Si el sondeo de estado se realiza correctamente en el siguiente sondeo correcto, Azure Load Balancer marcará las instancias del grupo de back-end como correctas. El sondeo de estado intenta comprobar el puerto de sondeo de estado configurado cada 5 segundos de forma predeterminada en Azure Portal, pero se puede establecer explícitamente en otro valor.

Para asegurarse de que se recibe una respuesta oportuna, los sondeos de estado HTTP/S tienen tiempos de espera integrados. A continuación se muestran las duraciones de tiempo de espera de los sondeos TCP y HTTP/S:

  • Duración del tiempo de espera del sondeo TCP: N/A (se producirá un error en los sondeos una vez que se haya superado la duración del intervalo de sondeo configurado y se haya enviado el siguiente sondeo).
  • Duración del tiempo de espera del sondeo HTTP/S: 30 segundos

Para los sondeos HTTP/S, si el intervalo configurado es mayor que el período de tiempo de espera anterior, se producirá un tiempo de espera del sondeo de estado y se producirá un error si no se recibe ninguna respuesta durante el período de tiempo de espera. Por ejemplo, si un sondeo de estado HTTP está configurado con un intervalo de sondeo de 120 segundos (cada 2 minutos) y no se recibe ninguna respuesta de sondeo en los primeros 30 segundos, el sondeo habrá alcanzado su período de tiempo de espera y producirá un error. Cuando el intervalo configurado es menor que el período de tiempo de espera anterior, se producirá un error en el sondeo de estado si no se recibe ninguna respuesta antes de que finalice el período de intervalo configurado y se enviará inmediatamente el siguiente sondeo.

Guía de diseño

  • Al diseñar el modelo de mantenimiento de la aplicación, realice un sondeo en un puerto de un punto de conexión de back-end que refleje el estado de esa instancia y el servicio de aplicación. El puerto de la aplicación y el puerto de sondeo no deben ser el mismo. En algunos escenarios, puede ser conveniente que el puerto de sondeo sea diferente del puerto que use la aplicación, pero generalmente se recomienda que usen el mismo puerto.

  • Puede ser útil para la aplicación generar una respuesta de sondeo de estado e indicarle al equilibrador de carga si la instancia debe recibir nuevas conexiones. Puede manipular la respuesta del sondeo para limitar la entrega de nuevas conexiones a una instancia generando un error en el sondeo de estado. Puede prepararse para el mantenimiento de la aplicación e iniciar la purga de conexiones a la aplicación. Una señal de sondeo inactivo siempre permitirá que los flujos TCP continúen hasta el tiempo de espera de inactividad o el cierre de la conexión en un Standard Load Balancer.

  • Para una aplicación UDP con equilibrio de carga, genere una señal de sondeo de estado personalizado desde el punto de conexión de back-end. Use TCP, HTTP o HTTPS para el sondeo de estado que coincida con el agente de escucha correspondiente.

  • Regla de equilibrio de carga de puertos de alta disponibilidad con Standard Load Balancer. Todos los puertos tienen equilibrio de carga y una única respuesta de sondeo de estado debe reflejar el estado de toda la instancia.

  • No use traducción ni un proxy para dirigir un sondeo de estado a través de la instancia que recibe el sondeo de estado a otra instancia de la red virtual. Esta configuración puede provocar errores en su escenario. Por ejemplo: se implementa un conjunto de dispositivos de terceros en el grupo de back-end de un equilibrador de carga para proporcionar escalado y redundancia para los dispositivos. El sondeo de estado está configurado para sondear un puerto que el dispositivo de terceros dirige a través de un proxy o mediante traducción a otras máquinas virtuales que están detrás del dispositivo. Si se sondea el mismo puerto que se usa para redirigir solicitudes a través de un proxy o mediante traducción a las otras máquinas virtuales que están detrás del dispositivo, cualquier respuesta del sondeo de una sola máquina virtual marcará el dispositivo como inactivo. Esta configuración puede provocar errores en cascada en la aplicación. El desencadenador puede ser un error de sondeo intermitente que hará que el equilibrador de carga marque la instancia del dispositivo como inactiva. Esta acción puede deshabilitar la aplicación. Sondee el estado del propio dispositivo. La selección del sondeo para determinar la señal de estado es un aspecto importante que debe tenerse en cuenta en los escenarios con dispositivos de red virtuales (NVA). Consulte al proveedor de la aplicación para saber cuál es la señal de estado adecuada en estos casos.

  • Si tiene varias interfaces configuradas en la máquina virtual, asegúrese de que se responde al sondeo en la interfaz en la que se recibe. Es posible que tenga que traducir la dirección de red de origen de esta dirección en la máquina virtual para cada interfaz.

  • No se requiere una definición de sondeo ni se comprueba cuando se usa Azure PowerShell, la CLI de Azure, plantillas o una API. Las pruebas de validación de sondeos solo se realizan cuando se usa Azure Portal.

  • Si el sondeo de estado fluctúa, el equilibrador de carga espera más tiempo antes de volver a poner el punto de conexión de back-end en buen estado. Este tiempo de espera adicional protege el usuario y la infraestructura y es una directiva intencionada.

  • Asegúrese de que las instancias de máquina virtual se estén ejecutando. Para cada instancia en ejecución del grupo de back-end, el sondeo de estado comprueba si hay disponibilidad. Si se detuviera una instancia, no se sondeará hasta que se haya iniciado de nuevo.

  • No configure la red virtual con el intervalo de direcciones IP propiedad de Microsoft que contiene 168.63.129.16. La configuración entrará en conflicto con la dirección IP del sondeo de estado y podría dar lugar a un error en el escenario.

  • Para probar un error de sondeo de estado o marcar una instancia concreta como inactiva, use un grupo de seguridad de red para bloquear explícitamente el sondeo de estado. Cree una regla de grupo de seguridad de red (NSG) para bloquear el puerto de destino o la dirección IP de origen con el fin de simular el error de un sondeo.

  • A diferencia de las reglas de equilibrio de carga, las reglas NAT entrantes no necesitan un sondeo de estado asociado.

  • No se recomienda bloquear la IP o el puerto del sondeo de estado de Azure Load Balancer con reglas de NSG. Este es un escenario no admitido y puede hacer que las reglas de NSG tengan un efecto retardado, lo que provoca que las sondas de estado representen de forma inexacta la disponibilidad de sus instancias de backend.

Supervisión

Standard Load Balancer expone el estado del sondeo de estado por punto de conexión y punto de conexión de back-end mediante Azure Monitor. Otros servicios de Azure o aplicaciones de socios pueden consumir estas métricas. Los registros de Azure Monitor no se admiten para Load Balancer Básico.

Dirección IP de origen del sondeo

Para que el sondeo de estado de Azure Load Balancer marque la instancia como activa, se debe permitir la dirección IP 168.63.129.16 en todos los grupos de seguridad de red de Azure y en las directivas de firewall locales. La etiqueta de servicio AzureLoadBalancer identifica esta dirección IP de origen en los grupos de seguridad de red y permite el tráfico de sondeo de estado de forma predeterminada. Puede obtener más información sobre esta IP aquí.

Si en las directivas de firewall no se permitiera la dirección IP de origen del sondeo, se producirá un error en el sondeo de estado, ya que no podrá acceder a la instancia. A su vez, Azure Load Balancer marca la instancia como inactiva debido al error del sondeo de estado. Esta configuración incorrecta puede producir un error en el escenario de aplicación con equilibrio de carga. Todos los sondeos de estado IPv4 de Load Balancer tienen como origen la dirección IP 168.63.129.16. Los sondeos IPv6 usan una dirección local de vínculo (fe80::1234:5678:9abc) como origen. Para una instancia de Azure Load Balancer de doble pila, debe configurar un grupo de seguridad de red para que funcione el sondeo de estado IPv6.

Limitaciones

  • Los sondeos HTTPS no admiten la autenticación mutua con un certificado de cliente.

  • Los sondeos HTTP no admiten el uso de nombres de host para back-end de sondeos.

  • La habilitación de marcas de tiempo TCP puede provocar limitaciones u otros problemas de rendimiento, lo que puede causar que los sondeos de estado agoten el tiempo de espera.

  • Un sondeo de estado básico del equilibrador de carga de SKU no es compatible con un conjunto de escalado de máquinas virtuales.

  • Los sondeos HTTP no admiten el sondeo en los puertos siguientes debido a problemas de seguridad: 19, 21, 25, 70, 110, 119, 143, 220 y 993.

Pasos siguientes