Server Load Balancer:Configure and manage CLB health checks

Configure health checks

You can configure the health check feature when you add a listener. In most cases, you can use the default health check settings.

1. Log on to the CLB console.

2. In the top navigation bar, select the region in which the CLB instance is deployed.

3. In the left-side navigation pane, choose CLB > Instances. 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 by following the wizard until you enter the Health Check step. The health check feature is enabled by default. Click Edit next to Advanced Settings to configure the following parameters.

   Parameter	Procedure
   Health Check Protocol	Select a protocol for health checks. If the listener protocol is TCP, set the health check protocol to TCP or HTTP. If the listener protocol is UDP, set the health check protocol to TCP, UDP, or HTTP. If the listener protocol is HTTP or HTTPS, set the health check protocol to HTTP. TCP health checks are performed at the network layer. CLB probes the port of a backend server to check whether a server is healthy by sending SYN packets. UDP health checks probe whether a server is healthy by sending UDP packets. HTTP health checks are 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 (only for HTTP health checks)	Supports both the HEAD and GET methods. The HEAD method is used by default. Note If your backend server does not support the HEAD method or the HEAD method is disabled, use the GET method. If the GET method is used and the response size exceeds 8 KB, the response is truncated. However, this does not affect the health check results.
   Health Check Port	Select the backend port that is used for health checks. By default, backend server ports are probed. Note If all the backend servers in the server group associated with the listener use different ports, you do not need to specify a port for health checks. CLB automatically probes the port of each backend server.
   Health Check Path (only for HTTP health checks)	By default, when CLB performs HTTP health checks on a backend server, CLB sends HTTP requests to the default homepage configured on the backend server. If you do not want to use the default homepage for health checks, you can specify a path. We recommend that you use static pages for health checks.
   Health Check Domain Name (only for HTTP health checks)	If a domain name is configured in health check settings, CLB adds this domain name to the Host header when CLB forwards a health check request to application servers. If no domain name is configured, CLB does not include the Host header in the request. Some application servers must verify the Host header in requests before the application servers can accept the requests. If the health check domain name is not configured and health check requests do not contain the Host header, the requests are rejected by application servers and the health check fails. If your application server needs to verify the Host header in requests, you must configure a domain name in health check settings to ensure that the health check feature works as expected. Note CLB performs health checks according to the health check path set for listeners, which is the root path by default, rather than URLs configured for a forwarding policy. If you have configured forwarding rules for requests destined for the same domain name but different URLs, but have not modified the health check path for the listeners, the backend server group may be declared unhealthy unexpectedly. You must modify the health check path based on your needs in the forwarding rules.
   Healthy Status Codes (only for HTTP health checks)	Select the HTTP status codes that indicate healthy backend servers. Default values: http_2xx and http_3xx. Note If the backend servers are running as expected but are declared unhealthy by CLB, you can specify http_4xx and http_5xx as normal HTTP status codes in health check settings to prevent CLB from declaring backend servers unhealthy for receiving 4XX or 5XX status codes.
   Health Check Response Timeout	Specify a maximum timeout period for a health check response. If a backend server does not respond within the specified timeout period, the backend server is declared unhealthy.
   Health Check Interval	Specify the interval between two consecutive health checks. All nodes in the cluster perform health checks independently and in parallel on backend servers at the specified interval. However, the frequency at which a single server is probed does not conform to the health check interval because the nodes probe the backend servers at different points in time.
   Healthy Threshold	Specify the number of times that an unhealthy backend server must consecutively pass health checks before it is considered healthy.
   Unhealthy Threshold	Specify the number of times that a healthy backend server must consecutively fail health checks before it is considered unhealthy.
   Health Check Request and Health Check Result (only for UDP health checks)	When you configure a health check for a UDP listener, you can enter the request content (such as youraccountID) in the Health Check Request field and the expected response (such as slb123) in the Health Check Result 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 backend server is considered healthy. Otherwise, the backend server is considered unhealthy. You can use this method to improve the accuracy of UDP health checks.

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 top navigation bar, select the region in which the CLB instance is deployed.

3. On the Instances page, click the ID of the CLB instance that you want to manage.

4. On the instance details page, click the Listener tab to view the health check status of the listener.

   Listeners can be in the following health check states:

   • Initializing: indicates that the backend servers to be checked are being initialized.

   • Healthy: indicates that all backend servers are healthy.

   • Error: 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.

Disable health checks

If you disable the health check feature, CLB distributes 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. In the top navigation bar, select the region in which the CLB instance is deployed.

3. In the left-side navigation pane, choose CLB > Instances. 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 until you enter the Health Check step.

6. Disable the health check feature and click Next.

References

• For more information about CLB health checks, see CLB health checks.

• For more information about how to troubleshoot health check issues, see FAQ about health checks.

• For more information about how to query and analyze health check logs, see Store and download health check logs.