ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [DISCUSS] Karaf clustering and ACE cloud support
Date Tue, 03 May 2011 06:58:41 GMT
Hi Marcel,

thanks for all these explanations.

I have the same vision as you: ACE is a premium solution for 
provisioning, especially provisioning Karaf (we have some Jira around 
that :)), and Karaf cluster should be performed on the Karaf side.

I'm gonna work on:
- ACE documentation (started guide, tutorials, etc)
- ACE/Karaf architecture draft to discuss about the different ways to work

Thanks again
Regards
JB

On 05/02/2011 05:19 PM, Marcel Offermans wrote:
> 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
>

Mime
View raw message