Hello JB, all,
On 2 May 2011, at 16:18 , Jean-Baptiste Onofré wrote:
Ioannis Canellos and I have worked and proposed an enhancement to Apache Karaf
named Cellar.
Cellar provides clustering to Karaf by using Hazelcast.
Ioannis blogged about Cellar and also provided a demo video:
http://iocanel.blogspot.com/2011/03/karaf-clustering-using-hazelcast.html
http://www.youtube.com/watch?v=HfNrTp371LA
A very interesting blog.
As you already know, I'm working on ACE to add full Karaf support.
Yes.
ACE already provide cloud support by the usage of jclouds.
As you know, we did a workshop on that at EclipseCon / OSGi DevCon. Let me
briefly explain where we are, and what our goals are with this.
The first use case we support is to have an ACE server running in the cloud that has support for
creating new cloud nodes and bootstrapping targets onto them. A node here is a "compute
node" and a target is an OSGi framework that is managed by ACE. Currently, we run one target
on each node but in theory you could have a node bootstrap more targets (to better load the system,
or to be able to better isolate separately running OSGi applications). What we can do right now is
to have ACE create a node and bootstrap one target on it. We use jclouds and tested it with Amazon
EC-2 compute nodes. Basically in the UI you add a new target, give it a name, double click on it
and then hit the "start" button in the dialog that appears. For this to work, ACE needs
to be configured with your Amazon API key.
Currently, our node manager also supports "probes" that measure certain
performance data for a node (think CPU load, network traffic, etc..). This data is logged
and sent back to the ACE server where it is aggregated for all nodes. This performance
data can then be made available to another component (one that we're still designing),
the cluster manager.
What we envision right now is that a cluster manager can either be a generic
implementation, or an application specific one (depending on how "smart" you
want it to be when elastically scaling your application). In any case the cluster manager
accesses the performance data mentioned above and, based on that, makes decisions on
whether to expand or contract the cluster. Once the cluster manager decides to make
changes, these are propagated back to the ACE server who is then again responsible for
actually performing the changes. Naturally, a cluster manager implementation would
probably need to be replicated (possibly onto every single node) to prevent single points
of failure. And while we're discussing that, you probably want to replicate the ACE
server as well (but that's a different topic).
So we can see ACE:
- as a provisioning platform which deploy bundles/config/features (soon :)) to
a Karaf target. This target could be a single Karaf instance, or a Karaf
cluster running on Cellar. ACE is the provisioning and Cellar is the sync of
nodes states, replication of resources, etc.
Yes, that would be one scenario: ACE basically sees a single "target" here and
does not know that it is actually a cluster. The upside is that this is easy to
implement. The downside is that you cannot see the cluster from within ACE and that the
feedback you normally have about the status of a target is somewhat artificial (we'd need
to discuss how this would have to work).
- as a provisioning platform to all Karaf cluster nodes. In that case, Cellar
is the sync of nodes but ACE should be able to target all nodes and replicate
node resources.
In this scenario Cellar could indeed sync data between the nodes (without
intervention of ACE) but a cluster manager could still talk to ACE (as
mentioned above). Basically you're using Cellar here to implement replication
of specific bundles and services transparantly. ACE would still be able to give
you an overview of the current cluster configuration, and you would always be
able to see on the ACE server what the state of the cluster is.
So, I would like to have your feedback about the role of ACE in this kind of
environment.
In general I would like ACE to be responsible for the provisioning of bundles
and configuration data.
Replication of bundle or service specific data (databases, state, ...) can be
done outside of ACE.
My idea is to provide a complete enterprise OSGi platform composed by:
- Apache Archiva as a central EBR/OBR
- Apache ACE to create distribution based on resources
(bundles/config/features) provided by Archiva and provision a set of targets
- Apache Karaf as target runtime/container
- Apache Karaf Cellar (using Hazelcast) to sync Karaf nodes, etc
I would like to write some architectural draft on ACE wiki about that, so any
feedback or resources (slides) are welcome :)
I'll upload the slides for the cloud tutorial, but the description above should
already give you some idea.
If you want to start writing on the wiki, feel free to create some pages and an
outline which we can then start filling together while our ideas on this
develop.
Greetings, Marcel
