|
>>>>> On Tue, 26 Jun 2001 09:11:19 +0200, "Rief, Jacob"
>>>>> <Jacob.Rief@xxxxxxxxxxxx> said:
> But how about persisent connections. If such a server goes down,
> a weight of 0 still leaves some of the previous connections open.
> If such a server goes down, all the clients will have to wait until
> their persintence times out instead of reconnecting to a different
> server and rebuilding the session information.
> Jacob
There seems to be a wide spread misconception of how to handle session
data in an LVS environment. Maybe it's time to write up a short piece
of documentation how it can be done right (at least imho). Additions,
corrections, different views welcome. If this thread reaches a
conclusion, a chapter for the HOWTO might ensue.
----------------------------------------------------------------------
0. Session data on LVS done right
1. What are sessions
When an application written on top of a stateless protocol like HTTP
has a need of stateful transactions, it typically writes some data to
disk between requests and retrieves these data again on the subsequent
request. This mechanism is known as session handling. The session data
typically get written to files or databases. Each followup-request
sends some sort of token to the server so that the application can
retrieve the correct file or correct record in the database.
2. The old-fashined way to identify sessions
At the time when every webserver was a single PC, the session token
identified a filename or a record in a database and everything was OK.
When an application that relies on this mechanism is ported to a
cluster environment, it stops working unless one deteriorates the
cluster with a mechanism called persistence. Persistence is a quick
and dirty way to get the old-fashioned token to work. It's not a very
clever way though.
3. Why persistence is bad
Persistence counteracts two purposes of a cluster: easy maintainance
by taking single machines out at any time and optimized balancing
between the members of a cluster. Above that, persistence consumes
memory on the load balancers.
4. How to do it better
Recall that there is a token being sent back and forth anyway, that
identifies a filename or a database record. Extend this token to
unambiguously point to the machine where the session data were created
and install a session server on each host that delivers session data
within the cluster to any of the peers on request. From that moment
you can run your application truely distributed, you can take single
machines out for maintainance any time: you turn their weight to 0 and
wait for maybe an hour or three, depending on how long you want your
sessions to last. You get better balancing, and you safe memory on the
balancer. Note, that unlike with a dedicated session server, you do
not create a single point of failure with this method.
---------------------------------------------------------------------
I hope that helps some,
--
andreas
|
