stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Imesh Gunaratne <im...@apache.org>
Subject [Load Balancer] New Component Architecture Proposal - A1
Date Wed, 09 Oct 2013 07:10:18 GMT
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

Mime
View raw message