|Re: Clustering [message #907201 is a reply to message #905642]
||Mon, 03 September 2012 14:03
|| Gunnar Wagenknecht
Registered: July 2009
Location: San Francisco ✈ Germany
Am 30.08.2012 21:58, schrieb Stefano Visconti:|
> Is it possible to specify clustering policies like:
> 1. service/application X needs to run on all nodes
> 2. service/application X needs to run at least on one node
> 3. service/application X needs to run at most on one node
You can "tag" nodes and then assign "roles" to nodes based on "tag" (or
other properties like location, etc.).
A "role" is something that triggers a specific action on the node.
Currently, a role can start a bundle or an OSGi application (OSGi
Out of the box, Gyrex uses the following tags:
* "webserver" -> activates Jetty on all nodes with that tag
* "worker" -> activates Worker engine on all nodes with that tag
* "scheduler" -> activates Schedule application on all nodes with that tag
In order to limit the running applications to "one node only" we use an
exclusive ZooKeeper lock within the application. For example, the
Scheduler application is activated on all nodes but only one node holds
the Scheduler lock. This node will start the actual Quartz scheduler.
All other "scheduler" nodes just wait for the lock. If the node dies,
ZooKeeper will ensure the lock is transitioned to another node.
However, this logic has not been generalized yet but it sounds like a
valid feature request for roles. I've opened bug 388686 to track this.
> In addition, it would be a very good thing to have an embedded HTTP load balancer that redirects requests properly according to the available nodes
For one of our production environments we've written a service that
monitors web nodes and (de-/)registers node with an external load
balancer. It's a small service easy to implement.
But I agree, Jetty already offers a load-balancing servlet and it should
be easy to provide an extended version which discovers nodes based on
ZooKeeper. Filed bug 388688.
Powered by FUDForum
. Page generated in 0.02200 seconds