On Mon, Jun 24, 2013 at 6:16 PM, Lakmal Warusawithana <[email protected]>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. 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.
>
> - 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?
>
> - 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. 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.
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/
