Use compute driver usage stats as an option

Registered by Maithem on 2013-12-10

Nova compute uses a resource tracker to audit available resources. The resources tracker makes a call to the virt driver and gets a dictionary of stats that includes resource capacity and resource usage. The resource tracker will use the resource capacity reported by the driver and ignore resources consumption stats. The resource tracker will query the database and calculate usage stats based on the flavors used. The resource tracker ignores usage stats reported from the driver, because the driver reports current usage, which might not reflect a total reservation for the instances created. For example, if the hypervisor has 3gb of ram and an instance is created with 2gb of ram, assuming the instance is only using 1gb of ram, the driver will report 2gb of available ram minus the hypervisor overheads for available ram. On the other hand nova resource manager will ignore the hypervisor's overheads and report the available memory by subtracting the full reservation of the vm from the total capacity. In the case of the example, the resource tracker will report 3 - 2 = 1 gb of available memory. Therefore, in some cases, if the hypervisor's overheads are fluctuating significantly, then the scheduler might not have an accurate view of available resources, which might result in an incorrect scheduling action.

Although an overhead reservation can be made by setting the reserved_host_memory_mb and reserved_host_disk_mb, in some settings having a static allocation is less optimal. The following use case illustrates the point: in the case of using xen or vmware, nova compute can reside on a vm on the hypervisor. Since that vm isn't created by nova, then the resource tracker will not account for the nova compute consumed resources, unless the host memory and disk reservations are set. With different hypervisor sizes, workloads and dynamic over-committing, setting static host reservations can result in over reservation.

For some deployments that don't require strict reservation requirements and have optimistic overcommitment mechanisms, it can be useful to have a variable in nova.conf to switch between auditing resources or deriving the resource usages directly from the driver.

Blueprint information

Status:
Started
Approver:
None
Priority:
Undefined
Drafter:
Maithem
Direction:
Needs approval
Assignee:
Maithem
Definition:
Drafting
Series goal:
None
Implementation:
Needs Code Review
Milestone target:
None
Started by
Maithem on 2014-01-14

Related branches

Sprints

Whiteboard

Gerrit topic: https://review.openstack.org/#q,topic:bp/use-driver-usage-stats,n,z

Addressed by: https://review.openstack.org/66508
    Update Available Resources From Driver Stats

The description of this BP and the full spec are misleading. The reason the resource tracker doesn't use the virt driver reported statistics is that many virt drivers will report on the amount of resources actually used not the total amount allocated. These are commonly different due to such things as ballooning and lazy allocation. So I would like to see this BP document what virt drivers this works for, where balooning is an issue (that can cause over subscription) etc. ~jogo (Feb 3, 2014)

deferred from icehouse-3 to "next": http://lists.openstack.org/pipermail/openstack-dev/2014-February/026335.html

Removed from next, as next is now reserved for near misses from the last milestone --johnthetubaguyGerrit topic: https://review.openstack.org/#q,topic:bp/use-driver-usage-stats,n,z

Addressed by: https://review.openstack.org/66508
    Update Available Resources From Driver Stats

The description of this BP and the full spec are misleading. The reason the resource tracker doesn't use the virt driver reported statistics is that many virt drivers will report on the amount of resources actually used not the total amount allocated. These are commonly different due to such things as ballooning and lazy allocation. So I would like to see this BP document what virt drivers this works for, where balooning is an issue (that can cause over subscription) etc. ~jogo (Feb 3, 2014)

deferred from icehouse-3 to "next": http://lists.openstack.org/pipermail/openstack-dev/2014-February/026335.html

Removed from next, as next is now reserved for near misses from the last milestone --johnthetubaguy

Marking this blueprint as definition: Drafting. If you are still working on this, please re-submit via nova-specs. If not, please mark as obsolete, and add a quick comment to describe why. --johnthetubaguy (20th April 2014)

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.