Sondeos de estado de Azure Load Balancer

  • Artículo
  • Tiempo de lectura: 15 minutos

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 recibirán 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 genera un error en el sondeo de estado, el equilibrador de carga deja de enviar nuevas conexiones a la instancia con estado incorrecto respectiva. La conectividad saliente no se ve afectada, solo la entrante.

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 Estándar SKU Básico
Tipos de sondeo TCP, HTTP, HTTPS TCP, HTTP
Comportamiento de sondeo inactivo Todos los sondeos inactivos y todos los flujos TCP continúan. Todos los sondeos inactivos y todos los flujos TCP expiran.

Importante

Los sondeos de estado de Load Balancer parten de la dirección IP 168.63.129.16 y no deben bloquearse para que los sondeos marquen su instancia como activa. Para más información, consulte el apartado Probe source IP address (Dirección IP de origen de sondeo). Para ver este tráfico de sondeo dentro de la instancia de back-end, revise las preguntas más frecuentes de Azure Load Balancer.

Independientemente del umbral de tiempo de espera configurado, los sondeos de estado del equilibrador de carga HTTP o HTTPS marcarán automáticamente la instancia como inactiva si el servidor devuelve cualquier código de estado que no sea HTTP 200 u OK o si la conexión se termina a través del restablecimiento de TCP.

Configuración de sondeo

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

  • Duración del intervalo entre sondeos

  • Protocolo

  • Port

  • Ruta de acceso HTTP que se va a usar para HTTP GET al utilizar sondeos HTTP(S)

Nota:

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.

Señal de aplicación, detección de la señal y reacción de Load Balancer

El valor interval determina la frecuencia con la que el sondeo de estado sondeará una respuesta de las instancias del grupo de back-end. Si se produce un error en el sondeo de estado, marcará inmediatamente las instancias del grupo de back-end como incorrectas. En el siguiente sondeo de estado correcto, el sondeo de estado volverá a marcar inmediatamente las instancias del grupo de back-end como correctas.

Por ejemplo, un sondeo de estado establecido en cinco segundos. La hora a la que se envía un sondeo no se sincroniza cuando la aplicación puede cambiar de estado. El tiempo total que tarda el sondeo de estado en reflejar el estado de la aplicación puede estar en uno de los dos escenarios siguientes:

  1. Si la aplicación produce una respuesta de tiempo de espera agotado justo antes de que llegue el siguiente sondeo, la detección de eventos tardará 5 segundos más la duración del tiempo de espera de la aplicación cuando llega el sondeo. Puede suponer que la detección tarda algo más de 5 segundos.

  2. Si la aplicación produce una respuesta de tiempo de espera agotado justo después de que llegue el siguiente sondeo, la detección de eventos no comenzará hasta que llegue el sondeo y se agote el tiempo de espera más otros 5 segundos. Puede suponer que la detección tarda poco menos de 10 segundos.

En este ejemplo, una vez que se ha producido la detección, la plataforma tarda un poco en reaccionar al cambio.

La reacción depende de:

  • Cuándo cambia de estado la aplicación.
  • Cuándo se detecta el cambio.
  • Cuándo se envía el siguiente sondeo de estado.
  • Cuándo se comunica la detección a través de la plataforma.

Suponga que la reacción a una respuesta de tiempo de espera agotado llevará un mínimo de 5 segundos y un máximo de 10 segundos para reaccionar al cambio.

Este ejemplo se proporciona para ilustrar lo que está ocurriendo. No es posible pronosticar una duración exacta más allá de lo que se indica en el ejemplo.

Nota:

El sondeo de estado comprobará todas las instancias en ejecución en el grupo de back-end. Si se detiene una instancia, no se sondeará hasta que se haya iniciado de nuevo.

Tipos de sondeo

El protocolo que usa el sondeo de estado puede configurarse con una de las siguientes opciones:

  • Agentes de escucha TCP

  • Puntos de conexión HTTP

  • Puntos de conexión HTTPS

Los protocolos disponibles dependen de la SKU de Load Balancer que se utilice:

TCP HTTP HTTPS
SKU estándar ✅ ✅ ✅
SKU básica ✅ ✅ ❌

Sondeo TCP

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.

El intervalo mínimo de sondeo es de 5 segundos y no puede superar los 120 segundos.

Un sondeo TCP genera un error cuando:

  • 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.

  • El sondeo recibe un restablecimiento de TCP de la instancia.

Sondeo HTTP/HTTPS

Nota:

El sondeo HTTPS solo está disponible para Standard Load Balancer.

Los sondeos HTTP y HTTPS se basan en el sondeo TCP y emiten una solicitud HTTP GET con la ruta de acceso 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. 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. De forma predeterminada, el sondeo de estado intenta comprobar cada 15 segundos el puerto de sondeo de estado configurado. El intervalo mínimo de sondeo es de 5 segundos y no puede superar los 120 segundos.

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. Por ejemplo, podría decidir quitar una instancia si está por encima del 90 % de la CPU y devolver un estado que no es 200.

Nota:

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

Si usa Cloud Services y tiene roles web que utilizan w3wp.exe, también obtiene la supervisión automática de su sitio web. Los errores en el código del sitio web devuelven un estado distinto de 200 para el sondeo del equilibrador de carga.

Un sondeo HTTP / HTTPS genera un error cuando:

  • El punto de conexión de sondeo devuelve un código HTTP de respuesta distinto de 200 (por ejemplo, 403, 404 o 500). El sondeo se marca como inactivo inmediatamente.

  • 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.

  • El punto de conexión de sondeo cierra la conexión mediante TCP Reset.

