Overall look good. How would the single node version work? Does it embed MB?
Kernel, are we using JMS as message interface or wrap it in our own interface? --Srinath On Thu, Jul 2, 2015 at 3:49 PM, Lakmal Warusawithana <[email protected]> wrote: > Hi, > > Had initial discussion with Azeez and Carbon team about $subject. Please > find the details. > > *Are we embedding MB into kernel?* > > We though of not to embed MB into kernel, rather runs it on top or > separate. Kernel APIs are expect topology and ADC topic (MB end point) for > the artifact distribution and the topology management. Will bungle light > weight MB features with products which can runs in management node to cover > requirement. But importantly kernel APIs are not depend on any specific MB, > rather only need MB end point. > > *Important of the topology topic* > > Topology topic contain cluster detail of the all members, artifacts etc. > When ever new member created (statically or dynamically) kernel will update > the topology with member details like cluster, IP, ports etc. > > With the effect of topology introduce, Load Balancers get all member > information dynamically which eliminate static member configuration. With > the load balancer extension, capable of working with ANY load balancers > without coupling to one. > > With the topology based LB support, we can achieved partition based > artifact update without major effect. e.g. Say we are having 5 nodes on a > cluster and want to update 3 node with artifact V1 and other two with > artifact V2. ADC can instruct (will explain topic based ADC next section) > second 2 nodes to take new version V2 and update the topology with relevant > artifact version, then LBs can dynamically configure to route V1 to first 3 > nodes and V2 to second 2 nodes etc. > > Topology also help to provide better solution to WKA member discovery in > current hazelcast implementation. Simply we can get all members > information for a cluster and update hazelcast member list. See same > mechanism used in Kubernetes to member discovery on hazelcast based > containers [1]. With the effect on that all members will be WKA and we > also no need to go specific implementation AWS member discovery etc. This > can be used in any cloud with out specific to a provider. Also this can > used with any clustering implementation. (not specific to hazelcast) > > [1] > https://github.com/pires/hazelcast-kubernetes-bootstrapper/blob/master/src/main/java/com/github/pires/hazelcast/HazelcastDiscoveryController.java > > *Topic based artifact synchronizer* > > This will replace hazelcast/SVN based artifact synchronizer. Instead > sending cluster messages, artifact updates are notify via pub/sub > communication which give more scalability and capable of multi region > deployment support. > > Also new artifact update should have two phases. > > 1. Upload artifact to management node > 2. Notify the members of the cluster > > Two phase model bring following benefits. > > - Artifact versioning support. > - with the versioning effect, capable of artifact rollback > - composite application artifact support - IMO individual products > should not aware of the deployment logic of the composite apps artifacts, > rather centralize ADC should handle the decompose logic and notify relevant > products to get relevant artifact update. > - Artifact update message should provide protocol and artifact end > point ( IMO by default we should support HTTP based artifact end points), > kernel will get and deploy the artifacts. > - By default HTTP based artifact server will host in the management > node, but if a cluster having larger size artifacts and frequent updates > recommended to having separate file server. But either way artifact update > APIs are not changed. > > > These are some key points, can discussed details when having the review > session. @Azeez is anything I missed? > > Welcome your thoughts :) > > PS: Also we have discussed MT model effect with containers and > microservice based product deployment. Need separate thread I guess :) > > -- > Lakmal Warusawithana > Vice President, Apache Stratos > Director - Cloud Architecture; WSO2 Inc. > Mobile : +94714289692 > Blog : http://lakmalsview.blogspot.com/ > > -- ============================ Blog: http://srinathsview.blogspot.com twitter:@srinath_perera Site: http://people.apache.org/~hemapani/ Photos: http://www.flickr.com/photos/hemapani/ Phone: 0772360902
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
