[openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ?

Steve Gordon sgordon at redhat.com
Wed Apr 9 17:13:17 UTC 2014


----- Original Message -----
> > -----Original Message-----
> > From: Chris Friesen [mailto:chris.friesen at windriver.com]
> > Sent: 09 April 2014 15:37
> > To: openstack-dev at lists.openstack.org
> > Subject: Re: [openstack-dev] [Nova] Hosts within two Availability Zones :
> > possible or not ?
> > 
> > On 04/09/2014 03:55 AM, Day, Phil wrote:
> > 
> > > I would guess that affinity is more likely to be a soft requirement
> > > that anti-affinity,  in that I can see some services just not meeting
> > > their HA goals without anti-affinity but I'm struggling to think of a
> > > use case why affinity is a must for the service.
> > 
> > Maybe something related to latency?  Put a database server and several
> > public-facing servers all on the same host and they can talk to each other
> > with less latency then if they had to go over the wire to another host?
> > 
> I can see that as a high-want, but would you actually rather not start the
> service if you couldn't get it ?  I suspect not, as there are many other
> factors that could affect performance.  On the other hand I could imagine a
> case where I declare its not worth having a second VM at all if I can't get
> it on a separate server.   Hence affinity feels more "soft" and
> anti-affinity "hard" in terms or requirments.

As the orchestrator if affinity is important to me and it turns out I can't place all of the VMs in the group with affinity, I would likely use the failure to place the second (or subsequent) instance as my cue to rollback and destroy the original VM(s) as well. I don't think either policy is naturally any more hard or soft - it depends on the user and their workloads - this is why I think a "soft" implementation of either filter should be in addition to rather than instead of the existing ones, though "soft" may make more sense for the defaults. 

Thanks,

Steve



More information about the OpenStack-dev mailing list