1. What scheduling algorithms are supported by Server Load Balancer (SLB)?
The following scheduling algorithms are supported:
Round robin (RR): Requests are distributed across the group of backend ECS servers sequentially.
Weighted round robin (WRR): You can set a weight for each backend server. Servers with higher weights receive more requests than those with lower weights.
Weighted least connections (WLC): In addition to the weight set to each backend ECS server, the number of connections to the client is also considered. A server with a higher weight value will receive a larger percentage of live connections at any one time. If the weights are the same, the system directs network connections to the server with the least number of established connections.
2. What is the difference between the Internet SLB and the intranet SLB?
The Internet SLB can distribute client requests from the Internet. A public IP is assigned to an Internet SLB instance.
The intranet SLB can only distribute client requests from the intranet. A private IP is assigned to an intranet SLB instance.
3. Can I modify the SLB instance type?
The SLB system allocates an instance IP (a public IP or a private IP) based on the SLB instance type. To switch the SLB instance type, you must first delete the instance and create a new SLB instance of the expected type.
4. Is the allocated IP address exclusive to the SLB Instance?
The IP address of the SLB instance is exclusive to the load balancing service you purchased during the entire lifecycle. Changing the SLB configurations and listening rules will not affect the IP address.
If the SLB IP has been resolved to a domain name to provide public services, do not delete the corresponding SLB instance unless necessary. The configurations and the IP will be deleted along with the deletion of the instance and cannot be restored. If you recreate a SLB instance, the system will allocate a new IP.
5. Does SLB support HTTP redirection?
SLB supports redirecting HTTP to HTTPS. For more information, see Redirect HTTP to HTTPS.
6. What is the difference between pinging the IP of the SLB instance and pinging the IP of a backend ECS instance?
When pinging the IP of an SLB instance, the response is sent from the SLB cluster. The request will not be forwarded to backend ECS instances.
When pinging the IP of a backend ECS instance, the response is sent from the backend ECS instance and has no relationship with the SLB.
7. Does SLB rely on the Internet bandwidth?
The communication between the SLB and backend ECS instances goes through the intranet, therefore, no need to configure extra Internet bandwidth for backend ECS instances.
However, if you want to provide public services through both the SLB and ECS instances at the same time, the corresponding ECS instances need to be configured with sufficient Internet bandwidth. The Internet bandwidth of backend ECS instances has no impact on the service capability of the SLB.
8. Is there any impact on the load balancing service if the public NIC is disabled?
If the ECS instance has configured a public IP, disabling the public NIC will impact the load balancing service.
The traffic goes through the public NIC If the backend ECS is configured with a public IP. When the public NIC is disabled, the returned data packet cannot be sent.
9. How to avoid the service failure of the SLB itself?
Add backend ECS instances in different zones to improve the local availability.
Create multiple SLB instances in the same region and use DNS to provide public services to improve the local availability.
Create multiple SLB instances in different regions and use DNS to provide public services to improve the cross-region availability.
10. What does the SLB balance?
The SLB distributes network traffic to backend ECS instances according to the specified scheduling algorithm:
Layer-4 listeners distribute the traffic based on TCP connections.
Layer-7 listeners distribute the traffic based on HTTP requests, such as an HTTP GET request.
11. Why is the traffic not balanced?
The following are possible reasons:
Have enabled session persistence
If session persistence is enabled, it will cause traffic imbalance when fewer clients are accessing the SLB instance.
This is especially common when a small number of clients are used to test the SLB instance. For example, session persistence (source-IP-based) is enabled for a TCP listener and a client is used to test the load balancing service.
Abnormal ECS status
Backend servers with abnormal heath status can also lead to an imbalance especially during stress test. If the health check for a backend ECS instance fails or its health status changes frequently, this will cause an imbalance.
When some backend ECS instances enables TCP Keepalive and others do not, the connections will accumulate on the ECS instances with TCP Keepalive enabled. This scenario will cause an imbalance.
- Check if the weight values of the backend ECS instances are the same.
- Check if the health check of the backend ECS instances fails or the health status is unstable in a specified period.
- Check if the health check is correctly configured with the status code.
- Check if both the WLC scheduling algorithm and session persistence are enabled. If so, change the scheduling algorithm to WRR.
12. Why each connection does not reach the bandwidth peak?
Because the SLB is deployed in cluster to provide the load balancing service, all requests are distributed evenly on the SLB system servers. Similarly, the specified bandwidth is also evenly distributed to these servers.
13. Why does the SLB compression fail?
content-typeattribute at the source site to a type supported by the SLB.
Change the Layer-7 listener to a Layer-4 listener.
14. How to query the load balancing traffic usage?
You can view the traffic consumed by the SLB instance on the Monitor page. (Click the ID of the SLB instance, and then click Monitor in the left-side navigation pane.)
15. Why I cannot modify the bandwidth by calling the API?
If the following error occurs when calling the API to modify the bandwidth, it indicates that the peak bandwidth set on the console conflicts with the value set in the API. You have to change the peak bandwidth on the console.
Code":"InvalidParameter","Message":"The specified parameter bandwidth is not valid."
16. Why is the load balancing monitoring data different from the actual billing data?
Because the measurement and granularity of these two kinds of data are different. For more information, see Differences between monitoring data and billing data.
17. What are the timeout values of each listener?
- TCP listeners: 900 seconds
- UDP listeners: 300 seconds
- HTTP listeners: 60 seconds
- HTTPS listeners: 60 seconds
18. Why does the SLB connection time out?
From the server side, the following situations may cause the connection timeout:
The IP of the SLB instance is protected
Such as the black hole triggering and traffic cleaning, as well as WAF protection.
Insufficient client ports
Lack of client ports may lead to connection failure especially in the stress test. The SLB erases the timestamp attribute of the TCP connection. Therefore, the
tw_reuseparameter does not work and the
time_waitstate connection heap causes the lack of the client ports.
Resolution: Do not enable TCP Keepalive for the clients and use the RST packet to terminate the connection not FIN.
The accept queue of the backend server is full
If the accept queue of the backend server is full, the backend server cannot sent the
SYN_ACKpacket. Therefore, the connection times out.
Resolution: Change the default value of
net.core.somaxconnto 128 by running the command
sysctl -w net.core.somaxconn=1024and then restart the applications deployed on the backend servers.
Access the Layer-4 load balancing service from the backend servers
For the Layer-4 load balancing service, the connection fails if you access the service from a backend server.
Improper RST configuration
If no data is transferred within 900 seconds after the TCP connection is established on the SLB, the system will send the RST packet to the client and the backend server to terminate the connection. If the RST configuration is not correct on the backend server, the backend server may send data to a closed connection, which leads to connection timeout.