There are several load balancing methods provided by the LoadMaster, which are known as "Scheduling Methods" or “algorithms”. These are described in the sections below.

Round Robin

With this method, incoming requests are distributed sequentially across the server farm (cluster), that is, the available servers.

If this method is selected, all the servers assigned to a Virtual Service should have the similar resource capacity and host identical applications. Choose round robin if all servers have the same or similar performance and are running the same load. Subject to this precondition, the round robin system is a simple and effective method of distribution.

However, if the servers have different capacities, the use of the round robin system can mean that a less powerful server receives the next inquiry even though it has not yet been able to process the current one. This could cause a weaker server to become overloaded.

Weighted Round Robin

This method balances out the weakness of the simple round robin: incoming requests are distributed across the cluster in a sequential manner, while taking account of a static “weighting” that can be pre-assigned per server.

The administrator simply defines the capacities of the servers available by weighting the servers. The most efficient server, A for example, is given the weighting 100, whilst a much less powerful server (B) is weighted at 50. This means that Server A would always receive two consecutive requests before Server B receives its first one, and so on.

Least Connection

Both round robin methods do not take into account that the system does not recognize how many connections are maintained over a given time. It could therefore happen that Server B is overloaded, although it receives fewer connections than Server A, because the users of this server maintain their connections longer. This means that the connections, and thus the load for the server, accumulate.

This potential problem can be avoided with the "least connections" method: requests are distributed on the basis of the connections that every server is currently maintaining. The server in the cluster with the least number of active connections automatically receives the next request. Basically, the same principle applies here as for the simple round robin: the servers related to a Virtual Service should ideally have the similar resource capacities.

Please note that in configurations with low traffic rates, the traffic will not balance out and the first server will be preferred. This is because if all the servers are equal, then the first server is preferred. Until the traffic reaches a level where the first server continually has active traffic, the first server will always be selected.

Least Connection Slow Start Time

For both the Least Connection and the Weighted Least Connection scheduling methods, when a Real Server is initially brought online, a period of time can be configured where the number of connections is initially restricted and gradually increased. This provides a ‘ramp-up time’ for a Real Server to ensure that it is not overloaded by a flood of connections upon startup.

This value is configured in the L7 configuration screen.

Weighted Least Connection

If the servers have different resource capacities the “weighted least connection” method is more applicable: The number of active connections combined with the various weights defined by the administrator generally provides a very balanced utilization of the servers, as it employs the advantages of both worlds.

This is, in general, a very fair distribution method, as it uses the ratio of the number of connections and the weight of a server. The server in the cluster with the lowest ratio automatically receives the next request.

Please note that the caveat for Least Connections regarding low traffic rates applies here as well.

Agent-Based Adaptive Balancing

The “resource-based (adaptive)” scheduling method periodically checks every Real Server in a Virtual Service for an integer value that describes the availability status of the Real Server in more detail than a health check alone. This allows the LoadMaster to apply more complex logic when making load balancing decisions.

For this method to work, each Real Server in a Virtual Service must populate a simple ASCII text file with an integer value that indicates the level of availability of the Real Server. For example, 0 indicates an idle server, while 100 indicates a fully loaded server. The LoadMaster retrieves this file on a regular interval from the Real Server using a HTTP GET request for the text file containing the integer.

One of the advantages of this method that makes it powerful is that the LoadMaster takes specific actions in response to specific return codes. For example:

  • When the load reported from the Real Servers is above 0, the scheduling algorithm calculates a weighting ratio out of the collected load values and distributes the connections according to it. So, if excessive overloading of a server occurs, the weighting is readjusted transparently by the system. This is similar to the weighted round robin method, where a more even distribution is achieved by assigning different weights to the servers available.

  • When the load values as reported by the servers are 0 (or the LoadMaster fails to GET an integer value from the server for whatever reason), the LoadMaster cannot build a representative sample load distribution to modify server weight. In this case, the LoadMaster switches temporarily to the round robin selection method. Once the Real Servers begin returning larger load values to build a representative traffic sample, the LoadMaster switches back to the adaptive method.

It is up to the administrator to configure the Real Server with some method of determining a load value and placing it into a text file for the LoadMaster to retrieve. Many customers use an ‘adaptive agent script’ that runs on the server specifically for this purpose.

For complete information on the integer protocol used to communicate Real Server availability status to the LoadMaster, in addition to sample adaptive agent scripts for both Linux and Windows systems, refer to the Writing a Resource Based Adaptive Server Agent Technical Note.

The LoadMaster contains adaptive load balancing technology which can be used with a Software Defined Networking (SDN) controller. In traditional networks, there is no end-to-end visibility of network paths and applications are not always routed optimally. The LoadMaster, integrated with an SDN Controller solution, solves this problem by making the critical flow pattern data available.

