geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell E Glaue <>
Subject Re: Pulling Geronimo Configuration
Date Wed, 11 Feb 2009 17:46:44 GMT
David Jencks wrote:
> On Feb 11, 2009, at 7:41 AM, Russell E Glaue wrote:
>> David Jencks wrote:
>>> On Feb 10, 2009, at 1:52 PM, Russell E Glaue wrote:
>>>> David Jencks wrote:
>>>>> On Feb 10, 2009, at 8:09 AM, Chance Yeoman wrote:
>>>>>> Hello All,
>>>>>> I am interested in setting up geronimo installations that can pull
>>>>>> installed plugins and their dependencies exclusively from a
>>>>>> repository
>>>>>> within a master geronimo server.  I hope to eventually have an
>>>>>> automated process allowing cluster members to poll a cluster-specific
>>>>>> geronimo server repository for available, locally uninstalled
>>>>>> plugins.  My goal is to be able to more easily manage geographically
>>>>>> separated cluster members and to quickly add or reinitialize nodes.
>>>>>> I've been having trouble getting started as I receive HTTP 401
>>>>>> responses when installing remote plugins using the admin interface,
>>>>>> even with security turned off on the maven-repo URL.  I can list
>>>>>> contents of the remote server's repository, but not install plugins.
>>>>> That's pretty odd.  Can you show the urls being used?  You should be
>>>>> able to check that it's working with a browser.
>>>>>> My question is:  Is using the GeronimoAsMavenServlet even the correct
>>>>>> approach to pull-based configuration?  How have others implemented
>>>>>> configuration pulling?  Any advice would be greatly appreciated.
>>>>> If you use a geronimo server as the plugin repo then
>>>>> GeronimoAsMavenServlet is the correct approach.  However, if I were
>>>>> you
>>>>> I would give significant consideration to using nexus as the plugin
>>>>> repo.  I think you will have a much easier time integrating this
>>>>> with a
>>>>> reasonable build/qa process.  In particular, if you build the plugins
>>>>> using maven with the car-maven-plugin, you can set the distribution
>>>>> management repos to be the nexus server and have mvn deploy or mvn
>>>>> release make the plugin available to the appropriate production
>>>>> servers.
>>>> For satisfying this scenario, how does nexus compare to Archiva, or
>>>> Artifactory?
>>>> Archiva:
>>>> Artifactory:
>>> I only have experience with nexus and it's worked great for me.  I'm not
>>> thrilled with the license.  I haven't actually looked but have a strong
>>> impression that it has a lot more/better features than the older
>>> managers.
>>>>> I hope you are also aware of the plugin-based clustering/farming
>>>>> support
>>>>> that may provide the features you need for easy rollout to mutliple
>>>>> servers.  If the existing features there don't exactly match your
>>>>> needs
>>>>> please work with us to improve this.  For instance IIUC since you
>>>>> indicate your cluster members are geographically separate the current
>>>>> multicast discovery of cluster members may not work for you... however
>>>>> changing this to a hardcoded set of servers should be pretty easy.  Or
>>>>> perhaps you want a hybrid approach where a bunch of
>>>>> multicast-connected
>>>>> sub-clusters aggregate to a controller.
>>>> I think the desire is to pull down the artifacts, initiated from the
>>>> end
>>>> geronimo server. So if Geronimo starts up, it can go to the central
>>>> Maven repo
>>>> and see if it needs to pull down anything for configuration.
>>>> The plugin-based farming, from my understanding, does the opposite.
>>> Your understanding is incomplete.  With plugin based farming the actual
>>> artifacts are pulled by each cluster member from the repository.
>>>> The central
>>>> server pushes out the new artifacts to the end web servers. And
>>>> perhaps this
>>>> introduces a few possibly undesired circumstances:
>>>> 1. Centrally pushed out, all servers receive the updates at one
>>>> time, not
>>>> staggering the updates. Unless you put the servers into multiple
>>>> groups so that
>>>> each group can receive updates at different times. But that is more
>>>> administration.
>>>> 2. If a server is offline when the push-out occurs, it is out of date
>>>> when it
>>>> comes back online. Some kind of re-sync has to happen.
>>>> If the end geronimo server does a pull on start-up, then it will
>>>> always be in
>>>> sync at run time. If we know what triggers the pull, an
>>>> administrator can
>>>> program this into a distributed command (like Rio, or RHN Satellite
>>>> command) to
>>>> tell the server to sync itself.
>>> Plugin based farming does pretty much this administration step.  The
>>> admin server keeps (in a db) plugins, plugin lists, clusters and
>>> plugin-list to plugin and cluster to plugin list associations.  It
>>> listens on a multicast address.  When a cluster member starts up it
>>> starts a heartbeat ping on that multicast address.  When the admin
>>> server recognizes a new cluster member it sends it a list of all the
>>> plugins that are supposed to be installed on it.  The cluster member
>>> then installs all the missing plugins on the list.
>>> If you don't like multicast you have to figure out some other way for
>>> the cluster members to find the admin server, such as by telling it.
>>> Then when the admin server fails and you have to move it you need a way
>>> to tell all the cluster members to look elsewhere.  I know multicast is
>>> often frowned on but I couldn't think of a plausible alternative that
>>> seemed like it would actually work.  If you have any ideas I'd love to
>>> hear them.
>> Multicast is a good option to have available.
>> But we will probably have 40 Geronimo Installs, with perhaps 120+
>> Geronimo
>> instances, and distributed over separated LANS. Another option to
>> multicast
>> would be nice.
> I agree, but I haven't figured out what it should be yet.  For your use
> would you consider multicast on each LAN with hardcoded connections
> between them?

