Difference between revisions of "Admin-set-resource-quota-dynamically"
m (→Design and implementation) |
(old page ?) |
||
| (4 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| + | {{OldDesignPage}} | ||
* '''Launchpad Entry''': NovaSpec:admin-set-resource-quota-dynamically | * '''Launchpad Entry''': NovaSpec:admin-set-resource-quota-dynamically | ||
| Line 6: | Line 7: | ||
== Introduction == | == Introduction == | ||
| − | To achieve high cost-effectiveness in IaaS cloud operation, a cloud administrator tries to | + | To achieve high cost-effectiveness in IaaS cloud operation, a cloud administrator tries to<br /> |
| − | guaranteeing users' QoS requirements. After more and more IaaS clouds are deployed, cost-effectiveness in IaaS operation<br /> | + | save physical resources while guaranteeing users' QoS requirements. After more and more<br /> |
| − | + | IaaS clouds are deployed, cost-effectiveness in IaaS operation has become an important<br /> | |
| + | problem, attracting attention from both public and private cloud owners and administrators. | ||
| − | Highly cost-effective IaaS operation requires allocating physical resource quota to a VM | + | Highly cost-effective IaaS operation requires allocating physical resource quota to a VM<br /> |
| − | e.g. physical CPU execution time, physical memory limitation, blkio and network bandwidth. From Grizzly, OpenStack introduces <br /> | + | instance quantitativelyand accurately, e.g. physical CPU execution time, physical memory<br /> |
| − | + | limitation, blkio and network bandwidth. From Grizzly, OpenStack introduces the feature of<br /> | |
| − | With this feature, a quantitative and accurate resource quota can be assigned and reserved for an instance statically when it is | + | [[InstanceResourceQuota|Instance Resource Quota]], which provides the capability of static<br /> |
| − | created. This feature is a large improvement to the basic resource allocation mechanism in OpenStack, in which only | + | instance quota allocation. With this feature, a quantitative and accurate resource quota can<br /> |
| − | parameters, e.g. VCPU number, can be specified. | + | be assigned and reserved for an instance statically when it is created. This feature is a large<br /> |
| + | improvement to the basic resource allocation mechanism in OpenStack, in which only<br /> | ||
| + | fundamental parameters, e.g. VCPU number, can be specified. | ||
| − | According to the requirements derived from our IaaS operation practices, we come to recognize that there is still space left for | + | According to the requirements derived from our IaaS operation practices, we come to<br /> |
| − | further improvement in instance-level physical resource quota allocation. Except for the capability of static instance quota allocation,<br /> | + | recognize that there is still space left for further improvement in instance-level physical<br /> |
| − | dynamic instance quota adjustment is also valuable for cloud administrators. With such dynamic adjustment capability, they can | + | resource quota allocation. Except for the capability of static instance quota allocation,<br /> |
| − | re-allocate resources according to requirements when instances are running. As an example, the admin can allocate more physical<br /> | + | dynamic instance quota adjustment is also valuable for cloud administrators. With such<br /> |
| − | CPU execution time to a high-priority instance running computation-intensive or latency-critical workloads. Also, more blkio bandwidth | + | dynamic adjustment capability, they can re-allocate resources according to requirements<br /> |
| − | could be allocated to high-poiority instances running I/O-intensive workloads. Combining the dynamic adjustment capability | + | when instances are running. As an example, the admin can allocate more physical<br /> |
| − | existing static allocation capability, such resource allocation decisions can be made either before or after instances are created. | + | CPU execution time to a high-priority instance running computation-intensive or<br /> |
| + | latency-critical workloads. Also, more blkio bandwidth could be allocated to high-poiority<br /> | ||
| + | instances running I/O-intensive workloads. Combining the dynamic adjustment capability<br /> | ||
| + | with the existing static allocation capability, such resource allocation decisions can be<br /> | ||
| + | made either before or after instances are created. | ||
| − | In this blueprint, we propose the capability of dynamically adjusting available physical resources, e.g. CPU execution time for VCPU | + | In this blueprint, we propose the capability of dynamically adjusting available physical<br /> |
| − | of an instance, physical memory occupation, disk I/O bandwidth, etc. With this feature, it can be decided quantitatively that how much<br /> | + | resources, e.g. CPU execution time for VCPU of an instance, physical memory occupation,<br /> |
| + | disk I/O bandwidth, etc. With this feature, it can be decided quantitatively that how much<br /> | ||
physical resources should be allocated and reserved to an instance when it is running. | physical resources should be allocated and reserved to an instance when it is running. | ||
== Design and implementation == | == Design and implementation == | ||
| − | This feature depends on the cgroup support provided by libvirt. As an example, by opening the setSchedulerParameters() method of<br /> | + | This feature depends on the cgroup support provided by libvirt. As an example,<br /> |
| − | + | by opening the setSchedulerParameters() method of virDomain class in libvirt, <br /> | |
| + | we can achieve management on physical CPU execution time. | ||
To implemented this CPU execution time management, proposed modifications include: | To implemented this CPU execution time management, proposed modifications include: | ||
| Line 74: | Line 84: | ||
- Wiki: https://wiki.openstack.org/wiki/InstanceResourceQuota<br /> | - Wiki: https://wiki.openstack.org/wiki/InstanceResourceQuota<br /> | ||
- Blueprint: https://blueprints.launchpad.net/nova/+spec/quota-instance-resource | - Blueprint: https://blueprints.launchpad.net/nova/+spec/quota-instance-resource | ||
| + | |||
| + | [[category: nova]] | ||
Latest revision as of 18:38, 9 January 2015
|
Old Design Page
This page was used to help design a feature for a previous release of OpenStack. It may or may not have been implemented. As a result, this page is unlikely to be updated and could contain outdated information. It was last updated on 2015-01-09 |
- Launchpad Entry: NovaSpec:admin-set-resource-quota-dynamically
- Created: Sep. 18, 2013
- Contributors: Yu Zhang
Contents
Introduction
To achieve high cost-effectiveness in IaaS cloud operation, a cloud administrator tries to
save physical resources while guaranteeing users' QoS requirements. After more and more
IaaS clouds are deployed, cost-effectiveness in IaaS operation has become an important
problem, attracting attention from both public and private cloud owners and administrators.
Highly cost-effective IaaS operation requires allocating physical resource quota to a VM
instance quantitativelyand accurately, e.g. physical CPU execution time, physical memory
limitation, blkio and network bandwidth. From Grizzly, OpenStack introduces the feature of
Instance Resource Quota, which provides the capability of static
instance quota allocation. With this feature, a quantitative and accurate resource quota can
be assigned and reserved for an instance statically when it is created. This feature is a large
improvement to the basic resource allocation mechanism in OpenStack, in which only
fundamental parameters, e.g. VCPU number, can be specified.
According to the requirements derived from our IaaS operation practices, we come to
recognize that there is still space left for further improvement in instance-level physical
resource quota allocation. Except for the capability of static instance quota allocation,
dynamic instance quota adjustment is also valuable for cloud administrators. With such
dynamic adjustment capability, they can re-allocate resources according to requirements
when instances are running. As an example, the admin can allocate more physical
CPU execution time to a high-priority instance running computation-intensive or
latency-critical workloads. Also, more blkio bandwidth could be allocated to high-poiority
instances running I/O-intensive workloads. Combining the dynamic adjustment capability
with the existing static allocation capability, such resource allocation decisions can be
made either before or after instances are created.
In this blueprint, we propose the capability of dynamically adjusting available physical
resources, e.g. CPU execution time for VCPU of an instance, physical memory occupation,
disk I/O bandwidth, etc. With this feature, it can be decided quantitatively that how much
physical resources should be allocated and reserved to an instance when it is running.
Design and implementation
This feature depends on the cgroup support provided by libvirt. As an example,
by opening the setSchedulerParameters() method of virDomain class in libvirt,
we can achieve management on physical CPU execution time.
To implemented this CPU execution time management, proposed modifications include:
- An action with a proposed name _action_set_cpu_time_quota() is defined in nova-api
File to be modified:
/nova/api/openstack/compute/servers.py
/nova/compute/instance_actions.py
- An api with a proposed name set_cpu_time_quota() is defined in nova-compute
File to be modified:
/nova/compute/api.py
/nova/compute/rpcapi.py
/nova/compute/manager.py
- The setSchedulerParameters() method of virDomain class in libvirt is exposed in nova-virt
File to be modified:
/nova/virt/driver.py
/nova/virt/libvirt/driver.py
The execution flow of this CPU execution time management is shown in the following figure:
Status and schedule
The feature of dynamically adjusting CPU execution time has been implemented in our local OpenStack environment and works well.
Testing
To be added
Scope
Since this feature depends on both cgroup of Linux and libvirt, therefore, if either KVM or libvirt are not used, this feature might not work.
But based on this feature, supports to other hypervisors and drivers should be easier to be added.
Reference
- cgroup doc
https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt
- libvirt API doc
http://libvirt.org/html/libvirt-libvirt.html
- Related blueprints
Instance Resource Quota
- Wiki: https://wiki.openstack.org/wiki/InstanceResourceQuota
- Blueprint: https://blueprints.launchpad.net/nova/+spec/quota-instance-resource
