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.
Imesh--On Wed, Oct 9, 2013 at 3:53 PM, Sanjiva Weerawarana <email@example.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 <firstname.lastname@example.org> wrote:
Hi,The below diagram is a proposal for the new component architecture of Stratos Load Balancer.
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 StructureTopology - (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