Yes, sort of. Here is what I would consider.
Simply - Say I have two LANS. I would have a master on each LAN responding to
multicast on their respective LAN.
The two masters would need a TCP connection between them for a replication.

So, in the end I would have two multicast networks, one "Geronimo Master Server"
I configure, and responding on LAN-A, and one "Geronimo Hub Server" receiving
configuration replication from the master, and responding on LAN-B.

I would consider it because the muticast solution would be able to work on
multiple LANs with only a single central server.

>> Have you considered:
>> Rio -
>> All application deployed services and Rio itself is managable using
>> JMX, with
>> notification support that includes an elegant peer-to-peer event
>> model, allowing
>> interested consumers to be notified of application and management
>> specific
>> events related to SLA enforcement, application deployment and service
>> availability.
>> Sun Jini = Apache River -
>> River could use some help to move forward. Perhaps backed by Geronimo
>> it might
>> get more interest.
> I have nothing against jini or leases but AFAIK the service discovery in
> jini relies either on multicast or on configuring the location of some
> "admin" server, which is basically what we already do.  For our purposes
> I don't see the need to pull in another entire infrastructure
> framework.  If you have more or different information I'd love to know
> more.

If Geronimo already has a "framework" (API) to utilize multicast for node
(client) identification to a central admin server, then this is fine so long as:
1. it is only used for identification purposes,
2. and we can either:
2a. utilize what I discussed above about a Master and Hub server, or be able to
2b. utilize some sort of multicast bridge between separated LANs.

I was considering Rio or Jini as only the node member identification, and not
the main communication channel. In this way, another option could be

So the solution would need to work like this.
1. A Geronimo node comes online.
2. The node makes itself known to the cluster via
3. The node discovers the central admin server
4. The node contacts the central admin server through a direct TCP connection to
receive configuration updates.
5. This works across seperated LANs

I believe the current multicast option does all these but #5.

You are right. Cluster administration is usually multicast, or hard coded.
We use multicast when we are not able to know our cluster members.
We use multicast to hard code a cluster member that will be available to talk to.

The only way around these two options is to use something like Rio.
With Rio, you should be able to centrally configure what is hard coded through
remote execution. This avoids the multicast traffic, and the pitfalls of local
hard-coded configuration.
However, Rio is a entire framework for distributed execution, which Geronimo
would have to be wrapped up inside of.
So Rio is not the most desirable when you look at it from ease of deployment for
the end user trying out Geronimo, or making a simple install work.
Rio is the most desirable when you look at it from the seasoned systems
administrator, experienced with Geronimo, attempting to manage a server farm.

So multicast is the best default option.
You say multicast is frowned upon, but it should be acceptable as long as there
is a path to a more desired solution for larger deployments.

However, it may not need emphasis, as the alternate solution will probably be
utilized by only 1% of the Geronimo community, where as the default multicast
will be the primarily accepted solution, without frowns.

And this means the alternate solution need not be part of the main Geronimo
distribution either.

We are attempting to discover a viable alternate solution.
Currently, we are looking towards Rio.
However, we will evaluate the default multicast option, and may end up using
that in addition to Rio. But we have multiple LANs.


> thanks
> david jencks
>>> If you don't have any need for dynamic plugin administration but are
>>> happy to kill, reinstall, and restart a cluster member whenever the
>>> plugins change then you could do something pretty easily with gshell to
>>> start the server and install a list of plugins on it.... you can script
>>> this very easily so you'd only be shipping a script to the cluster
>>> members.
>> Actually, the Rio project can do this very nicely, in a distributed
>> fashion.
>> You can script it to install more plugins, and execute it
>> remotely/centrally.
>> But we are more interested in a centrally managed system, which we could
>> "mirror" out the requirements.
>> -RG
>>> thanks
>>> david jencks
>>>> -RG
>>>>> thanks
>>>>> david jencks
>>>>>> Thank you,
>>>>>> Chance

View raw message