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)	Health checks of Layer 7 (HTTP or HTTPS) listeners support 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, the health check may fail. To resolve this issue, you can use the GET method. If the GET method is used and the response size exceeds 8 KB, the response is truncated. However, you can still obtain the health check result based on the response.
   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.
   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.
   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.

Health prechecks

After you add ECS instances to a CLB instance, you can use Cloud Assistant to execute a health precheck script on the ECS instances and view the health precheck results. Heath precheck scripts are generated based on the health check configurations of listeners.

• You cannot execute a health precheck script on backend servers that are associated with forwarding rules.

• The health precheck results may differ from the actual health check results because different connections are used to perform these checks. The health precheck results provide only suggestions on health check configurations.

Prerequisites for health prechecks

• The AliyunSLBHealthDiagnoseRole RAM role is assigned to CLB to allow CLB to access ECS instances.

• Backend ECS instances must meet the following requirements:

  • The ECS instances are deployed in virtual private clouds (VPCs).

  • Linux and Cloud Assistant are installed. For information about how to install Cloud Assistant Agent, see Install Cloud Assistant Agent.

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

Health precheck procedure

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. Click Health Precheck on the right side of Advanced Settings.

   The first time you use health prechecks, click Activate Now. On the Cloud Resource Access Authorization page, click Confirm Authorization Policy. The system automatically creates the AliyunSLBHealthDiagnoseRole role and assigns the role to CLB. CLB assumes this role to access backend ECS instances.

7. 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.

8. 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	✔	✔	✔	✔	-

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.