geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <Alex.Blew...@ioshq.com>
Subject Re: Web Clustering
Date Fri, 15 Aug 2003 09:19:20 GMT
> 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.

The difference between 'shared store' and 'replicated store' is that 
the latter doesn't scale as well as you add more nodes to the system. 
If I have 1 node and 1 db, then it makes no difference, but if I have 
20 nodes and 1 db then a replicated store is going to generate 20x as 
much traffic as the db variant.

Usually the DB is on two machines (and clustered) so there isn't a SPOF.

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

(or loading it). There's a tradeoff between having the SPOF and 
replication, for sure.

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

Don't understand why replication allows this specifically. Do you mean 
that there's no need for a DB server to hold the store data? If so, I 
agree with you -- but in almost all situations there will be a DB that 
can be piggy-backed for this.

> (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)??

Yes, the one node does become a SPOF for that client. This may not be 
acceptable (but it may be).

> (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 ?).

It still had the SPOF concept, but instead of replicating the session 
data it merely proxied to the session store on the remote server.

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

I think I like enough of the various possibilities to make it 
worthwhile to abstract an interface to allow this to happen in several 
ways. So, you could (say) start the DB-Session-Store or the 
Affinity-Store or the Replicated-Store depending on your deployment.

For a developer, for example, I'd probably go with the 
Affinity-Store/Replicated-Store on one machine. For multiple nodes, it 
might be easier to use the Replicated/DB-Stores, but IMHO the 
Replicated one may give a lot of headaches to implement :-)

One thing that probably is worth stating explicitly is that when you're 
using various stores, it may not be necessary to load the store in its 
entierity each time; just proxy through the 
session.getAttribute("thing") to the underlying store. The store may 
then choose to load the session as a whole, or may choose to only load 
attribute 'thing'.

It might also be worth doing a further abstracted layer to provide a 
generic 'replicated Map' which the Session then uses. Might come in 
handy for other things, who knows ...

Alex.


Mime
View raw message