Server Load Balancer:Configure and manage health checks

Configure health checks

You can configure health checks when you add a listener. The default health check settings are suitable for most use cases.

1. Log on to the CLB console.
2. In the top navigation bar, select the region where the CLB instance is deployed.
3. On the Instances page, find the CLB instance that you want to manage and click the ID of the instance.
4. On the instance details page, click the Listener tab. Click Add Listener or click Modify Listener in the Actions column.
5. Configure the listener as prompted. In the Health Check step, you can configure health checks. The health check feature is enabled by default. Click Edit on the right side of Advanced Settings to set the following parameters:

   Parameter	Description
   Health Check Protocol	Select the protocol that the CLB instance uses when it performs health checks. For TCP listeners, both TCP health checks and HTTP health checks are supported. A TCP health check is performed at the network layer. CLB probes the port of a backend server to check whether the server is healthy by sending SYN packets. An HTTP health check is performed in a similar way as a browser accesses a web page. CLB checks whether a backend server is healthy by sending HEAD or GET requests.
   Health Check Method (for HTTP and HTTPS health checks only)	Health checks of Layer 7 (HTTP or HTTPS) listeners support both the HEAD and GET methods. The HEAD method is used by default. If your backend server does not support the HEAD method or the HEAD method is disabled, the health check may fail. To resolve this issue, you can use the GET method instead. If the GET method is used and the response size exceeds 8 KB, the response is truncated. However, you can still identify the health check result based on the response. Note Health checks of Layer 7 listeners of all regions support the GET method.
   Health Check Path and Health Check Domain Name (Optional) (for HTTP health checks only)	By default, when CLB performs HTTP health checks, it tests the default homepage configured on a backend Elastic Compute Service (ECS) instance by sending HTTP HEAD requests to the private IP address of the ECS instance. If you do not want to use the default homepage for health checks, you can specify another URL path. Some application servers must verify the host field in requests before the application servers can accept the requests. In this case, the request header must carry the host field. If a domain name is configured in health check settings, CLB adds this domain name to the host field when CLB forwards a health check request to one of the preceding application servers. If no domain name is configured, CLB does not include the host field in the request. As a result, the request is rejected by the application server and the health check fails. If your application server needs to verify the host field in requests, you must configure a domain name in health check settings to ensure that the health check feature functions as normal.
   Normal Status Code (for HTTP health checks only)	Select the HTTP status code that indicates successful health checks. Default values: http_2xx and http_3xx.
   Health Check Port	Specify the backend port to be probed. By default, the backend port specified in the listener configuration is probed. Note If a vServer group or a primary/secondary server group is associated with the listener, and the Elastic Compute Service (ECS) instances in the server group use different ports, leave this parameter empty. CLB automatically probes the port of each ECS instance.
   Response Timeout	Specify the timeout period of a health check response. If a backend ECS instance does not return a health check response within the specified timeout period, the server fails the health check. Valid values: 1 to 300. Unit: seconds. Default value for UDP listeners: 10. Default value for HTTP, HTTPS, and TCP listeners: 5.
   Health Check Interval	The interval between two consecutive health checks. All nodes in the LVS cluster perform health checks independently and in parallel on backend ECS instances at the specified interval. However, the frequency at which a single ECS instance is probed does not conform to the health check interval because the nodes probe the ECS instance at different times. Valid values: 1 to 50. Unit: seconds. Default value for UDP listeners: 5. Default value for HTTP, HTTPS, and TCP listeners: 2.
   Unhealthy Threshold	The number of health checks that a backend ECS instance must consecutively fail before the ECS instance is considered unhealthy. Valid values: 2 to 10. Default value: 3.
   Healthy Threshold	The number of health checks that a backend ECS instance must consecutively pass before the ECS instance is considered healthy. Valid values: 2 to 10. Default value: 3.
   Health Check Requests and Health Check Results	When you configure a health check for a UDP listener, you can enter the request content (such as youraccountID) in the Health Check Requests field and the expected response (such as slb123) in the Health Check Results field. This operation adds the health check response logic to backend servers. For example, slb123 is returned when a youraccountID request is received. If CLB receives the expected response from a backend server, the health check succeeds. Otherwise, the health check fails. You can use this method to improve health check accuracy.

