A configuration can be deployed to a cluster of Geronimo servers via a single logical deployment step. Once deployed to a cluster, this configuration can then be transparently started, stopped or undeployed across all the cluster members.
Cluster members are configured on a Geronimo server, which may but is not required to be a member of the cluster. This is achieved by adding a org.apache.geronimo.farm.config.BasicNodeInfo GBean for each cluster member to the farming configuration of config.xml. This GBean looks like this:
<gbean name="org.apache.geronimo.configs/farming/2.1/car?ServiceModule=org.apache.geronimo.configs/farming/2.1/car,j2eeType=NodeInfo,name=NodeInfo2" gbeanInfo="org.apache.geronimo.farm.config.BasicNodeInfo"> <attribute name="name">NODE2</attribute> <attribute propertyEditor="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor" name="extendedJMXConnectorInfo"> <ns:javabean class="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo" xmlns:ns4="http://geronimo.apache.org/xml/ns/attributes-1.2" xmlns:ns="http://geronimo.apache.org/xml/ns/deployment/javabean-1.0" xmlns=""> <ns:property name="username">system</ns:property> <ns:property name="password">manager</ns:property> <ns:property name="protocol">rmi</ns:property> <ns:property name="host">localhost</ns:property> <ns:property name="port">1100</ns:property> <ns:property name="urlPath">JMXConnector</ns:property> <ns:property name="local">false</ns:property> </ns:javabean> </attribute> </gbean>
It defines network address (host, port, urlPath) and credentials (username and password) to be used to connect to the cluster member via JMX. Such declarations are to be included within the config.xml file, farming module of your Geronimo server.
To deploy a configuration to configured members, you simply deploy it to the MasterConfigurationStore repository defined by the farming configuration. This configuration being stopped out-of-the-box, you may have to start it the first time via this GShell command:
farming adds two new repositories to the server: MasterConfigurationStore and ClusterStore. MasterConfigurationStore is the repository you should use most of the time if not always. ClusterStore is a repository you may have to use in specific and infrequent scenarios.
deploy/distribute --targets XXX,name=MasterConfigurationStore <your module>
Following this deployment
To start, stop or undeploy configurations across a cluster, you perform the relevant deployment task against the virtual configuration. All the cluster members configured at the time of the initial deployment must be running otherwise these operations are partially executed. For instance, if three members were configured and only two of them are running when the virtual configuration is undeployed, then the configuration is removed from the ClusterStore of the two running servers. The ClusterStore of the third server still contains the configuration and this latter will have to be manually undeployed on this server.