Difference between revisions of "Blueprint-nova-planned-resource-reservation-api"

Revision as of 04:13, 15 April 2013

Created: Julien Danjou
Contributors: Julien Danjou, Patrick Petit, François Rossigneux, Julien Carpentier

Summary

This blueprint introduces the concept of a Capacity Leasing Service for OpenStack. With that service, a user with admin privileges can reserve hardware resources that are dedicated to the sole use of a tenant. A lease is a negotiation agreement between the provider and the consumer where the former agrees to make a set of hardware resources (compute and possibly storage) available to the latter, based on a set of lease terms presented by the consumer. The lease terms include the description of the host's capacity and the availability period during which the hardware is reserved.

We are thinking of three kinds of lease terms:

Schedule lease: where resources must be provisioned at a specific date and time
Best-effort lease: where resources are provisioned as soon as possible
Immediate lease: where resources are provisioned immediately or not at all

Once a lease is created, nobody but the users of the tenant can use the reserved resources during the period of the lease. When a lease ends, nothing disruptive happens to the instances that have been scheduled on the reserved resources. The hardware resources simply return to the common pool and so become available to other tenants for VM scheduling. A lease is potentially a billable item for which customers can be charged a flat fee or a premium price for each VM scheduled on reserved hardware and so usage of resource leases should be accounted for through Ceilometer.

See Launchpad Blueprint: Planned resource reservation API

Rationale

There are situations where the reservation of hardware resources are desired to satisfy peaks of load that are known in advance. This is especially true for small scale cloud infrastructures and in HPC use cases where the co-scheduling of multiple compute nodes at once is necessary, to satisfy the needs of urgent computing applications or to avoid mixing different types of workload on the same physical host.

Detailed Description

As with the Filter Scheduler, the Capacity Leasing Service uses filtering to perform the match making between the properties of the lease terms and the available hosts. The lease term properties should include:

the region
the availability zone
the host capabilities extra specs
the number of hosts,
the type of lease (SCHEDULE, BEST-EFFORT, IMMEDIAT)
the staring date of the lease if of type SCHEDULE
the duration in days and hours of the lease
A set of filters and weighting to make informed decisions on where a new instance should be created

In return, the service displays a list of lease handles (sorted in chronological order) containing a schedule proposals (starting date and time), and other optional (provider's specific?) parameters. The user can then create, and so activate the lease, using one of the lease handles he obtained from the previous step. More advanced usage scenarios will be enabled through the use of plug-able modules to backend systems that will affect the content of the lease handles returned by the service. Beyond reserving capacity, the expected benefits of the Capacity Leasing Service is to foster energy efficiency (greener?) behaviors through promoting nodes with the lowest MFLOPS/Watt ratio, or save electricity by automatically turning machines on and off based on the leasing schedule. In addition, the service should help operators with the management of their physical assets in a more effective way thanks to the enablement of capacity planing and automated fulfillment processes based again on the leasing schedule.

Last but not least. The Capacity Leasing Service is also expected to address a class of performance needs and types of workload that are typical of the high performance computing world, whereby applications require to be executed on dedicated nodes of similar hardware specification and speed (CPU arch, model, and clock frequency)

As a result, capacity leasing requests to the service should allow users to specify host capabilities parameters criteria that are compatible, or even the same, as those used by the ComputeCapabilitiesFilter which are known as the instance type extra specifications.

For exemple:

memory_mb == 22000
vcpus == 8
local_gb == 1690
cpu_arch == "x86_64"
cpu_info == '{"model":"Nehalem", "features":["tdtscp", "xtpr"]}'
xpu_arch = "fermi"
xpus = 2
xpu_info ='{"model":"Tesla 2050", "gcores":"448"}'
net_arch = "ethernet"
net_info = '{"encap":"Ethernet", "MTU":"8000"}'
net_mbps = 10000
hypervisor_ype == QEMU

As for the ComputeCapabilitiesFilter, the extra specification parameters used by the Capacity Leasing Service should support an operator at the beginning of the value string of a key/value pair. If there is no operator specified, then a default operator of ‘s==’ is used.

As a recap, valid operators are:

= (equal to or greater than as a number; same as vcpus case)
== (equal to as a number)
!= (not equal to as a number)
>= (greater than or equal to as a number)
<= (less than or equal to as a number)
s== (equal to as a string)
s!= (not equal to as a string)
s>= (greater than or equal to as a string)
s> (greater than as a string)
s<= (less than or equal to as a string)
s< (less than as a string)
<in> (substring)
<or> (find one of these)

Examples are: ">= 5", "s== 2.1.0", "<in> gcc", and "<or> fpu <or> gpu"

Design

A reservation, or lease, is tight to a project. It has a start and an end timestamp, during which the lease is valid. It also has a number of nodes and their flavors associated with, so it can be quantified. A lease has a set of scheduler hints set that are immutable. An API call allows a user to retrieve the list and combination of applicable hints. When a user tries to creates a lease, the list of scheduler hints is checked for validity: an operator can refuse a lease with invalid or too strict hints.

When an instance is created, it's registered as being part of the lease when the user passes the information at creation time. It's taken from the lease when it's destroyed. If an instance is created as being part of a lease, the scheduler has to launch the instance with the requirements fulfilled.

Implementation

TBD

Test Plan

TBD

@@ Line 20: / Line 20: @@
 There are situations where the reservation of hardware resources are desired to satisfy peaks of load that are known in advance. This is especially true for small scale cloud infrastructures and in HPC use cases where the co-scheduling of multiple compute nodes at once is necessary, to satisfy the needs of urgent computing applications or to avoid mixing different types of workload on the same physical host.
-== More Advanced Use Cases ==
+== Detailed Description ==
+As with the Filter Scheduler, the Capacity Leasing Service uses filtering to perform the match making between the properties of the lease terms and the available hosts. The lease term properties should include:
+# the region
+# the availability zone
+# the host capabilities extra specs
+# the number of hosts,
+# the type of lease (SCHEDULE, BEST-EFFORT, IMMEDIAT)
+# the staring date of the lease if of type SCHEDULE
+# the duration in days and hours of the lease
+# A set of filters and weighting to make informed decisions on where a new instance should be created
+In return, the service displays a list of lease handles (sorted in chronological order) containing a schedule proposals (starting date and time), and other optional (provider's specific?) parameters.
+The user can then create, and so activate the lease, using one of the lease handles he obtained from the previous step.
 More advanced usage scenarios will be enabled through the use of plug-able modules to backend systems that will affect the content of the lease handles returned by the service. Beyond reserving capacity, the expected benefits of the Capacity Leasing Service is to foster energy efficiency (greener?) behaviors through promoting nodes with the lowest MFLOPS/Watt ratio, or save electricity by automatically turning machines on and off based on the leasing schedule. In addition, the service should help operators with the management of their physical assets in a more effective way thanks to the enablement of capacity planing and automated fulfillment processes based again on the leasing schedule.