Difference between revisions of "Nova-scheduler-HostState"
Lianhao-lu (talk | contribs) (correct db table names) |
Lianhao-lu (talk | contribs) (update the db scheme) |
||
(5 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
== Nova Scheduler HostState Change Proposal== | == Nova Scheduler HostState Change Proposal== | ||
− | + | ||
+ | [[User:Lianhao-lu|lianhao-lu]] ([[User talk:Lianhao-lu|talk]]) 04:27, 8 June 2013 (UTC) Created. | ||
+ | |||
+ | [[User:Lianhao-lu|lianhao-lu]] ([[User talk:Lianhao-lu|talk]]) 06:17, 21 June 2013 (UTC) Updated according to Rerngvit's comment. | ||
+ | |||
Here we list the current HostState fields in nova scheduler, and proposed the potential changes required for the following blueprints: | Here we list the current HostState fields in nova scheduler, and proposed the potential changes required for the following blueprints: | ||
Line 25: | Line 29: | ||
|- | |- | ||
| total_usable_disk_gb<br/>disk_mb_used<br/>free_ram_mb<br/>free_disk_mb<br/>vcpus_total<br/>vcpus_used | | total_usable_disk_gb<br/>disk_mb_used<br/>free_ram_mb<br/>free_disk_mb<br/>vcpus_total<br/>vcpus_used | ||
− | || rw || DB table - | + | || rw || DB table - compute_nodes || || compute node periodically polls and save into DB.<br/>modified by scheduler according to scheduling situation. |
|- | |- | ||
| num_instances<br/>num_io_ops || rw || DB table - compute_node_stats || statistics || compute node periodically polls and save into DB.<br/>modified by scheduler according to scheduling situation. | | num_instances<br/>num_io_ops || rw || DB table - compute_node_stats || statistics || compute node periodically polls and save into DB.<br/>modified by scheduler according to scheduling situation. | ||
Line 36: | Line 40: | ||
|} | |} | ||
− | === Proposed changes === | + | === Proposed changes to the HostState fields=== |
+ | We plan to use the following fields to replace the current HostState fields, which is extensible to store more information for the scheduler. Every nova compute host will have a corresponding HostState instance respectively. | ||
+ | |||
1. A new dictionary 'resources' will contain the resource usage information(e.g. free_ram_mb, vcpus_used, etc.) about the platform in the following format: | 1. A new dictionary 'resources' will contain the resource usage information(e.g. free_ram_mb, vcpus_used, etc.) about the platform in the following format: | ||
Line 47: | Line 53: | ||
} | } | ||
− | + | The resource_name can contain any printable ascii characters other than ':' or '='. | |
− | The | ||
2. Those statistic related fields(i.e. num_instances, vm_states, etc.) might need to grouped into a new dictionary 'stats', which would look something like the followings: | 2. Those statistic related fields(i.e. num_instances, vm_states, etc.) might need to grouped into a new dictionary 'stats', which would look something like the followings: | ||
Line 65: | Line 70: | ||
3. The existing 'capabilities' will only contains features information of the compute node platform, i.e. cpu features, etc. | 3. The existing 'capabilities' will only contains features information of the compute node platform, i.e. cpu features, etc. | ||
− | 4. For compatibility, the new HostState should also support the current method to access its current fields, e.g. host_state.num_instances, host_state.free_ram_mb, etc. | + | 4. Other fields will remain unchanged. |
+ | |||
+ | 5. For compatibility, the new HostState should also support the current method to access its current fields, e.g. host_state.num_instances, host_state.free_ram_mb, etc. | ||
+ | |||
+ | === How to get the data(initial data source) === | ||
+ | |||
+ | The data where stored in the 'resources' dictionary in HostState could be reported from the compute node periodically to the scheduler by RPC, as mentioned in [[UtilizationAwareScheduling]] according to blueprint[[#1]]. The data could also be collected from other service, e.g. ceilometer. However, there are some discussions in the community to argue that the data should be saved in to DB first: | ||
+ | http://lists.openstack.org/pipermail/openstack-dev/2013-June/010653.html | ||
+ | |||
+ | If the community decides to store the data into DB then loaded by the scheduler for use, like the 'resource_tracker', the following DB scheme which is extensible is needed: | ||
+ | |||
+ | {| class="wikitable" | ||
+ | |- | ||
+ | ! Field !! description | ||
+ | |- | ||
+ | | id || primary_key | ||
+ | |- | ||
+ | | compute_node_id || foreign key to table compute_nodes | ||
+ | |- | ||
+ | | name || string, resource_name | ||
+ | |- | ||
+ | | value || text, json encoded value | ||
+ | |- | ||
+ | | timestamp || timestamp | ||
+ | |- | ||
+ | | source || string | ||
+ | |} |
Latest revision as of 09:03, 5 July 2013
Contents
Nova Scheduler HostState Change Proposal
lianhao-lu (talk) 04:27, 8 June 2013 (UTC) Created.
lianhao-lu (talk) 06:17, 21 June 2013 (UTC) Updated according to Rerngvit's comment.
Here we list the current HostState fields in nova scheduler, and proposed the potential changes required for the following blueprints:
Current HostState
Field | Read/Write | Initial Source | Description | Comment |
---|---|---|---|---|
host/nodename | n/a | __init__() | identify the host/node | |
capabilities | ro | nova compute manager | dictionary contains the following keys:
|
compute node polls periodically. send it directly back to scheduler through RPC. |
service | ro | DB table - services | nova compute service | |
total_usable_disk_gb disk_mb_used free_ram_mb free_disk_mb vcpus_total vcpus_used |
rw | DB table - compute_nodes | compute node periodically polls and save into DB. modified by scheduler according to scheduling situation. | |
num_instances num_io_ops |
rw | DB table - compute_node_stats | statistics | compute node periodically polls and save into DB. modified by scheduler according to scheduling situation. |
num_instances_by_project num_instances_by_os_type vm_states task_states |
rw | DB table - compute_node_stats | number of instances by project_id, os_type, vm_state, task_state respectively | compute node periodically polls and save into DB. modified by scheduler according to scheduling situation. |
limits | rw | from schedulers | resource oversubscription value | used by compute node when building new instance |
updated | rw | last update timestamp |
Proposed changes to the HostState fields
We plan to use the following fields to replace the current HostState fields, which is extensible to store more information for the scheduler. Every nova compute host will have a corresponding HostState instance respectively.
1. A new dictionary 'resources' will contain the resource usage information(e.g. free_ram_mb, vcpus_used, etc.) about the platform in the following format:
{ <resource_name> : { 'value': <value of the resource>, 'timestamp': <last update time stamp>, 'source':<source of the data>, i.e. nova-compute, ceilometer, etc. } }
The resource_name can contain any printable ascii characters other than ':' or '='.
2. Those statistic related fields(i.e. num_instances, vm_states, etc.) might need to grouped into a new dictionary 'stats', which would look something like the followings:
{ 'num_instances': 1 'num_instances_by_project': { 'project-id1': 2 'project-id2': 1 } 'vm_states': { 'active': 1 } }
3. The existing 'capabilities' will only contains features information of the compute node platform, i.e. cpu features, etc.
4. Other fields will remain unchanged.
5. For compatibility, the new HostState should also support the current method to access its current fields, e.g. host_state.num_instances, host_state.free_ram_mb, etc.
How to get the data(initial data source)
The data where stored in the 'resources' dictionary in HostState could be reported from the compute node periodically to the scheduler by RPC, as mentioned in UtilizationAwareScheduling according to blueprint#1. The data could also be collected from other service, e.g. ceilometer. However, there are some discussions in the community to argue that the data should be saved in to DB first:
http://lists.openstack.org/pipermail/openstack-dev/2013-June/010653.html
If the community decides to store the data into DB then loaded by the scheduler for use, like the 'resource_tracker', the following DB scheme which is extensible is needed:
Field | description |
---|---|
id | primary_key |
compute_node_id | foreign key to table compute_nodes |
name | string, resource_name |
value | text, json encoded value |
timestamp | timestamp |
source | string |