You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Imesh Gunaratne <im...@apache.org> on 2013/10/09 09:10:18 UTC
[Load Balancer] New Component Architecture Proposal - A1
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
Re: [Load Balancer] New Component Architecture Proposal - A1
Posted by Imesh Gunaratne <im...@apache.org>.
Hi Kishanthan,
Thanks for your query.
Actually there is no difference, topology data structure is the topology
itself. What happens in this design is that topology is built using the
topology event messages received via the "topology-events-topic". These
messages may sound like "Cluster Created", "Member Subscribed", "Member
Started", "Member Activated", etc. Accordingly topology will get updated.
At the same time Cloud Controller may send the complete topology to the
"topology-topic" (I will draw it in the diagram and do another revision) if
a load balancer would require to find the current state of the topology.
This may only be used once by a load balancer in its life-cycle. This
feature will be useful to build the current state of the topology if a load
balancer is connected to an existing Stratos environment or if one was
restarted.
The reason for not directly using the complete topology is that, comparing
two versions of topology might be costly to identify its changes/events
compared to this approach.
WDYT?
Thanks
Imesh
On Thu, Oct 10, 2013 at 11:37 AM, Kishanthan Thangarajah <
kshanth2101@gmail.com> wrote:
> Hi Imesh,
>
>
> On Wed, Oct 9, 2013 at 12:40 PM, Imesh Gunaratne <im...@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.
>>
>
> May be I'm missing some information here. So the below question.
>
> What is the difference(main) between the info gathered from topology data
> structure and the complete topology info form "topology-topic"?
>
> The reason I ask is that I can see two places that the load-balancer gets
> the info of a topology. One is from the topology-topic and the other one
> form the data structure.
>
> Thanks,
> Kishanthan.
>
> - 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
>>
>>
>>
>
Re: [Load Balancer] New Component Architecture Proposal - A1
Posted by Kishanthan Thangarajah <ks...@gmail.com>.
Hi Imesh,
On Wed, Oct 9, 2013 at 12:40 PM, Imesh Gunaratne <im...@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.
>
May be I'm missing some information here. So the below question.
What is the difference(main) between the info gathered from topology data
structure and the complete topology info form "topology-topic"?
The reason I ask is that I can see two places that the load-balancer gets
the info of a topology. One is from the topology-topic and the other one
form the data structure.
Thanks,
Kishanthan.
- 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
>
>
>
Re: [Load Balancer] New Component Architecture Proposal - A1
Posted by Imesh Gunaratne <im...@apache.org>.
Hi Lakmal,
Thanks for the clarification. Yes I also believe that it could become a
bottleneck if multiple load balancers publish real time stats on incoming
requests to the message broker.
I will design an abstract layer for this functionality and update the dev
mailing list.
Many Thanks
Imesh
On Thu, Oct 10, 2013 at 1:17 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
> 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 <im...@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 <sa...@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 <im...@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/
>
>
Re: [Load Balancer] New Component Architecture Proposal - A1
Posted by Lakmal Warusawithana <la...@wso2.com>.
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 <im...@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 <sa...@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 <im...@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/
Re: [Load Balancer] New Component Architecture Proposal - A1
Posted by Imesh Gunaratne <im...@wso2.com>.
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 <sa...@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 <im...@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
Re: [Load Balancer] New Component Architecture Proposal - A1
Posted by Sanjiva Weerawarana <sa...@wso2.com>.
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 <im...@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