geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Barker <mbl...@dsl.pipex.com>
Subject Re: Web Clustering : Stick Sessions with Shared Store
Date Fri, 17 Oct 2003 08:17:54 GMT
Would it be possible to have a pluggable Web Clustering layer? 
Different users may want to have different configurations depending on
their implementation.

E.g. In-memory replication (perhaps via a non-persistent message on an
HA JMS system) would work quite well on a small cluster (2-4 nodes) as
there would not be that much more network traffic and each node would
only have to hold 2-4 times as many http sessions as there are currently
associated to that node.  It would not scale up to a larger cluster
though, as amount of memory required to store the sessions and the
network traffic to replicate them would become unwieldy, therefore DB
persistence would work better in this case.

Also hybrid solutions (similar to the one below) could be created by
enabling sticky sessions (with fail-over if unavailable) and cached DB
replication.

If I was architecting a solution I know I would like to able to select
the optimal clustering solution for my configuration.

Just my 2c.

Mike.

On Thu, 2003-10-16 at 20:50, Bhagwat, Hrishikesh wrote:
> hi all,
> 
> I was going through the Architecture Notes for Web Clustering (http://wiki.codehaus.org/geronimo/Architecture/Clustering).
I do not have much experience with these things ... none the less here is an approach i did
like to suggest.
> 
> PLEASE SEE THE jpeg image (inline -text based images get distorted when seen through
different mail-clients)
> 
> All ref. below are from the doc. mentioned in the hyperlink above
> 
> *  A particular session is associated with exactly one Node (Managed Server - MS). 
> *  Any change to the session will be written to the DB by the corresponding node. However
unlike what has been mentioned in section 1.1.1, the session WILL NOT BE       POPPED OUT
OF MEMORY between two HTTP requests. It will continue to stay there (in memory) so that subsequent
requests can be serviced quickly. (The only reason to write it to the DB is that, in case
this node fails, another node can pick up the session-info from the DB.)
> * Now if this node becomes unavailable the, the ADMIN SERVER will distribute its clients
to other MSs. Each MS will thus get a subset of Clients, of the server, that just went down.
> * An MS can then query the DB and get the Session object (updated to the last activity)
for each of its newly acquired clients.
> 
> Advantages:
> 1. Does not suffer from Single Point Of Failure
> 2. Easy to implement. No broadcasting or session-duplication issues. etc. (No need for
a messaging system). 
> 3. With a little intelligence built in an MS can store away, less busy sessions to DB
and retrieve them when needed 
>     thus offering something that is near to "virtually unlimited amount of sessions (section
1.1.1.1)"
> 4. On fail over the algo to distribute the clients can be relatively simple. Probably
use round robin. Say X and Y are
>     clients for MS1(which has just failed).
>     client 'X' makes a request, the ADMIN Server can direct that to MS2 and then simply
updates its (ADMIN_SERVER's) internal Data structures 
>     to say 'X' belongs to MS2 . Then a request from 'Y' comes in ...direct it to MS3
... etc
> 5. Since no MS knows about no other MS, implementing the MS and ADMIN SERVER would be
simpler. ( I think that the concept of Primaries and Secondaries
>     is rather difficult to implement).
> 6. Does not create unnecessary Broadcast traffic (needed otherwise for Session data replication)
> 
> Disadvantages
> 1. Need to write the session to the DB for every request.
> 
> 
> Awaiting comments.
> -hb
>  <<cluster.jpeg>> 
> 
> 
-- 
Michael Barker <mblist@dsl.pipex.com>


Mime
View raw message