Health Check

Health checks can help determine whether back-end servers are functioning normally. Unhealthy back-end servers will be removed from the server pool, and client requests will be distributed among other servers. When servers that are in an abnormal state return to normal, they will be reinstated into the server pool.

Health Check Methods Supported by Different Types of VServers

Applicable Scenarios for Different Health Checks

Overall, health check methods can be divided into two categories: checking port survival and checking service survival.

Port survival check: Includes Port Check and Ping Detection.

Service Survival Check: Includes HTTP Check and UDP Check.

Detailed Description of Different Health Check Methods

Port Check

Within each availability zone, dedicated servers are deployed to check if the IP + port of the back-end nodes is working properly. The probe frequency is 2s. If probe fails three times consecutively, the back-end server status is abnormal. If probed successfully for three times consecutively, the back-end server status is normal. Note: Data updating has a 6s delay, so the health check status may have a delay of 6s.

All protocols support port checking, but the detection statuses slightly vary: HTTP, HTTPS and TCP request proxy mode use TCP for probing. However, TCP packet forwarding mode and UDP protocol use the selected four-layer protocol for port detection.

HTTP Check

This method checks via HTTP HEAD request whether the application on the back-end server is available, which requires the back-end servers to support HEAD requests.

When implementing HTTP health check, users need to configure the HTTP check path (if necessary, they can also configure the HTTP check domain, but this is usually not needed). Together they constitute the HTTP check URL. An HTTP HEAD request is made to this URL. If the request response code is 2xx or 3xx, then the back-end server is considered to be functioning properly. The health check probe cycle is 2s. If the probe fails consecutively three times, the back-end node is unhealthy. If it remains normal for two successive times, it is healthy.

Maximum characters for HTTP check path is 227, directly add relative path file after domain name or IP address. This could be the homepage, any page with a small probability of failure, or a vacant file specially prepared for health checking(200 response code can be obtained through HTTP HEAD request). Note that using the homepage might increase server pressure, therefore it is not recommended to use homepage as HTTP health check domain and path.

For HTTP check domain, it’s not recommended to write “http:” or “https:“. Simply input the domain name or IP address. It supports main domain name, secondary domain name, and multilevel domain names.

HTTP check is supported by HTTP protocol and HTTPS protocol (Layer 7 service).

UDP Check

According to the health check configuration, the health check service sends a UDP request message to the service node every 2s. If a predetermined UDP response message can be received within 2s after the request is sent, it is considered that the service node has responded successfully.

Health check success: Three consecutive successful responses.

Health check failure: Three consecutive failed responses.

For example, if a service node’s current status is “healthy”, the node status will not change to “failure” unless the service node response fails three times consecutively.

Note: For UDP Check, to avoid service nodes responding to the request message incorrectly, service nodes cannot bind to 0.0.0.0/0.