On Wed, Aug 15, 2012 at 2:04 AM, Kelven Yang <kelven.y...@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
