stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lakmal Warusawithana <lak...@wso2.com>
Subject Re: [Load Balancer] New Component Architecture Proposal - A1
Date Thu, 10 Oct 2013 07:47:19 GMT
Hi Imesh,

I think what Sanjiva saying is that, these LB stats publishers should go-to
directly to real time event processing engine(CEP), because otherwise MB
will be a bottle neck. I think we can have some abstraction layer to get
these real time stats ( LB stats, health checker starts .etc) and then pass
it to CEP. Then it is easy clean, any one can plug any event process
engine. I will update the architecture diagram to reflect that.

thanks


On Thu, Oct 10, 2013 at 9:32 AM, Imesh Gunaratne <imesh@wso2.com> wrote:

> Hi Sanjiva,
>
> Thanks for the quick feedback.
>
> That's a great thought! Yes I think I missed that functionality.
> I will add it to Stratos Load Balancer spec so that it could report all
> failed messages to CEP via a MB topic. I will also investigate and see how
> we could give an extension point which third party load balancers could
> make use of to support this feature.
>
> Many Thanks
> Imesh
>
>
> On Wed, Oct 9, 2013 at 3:53 PM, Sanjiva Weerawarana <sanjiva@wso2.com>wrote:
>
>> Imesh shouldn't there be provision for the LB to fire events to the real
>> time system too? Shouldn't be a requirement (and its pretty impossible to
>> do that with many 3rd party LBs) but our built in one should have the
>> option IMO. For example, telling info about failed messages so that the CEP
>> engine can accumulate and decide at will that the failure rate is too high
>> type scenarios?
>>
>> Sanjiva.
>>
>>
>> On Wed, Oct 9, 2013 at 12:40 PM, Imesh Gunaratne <imesh@apache.org>wrote:
>>
>>> Hi,
>>>
>>> The below diagram is a proposal for the new component architecture of
>>> Stratos Load Balancer.
>>>
>>> [image: Inline image 2]
>>>
>>> According to the proposed Stratos architecture, Stratos Load Balancer is
>>> expected to be light-weight and loosely coupled with Stratos core &
>>> underlying Apache Synapse components. As a result I thought we could
>>> extract out components and data structures which might be common to any
>>> other load balancer if we were to integrate them with Stratos.
>>>
>>> *Scope Common for All Load Balancers*
>>> - This section illustrates the major components and data structures that
>>> might be common to any load balancer which could integrate with Stratos.
>>> - We could bundle these components using a new module so that it could
>>> be used for implementing extensions for other load balancers.
>>>
>>> *Scope of Stratos Load Balancer*
>>> - Stratos Load Balancer is expected to support load balancing
>>> algorithms, sticky sessions, domain mappings and state replication. Please
>>> add if I have missed any other major features.
>>> *
>>> *
>>> *Functionality*
>>> - Cloud Controller publishes topology events to the
>>> "topology-events-topic". Event messages are sent as they actually occur.
>>> - Cloud Controller publishes complete topology to the "topology-topic".
>>> This happens periodically (time interval t1).
>>> - Load Balancer starts and receives complete topology from
>>> "topology-topic". Here the load balancer may need to initially wait for t1
>>> at start up to be operational. Here the message broker has been used for
>>> this functionality to maintain the loosely coupled nature of the load
>>> balancer.
>>> - Topology Event Message Receiver receives topology event messages and
>>> put them into a message queue.
>>> - Topology Event Message Processor takes messages from the message queue
>>> and updates the topology data structure in a thread synchronized manner.
>>> - When a request is received by the Stratos Load Balance Endpoint, the
>>> topology data structure is fetched and identified the next suitable
>>> application member according to the algorithm defined.
>>> - If an existing session is found for the incoming request, it will be
>>> delivered to a member node with the same session. Or else it will be sent
>>> to the next available member.
>>> *
>>> *
>>> *Topology Data Structure*
>>> Topology - (1:M) -> Service - (1:M) -> Cluster - (1:M) -> Member
>>>
>>> - Topology is the root element of the data structure.
>>> - A service represents a cartridge type, examples: PHP, MySQL, Tomcat,
>>> ESB, AppServer.
>>> - Each service will have a collection of clusters which may be used for
>>> tenant partitioning.
>>> - Each service cluster will have a collection of member nodes which
>>> hosts the actual application instances.
>>>
>>>
>>> Really appreciate your thoughts on this.
>>>
>>> Thanks
>>> Imesh
>>>
>>>
>>>
>>
>>
>> --
>> Sanjiva Weerawarana, Ph.D.
>> Founder, Chairman & CEO; WSO2, Inc.;  http://wso2.com/
>> email: sanjiva@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1
>> 650 265 8311
>> blog: http://sanjiva.weerawarana.org/
>>
>> Lean . Enterprise . Middleware
>>
>
>
>
> --
> *Imesh Gunaratne*
> Technical Lead
> WSO2 Inc | http://wso2.com
> T: +94 11 214 5345 | M: +94 77 374 2057
> W: http://imesh.gunaratne.org
>
> Lean . Enterprise . Middleware
>
>


-- 
Lakmal Warusawithana
Software Architect; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/

Mime
View raw message