geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <ju...@coredevelopers.net>
Subject Re: Web Clustering
Date Fri, 15 Aug 2003 08:53:59 GMT
True, Alex,

Let's number your suggestions 1,2,3 and look at them

(1) I call this one shared store. I think 'replication' is better than 
shared store for the following reasons :

- replication IS shared store, it's just the stores are in each and 
every node.

- because your store is already on-node, you save a round trip to the 
remote store with every request for a session

- replication allows your cluster to be made up of homogeneous nodes 
rather than heterogeneous ones (i.e. web servers and session servers) - 
clusters are complex enough already and a management nightmare. My aim 
is to make them easy, out-of-the box, deployments....

I shall probably end up implementing the replicated store as a separate 
Geronimo service anyway, so if you choose to deploy it seperately from 
the webcontainer you will effectively  have the  remote store that you 
are describing (this complicates deployment and logic since the load and 
functionality on/of a node now depend on it's type. There is no point in 
putting three webcontainers into a partition if they do not have a 
shared store between them and vice versa...)

(2) This is affinity/sticky sessions right ?

The one node holding the session becomes a SPoF for the client who owns 
the session. As soon as you add backing up the session off-node to the 
equation you are back at the replication (my approach) or shared store 
(1) approach. Except that you have the optimisation you describe in (3)??

(3) I'm not clear on exactly what is going on in this one :-) It looks 
like an optimisation (in the form of affinity) that you might use to 
prevent continually pulling the same unchanged session across a network 
from a shared store - right ? I will be doing exactly the same in my 
model. Mod_JK will be set up (dynamically and automagically) to route 
requests for sessions in particular bucket to ANY node in the partition 
in which the bucket resides. This is affinity at the partition level. I 
don't have to do it at the node level, since I can guarantee that the 
session is in-vm on every node in the partition. There is also, as far 
as i can tell, no way to tell Mod_JK to route to a node, but fail-over 
within a partition, at the moment. (Any mod_jk people reading this list ?).

So, actually, we are not far adrift :-) If you really like the DB idea, 
perhaps we could abstract away enough from what we are doing to allow a 
store to be a DB...


Jules

Alex Blewitt wrote:

> There are a couple of other options than the one you list:
>
> o Store all session state in a DB that's accessible by everyone (using 
> Serialization and a blob)
> o Keep the session on one machine, then forward all requests back to 
> that one machine
> o Try and forward requests to the same machine that had the session 
> last time, or set up proxy (as above) dynamically
>
> These approaches are likely to be more scaleable at the high-end than 
> at the low-end. They do depend on a fast network between the servers, 
> but in really serious server implementations I've worked on, they've 
> had dedicated fast/gigabit networking just for the server/db machines.
>
> Alex.
>


-- 
/*************************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 * http://www.coredevelopers.net
 *************************************/



Mime
View raw message