[openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..

Jay Pipes jaypipes at gmail.com
Wed Mar 26 18:40:24 UTC 2014

On Wed, 2014-03-26 at 09:47 -0700, Vishvananda Ishaya wrote:
> Personally I view this as a bug. There is no reason why we shouldn’t
> support arbitrary grouping of zones. I know there is at least one
> problem with zones that overlap regarding displaying them properly:
> https://bugs.launchpad.net/nova/+bug/1277230
> There is probably a related issue that is causing the error you see
> below. IMO both of these should be fixed. I also think adding a
> compute node to two different aggregates with azs should be allowed.
> It also might be nice to support specifying multiple zones in the
> launch command in these models. This would allow you to limit booting
> to an intersection of two overlapping zones.
> A few examples where these ideas would be useful:
> 1. You have 3 racks of servers and half of the nodes from each rack
> plugged into a different switch. You want to be able to specify to
> spread across racks or switches via an AZ. In this model you could
> have a zone for each switch and a zone for each rack.
> 2. A single cloud has 5 racks in one room in the datacenter and 5
> racks in a second room. You’d like to give control to the user to
> choose the room or choose the rack. In this model you would have one
> zone for each room, and smaller zones for each rack.
> 3. You have a small 3 rack cloud and would like to ensure that your
> production workloads don’t run on the same machines as your dev
> workloads, but you also want to use zones spread workloads across the
> three racks. Similarly to 1., you could split your racks in half via
> dev and prod zones. Each one of these zones would overlap with a rack
> zone.
> You can achieve similar results in these situations by making small
> zones (switch1-rack1 switch1-rack2 switch1-rack3 switch2-rack1
> switch2-rack2 switch2-rack3) but that removes the ability to decide to
> launch something with less granularity. I.e. you can’t just specify
> ‘switch1' or ‘rack1' or ‘anywhere’
> I’d like to see all of the following work
> nova boot … (boot anywhere)
> nova boot —availability-zone switch1 … (boot it switch1 zone)
> nova boot —availability-zone rack1 … (boot in rack1 zone)
> nova boot —availability-zone switch1,rack1 … (boot

Personally, I feel it is a mistake to continue to use the Amazon concept
of an availability zone in OpenStack, as it brings with it the
connotation from AWS EC2 that each zone is an independent failure
domain. This characteristic of EC2 availability zones is not enforced in
OpenStack Nova or Cinder, and therefore creates a false expectation for
Nova users.

In addition to the above problem with incongruent expectations, the
other problem with Nova's use of the EC2 availability zone concept is
that availability zones are not hierarchical -- due to the fact that EC2
AZs are independent failure domains. Not having the possibility of
structuring AZs hierarchically limits the ways in which Nova may be
deployed -- just see the cells API for the manifestation of this

I would love it if the next version of the Nova and Cinder APIs would
drop the concept of an EC2 availability zone and introduce the concept
of a generic region structure that can be infinitely hierarchical in
nature. This would enable all of Vish's nova boot commands above in an
even simpler fashion. For example:

Assume a simple region hierarchy like so:

              /      \
         regionB    regionC

# User wants to boot in region B
nova boot --region regionB
# User wants to boot in either region B or region C
nova boot --region regionA

I think of the EC2 availability zone concept in the Nova and Cinder APIs
as just another example of implementation leaking out of the API. The
fact that EC2 availability zones are implemented as independent failure
domains and thus have a non-hierarchical structure has caused the Nova
API to look and feel a certain way that locks the API into the
implementation of a non-OpenStack product.


More information about the OpenStack-dev mailing list