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 componentization
Date Fri, 27 Jan 2006 18:39:35 GMT
Paul McMahan wrote:

> Thanks for initiating this important conversation.  As part of the 
> clustering effort I would like to work on a new admin portlet that can 
> be used to visualize the cluster topology and do things like set 
> properties for the session managers, deploy/undeploy applications, 
> etc.  I think that making this aspect of Geronimo intuitive and easy 
> to use will be a big differentiator in our favor.  I would love to 
> hear everyone's feedback about this idea.  E.g. given our current 
> direction does this idea make sense? and what should it look like?
>
> If we are generally in favor of this idea then before proceeding I 
> would need help understanding certain fundamental concepts of our 
> approach, such as:
>
> -- Will G have explicit knowledge and control over clustering or will 
> it just be "embedded" within the applications' logic/configuration?

Geronimo should have full knowledge at the container level.

> -- Will G follow a deployment manager paradigm where a certain node is 
> in charge of managing the entire config and pushing it to the worker 
> nodes?  Or will each node be responsible for its own configuration?

I don't know if there has been any discussion of this ? I think that IBM 
donated a control panel of some sort but I haven't seen it and don't 
know if it covers deployment.

There is some stuff of relevance in the clustering overview that I just 
posted.

I would like to see a situation where you can [un]deploy to/from any 
node in the [sub]cluster. This would perform the same operation on all 
nodes in that [sub]cluster. Essentially, applications become 1->all 
replicated data.

This is a very simplistic view - as it is probably not useful to 
synchronise the lifecycle of instances of the same app around the 
cluster, otherwise you can't stop one without stopping them all (but 
maybe this is what you want?) - maybe we need a synchronised and 
non-sychronised mode...?

Of course, it may be that this conversation has already been had and 
decisions made elsewhere ? In which case, I would be interested in 
knowing the outcome so that I can update the clustering overview and add 
pointers to the necessary threads/people etc...

> -- What component(s) of G will provide an interface to the clustering 
> metadata and config?  Would it be possible to provide a single point 
> of control in G that can take as input a clustering "plan" and handle 
> the resulting deployments and node configuration?

I'm not aware that anyone has drilled down this far yet, into how a 
unified approach might work, but I suspect that we will end up with some 
form of ClusterGBean which provides the node's connection to the Cluster 
(an activecluster.Cluster), notification of other nodes leaving and 
joining, messaging primitives etc. A clustering portlet might register 
listeners with this.

> -- Is each member of a cluster assumed to be using an identical 
> configuration?

In a homogeneous cluster yes - but I think that we will have to cater 
for heterogeneous deployments. There is a nascent section in the 
overview doc about this.

> -- Will G be able to participate in heterogeneous clusters with other 
> types of app servers and/or versions of G?

I don't know whether anyone else has considered mixing (a) appservers or 
(b) geronimo versions in the same cluster - I haven't. I think (a) 
unlikely (unless you are talking about e.g. a business tier that is 
geronimo and a web-tier that is standalone Jetty/Tomcat, which I guess 
might be possible, but i suspect that both tiers would just be geronimo 
running different configurations), (b) is more possible, provided that 
the protocols used by  the different clustering components were 
compatible. With the amount of complexity already surrounding 
clustering, though, I think you would just be making your life much more 
difficult than it need be.

Hope that helps,


Jules

>
> Looking forward to your feedback and advice.
>
> Best wishes,
> Paul
>
>
>
> On 1/26/06, *David Jencks* <david_jencks@yahoo.com 
> <mailto:david_jencks@yahoo.com>> wrote:
>
>     I have some ideas about how to set up web clustering in terms of
>     geronimo modules and configurations and connections between gbeans.
>     I've talked with Jules and Jeff about this and think that they agree
>     that this is a good starting point so I'll try to describe it and
>     possibly even help implement parts of it.
>
>     There are quite a few questions I'm going to ignore, such as EJB SFSB
>     clustering and the new session module James and Dain wrote and how it
>     might relate to the web clustering stuff.  We have to start
>     somewhere.
>
>     For me, one of the most important factors is that the clustering
>     solution be pluggable, in particular that you be able to run geronimo
>     without any clustering classes.  This means that each clustering
>     solution needs to be packaged in one or more Configurations or
>     modules and that communication to the clustering module be done
>     through interfaces defined in a more core geronimo module.  It also
>     implies that the all the web containers should communicate with the
>     clustering implementation through the same interface(s).
>
>     I'm proposing that the interfaces be SessionManagerFactory and
>     SessionManager, the factory being able to provide SessionManager
>     instances.  I see the SessionManagerFactory being deployed as a GBean
>     and made available to web containers through a gbean reference.
>
>     My understanding is that for both jetty and tomcat, the web app
>     context needs an instance of a session manager.  Therefore I propose
>     giving each web app context a reference to the session manager
>     factory gbean.  At an appropriate lifecycle point it can get the
>     session manager it needs.  In Tomcat IIUC a host or engine can also
>     be where a session manager is configured.  We don't really need to
>     support that directly since we can in our deployer push a reference
>     to whatever "global" session manager may be configured down into each
>     web app context.
>
>     I see the jetty and tomcat builders installing references to
>     appropriate session manager factory gbeans.  IIUC there is a lot of
>     configuration possible for at least WADI, and we should be able to
>     support running multiple session manager configurations at once, as
>     follows:
>
>     - there can be a default session manager (say WADI) configuration,
>     and the name of its session manager factory gbean can be configured
>     in the web app builder(s).  This will be used for distributable web
>     apps that don't specify in their plan a different session manager
>     factory gbean.
>
>     - a web app plan can contain an explicit reference to a specific
>     session manager factory or an entire session manager factory/WADI
>     configuration.
>
>     - we can use a namespace driven xml-reference builder to construct a
>     wadi configuration inside a SMF reference (maybe :-)
>
>     There are a couple loose ends I can see and probably lots more I
>     can't:
>
>     -- I imagine we want to be able to have pluggable session managers
>     for non distributable apps or in the absence of clustering.  I don't
>     know if we'd want 2 "default" session manager factory gbeans
>     available, one for cluster and one not, or if there is a better
>     solution. Having 2 and having the builder decide which you get seems
>     simplest at the moment.
>
>     -- We need to be able to support the non-wadi existing tomcat-
>     specific clustering, and it is unlikely this can be coerced
>     effectively into the proposed geronimo SMF and SM interfaces.  We
>     could support this with another gbean and interface, but at the
>     moment I'm leaning towards giving the web app context either a
>     separate gbean reference to the tomcat specific clustering or
>     directly installing the tomcat solution into the web app context.
>
>     Comments?  Flames?
>
>     thanks
>     david jencks
>
>


-- 
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/


Mime
View raw message