Comportamiento del sondeo activo

Los sondeos de estado TCP, HTTP y HTTPS se consideran en buen estado y marcan el punto de conexión de back-end como tal en los casos siguientes:

  • El sondeo de estado es correcto después de arrancar la máquina virtual.

Cualquier punto de conexión de back-end que haya logrado un estado correcto se considera apto para recibir nuevos flujos.

Nota:

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.

Comportamiento de sondeo inactivo

Conexiones TCP

Se realizarán nuevas conexiones TCP correctamente al punto de conexión de back-end en buen estado.

Si se produce un error en el sondeo de estado de un punto de conexión de back-end, las conexiones TCP establecidas con él continúan.

Si se produce algún error en todos los sondeos de todas las instancias de un grupo de back-end, no se enviarán flujos nuevos a dicho grupo. Standard Load Balancer permitirá que los flujos de TCP establecidos continúen. Basic Load Balancer terminará todos los flujos de TCP existente en el grupo de back-end.

Load Balancer es un servicio de paso a través. Load Balancer no finaliza las conexiones TCP. El flujo tiene lugar siempre entre el cliente y el sistema operativo invitado y la aplicación de la máquina virtual. Un grupo con todos los sondeos inactivos da lugar a un front-end que no responderá a los intentos de apertura de la conexión TCP. No hay un punto de conexión de back-end con un estado correcto para recibir el flujo y responder con una confirmación.

Datagramas UDP

Los datagramas UDP se entregarán a los puntos de conexión de back-end correctos.

UDP no tiene conexión y no hay ningún estado de flujo que realice el seguimiento para UDP. Si se produce un error en el sondeo de estado de un punto de conexión de back-end, los flujos UDP existentes se mueven a otra instancia en buen estado del grupo de back-end.

Si se produce un error en todos los sondeos de todas las instancias de un grupo de back-end, los flujos UDP terminarán para las instancias de Basic Load Balancer y Standard Load Balancer.

Dirección IP de origen del sondeo

Load Balancer usa un servicio de sondeo distribuido para su modelo de mantenimiento interno. El servicio de sondeos reside en todos los host donde residan las máquinas virtuales y se puede programar a petición para generar sondeos de estado por cada configuración de cliente. El tráfico del sondeo de estado se realiza directamente entre el servicio de sondeos que genera el sondeo de estado y la máquina virtual del cliente. Todos los sondeos de Load Balancer tienen como origen la dirección IP 168.63.129.16. Puede usar un espacio de direcciones IP dentro de una red virtual que no sea el espacio RFC1918. El uso de una dirección IP propiedad de Microsoft reservada de forma global reduce la posibilidad de un conflicto de dirección IP con el espacio de direcciones IP que se usa dentro de la red virtual. La dirección IP es la misma en todas las regiones. La dirección IP no cambia y no es un riesgo para la seguridad. Solo la plataforma interna Azure puede obtener un paquete de la dirección IP.

La etiqueta del 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 manera predeterminada.

Además de los sondeos de estado de Load Balancer, en las operaciones siguientes se usa esta dirección IP:

  • Permite al agente de VM comunicarse con la plataforma para indicar que se encuentra en estado "Listo"

  • Permite la comunicación con el servidor virtual de DNS para proporcionar resolución de nombres filtrada a los clientes que no definen servidores DNS personalizados. Este filtro garantiza que los clientes solo pueden resolver los nombres de host de su implementación.

  • Permite que la máquina virtual obtenga una dirección IP dinámica desde el servicio DHCP en Azure.

Guía de diseño

  • Los sondeos de estado se usan para hacer que el servicio sea resistente y escalable. Una configuración incorrecta puede afectar a la disponibilidad y escalabilidad del servicio. Revise todo este documento y tenga en cuenta cuál es el efecto para su escenario cuando la respuesta del sondeo es activa o inactiva. Tenga en cuenta cómo afecta la respuesta del sondeo a la disponibilidad de la aplicación.

  • 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 al que utiliza la aplicación.

  • 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 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 cascada 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 en las directivas de firewall no se permite la dirección IP de origen del sondeo, se producirá un error en el sondeo de estado, ya que no puede acceder a la instancia. A su vez, Load Balancer marcará 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.

  • Para que el sondeo de estado de Load Balancer marque la instancia como activa, se debe permitir esta dirección IP en todos los grupos de seguridad de red de Azure y en las directivas de firewall locales. De forma predeterminada, todos los grupos de seguridad de red incluyen la etiqueta de servicio AzureLoadBalancer para permitir el tráfico de sondeo de estado.

  • 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.

  • 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 puede dar lugar a un error en el escenario.

  • 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 habilite las marcas de tiempo TCP. Las marcas de tiempo TCP pueden causar un error en los sondeos de estado debido a que la pila TCP del sistema operativo invitado de la máquina virtual ha eliminado paquetes TCP. Los paquetes eliminados pueden hacer que el equilibrador de carga marque el punto de conexión como inactivo. Normalmente, las marcas de tiempo TCP están habilitadas de forma predeterminada en las imágenes de máquina virtual con seguridad reforzada y se deben deshabilitar.

Supervisión

Las instancias públicas e internas de Standard Load Balancer exponen 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 asociados pueden usar estas métricas.

Los registros de Azure Monitor no están disponibles para las instancias públicas e internas de Basic Load Balancer.

Limitaciones

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

  • Debe asumir que se producirá un error en los sondeos de estado cuando se habiliten las marcas de tiempo TCP.

  • 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