incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [Discuss] CloudStack architecture to a loosely-coupled component oriented distributed architecture
Date Thu, 16 Aug 2012 04:53:23 GMT
On Thu, Aug 16, 2012 at 12:24 AM, Kelven Yang <kelven.yang@citrix.com> wrote:
>>The only hesitation that I have is around ease of installation />
>>configuration.  CloudStack is great at this today (one of the reasons
>>that my company gravitated to it), and I don't want to lose that
>>value.  I don't think this is a blocker to distributing the system at
>>all, but it will be a critical design and implementation detail to
>>consider.
>
> Yes, we should not sacrifice too much to lose the ease of installation,
> one of the most attractive property of CloudStack. the problem may be
> improved by having component-provisioning service in CloudStack core
> component that helps installation and auto configuration of other
> components

Agreed.  I just wanted to be sure we were thinking about it!

>>How do you see this matching up with Murali's Event notification
>>framework proposal?  It seems to me, that switching to a distributed
>>model requires a shift in his thinking on the actual event framework
>>itself.
>
> Murali's event notification assumes reliable event service requires by the
> semantics from business logic. It basically converts synchronized listener
> callback pattern into a disconnected implementation fashion.
>
> The messaging event I mentioned in the proposal has more semantics towards
> signaling process, it does not have a strong semantics to require a
> reliable event notification mechanism.
>

I think I follow you, but my point is that I like Murali's proposal
quite a bit.  Except in this context it needs to change to account for
the proposed distribution of processes that may contain potential
event sources and listeners.  Isn't this an opportunity to use a
common messaging approach, expecting syntactic differences between the
use cases?  I think the goals of the two proposals are complementary.
Elements of the proposed implementation approaches are what need to be
adjusted.

>
>>Over time, and depending on the implementation details, we may also
>>find a need for a distributed locking mechanism.
>
> This is why I mentioned about ZooKeeper. Yes, we need such service
>
> Kelven
>
>
>
>
> On 8/15/12 5:25 PM, "Chip Childers" <chip.childers@sungard.com> wrote:
>
>>On Wed, Aug 15, 2012 at 2:04 AM, Kelven Yang <kelven.yang@citrix.com>
>>wrote:
>>> I know everyone is recently busy and excited for the first Apache
>>>release
>>> of CloudStack, hopefully we still have some bandwidth for discussions
>>> about architecture fine-tunes, here is one for discussion.
>>>
>>> Conceptually, current CloudStack works very much like an JaveEE
>>> application server container, given the scale of all our current cloud
>>> deployments with CloudStack, I think CloudStack has done a great job.
>>>
>>> Running as an application server container, it brings us a lot of
>>>benefits
>>> like easy to deploy, efficient resource utilization, etc, but in the
>>>mean
>>> time, as modules inside a container are too easy to be involved tightly,
>>> over time, as we add more and more features, the complexity of overall
>>> system increases dramatically. Moving forward, it makes a lot of sense
>>>to
>>> reshape CloudStack from a module container to be a component oriented
>>> distributed platform.
>>
>>+1 - I completely agree with the idea of evolving to a more
>>distributed architecture for the system.
>>
>>Another plus to making it more distributed (and the devil is in the
>>details of the IPC mechanisms) is that third party developers would be
>>able to build plugins that may not be acceptable within the project
>>itself.  Obviously, I'd love if we keep everything in the ASF
>>codebase...  but it does open up opportunity for a larger ecosystem.
>>
>>The only hesitation that I have is around ease of installation /
>>configuration.  CloudStack is great at this today (one of the reasons
>>that my company gravitated to it), and I don't want to lose that
>>value.  I don't think this is a blocker to distributing the system at
>>all, but it will be a critical design and implementation detail to
>>consider.
>>
>>> Component
>>> Component is an independent deployment unit in a distributed
>>> environment(i.e., CloudStack), it usually runs as a separated process,
>>>can
>>> be independently scaled and has independent communication endpoint. It
>>> should have simple bindings to the distributed environment instead of
>>> requiring a complex container, to communicate with other components in
>>>the
>>> system, it should use bi-directional principal for loose-coupling and
>>> service-oriented, which is, using light-weight messaging event
>>> notification in one direction and service-oriented interaction at
>>>another
>>> direction.
>>>
>>> Module
>>> Module is a logic software unit that encapsulates software functions
>>>with
>>> well defined programming interface, a component contains one or more
>>> software modules
>>>
>>> Component Service
>>> Software service that is provided at component level, usually in shape
>>>of
>>> web service or REST-ful service
>>>
>>> Messaging
>>> A process for components to notify each other by exchanging messaging
>>> events
>>>
>>> Messaging event
>>> A package of information that is uni-casted or broadcasted to the
>>> destination component(s)
>>
>>How do you see this matching up with Murali's Event notification
>>framework proposal?  It seems to me, that switching to a distributed
>>model requires a shift in his thinking on the actual event framework
>>itself.
>>
>>> Service discovery
>>> A process for component to discover services and endpoint bindings
>>>within
>>> the environment, it could be either through a directory service provided
>>> at infrastructure level or through auto-discovery
>>>
>>> Under component oriented principal, at high level CloudStack core can be
>>> fine-tuned to a number of (not limited to) components
>>>
>>> API component
>>> Implements CloudStack API, it also initiates logic orchestration flows
>>> (i.e., deploy a VM) which will be notified and picked up in
>>>Orchestration
>>> engine component
>>>
>>> Orchestration Engine component
>>> This components is the heart to drive all async-flows currently active
>>>in
>>> the system, it orchestrates high-level flow through messaging among
>>> networking/storage/compute components.
>>>
>>> Data service component
>>> This components provides the data service for objects within the Cloud.
>>>
>>> Networking component
>>> A component to implement networking provisioning
>>>
>>> Storage Component
>>> A component to implement storage provisioning
>>>
>>> Compute Component
>>> A component to implement hypervisor VM provisioning
>>>
>>> Fabric Monitoring Component
>>> A component dedicated for monitoring on fabric resources, for example,
>>> monitoring of hypervisor host status
>>>
>>> Fabric Admin Component
>>> A component that implements fabric resource administration.
>>>
>>> Service Framework Component (module?)
>>> A component(or a module inside Orchestration Engine?) to provide service
>>> to launch component service in a VM and auto-scale the component
>>>service.
>>>
>>> At middleware level, we will need a messaging event delivery platform
>>>and
>>> middleware level synchronization system, possible candidates could be
>>> Redis and Apache ZooKeeper.
>>>
>>
>>Over time, and depending on the implementation details, we may also
>>find a need for a distributed locking mechanism.  Some resources that
>>are being orchestrated have limits to the number of concurrent
>>connections / tasks / whatever.  That's a logical resource that needs
>>it's consumption / use tracked at runtime.  Example: the VMware API
>>has a concurrent connection limit, and several task type are limited
>>in the total number per host or per cluster.  I've learned the hard
>>way that trusting Virtual Center to deal with that contention is a
>>risky design decision.  I'm sure there are plenty of other similar
>>situations.
>>
>>-chip
>
>

Mime
View raw message