The method used to distribute incoming client requests to a server farm located behind LoadMaster is often called the load balancing “algorithm” and sometimes the load balancing “type”. LoadMaster supports a rich set of techniques ranging from simple round-robin load balancing to adaptive load balancing that responds to status information retrieved from the server farm.
The algorithm that you use in a LoadMaster service depends on the type of service or application being hosted and the performance and capacity profile of the servers behind LoadMaster that are hosting the application or service.
LoadMaster’s load balancing methods are outlined below, along with some guidance on appropriate usage scenarios.
Round-robin load balancing is the simplest and most commonly-used load balancing algorithm. Client requests are distributed to application servers in simple rotation. For example, if you have three application servers: the first client request is sent to the first application server in the list, the second client request to the second application server, the third client request to the third application server, the fourth to the first application server, and so on.Round robin load balancing is most appropriate for predictable client request streams that are being spread across a server farm whose members have relatively equal processing capabilities and available resources (such as network bandwidth and storage).
Learn about load balancing and see how you can benefit from the technology in your IT architecture.
Weighted round robin is similar to the round-robin load balancing algorithm, adding the ability to spread the incoming client requests across the server farm according to the relative capacity of each server. It is most appropriate for spreading incoming client requests across a set of servers that have varying capabilities or available resources. The administrator assigns a weight to each application server based on criteria of their choosing that indicates the relative traffic-handling capability of each server in the farm.
So, for example: if application server #1 is twice as powerful as application server #2 (and application server #3), application server #1 is provisioned with a higher weight and application server #2 and #3 get the same, lower, weight. If there are five (5) sequential client requests, the first two (2) go to application server #1, the third (3) goes to application server #2, the fourth (4) to application server #3. The fifth (5) request would then go to application server #1, and so on.
Least connection load balancing is a dynamic load balancing algorithm where client requests are distributed to the application server with the least number of active connections at the time the client request is received. In cases where application servers have similar specifications, one server may be overloaded due to longer lived connections; this algorithm takes the active connection load into consideration. This technique is most appropriate for incoming requests that have varying connection times and a set of servers that are relatively similar in terms of processing power and available resources.
Weighted least connection builds on the least connection load balancing algorithm to account for differing application server characteristics. The administrator assigns a weight to each application server based on the relative processing power and available resources of each server in the farm. The LoadMaster makes load balancing decisions based on active connections and the assigned server weights (e.g., if there are two servers with the lowest number of connections, the server with the highest weight is chosen).
Resource based (or adaptive) load balancing makes decisions based on status indicators retrieved by LoadMaster from the back-end servers. The status indicator is determined by a custom program (an “agent”) running on each server. LoadMaster queries each server regularly for this status information and then sets the dynamic weight of the real server appropriately.
In this fashion, the load balancing method is essentially performing a detailed “health check” on the real server. This method is appropriate in any situation where detailed health check information from each server is required to make load balancing decisions. For example: this method would be useful for any application where the workload is varied and detailed application performance and status is required to assess server health. This method can also be used to provide application-aware health checking for Layer 4 (UDP) services via the load balancing method.
SDN adaptive is a load balancing algorithm that combines knowledge from Layers 2, 3, 4 and 7 and input from an SDN controller to make more optimized traffic distribution decisions. This allows information about the status of the servers, the status of the applications running on them, the health of the network infrastructure, and the level of congestion on the network to all play a part in the load balancing decision making. This method is appropriate for deployments that include an SDN controller.
Fixed weighting is a load balancing algorithm where the administrator assigns a weight to each application server based on criteria of their choosing to represent the relative traffic-handling capability of each server in the server farm. The application server with the highest weight will receive all of the traffic. If the application server with the highest weight fails, all traffic will be directed to the next highest weight application server. This method is appropriate for workloads where a single server is capable of handling all expected incoming requests, with one or more “hot spare” servers available to pick up the load should the currently active server fail.
The weighted response time load balancing algorithm that uses the application server’s response time to calculate a server weight. The application server that is responding the fastest receives the next request. This algorithm is appropriate for scenarios where the application response time is the paramount concern.
The source IP hash load balancing algorithm uses the source and destination IP addresses of the client request to generate a unique hash key which is used to allocate the client to a particular server. As the key can be regenerated if the session is broken, the client request is directed to the same server it was using previously. This method is most appropriate when it’s vital that a client always return to the same server for each successive connection.
Take a quick guided tour of Kemp LoadMaster web user interface (WUI) for set-up and configuration of a Kemp load balancer.