Hi Martin, Sorry for the delay...Thanks for the re-sending it..I will go through it and update soon..
Thanks, Reka On Mon, Oct 6, 2014 at 1:09 AM, Martin Eppel (meppel) <mep...@cisco.com> wrote: > Resending it in case you missed it, > > > > Thanks > > > > Martin > > > > *From:* Martin Eppel (meppel) > *Sent:* Thursday, October 02, 2014 6:29 PM > *To:* 'Reka Thirunavukkarasu'; dev > *Cc:* Lakmal Warusawithana; Shaheedur Haque (shahhaqu); Isuru > Haththotuwa; Udara Liyanage > *Subject:* RE: [Discuss][Grouping] Handling Group level scaling in > Composite Application > > > > Hi Reka, > > > > See inline (“Martin:”) > > > > Thanks > > > > Martin > > > > *From:* Reka Thirunavukkarasu [mailto:r...@wso2.com <r...@wso2.com>] > *Sent:* Thursday, October 02, 2014 5:58 AM > *To:* dev > *Cc:* Lakmal Warusawithana; Shaheedur Haque (shahhaqu); Martin Eppel > (meppel); Isuru Haththotuwa; Udara Liyanage > *Subject:* [Discuss][Grouping] Handling Group level scaling in Composite > Application > > > > Hi > > > > This is to discuss $subject. In the case of scaling with composite > application, we can divide it into three parts as Martin has also explained > in previous mails. I summarise as below from a Martin's mail with the > proposed possible solution in stratos to support group level scaling: > > > > o scaling by statistics, > > o scaling by group member and > > o scaling by group. > > > > Based on this, the general algorithm would be like this (in order): > > 1. Scale VMs until the cluster maximum is reached (in at least one > of the cluster within the group - scale by statistics) > > We can address this in stratos with the usual autoscaling based on > statistics. A single cluster monitor is capable of taking this decision to > scale its own members. > > 2. Scale up a new cluster of same type as the one which has reached > the maximum of VMs until the max member number is reached (scale by group > member). > > If a cluster of a group reaches the max based on the deployment policy, > then if there is a room in the partition to spin more instances, we can > simply update the deployment policy of that cluster to increase the max > instances. If there are more than one cluster of the group resides in a > partition, we can divide the max instances of the partition among all of > those clusters by keeping a ratio among those clusters like 3C1:4C2. In > case, when the partition is max out, if we extend the partition with more > hardware, then again we can update the deployment policy with new > max values of those clusters. So that relevant cluster monitors will > execute with the updated values. > > “Martin:” is the max instance adjusted automatically by the autoscaler or > does it have to be done per “user” request ? > > 3. Scale up a new group instance of the same group type (or > definition), including all the respective dependencies (scale by group) > > We can achieve this by using combination of round-robin and > one-after-another algorithm in the deployment policy. For Eg: > > You can deploy a group(G1) which contains of C1 and C2 clusters in > partition P1 and P2 using round-robin algorithm. So that C1 and C1 will get > the high availability. You can have another idle partition called P3. When > you decided to scale by group, then using one-after-another algorithm in > deployment policy, we can choose the P3 to bring up the G1 with relevant > minimum instances. > > In that way, we can improve our deployment policy to support combination > of these algorithms within a network partition. When we have P1, P2 and P3 > in a network partition, we will be able to use round-robin among P1 and P2 > and we can use one-after-another among (P1, P2) and P3. > > “Martin:” I am not entirely sure I completely understand how this works > using the round robin algorithm and the partitioning, I think it would be > helpful to demonstrate the algorithm by using a more complex group with > multiple cartridges and nested sub groups, including the group id / > subscription alias generation, and event generation ? > A few more questions: > - when we spin up new instances of a group using the above mentioned > algorithm will it also subsequently scale all the respective dependencies ? > One of the main advantages of grouping (IMHO)) is that it scales up / down > not only a specific instance of a group but also subsequent dependencies > (cartridges and nested groups). > - For the new group instances, how will the group Id differ from the group > which is scaled, how would we generate group Ids ? > - How will the scale down work (or termination of a group and it’s > dependencies) ? > - What about group events, which event will be generated (e.g. group > active, group down, etc and what parameters like group name, group id, app > id ? > > Please share your thoughts on the above approach and Please add, if i > have missed any other points here.. > > > > Thanks, > > Reka > > > > -- > > Reka Thirunavukkarasu > Senior Software Engineer, > WSO2, Inc.:http://wso2.com, > > Mobile: +94776442007 > > > -- Reka Thirunavukkarasu Senior Software Engineer, WSO2, Inc.:http://wso2.com, Mobile: +94776442007
