incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kelven Yang <kelven.y...@citrix.com>
Subject Re: [Discuss] CloudStack architecture to a loosely-coupled component oriented distributed architecture
Date Tue, 21 Aug 2012 05:24:42 GMT


On 8/20/12 9:49 PM, "Kelven Yang" <kelven.yang@citrix.com> wrote:

>
>
>On 8/20/12 9:33 PM, "Murali Reddy" <Murali.Reddy@citrix.com> wrote:
>
>>On 20/08/12 11:23 PM, "Kelven Yang" <kelven.yang@citrix.com> wrote:
>>
>>>Murali,
>>>
>>>The key point is the shifting to event-driven programming model itself
>>>at
>>>orchestration layer, the underlying facility is currently not at
>>>critical
>>>path, we will need to do a messaging arbitration here so that we can
>>>plugin a suitable MQ selection in a fairly easy step. One thing I'm sure
>>>is that we won't use two separated MQ solutions in one system.
>>
>>Agree. Underlaying messaging infrastructure is not much of concern,



>>but my
>>point was we need to have message abstraction (be it for IPC, event
>>notifications) requirements so that we know what to expect from
>>middleware
>>when we need to choose.


I just started to work on this. I'm evaluating and testing out the
messaging choice (ZeroMQ/ActiveMQ) in javelin branch. Here is some of
requirements I'm considering

Event notification for orchestration signaling process
RPC over message queue

Above two use the queue facility as a unicast and multicast capable
transport, reliable delivery is not mandatory, and persistency is also not
mandatory, but responding time should be in range of orchestration needs.
I original thought to use blind-multicast to auto-scale the event
processing components, however, this approach needs assistant from a
distributed lock facility like ZooKeeper, now I'm also thinking to build
on top of a load balancing feature in the signaling process by using
multicast/unicast service provided from the messaging facility, basically,
event signaling process has a destination resolution phase before final
delivery and load balancing can be handled in the signaling phase without
a need for locking facility. (Maybe too complex and wild idea? This is
trying to reduce the setup complexity of the Cloud as a whole)

Persist queue events
This usually requires persistence and reliable queue service. Suitable for
workflow integration with external system (Murali's proposal)


>>
>>>
>>>We also need to think twice of tight-coupled listener pattern across
>>>components, if listeners from different components are implicitly
>>>required
>>>to participate application level transaction across components, it
>>>should
>>>better be done through an orchestration process.
>>>
>>>Kelven   
>>>
>
>
>
>
>>
>>IMO, I think we need to move away from listener-callback paradigm in
>>distributed environment.
>
>This is exactly what I meant.
>
>
>>Good thing is its not used much and is not
>>required for event notification framework as well. Its good if we have
>>request-response messaging pattern. I am thinking aloud, in enterprise
>>environments it can enable 3rd party components to integrate workflows in
>>orchestrations in a loosely coupled manner. For e.g. On Vm starting event
>>message, external workflow software can provision resources like IP,
>>name,
>>user creds etc provide a response which can be used to provision the Vm
>>with provided details.
>>
>
>Agree.
>
>
>>
>


Mime
View raw message