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:56:57 GMT
lichtner wrote:

>I would pick one type of clustering at a time, solve that problem, roll it
>out, and then move on to the next one. And I would specifically address
>each type of clustering requirement separately (e.g. http and entity
>beans) because the best solution is different in each case.
>  
>
check out my 'Clustering Overview - 10.000 feet...' thread posted a 
couple of hours ago - this is exactly what I have done :-)

Jules

>On Fri, 27 Jan 2006, Jules Gosnell wrote:
>
>  
>
>>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.
>> **********************************/
>>
>>
>>    
>>


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