Difference between revisions of "ExtensibleResourceTracking"
(→Summary - (in progress)) |
(→Definitions) |
||
| Line 28: | Line 28: | ||
** weighers - examples using extended resources | ** weighers - examples using extended resources | ||
| − | === | + | === Resource Models and Naming === |
| − | The | + | A resource has the following attributes: |
| + | * name - used to identify this resource | ||
| + | * type - a resource type name for human viewing | ||
| + | * units - a resource unit name for human viewing | ||
| + | * description - a short description for human viewing | ||
| + | |||
| + | The resource_tracker maintains two attributes for each resource of a compute node: | ||
| + | * resource = value (total amount of resource) | ||
| + | * resource used = value (amount of resource currently used) | ||
| + | |||
| + | A flavor has a single attribute for each resource it requires: | ||
| + | * resource = value (amount required) | ||
| + | |||
| + | An instance has a single attribute for each resource it requires: | ||
| + | * resource = value (from flavor) | ||
| + | |||
| + | The information known to the resource_tracker is communicated to the scheduler's host_manager and accessed through the host_state: | ||
| + | * resource = value (from resource_tracker) | ||
| + | * resource used = value (from resource_tracker) | ||
| + | |||
| + | When the scheduler matches an instance create request to a compute node, it uses a resource allocation policy that includes knowledge of how much it can over-commit the resource. It may also chose to ignore resource limits (for example, when forcing an instance to a host). It calculates a resource limit value to guide its decision. | ||
| + | * resource = value (from host_state) | ||
| + | * resource used = value (from host_state) | ||
| + | * resource commit ratio = value (configured) | ||
| + | * resource limit = value (calculated) | ||
| + | |||
| + | Instance create requests communicate details of the instance and its requirements, including the limit used to calculate if it fits on the host according to the resource allocation policy. | ||
| + | * resource = value (from flavor) | ||
| + | * resource limit = value (from scheduler) | ||
Revision as of 18:10, 28 November 2013
Summary - (in progress)
There are a number of defined resources in Nova, including disk, memory and number of vCPU. The purpose of this specification is to support an extensible set of resources so that new resources can be defined for compute nodes and resource requirements for instances. These will be made available to the scheduler and allocated by the compute manager.
The resources of a compute node have limited capacity. Most, including disk, memory and vCPU, map to a physical counterpart, typically via a virtualisation technology, but it is also possible to create entirely abstract resource types that do not. As an example, a provider may chose that only one instances of a certain type should run on any compute node. This trivial example can be supported by defining a new resource for compute nodes and associating a requirement for that resource with the instance type.
Each instance has resource requirements specified as the quantity of each type of resource it needs. These are used by the scheduler to match it to compute nodes with sufficient available resources.
The compute manager on a host is aware of the resources available at the compute node and is responsible for their allocation and management. Because it has definitive knowledge of what resources are actually in use, the compute manager has the final say as to whether a compute node is able to host an instance.
We will need:
- a model of a resource
- a model of a resource requirement
- a naming scheme to allow resource requirements to be related to resources
- changes for compute nodes
- resource configuration - to define extended resources
- resource_tracker - to track extended resources
- claims - to test requirements against available extended resources
- changes for instances
- resource requirements in flavors
- resource requirements in requests
- resource requirements in instances
- changes for the database
- extended resources at compute_nodes
- extended resource requirements in instances
- changes for scheduler (filter scheduler)
- host manager - to access extended resources
- filters - examples using extended resources
- weighers - examples using extended resources
Resource Models and Naming
A resource has the following attributes:
- name - used to identify this resource
- type - a resource type name for human viewing
- units - a resource unit name for human viewing
- description - a short description for human viewing
The resource_tracker maintains two attributes for each resource of a compute node:
- resource = value (total amount of resource)
- resource used = value (amount of resource currently used)
A flavor has a single attribute for each resource it requires:
- resource = value (amount required)
An instance has a single attribute for each resource it requires:
- resource = value (from flavor)
The information known to the resource_tracker is communicated to the scheduler's host_manager and accessed through the host_state:
- resource = value (from resource_tracker)
- resource used = value (from resource_tracker)
When the scheduler matches an instance create request to a compute node, it uses a resource allocation policy that includes knowledge of how much it can over-commit the resource. It may also chose to ignore resource limits (for example, when forcing an instance to a host). It calculates a resource limit value to guide its decision.
- resource = value (from host_state)
- resource used = value (from host_state)
- resource commit ratio = value (configured)
- resource limit = value (calculated)
Instance create requests communicate details of the instance and its requirements, including the limit used to calculate if it fits on the host according to the resource allocation policy.
- resource = value (from flavor)
- resource limit = value (from scheduler)
