stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shaheedur Haque (shahhaqu)" <shahh...@cisco.com>
Subject RE: [Discuss] Group Scaling & Dependent Scaling Behaviours
Date Mon, 24 Nov 2014 10:53:18 GMT
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
Mime
View raw message