Health Examination

• Converge CloudCLB instance can periodically send Pings, connection attempts, or requests to backend servers to test the running status of the backend servers. These tests are called health checks.
• When a backend server instance is determined to be unhealthy, the CLB instance will not forward requests to that instance. However, health checks will be performed on all backend servers (regardless of whether they are assessed to be healthy or unhealthy). When the unhealthy instance returns to normal, the CLB instance will resume forwarding new requests to it.
• The auto scaling group periodically uses a similar method to determine the operating status of each instance in the group. For more information, see Auto scaling.

Layer-4 forwarding health check configuration

The health check mechanism of layer-4 forwarding: the CLB initiates an access request to the server port specified in the configuration. If the port access is normal, the backend server is considered to be running normally, otherwise it is considered to be running exceptionally.
For TCP business, use SYN packets for detection; for UDP business, use Ping for inspection.

Layer-7 forwarding health check configuration

The health check mechanism of layer-7 forwarding is that the CLB sends HTTP requests to the backend server to detect the backend service. The CLB checks whether the service is normal based on the HTTP return value selected by the user. Assume that in a certain scenario, the HTTP return value is http_1xx, http_2xx, http_3xx, http_4xx and http_5xx. Users can edit http_1xx and http_2xx according to business needs as normal service status and set the return values of http_3xx is set to http_5xx as the exception status.

Health check status

Based on the health check detection situation, the health check status of the backend service is as follows:

Troubleshooting ideas for health check exceptions

Layer-4 troubleshooting

Under the TCP protocol, the CLB uses SYN packets for detection; under the UDP protocol, the CLB uses the ping command for detection.
Check the health status of the backend server port on the page. If it is unhealthy, the troubleshooting ideas are as follows:

• Determine whether the backend server has a security group configured that affects the service. For information on how to control access to backend servers to ensure normal service operation, see Backend CVM Security Group Configuration Instructions.
• Using netstat command to determine whether there is a process listening on the port of the backend server. If no process is found, restart the service.

Layer-7 troubleshooting

For layer-7 (HTTP/HTTPS protocol) services, when a health check exception occurs in a listener, you can troubleshoot it through the following aspects:

1. Since the layer-7 health check service of the CLB communicates with the backend CVM through the private network, you need to log in to the server to check whether the application server port is normally listening on the private network address. If it is not listening on that address, let the application server port listen on the private network to ensure normal communication between CLB system and the backend CVM.
   Assume that the front-end port of the CLB is 80, the back-end port of the CVM is also 80, and the private IP address of the CVM is: 1.1.1.10.

   For Windows servers, use the following command:

   netstat -ano | findstr :80
   

   For Linux servers, use the following command:

   netstat -anp | grep :80
   

   If you can see 1.1.1.10:80 Listening or 0.0.0.0:80 If the monitoring is successful, this configuration is normal.

2. Make sure that the backend server has opened the backend port you configured in the CLB listener.
   If it is a layer-4 CLB, as long as the backend port telnet responds, you can use telnet 1.1.1.10 80 to test. If it is a layer-7 CLB, the HTTP status code needs to be 200 or other normal status codes. The inspection method is as follows:

• In Windows, you can directly enter the private IP address in the browser in CVM to test whether it is normal. In this example, use http://1.1.1.10 is used..
• Linux system can use curl -I command to check if the status is HTTP/1.1 200 OK In this example, use curl -I 1.1.1.10 Order.

3. Check whether there is a firewall or other security protection software inside the backend CVM. This type of software can easily block the local IP address of the CLB system, causing that system to be unable to communicate with the backend server.
   Check whether the server's private network firewall allows access to port 80. You can temporarily close the firewall for testing.

• For Windows systems, enter firewall.cpl to close.
• For Linux systems, enter /etc/init.d/iptables stop to close.

4. Check whether the CLB health check parameters settings are correct. It is recommended to set them according to the default values of the health check parameters provided in this document.
5. The detection file specified by the health check is recommended to be a simple HTML page, which is only used to check the return results. It is not recommended to use dynamic scripting languages such as PHP.
6. Check whether the backend has a high load, causing the CVM to respond slowly to external services.
7. Check the HTTP request method. If the HEAD method is used, the backend service must support HEAD. If the method is GET, the backend service must support GET.

Explanation of frequent health check detection

The frequency of health check probe packets is too high. The console is set to receive probe packets once every 5 seconds. In fact, the backend RS found that it received one or more health check requests within 1 second. The reason is:

• Currently, the problem of too high a health check frequency is mainly related to the implementation mechanism of the health detection of the CLB backend. Assume that 1 million client requests are distributed on 4 CLB backend physical machines and then transferred to the CVM. The health check detection is performed on the backend physical machines of the CLB separately. Therefore, the CLB instance sets a detection request every 5 seconds. In fact, each physical machine in the CLB backend sends a detection every 5 seconds. Therefore, multiple detection requests are received on the backend CVM. (Assuming that the cluster where the CLB instance is located has 8 physical machines, each machine sends a request once every 5 seconds, and the backend host may receive 8 times detection in 5 seconds.)
• The strengths of this implementation scheme are high efficiency, accurate detection, and avoidance of false elimination. For example, among the eight physical machines in the CLB instance cluster, if one fails, only one machine no longer forwards traffic, while the traffic of the other seven machines is normal.
  Therefore, if the detection frequency of your backend CVM is too high, you can solve it by setting a longer detection interval (for example, setting it to detect once every 15 seconds).