- How does the health check function of Server Load Balancer (SLB) work?
- What are the recommended configurations for health checks in SLB?
- Can I disable the health check function?
- What is the recommended health check method for TCP listeners?
- Is there any impact to health checks if the weight of an ECS instance is zero?
- What health check method is used for HTTP listeners on backend ECS instances?
- What are the ranges of IP addresses that HTTP listeners use to perform health checks on backend ECS instances?
- Why is the health check frequency that is displayed on the console different from that recorded in the web logs?
- Do health checks use system resources?
- How do I handle a health check failure caused by a faulty backend database?
- Why is a network connection exception recorded in the backend service logs, but the TCP health check is displayed as successful?
- Why is the health check result returned as abnormal when the service is running normally?
How does the health check function of Server Load Balancer (SLB) work?
SLB checks the service availability of backend servers (ECS instances) by performing health checks on backend servers. When SLB detects that an ECS instance is unhealthy, SLB stops distributing requests to the ECS instance until it becomes healthy again.
The IP address range used for health checks is 100.64.0.0/10. Make sure that backend ECS instances do not block this CIDR block. You do not need to configure a security group rule to allow access from this CIDR block. However, if you have configured security rules such as iptables, you must allow access from this CIDR block. (100.64.0.0/10 is reserved by Alibaba Cloud. Other users cannot use any IP address in this CIDR block and therefore no security risk is involved.)
For more information, see Configure health checks.
What are the recommended configurations for health checks in SLB?
To avoid the impact of backend server switching caused by frequent health check failures on system availability, health check failures or successes must reach a certain threshold before the health check status of a backend server is switched.
The following are recommended health check configurations for TCP, HTTP, and HTTPS listeners.
|Response timeout||5 seconds|
|Health check interval||2 seconds|
|Unhealthy threshold||3 times|
The following are recommended health check configurations for UDP listeners.
|Response timeout||10 seconds|
|Health check interval||5 seconds|
|Unhealthy threshold||3 times|
|Healthy threshold||3 times|
Can I disable the health check function?
You can only disable health checks for HTTP and HTTPS listeners. Health checks for UDP and TCP listeners cannot be disabled.
What is the recommended health check method for TCP listeners?
For TCP listeners, both the TCP health check and HTTP health check are supported:
- TCP health checks send SYN handshake packets to backend servers to check whether the ports of backend servers are normal.
- HTTP health checks detect the health status of applications on backend servers by sending HEAD and GET requests to simulate visits from the browser of a user.
The TCP health check minimally impacts the performance of backend servers and consumes less server resources. Select TCP health check if the traffic load on backend servers is high, and select HTTP health check if not.
Is there any impact to health checks if the weight of an ECS instance is zero?
If you set the weight of an ECS instance to zero, SLB no longer forwards traffic to this ECS instance. If the ECS instance is associated with a layer-4 listener, the health check of this ECS instance fails. If the ECS instance is associated with a layer-7 listener, the health check of the ECS instances is normal.
Setting the weight value to zero means manually removing the ECS instance from SLB. Generally, the weight is set to zero only when you restart, adjust, or maintain the ECS instance.
What health check method is used for HTTP listeners on backend ECS instances?
HEAD request method.
curl -v -0 -I -H "Host:" -X HEAD http://IP:port
What are the ranges of IP addresses that HTTP listeners use to perform health checks on backend ECS instances?
The IP address range used by SLB health checks is 100.64.0.0/10. This CIDR block is reserved by Alibaba Cloud. Other users cannot use any IP address in this CIDR block and therefore no security risks are involved. If the backend ECS instance enables access control such as iptables, you must allow the access of 100.64.0.0/10 on the NIC of the internal network.
Why is the health check frequency that is displayed on the console different from that recorded in the web logs?
Health checks are performed in the cluster to avoid single points of failure. Therefore, the health check frequency recorded in the logs is different from the frequency configured in the console.
Do health checks use system resources?
HTTP health checks consume few resources of the backend ECS instances.
How do I handle a health check failure caused by a faulty backend database?
Two web sites are configured on an ECS instance. The website www.test.com is a static website, and the website app.test.com is a dynamic website. A 502 error occurs due to a backend database fault when accessing www.test.com.
The domain name app.test.com is configured for health checks. RDS or self-built database failure causes the access error to app.test.com. Therefore, the health check fails.
Configure the domain name used for health checks to www.test.com.
Why is a network connection exception recorded in the backend service logs, but the TCP health check is displayed as successful?
After configuring the backend TCP port in an SLB listener, a network connection exception is frequently shown in the backend service logs. The requests are sent from the SLB instance and the SLB instance also sends RST packets to the backend server at the same time.
The problem is related to how the health check works.
TCP is transparent to the upper-layer applications and is utilized to reduce the cost of health checks and the impact on backend service. TCP health checks only perform a simple three-way handshake and then directly send RST packets to terminate the TCP connection. The data exchange process is as follows:
- The SLB instance sends a SYN packet to the backend port.
- The backend server replies with a SYN-ACK if the backend port is normal.
- After successfully receiving the response from the backend port, the SLB instance considers that the port is in normal status and the status of the backend server is normal.
- The SLB instance sends a RST packet to the backend port to actively terminate the connection. For now, a health check is completed.
After the health check succeeds, the SLB instance directly sends RST packets to terminate
the connection and no data is sent afterwards. Therefore, upper-layer services (such
as Java connection pool) deem that the connection is abnormal and errors such as
Connection reset by pee occur.
- Use the HTTP protocol.
- In terms of the service, filter the logs from the SLB IP address range and ignore related error messages.
Why is the health check result returned as abnormal when the service is running normally?
curl -ltest is normal as follows:
echo -e ‘HEAD /test.html HTTP/1.0\r\n\r\n’ | nc -t 192.168.0.1 80
If the returned status code is different from the normal status code configured in the console, the backend ECS instance is declared as unhealthy. For example, if the configured normal status code is http_2xx, the returning of all other status codes is considered as health check failure.
No error occurred when a curl test is performed on the Tengine/Nginx cluster, but a 404 error occurred in the test.html test file because the default site is used in the echo test.
- Modify the main configuration file and annotate the default site.
- Add the domain name used for health checks in the health check configurations.