Hi Sanjeewa,
On Tue, Jun 25, 2013 at 12:15 PM, sanjeewa rangana <[email protected]>wrote: > > > > 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. > 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/
