If a client cannot access a backend server through a load balancer, the backend server is declared unhealthy. You can check the health check result of the backend server on the ELB console.
On the Load Balancers page, click the name of the load balancer to view its details. Click Backend Server Groups and locate the server group. In the Basic Information area, view the health check result of the backend server.
On the Load Balancers page, click the name of the load balancer to view its details. Click Backend Server Groups and locate the server group. In the Basic Information area, view the health check result of the backend server.
The load balancer uses IP addresses in 100.125.0.0/16 to send heartbeats to backend servers and check their health. To ensure that health checks can be performed normally, IP addresses in 100.125.0.0/16 must be allowed to access the backend servers.
Security group rules configured for backend servers associated with dedicated load balancers are different from those configured for backend servers associated with shared load balancers.
For details about how to configure security groups for backend servers associated with dedicated load balancers, see Configuring Security Group Rules for Backend Servers (Dedicated Load Balancers).
If a backend server is considered unhealthy, ELB will not route traffic to it until it is declared healthy again.
If you change the weight of a healthy backend server to 0, the health check result of this server becomes Unhealthy.
Possible causes are sequenced based on their occurrence probability.
Check these causes one by one until the fault persists.
You may need to change the health check configuration. It takes a while for the modification to take effect. The required time depends on health check interval and timeout duration. View the health check result in the backend server list of the load balancer.
Figure 1 Troubleshooting processPossible Cause |
Solution |
---|---|
Backend server group |
Checking Whether the Backend Server Group Is Associated with a Listener |
Health check configuration |
|
Security group rules |
|
Network ACL rules |
|
Backend server listening configuration |
|
Backend server firewall configuration |
|
Backend server route configuration |
|
Backend server load |
|
Backend server host.deny file |
Check whether the backend server group that the unhealthy backend server belongs to is associated with a listener.
Classic load balancers: In the Listeners area, locate the listener with an unhealthy backend server associated and click View in the Health Check column. The Health Check dialog box is displayed. Check the following parameters:
The health check port must be the one used on the backend server, and it cannot be customized.
Check whether the health check port is the one that the load balancer is listening to. If the two ports are inconsistent, the health check will become abnormal.
Enter an absolute path.
Examples:
If the URL is http://www.example.com/chat/try/, the health check path is /chat/try/.
If the URL is http://192.168.63.187:9096/chat/index.html, the health check path is /chat/index.html.
Shared load balancers: Click the name of the load balancer to view its details. Click Backend Server Groups and then click the name of the server group. On the Basic Information page, click Configure on the right of Health Check. Check the following parameters:
If the URL is http://www.example.com/chat/try/, the health check path is /chat/try/.
If the URL is http://192.168.63.187:9096/chat/index.html, the health check path is /chat/index.html.
The inbound rules of the security group that the backend server belongs to must allow traffic to the VPC where the load balancer resides.
You can check the protocol and port in the basic information area of the backend server group.
You can check the protocol and port in the basic information area of the backend server group.
You can associate one or more subnets with a firewall for controlling traffic in and out of the subnets. Similar to security groups, firewalls provide access control functions, but add an additional layer of defense to your VPC. Default firewall rules reject all inbound and outbound traffic. If the subnet of a load balancer or associated backend servers has a firewall associated, the load balancer cannot receive traffic from the Internet or route traffic to backend servers, and backend servers cannot receive traffic from and respond to the load balancer.
You can configure an inbound firewall rule to permit access from 100.125.0.0/16.
If the backend server runs a Windows OS, use a browser to access https://Backend server IP address:Health check port. If a 2xx or 3xx code is returned, the backend server is running normally.
netstat -anlp | grep port
If the health check port and LISTEN are displayed, the backend port is in the listening state. As shown in Figure 8, TCP port 880 is listened on.
If you do not specify a health check port, backend ports are used by default.Figure 8 Backend server port listened oncurl Private IP address of the backend server:Health check port/Health check path -iv
To perform an HTTP health check, the load balancer initiates a GET request to the backend server. If the following response status codes are displayed, the backend server is considered healthy:
TCP listeners: 200
Public network classic load balancers: 2xx or 3xx
Dedicated load balancers: 200 for TCP/UDP/HTTP/HTTPS health checks
Shared load balancers: 200, 202, or 401 for HTTP health checks, and 200 for TCP health checks
Figure 10 Unhealthy backend serverOn the Listeners tab page, modify the listener, select the backend server group for which TCP health check has been configured, or add a backend server group and select TCP as the health check protocol. After you complete the configuration, wait for a while and check the health check result.
The firewall or other security software on the backend server may mask IP addresses in 100.125.0.0/16. Ensure that access from 100.125.0.0/16 is allowed in the security group containing the backend server.
Check whether the default route configured for the primary NIC has been manually modified. If the default route is changed, health check packets may fail to reach the backend server.
Run the following command on the backend server to check whether the default route points to the gateway (For Layer 3 communications, the default route must be configured to point to the gateway):ip route
Alternatively, run the following command:
route -n
If the command output does not contain the highlighted route or the IP address to which the route points is not the gateway address of the VPC subnet, change the route to the default one.
Figure 12 Example default route pointing to the gatewayCheck the load of the backend server. If the load is high, connections or requests for health checks may time out.
Verify that IP addresses in 100.125.0.0/16 are not written to the /etc/hosts.deny file on the backend server.
Parent topic: Health Check