geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <>
Subject Distribution and start/stop of clustered deployments
Date Mon, 12 Nov 2007 13:37:26 GMT

I have just checked in support for distribution of configurations to  
clusters and also management, i.e. start/stop, of such clustered  

I will try to explain how everything hangs together so that people  
can jump in, provide feedback, request enhancements etc.

There is now a secondary configuration store:
which is a configuration store, which is aware of the cluster members  
statically configured by users (more on this later). Its  
responsibilities are:
* (un)installation of configurations on cluster members; and
* creation of "master" configurations defining GBeans able to remote  
start and stop a given configuration on a specific cluster member.

Here is what happens when a configuration, e.g. groupId/artifactId/ 
2.0/car, is distributed to this store:
1. The usual configuration processing is executed. This results into  
a backed configuration, i.e. with its associated GBeans, ready to be  
installed by the clustered store.
2. The clustered store uploads the backed configuration to the  
registered cluster members, which subsequently locally install them.  
If the "remote" installation fails for one of the members, then the  
clustered store removes the configuration from all the members having  
successfully installed it so far.
3. The clustered store installs the configuration locally.
4. The clustered store creates from scratch a master configuration,  
e.g. groupId/artifactId_G_MASTER/2.0/car. This master configuration  
is made of GBeans, one for each member, which can remote start or  
stop the configuration on a given member: when the master  
configuration starts, its GBeans start, which in turn remote start  
the configuration on a given member. In order to be able to start the  
master configuration without all the members up, these GBeans "fail"  
silently when a remote start fails. However, as these GBeans expose  
startConfiguration and stopConfiguration managed operations, it is  
pretty easy to remote start a configuration on a given member later  
via JMX. As expected, when the master configuration is stopped, its  
GBeans stop, which in turn remote stop the configurations.

The clustered store relies on the static configuration of cluster  
members. This static configuration MUST be done within  
org.apache.geronimo.configs/clustering//car as nodes must be  
registered before the start of any master configurations. Indeed,  
master configurations are injected with this static cluster  
configuration to retrieve the necessary JMX connection info to  
connect and cluster members and remote start/stop configurations.

At step 3. of the above deployment process, I wrote that the  
configuration is locally installed, i.e. into the clustered  
configuration store. At this stage, this is pretty much useless;  
however, I believe that keeping a carbon-copy of the configuration in  
the master repository may become quite handy. For instance, within  
the master configuration, we could add a GBean able to upload on  
demand this configuration to a given member. This way, when you add a  
new member to an existing clustered deployment, you simply need to  
add a new GBean to remote start/stop the configuration on this new  
member and upload the configuration to this new member via the  
utility GBean.

Hope the above is clear enough.

I will comment the org.apache.geronimo.configs/clustering//car  
deployment plan as there are new GBeans declarations not too obvious  
to understand without reading the code.

Following this, I will move to the remote start/stop of Geronimo  
instances from a single Geronimo server. This should provide a set of  
administration GBeans admin console people may want to leverage to  
improve the remote management of Geronimo instances. These GBeans  
will talk to GShell instances and send arbitrary groovy scripts for  
execution within GShells.

Meanwhile, if people are interested by working on the clustering of  
Tomcat or OpenEJB via WADI, then please reply as I am keen and happy  
to provide help. One of those two new features will be the next stuff  
I will work on after completion of the above management enhancement.


View raw message