> Persistence
The solution to the limits above is then to use
persistence. Persistence is a way to ensure that a given user
will keep going to the same server for all his requests, where
its context is known. A common cheap solution is for the
application to send back a redirection to the local server
address using an HTTP 302 response. A major drawback is that
when the server fails, the user has no easy way to escape, and
keeps trying to reach the dead server. Just like with DNS, this
method is useful only on big sites when the address passed to
the user is guaranteed to be reachable.
A second solution is for the load balancer to learn user-server
associations, the cheapest way being to learn which user's IP
went to which server last time. This generally solves the
problem of the server farm size varying due to failures, but
does not solve the problem of users with a variable IP address.
So what's left ? From the start, we're stating that we're trying
to guarantee that a user will find his context on subsequent
requests to the same server. How is the context identified by
the server ? By a cookie. Cookies were invented exactly for that
purpose : send an information to the user which he will pass
back on future visits so that we know what to do with him. Of
course, this requires that the user supports cookies, but this
is generally the case on applications which need persistence.
If the load balancer could identify the server based on the
cookies presented by the user, it would solve mosts of the
problems. There are mainly two approaches regarding the cookies
: the load balancer can learn the session cookies assigned by
the servers, or they can insert cookie for server
identification.
1. Cookie learning
Cookie learning is the least intrusive solution. The load
balancer is configured to learn the application cookie
(eg. "JSESSIONID"). When it receives the user's request, it
checks if it contains this cookie and a known value. If this is
not the case, it will direct the request to any server,
according to the load balancing algorithm. It will then extract
the cookie value from the response and add it along with the
server's identifier to a local table. When the user comes back
again, the load balancer sees the cookie, lookups the table and
finds the server to which it forwards the request. This method,
although easily deployed, has two minor drawbacks, implied by
the learning aspect of this method :
-
The load balancer has finite memory, so it might saturate, and
the only solution to avoid this is to limit the cookie
lifetime in the table. This implies that if a user comes back
after the cookie expiration, he will be directed to a wrong
server.
-
If the load balancer dies and its backup takes over, it will
not know any association and will again direct users to wrong
servers. Of course, it will not be possible to use the load
balancers in active-active combinations either. A solution to
this is real-time session synchronization, which is difficult
to guarantee.
-
A workaround for these drawbacks is often to choose a
deterministic load balancing algorithm such as the user's
address hashing when possible. This way, should the cookie be
lost on the load balancer, at least the users who have a fixed
IP address will be kept on their server.
2. Cookie insertion
If the users support cookies, why not add another one with fixed
text ? This method, called "cookie insertion", consists in
inserting the server's identifier in a cookie added to the
response. This way, the load balancer has nothing to learn, it
will simply reuse the value presented by the user to select the
right server. This solves both problems of cookie learning :
memory limitations and load balancer takeover. However, it
requires more efforts from the load balancer, which must open
the stream an insert data. This is not easily done, especially
on ASIC-based load balancers which have very limited knowledge
of TCP and HTTP. It also requires that the user agent accepts
multiple cookies. This is not always the case on small mobile
terminals for instance, which are sometimes limited to only one
cookie. Then, several variations on this concept may be applied,
such as cookie modification, consisting in prefixing an already
existing cookie with the server's identifier. Special care
should also be taken on the load balancer regarding the
response's cacheability : front caches might store the load
balancer cookie and pass it to all users requesting the index
page for instance, which would lead to all users being directed
to the same server.
<<<
[ 4/10 ]
>>>
