You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Imesh Gunaratne <im...@apache.org> on 2014/11/24 09:17:37 UTC
[Discuss] Group Scaling & Dependent Scaling Behaviours
Hi Devs,
This is to discuss $subject. I spent some time analyzing the on going
development efforts on this and thought we could discuss different types of
scaling behaviours we have now and summarize them. As I understood there
are two main types of scaling behaviours which have been introduced with
service grouping, please correct me if I have misunderstood.
*1. Group Scaling*
*-----------------------------*
If a group of services requires to maintain a dependent ratio between
services and create an instance of the group on each autoscaling iteration
we could use this approach. Please refer below diagram:
The above diagram shows a composite application where it has a group
containing two cartridges and enabled group scaling. The table illustrates
four autoscaling iterations. Here we can identify group instances created
at each autoscaling iteration as a separate set (G1-1, G1-2, G1-3, G1-4).
The key feature of this model is that it could create another level of
isolation within a cluster if required by the application.
*Dependency requirement:*
In this example a dependency has been defined as C2 -> C1. This says that
if there are 'n' number of instances available from C2, there should be '2
x n' instances in C1 (according to minimum instance counts).
*Scaling up logic:*
Autoscaler's scaling up rule will first detect the requirement for scaling
up decision for a given service, based on the threshold values defined and
the statistics retrieved from CEP. Then it will predict the number of
instances needed for the above service and calculate number of group
instances needed to handle this load:
For an example if a high load was detected in service C1 following
calculation will be done:
Predicted number of instances for service C1 = 10
Minimum number of instances required = 2
Number of group instances required: 10/2 = 5
Assuming the above sample, autoscaler will create 5 new group instances
having both C1 and C2 services with their corresponding minimum instance
counts.
*Scaling down logic:*
Similar to the scaling up logic here autoscaler's scaling down rule will
detect the requirement for scaling down by comparing the predicted value
with the available number of group instances. If more resources are
available it will remove group instances one by one periodically.
For an example if the load detected in service C1 is as follows:
Predicted number of instances for service C1 = 6
Number of running group instances = 8
Number of required group instances = 6/2 = 3
Extra group instances found = 8 - 3 = 5
Now there are 5 extra group instances available. To adhere to "scale down
slowly" concept, autoscaler will remove group instances at each iteration
rather than removing them once.
*2. Dependent Scaling*
*----------------------------------*
The main difference between Group Scaling and Dependent Scaling is that we
will not create a group instance if Dependent Scaling is enabled for a
group. Rather at each autoscaling iteration the predicted number of
instances will be created for each service cluster. Moreover if a
dependency is found the dependent cluster will also be autoscaled.
*Scaling up logic:*
Scenario A:
For an example if a high load was detected in service C2 following
calculation will be done:
Predicted number of instances for service C2 = 4
Here autoscaler will create 4 instances of service C2 and 8 instances of C1
(according to the dependency rule C2 : C1 = 1 : 2).
Scenario B:
For an example if a high load was detected in service C1 following
calculation will be done:
Predicted number of instances of service C1 = 2
There will be 2 instances created for service C1 but no instances will be
created for service C2. The reason is that there is no dependency defined
as C1 -> C2.
*Scaling down logic:*
Scenario A:
For an example if the load detected in service C2 is as follows:
Predicted number of instances for service C2 = 5
Number of running instances of service C2 = 8
Extra number of instances found in service C2 = 8 - 5 = 3
Number of C1 instances required for 5 C2 instances = 10
Number of running instance of service C1 = 11
Extra number of instances found in service C1 = 11 - 10 = 1
Here there are 3 extra instances of service C2 and 1 extra instance in
service C1. To adhere to "scale down slowly" concept, autoscaler will
remove instances one by one at each iteration rather than removing them
once. In first iteration it will remove one instance of C1 and one instance
of C2.
Scenario B:
For an example if the load detected in service C1 is as follows:
Predicted number of instances for service C1: 6
Number of running instances of service C1: 10
Extra number of instances found: 10 - 6 = 4
Here there are 4 extra C1 instances available. To adhere to "scale down
slowly" concept, autoscaler will remove instances one by one at each
iteration rather than removing them once.
Thanks
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: [Discuss] Group Scaling & Dependent Scaling Behaviours
Posted by "Matt Turner (matttur)" <ma...@cisco.com>.
I agree; this is also my understanding of the specification.
To paraphrase: Scaling works as per currently, with the different that when a subscription / cluster reaches its maximum, rather then stop, it “overflows” into a new instance of its containing group (which starts with the minimum number of all member cartridges). I also don’t recall any discussion of using the dependency graph for autoscaling.
Note that if you implement Group Scaling as we (and I believe the spec) describes it, you get your version of Group Scaling for free. It’s a degenerate form of what we’re describing; just set each cluster’s min == max.
Hope this helps,
matt
On 24/11/2014 10:53, "Shaheedur Haque (shahhaqu)" <sh...@cisco.com>> wrote:
Hi Imesh,
Thanks for the writeup, most helpful. I want to draw one thing to your attention…
In the original spec, I was thinking of a slightly different distinction between the Group Scaling and the Dependent Scaling modes (to use your terms). To me, the dependency concept is strictly to do with startup ordering (and failure handling). Thus to say that C2 depends on C1 ONLY governs the behaviour that C1 must be up before C2 comes up.
To distinguish between the scaling modes, which I think of Group Scaling and Normal Scaling, I had it in mind that the model should be:
· By default, the ratio is determined by the “min” values.
o The ratio controls the number of instances of each cartridge required when the group first starts only.
o Later, we might add other choices, but this seems like a sensible place to start.
· Normal scaling proceeds on a per-cartridge type basis (or per subscription, if the recent discussions about aliased subscriptions are implemented) till the “max” is reached for any type (or subscription) in the group.
· Group Scaling is triggered when the “max” would otherwise be exceeded.
To me, this seems like a much more natural evolution of the current Stratos “Normal Scaling” model.
WDYT?
Thanks, Shaheed
From: Imesh Gunaratne [mailto:imesh@apache.org]
Sent: 24 November 2014 08:18
To: dev
Subject: [Discuss] Group Scaling & Dependent Scaling Behaviours
Hi Devs,
This is to discuss $subject. I spent some time analyzing the on going development efforts on this and thought we could discuss different types of scaling behaviours we have now and summarize them. As I understood there are two main types of scaling behaviours which have been introduced with service grouping, please correct me if I have misunderstood.
1. Group Scaling
-----------------------------
If a group of services requires to maintain a dependent ratio between services and create an instance of the group on each autoscaling iteration we could use this approach. Please refer below diagram:
[cid:image002.png@01D007D4.D78C4620]
The above diagram shows a composite application where it has a group containing two cartridges and enabled group scaling. The table illustrates four autoscaling iterations. Here we can identify group instances created at each autoscaling iteration as a separate set (G1-1, G1-2, G1-3, G1-4). The key feature of this model is that it could create another level of isolation within a cluster if required by the application.
Dependency requirement:
In this example a dependency has been defined as C2 -> C1. This says that if there are 'n' number of instances available from C2, there should be '2 x n' instances in C1 (according to minimum instance counts).
Scaling up logic:
Autoscaler's scaling up rule will first detect the requirement for scaling up decision for a given service, based on the threshold values defined and the statistics retrieved from CEP. Then it will predict the number of instances needed for the above service and calculate number of group instances needed to handle this load:
For an example if a high load was detected in service C1 following calculation will be done:
Predicted number of instances for service C1 = 10
Minimum number of instances required = 2
Number of group instances required: 10/2 = 5
Assuming the above sample, autoscaler will create 5 new group instances having both C1 and C2 services with their corresponding minimum instance counts.
Scaling down logic:
Similar to the scaling up logic here autoscaler's scaling down rule will detect the requirement for scaling down by comparing the predicted value with the available number of group instances. If more resources are available it will remove group instances one by one periodically.
For an example if the load detected in service C1 is as follows:
Predicted number of instances for service C1 = 6
Number of running group instances = 8
Number of required group instances = 6/2 = 3
Extra group instances found = 8 - 3 = 5
Now there are 5 extra group instances available. To adhere to "scale down slowly" concept, autoscaler will remove group instances at each iteration rather than removing them once.
2. Dependent Scaling
----------------------------------
[cid:image004.png@01D007D4.D78C4620]
The main difference between Group Scaling and Dependent Scaling is that we will not create a group instance if Dependent Scaling is enabled for a group. Rather at each autoscaling iteration the predicted number of instances will be created for each service cluster. Moreover if a dependency is found the dependent cluster will also be autoscaled.
Scaling up logic:
Scenario A:
For an example if a high load was detected in service C2 following calculation will be done:
Predicted number of instances for service C2 = 4
Here autoscaler will create 4 instances of service C2 and 8 instances of C1 (according to the dependency rule C2 : C1 = 1 : 2).
Scenario B:
For an example if a high load was detected in service C1 following calculation will be done:
Predicted number of instances of service C1 = 2
There will be 2 instances created for service C1 but no instances will be created for service C2. The reason is that there is no dependency defined as C1 -> C2.
Scaling down logic:
Scenario A:
For an example if the load detected in service C2 is as follows:
Predicted number of instances for service C2 = 5
Number of running instances of service C2 = 8
Extra number of instances found in service C2 = 8 - 5 = 3
Number of C1 instances required for 5 C2 instances = 10
Number of running instance of service C1 = 11
Extra number of instances found in service C1 = 11 - 10 = 1
Here there are 3 extra instances of service C2 and 1 extra instance in service C1. To adhere to "scale down slowly" concept, autoscaler will remove instances one by one at each iteration rather than removing them once. In first iteration it will remove one instance of C1 and one instance of C2.
Scenario B:
For an example if the load detected in service C1 is as follows:
Predicted number of instances for service C1: 6
Number of running instances of service C1: 10
Extra number of instances found: 10 - 6 = 4
Here there are 4 extra C1 instances available. To adhere to "scale down slowly" concept, autoscaler will remove instances one by one at each iteration rather than removing them once.
Thanks
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: [Discuss] Group Scaling & Dependent Scaling Behaviours
Posted by Imesh Gunaratne <im...@apache.org>.
+1 for the suggestion to scale up a group instance up to its maximum limit
and then to create another group instance to handle the additional load (if
group scaling is enabled). I think that make more sense than creating
multiple group instances with minimum counts.
Thanks
On Tue, Nov 25, 2014 at 1:38 PM, Lakmal Warusawithana <la...@wso2.com>
wrote:
> Thanks folks for the feedbacks. IMO we can simply support individual
> scaling up-to define max, within the scaling enable group. When ever one of
> individual group member reach out its max, if group scaling enable, it will
> scale by group. For scale down, all individual members scaled down below
> the define max, group level scale down take place.
>
> On Tue, Nov 25, 2014 at 6:03 AM, Martin Eppel (meppel) <me...@cisco.com>
> wrote:
>
>> Hi Shaheed, Matt, Imesh, Lakmal
>>
>>
>>
>> I think the proposed group scaling is going to satisfy the immediate
>> requirements and considering the tight schedule for 4.1 I wonder if it
>> would make sense to focus on its delivery while continue the discussions
>> around member scaling (as proposed in the specification) and respectively
>> dependency scaling as proposed in the email thread, WDYT ?
>>
>>
>>
>> Regards
>>
>>
>>
>> Martin
>>
>>
>>
>> *From:* Shaheedur Haque (shahhaqu)
>> *Sent:* Monday, November 24, 2014 2:53 AM
>> *To:* dev@stratos.apache.org
>> *Subject:* RE: [Discuss] Group Scaling & Dependent Scaling Behaviours
>>
>>
>>
>> Hi Imesh,
>>
>>
>>
>> Thanks for the writeup, most helpful. I want to draw one thing to your
>> attention…
>>
>>
>>
>> In the original spec, I was thinking of a slightly different distinction
>> between the Group Scaling and the Dependent Scaling modes (to use your
>> terms). To me, the dependency concept is strictly to do with startup
>> ordering (and failure handling). Thus to say that C2 depends on C1 ONLY
>> governs the behaviour that C1 must be up before C2 comes up.
>>
>>
>>
>> To distinguish between the scaling modes, which I think of Group Scaling
>> and Normal Scaling, I had it in mind that the model should be:
>>
>>
>>
>> · By default, the ratio is determined by the “min” values.
>>
>> o The ratio controls the number of instances of each cartridge
>> required when the group first starts only.
>>
>> o Later, we might add other choices, but this seems like a sensible
>> place to start.
>>
>> · Normal scaling proceeds on a per-cartridge type basis (or per
>> subscription, if the recent discussions about aliased subscriptions are
>> implemented) till the “max” is reached for any type (or subscription) in
>> the group.
>>
>> · Group Scaling is triggered when the “max” would otherwise be
>> exceeded.
>>
>>
>>
>> To me, this seems like a much more natural evolution of the current
>> Stratos “Normal Scaling” model.
>>
>>
>>
>> WDYT?
>>
>>
>>
>> Thanks, Shaheed
>>
>>
>>
>> *From:* Imesh Gunaratne [mailto:imesh@apache.org <im...@apache.org>]
>> *Sent:* 24 November 2014 08:18
>> *To:* dev
>> *Subject:* [Discuss] Group Scaling & Dependent Scaling Behaviours
>>
>>
>>
>> Hi Devs,
>>
>>
>>
>> This is to discuss $subject. I spent some time analyzing the on going
>> development efforts on this and thought we could discuss different types of
>> scaling behaviours we have now and summarize them. As I understood there
>> are two main types of scaling behaviours which have been introduced with
>> service grouping, please correct me if I have misunderstood.
>>
>>
>>
>> *1. Group Scaling*
>>
>> *-----------------------------*
>>
>> If a group of services requires to maintain a dependent ratio between
>> services and create an instance of the group on each autoscaling iteration
>> we could use this approach. Please refer below diagram:
>>
>>
>>
>> The above diagram shows a composite application where it has a group
>> containing two cartridges and enabled group scaling. The table illustrates
>> four autoscaling iterations. Here we can identify group instances created
>> at each autoscaling iteration as a separate set (G1-1, G1-2, G1-3, G1-4).
>> The key feature of this model is that it could create another level of
>> isolation within a cluster if required by the application.
>>
>>
>>
>> *Dependency requirement:*
>>
>>
>>
>> In this example a dependency has been defined as C2 -> C1. This says that
>> if there are 'n' number of instances available from C2, there should be '2
>> x n' instances in C1 (according to minimum instance counts).
>>
>>
>>
>> *Scaling up logic:*
>>
>>
>>
>> Autoscaler's scaling up rule will first detect the requirement for
>> scaling up decision for a given service, based on the threshold values
>> defined and the statistics retrieved from CEP. Then it will predict the
>> number of instances needed for the above service and calculate number of
>> group instances needed to handle this load:
>>
>>
>>
>> For an example if a high load was detected in service C1 following
>> calculation will be done:
>>
>> Predicted number of instances for service C1 = 10
>>
>> Minimum number of instances required = 2
>>
>> Number of group instances required: 10/2 = 5
>>
>>
>>
>> Assuming the above sample, autoscaler will create 5 new group instances
>> having both C1 and C2 services with their corresponding minimum instance
>> counts.
>>
>>
>>
>> *Scaling down logic:*
>>
>>
>>
>> Similar to the scaling up logic here autoscaler's scaling down rule will
>> detect the requirement for scaling down by comparing the predicted value
>> with the available number of group instances. If more resources are
>> available it will remove group instances one by one periodically.
>>
>>
>>
>> For an example if the load detected in service C1 is as follows:
>>
>> Predicted number of instances for service C1 = 6
>>
>> Number of running group instances = 8
>>
>> Number of required group instances = 6/2 = 3
>>
>> Extra group instances found = 8 - 3 = 5
>>
>>
>>
>> Now there are 5 extra group instances available. To adhere to "scale down
>> slowly" concept, autoscaler will remove group instances at each iteration
>> rather than removing them once.
>>
>>
>>
>> *2. Dependent Scaling*
>>
>> *----------------------------------*
>>
>>
>>
>>
>> The main difference between Group Scaling and Dependent Scaling is that
>> we will not create a group instance if Dependent Scaling is enabled for a
>> group. Rather at each autoscaling iteration the predicted number of
>> instances will be created for each service cluster. Moreover if a
>> dependency is found the dependent cluster will also be autoscaled.
>>
>>
>>
>> *Scaling up logic:*
>>
>>
>>
>> Scenario A:
>>
>> For an example if a high load was detected in service C2 following
>> calculation will be done:
>>
>> Predicted number of instances for service C2 = 4
>>
>>
>>
>> Here autoscaler will create 4 instances of service C2 and 8 instances of
>> C1 (according to the dependency rule C2 : C1 = 1 : 2).
>>
>>
>>
>> Scenario B:
>>
>> For an example if a high load was detected in service C1 following
>> calculation will be done:
>>
>> Predicted number of instances of service C1 = 2
>>
>> There will be 2 instances created for service C1 but no instances will be
>> created for service C2. The reason is that there is no dependency defined
>> as C1 -> C2.
>>
>>
>>
>> *Scaling down logic:*
>>
>>
>>
>> Scenario A:
>>
>> For an example if the load detected in service C2 is as follows:
>>
>> Predicted number of instances for service C2 = 5
>>
>> Number of running instances of service C2 = 8
>>
>> Extra number of instances found in service C2 = 8 - 5 = 3
>>
>>
>>
>> Number of C1 instances required for 5 C2 instances = 10
>>
>> Number of running instance of service C1 = 11
>>
>> Extra number of instances found in service C1 = 11 - 10 = 1
>>
>>
>>
>> Here there are 3 extra instances of service C2 and 1 extra instance in
>> service C1. To adhere to "scale down slowly" concept, autoscaler will
>> remove instances one by one at each iteration rather than removing them
>> once. In first iteration it will remove one instance of C1 and one instance
>> of C2.
>>
>>
>>
>> Scenario B:
>>
>> For an example if the load detected in service C1 is as follows:
>>
>> Predicted number of instances for service C1: 6
>>
>> Number of running instances of service C1: 10
>>
>> Extra number of instances found: 10 - 6 = 4
>>
>>
>>
>> Here there are 4 extra C1 instances available. To adhere to "scale down
>> slowly" concept, autoscaler will remove instances one by one at each
>> iteration rather than removing them once.
>>
>>
>>
>>
>>
>> Thanks
>>
>>
>>
>>
>> --
>>
>> Imesh Gunaratne
>>
>>
>>
>> Technical Lead, WSO2
>>
>> Committer & PMC Member, Apache Stratos
>>
>
>
>
> --
> Lakmal Warusawithana
> Vice President, Apache Stratos
> Director - Cloud Architecture; WSO2 Inc.
> Mobile : +94714289692
> Blog : http://lakmalsview.blogspot.com/
>
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: [Discuss] Group Scaling & Dependent Scaling Behaviours
Posted by Lakmal Warusawithana <la...@wso2.com>.
Thanks folks for the feedbacks. IMO we can simply support individual
scaling up-to define max, within the scaling enable group. When ever one of
individual group member reach out its max, if group scaling enable, it will
scale by group. For scale down, all individual members scaled down below
the define max, group level scale down take place.
On Tue, Nov 25, 2014 at 6:03 AM, Martin Eppel (meppel) <me...@cisco.com>
wrote:
> Hi Shaheed, Matt, Imesh, Lakmal
>
>
>
> I think the proposed group scaling is going to satisfy the immediate
> requirements and considering the tight schedule for 4.1 I wonder if it
> would make sense to focus on its delivery while continue the discussions
> around member scaling (as proposed in the specification) and respectively
> dependency scaling as proposed in the email thread, WDYT ?
>
>
>
> Regards
>
>
>
> Martin
>
>
>
> *From:* Shaheedur Haque (shahhaqu)
> *Sent:* Monday, November 24, 2014 2:53 AM
> *To:* dev@stratos.apache.org
> *Subject:* RE: [Discuss] Group Scaling & Dependent Scaling Behaviours
>
>
>
> Hi Imesh,
>
>
>
> Thanks for the writeup, most helpful. I want to draw one thing to your
> attention…
>
>
>
> In the original spec, I was thinking of a slightly different distinction
> between the Group Scaling and the Dependent Scaling modes (to use your
> terms). To me, the dependency concept is strictly to do with startup
> ordering (and failure handling). Thus to say that C2 depends on C1 ONLY
> governs the behaviour that C1 must be up before C2 comes up.
>
>
>
> To distinguish between the scaling modes, which I think of Group Scaling
> and Normal Scaling, I had it in mind that the model should be:
>
>
>
> · By default, the ratio is determined by the “min” values.
>
> o The ratio controls the number of instances of each cartridge required
> when the group first starts only.
>
> o Later, we might add other choices, but this seems like a sensible
> place to start.
>
> · Normal scaling proceeds on a per-cartridge type basis (or per
> subscription, if the recent discussions about aliased subscriptions are
> implemented) till the “max” is reached for any type (or subscription) in
> the group.
>
> · Group Scaling is triggered when the “max” would otherwise be
> exceeded.
>
>
>
> To me, this seems like a much more natural evolution of the current
> Stratos “Normal Scaling” model.
>
>
>
> WDYT?
>
>
>
> Thanks, Shaheed
>
>
>
> *From:* Imesh Gunaratne [mailto:imesh@apache.org <im...@apache.org>]
> *Sent:* 24 November 2014 08:18
> *To:* dev
> *Subject:* [Discuss] Group Scaling & Dependent Scaling Behaviours
>
>
>
> Hi Devs,
>
>
>
> This is to discuss $subject. I spent some time analyzing the on going
> development efforts on this and thought we could discuss different types of
> scaling behaviours we have now and summarize them. As I understood there
> are two main types of scaling behaviours which have been introduced with
> service grouping, please correct me if I have misunderstood.
>
>
>
> *1. Group Scaling*
>
> *-----------------------------*
>
> If a group of services requires to maintain a dependent ratio between
> services and create an instance of the group on each autoscaling iteration
> we could use this approach. Please refer below diagram:
>
>
>
> The above diagram shows a composite application where it has a group
> containing two cartridges and enabled group scaling. The table illustrates
> four autoscaling iterations. Here we can identify group instances created
> at each autoscaling iteration as a separate set (G1-1, G1-2, G1-3, G1-4).
> The key feature of this model is that it could create another level of
> isolation within a cluster if required by the application.
>
>
>
> *Dependency requirement:*
>
>
>
> In this example a dependency has been defined as C2 -> C1. This says that
> if there are 'n' number of instances available from C2, there should be '2
> x n' instances in C1 (according to minimum instance counts).
>
>
>
> *Scaling up logic:*
>
>
>
> Autoscaler's scaling up rule will first detect the requirement for scaling
> up decision for a given service, based on the threshold values defined and
> the statistics retrieved from CEP. Then it will predict the number of
> instances needed for the above service and calculate number of group
> instances needed to handle this load:
>
>
>
> For an example if a high load was detected in service C1 following
> calculation will be done:
>
> Predicted number of instances for service C1 = 10
>
> Minimum number of instances required = 2
>
> Number of group instances required: 10/2 = 5
>
>
>
> Assuming the above sample, autoscaler will create 5 new group instances
> having both C1 and C2 services with their corresponding minimum instance
> counts.
>
>
>
> *Scaling down logic:*
>
>
>
> Similar to the scaling up logic here autoscaler's scaling down rule will
> detect the requirement for scaling down by comparing the predicted value
> with the available number of group instances. If more resources are
> available it will remove group instances one by one periodically.
>
>
>
> For an example if the load detected in service C1 is as follows:
>
> Predicted number of instances for service C1 = 6
>
> Number of running group instances = 8
>
> Number of required group instances = 6/2 = 3
>
> Extra group instances found = 8 - 3 = 5
>
>
>
> Now there are 5 extra group instances available. To adhere to "scale down
> slowly" concept, autoscaler will remove group instances at each iteration
> rather than removing them once.
>
>
>
> *2. Dependent Scaling*
>
> *----------------------------------*
>
>
>
>
> The main difference between Group Scaling and Dependent Scaling is that
> we will not create a group instance if Dependent Scaling is enabled for a
> group. Rather at each autoscaling iteration the predicted number of
> instances will be created for each service cluster. Moreover if a
> dependency is found the dependent cluster will also be autoscaled.
>
>
>
> *Scaling up logic:*
>
>
>
> Scenario A:
>
> For an example if a high load was detected in service C2 following
> calculation will be done:
>
> Predicted number of instances for service C2 = 4
>
>
>
> Here autoscaler will create 4 instances of service C2 and 8 instances of
> C1 (according to the dependency rule C2 : C1 = 1 : 2).
>
>
>
> Scenario B:
>
> For an example if a high load was detected in service C1 following
> calculation will be done:
>
> Predicted number of instances of service C1 = 2
>
> There will be 2 instances created for service C1 but no instances will be
> created for service C2. The reason is that there is no dependency defined
> as C1 -> C2.
>
>
>
> *Scaling down logic:*
>
>
>
> Scenario A:
>
> For an example if the load detected in service C2 is as follows:
>
> Predicted number of instances for service C2 = 5
>
> Number of running instances of service C2 = 8
>
> Extra number of instances found in service C2 = 8 - 5 = 3
>
>
>
> Number of C1 instances required for 5 C2 instances = 10
>
> Number of running instance of service C1 = 11
>
> Extra number of instances found in service C1 = 11 - 10 = 1
>
>
>
> Here there are 3 extra instances of service C2 and 1 extra instance in
> service C1. To adhere to "scale down slowly" concept, autoscaler will
> remove instances one by one at each iteration rather than removing them
> once. In first iteration it will remove one instance of C1 and one instance
> of C2.
>
>
>
> Scenario B:
>
> For an example if the load detected in service C1 is as follows:
>
> Predicted number of instances for service C1: 6
>
> Number of running instances of service C1: 10
>
> Extra number of instances found: 10 - 6 = 4
>
>
>
> Here there are 4 extra C1 instances available. To adhere to "scale down
> slowly" concept, autoscaler will remove instances one by one at each
> iteration rather than removing them once.
>
>
>
>
>
> Thanks
>
>
>
>
> --
>
> Imesh Gunaratne
>
>
>
> Technical Lead, WSO2
>
> Committer & PMC Member, Apache Stratos
>
--
Lakmal Warusawithana
Vice President, Apache Stratos
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
RE: [Discuss] Group Scaling & Dependent Scaling Behaviours
Posted by "Martin Eppel (meppel)" <me...@cisco.com>.
Hi Shaheed, Matt, Imesh, Lakmal
I think the proposed group scaling is going to satisfy the immediate requirements and considering the tight schedule for 4.1 I wonder if it would make sense to focus on its delivery while continue the discussions around member scaling (as proposed in the specification) and respectively dependency scaling as proposed in the email thread, WDYT ?
Regards
Martin
From: Shaheedur Haque (shahhaqu)
Sent: Monday, November 24, 2014 2:53 AM
To: dev@stratos.apache.org
Subject: RE: [Discuss] Group Scaling & Dependent Scaling Behaviours
Hi Imesh,
Thanks for the writeup, most helpful. I want to draw one thing to your attention…
In the original spec, I was thinking of a slightly different distinction between the Group Scaling and the Dependent Scaling modes (to use your terms). To me, the dependency concept is strictly to do with startup ordering (and failure handling). Thus to say that C2 depends on C1 ONLY governs the behaviour that C1 must be up before C2 comes up.
To distinguish between the scaling modes, which I think of Group Scaling and Normal Scaling, I had it in mind that the model should be:
· By default, the ratio is determined by the “min” values.
o The ratio controls the number of instances of each cartridge required when the group first starts only.
o Later, we might add other choices, but this seems like a sensible place to start.
· Normal scaling proceeds on a per-cartridge type basis (or per subscription, if the recent discussions about aliased subscriptions are implemented) till the “max” is reached for any type (or subscription) in the group.
· Group Scaling is triggered when the “max” would otherwise be exceeded.
To me, this seems like a much more natural evolution of the current Stratos “Normal Scaling” model.
WDYT?
Thanks, Shaheed
From: Imesh Gunaratne [mailto:imesh@apache.org]
Sent: 24 November 2014 08:18
To: dev
Subject: [Discuss] Group Scaling & Dependent Scaling Behaviours
Hi Devs,
This is to discuss $subject. I spent some time analyzing the on going development efforts on this and thought we could discuss different types of scaling behaviours we have now and summarize them. As I understood there are two main types of scaling behaviours which have been introduced with service grouping, please correct me if I have misunderstood.
1. Group Scaling
-----------------------------
If a group of services requires to maintain a dependent ratio between services and create an instance of the group on each autoscaling iteration we could use this approach. Please refer below diagram:
[cid:image001.png@01D00803.D77B23C0]
The above diagram shows a composite application where it has a group containing two cartridges and enabled group scaling. The table illustrates four autoscaling iterations. Here we can identify group instances created at each autoscaling iteration as a separate set (G1-1, G1-2, G1-3, G1-4). The key feature of this model is that it could create another level of isolation within a cluster if required by the application.
Dependency requirement:
In this example a dependency has been defined as C2 -> C1. This says that if there are 'n' number of instances available from C2, there should be '2 x n' instances in C1 (according to minimum instance counts).
Scaling up logic:
Autoscaler's scaling up rule will first detect the requirement for scaling up decision for a given service, based on the threshold values defined and the statistics retrieved from CEP. Then it will predict the number of instances needed for the above service and calculate number of group instances needed to handle this load:
For an example if a high load was detected in service C1 following calculation will be done:
Predicted number of instances for service C1 = 10
Minimum number of instances required = 2
Number of group instances required: 10/2 = 5
Assuming the above sample, autoscaler will create 5 new group instances having both C1 and C2 services with their corresponding minimum instance counts.
Scaling down logic:
Similar to the scaling up logic here autoscaler's scaling down rule will detect the requirement for scaling down by comparing the predicted value with the available number of group instances. If more resources are available it will remove group instances one by one periodically.
For an example if the load detected in service C1 is as follows:
Predicted number of instances for service C1 = 6
Number of running group instances = 8
Number of required group instances = 6/2 = 3
Extra group instances found = 8 - 3 = 5
Now there are 5 extra group instances available. To adhere to "scale down slowly" concept, autoscaler will remove group instances at each iteration rather than removing them once.
2. Dependent Scaling
----------------------------------
[cid:image002.png@01D00803.D77B23C0]
The main difference between Group Scaling and Dependent Scaling is that we will not create a group instance if Dependent Scaling is enabled for a group. Rather at each autoscaling iteration the predicted number of instances will be created for each service cluster. Moreover if a dependency is found the dependent cluster will also be autoscaled.
Scaling up logic:
Scenario A:
For an example if a high load was detected in service C2 following calculation will be done:
Predicted number of instances for service C2 = 4
Here autoscaler will create 4 instances of service C2 and 8 instances of C1 (according to the dependency rule C2 : C1 = 1 : 2).
Scenario B:
For an example if a high load was detected in service C1 following calculation will be done:
Predicted number of instances of service C1 = 2
There will be 2 instances created for service C1 but no instances will be created for service C2. The reason is that there is no dependency defined as C1 -> C2.
Scaling down logic:
Scenario A:
For an example if the load detected in service C2 is as follows:
Predicted number of instances for service C2 = 5
Number of running instances of service C2 = 8
Extra number of instances found in service C2 = 8 - 5 = 3
Number of C1 instances required for 5 C2 instances = 10
Number of running instance of service C1 = 11
Extra number of instances found in service C1 = 11 - 10 = 1
Here there are 3 extra instances of service C2 and 1 extra instance in service C1. To adhere to "scale down slowly" concept, autoscaler will remove instances one by one at each iteration rather than removing them once. In first iteration it will remove one instance of C1 and one instance of C2.
Scenario B:
For an example if the load detected in service C1 is as follows:
Predicted number of instances for service C1: 6
Number of running instances of service C1: 10
Extra number of instances found: 10 - 6 = 4
Here there are 4 extra C1 instances available. To adhere to "scale down slowly" concept, autoscaler will remove instances one by one at each iteration rather than removing them once.
Thanks
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
RE: [Discuss] Group Scaling & Dependent Scaling Behaviours
Posted by "Shaheedur Haque (shahhaqu)" <sh...@cisco.com>.
Hi Imesh,
Thanks for the writeup, most helpful. I want to draw one thing to your attention…
In the original spec, I was thinking of a slightly different distinction between the Group Scaling and the Dependent Scaling modes (to use your terms). To me, the dependency concept is strictly to do with startup ordering (and failure handling). Thus to say that C2 depends on C1 ONLY governs the behaviour that C1 must be up before C2 comes up.
To distinguish between the scaling modes, which I think of Group Scaling and Normal Scaling, I had it in mind that the model should be:
· By default, the ratio is determined by the “min” values.
o The ratio controls the number of instances of each cartridge required when the group first starts only.
o Later, we might add other choices, but this seems like a sensible place to start.
· Normal scaling proceeds on a per-cartridge type basis (or per subscription, if the recent discussions about aliased subscriptions are implemented) till the “max” is reached for any type (or subscription) in the group.
· Group Scaling is triggered when the “max” would otherwise be exceeded.
To me, this seems like a much more natural evolution of the current Stratos “Normal Scaling” model.
WDYT?
Thanks, Shaheed
From: Imesh Gunaratne [mailto:imesh@apache.org]
Sent: 24 November 2014 08:18
To: dev
Subject: [Discuss] Group Scaling & Dependent Scaling Behaviours
Hi Devs,
This is to discuss $subject. I spent some time analyzing the on going development efforts on this and thought we could discuss different types of scaling behaviours we have now and summarize them. As I understood there are two main types of scaling behaviours which have been introduced with service grouping, please correct me if I have misunderstood.
1. Group Scaling
-----------------------------
If a group of services requires to maintain a dependent ratio between services and create an instance of the group on each autoscaling iteration we could use this approach. Please refer below diagram:
[cid:image002.png@01D007D4.D78C4620]
The above diagram shows a composite application where it has a group containing two cartridges and enabled group scaling. The table illustrates four autoscaling iterations. Here we can identify group instances created at each autoscaling iteration as a separate set (G1-1, G1-2, G1-3, G1-4). The key feature of this model is that it could create another level of isolation within a cluster if required by the application.
Dependency requirement:
In this example a dependency has been defined as C2 -> C1. This says that if there are 'n' number of instances available from C2, there should be '2 x n' instances in C1 (according to minimum instance counts).
Scaling up logic:
Autoscaler's scaling up rule will first detect the requirement for scaling up decision for a given service, based on the threshold values defined and the statistics retrieved from CEP. Then it will predict the number of instances needed for the above service and calculate number of group instances needed to handle this load:
For an example if a high load was detected in service C1 following calculation will be done:
Predicted number of instances for service C1 = 10
Minimum number of instances required = 2
Number of group instances required: 10/2 = 5
Assuming the above sample, autoscaler will create 5 new group instances having both C1 and C2 services with their corresponding minimum instance counts.
Scaling down logic:
Similar to the scaling up logic here autoscaler's scaling down rule will detect the requirement for scaling down by comparing the predicted value with the available number of group instances. If more resources are available it will remove group instances one by one periodically.
For an example if the load detected in service C1 is as follows:
Predicted number of instances for service C1 = 6
Number of running group instances = 8
Number of required group instances = 6/2 = 3
Extra group instances found = 8 - 3 = 5
Now there are 5 extra group instances available. To adhere to "scale down slowly" concept, autoscaler will remove group instances at each iteration rather than removing them once.
2. Dependent Scaling
----------------------------------
[cid:image004.png@01D007D4.D78C4620]
The main difference between Group Scaling and Dependent Scaling is that we will not create a group instance if Dependent Scaling is enabled for a group. Rather at each autoscaling iteration the predicted number of instances will be created for each service cluster. Moreover if a dependency is found the dependent cluster will also be autoscaled.
Scaling up logic:
Scenario A:
For an example if a high load was detected in service C2 following calculation will be done:
Predicted number of instances for service C2 = 4
Here autoscaler will create 4 instances of service C2 and 8 instances of C1 (according to the dependency rule C2 : C1 = 1 : 2).
Scenario B:
For an example if a high load was detected in service C1 following calculation will be done:
Predicted number of instances of service C1 = 2
There will be 2 instances created for service C1 but no instances will be created for service C2. The reason is that there is no dependency defined as C1 -> C2.
Scaling down logic:
Scenario A:
For an example if the load detected in service C2 is as follows:
Predicted number of instances for service C2 = 5
Number of running instances of service C2 = 8
Extra number of instances found in service C2 = 8 - 5 = 3
Number of C1 instances required for 5 C2 instances = 10
Number of running instance of service C1 = 11
Extra number of instances found in service C1 = 11 - 10 = 1
Here there are 3 extra instances of service C2 and 1 extra instance in service C1. To adhere to "scale down slowly" concept, autoscaler will remove instances one by one at each iteration rather than removing them once. In first iteration it will remove one instance of C1 and one instance of C2.
Scenario B:
For an example if the load detected in service C1 is as follows:
Predicted number of instances for service C1: 6
Number of running instances of service C1: 10
Extra number of instances found: 10 - 6 = 4
Here there are 4 extra C1 instances available. To adhere to "scale down slowly" concept, autoscaler will remove instances one by one at each iteration rather than removing them once.
Thanks
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos