Web Clustering : Stick Sessions with Shared Store

["Bhagwat, Hrishikesh" <hb...@visa.com>]

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>> 

Re: Web Clustering : Stick Sessions with Shared Store

[Jules Gosnell <ju...@coredevelopers.net>]

this sort of flexibility is high on the list

Jules



Michael Barker wrote:

>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>> 
>>
>>
>>    
>>


-- 
/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 **********************************/

Re: Web Clustering : Stick Sessions with Shared Store

[Michael Barker <mb...@dsl.pipex.com>]

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 <mb...@dsl.pipex.com>