<tt><font size=2>Huangtianhua <huangtianhua@huawei.com> wrote on
07/04/2014 02:35:56 AM:<br>
<br>
> I have register a bp about this : </font></tt><a href=https://blueprints.launchpad.net/><tt><font size=2>https://blueprints.launchpad.net/</font></tt></a><tt><font size=2><br>
> heat/+spec/implement-autoscalinggroup-availabilityzones</font></tt>
<br><tt><font size=2>> ¡¤ </font></tt>
<br><tt><font size=2>> ¡¤ And I am thinking
how to implement this recently.</font></tt>
<br><tt><font size=2>> ¡¤ </font></tt>
<br><tt><font size=2>> ¡¤ According to
AWS autoscaling implementation ¡°attempts to <br>
> distribute instances evenly between the Availability Zones that are
<br>
> enabled for your Auto Scaling group. </font></tt>
<br><tt><font size=2>> ¡¤ Auto Scaling
does this by attempting to launch new <br>
> instances in the Availability Zone with the fewest instances. If the<br>
> attempt fails, however, Auto Scaling will attempt to launch in other<br>
> zones until it succeeds.¡±</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> But there is a doubt about the ¡°fewest instance¡±,
.e.g </font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> There are two azs,</font></tt>
<br><tt><font size=2>> Az1: has two instances</font></tt>
<br><tt><font size=2>> Az2: has three instances</font></tt>
<br><tt><font size=2>> ¡¤ And
then to create a asg with 4 instances, I think we <br>
> should create two instances respectively in az1 and az2, right? Now
<br>
> if need to extend to 5 instances for the asg, which az to lauch new
instance?</font></tt>
<br><tt><font size=2>> If you interested in this bp, I think we can
discuss thisJ</font></tt>
<br>
<br><tt><font size=2>The way AWS handles this is described in </font></tt><a href="http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/AS_Concepts.html#arch-AutoScalingMultiAZ"><tt><font size=2>http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/AS_Concepts.html#arch-AutoScalingMultiAZ</font></tt></a>
<br>
<br><tt><font size=2>That document leaves a lot of freedom to the cloud
provider. And rightfully so, IMO. To answer your specific example,
when spreading 5 instances across 2 zones, the cloud provider gets to pick
which zone gets 3 and which zone gets 2. As for what a Heat scaling
group should do, that depends on what Nova can do for Heat. I have
been told that Nova's instance-creation operation takes an optional parameter
that identifies one AZ and, if that parameter is not provided, then a configured
default AZ is used. Effectively, the client has to make the choice.
I would start out with Heat making a random choice; in subsequent
development it might query or monitor Nova for some statistics to guide
the choice.</font></tt>
<br>
<br><tt><font size=2>An even more interesting issue is the question of
choosing which member(s) to remove when scaling down. The approach
taken by AWS </font></tt><font size=3>is documented at </font><a href="http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/us-termination-policy.html"><font size=3 color=blue><u>http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/us-termination-policy.html</u></font></a>
<p><font size=3>but the design there has redundant complexity and the doc
is not well written. Following is a short sharp presentation of an
isomorphic system.</font>
<p><font size=3>A client that owns an ASG configures that ASG to have a
series (possibly empty) of instance termination policies; the client can
change the series during the ASG's lifetime. Each policy is drawn
from the following menu:</font>
<ul>
<li><font size=3>OldestLaunchConfiguration</font>
<li><font size=3>ClosestToNextInstanceHour</font>
<li><font size=3>OldestInstance</font>
<li><font size=3>NewestInstance</font></ul><font size=3>(see the AWS doc
for the exact meaning of each). The signature of a policy is this:
given a set of candidate instances for removal, return a subset (possibly
the whole input set).</font>
<p><font size=3>When it is time to remove instances from an ASG, they are
chosen one by one. AWS uses the following procedure to choose one
instance to remove. </font>
<br><font size=2 face="sans-serif">1. </font><font size=3>Choose
the AZ from which the instance will be removed. The choice is based
primarily on balancing the number of group members in each AZ, and ties
are broken randomly.</font>
<br><font size=2 face="sans-serif">2. </font><font size=3>Starting
with a "candidate set" consisting of all the ASG's members in
the chosen AZ, run the configured series of policies to progressively narrow
down the set of candidates.</font>
<br><font size=2 face="sans-serif">3. </font><font size=3>Use
OldestLaunchConfiguration and then ClosestToNextInstanceHour to further
narrow the set of candidates.</font>
<br><font size=2 face="sans-serif">4. </font><font size=3>Make
a random choice among the final set of candidates.</font>
<p><font size=3>Since each policy returns its input when its input's size
is 1 we do not need to talk about early exits when defining the procedure
(although the implementation might make such optimizations).</font>
<p><font size=3>I plan to draft a spec.</font>
<p><font size=3>Thanks,</font>
<p><font size=3>Mike</font>
<p>
<p>