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>>
<<attachment: cluster.jpeg>>
