Jeremy Boynes wrote:
Jules
Not sure this is the right track - I brain dumped on the wiki http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE/Clustering
--
Jeremy
Jeremy,
I agree with everything you have said (the cheque's in the post - right?), except the last bit:
"
IMNSHO these are independent of the approach used to replicate state, but should be driven by other concerns. For example, I may use partitions to determine to which nodes an application gets deployed, which obviously interacts with load-balancing in that I do not want to have requests directed to nodes where an app is not running.
However, as I hope I illustrated above, the policy for storing, replicating and locating state does not really depend on the partition structure.
"
I figure that we are talking about two different and orthogonal types of partition here.
I'm happy to call the way that nodes are linked into buddy-groups (groups of peers that store replicated state for each other) something other than 'partition', if we want to reserve that term for some sort of cluster management concept, but you do agree that these structures exist, do you not ? regardless of what they are called, otherwise you do not scale, as we have all agreed.
As for loadbalancer configuration I think this will draw upon both 'jeremy-partition' and 'jules-buddy-group' status as :
- you only want to balance requests for a webapp to nodes on which it is deployed
- you only want to fail-over requests to other nodes in the same buddy-group as the failed node
if you can do the latter you can avoid cluster-wide logic for findg and migrating sessions from remote nodes to the one receiving the request, because you can guarantee that the session is already there.
Are we getting closer ?
Jules
-- /************************************* * Jules Gosnell * Partner * Core Developers Network (Europe) * http://www.coredevelopers.net *************************************/
