[openstack-dev] [Scheduler] New scheduler feature - VM Ensembles
gkotton at redhat.com
Thu Jan 24 10:14:45 UTC 2013
On 01/22/2013 05:03 PM, Russell Bryant wrote:
> On 01/08/2013 08:27 AM, Gary Kotton wrote:
>> The link
>> introduces the concept of a VM ensemble or VM group into Nova. An
>> ensemble will provide the tenant the ability to group together VMs that
>> provide a certain service or part of the same application. More
>> specifically it enables configuring scheduling policies per group. This
>> will in turn allow for a more robust and resilient service.
>> Specifically, it will allow a tenant to deploy a multi-VM application
>> that is designed for VM fault tolerance in a way that application
>> availability is actually resilient to physical host failure.
>> Any inputs and comments will be greatly appreciated.
> I just read over the blueprint and document for this.
> My gut reaction is that this seems to be bleeding some of what Heat does
> into Nova, which I don't like.
No. This does not take any of Heats functionality. It actually provides
Heat with tools that can provide better placements.
> The document provides an example using the existing different_host
> scheduler hint. It shows how it might schedule things in a way that
> won't work, but only if the compute cluster is basically running out of
> capacity. I'm wondering how realistic of a problem this example is
This may be a rare case if you are looking at a 40%-50% overall resource
utilization. However, once you are pushing utilization to the 70%-80%
and (where most cloud operators would expect it to be), then resource
contention would be a very common phenomena that cannot be ignored.
70-80% utilization is not an edge case.
We also foresee that at the target utilization levels of 75%+ we will
also need to deal with resource fragmentation. Such
that, de-fragmentation of resources will need to automatically triggered
when needed. Therefore, VM groups scheduling policies need to be stored
and used for future re-scheduling of VM group members.
> The document mentions that when requesting N instances, specifying that
> anti-affinity is required for the hosts is not possible. Perhaps that's
> something that could be added.
This will not work - the best example is to look at that in the
document. In order to provide a complete solution the scheduler would be
required to see the whole group in order to select the best placement
strategy. The scheduling hints do not provide a solution when the
scheduler need to see the whole picture.
This is certainly a topic that we certainly need to speak about at up
and coming summit. I think that it would also be very beneficial if we
can have this in the G version.
More information about the OpenStack-dev