You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Sanjiva Weerawarana <sa...@wso2.com> on 2013/10/07 04:03:02 UTC
proposed architectural changes to Stratos
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. 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.
- 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.
Re: proposed architectural changes to Stratos
Posted by Lahiru Sandaruwan <la...@wso2.com>.
Hi all,
Please find my comments inline,
Sent from my mobile.
On Oct 9, 2013 6:50 AM, "Sanjiva Weerawarana" <sa...@wso2.com> wrote:
>
> Hi Dale,
>
> On Tue, Oct 8, 2013 at 9:37 PM, Chalfant, Dale (DTI) <
Dale.Chalfant@state.de.us> wrote:
>>
>> Team:
>>
>>
>>
>> Some things to consider for long-term roadmap:
>>
>>
>>
>> System documentation (such as system diagrams / deployment diagrams) go
into repository (ideally an ITIL configuration management database/CMDB).
This information is used along with rules to form build scripts. Certain
instances are hibernated for quick startup (higher cost than building from
scratch, but lower cost than active).
>
>
> This is an interesting next step definitely. We currently have a CMDB too
- that the manager writes to - but its fairly rudimentary yet. Right now we
are dealing with atomic service deployment only I believe. The next step is
to have a composite model that takes an entire system and deploys it as a
whole. Lakmal can you clarify what we can do in that regard right now - in
terms of inter-cartridge dependencies etc..
>
> My suggestion is to do this improvement (support for composite apps -
that's where even specs like CAMP come in) next. We had some some for CAR
(WSO2's composite application archive) format but I'm not sure what status
its in.
>
>> Metering is performed on the boxes and we balance resources based on
acceleration rather than some threshold. If a box is running 95% CPU and
has been doing so for a while, that is a good thing, not an indicator of
needing another box per se, but if the box is at 5% then quickly is
climbing (high acceleration), we would want to fire up a hibernated box and
get another in the pipeline.
>
>
> Yes +1. This is easily implementable in the proposed new architecture -
basically a CEP query which says if the rate of change of system load stays
at 5% over a few minute interval then fire up another one type query. Great
point that rate of change is more important than the actual current load.
Nice thinking indeed. Currently we use requests in-flight as an indicator
to scale up, scale down. I think we can apply same logic for this aspect as
well, which means using rate of changing average requests in-flight in
addition to current number of requests in-flight.
I would like to volunteer for auto scaling(with rules engine)
implementation.
We can use Lb statistics(requests in-flight) as well as instance load
details like CPU, memory...
Thanks.
>
> Sanjiva.
> --
> 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
Re: proposed architectural changes to Stratos
Posted by Lakmal Warusawithana <la...@wso2.com>.
Hi Dale,
We can have couple of improvement with your suggestions. Please see in-line
comments;
On Wed, Oct 9, 2013 at 6:49 AM, Sanjiva Weerawarana <sa...@wso2.com>wrote:
> Hi Dale,
>
> On Tue, Oct 8, 2013 at 9:37 PM, Chalfant, Dale (DTI) <
> Dale.Chalfant@state.de.us> wrote:
>
>> Team:****
>>
>> ** **
>>
>> Some things to consider for long-term roadmap:****
>>
>> ** **
>>
>> ****
>>
>> System documentation (such as system diagrams / deployment diagrams) go
>> into repository (ideally an ITIL configuration management database/CMDB).
>> This information is used along with rules to form build scripts. Certain
>> instances are hibernated for quick startup (higher cost than building from
>> scratch, but lower cost than active).
>>
>
> This is an interesting next step definitely. We currently have a CMDB too
> - that the manager writes to - but its fairly rudimentary yet. Right now we
> are dealing with atomic service deployment only I believe. The next step is
> to have a composite model that takes an entire system and deploys it as a
> whole. Lakmal can you clarify what we can do in that regard right now - in
> terms of inter-cartridge dependencies etc..
>
>
My suggestion is to do this improvement (support for composite apps -
> that's where even specs like CAMP come in) next. We had some some for CAR
> (WSO2's composite application archive) format but I'm not sure what status
> its in.
>
Yes, as Sanjiva said we have composite application creating in our roadmap.
We had quick looked for CAMP, but not in detail. Anyway we need to have
capability of composite application creation. May be we can used ITIL and
CMDB for that.
[image: Inline image 2]
We can include composite application engine with SM. Based on users
requirement of their application, it will regenerate/list-out required
cartridges+policies for the application. May be this will go with SM new
GUI design. If we have resources (developers) we can start this as a
parallel item and later integrate.
>
> Metering is performed on the boxes and we balance resources based on
>> acceleration rather than some threshold. If a box is running 95% CPU and
>> has been doing so for a while, that is a good thing, not an indicator of
>> needing another box per se, but if the box is at 5% then quickly is
>> climbing (high acceleration), we would want to fire up a hibernated box and
>> get another in the pipeline.
>>
>
> Yes +1. This is easily implementable in the proposed new architecture -
> basically a CEP query which says if the rate of change of system load stays
> at 5% over a few minute interval then fire up another one type query. Great
> point that rate of change is more important than the actual current load.
>
Yes, this is exact use case, and one reason of introduce new architecture.
With the cartridge heath publisher, we can get CPU load, load average,
memory usage ..etc and based on one or all of them CEP will send summarised
health message and based on that autoscalar take the decision.
Also as you said, based on policy user has selected, if application need to
switch new instance quickly and load balance, from Could controller we can
have hibernated instances and update topology based on autoscalar decision,
then load balancer can add ready-made members in very short time.
>
> Sanjiva.
> --
> 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
>
--
Lakmal Warusawithana
Software Architect; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: proposed architectural changes to Stratos
Posted by Sanjiva Weerawarana <sa...@wso2.com>.
Hi Dale,
On Tue, Oct 8, 2013 at 9:37 PM, Chalfant, Dale (DTI) <
Dale.Chalfant@state.de.us> wrote:
> Team:****
>
> ** **
>
> Some things to consider for long-term roadmap:****
>
> ** **
>
> ****
>
> System documentation (such as system diagrams / deployment diagrams) go
> into repository (ideally an ITIL configuration management database/CMDB).
> This information is used along with rules to form build scripts. Certain
> instances are hibernated for quick startup (higher cost than building from
> scratch, but lower cost than active).
>
This is an interesting next step definitely. We currently have a CMDB too -
that the manager writes to - but its fairly rudimentary yet. Right now we
are dealing with atomic service deployment only I believe. The next step is
to have a composite model that takes an entire system and deploys it as a
whole. Lakmal can you clarify what we can do in that regard right now - in
terms of inter-cartridge dependencies etc..
My suggestion is to do this improvement (support for composite apps -
that's where even specs like CAMP come in) next. We had some some for CAR
(WSO2's composite application archive) format but I'm not sure what status
its in.
Metering is performed on the boxes and we balance resources based on
> acceleration rather than some threshold. If a box is running 95% CPU and
> has been doing so for a while, that is a good thing, not an indicator of
> needing another box per se, but if the box is at 5% then quickly is
> climbing (high acceleration), we would want to fire up a hibernated box and
> get another in the pipeline.
>
Yes +1. This is easily implementable in the proposed new architecture -
basically a CEP query which says if the rate of change of system load stays
at 5% over a few minute interval then fire up another one type query. Great
point that rate of change is more important than the actual current load.
Sanjiva.
--
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
RE: proposed architectural changes to Stratos
Posted by "Chalfant, Dale (DTI)" <Da...@state.de.us>.
Team:
Some things to consider for long-term roadmap:
[cid:image001.png@01CEC41E.F4A6FB10]
System documentation (such as system diagrams / deployment diagrams) go into repository (ideally an ITIL configuration management database/CMDB). This information is used along with rules to form build scripts. Certain instances are hibernated for quick startup (higher cost than building from scratch, but lower cost than active).
Metering is performed on the boxes and we balance resources based on acceleration rather than some threshold. If a box is running 95% CPU and has been doing so for a while, that is a good thing, not an indicator of needing another box per se, but if the box is at 5% then quickly is climbing (high acceleration), we would want to fire up a hibernated box and get another in the pipeline.
From: Lakmal Warusawithana [mailto:lakmal@wso2.com]
Sent: Monday, October 07, 2013 1:18 PM
To: dev@stratos.incubator.apache.org
Subject: Re: proposed architectural changes to Stratos
Hi,
As Sanjiva mention, in this architecture will address issues that has in current Stratos. With this all major components will loosely coupled, give more extendability. All communication will used standard pub/sub. Also it is very easy to integrate with other external components.
Please find the first cut of sequence diagram that I come across.
thanks
On Mon, Oct 7, 2013 at 7:33 AM, Sanjiva Weerawarana <sa...@wso2.com>> 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:
[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. 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.
* 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.
--
Lakmal Warusawithana
Software Architect; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: proposed architectural changes to Stratos
Posted by Sanjiva Weerawarana <sa...@wso2.com>.
Actually, why do you special case the HA Proxy LB? That's like any other
3rd party LB .. so its either the built-in one or a 3rd party one + some
agent to interact with the Stratos messages.
Sanjiva.
On Thu, Oct 10, 2013 at 10:10 PM, Sanjiva Weerawarana <sa...@wso2.com>wrote:
> Looks good!
>
>
> On Thu, Oct 10, 2013 at 4:54 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
>
>> Hi folks,
>>
>> Based on several feedback, here I re-draw the Stratos Architecture
>> diagram. Please share your thoughts.
>>
>> [image: Inline image 1]
>>
>>
>> On Thu, Oct 10, 2013 at 12:34 PM, Reka Thirunavukkarasu <re...@wso2.com>wrote:
>>
>>> Hi Lakmal/Devs
>>>
>>> Would like to be a volunteer for the ADC pub/sub model and the topology
>>> handling in the Cloud controller. Will start up with a discussion for them
>>> in a separate thread.
>>>
>>> Thanks,
>>> Reka
>>>
>>>
>>> On Thu, Oct 10, 2013 at 9:08 AM, Lakmal Warusawithana <la...@wso2.com>wrote:
>>>
>>>> +1
>>>>
>>>>
>>>>
>>>> On Thu, Oct 10, 2013 at 7:36 AM, Pradeep Fernando <pr...@gmail.com>wrote:
>>>>
>>>>> Hi Lakmal/Devs,
>>>>>
>>>>> Like the new approach... Looks like the Stratos controller road map
>>>>> items are more or less unaffected. I will own the Stratos Manager RESTful
>>>>> APIs. (I have already started on this)
>>>>>
>>>>> Furthermore I will start a discussion on the Stratos new GUI as well.
>>>>> Once we all agree, we can initiate the initialization bits in parallel to
>>>>> REST API.
>>>>>
>>>>> Thanks,
>>>>> --Pradeep
>>>>> On Tue, Oct 8, 2013 at 11:17 AM, Lakmal Warusawithana <lakmal@wso2.com
>>>>> > wrote:
>>>>>
>>>>>> Hi devs,
>>>>>>
>>>>>> Shall we start looking into detail of this. Here(below) what I
>>>>>> identified individual items for implementing this. we can make a branch and
>>>>>> start working on this (some POC, then alpha ). May be we can do this as
>>>>>> 4.0.0 release, because it has major improvement of the architecture.
>>>>>> Please add/review this items. Volunteers can own these task :)
>>>>>>
>>>>>> Please share your thoughts.
>>>>>>
>>>>>> Common:
>>>>>>
>>>>>> - Component Topic Pub/Sub
>>>>>> - Health Checker
>>>>>> - Nagios
>>>>>> - define all message structures
>>>>>>
>>>>>> Cartridge Agent:
>>>>>>
>>>>>> - Generic Agent -> better if we can use Python
>>>>>> - pub/sub based DepSync
>>>>>>
>>>>>> Load Balancer:
>>>>>>
>>>>>> - LB Subscribe to topic and create endpoints
>>>>>> - test with multiple LBs
>>>>>> - Test with external LBs (like HA-Proxy)
>>>>>> - LB stat publisher
>>>>>> - Remove Autoscalar from current ELB
>>>>>>
>>>>>> Cloud Controller :
>>>>>>
>>>>>> - Move ADC to CC
>>>>>> - Support pub/sub based ADC
>>>>>> - Event aggregation
>>>>>> - Dynamic Payloads
>>>>>> - Topology handling
>>>>>>
>>>>>> Stratos Manager
>>>>>>
>>>>>> - Interface to define Cartridges
>>>>>> - REST APIs - Json
>>>>>> - New GUI/ without depending carbon framework.
>>>>>> - CLI to work with new REST APIs
>>>>>> - Policy handling
>>>>>>
>>>>>> AutoScalar :
>>>>>>
>>>>>> - New component call autoscalar
>>>>>> - Rule Engine
>>>>>> - Start with simple policy and then go to complex
>>>>>>
>>>>>> Event Process Engine:
>>>>>>
>>>>>> - New component
>>>>>> - May be we can use wso2 cep
>>>>>> - start with simple rule set and go to complex
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Oct 7, 2013 at 10:47 PM, Lakmal Warusawithana <
>>>>>> lakmal@wso2.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> As Sanjiva mention, in this architecture will address issues that
>>>>>>> has in current Stratos. With this all major components will loosely
>>>>>>> coupled, give more extendability. All communication will used standard
>>>>>>> pub/sub. Also it is very easy to integrate with other external components.
>>>>>>>
>>>>>>> Please find the first cut of sequence diagram that I come across.
>>>>>>>
>>>>>>> thanks
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Oct 7, 2013 at 7:33 AM, Sanjiva Weerawarana <
>>>>>>> sanjiva@wso2.com> 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. 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.
>>>>>>>>
>>>>>>>> - 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.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Lakmal Warusawithana
>>>>>>> Software Architect; WSO2 Inc.
>>>>>>> Mobile : +94714289692
>>>>>>> Blog : http://lakmalsview.blogspot.com/
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Lakmal Warusawithana
>>>>>> Software Architect; WSO2 Inc.
>>>>>> Mobile : +94714289692
>>>>>> Blog : http://lakmalsview.blogspot.com/
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Pradeep Fernando.
>>>>> http://pradeepfernando.blogspot.com/
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Lakmal Warusawithana
>>>> Software Architect; WSO2 Inc.
>>>> Mobile : +94714289692
>>>> Blog : http://lakmalsview.blogspot.com/
>>>>
>>>>
>>>
>>>
>>> --
>>> Reka Thirunavukkarasu
>>> Software Engineer,
>>> WSO2, Inc.:http://wso2.com,
>>> Mobile: +94776442007
>>>
>>>
>>>
>>
>>
>> --
>> Lakmal Warusawithana
>> Software Architect; WSO2 Inc.
>> Mobile : +94714289692
>> Blog : http://lakmalsview.blogspot.com/
>>
>>
>
>
> --
> 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
>
--
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
Re: proposed architectural changes to Stratos
Posted by Sanjiva Weerawarana <sa...@wso2.com>.
Looks good!
On Thu, Oct 10, 2013 at 4:54 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
> Hi folks,
>
> Based on several feedback, here I re-draw the Stratos Architecture
> diagram. Please share your thoughts.
>
> [image: Inline image 1]
>
>
> On Thu, Oct 10, 2013 at 12:34 PM, Reka Thirunavukkarasu <re...@wso2.com>wrote:
>
>> Hi Lakmal/Devs
>>
>> Would like to be a volunteer for the ADC pub/sub model and the topology
>> handling in the Cloud controller. Will start up with a discussion for them
>> in a separate thread.
>>
>> Thanks,
>> Reka
>>
>>
>> On Thu, Oct 10, 2013 at 9:08 AM, Lakmal Warusawithana <la...@wso2.com>wrote:
>>
>>> +1
>>>
>>>
>>>
>>> On Thu, Oct 10, 2013 at 7:36 AM, Pradeep Fernando <pr...@gmail.com>wrote:
>>>
>>>> Hi Lakmal/Devs,
>>>>
>>>> Like the new approach... Looks like the Stratos controller road map
>>>> items are more or less unaffected. I will own the Stratos Manager RESTful
>>>> APIs. (I have already started on this)
>>>>
>>>> Furthermore I will start a discussion on the Stratos new GUI as well.
>>>> Once we all agree, we can initiate the initialization bits in parallel to
>>>> REST API.
>>>>
>>>> Thanks,
>>>> --Pradeep
>>>> On Tue, Oct 8, 2013 at 11:17 AM, Lakmal Warusawithana <la...@wso2.com>wrote:
>>>>
>>>>> Hi devs,
>>>>>
>>>>> Shall we start looking into detail of this. Here(below) what I
>>>>> identified individual items for implementing this. we can make a branch and
>>>>> start working on this (some POC, then alpha ). May be we can do this as
>>>>> 4.0.0 release, because it has major improvement of the architecture.
>>>>> Please add/review this items. Volunteers can own these task :)
>>>>>
>>>>> Please share your thoughts.
>>>>>
>>>>> Common:
>>>>>
>>>>> - Component Topic Pub/Sub
>>>>> - Health Checker
>>>>> - Nagios
>>>>> - define all message structures
>>>>>
>>>>> Cartridge Agent:
>>>>>
>>>>> - Generic Agent -> better if we can use Python
>>>>> - pub/sub based DepSync
>>>>>
>>>>> Load Balancer:
>>>>>
>>>>> - LB Subscribe to topic and create endpoints
>>>>> - test with multiple LBs
>>>>> - Test with external LBs (like HA-Proxy)
>>>>> - LB stat publisher
>>>>> - Remove Autoscalar from current ELB
>>>>>
>>>>> Cloud Controller :
>>>>>
>>>>> - Move ADC to CC
>>>>> - Support pub/sub based ADC
>>>>> - Event aggregation
>>>>> - Dynamic Payloads
>>>>> - Topology handling
>>>>>
>>>>> Stratos Manager
>>>>>
>>>>> - Interface to define Cartridges
>>>>> - REST APIs - Json
>>>>> - New GUI/ without depending carbon framework.
>>>>> - CLI to work with new REST APIs
>>>>> - Policy handling
>>>>>
>>>>> AutoScalar :
>>>>>
>>>>> - New component call autoscalar
>>>>> - Rule Engine
>>>>> - Start with simple policy and then go to complex
>>>>>
>>>>> Event Process Engine:
>>>>>
>>>>> - New component
>>>>> - May be we can use wso2 cep
>>>>> - start with simple rule set and go to complex
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Oct 7, 2013 at 10:47 PM, Lakmal Warusawithana <lakmal@wso2.com
>>>>> > wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> As Sanjiva mention, in this architecture will address issues that has
>>>>>> in current Stratos. With this all major components will loosely coupled,
>>>>>> give more extendability. All communication will used standard pub/sub. Also
>>>>>> it is very easy to integrate with other external components.
>>>>>>
>>>>>> Please find the first cut of sequence diagram that I come across.
>>>>>>
>>>>>> thanks
>>>>>>
>>>>>>
>>>>>> On Mon, Oct 7, 2013 at 7:33 AM, Sanjiva Weerawarana <sanjiva@wso2.com
>>>>>> > 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. 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.
>>>>>>>
>>>>>>> - 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.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Lakmal Warusawithana
>>>>>> Software Architect; WSO2 Inc.
>>>>>> Mobile : +94714289692
>>>>>> Blog : http://lakmalsview.blogspot.com/
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Lakmal Warusawithana
>>>>> Software Architect; WSO2 Inc.
>>>>> Mobile : +94714289692
>>>>> Blog : http://lakmalsview.blogspot.com/
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Pradeep Fernando.
>>>> http://pradeepfernando.blogspot.com/
>>>>
>>>
>>>
>>>
>>> --
>>> Lakmal Warusawithana
>>> Software Architect; WSO2 Inc.
>>> Mobile : +94714289692
>>> Blog : http://lakmalsview.blogspot.com/
>>>
>>>
>>
>>
>> --
>> Reka Thirunavukkarasu
>> Software Engineer,
>> WSO2, Inc.:http://wso2.com,
>> Mobile: +94776442007
>>
>>
>>
>
>
> --
> Lakmal Warusawithana
> Software Architect; WSO2 Inc.
> Mobile : +94714289692
> Blog : http://lakmalsview.blogspot.com/
>
>
--
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
Re: proposed architectural changes to Stratos
Posted by Lahiru Sandaruwan <la...@wso2.com>.
Hi Lakmal,
Small change,
Autoscaler will also need the topology information. So it has to subscribe
to topology topic.
Thanks.
On Thu, Oct 10, 2013 at 4:54 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
> Hi folks,
>
> Based on several feedback, here I re-draw the Stratos Architecture
> diagram. Please share your thoughts.
>
> [image: Inline image 1]
>
>
> On Thu, Oct 10, 2013 at 12:34 PM, Reka Thirunavukkarasu <re...@wso2.com>wrote:
>
>> Hi Lakmal/Devs
>>
>> Would like to be a volunteer for the ADC pub/sub model and the topology
>> handling in the Cloud controller. Will start up with a discussion for them
>> in a separate thread.
>>
>> Thanks,
>> Reka
>>
>>
>> On Thu, Oct 10, 2013 at 9:08 AM, Lakmal Warusawithana <la...@wso2.com>wrote:
>>
>>> +1
>>>
>>>
>>>
>>> On Thu, Oct 10, 2013 at 7:36 AM, Pradeep Fernando <pr...@gmail.com>wrote:
>>>
>>>> Hi Lakmal/Devs,
>>>>
>>>> Like the new approach... Looks like the Stratos controller road map
>>>> items are more or less unaffected. I will own the Stratos Manager RESTful
>>>> APIs. (I have already started on this)
>>>>
>>>> Furthermore I will start a discussion on the Stratos new GUI as well.
>>>> Once we all agree, we can initiate the initialization bits in parallel to
>>>> REST API.
>>>>
>>>> Thanks,
>>>> --Pradeep
>>>> On Tue, Oct 8, 2013 at 11:17 AM, Lakmal Warusawithana <la...@wso2.com>wrote:
>>>>
>>>>> Hi devs,
>>>>>
>>>>> Shall we start looking into detail of this. Here(below) what I
>>>>> identified individual items for implementing this. we can make a branch and
>>>>> start working on this (some POC, then alpha ). May be we can do this as
>>>>> 4.0.0 release, because it has major improvement of the architecture.
>>>>> Please add/review this items. Volunteers can own these task :)
>>>>>
>>>>> Please share your thoughts.
>>>>>
>>>>> Common:
>>>>>
>>>>> - Component Topic Pub/Sub
>>>>> - Health Checker
>>>>> - Nagios
>>>>> - define all message structures
>>>>>
>>>>> Cartridge Agent:
>>>>>
>>>>> - Generic Agent -> better if we can use Python
>>>>> - pub/sub based DepSync
>>>>>
>>>>> Load Balancer:
>>>>>
>>>>> - LB Subscribe to topic and create endpoints
>>>>> - test with multiple LBs
>>>>> - Test with external LBs (like HA-Proxy)
>>>>> - LB stat publisher
>>>>> - Remove Autoscalar from current ELB
>>>>>
>>>>> Cloud Controller :
>>>>>
>>>>> - Move ADC to CC
>>>>> - Support pub/sub based ADC
>>>>> - Event aggregation
>>>>> - Dynamic Payloads
>>>>> - Topology handling
>>>>>
>>>>> Stratos Manager
>>>>>
>>>>> - Interface to define Cartridges
>>>>> - REST APIs - Json
>>>>> - New GUI/ without depending carbon framework.
>>>>> - CLI to work with new REST APIs
>>>>> - Policy handling
>>>>>
>>>>> AutoScalar :
>>>>>
>>>>> - New component call autoscalar
>>>>> - Rule Engine
>>>>> - Start with simple policy and then go to complex
>>>>>
>>>>> Event Process Engine:
>>>>>
>>>>> - New component
>>>>> - May be we can use wso2 cep
>>>>> - start with simple rule set and go to complex
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Oct 7, 2013 at 10:47 PM, Lakmal Warusawithana <lakmal@wso2.com
>>>>> > wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> As Sanjiva mention, in this architecture will address issues that has
>>>>>> in current Stratos. With this all major components will loosely coupled,
>>>>>> give more extendability. All communication will used standard pub/sub. Also
>>>>>> it is very easy to integrate with other external components.
>>>>>>
>>>>>> Please find the first cut of sequence diagram that I come across.
>>>>>>
>>>>>> thanks
>>>>>>
>>>>>>
>>>>>> On Mon, Oct 7, 2013 at 7:33 AM, Sanjiva Weerawarana <sanjiva@wso2.com
>>>>>> > 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. 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.
>>>>>>>
>>>>>>> - 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.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Lakmal Warusawithana
>>>>>> Software Architect; WSO2 Inc.
>>>>>> Mobile : +94714289692
>>>>>> Blog : http://lakmalsview.blogspot.com/
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Lakmal Warusawithana
>>>>> Software Architect; WSO2 Inc.
>>>>> Mobile : +94714289692
>>>>> Blog : http://lakmalsview.blogspot.com/
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Pradeep Fernando.
>>>> http://pradeepfernando.blogspot.com/
>>>>
>>>
>>>
>>>
>>> --
>>> Lakmal Warusawithana
>>> Software Architect; WSO2 Inc.
>>> Mobile : +94714289692
>>> Blog : http://lakmalsview.blogspot.com/
>>>
>>>
>>
>>
>> --
>> Reka Thirunavukkarasu
>> Software Engineer,
>> WSO2, Inc.:http://wso2.com,
>> Mobile: +94776442007
>>
>>
>>
>
>
> --
> Lakmal Warusawithana
> Software Architect; WSO2 Inc.
> Mobile : +94714289692
> Blog : http://lakmalsview.blogspot.com/
>
>
--
--
Lahiru Sandaruwan
Software Engineer,
Platform Technologies,
WSO2 Inc., http://wso2.com
lean.enterprise.middleware
email: lahirus@wso2.com cell: (+94) 773 325 954
blog: http://lahiruwrites.blogspot.com/
twitter: http://twitter.com/lahirus
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
Re: proposed architectural changes to Stratos
Posted by Lakmal Warusawithana <la...@wso2.com>.
Hi folks,
Based on several feedback, here I re-draw the Stratos Architecture diagram.
Please share your thoughts.
[image: Inline image 1]
On Thu, Oct 10, 2013 at 12:34 PM, Reka Thirunavukkarasu <re...@wso2.com>wrote:
> Hi Lakmal/Devs
>
> Would like to be a volunteer for the ADC pub/sub model and the topology
> handling in the Cloud controller. Will start up with a discussion for them
> in a separate thread.
>
> Thanks,
> Reka
>
>
> On Thu, Oct 10, 2013 at 9:08 AM, Lakmal Warusawithana <la...@wso2.com>wrote:
>
>> +1
>>
>>
>>
>> On Thu, Oct 10, 2013 at 7:36 AM, Pradeep Fernando <pr...@gmail.com>wrote:
>>
>>> Hi Lakmal/Devs,
>>>
>>> Like the new approach... Looks like the Stratos controller road map
>>> items are more or less unaffected. I will own the Stratos Manager RESTful
>>> APIs. (I have already started on this)
>>>
>>> Furthermore I will start a discussion on the Stratos new GUI as well.
>>> Once we all agree, we can initiate the initialization bits in parallel to
>>> REST API.
>>>
>>> Thanks,
>>> --Pradeep
>>> On Tue, Oct 8, 2013 at 11:17 AM, Lakmal Warusawithana <la...@wso2.com>wrote:
>>>
>>>> Hi devs,
>>>>
>>>> Shall we start looking into detail of this. Here(below) what I
>>>> identified individual items for implementing this. we can make a branch and
>>>> start working on this (some POC, then alpha ). May be we can do this as
>>>> 4.0.0 release, because it has major improvement of the architecture.
>>>> Please add/review this items. Volunteers can own these task :)
>>>>
>>>> Please share your thoughts.
>>>>
>>>> Common:
>>>>
>>>> - Component Topic Pub/Sub
>>>> - Health Checker
>>>> - Nagios
>>>> - define all message structures
>>>>
>>>> Cartridge Agent:
>>>>
>>>> - Generic Agent -> better if we can use Python
>>>> - pub/sub based DepSync
>>>>
>>>> Load Balancer:
>>>>
>>>> - LB Subscribe to topic and create endpoints
>>>> - test with multiple LBs
>>>> - Test with external LBs (like HA-Proxy)
>>>> - LB stat publisher
>>>> - Remove Autoscalar from current ELB
>>>>
>>>> Cloud Controller :
>>>>
>>>> - Move ADC to CC
>>>> - Support pub/sub based ADC
>>>> - Event aggregation
>>>> - Dynamic Payloads
>>>> - Topology handling
>>>>
>>>> Stratos Manager
>>>>
>>>> - Interface to define Cartridges
>>>> - REST APIs - Json
>>>> - New GUI/ without depending carbon framework.
>>>> - CLI to work with new REST APIs
>>>> - Policy handling
>>>>
>>>> AutoScalar :
>>>>
>>>> - New component call autoscalar
>>>> - Rule Engine
>>>> - Start with simple policy and then go to complex
>>>>
>>>> Event Process Engine:
>>>>
>>>> - New component
>>>> - May be we can use wso2 cep
>>>> - start with simple rule set and go to complex
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Oct 7, 2013 at 10:47 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> As Sanjiva mention, in this architecture will address issues that has
>>>>> in current Stratos. With this all major components will loosely coupled,
>>>>> give more extendability. All communication will used standard pub/sub. Also
>>>>> it is very easy to integrate with other external components.
>>>>>
>>>>> Please find the first cut of sequence diagram that I come across.
>>>>>
>>>>> thanks
>>>>>
>>>>>
>>>>> On Mon, Oct 7, 2013 at 7:33 AM, Sanjiva Weerawarana <sa...@wso2.com>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. 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.
>>>>>>
>>>>>> - 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.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Lakmal Warusawithana
>>>>> Software Architect; WSO2 Inc.
>>>>> Mobile : +94714289692
>>>>> Blog : http://lakmalsview.blogspot.com/
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Lakmal Warusawithana
>>>> Software Architect; WSO2 Inc.
>>>> Mobile : +94714289692
>>>> Blog : http://lakmalsview.blogspot.com/
>>>>
>>>>
>>>
>>>
>>> --
>>> Pradeep Fernando.
>>> http://pradeepfernando.blogspot.com/
>>>
>>
>>
>>
>> --
>> Lakmal Warusawithana
>> Software Architect; WSO2 Inc.
>> Mobile : +94714289692
>> Blog : http://lakmalsview.blogspot.com/
>>
>>
>
>
> --
> Reka Thirunavukkarasu
> Software Engineer,
> WSO2, Inc.:http://wso2.com,
> Mobile: +94776442007
>
>
>
--
Lakmal Warusawithana
Software Architect; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: proposed architectural changes to Stratos
Posted by Reka Thirunavukkarasu <re...@wso2.com>.
Hi Lakmal/Devs
Would like to be a volunteer for the ADC pub/sub model and the topology
handling in the Cloud controller. Will start up with a discussion for them
in a separate thread.
Thanks,
Reka
On Thu, Oct 10, 2013 at 9:08 AM, Lakmal Warusawithana <la...@wso2.com>wrote:
> +1
>
>
>
> On Thu, Oct 10, 2013 at 7:36 AM, Pradeep Fernando <pr...@gmail.com>wrote:
>
>> Hi Lakmal/Devs,
>>
>> Like the new approach... Looks like the Stratos controller road map items
>> are more or less unaffected. I will own the Stratos Manager RESTful APIs.
>> (I have already started on this)
>>
>> Furthermore I will start a discussion on the Stratos new GUI as well.
>> Once we all agree, we can initiate the initialization bits in parallel to
>> REST API.
>>
>> Thanks,
>> --Pradeep
>> On Tue, Oct 8, 2013 at 11:17 AM, Lakmal Warusawithana <la...@wso2.com>wrote:
>>
>>> Hi devs,
>>>
>>> Shall we start looking into detail of this. Here(below) what I
>>> identified individual items for implementing this. we can make a branch and
>>> start working on this (some POC, then alpha ). May be we can do this as
>>> 4.0.0 release, because it has major improvement of the architecture.
>>> Please add/review this items. Volunteers can own these task :)
>>>
>>> Please share your thoughts.
>>>
>>> Common:
>>>
>>> - Component Topic Pub/Sub
>>> - Health Checker
>>> - Nagios
>>> - define all message structures
>>>
>>> Cartridge Agent:
>>>
>>> - Generic Agent -> better if we can use Python
>>> - pub/sub based DepSync
>>>
>>> Load Balancer:
>>>
>>> - LB Subscribe to topic and create endpoints
>>> - test with multiple LBs
>>> - Test with external LBs (like HA-Proxy)
>>> - LB stat publisher
>>> - Remove Autoscalar from current ELB
>>>
>>> Cloud Controller :
>>>
>>> - Move ADC to CC
>>> - Support pub/sub based ADC
>>> - Event aggregation
>>> - Dynamic Payloads
>>> - Topology handling
>>>
>>> Stratos Manager
>>>
>>> - Interface to define Cartridges
>>> - REST APIs - Json
>>> - New GUI/ without depending carbon framework.
>>> - CLI to work with new REST APIs
>>> - Policy handling
>>>
>>> AutoScalar :
>>>
>>> - New component call autoscalar
>>> - Rule Engine
>>> - Start with simple policy and then go to complex
>>>
>>> Event Process Engine:
>>>
>>> - New component
>>> - May be we can use wso2 cep
>>> - start with simple rule set and go to complex
>>>
>>>
>>>
>>>
>>> On Mon, Oct 7, 2013 at 10:47 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
>>>
>>>> Hi,
>>>>
>>>> As Sanjiva mention, in this architecture will address issues that has
>>>> in current Stratos. With this all major components will loosely coupled,
>>>> give more extendability. All communication will used standard pub/sub. Also
>>>> it is very easy to integrate with other external components.
>>>>
>>>> Please find the first cut of sequence diagram that I come across.
>>>>
>>>> thanks
>>>>
>>>>
>>>> On Mon, Oct 7, 2013 at 7:33 AM, Sanjiva Weerawarana <sa...@wso2.com>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. 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.
>>>>>
>>>>> - 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.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Lakmal Warusawithana
>>>> Software Architect; WSO2 Inc.
>>>> Mobile : +94714289692
>>>> Blog : http://lakmalsview.blogspot.com/
>>>>
>>>>
>>>
>>>
>>> --
>>> Lakmal Warusawithana
>>> Software Architect; WSO2 Inc.
>>> Mobile : +94714289692
>>> Blog : http://lakmalsview.blogspot.com/
>>>
>>>
>>
>>
>> --
>> Pradeep Fernando.
>> http://pradeepfernando.blogspot.com/
>>
>
>
>
> --
> Lakmal Warusawithana
> Software Architect; WSO2 Inc.
> Mobile : +94714289692
> Blog : http://lakmalsview.blogspot.com/
>
>
--
Reka Thirunavukkarasu
Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
Re: proposed architectural changes to Stratos
Posted by Lakmal Warusawithana <la...@wso2.com>.
+1
On Thu, Oct 10, 2013 at 7:36 AM, Pradeep Fernando <pr...@gmail.com>wrote:
> Hi Lakmal/Devs,
>
> Like the new approach... Looks like the Stratos controller road map items
> are more or less unaffected. I will own the Stratos Manager RESTful APIs.
> (I have already started on this)
>
> Furthermore I will start a discussion on the Stratos new GUI as well. Once
> we all agree, we can initiate the initialization bits in parallel to REST
> API.
>
> Thanks,
> --Pradeep
> On Tue, Oct 8, 2013 at 11:17 AM, Lakmal Warusawithana <la...@wso2.com>wrote:
>
>> Hi devs,
>>
>> Shall we start looking into detail of this. Here(below) what I identified
>> individual items for implementing this. we can make a branch and start
>> working on this (some POC, then alpha ). May be we can do this as 4.0.0
>> release, because it has major improvement of the architecture. Please
>> add/review this items. Volunteers can own these task :)
>>
>> Please share your thoughts.
>>
>> Common:
>>
>> - Component Topic Pub/Sub
>> - Health Checker
>> - Nagios
>> - define all message structures
>>
>> Cartridge Agent:
>>
>> - Generic Agent -> better if we can use Python
>> - pub/sub based DepSync
>>
>> Load Balancer:
>>
>> - LB Subscribe to topic and create endpoints
>> - test with multiple LBs
>> - Test with external LBs (like HA-Proxy)
>> - LB stat publisher
>> - Remove Autoscalar from current ELB
>>
>> Cloud Controller :
>>
>> - Move ADC to CC
>> - Support pub/sub based ADC
>> - Event aggregation
>> - Dynamic Payloads
>> - Topology handling
>>
>> Stratos Manager
>>
>> - Interface to define Cartridges
>> - REST APIs - Json
>> - New GUI/ without depending carbon framework.
>> - CLI to work with new REST APIs
>> - Policy handling
>>
>> AutoScalar :
>>
>> - New component call autoscalar
>> - Rule Engine
>> - Start with simple policy and then go to complex
>>
>> Event Process Engine:
>>
>> - New component
>> - May be we can use wso2 cep
>> - start with simple rule set and go to complex
>>
>>
>>
>>
>> On Mon, Oct 7, 2013 at 10:47 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
>>
>>> Hi,
>>>
>>> As Sanjiva mention, in this architecture will address issues that has in
>>> current Stratos. With this all major components will loosely coupled, give
>>> more extendability. All communication will used standard pub/sub. Also it
>>> is very easy to integrate with other external components.
>>>
>>> Please find the first cut of sequence diagram that I come across.
>>>
>>> thanks
>>>
>>>
>>> On Mon, Oct 7, 2013 at 7:33 AM, Sanjiva Weerawarana <sa...@wso2.com>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. 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.
>>>>
>>>> - 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.
>>>>
>>>
>>>
>>>
>>> --
>>> Lakmal Warusawithana
>>> Software Architect; WSO2 Inc.
>>> Mobile : +94714289692
>>> Blog : http://lakmalsview.blogspot.com/
>>>
>>>
>>
>>
>> --
>> Lakmal Warusawithana
>> Software Architect; WSO2 Inc.
>> Mobile : +94714289692
>> Blog : http://lakmalsview.blogspot.com/
>>
>>
>
>
> --
> Pradeep Fernando.
> http://pradeepfernando.blogspot.com/
>
--
Lakmal Warusawithana
Software Architect; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: proposed architectural changes to Stratos
Posted by Pradeep Fernando <pr...@gmail.com>.
Hi Lakmal/Devs,
Like the new approach... Looks like the Stratos controller road map items
are more or less unaffected. I will own the Stratos Manager RESTful APIs.
(I have already started on this)
Furthermore I will start a discussion on the Stratos new GUI as well. Once
we all agree, we can initiate the initialization bits in parallel to REST
API.
Thanks,
--Pradeep
On Tue, Oct 8, 2013 at 11:17 AM, Lakmal Warusawithana <la...@wso2.com>wrote:
> Hi devs,
>
> Shall we start looking into detail of this. Here(below) what I identified
> individual items for implementing this. we can make a branch and start
> working on this (some POC, then alpha ). May be we can do this as 4.0.0
> release, because it has major improvement of the architecture. Please
> add/review this items. Volunteers can own these task :)
>
> Please share your thoughts.
>
> Common:
>
> - Component Topic Pub/Sub
> - Health Checker
> - Nagios
> - define all message structures
>
> Cartridge Agent:
>
> - Generic Agent -> better if we can use Python
> - pub/sub based DepSync
>
> Load Balancer:
>
> - LB Subscribe to topic and create endpoints
> - test with multiple LBs
> - Test with external LBs (like HA-Proxy)
> - LB stat publisher
> - Remove Autoscalar from current ELB
>
> Cloud Controller :
>
> - Move ADC to CC
> - Support pub/sub based ADC
> - Event aggregation
> - Dynamic Payloads
> - Topology handling
>
> Stratos Manager
>
> - Interface to define Cartridges
> - REST APIs - Json
> - New GUI/ without depending carbon framework.
> - CLI to work with new REST APIs
> - Policy handling
>
> AutoScalar :
>
> - New component call autoscalar
> - Rule Engine
> - Start with simple policy and then go to complex
>
> Event Process Engine:
>
> - New component
> - May be we can use wso2 cep
> - start with simple rule set and go to complex
>
>
>
>
> On Mon, Oct 7, 2013 at 10:47 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
>
>> Hi,
>>
>> As Sanjiva mention, in this architecture will address issues that has in
>> current Stratos. With this all major components will loosely coupled, give
>> more extendability. All communication will used standard pub/sub. Also it
>> is very easy to integrate with other external components.
>>
>> Please find the first cut of sequence diagram that I come across.
>>
>> thanks
>>
>>
>> On Mon, Oct 7, 2013 at 7:33 AM, Sanjiva Weerawarana <sa...@wso2.com>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. 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.
>>>
>>> - 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.
>>>
>>
>>
>>
>> --
>> Lakmal Warusawithana
>> Software Architect; WSO2 Inc.
>> Mobile : +94714289692
>> Blog : http://lakmalsview.blogspot.com/
>>
>>
>
>
> --
> Lakmal Warusawithana
> Software Architect; WSO2 Inc.
> Mobile : +94714289692
> Blog : http://lakmalsview.blogspot.com/
>
>
--
Pradeep Fernando.
http://pradeepfernando.blogspot.com/
Re: proposed architectural changes to Stratos
Posted by Imesh Gunaratne <im...@apache.org>.
Hi Lakmal,
The new Stratos architecture looks promising. I think the decoupled nature
of the components will allow users to extend Stratos ecosystem seamlessly.
I would like to contribute to Load Balancer module.
I think we could re-design existing Stratos ELB by removing it's
dependencies to Autoscaler, Cloud Controller, Axis2/Tribes clustering and
introducing a new topology domain model. This will allow us to make the
load balancer more lighter and replace it with any other standard load
balancer which could communicate via the message broker in the new
architecture.
I will prepare a design plan for this and post it to dev list soon.
Thanks
Imesh
On Tue, Oct 8, 2013 at 11:17 AM, Lakmal Warusawithana <la...@wso2.com>wrote:
> Hi devs,
>
> Shall we start looking into detail of this. Here(below) what I identified
> individual items for implementing this. we can make a branch and start
> working on this (some POC, then alpha ). May be we can do this as 4.0.0
> release, because it has major improvement of the architecture. Please
> add/review this items. Volunteers can own these task :)
>
> Please share your thoughts.
>
> Common:
>
> - Component Topic Pub/Sub
> - Health Checker
> - Nagios
> - define all message structures
>
> Cartridge Agent:
>
> - Generic Agent -> better if we can use Python
> - pub/sub based DepSync
>
> Load Balancer:
>
> - LB Subscribe to topic and create endpoints
> - test with multiple LBs
> - Test with external LBs (like HA-Proxy)
> - LB stat publisher
> - Remove Autoscalar from current ELB
>
> Cloud Controller :
>
> - Move ADC to CC
> - Support pub/sub based ADC
> - Event aggregation
> - Dynamic Payloads
> - Topology handling
>
> Stratos Manager
>
> - Interface to define Cartridges
> - REST APIs - Json
> - New GUI/ without depending carbon framework.
> - CLI to work with new REST APIs
> - Policy handling
>
> AutoScalar :
>
> - New component call autoscalar
> - Rule Engine
> - Start with simple policy and then go to complex
>
> Event Process Engine:
>
> - New component
> - May be we can use wso2 cep
> - start with simple rule set and go to complex
>
>
>
>
> On Mon, Oct 7, 2013 at 10:47 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
>
>> Hi,
>>
>> As Sanjiva mention, in this architecture will address issues that has in
>> current Stratos. With this all major components will loosely coupled, give
>> more extendability. All communication will used standard pub/sub. Also it
>> is very easy to integrate with other external components.
>>
>> Please find the first cut of sequence diagram that I come across.
>>
>> thanks
>>
>>
>> On Mon, Oct 7, 2013 at 7:33 AM, Sanjiva Weerawarana <sa...@wso2.com>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. 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.
>>>
>>> - 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.
>>>
>>
>>
>>
>> --
>> Lakmal Warusawithana
>> Software Architect; WSO2 Inc.
>> Mobile : +94714289692
>> Blog : http://lakmalsview.blogspot.com/
>>
>>
>
>
> --
> Lakmal Warusawithana
> Software Architect; WSO2 Inc.
> Mobile : +94714289692
> Blog : http://lakmalsview.blogspot.com/
>
>
Re: proposed architectural changes to Stratos
Posted by Lakmal Warusawithana <la...@wso2.com>.
Hi devs,
Shall we start looking into detail of this. Here(below) what I identified
individual items for implementing this. we can make a branch and start
working on this (some POC, then alpha ). May be we can do this as 4.0.0
release, because it has major improvement of the architecture. Please
add/review this items. Volunteers can own these task :)
Please share your thoughts.
Common:
- Component Topic Pub/Sub
- Health Checker
- Nagios
- define all message structures
Cartridge Agent:
- Generic Agent -> better if we can use Python
- pub/sub based DepSync
Load Balancer:
- LB Subscribe to topic and create endpoints
- test with multiple LBs
- Test with external LBs (like HA-Proxy)
- LB stat publisher
- Remove Autoscalar from current ELB
Cloud Controller :
- Move ADC to CC
- Support pub/sub based ADC
- Event aggregation
- Dynamic Payloads
- Topology handling
Stratos Manager
- Interface to define Cartridges
- REST APIs - Json
- New GUI/ without depending carbon framework.
- CLI to work with new REST APIs
- Policy handling
AutoScalar :
- New component call autoscalar
- Rule Engine
- Start with simple policy and then go to complex
Event Process Engine:
- New component
- May be we can use wso2 cep
- start with simple rule set and go to complex
On Mon, Oct 7, 2013 at 10:47 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
> Hi,
>
> As Sanjiva mention, in this architecture will address issues that has in
> current Stratos. With this all major components will loosely coupled, give
> more extendability. All communication will used standard pub/sub. Also it
> is very easy to integrate with other external components.
>
> Please find the first cut of sequence diagram that I come across.
>
> thanks
>
>
> On Mon, Oct 7, 2013 at 7:33 AM, Sanjiva Weerawarana <sa...@wso2.com>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. 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.
>>
>> - 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.
>>
>
>
>
> --
> Lakmal Warusawithana
> Software Architect; WSO2 Inc.
> Mobile : +94714289692
> Blog : http://lakmalsview.blogspot.com/
>
>
--
Lakmal Warusawithana
Software Architect; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: proposed architectural changes to Stratos
Posted by Lakmal Warusawithana <la...@wso2.com>.
Hi,
As Sanjiva mention, in this architecture will address issues that has in
current Stratos. With this all major components will loosely coupled, give
more extendability. All communication will used standard pub/sub. Also it
is very easy to integrate with other external components.
Please find the first cut of sequence diagram that I come across.
thanks
On Mon, Oct 7, 2013 at 7:33 AM, Sanjiva Weerawarana <sa...@wso2.com>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. 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.
>
> - 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.
>
--
Lakmal Warusawithana
Software Architect; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: proposed architectural changes to Stratos
Posted by Nirmal Fernando <ni...@gmail.com>.
Hi Sanjiva,
On Fri, Oct 11, 2013 at 11:27 AM, Sanjiva Weerawarana <sa...@wso2.com>wrote:
> On Fri, Oct 11, 2013 at 10:23 AM, Nirmal Fernando <ni...@gmail.com>wrote:
>
>> +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.
>>
>
> Are you suggesting some topic hierarchy which recognizes the actual LB
> type? I don't like that because that couples the CC to LB types.
>
I'm sorry, I don't get your point. What I meant was a topic hierarchy like
below: Hierarchy is based on the services and service clusters.
Topology
|
|____PHP
| |____ php cluster 1
| |____ php cluster 2
| ......
|____MySql
| |____ mysql cluster 1
| ......
.....
> My preference is a model where all LBs get all updates and they decide
> what they care about and do something about those.
>
In the topic hierarchy case, LBs will get only the information that each
one of them interested in and not other garbage. In someway, LB should know
what services or even clusters, it gonna serve and then with a topic
hierarchy in hand, LBs get the flexibility of subscribing only to the
topics that it's interested in.
>
>>> - 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
>> restart.
>>
>
> Yeah to handle fresh LBs we either need to have a periodic update going
> out or have a way for the LB to contact the CC and get the latest config. I
> prefer the latter because that's a bit like ADC being used to config a
> fresh instance.
>
+1. But I've heard from some other discussion that we are thinking of
keeping ADC inside Stratos Manager. :)
In fact, going forward we could even auto scale LBs .. but that's a bit far
> fetched as it requires possibly doing DNS updates too. But its not that
> hard.
>
> Sanjiva.
> --
> 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
>
--
Best Regards,
Nirmal
C.S.Nirmal J. Fernando
Senior Software Engineer,
WSO2 Inc.
Blog: http://nirmalfdo.blogspot.com/
Re: proposed architectural changes to Stratos
Posted by Isuru Haththotuwa <is...@wso2.com>.
Hi Devs,
I'll work on the Interface to define Cartridges in Stratos Manager. I
reported a jira for the same purpose sometime back, will continue it and
provide an update on a separate thread.
On Fri, Oct 11, 2013 at 5:05 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
> Hi folks,
>
> Please see modified architecture diagram, with few changes. (autoscalar
> subscribe to topology, change HA proxy to any third party LB)
>
> [image: Inline image 1]
>
> See below for how topology can handle in CC, LB and autoscalar. Also added
> some sample topology structure.
>
> [image: Inline image 2]
>
>
> Here I am trying to explain in detail :)
>
>
> - First user will subscribe to a cartridge, say PHP.
> - Then subscription detail will goes to CC, with selected policy..etc
> - CC will create initial topology with saying "create cluster" event.
> (here CC will publish topology with different events, also it will
> periodically send full topology in event call "full topology"). for this
> scenario create cluster event message looks like below (please concider
> this is only sample, we need to define it correctly)
>
> event: create cluster
> {
> cluster: PHP-UUID
> policy : policy1
> }
>
> - Autoscalar(AS) will listen to all event that publish by CC. (I will
> explain why later). So from this event, AS will take this topology info and
> get a new scaling (up/down) decision and pass it to CC. (For eg. based on
> the policy, AS will say start first instance in EC2 with A1 instance type.)
> - CC will get the AS decision, and create PHP instance on EC2 with
> type A1 via jclouds. Also it will update topology with "spin instance"
> event.
>
> event: spin instance
> {
> cluster: PHP-UUID
> policy : policy1
> Cloud {
> IaaS : EC2
> Instances{
> Instance: UUID
> type : A1
> Status : spinning
> }
> }
> }
>
>
> - After instance started, update all artifacts and then it will
> publish info to "Instance Status" topology. for a sample it may look like
> below
>
> cluster : PHP-UUID
> instance : UUID
> IP : 192.168.1.10
> port : 443
> Status : ACTIVE
>
> - CC will received this and update topology with "add member" event
>
> event: add member
> {
> cluster: PHP-UUID
> policy : policy1
> Cloud {
> IaaS : EC2
> Instances{
> Instance: UUID
> type : A1
> IP : 192.168.1.10
> port : 443
> status: ACTIVE
> }
> }
> }
>
>
> - LB is subscribe to topology, but it will only interested in some set
> of events. For eg, LB will interested in "add member" event and process
> topology and update its member list for load balance.
>
>
>
> Event "full topology" will only use, LB or AS restart or first start-up
> time to get current state. AS need to know every event of the topology,
> because see following scenario.
>
>
> - AS will send spin up an instance and for instance to come active
> status lets say take 2 minute.
> - Assume at same time there is huge load coming to to cluster. So
> based on CEP summarized stats, to handle this load, there should be
> at-least 3 instances. Now AS need to now how many in the pipe-line, and
> based on "spin instance" event, it can get that. likewise AS should update
> to get correct decision.
>
> I hope I explain with some detail. Lets see how you can get/understand
> this :).
>
> So based on above design, we only need one topic call topology, and its
> make our life easier and clean architecture.
>
> thanks
>
>
>
>
> On Fri, Oct 11, 2013 at 1:21 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
>
>>
>>
>>
>> On Fri, Oct 11, 2013 at 11:27 AM, Sanjiva Weerawarana <sa...@wso2.com>wrote:
>>
>>> On Fri, Oct 11, 2013 at 10:23 AM, Nirmal Fernando <
>>> nirmal070125@gmail.com> wrote:
>>>
>>>> +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.
>>>>
>>>
>>> Are you suggesting some topic hierarchy which recognizes the actual LB
>>> type? I don't like that because that couples the CC to LB types. My
>>> preference is a model where all LBs get all updates and they decide what
>>> they care about and do something about those.
>>>
>>
>> Yeah, I also think, no need to have hierarchical typology topics (even
>> hierarchical topology messages), single topic can do the stuff. Maybe we
>> need to have topology topic for publish full topology (it will used by LBs,
>> Autoscalar..etc to come current state when it restart or new comers ) and
>> topology-event topic for sync with the events like add/remove cluster
>> members. I will draw some sequence and sample topology messages, which
>> explain it further. These topology topics will utilize by LBs and
>> autoscalar for there functionalists.
>>
>>
>>>
>>>>> - 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
>>>> restart.
>>>>
>>>
>>> Yeah to handle fresh LBs we either need to have a periodic update going
>>> out or have a way for the LB to contact the CC and get the latest config. I
>>> prefer the latter because that's a bit like ADC being used to config a
>>> fresh instance. In fact, going forward we could even auto scale LBs .. but
>>> that's a bit far fetched as it requires possibly doing DNS updates too. But
>>> its not that hard.
>>>
>>
>>> Sanjiva.
>>> --
>>> 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
>>>
>>
>>
>>
>> --
>> Lakmal Warusawithana
>> Software Architect; WSO2 Inc.
>> Mobile : +94714289692
>> Blog : http://lakmalsview.blogspot.com/
>>
>>
>
>
> --
> Lakmal Warusawithana
> Software Architect; WSO2 Inc.
> Mobile : +94714289692
> Blog : http://lakmalsview.blogspot.com/
>
>
--
Thanks and Regards,
Isuru H.
Software Engineer, WSO2 Inc.
+94 716 358 048* <http://wso2.com/>*
Re: proposed architectural changes to Stratos
Posted by Lakmal Warusawithana <la...@wso2.com>.
Hi folks,
Please see modified architecture diagram, with few changes. (autoscalar
subscribe to topology, change HA proxy to any third party LB)
[image: Inline image 1]
See below for how topology can handle in CC, LB and autoscalar. Also added
some sample topology structure.
[image: Inline image 2]
Here I am trying to explain in detail :)
- First user will subscribe to a cartridge, say PHP.
- Then subscription detail will goes to CC, with selected policy..etc
- CC will create initial topology with saying "create cluster" event.
(here CC will publish topology with different events, also it will
periodically send full topology in event call "full topology"). for this
scenario create cluster event message looks like below (please concider
this is only sample, we need to define it correctly)
event: create cluster
{
cluster: PHP-UUID
policy : policy1
}
- Autoscalar(AS) will listen to all event that publish by CC. (I will
explain why later). So from this event, AS will take this topology info and
get a new scaling (up/down) decision and pass it to CC. (For eg. based on
the policy, AS will say start first instance in EC2 with A1 instance type.)
- CC will get the AS decision, and create PHP instance on EC2 with type
A1 via jclouds. Also it will update topology with "spin instance" event.
event: spin instance
{
cluster: PHP-UUID
policy : policy1
Cloud {
IaaS : EC2
Instances{
Instance: UUID
type : A1
Status : spinning
}
}
}
- After instance started, update all artifacts and then it will publish
info to "Instance Status" topology. for a sample it may look like below
cluster : PHP-UUID
instance : UUID
IP : 192.168.1.10
port : 443
Status : ACTIVE
- CC will received this and update topology with "add member" event
event: add member
{
cluster: PHP-UUID
policy : policy1
Cloud {
IaaS : EC2
Instances{
Instance: UUID
type : A1
IP : 192.168.1.10
port : 443
status: ACTIVE
}
}
}
- LB is subscribe to topology, but it will only interested in some set
of events. For eg, LB will interested in "add member" event and process
topology and update its member list for load balance.
Event "full topology" will only use, LB or AS restart or first start-up
time to get current state. AS need to know every event of the topology,
because see following scenario.
- AS will send spin up an instance and for instance to come active
status lets say take 2 minute.
- Assume at same time there is huge load coming to to cluster. So based
on CEP summarized stats, to handle this load, there should be at-least 3
instances. Now AS need to now how many in the pipe-line, and based on "spin
instance" event, it can get that. likewise AS should update to get correct
decision.
I hope I explain with some detail. Lets see how you can get/understand this
:).
So based on above design, we only need one topic call topology, and its
make our life easier and clean architecture.
thanks
On Fri, Oct 11, 2013 at 1:21 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
>
>
>
> On Fri, Oct 11, 2013 at 11:27 AM, Sanjiva Weerawarana <sa...@wso2.com>wrote:
>
>> On Fri, Oct 11, 2013 at 10:23 AM, Nirmal Fernando <nirmal070125@gmail.com
>> > wrote:
>>
>>> +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.
>>>
>>
>> Are you suggesting some topic hierarchy which recognizes the actual LB
>> type? I don't like that because that couples the CC to LB types. My
>> preference is a model where all LBs get all updates and they decide what
>> they care about and do something about those.
>>
>
> Yeah, I also think, no need to have hierarchical typology topics (even
> hierarchical topology messages), single topic can do the stuff. Maybe we
> need to have topology topic for publish full topology (it will used by LBs,
> Autoscalar..etc to come current state when it restart or new comers ) and
> topology-event topic for sync with the events like add/remove cluster
> members. I will draw some sequence and sample topology messages, which
> explain it further. These topology topics will utilize by LBs and
> autoscalar for there functionalists.
>
>
>>
>>>> - 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
>>> restart.
>>>
>>
>> Yeah to handle fresh LBs we either need to have a periodic update going
>> out or have a way for the LB to contact the CC and get the latest config. I
>> prefer the latter because that's a bit like ADC being used to config a
>> fresh instance. In fact, going forward we could even auto scale LBs .. but
>> that's a bit far fetched as it requires possibly doing DNS updates too. But
>> its not that hard.
>>
>
>> Sanjiva.
>> --
>> 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
>>
>
>
>
> --
> Lakmal Warusawithana
> Software Architect; WSO2 Inc.
> Mobile : +94714289692
> Blog : http://lakmalsview.blogspot.com/
>
>
--
Lakmal Warusawithana
Software Architect; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: proposed architectural changes to Stratos
Posted by Lakmal Warusawithana <la...@wso2.com>.
On Fri, Oct 11, 2013 at 11:27 AM, Sanjiva Weerawarana <sa...@wso2.com>wrote:
> On Fri, Oct 11, 2013 at 10:23 AM, Nirmal Fernando <ni...@gmail.com>wrote:
>
>> +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.
>>
>
> Are you suggesting some topic hierarchy which recognizes the actual LB
> type? I don't like that because that couples the CC to LB types. My
> preference is a model where all LBs get all updates and they decide what
> they care about and do something about those.
>
Yeah, I also think, no need to have hierarchical typology topics (even
hierarchical topology messages), single topic can do the stuff. Maybe we
need to have topology topic for publish full topology (it will used by LBs,
Autoscalar..etc to come current state when it restart or new comers ) and
topology-event topic for sync with the events like add/remove cluster
members. I will draw some sequence and sample topology messages, which
explain it further. These topology topics will utilize by LBs and
autoscalar for there functionalists.
>
>>> - 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
>> restart.
>>
>
> Yeah to handle fresh LBs we either need to have a periodic update going
> out or have a way for the LB to contact the CC and get the latest config. I
> prefer the latter because that's a bit like ADC being used to config a
> fresh instance. In fact, going forward we could even auto scale LBs .. but
> that's a bit far fetched as it requires possibly doing DNS updates too. But
> its not that hard.
>
> Sanjiva.
> --
> 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
>
--
Lakmal Warusawithana
Software Architect; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: proposed architectural changes to Stratos
Posted by Sanjiva Weerawarana <sa...@wso2.com>.
On Fri, Oct 11, 2013 at 10:23 AM, Nirmal Fernando <ni...@gmail.com>wrote:
> +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.
>
Are you suggesting some topic hierarchy which recognizes the actual LB
type? I don't like that because that couples the CC to LB types. My
preference is a model where all LBs get all updates and they decide what
they care about and do something about those.
>
>> - 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
> restart.
>
Yeah to handle fresh LBs we either need to have a periodic update going out
or have a way for the LB to contact the CC and get the latest config. I
prefer the latter because that's a bit like ADC being used to config a
fresh instance. In fact, going forward we could even auto scale LBs .. but
that's a bit far fetched as it requires possibly doing DNS updates too. But
its not that hard.
Sanjiva.
--
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
Re: proposed architectural changes to Stratos
Posted by Nirmal Fernando <ni...@gmail.com>.
+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 <sa...@wso2.com>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
restart.
>
> - 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
bit.
>
> -
> - 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,
Nirmal
C.S.Nirmal J. Fernando
Senior Software Engineer,
WSO2 Inc.
Blog: http://nirmalfdo.blogspot.com/