stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Imesh Gunaratne <>
Subject Re: [Load Balancer] New Component Architecture Proposal - A1
Date Thu, 10 Oct 2013 06:40:18 GMT
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

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.



On Thu, Oct 10, 2013 at 11:37 AM, Kishanthan Thangarajah <> wrote:

> Hi Imesh,
> On Wed, Oct 9, 2013 at 12:40 PM, Imesh Gunaratne <> 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

View raw message