Balancing Algorithm Selection and Weight Configuration Instance

Comparative Analysis of CLB Algorithms

Weighted Round-Robin Scheduling

• Principle
  The round-robin scheduling algorithm allocates requests to different servers in a round-robin method. Specifically, it selects server i by executing i = (i + 1) mod n for each scheduling operation. The weighted round-robin scheduling algorithm addresses the issue of varying server performance by assigning a weight to each server to represent its processing performance. Requests are allocated based on these weights and in a round-robin method. Servers with higher weights receive new connections first than those with lower weights, servers with higher weights get more connections than those with lower weights, and servers with equal weights get equal connections.
• Advantages
  The algorithm excels in simplicity and practicality. As it does not need to track the status of all current connections, it operates as a stateless scheduling mechanism.
• 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 scenarios
  Load balancing performs best when the backend processing time for each request is roughly the same. It is often used for non-persistent connection services, such as HTTP.
• User recommendations
  When users know that the backend processing time for each request is roughly the same, such as when the RS processes requests of the same or similar types, it is recommended to choose the weighted round-robin method. The weighted round-robin method is also recommended when request times differ slightly, because this implementation method has low overhead, does not require traversal, and is highly efficient.

Weighted Least-Connection Scheduling

• Principle
  In real-world scenarios, the duration for which each client request resides on a server may vary significantly. Over time, using simple round-robin or random load balancing algorithms may result in a highly uneven number of connection processes across servers, which does not achieve true load balancing. The least-connection scheduling algorithm dynamically estimates the load on a server based on the number of currently active connections. Contrary to the round-robin scheduling algorithm, the scheduler needs to keep track of the number of established connections on each server. When a request is scheduled to a server, its connection number is incremented by 1. When a connection terminates or times out, its connection number is decremented by 1. The weighted least-connection scheduling algorithm is an improvement upon the basic least-connection scheduling algorithm. It assigns different weights to servers based on their processing capabilities, allowing each server to handle a proportional number of requests according to its assigned weight.

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.

• Advantages
  This balancing algorithm is suitable for requests that require prolonged processing time, such as FTP applications.
• Disadvantages
  Due to API limitations, the least connection and session persistence features cannot be enabled at the same time.
• Applicable scenarios
  This algorithm is applicable to scenarios where the backend processing time for each request differs significantly. It is commonly used for persistent connection services.
• User recommendations
  If users need to process different requests where the backend processing time varies significantly (differing by orders of magnitude, such as 3 ms versus 3s), it is recommended to use the weighted least-connection scheduling algorithm for load balancing.

Source Address Hash Scheduling Algorithm ip_hash

• Principle
  This algorithm uses the source IP address of the request as the hash key to look up the corresponding server from a statically allocated hash table. If the server is available and not overloaded, the request is sent to that server. Otherwise, null is returned.
• Advantages
  ip_hash can achieve partial session persistence by remembering the source IP address, ensuring that requests from a particular client are consistently mapped to the same RS through the hash table. Therefore, ip_hash can be used for scheduling in scenarios where session persistence is not supported.
• User recommendations
  Perform a hash operation on the source address of the request and dispatch the request to a matching server based on the backend server's weight. This ensures that requests from the same client IP address are always dispatched to a specific server. This method is suitable for TCP protocols without the 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.

• Scenario 1
  Suppose that there are three RSs with the same configuration (CPU/memory). Since their performance is the same, the user can set the weight for each RS to 10. Assume that each RS has established 100 TCP connections with the client and a new RS is added. In this scenario, it is recommended to use the least-connection load balancing method. This configuration can quickly increase the load on the fourth RS and reduce the pressure on the other three RSs.
• Scenario 2
  Suppose that a user is new to cloud services and the website has been running for a short time with low traffic. It is recommended to purchase RSs with the same configuration, as they serve as identical access layer servers. In this scenario, the user can set the weight for each RS server to 10 and use the weighted round-robin load balancing method for traffic distribution.
• Scenario 3
  A user has five servers that are used to host a simple static website, and the computing power of the five servers is in the ratio of 9:3:3:3:1 (based on CPU and memory). In this scenario, the user can set the weight of the RSs in the ratio of 90, 30, 30, 30, and 10. Since static website access mostly involves non-persistent connection requests, the weighted round-robin load balancing method can be used to allow the CLB instance to allocate requests among the RSs according to their performance ratio.
• Scenario 4
  A user has 10 RSs that are used to handle massive web access requests, and does not want to purchase additional RSs to increase expenditure. However, a specific RS often experiences high load, causing it to restart frequently. In this scenario, it is recommended to set weights for the RSs based on their performance. Set a lower weight for an RS with a high load. Additionally, the least-connection load balancing method can be used to allocate requests to the RSs with fewer active connections, thus resolving the issue of high load on specific RSs.
• Scenario 5
  A user has three RSs that are used to handle several persistent connection requests, and the computing power of these servers is in the ratio of 3:1:1 (based on CPU and memory). In this case, the best-performing server handles more requests. The user does not want to overload this server and wants new requests to be distributed to the idle servers. In this scenario, the least-connection load balancing method can be used, and the weights of busier servers can be appropriately reduced. This allows the CLB instance to allocate requests to the RSs with fewer active connections, achieving load balancing.
• Scenario 6
  A user wants subsequent client requests to be allocated to the same server. However, using the weighted round-robin or weighted least-connection scheduling method cannot guarantee that requests from the same client will always go to the same server. To meet the requirements of specific application servers and ensure that client sessions are "sticky" or "persistent", the user can use the ip_hash load balancing method for traffic distribution in this scenario. 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 becomes unavailable).