Hi,
I have just checked in support for distribution of configurations to
clusters and also management, i.e. start/stop, of such clustered
deployments.
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:
org.apache.geronimo.configs/clustering/2.1-SNAPSHOT/car?
ServiceModule=org.apache.geronimo.configs/clustering/2.1-SNAPSHOT/
car,j2eeType=ConfigurationStore,name=MasterConfigurationStore
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.
Thanks,
Gianny
