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.

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.

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

Reply via email to