tencent cloud

PrevNext

Feedback

search by keyword

Recent Pages

Documentation
Cloud Load Balancer
    Documentation
    Download PDF

    Troubleshooting Health Check Issues

    Last updated: 2024-01-04 14:39:00
    Download PDF
      Tencent Cloud Load Balancer (CLB) instances determine the availability of real servers by performing health checks. This document describes methods for troubleshooting the exceptions detected in a health check.
      Note:
      If an exception is detected in the health check on a real server, CLB instances stop forwarding traffic to the real server.
      If all the real servers are checked as abnormal, requests will be forwarded to all the real servers.
      For more information about how health check works, see Health Check Overview.

      Checking the Public Network Bandwidth of Real Servers

      If you use a bill-by-CVM account, you must specify the public network bandwidth for the backend CVM instances bound to CLB instances. Otherwise, the health check result will be abnormal. This is because the bandwidth attribute of the account is on CVM instances instead of CLB instances.
      If you use a bill-by-IP account, you do not need to specify the public network bandwidth for the backend CVM instances bound to CLB instances and this does not affect the load balancing service.
      Note:
      For more information about how to determine your account type, see Checking Account Type.
      A bill-by-CVM account does not pay traffic or bandwidth fees. Fees for public network traffic incurred by CLB are billed in the bound backend CVM instances.
      You can purchase public network bandwidth for a CVM instance without assigning a public network IP address to it.

      Checking Security Group Configuration

      Check whether the Allow Traffic by Default feature is enabled in the security group of the CLB instance. If not, you need to allow source IP addresses in the CVM security group. If your CLB service supports access from any IP addresses, set the source IP address to 0.0.0.0/0 in the inbound rules of the security group. For more information, see Configuring CLB Security Group.

      Checking Layer-4 Listeners

      Note:
      CLB checks server health by using SYN packets over Transmission Control Protocol (TCP).
      CLB checks server health by running the ping command over User Datagram Protocol (UDP).
      If you find an exception when viewing the health status of the CLB server ports on the page, use the following methods for troubleshooting:
      Confirm whether a security group is configured for CLB real servers and thus affecting the service. The security group performs access control on real servers to ensure normal service. For more information, see Configuring CVM Security Groups.
      Run the netstat command to check whether there is a listening process on the real server port. If no, restart the service.

      Checking Layer-7 Listeners

      For Layer-7 (HTTP protocol) services, when the health check result on a listener is abnormal, perform the following steps for troubleshooting:
      Because the layer-7 health check service of CLB communicates with backend CVM instances over the private network, you need to log in to the server to check whether the application server port is listened on normally at the private network address. If not, enable the listening of the application server port on the private network to ensure the normal communication between the CLB instance and backend CVM instances. Suppose that both CLB’s frontend port and CVM’s backend port are 80, and the CVM’s private IP is 1.1.1.10:
      For a Windows server, use the following command:
      netstat -ano | findstr :80
      For a Linux server, use the following command:
      netstat -anp | grep :80
      If you can see the listening of 1.1.1.10:80 or 0.0.0.0:80, the configuration is correct.
      Ensure that the backend port configured in CLB listener has been enabled on the real server.
      For a layer-4 CLB instance, run the telnet 1.1.1.10 80 command. If the backend port responds, the port is enabled.
      For a layer-7 CLB instance, the backend port must respond with an HTTP status code that indicates success, such as status code 200. The check method varies depending on the operating system:
      On Windows, enter the private IP address in the browser of a CVM instance to check whether it is normal. This example uses http://1.1.1.10.
      On Linux, you can run the curl -I command to check whether the status is HTTP/1.1 200 OK. This example uses the curl -I 1.1.1.10 command.
      Check whether the backend CVM instance has a firewall or other security software, which may block the local IP address of the CLB instance. As a result, the CLB instance may fail to communicate with the real server. Check whether the private network firewall of the server allows port 80 to pass. You can temporarily disable the firewall.
      On Windows, run the `firewall.cpl' command in the Run command window to disable the firewall.
      On Linux, run the /etc/init.d/iptables stop command to disable the firewall. If you use CenOS 7.x, run the systemctl stop firewalld command.
      Check whether the health check parameters of CLB are configured correctly. We recommend you use the default health check parameter values in Health Check Overview.
      For the test file specified for health check, we recommend you use a simple page in HTML format, which is used only to check the returned results. Dynamic programming languages such as PHP are not recommended.
      Check whether the CVM instance has high load that leads to slow response.
      Check the HTTP request method.
      If the HEAD method is used, the real server must support HEAD.
      If the GET method is used, the real server must support GET.
      The health check result may be abnormal if both the tcp_tw_recycle and tcp_timestamps parameters are enabled. We recommend that you disable tcp_tw_recycle. For more information, see Solution to Excessive Clients in TIME_WAIT Status.

      Highly Frequent Health Checks

      For example, you configured to send a health check packet every 5 seconds in the console. However, the real server receives one or more health check requests per second. This is mainly related to the implementation mechanism of CLB health check. Assume that 1 million requests from clients are distributed to four CLB servers, which then forward them to real servers. Each CLB server performs health checks separately. Therefore, if the CLB servers are configured to send a health check request every 5 seconds, each CLB server send a health check request every 5 seconds, and the real server may receive 4 health check requests within 5 seconds.
      
      This implementation mechanism is efficient and accurate, and avoids false removal of servers. For example, if one of the eight physical servers in a CLB cluster fails, the other seven servers can still forward traffic normally.
      
      If your business is load-sensitive, highly frequent health checks may cause business interruptions. You can reduce the business impact by setting a larger time interval, such as 15 seconds, for health checks.
      
      If a real server is bound to multiple CLB instances, each CLB instance sends health check packets to detect the server health, resulting in a high frequency of health checks.
      Contact Us

      Contact our sales team or business advisors to help your business.

      Contact Us
      Technical Support

      Open a ticket if you're looking for further assistance. Our Ticket is 7x24 avaliable.

      Submit a Ticket
      7x24 Phone Support
      Copyright © 2013-2024 Tencent Cloud. All Rights Reserved.
      Privacy PolicyLegalCookie Policy