This topic describes how to configure health check. You can configure health check when you create a listener or for an existing listener. The default health check settings can meet your requirements in most cases.

Background information

You can configure health check by using the SLB console or API calls. For more information, see Health check overview and Health check FAQ.

Procedure

  1. Log on to the Server Load Balancer console.
  2. Select the region of the target SLB instance.
  3. Find the target SLB instance and click its instance ID.
  4. Click the Listener tab.
  5. Click Add Listener, or find the target listener and click Modify Listener in the Actions column.
  6. Click Next to go to the Health Check step. Click Modify next to Advanced.
    Configure Health Check
    We recommend that you use the default settings when you configure the health check.
    Table 1. Health check configuration
    Parameter Description
    Health Check Protocol
    Select the protocol for health check. For TCP listeners, both the TCP health check and HTTP health check are supported.
    • The TCP health check implements detection at the network layer by sending SYN packets to check if a port is open.
    • The HTTP health check verifies the health of a backend server by sending HEAD/GET requests to simulate browser access.
    Health Check Method

    (for the HTTP and HTTPS health checks only)

    The health check of Layer-7 (HTTP or HTTPS) listeners supports both the HEAD and GET methods. The HEAD method is used by default.

    If your backend applications do not support the HEAD method or if 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, the health check result is not affected.

    Note Only the India (Mumbai) region supports the GET method.
    Health Check Path and Health Check Domain Name (Optional)

    (for the HTTP health check only)

    By default, SLB performs the health check by sending HTTP HEAD requests to the default homepage of the application deployed on the ECS instance with the internal IP address of the ECS instance.

    If you need to use another web page other than the default homepage for the health check, you must specify a request path.

    Some application servers require the request header to contain the host field for verification. If a domain name is configured in health check settings, SLB adds this domain name to the host field when forwarding a health check request to one of the preceding application servers. If no domain name is configured, SLB does not include the host field in the request, which means that the request will be rejected by the application server and the health check may fail. Therefore, if your application server verifies the host field in requests, you must configure a domain name in health check settings to make sure that the health check can run properly.

    The URL path for the health check must be 1 to 80 characters in length and can contain letters, digits, hyphens (-), underscores (_), forward slashes (/), periods (.), percent signs (%), question marks (?), number signs (#), ampersands (&), and equals signs (=).

    The health check domain name can contain letters, digits, periods (.), and hyphens (-). The internal IP addresses of backend servers are used as domain names for the health check by default.

    Normal Status Code

    (for the HTTP health check only)

    Select the HTTP status code that indicates a successful health check.

    Default values: http_2xx and http_3xx.

    Health Check Port Set the detection port used by health check to access backend servers.

    By default, the backend port configured for the listener is used.

    Valid values: 1 to 65535.

    Note If a VServer group or an active/standby server group is configured for the listener, and the ECS instances in the group use different ports, leave this parameter empty. SLB uses the backend ports of the ECS instances to perform the health check.
    Response Timeout Specify the amount of time to wait for a health check response. If the backend ECS instance does not send an expected response within the specified response timeout period, the health check fails.

    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 Specify the interval between health checks.

    All nodes in the LVS cluster perform health checks independently and in parallel on backend ECS instances at the specified interval. The health check statistics of a single ECS instance cannot reflect the health check interval because the nodes perform health checks 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 Specify the number of consecutive failed health checks that must occur before an ECS instance is declared unhealthy.

    Valid values: 2 to 10. Default value: 3.

    Healthy Threshold Specify the number of consecutive successful health checks that must occur before an ECS instance is declared healthy.

    Valid values: 2 to 10. Default value: 3.

    Health Check Requests and Health Check Results When you configure health check for a UDP listener, you can enter the request content (such as youraccountID) in Health Check Requests and the expected response (such as slb123) in Health Check Results.

    This operation adds the health check response logic to backend servers. For example, return slb123 when a youraccountID request is received.

    If SLB receives the expected response from the backend server, the health check succeeds. Otherwise, the health check fails. You can use this method to improve the accuracy of the health check.

  7. Click Next.