The LoadMaster pulls the Layer 2/Layer 3 information from the switches in the network using the Controller. The LoadMaster combines the Layer 2/3 information with the Layer 4/7 information to make more optimized traffic distribution decisions. The LoadMaster can be used to provide end-to-end visibility of network paths for optimal routing of applications across the server and switching infrastructure.

The Progress Kemp SDN solution provides greater efficiency by enabling:

  • Application visibility to the network
  • Network data to be pulled by the Application Delivery Controller (ADC)
  • Adaptive load balancing

A Virtual Service which is using an adaptive scheduling method can be viewed as a control system. The intent is to achieve an evenly distributed load over the Real Servers and the controller calculates an error value from this (that describes the deviation from the desired even distribution). It also calculates a set of control values (Real Server weights) that are fed back into the system in a way to decrease the error value.

For more information on SDN adaptive load balancing, refer to the SDN Adaptive Load Balancing Feature Description.

Resource-based (SDN Adaptive)

The LoadMaster contains adaptive load balancing technology which can be used with a Software Defined Networking (SDN) controller. In traditional networks, there is no end-to-end visibility of network paths and applications are not always routed optimally. The LoadMaster, integrated with an SDN Controller solution, solves this problem by making the critical flow pattern data available.

The LoadMaster pulls the Layer 2/Layer 3 information from the switches in the network using the Controller. The LoadMaster combines the Layer 2/3 information with the Layer 4/7 information to make more optimized traffic distribution decisions. The LoadMaster can be used to provide end-to-end visibility of network paths for optimal routing of applications across the server and switching infrastructure.

The Progress Kemp SDN solution provides greater efficiency by enabling:

  • Application visibility to the network
  • Network data to be pulled by the Application Delivery Controller (ADC)
  • Adaptive load balancing

A Virtual Service which is using an adaptive scheduling method can be viewed as a control system. The intent is to achieve an evenly distributed load over the Real Servers and the controller calculates an error value from this (that describes the deviation from the desired even distribution). It also calculates a set of control values (Real Server weights) that are fed back into the system in a way to decrease the error value.

For more information on SDN adaptive load balancing, refer to the SDN Adaptive Load Balancing Feature Description.

Fixed Weighted

The highest weight Real Server is only used when other Real Server(s) are given lower weight values. However, if the highest weighted server fails, the Real Server with the next highest priority number will be available to serve clients. The weight for each Real Server should be assigned based on the priority among the Real Server(s). If multiple Real Servers share the same highest weight, connections are forwarded to the first highest-weighted, available Real Server.

Weighted Response Time

The traffic is scheduled using the weighted round robin method. The weights used by the weighted round robin method are calculated using the response times from health check requests.

Each health check request is timed to see how long it takes to respond. Please note that is assumed that the speed of the health check depends on how slow the machine is which may not always be the case.

The total response times of all the Real Servers on the Virtual Service are added together, from which the weight of the individual Real Server is calculated.

The weights are recalculated approximately every fifteen seconds.

Source IP Hash

When using the source IP hash scheduling method with Layer 4 (L4) Virtual Services, LoadMaster uses a prepopulated hash table to determine how client traffic is distributed across Real Servers.

For L4 source IP hash scheduling:

  • LoadMaster uses a fixed hash table containing 4096 destination slots.
  • Each Real Server is assigned a number of slots based on its configured Server weight.
  • The weights of all Real Servers associated with the Virtual Service are tallied together to determine how the 4096 slots are distributed.

This prepopulation directly affects how source IP addresses are mapped to Real Servers.

By default, each Real Server is assigned a weight of 1000.

When multiple Real Servers are configured using the default weight, the total combined weight may not evenly divide into 4096.

In such cases, LoadMaster allocates slots sequentially based on Server weight until all 4096 slots are assigned. Any remaining slots are assigned starting again from the first Real Server.

As a result, some Real Servers particularly those added later may receive significantly fewer connections or no connections at all.

Example 1: Four Real Servers, weight 1000 each

  • rs1: 1000 slots
  • rs2: 1000 slots
  • rs3: 1000 slots
  • rs4: 1000 slots
  • rs1: remaining 96 slots

Example 2: Five Real Servers, weight 1000 each

  • rs1: 1000 slots
  • rs2: 1000 slots
  • rs3: 1000 slots
  • rs4: 1000 slots
  • rs5: 96 slots

In the second example, the fifth Real Server receives a very small share of the hash table, which can lead to minimal or no traffic being forwarded to that Server.

When using source IP hash scheduling, ensure that the sum of all Real Server weights is a factor of 4096.

Users should adjust Real Server weights rather than relying on the default value of 1000 based on the number of configured Servers. This ensures an even distribution of hash slots and prevents traffic imbalance.