Open Stack

Huangtianhua <huangtianhua at huawei.com> wrote on 07/09/2014 10:20:42 PM:

> 发件人: Mike Spreitzer [mailto:mspreitz at us.ibm.com] 
> 发送时间: 2014年7月10日 3:19
> 收件人: OpenStack Development Mailing List (not for usage questions)
> 主题: Re: [openstack-dev] 答复: [heat] autoscaling across regions 
> and availability zones
> 
> Huangtianhua <huangtianhua at huawei.com> wrote on 07/04/2014 02:35:56 AM:
> 
> > I have register a bp about this : https://blueprints.launchpad.net/
> > heat/+spec/implement-autoscalinggroup-availabilityzones 
> > ・ 
> > ・         And I am thinking how to implement this recently. 
> > ・ 
> > ・         According to AWS autoscaling implementation  “attempts to 
> > distribute instances evenly between the Availability Zones that are 
> > enabled for your Auto Scaling group. 
> > ・         Auto Scaling does this by attempting to launch new 
> > instances in the Availability Zone with the fewest instances. If the
> > attempt fails, however, Auto Scaling will attempt to launch in other
> > zones until it succeeds.” 
> > 
> > But there is a doubt about the “fewest instance”, .e.g 
> > 
> > There are two azs, 
> >    Az1: has two instances 
> >    Az2: has three instances 
> > ・            And then to create a asg with 4 instances, I think we 
> > should create two instances respectively in az1 and az2, right? Now 
> > if need to extend to 5 instances for the asg, which az to lauch 
> new instance? 
> > If you interested in this bp, I think we can discuss thisJ 
> 
> The way AWS handles this is described in http://docs.aws.amazon.com/
> 
AutoScaling/latest/DeveloperGuide/AS_Concepts.html#arch-AutoScalingMultiAZ 

> 
> 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. 

> --------yes, I read the doc, as you said, the doc is not well 
> written, so I doubt about the “fewest instance” before, but now IMO,
> “fewest instance” means the instances of the group, so you are 
> right, to my specific example, the instance should be launch at 
> random or in a round-robin mode.
> 
> An even more interesting issue is the question of choosing which 
> member(s) to remove when scaling down.  The approach taken by AWS is
> documented at http://docs.aws.amazon.com/AutoScaling/latest/
> DeveloperGuide/us-termination-policy.html 
> but the design there has redundant complexity and the doc is not 
> well written.  Following is a short sharp presentation of an 
> isomorphic system. 
> 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: 
> OldestLaunchConfiguration 
> ClosestToNextInstanceHour 
> OldestInstance 
> NewestInstance
> --------and there is a default policy of termination...

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).

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 "One more lifecycle plug point - in scaling groups
") about opening up this policy issue to give the cloud provider an 
opportunity to configure some code into the selection procedure.

> I plan to draft a spec. 
> --------may be no need to draft a spec, due to my bp is approved 
> already, and I am developing now, if you are interested in it, we 
> can cooperateJ, thanks.
> https://blueprints.launchpad.net/heat/+spec/implement-
> autoscalinggroup-availabilityzones

I submitted my spec before I got your email.  See 
https://review.openstack.org/#/c/105907/ 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.

Thanks,
Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140709/3e1ea72b/attachment.html>