stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nirmal Fernando <nirmal070...@gmail.com>
Subject Re: Stratos Milestone plan
Date Wed, 26 Jun 2013 05:05:06 GMT
Hi Sanjeewa,


On Tue, Jun 25, 2013 at 12:15 PM, sanjeewa rangana <sanjeewa190@gmail.com>wrote:

>
>
>
> On Mon, Jun 24, 2013 at 6:16 PM, Lakmal Warusawithana <lakmal@wso2.com>wrote:
>
>> Hi All,
>>
>> I hope all commiters / folks are in the mailing list now. Here I have
>> listed below, some identified improvements, features that like to have in
>> Stratos.
>>
>> Any other improvements/features are mostly welcome and will add those to
>> the bellow list, then we can discuss and then will create milestones plan
>> for releases. ( We will commit current code based soon after we got the git
>> repository available)
>>
>> Before that if some one want to get quick overview of current
>> release/architecture of Stratos please see [1] for my reason blog post or
>> more detail [2] with current product documentation, which will migrate to
>> Apache soon. Also we will organize some hangout sessions to explain current
>> architecture and code based, and it may helpful other commierts to come
>> up-to speed quickly.
>>
>> Here the list;
>>
>>    - Re-factor current code to Apache
>>
>> First we will move current code based to apache and then start
>> re-factoring to apache and make a release without adding any other
>> improvement or feature.
>>
>>
>>    - IaaS Independent cartridge for Linux.
>>
>> With the current architecture when you create a cartridge its depend on
>> the IaaS. For example If you create a cartridge in EC2, we have to make an
>>  AMI  cartridge. Likewise you have to create cartridges (say PHP cartridge)
>> for each and every IaaSs for support the IaaSs. As a solution we can
>> introduce LXC based cartridges (which IaaS independent cartridges) and can
>> be consider LXC is the default Stratos runtime container for Linux
>> cartridges. Also this will provide more scallability to the PaaS (I will
>> start separate mail thread with more detail on this)
>>
>>
>>    - Support Windows based cartridges.
>>
>> If IaaS support windows VM then we can have windows based cartridges. It
>> will lead to have .net cartridges
>>
>>
>>    - Expand auto-scaling algorithm
>>
>> Currently auto scaling decision take based on looking at length of the
>> http/https request queue. We have to expand this to consider CPU usage,
>> memory utilization ..etc of the cartridges.
>>
>> Before we introduce que length based decision making mechanism we had
> load average based decision making mechanism. Each server need to expose
> some API(some service) to get load average of given server. Load
> calculation can be different from one server to other. Load balancer will
> do web service call to those end points and update load average values of
> member list periodically.
>

We will separate out the load balancer logic and the auto-scaling logic
soon. This would require some code level changes. But the vision is there.

In brief, we should build APIs in Auto-scaler, so that the external
components could provide/insert information that matters the decision of
scaling up/down, depending on the algorithm used.

Normally that service returns integer value(let say 0 to 10) and we can get
> some idea about load from that. When it comes to traffic route we will give
> high priority to server with minimum load and so on. So that type of
> implementation would be ideal for this case as well. Synapse member
> selection algorithm can be configurable and we can add new algorithm for
> this if need.
>

This is an extension point, one could leverage.

>
>>    - TCP level load balance.
>>
>> Current we only doing http/https based load balancing but need to expand
>> this to do TCP level load balancing.
>>
>> This would be again nice feature IMO. Also i think we need considerable
> amount of synapse transport level improvements to implement this. WDYT?
>

We may require to write a TCP load balance endpoint, if one is not already
available (I couldn't find any reference).

>
>>    - Health monitoring
>>
>> Current release we haven't much in the cartridge heath monitoring but its
>> very important and need to have in the future release.
>>
>> If we implemented above mentioned load average calculation mechanism then
> we can do this easily.
>

Yes, health monitor would ideally consider the load average of the
Cartridge instances, memory consumption etc. and transit the state
according to a pre-defined curriculum, IMO.

We can call that end point and get whatever we need. Also it would be ideal
> if we can have some simple user interface for load balancer to view active
> services and subscribed nodes and their status. Or else we can use cluster
> message and set status of server as member attribute.
>

> Also i would like to suggest static load balance endpoint support for load
> balancer(as a suggestion). Let say some user have fixed set of back end
> servers and need to route traffic to them through load balancer. That would
> be useful feature and we can consider it when we design milestone plan.
>

I'm afraid this won't be a use-case when you consider Apache Stratos.
Apache Stratos is a fully dynamic environment i.e. all the clusters get
build, as and when required. We don't have a concept call static endpoints
in the context of Stratos.

Sample configuration would be as follows(It tells everything about
> implementation). Sometimes back me and azeez had offline discussion about
> this.
>
>    TestService {
>     hosts       server.test.com;
>     servers   {
>             server1 {
>                 ip = 192.0.0.1;
>                 http = 80;
>                 https = 443;
>             }
>
>             server2 {
>                 ip = 192.0.0.2;
>                 http = 80;
>                 https = 443;
>             }
>       }
>     }
>
>>
>>    - Improving ADC (Artifact Distribution Coordinator)
>>
>> Current release we only support git based artifact distribution and need
>> to provide more scalable deployment options
>>
>>
>>    - Light weight cartridge agent
>>
>> Current load balancer used tribes based clustering. To support tribes
>> clustering we have to use java based cartridge agent and it will put some
>> unnecessary heavy load to non java cartridges like PHP. If we can moved to
>> Hazelcast Clustering we can have python based light weight cartridge agent
>> across all type of cartridges.
>>
>>
>>    - Adding more and more cartridges
>>
>> We can have more and more cartridges like Python, Ruby, Node.js, Mongo
>> etc.
>>
>>
>> thanks
>>
>> [1]
>> http://lakmalsview.blogspot.com/2013/06/wso2-stratos-200-is-released.html
>> [2]
>> http://docs.wso2.org/wiki/display/Stratos200/WSO2+Stratos+Documentation
>>
>>
>> --
>> Lakmal Warusawithana
>> Software Architect; WSO2 Inc.
>> Mobile : +94714289692
>> Blog : http://lakmalsview.blogspot.com/
>>
>>
>
>
> --
>
> *Sanjeewa Malalgoda
> **B.Sc. Engineering(Hons)
> Dip. in Com.Sc.
> AMIESL , MIACSIT, CCNA
>
> *
> Mobile +94713068779
>
> http://sanjeewamalalgoda.blogspot.com/
>



-- 
Best Regards,
Nirmal

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

Blog: http://nirmalfdo.blogspot.com/

Mime
View raw message