6. Click Next to proceed to the next step of listener configuration.

View health check information

1. Log on to the CLB console.
2. In the left-side navigation pane, choose CLB (FKA CLB) > Instances.
3. In the upper-right corner of the page, click the icon, and select Port/Health Check/Backend Server. The corresponding column is displayed on the Instances page.
4. On the Instances page, click the ID of the CLB instance whose health check information you want to view. Then, click the Listener tab to view the health check status of the listener.
   Listeners can be in one of the following health check states:

   • Initializing: indicates that the backend servers to be checked are being initialized.
   • Normal: indicates that all backend servers are healthy.
   • Abnormal: indicates that unhealthy backend servers exist.
   • Unavailable: indicates that the health check feature is not enabled.
5. Click Abnormal or Initializing corresponding to a listener to view the Listener/Forwarding Rule, Group, ECS Instance/Port, Health Status, and Cause parameters of the listener.

Health prechecks

Prerequisites for health prechecks

• Your CLB service is granted the required permissions to perform health prechecks on ECS instances. To grant the permissions, go to RAM Roles.
• Backend ECS instances must meet the following requirements:
  • The ECS instances are deployed in virtual private clouds (VPCs).
  • Linux and Cloud Assistant are installed.
  • The instances are in the Running state and the default shell is bash.
• The health check feature is enabled for the listener of the CLB instance, and the ECS instances are added to the backend server group of the CLB instance.

1. Log on to the CLB console.
2. On the Instances page, find the CLB instance that you want to manage and click the ID of the instance.
3. On the Listeners tab, find the listener for which you want to perform a health precheck and click Modify Listener in the Actions column.
4. On the Configure Listener page, click Next until the Health Check step appears.
5. Click Health Precheck in the Advanced section.
6. On the Health Precheck page, find the backend server on which you want to perform a health precheck and click Start Detection in the Actions column.
   You can select up to five ECS instances at a time. If you want to perform a health precheck on more than five ECS instances, divide these ECS instances into batches.
7. Click OK to perform the health precheck. After the health precheck is completed, the result is displayed in the console.
   The following table describes the check items that are supported by listeners.

   Listener type	Status of health check ports	iptables configuration	rpfilter configuration	Response upon HTTP probing	UDP probing
   TCP	✔	✔	✔	✔	-
   UDP	✔	✔	✔	-	✔
   HTTP	✔	✔	✔	✔	-
   HTTPS	✔	✔	✔	✔	-

   To view the detailed health precheck results, log on to the ECS console and go to the ECS Cloud Assistant page, select the region where the ECS instance is deployed, and then click the Command Execution Result tab.

Disable the health check feature

You can disable the health check feature for a CLB instance as needed. When you disable the health check feature, CLB will continue distributing requests to unhealthy backend ECS instances, which causes service interruptions. We recommend that you enable the health check feature.

1. Log on to the CLB console.
2. On the Instances page, find the CLB instance that you want to manage and click the ID of the instance.
3. On the Listeners tab, find the listener for which you want to perform a health precheck and click Modify Listener in the Actions column.
4. On the Configure Listener page, click Next until the Health Check step appears.
5. Turn off the Enable Health Check switch and click Next.
6. Click Submit and click OK.

References

• Health check overview
• Store and download health check logs

API references

• TCP listeners
  • CreateLoadBalancerTCPListener: Configure health checks when you create a TCP listener.
  • SetLoadBalancerTCPListenerAttribute: Configure or disable health checks when you modify a TCP listener.
• UDP listeners
  • CreateLoadBalancerUDPListener: Configure health checks when you create a UDP listener.
  • SetLoadBalancerUDPListenerAttribute: Configure or disable health checks when you modify a UDP listener.
• HTTP listeners
  • CreateLoadBalancerHTTPListener: Configure health checks when you create an HTTP listener.
  • SetLoadBalancerHTTPListenerAttribute: Configure or disable health checks when you modify an HTTP listener.
• HTTPS listeners
  • CreateLoadBalancerHTTPSListener: Configure health checks when you create an HTTPS listener.
  • SetLoadBalancerHTTPSListenerAttribute: Configure or disable health checks when you modify an HTTPS listener.