Balancing Algorithm Selection and Weight Configuration Instance

Comparative Analysis of CLB Algorithms

Weighted Round-Robin Scheduling

• How It Works
  The round-robin scheduling algorithm dispatches requests to different servers in a round-robin manner, that is, each time the scheduling is executed i = (i + 1) mod n, the i-th server is selected. 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 servers and allocates requests to each server according to the weights and in a round-robin manner. Servers with higher weights receive connections first. Servers with higher weights handle more connections than servers with lower weights. Servers with the same weights handle the same number of connections.
• Strength
  The strengths of the algorithm are its simplicity and practicality. It does not need to record the status of all current connections, so it is a stateless scheduling.
• Disadvantages
  The weighted round-robin scheduling algorithm is relatively simple, but it is not suitable for situations where the request service time varies greatly or the time consumed by each request is inconsistent. In this case, the round-robin scheduling algorithm is likely to cause a load imbalance between servers.
• 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 the user knows that the backend time occupied by each request is basically the same, such as when it is known that RS processes requests of the same or similar types, it is recommended to choose the weighted round-robin scheduling method. When the request time difference is small, it is also recommended to 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

• How It Works
  In actual situations, the time that each client request stays on the server may vary greatly. As working hours extend, if a simple round-robin scheduling or random balancing algorithm is used, the number of connection processes on each server may vary greatly, and true load balancing is not actually achieved. The least connection scheduling is a dynamic scheduling algorithm that estimates the server load based by the number of active connections currently on the server. In contrast to the round-robin scheduling algorithm, the least connection scheduling is a dynamic scheduling algorithm that 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 connection number increases by 1; when the connection is terminated or times out, its connection number decreases by 1. The weighted least connection scheduling algorithm is based on the minimum connection scheduling algorithm. According to the different processing capabilities of the servers, different weights are assigned to each server so that it can accept service requests with corresponding weights. It is an improvement on the least connection scheduling algorithm.

1. Assume that the weight of each RS is WI, the current number of connections is CI and calculate CI/WI in turn. The RS with the smallest value is the next RS to be allocated.
2. If there are RS with the same CI/WI, these RS are scheduled using weighted round-robin scheduling.

• Strength
  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 ip_hash

• How It Works
  According to the source IP address of the request, the corresponding server is found from the statically allocated hash table as the hash key. If the server is available and not overloaded, the request is sent to the server, otherwise it returns nothing.
• Strength
  ip_hash can achieve the effect of partial session retention, remember the source IP, and make a client request always mapped to the same RS through the hash table. Therefore, ip_hash can be used for scheduling in cases that do not support session persistence.
• User Recommendation
  The source address of the request is hashed and dispatched to a matching server based on the weight of the backend server. This ensures that requests from the same client IP are always dispatched to a specific server. This method is suitable for TCP protocol without a cookie feature in CLB.

Balancing Algorithm Selection and Weight Configuration Instance

Among the new features that will be released soon in CLB, layer-7 forwarding will support the balancing method with the least connections. In order to enable the RS cluster to stably undertake business in different cases, we provide several examples of CLB selection and weight configuration for users' reference.

• Case 1
  Suppose there are 3 RSs with the same configuration (CPU/memory). Since the performance is consistent, the user can set the RS weight to 10. Assume that each RS has established 100 TCP links with the client and a new RS is added. In this case, it is recommended that users use the balancing method with the least connections. This configuration can quickly increase the load on the fourth RS and reduce the pressure on the other three RSs.
• Case 2
  If the user is using cloud services for the first time, the website has not been built for a long time, and the website load is low, it is recommended to purchase RS with the same configuration. Therefore, RS are all connect layer servers without distinction. In this scenario, users can set the RS weights to 10 and use a weighted round-robin scheduling method to distribute traffic.
• Case 3
  The user has 5 servers to host simple static website access, and the computing power ratio of the 5 servers is 9:3:3:3:1 (based on CPU and memory conversion). In this case, users can set the RS weight ratio to 90, 30, 30, 30, and 10 in sequence. Since most static website access requests are non-persistent connection requests, a weighted round-robin scheduling method can be used to allow CLB to allocate requests according to the performance ratio of RS.
• Case 4
  A user has 10 RSs to handle massive Web access requests and does not want to increase expenses by purchasing more RSs. A certain RS often restarts due to excessive load. In this case, it is recommended that users set the corresponding weights according to the performance of the RS and set a smaller weight for the RS with excessive load. In addition, you can use the least connection load balancing method to distribute requests to RSs with fewer active connections, thereby solving the problem of excessive load on a certain RS.
• Case 5
  A user has three RSs to process 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. Users do not want to overload this server and hope to allocate new requests to free servers. In this case, you can use the least connection balancing method and appropriately reduce the weight of busy servers, so that CLB can distribute requests to RSs with fewer active servers to achieve load balancing.
• Case 6
  A user hopes that subsequent client requests can be assigned to the same server. However, using weighted round-robin scheduling or weighted least connections cannot guarantee that requests from the same client are assigned to a fixed server. In order to meet the needs of the customer's specific application server and ensure that the client's session is sticky or persistent, in this case, we can use the ip_hash balancing method to distribute traffic. This method ensures that requests from the same client are always directed to the same RS. (Except when the number of servers changes or the server is unavailable)