All Products
Search
Document Center

Server Load Balancer:Configure and manage CLB health checks

Last Updated:Jan 25, 2024

Classic Load Balancer (CLB) performs health checks to check the availability of backend servers. After you enable the health check feature, if a backend server is declared unhealthy, CLB stops forwarding requests to the backend server and distributes subsequent requests to healthy backend servers. After the unhealthy backend server recovers, CLB distributes requests to the backend server. The health check feature prevents single points of failure (SPOFs) caused by unhealthy backend servers and improves the availability of services.

Note

Before you configure health checks, we recommend that you understand how CLB health checks work.

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

    Description

    Health Check Protocol

    Select the protocol of the health check. For TCP listeners, both TCP 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

    (only for HTTP and HTTPS 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

    Specify the backend port to be probed. Backend server ports are probed by default.

    Note

    If a vServer group or a primary/secondary server group is associated with the listener, and the backend servers in the server group use different ports, leave this parameter empty. 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, CLB sends HTTP requests to the default homepage configured on a 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 successful health checks.

    Default values: http_2xx and http_3xx.

    Health Check Response Timeout

    The maximum timeout period of 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 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.

    Unhealthy Threshold

    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 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 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. 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. 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 the health check feature

Important

If your business is highly sensitive to traffic fluctuations, frequent health checks may affect the availability of your business. To reduce the impacts of health checks on your business, you can reduce the health check frequency, increase the health check interval, or change Layer 7 health checks to Layer 4 health checks. To ensure business continuity, we recommend that you enable the health check feature.

If you disable the health check feature, CLB continues to distribute 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. 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. 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