20
Copyright © 2000 - 2005 KEMP Technologies, Inc. All Rights Reserved.
2. 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.
3. 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.
4. 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.
5. Agent Based Adaptive Balancing
In addition to the methods above the LoadMaster contains an adaptive logic, which checks the state of the
servers at regular intervals and independently of the configured weighting.
For the extremely powerful “agent based adaptive balancing” method the balancer periodically checks the
system load on all the servers in the farm: Each server machine should provide a file that contains a numeric
value in the range between 0 and 100 representing the actual load on this server (0 = idle, 100 = overload).
The balancer retrieves this file by an HTTP GET operation. It is the server’s job to provide the actual load in
the ASCII file. There are no prerequisites, though, how the servers evaluate this information.
Two different strategies are applied, depending on the overall load of the server farm:
During normal operation 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. As with the weighted round robin, incorrect distribution can then be
countered by assigning different weights to the servers available.
During a period of very low traffic, however, the load values as reported by the servers will not build a
representative sample. A load distribution based on these values would result in uncontrolled, oscillating
directives. Therefore in such a situation it is more reasonable, to calculate the load distribution based on the
static weight ratio. The balancer switches to the weighted round robin method automatically when the load on
all servers falls below a limit defined by the administrator. If the load rises above the limit the balancer
switches back to the adaptive method.
(See also section O.1: API for Agent Based Adaptive Balancing)
