[openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
Jay Pipes
jaypipes at gmail.com
Thu Mar 27 01:14:38 UTC 2014
On Thu, 2014年03月27日 at 01:10 +0000, Joshua Harlow wrote:
> Region graphs?
>> Sounds like what u are describing sounds like a graph
> (non-hierarchical) which has nodes that have defined attributes on
> them.
>> A region then would just be a set of connected nodes (which could be
> connected via a parent<->child edge for example).
>> Each node can also have attributes (allowing regions to also be
> selected by common attributes). Seems like that might fit what is
> wanted?
Precisely.
-jay
>> From: Jay Pipes <jaypipes at gmail.com>
> Reply-To: "OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev at lists.openstack.org>
> Date: Wednesday, March 26, 2014 at 4:45 PM
> To: "openstack-dev at lists.openstack.org"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova][scheduler] Availability Zones and
> Host aggregates..
>>>> On Wed, 2014年03月26日 at 13:33 -0700, Vishvananda Ishaya wrote:
> On Mar 26, 2014, at 11:40 AM, Jay Pipes
> <jaypipes at gmail.com> wrote:
>> > 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
> > problem.
> >
> > 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:
> >
> > regionA
> > / \
> > 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 the overlapping zones allows for this and also
> enables additional use
> cases as mentioned in my earlier email.
>>> You are assuming that the region hierarchy I was describing
> had only a
> single root region. I didn't say that. I envision multiple
> root regions,
> which would enable compute nodes to reside in multiple
> regions.
>>> Hierarchical doesn’t work for the
> rack/switch model.
>>> Sure it does. Just not a single root hierarchy.
>>> I’m definitely +1 on breaking from the amazon usage
> of availability zones but I’m a bit leery to add
> another parameter to
> the create request.
>>> It wouldn't add another *required* parameter to the create
> request. The
> region would default to whatever region the keystone endpoint
> that
> returned the service catalog for the novaclient had as its
> default
> region.
>>> It is also unfortunate that region already has a
> meaning
> in the amazon world which will add confusion.
>>> OK. We could call it something else... though IIRC, trying to
> come up
> with a name for this kind of thing is, well, kind of tough :)
>>> -jay
>>>>> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
More information about the OpenStack-dev
mailing list