<tt><font size=2>Huangtianhua <huangtianhua@huawei.com> wrote on
07/09/2014 10:20:42 PM:<br>
<br>
> 发件人: Mike Spreitzer [</font></tt><a href=mailto:mspreitz@us.ibm.com><tt><font size=2>mailto:mspreitz@us.ibm.com</font></tt></a><tt><font size=2>]
<br>
> 发送时间: 2014年7月10日 3:19<br>
> 收件人: OpenStack Development Mailing List (not for usage questions)<br>
> 主题: Re: [openstack-dev] 答复: [heat] autoscaling across regions
<br>
> and availability zones</font></tt>
<br><tt><font size=2>>  </font></tt>
<br><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 <br>
> > ·           <br>
> > ·         And I am thinking how to implement
this recently. <br>
> > ·           <br>
> > ·         According to AWS autoscaling
implementation  “attempts to <br>
> > distribute instances evenly between the Availability Zones that
are <br>
> > enabled for your Auto Scaling group. <br>
> > ·         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.” <br>
> >   <br>
> > But there is a doubt about the “fewest instance”, .e.g <br>
> >   <br>
> > There are two azs, <br>
> >    Az1: has two instances <br>
> >    Az2: has three instances <br>
> > ·            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
<br>
> new instance? <br>
> > If you interested in this bp, I think we can discuss thisJ <br>
> <br>
> The way AWS handles this is described in </font></tt><a href=http://docs.aws.amazon.com/><tt><font size=2>http://docs.aws.amazon.com/</font></tt></a><tt><font size=2><br>
> AutoScaling/latest/DeveloperGuide/AS_Concepts.html#arch-AutoScalingMultiAZ
<br>
> <br>
> That document leaves a lot of freedom to the cloud provider.  And
<br>
> rightfully so, IMO.  To answer your specific example, when spreading<br>
> 5 instances across 2 zones, the cloud provider gets to pick which
<br>
> zone gets 3 and which zone gets 2.  As for what a Heat scaling
group<br>
> should do, that depends on what Nova can do for Heat.  I have
been <br>
> told that Nova's instance-creation operation takes an optional <br>
> parameter that identifies one AZ and, if that parameter is not <br>
> provided, then a configured default AZ is used.  Effectively,
the <br>
> client has to make the choice.  I would start out with Heat making
a<br>
> random choice; in subsequent development it might query or monitor
<br>
> Nova for some statistics to guide the choice. <br>
</font></tt>
<br><tt><font size=2>> --------yes, I read the doc, as you said, the
doc is not well <br>
> written, so I doubt about the “fewest instance” before, but now
IMO,<br>
> “fewest instance” means the instances of the group, so you are
<br>
> right, to my specific example, the instance should be launch at <br>
> random or in a round-robin mode.</font></tt>
<br><tt><font size=2>> <br>
> An even more interesting issue is the question of choosing which <br>
> member(s) to remove when scaling down.  The approach taken by
AWS is<br>
> documented at </font></tt><a href=http://docs.aws.amazon.com/AutoScaling/latest/><tt><font size=2>http://docs.aws.amazon.com/AutoScaling/latest/</font></tt></a><tt><font size=2><br>
> DeveloperGuide/us-termination-policy.html </font></tt>
<br><tt><font size=2>> but the design there has redundant complexity
and the doc is not <br>
> well written.  Following is a short sharp presentation of an
<br>
> isomorphic system. </font></tt>
<br><tt><font size=2>> A client that owns an ASG configures that ASG
to have a series <br>
> (possibly empty) of instance termination policies; the client can
<br>
> change the series during the ASG's lifetime.  Each policy is
drawn <br>
> from the following menu: </font></tt>
<br><tt><font size=2>> OldestLaunchConfiguration </font></tt>
<br><tt><font size=2>> ClosestToNextInstanceHour </font></tt>
<br><tt><font size=2>> OldestInstance </font></tt>
<br><tt><font size=2>> NewestInstance</font></tt>
<br><tt><font size=2>> --------and there is a default policy of termination...</font></tt>
<br>
<br><tt><font size=2>If you are objecting to the fact that I omitted "Default"
from the menu of available policies, note that there is no need to discuss
a "Default" policy.  Remember that doc also stipulates that
if your list of policies includes "Default" then "Default"
should be at the end of your list.  Since the Default policy is always
applied after your list (if there is a need), there is no need to explicitly
declare it at the end.  Note also that the doc is confusing about
default policy; at first it says that the default policy selects an AZ,
and later it mentions using the default policy to narrow down a set of
candidates within an AZ that has already been chosen.  So a simpler,
equivalent explanation has no need to ever talk about a "default policy",
rather it can stipulate that the configured list of ways to narrow down
the set of candidate instances is always followed by OldestLaunchConfiguration,
then ClosestToNextInstanceHour, then a random choice (which is how the
so-called "default policy" narrows down the set of candidates
after the AZ has been chosen).</font></tt>
<br>
<br><tt><font size=2>I brought this whole sub-topic up only to mostly dismiss
it.  OpenStack scaling groups do not currently attempt anything similar
to OldestLaunchConfiguration or ClosestToNextInstanceHour and I recommend
that the work on spanning across AZs should not attempt to change that.
 My recommendation is that this spec only call for adding a balancing
selection of AZ to what is currently done.  I have also opened a separate
discussion (ML subject "</font></tt><font size=2 face="sans-serif"><b>One
more lifecycle plug point - in scaling groups</b></font><tt><font size=2>")
about opening up this policy issue to give the cloud provider an opportunity
to configure some code into the selection procedure.</font></tt>
<br>
<br><tt><font size=2>> I plan to draft a spec. </font></tt>
<br><tt><font size=2>> --------may be no need to draft a spec, due to
my bp is approved <br>
> already, and I am developing now, if you are interested in it, we
<br>
> can cooperateJ, thanks.</font></tt>
<br><tt><font size=2>> </font></tt><a href="https://blueprints.launchpad.net/heat/+spec/implement-"><tt><font size=2>https://blueprints.launchpad.net/heat/+spec/implement-</font></tt></a><tt><font size=2><br>
> autoscalinggroup-availabilityzones</font></tt>
<br>
<br><tt><font size=2>I submitted my spec before I got your email.  See
</font></tt><a href=https://review.openstack.org/#/c/105907/><tt><font size=2>https://review.openstack.org/#/c/105907/</font></tt></a><tt><font size=2>
as well as the ML discussion (I just replied to Zane on the subject).  I
hope we can agree on the details discussed here and there.</font></tt>
<br>
<br><tt><font size=2>Thanks,</font></tt>
<br><tt><font size=2>Mike</font></tt>
<br>