stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nirmal Fernando <>
Subject Re: proposed architectural changes to Stratos
Date Fri, 11 Oct 2013 04:53:16 GMT
+1 for the new design.

A question:

How can we handle multiple load balancer scenario where one load balancer
would not interested in all the clusters but a set of selected ones? I
suggest we go for a hierarchical topic concept, instead of one single
topology topic.

On Mon, Oct 7, 2013 at 7:33 AM, Sanjiva Weerawarana <>wrote:

> In a recent F2F meeting with Luca Martini and team from Cisco, some of us
> discussed several architectural changes that will significantly improve
> Stratos' capabilities and flexibility. The main driving forces behind the
> proposed changes are:
>    - make the overall architecture more resilient and pluggable by using
>    a message bus as the core communication system
>    - integrate both real-time and rule-based decision making into the
>    decision making architecture
>    - support both HTTP and non-HTTP traffic in an equal manner for load
>    balancing and elastic scaling purposes
>    - make the architecture support any LB, including hardware ones
> The following slightly complex picture attempts to explain the proposed
> changes:
> [image: Inline image 1]
> Let me try to explain a bit more in detail the runtime view as that'll
> show the changes:
>    - Traffic comes in thru any load balancer (e.g. HAProxy for non-HTTP
>    traffic and our LB for HTTP traffic). LB routes based on its configuration
>    which is periodically updated by the Cloud Controller via topology update
>    messages.
> IMO we should send topology messages periodically (even there's no
change), so that LB can get the current status of the system, even after a

>    - LB also fires status events into the message bus, and possibly
>    directly into the real-time event processor.
>    - The event processing engine does temporal (i.e. time based) queries
>    to analyze all the event streams that are being sent to it and send
>    summarized info to the Autoscaler. Basically the event processing engine is
>    an event aggregator/accumulator .. it takes lots of events and produces
>    messages that the autoscaler uses to make elasticity decisions in a more
>    granular fashion.
> I'd like to work on this task and will send a design over after thinking a

>    -
>    - The Autoscaler runs a rule engine to make auto scaling decisions
>    based on all the messages it has received. (Not different from now except
>    for the introduction of a rule engine.) The output of the rule engine runs
>    are a message to the Cloud Controller.
>    - The Cloud Controller sends instructions via jClouds to some IaaS to
>    do something. It also listens to messages from instances and updates the
>    routing topology periodically. Topology updates fire messages on a
>    different topic that the LBs listen to.
>    - Agents in each booted up instance can fire various events - some to
>    the message bus and some to the realtime event stream. These events range
>    from "I'm up and ready to go" to "my guy is down" etc..
>    - Another component (not shown in picture) can of course be external
>    monitoring systems like Nagios. Those can fire events into either event
>    stream as well - for example CPU load info can be pumped into the event
>    processing engine as frequently as possible and let the event processor
>    analyze over a period of time and alert the autoscaler if there's something
>    to worry about further.
> Overall its not major changes but a bunch of refactoring to make the
> system more flexible and resilient. It also removes any limits on the kinds
> of LBs or types of cartridges possible as all communication between the
> systems is thru asynchronous messaging with no assumptions about OS/Java
> versions. (The current Hazelcast approach has that limitation.)
> Lakmal was going to draw some sequence diagrams to further explain the
> runtime. Lakmal please send when you're ready.
> Lets discuss via the list and I look forward a lively f2f discussion at
> the upcoming bar camp in San Francisco.
> Sanjiva.

Best Regards,

C.S.Nirmal J. Fernando
Senior Software Engineer,
WSO2 Inc.


View raw message