[openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live migration with one nova compute

Jay Pipes jaypipes at gmail.com
Tue Apr 15 13:43:00 UTC 2014


Hi again, Divakar, sorry for the delayed response!

On Wed, 2014-04-09 at 14:52 +0000, Nandavar, Divakar Padiyar wrote:
> Hi Jay, Managing multiple clusters using the "Compute Proxy" is not new
> right? Prior to this "nova baremetal" driver has used this model
> already.

Yes, unfortunately. However, nova-baremetal has moved to the Ironic
project, which has its own scheduler that is built to deal with the
problem of having a single compute manager responsible for >1 set of
compute resources.

> Also this "Proxy Compute" model gives flexibility to deploy as many
> computes required based on the requirement. For example, one can
> setup one proxy compute node to manage a set of clusters and another
> proxy compute to manage a separate set of clusters or launch compute
> node for each of the clusters.

It actually reduces the flexibility of Nova in two main ways:

1) It breaks the horizontal scale-out model that exists when a single
nova-compute is responsible for a wholly-separate group of compute
resources. Under the proxy compute model, if the proxy compute goes
down, the whole cluster goes down.

2) It surrenders control of the VMs to an external system and in doing
so, must constantly poll this external system in order to know the state
of the externally-controlled resources. We do this already at the
hypervisor driver level. The source of truth for VM state is the
hypervisor, and nova-compute must periodically query the hypervisor for
live data about the VMs running on the hypervisor. The Nova scheduler
queries nova-compute workers for information about the VMs running on
the host it controls. For the proxy-compute model, the Nova scheduler
queries proxy-computes, which then must query some externally-controlled
management platform, and then aggregate this data back up to the Nova
scheduler (a job that the Nova scheduler is designed to do, not the
nova-compute worker). This additional layer of complexity does not allow
greater flexibility -- it instead limits the flexibility of Nova, since
it changes the definition and responsibility of two of its major
components: nova-compute and nova-scheduler.

Best,
-jay





More information about the OpenStack-dev mailing list