Open Stack

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<app:ds:interested> in<app:ds:in> this bp, I think we can discuss this:)


Thanks
发件人: Mike Spreitzer [mailto:mspreitz at us.ibm.com]
发送时间: 2014年7月2日 4:23
收件人: OpenStack Development Mailing List
主题: [openstack-dev] [heat] autoscaling across regions and availability zones

An AWS autoscaling group can span multiple availability zones in one region.  What is the thinking about how to get analogous functionality in OpenStack?

Warmup question: what is the thinking about how to get the levels of isolation seen between AWS regions when using OpenStack?  What is the thinking about how to get the level of isolation seen between AWS AZs in the same AWS Region when using OpenStack?  Do we use OpenStack Region and AZ, respectively?  Do we believe that OpenStack AZs can really be as independent as we want them (note that this is phrased to not assume we only want as much isolation as AWS provides --- they have had high profile outages due to lack of isolation between AZs in a region)?

I am going to assume that the answer to the question about ASG spanning involves spanning OpenStack regions and/or AZs.  In the case of spanning AZs, Heat has already got one critical piece: the OS::Heat::InstanceGroup and AWS::AutoScaling::AutoScalingGroup types of resources take a list of AZs as an optional parameter.  Presumably all four kinds of scaling group (i.e., also OS::Heat::AutoScalingGroup and OS::Heat::ResourceGroup) should have such a parameter.  We would need to change the code that generates the template for the nested stack that is the group, so that it spreads the members across the AZs in a way that is as balanced as is possible at the time.

Currently, a stack does not have an AZ.  That makes the case of an OS::Heat::AutoScalingGroup whose members are nested stacks interesting --- how does one of those nested stacks get into the right AZ?  And what does that mean, anyway?  The meaning would have to be left up to the template author.  But he needs something he can write in his member template to reference the desired AZ for the member stack.  I suppose we could stipulate that if the member template has a parameter named "availability_zone" and typed "string" then the scaling group takes care of providing the right value to that parameter.

To spread across regions adds two things.  First, all four kinds of scaling group would need the option to be given a list of regions instead of a list of AZs.  More likely, a list of contexts as defined in https://review.openstack.org/#/c/53313/ --- that would make this handle multi-cloud as well as multi-region.  The other thing this adds is a concern for context health.  It is not enough to ask Ceilometer to monitor member health --- in multi-region or multi-cloud you also have to worry about the possibility that Ceilometer itself goes away.  It would have to be the scaling group's responsibility to monitor for context health, and react properly to failure of a whole context.

Does this sound about right?  If so, I could draft a spec.

Thanks,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140704/1472a96e/attachment.html>