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
