The round-robin scheduling is the algorithm for allocating traffic to the backend server by CLB. Different results can achieved according to different round-robin scheduling methods and weight settings of the backend servers.
Weighted round robin scheduling algorithm
The weighted round-robin scheduling algorithm requests scheduling of different servers in turn in a round-robin manner. The weighted round-robin scheduling algorithm can solve the problem of different performance among servers. It uses corresponding weights to represent the processing performance of the server and allocates requests to each server according to the weight and round-robin scheduling method. The weighted round-robin scheduling algorithm is scheduled based on the number of new connections. Servers with higher weights receive connections first. The higher the weight, the higher the number of times (probability) for its round-robin scheduling. Servers with the same weight handle the same number of connections.
- Advantages: It is simple and practical. It does not need to record the status of all current connections. It is a stateless scheduling.
- Disadvantages: Relatively simple, it is easy to cause load imbalance among servers when the request service time varies greatly or the time consumed by each request is inconsistent.
- Applicable Cases: The best load situation is when each request takes roughly the same amount of time to reach the backend. Commonly used for non-persistent connection services, such as HTTP.
- User Recommendation: If you know that the time each request takes to complete the task is roughly the same and the types of requests processed by the backend servers are the same or similar, we recommend that you choose the weighted round-robin scheduling method. When the request time difference is small, it is also recommended that you use the weighted round-robin scheduling method, because this implementation method consumes little energy, does not require traversal, and is more efficient.
Weighted Least Connection Scheduling Algorithm
In actual situations, the time that a client's request service stays on the server can vary greatly. As working hours extend, using simple round-robin scheduling or random balancing algorithms, the number of connection processes on each server may vary greatly, resulting in no true load balancing.
Least connection scheduling is a dynamic scheduling algorithm. In contrast to the round-robin scheduling algorithm, it estimates the server load by the number of active connections currently on the server. The scheduler needs to record the number of connections established by each server. When a request is scheduled to a server, its number of connections increases by one; when the connection is terminated or times out, its number of connections decreases by one.
The weighted least connection scheduling is based on the least connection scheduling algorithm. It assigns different weights to each server according to the different processing capabilities of the servers so that they can accept service requests with corresponding weights. It is an improvement on the least connection scheduling algorithm.
Note:
Assume that the weight of each backend server is wi, the current number of connections is ci, and ci/wi is calculated in sequence. The backend server instance with the smallest value is used as the next allocated instance. If there are backend server instances with the same ci/wi, weighted round-robin scheduling is used.
- Advantages:This algorithm is suitable for long-time processing request services, such as FTP and other applications.
- Disadvantages: Due to API limitations, the minimum number of connections and session persistence features cannot be enabled at the same time.
- Applicable Cases: The case where the backend time taken by each request varies greatly. Commonly used in persistent connection services.
- User Recommendation: If the user needs to process different requests and the time taken by the requests to complete the backend differs greatly, such as a difference of orders of magnitude between 3ms and 3s, it is recommended to use the weighted least connection scheduling algorithm to achieve load balancing.
Source address hash scheduling algorithm
The source address hash scheduling algorithm (ip_hash) uses the hash key (Hash Key) to find the corresponding server from the statically allocated hash table according to the source IP address of the request. If the server is available and not overloaded, the request is sent to the server, otherwise it returns nothing.
- Advantages: A client's request can be mapped to the same backend server through a hash table. In cases where session persistence is not supported, ip_hash can be used to implement simple session persistence.
- User Recommendation: Perform a hash operation on the source address of the request and combine it with the weight of the backend server to dispatch the request to a matching server, so that requests from the same client IP are always dispatched to a specific server. This method is suitable for TCP protocols without cookie feature.
Balancing algorithm selection and weight configuration
In order to enable users to realize stable business handling of backend server clusters in different scenarios, the following is a case example of load balancing selection and weight configuration for your reference.
- Scenario 1:
- Assume that there are three backend servers with the same configuration (CPU/memory). Since their performance is consistent, the weights of all backend servers can be set to 10.
- Now each backend server has established 100 TCP connections with the client, and 1 new backend server has been added.
- In this scenario, it is recommended to use the least connection balancing method, which can quickly increase the load on the fourth backend server and reduce the pressure on the other three backend servers.
- Scenario 2:
- Assume that this is your first time using cloud services, and your website has been built for a short time with low website load, it is recommended that you purchase backend servers with the same configuration. At this time, the backend servers are all access layer servers without any difference.
- In this scenario, you can set the weights of all backend servers to the default value of 10, and use a weighted round-robin scheduling method to distribute traffic.
- Scenario 3:
- Assume that you have five servers for hosting simple static website access, and the computing power ratio of the five servers is 9:3:3:3:1 (based on CPU and memory conversion).
- In this scenario, you can set the backend server weight ratios to 90, 30, 30, 30, and 10 in sequence. Most static website visits are non-persistent connection requests. Therefore, a weighted round-robin scheduling method can be used to allow the CLB instance to distribute requests according to the performance ratio of the backend server.
- Scenario 4:
- Assume that you have 10 backend servers to handle a large number of Web access requests, and you do not want to purchase more backend servers to increase expenses. However, one of the backend servers often restarts due to excessive load.
- In this scenario, it is recommended to set the corresponding weights according to the performance of the backend servers, and set smaller weights for backend servers with excessive load. In addition, you can use the least connection load balancing method to distribute requests to backend servers with fewer active connections, thereby solving the problem of excessive load on a backend server.
- Scenario 5:
- Assume that you have three backend servers for processing several persistent connection requests, and the computing power ratio of these three servers is 3:1:1 (based on CPU and memory conversion).
- At this time, the server with the best performance handles more requests. You do not want to overload this server and want to assign new requests to idle servers.
- In this scenario, you can use the least connection balancing method and appropriately reduce the weight of busy servers, so that the CLB can distribute requests to backend servers with fewer active servers to achieve load balancing.
- Scenario 6:
- Assume that you want subsequent client requests to be dispatched to the same server. At this time, using weighted round-robin scheduling or weighted least connections cannot guarantee that requests from the same client are assigned to a fixed server.
- To suit the needs of a specific application server, the client's session is guaranteed to be sticky or persistent. In this scenario, you can use the ip_hash balancing method to distribute traffic, which can ensure that requests from the same client are always directed to the same backend server (except when the number of servers changes or the server is unavailable).