CLB utiliza verificaciones de estado para determinar la disponibilidad de los servidores backend. Si un servidor backend presenta errores, CLB deja de enviarle solicitudes y las distribuye entre los servidores que funcionan correctamente. Cuando el servidor se recupera, CLB reanuda el reenvío de tráfico hacia él. Este mecanismo de verificación de estado mejora la disponibilidad general del servicio al evitar que los fallos de servidores individuales afecten su aplicación.
Si su servicio es sensible a la carga, las verificaciones de estado frecuentes pueden afectar el tráfico normal del servicio. Puede reducir este impacto si disminuye la frecuencia de las verificaciones de estado, aumenta el intervalo entre ellas o cambia de verificaciones de capa 7 a capa 4. Sin embargo, para garantizar la disponibilidad continua del servicio, le recomendamos que no deshabilite las verificaciones de estado.
Proceso de verificación de estado
Las verificaciones de estado confirman el estado del servidor mediante el envío de solicitudes periódicas.
CLB se despliega en un clúster. Los nodos dentro de este clúster realizan tanto el reenvío de datos como las verificaciones de estado. Si un servidor backend falla una verificación de estado, CLB deja de distribuir nuevas solicitudes de clientes a ese servidor con errores.
CLB utiliza el bloque CIDR 100.64.0.0/10 para las verificaciones de estado. Sus servidores backend no deben bloquear el tráfico proveniente de este rango de direcciones. No es necesario agregar una regla de permiso en su security group de ECS, pero si ha configurado otras directivas de seguridad como iptables, debe permitir el tráfico desde este bloque CIDR. El rango 100.64.0.0/10 es un espacio de direcciones reservado de Alibaba Cloud y no representa ningún riesgo de seguridad.
Mejores prácticas para la protección del security group de ECS backend
Para evitar que atacantes eviten CLB y accedan directamente a la IP pública de una instancia ECS backend, le recomendamos configurar reglas de entrada en el security group de ECS. Estas reglas deben permitir el tráfico a sus puertos de servicio únicamente desde los bloques CIDR necesarios y rechazar las solicitudes directas desde Internet. Se recomienda la siguiente configuración:
El bloque CIDR 100.64.0.0/10, utilizado para las verificaciones de estado y el reenvío de tráfico de CLB, no está restringido por las reglas de entrada del security group de ECS backend. No necesita agregar una regla de permiso específica para este bloque CIDR, ya que el tráfico de CLB hacia las instancias ECS backend siempre está permitido.
En las reglas de entrada del security group de ECS, permita el acceso a sus puertos de servicio (como 80 y 443) únicamente desde el bloque CIDR de su VPC. No permita el acceso a sus puertos de servicio desde Internet (0.0.0.0/0).
Una vez completada esta configuración, el security group bloquea las solicitudes directas desde Internet hacia los puertos de servicio de la instancia ECS. El tráfico normal reenviado por CLB no se ve afectado.
Verificaciones de estado HTTP y HTTPS
Los listeners de capa 7 (HTTP/HTTPS) realizan verificaciones de estado mediante solicitudes HEAD o GET.
Para los listeners HTTPS, CLB gestiona los certificados. CLB utiliza HTTP para el intercambio de datos con los servidores backend con el fin de mejorar el rendimiento.
Una verificación de estado de listener de capa 7 funciona de la siguiente manera:
CLB envía una solicitud HTTP HEAD al servidor backend.
El servidor backend devuelve un código de estado HTTP.
Si CLB no recibe una respuesta dentro del tiempo de espera de respuesta, la verificación de estado falla.
Si CLB recibe una respuesta dentro del tiempo de espera de respuesta, compara el código de estado con los códigos de estado correctos configurados. Si el código coincide, la verificación es exitosa; de lo contrario, falla.
De forma predeterminada, las verificaciones de estado de CLB consideran correctos únicamente los códigos de estado HTTP 2xx y 3xx. Si un servidor backend devuelve un código de estado 4xx (como 400, 403, 404 o 429) o 5xx (como 500, 502 o 503), la verificación de estado falla.
Se recomienda crear un endpoint dedicado para la verificación de estado, como /health, que devuelva un código de estado HTTP 200, en lugar de agregar códigos 4xx o 5xx a la lista de códigos de estado correctos.
Verificaciones de estado TCP
Para los listeners TCP de capa 4, CLB utiliza sondeos TCP personalizados para comprobar el estado del servidor, como se muestra en la siguiente figura.
Una verificación de estado de listener TCP funciona de la siguiente manera:
Un nodo en el clúster de capa 4 envía un paquete TCP SYN a la IP interna y al puerto de verificación de estado del servidor backend.
Después de recibir la solicitud, si el servidor está escuchando correctamente en el puerto, devuelve un paquete SYN+ACK.
Si el nodo del clúster de capa 4 no recibe respuesta del servidor backend dentro del tiempo de espera de respuesta, la verificación de estado falla. A continuación, el nodo envía un paquete RST para finalizar la conexión TCP.
Si el nodo del clúster de capa 4 recibe una respuesta del servidor backend dentro del tiempo de espera de respuesta, la verificación de estado es exitosa. Luego, el nodo envía un paquete RST para finalizar la conexión TCP.
Este mecanismo puede provocar que el servidor backend considere anormales las conexiones TCP y registre errores, como Connection reset by peer, en sus registros de aplicación.
Soluciones alternativas:
Para listeners TCP, utilice verificaciones de estado basadas en HTTP.
Después de configurar el servidor backend para obtener la IP real del cliente, ignore los errores de conexión provenientes del bloque de direcciones del servicio CLB.
Verificaciones de estado UDP
Para los listeners UDP de capa 4, las verificaciones de estado utilizan sondeos de paquetes UDP para comprobar el estado del servidor, como se muestra en la siguiente figura.
Una verificación de estado de listener UDP funciona de la siguiente manera:
Un nodo en el clúster de capa 4 envía un paquete UDP a la IP interna y al puerto de verificación de estado del servidor backend.
Si el servidor backend no está escuchando en el puerto, su sistema operativo devuelve un mensaje de error ICMP como
port XX unreachable. De lo contrario, el servidor no responde.Si el nodo del clúster de capa 4 recibe este mensaje de error del servidor backend dentro del tiempo de espera de respuesta, la verificación de estado falla.
Si el nodo del clúster de capa 4 no recibe ninguna respuesta del servidor backend dentro del tiempo de espera de respuesta, la verificación de estado es exitosa.
Para servicios UDP, el estado de la verificación de estado podría no coincidir siempre con el estado real del servicio.
Si el servidor backend es Linux, los escenarios de alta concurrencia pueden activar el mecanismo de protección contra inundación ICMP de Linux, el cual limita la velocidad a la que el servidor envía mensajes ICMP. En este caso, incluso si el servicio está inactivo, es posible que el servidor no pueda devolver un error ICMP port XX unreachable. Como resultado, cuando CLB no recibe una respuesta ICMP, marca incorrectamente la verificación de estado como exitosa. Esto provoca una discrepancia entre el estado de salud reportado y el estado real del servicio.
Solución alternativa:
Configure el load balancer para que envíe una cadena específica al servidor backend y considere la verificación como exitosa solo después de recibir una respuesta específica. Este mecanismo requiere que su aplicación backend sea compatible con esta función.
Ventana de tiempo de verificación de estado
El mecanismo de verificación de estado mejora la disponibilidad del servicio. Sin embargo, para evitar la inestabilidad del sistema debido a cambios frecuentes de estado, CLB modifica el estado de un servidor solo después de que este aprueba o falla un número específico de verificaciones de estado consecutivas dentro de una ventana de tiempo de verificación de estado. Esta ventana de tiempo depende de los siguientes tres factores:
Intervalo de verificación de estado (frecuencia con la que se realiza una verificación de estado)
Tiempo de espera de respuesta (tiempo que se espera para que un servidor responda a una verificación de estado)
Umbral de verificación (número de verificaciones exitosas o fallidas consecutivas necesarias para cambiar el estado)
La ventana de tiempo de verificación de estado se calcula de la siguiente manera:
Ventana de fallo de verificación de estado = tiempo de espera de respuesta × umbral de error + intervalo de verificación de estado × (umbral de error - 1)
-
Ventana de éxito de verificación de estado = (tiempo de respuesta de verificación de estado exitosa × umbral de correcto) + intervalo de verificación de estado × (umbral de correcto - 1)
NotaEl tiempo de respuesta de verificación de estado exitosa es la duración desde el envío de una solicitud de verificación de estado hasta la recepción de una respuesta. Para las verificaciones de estado TCP, este tiempo es insignificante. Para las verificaciones de estado HTTP, este tiempo depende del rendimiento y la carga del servidor, pero generalmente es inferior a un segundo.
El estado de la verificación de estado afecta el reenvío de solicitudes de la siguiente manera:
Si un servidor backend objetivo falla una verificación de estado, se dejan de distribuir nuevas solicitudes hacia él. Esta redirección es transparente para los nuevos clientes.
Si un servidor backend objetivo pasa una verificación de estado, se le distribuyen nuevas solicitudes y el acceso del cliente es normal.
Si un servidor backend está fallando en sus verificaciones de estado pero aún no ha alcanzado el umbral de error (tres fallos consecutivos de forma predeterminada), CLB continúa enviándole solicitudes. Esto puede provocar que las solicitudes de los clientes fallen.
Ejemplo de configuración de verificación de estado
Este ejemplo utiliza la siguiente configuración de verificación de estado:
response timeout: 5 seconds
health check interval: 2 seconds
healthy threshold: 3
unhealthy threshold: 3
La ventana de fallo de verificación de estado se calcula como: tiempo de espera de respuesta × umbral de error + intervalo de verificación de estado × (umbral de error - 1). Con los valores proporcionados, esto es 5 × 3 + 2 × (3 - 1) = 19 segundos. Este es el tiempo total desde el inicio de la primera verificación de estado fallida hasta que el servidor se marca con errores.
La ventana de éxito de verificación de estado se calcula como: (tiempo de respuesta de verificación de estado exitosa × umbral de correcto) + intervalo de verificación de estado × (umbral de correcto - 1). Si se asume un tiempo de respuesta exitosa de 1 segundo, esto es (1 × 3) + 2 × (3 - 1) = 7 segundos. Este es el tiempo total desde el inicio de la primera verificación de estado exitosa hasta que el servidor se marca como correcto.
El tiempo de respuesta de verificación de estado exitosa es la duración desde el envío de una solicitud de verificación de estado hasta la recepción de una respuesta. Para las verificaciones de estado TCP, este tiempo es insignificante porque solo comprueban si un puerto está activo. Para las verificaciones de estado HTTP, este tiempo depende del rendimiento y la carga del servidor de aplicaciones, pero generalmente es inferior a un segundo.
Nombres de dominio en verificaciones de estado HTTP
Cuando configura una verificación de estado HTTP, opcionalmente puede especificar un nombre de dominio. Algunos servidores de aplicaciones requieren que el encabezado host esté presente en las solicitudes. Si su servidor tiene este requisito, debe configurar un nombre de dominio. CLB agrega este nombre de dominio al encabezado host de la solicitud de verificación de estado. Si falta este encabezado, el servidor podría rechazar la solicitud y provocar que la verificación de estado falle.
Por lo tanto, si su servidor de aplicaciones valida el campo host, configure el nombre de dominio para asegurar que las verificaciones de estado sean exitosas.
Referencias
Configure las verificaciones de estado cuando agregue un listener. Para consultar los pasos específicos, consulte Configure and manage CLB health checks.
Para preguntas frecuentes sobre las verificaciones de estado, consulte CLB health check FAQ.