> Load balancing techniques (cont'd)
2.2. Selecting the best server
There are many ways for the load balancer to distribute the
load. A common misconception is to expect it to send a request
to "the first server to respond". This practise is wrong because
if a server has any reason to reply even slightly faster, it
will unbalance the farm by getting most of the requests. A
second idea is often to send a request to "the least loaded
server". Although this is useful in environments involving very
long sessions, it is not well suited for web servers where the
load can vary by two digits factors within seconds.
For homogeneous server farms, the "roundrobin" method is most
often the best one. It uses every server in turn. If servers are
of unequal capacity, then a "weighted roundrobin" algorithm will
assign the traffic to the servers according to their configured
relative capacities.
These algorithms present a drawback : they are
non-deterministic. This means that two consecutive requests from
the same user will have a high chance of reaching two different
servers. If user contexts are stored on the application servers,
they will be lost between two consecutive requests. And when
complex session setup happens (eg: SSL key negociation), it will
have to be performed again and again at each connection. To work
around this problem, a very simple algorithm is often involved :
address hashing. To summarize it, the user's IP address is
divided by the number of servers and the result determines the
right server for this particular user. This works well as long
as the number of servers does not change and as the user's IP
address is stable, which is not always the case. In the event of
any server failure, all users are rebalanced and lose their
sessions. And the few percent of the users browsing through
proxy farms will not be able to use the application either
(usually 5-10%). This method is not always applicable though,
because for a good distribution, a high number of source IP
addresses is required. This is true on the Internet, but not
always within small companies or even ISP's
infrastructures. However, this is very efficient to avoid
recomputing SSL session keys too often.
<<<
[ 3/10 ]
>>>
