Yup, Sandy's zone stuff, Justin's metadata stuff, and this is all
pretty much the same (or at least very closely related). First off,
lets move away from the term zone and define "location" as an arbitrary
grouping of one or more resources, not the traditional "availability
zones". Thinking in terms of hierarchical locations, a root location
could be the endpoint for an entire public service. A leaf location
could be a single compute host (or possible even an instance on that
host). This location tag can be reused across OpenStack services. A
zone defines a location as well, but locations can be much more
granular.
When a request comes in that can take into account locality, you can
say "in location X", "near location X", "not in location X", etc. It
should be deployment specific what "near" is, and other relationship
terms between locations may need to be defined. We also need to keep
into consideration that some deployments want to keep topology opaque,
so some deployments may need a location-lookup service that translates
arbitrary locations to meaningful ones.
In a previous proposal I suggested we use DNS names, but folks said
it should stay pluggable to any arbitrary string. We can default to
using DNS names for simplicity though.
As an example, we could have:
Zones:
example.com
east.example.com
west.example.com
Locations: all zones above plus +
dc1.east.example.com
rack1.dc1.east.example.com
compute1.rack1.dc1.east.example.com
instance1.compute1.rack1.dc1.east.example.com
...
compute2.rack1.dc1.east.example.com
...
...
rack2.dc1.east.example.com
...
dc2.east.example.com
...
dc1.west.example.com
...
As mentioned before, all location names are subject to change at
anytime (rebalancing, failover, ...), so if you want to use them
to place objects near one another, you should always lookup the
location for the object when you make the request. A service may also
allow shortcuts, so you can say "launch an instance near this other
instance", which internally will resolve locations before performing
the request. Cross-project shortcuts are probably not worth it,
as then every service would need to know how to resolve objects for
every other.
So, with all this, we simply need a piece of metadata (auto-generated
and updated by service) named 'location' on all objects, and various
service schedulers will know how to operate on these with some set of
operations. Same may be required by the service (ie, putting volumes
on the same networks as the instance for example), but others can
be user-defined.
-Eric
On Mon, Feb 28, 2011 at 03:01:23PM -0800, Vishvananda Ishaya wrote:
> This seems to overlap heavily with justin's metadata stuff. The idea was
> that you could pass in metadata on instance launch saying near: other-object.
> I think that is far more useful than an opaque affinity id.
>
> Vish
>
> On Feb 28, 2011, at 2:53 PM, Gabe Westmaas wrote:
>
> > Hi Eric,
> >
> > I probably chose a poor word there, this is actually referring to something
> > smaller than the multicluster zones that Sandy has been working on. For
> > example, in case for some performance reasons you wanted two servers with
> > as few network hops as possible. If that still lines up with what you are
> > talking about, great.
> >
> > Sorry about that!
> >
> > Gabe
> >
> > On Monday, February 28, 2011 4:57pm, "Eric Day" <e...@oddments.org> said:
> >
> >> Hi Gabe,
> >>
> >> There has been a lot of discussion about this, along with zone naming,
> >> structure, and so forth. I was propsing we not only make it part of
> >> Nova, but suggest all projects use the same locality zone names/tags
> >> to ensure cross-project locality.
> >>
> >> So, "yes", and don't make it nova-specific. :)
> >>
> >> -Eric
> >>
> >> On Mon, Feb 28, 2011 at 04:48:25PM -0500, Gabe Westmaas wrote:
> >>> Hey All,
> >>>
> >>> For various reasons, Rackspace has a need to allow customers to request
> >>> placement
> >>> in the same zone as another server. I am trying to figure out if this is
> >>> generically useful, or something that should be outside of core. The
> >>> idea is
> >>> that if you don't specify an affinity ID one will get returned to you
> >>> when you
> >>> create the server, and you can use that ID to add additional servers in
> >>> close
> >>> proximity to the first.
> >>>
> >>> What do you think? Is this useful enough outside Rackspace to be in
> >>> core?
> >>> Alternatively, we can write it as an extension so as not to clutter core.
> >>>
> >>> Gabe
> >>>
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~openstack
> >>> Post to : openstack@lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help : https://help.launchpad.net/ListHelp
> >>
> >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
