Session in http unde LVS
http://lists.community.tummy.com/pipermail/linux-ha-dev/2001-December/002993.html
引用
2. I can set up a separate URL for session based apps that sends all requests
to a heatbeat duplicated session manager on the first tier using
Apache/webapps/Tomcat to load balance to the next tier down. The load
balancing in webapps/mod_jk assures that the session always returns to the
same machine the the cluster. This solution increases the complexity of the
cluster and it's management.. If the load grows too much I can always
esatblish another set of session managers. I don't have to go hammer my
developers to comply with yet another set of demands out of systems. It's
hard enough to get compliance on logging and testing....
LVS: Cluster friendly versions of applications that need to maintain state
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.cluster_friendly_applications.html
引用
*
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.
*
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.
*
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.
*
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 save memory on the balancer. Note, that unlike with a dedicated session server, you do not create a single point of failure with this method.