GWLB determines the availability of real servers through health checks to avoid real server exceptions from affecting frontend businesses, thereby improving the overall availability of businesses.
After the health check feature is enabled, health checks will be performed regardless of the real server weight (including 0). You can view the "health status" of real servers on the Instances in the Target Group tab of the target group details page.
After a real server instance is considered abnormal, the GWLB instance will automatically forward new requests only to other normal real servers.
After the abnormal instance returns to normal, GWLB will resume the load balancing service for it and forward requests to this instance again.
If all real servers are considered abnormal in health checks, requests will be forwarded to all the real servers.
If health check is disabled, GWLB will forward traffic to all real servers (including abnormal real servers), so it is strongly recommended to enable health check, allowing GWLB to automatically check real servers and remove abnormal servers for you.
Health Check Status
Based on the health check status, the health check status of a real server is as follows:
Status
Description
Whether to Forward Traffic
Detecting
When the target group is not bound to any GWLB instance, the instances (real servers) in the target group are all in the detecting status.
Status of the newly bound real server within a period equal to the check interval multiplied by the healthy threshold. For example, if the check interval is 2 seconds and the healthy threshold is 3 times, the period is 6 seconds.
GWLB does not forward traffic to "detecting" real servers.
Healthy
The real server is normal.
GWLB forwards traffic to "healthy" real servers.
Abnormal
The real server is abnormal.
GWLB does not forward traffic to "abnormal" real servers.
If GWLB detects that all real servers are unhealthy, it will activate the All-Alive or All-Dead logic, that is, requests will be forwarded to all real servers with a non-zero weight.
Disabled
Health check is disabled.
GWLB forwards traffic to all real servers.
TCP Health Check
TCP health check is conducted with SYN packets (by initiating a TCP three-way handshake) to obtain the status information of a real server.
The TCP health check mechanism is as follows:
Search for the required CAM policy as needed, and click to complete policy association.
1. GWLB sends a SYN connection request packet to a real server (the VIP address and health check port of the GWLB instance).
2. After the real server receives the SYN request packet, it will return a SYN-ACK response packet if the corresponding port is in the normal listening state.
3. If GWLB receives the SYN-ACK response packet from the real server within the response timeout period, it indicates that the server is normal and the health check is successful. It will send an RST reset packet to the real server to interrupt the TCP connection.
4. If GWLB does not receive the SYN-ACK response packet from the real server within the response timeout period, it indicates that the server is abnormal and the health check fails. It will send an RST reset packet to the real server to interrupt the TCP connection.
PING Health Check
If you select the PING check method, only ICMP ECHO packets are used for check.
Search for the required CAM policy as needed, and click to complete policy association.
The health check mechanism is as follows:
1. GWLB issues a Ping command to the private IP address of a real server.
2. If the Ping is successful, it indicates that the server is normal and the health check is successful.
3. If the Ping fails, it indicates that the server is abnormal and the health check fails.
Note:
The health check relies on the ICMP protocol and the real server needs to allow ICMP packet responses (supporting Ping).
Health Check Time Window
The health check mechanism of GWLB effectively improves the business availability. To avoid the system availability impact caused by frequent health check failures, switching between healthy and unhealthy status only occurs after multiple consecutive successful or failed checks within the health check time window. The health check time window is determined by the following factors:
Health Check Configuration
Description
Default Value
Response timeout
The maximum timeout for health check responses.
If a real server fails to respond within the timeout period, it is considered as abnormal.
Configurable range: 2-30 seconds.
2 seconds
Check interval
The interval for the CLB health check.
Configurable range: 2-300 seconds.
5 second
Unhealthy threshold
If a real server has failed to pass the health check for n (n is the input value) consecutive times, it is considered as unhealthy and the health check result is displayed as failure in the console.
Configurable range: 2-10 times.
3 times
Health threshold
If a real server has passed the health check for n (n is the input value) consecutive times, it is considered as healthy and the health check result is displayed as success in the console.
Configurable range: 2-10 times.
3 times
The health check time window is calculated as follows:
Time window of a failed health check = Response timeout period x Unhealthy threshold + Check interval × (Unhealthy threshold - 1)
In the example below, the health check response timeout period is 2 seconds, the check interval is 5 seconds, and the unhealthy threshold is 3 times, so the time window of a failed health check is calculated as 2 x 3 + 5 x (3 - 1) = 16 seconds.
Time window of a successful health check = Response timeout period x Healthy threshold + Check interval x (Healthy threshold - 1)
In the example below, the health check response timeout period is 1 second, the check interval is 5 seconds, and the healthy threshold is 3 times, so the time window of a successful health check is calculated as 1 x 3 + 5 x (3 - 1) = 13 seconds.
Health Check Identifier
After GWLB health check is enabled, the real servers will receive health check requests in addition to normal business requests. The source IP address of the health check requests is the VIP address of GWLB.
