14 October 2015

​

Ildikó Vancsa, Ericsson

Gerald Kunzmann, DOCOMO Euro-Labs

Promise

Resource Reservation

Capacity Management

​

Architectural options

PROMISE architectural options - overview

demo B-release evolution path? target architecture?

Option 1 - pure shim-layer

Main benefit: no change in OpenStack required

​

Main disadvantages:

• will require all signalling to OS to go via SL

→ is this feasible in planned architecture?

• no support of e.g. affinity-rules, numa, … as SL will not know about it?

​

Gaps:

• (API extension work on OS to synchronize capacity with OS, preferably by notification to minimize delay)

​

​

Open issues/questions:

• How to reserve resources with specific requirements, e.g. affinity/anti-affinity, numa, ...? Does/can the SL know about such level of details? Will this require further API extensions?

Pure shim-layer

Consumer A

Consumer B

Shim-layer�(w/ allocation+reserv. logic+policies)

OpenStack�(Nova, Neutron, Cinder)

Pros & Cons:

+ flexible update of APIs possible

+ reservation and capacity mgmt in one place

+ multi-site support

- Feasibility of shim-layer for all I/Fs between � Consumer(s) and VIM(s) ?

- Synchronization gap/issue � between OpenStack and Shimlayer

- No support of e.g. affinity-rules etc. ?

Reservation + �alloc./termin. requests

Allocation/termination

Sync capacity

Using option 1 we can realize demo for OPNFV Summit

Option 1 - flow chart - Reservation

Virtualised Resource Capacity

Consumer A

Shim Layer

Reservation

Shim Layer

Capacity Mgt

1. create_reservation

(start, end, capacity)

“end”: “2015-11-23T00:00:00Z”, “capacity”: {“instances”: 2, “addresses”: 1, “gigabytes”: 10}

2. query_capacity

(start, end, capacity)

“end”: “2015-11-23T00:00:00Z”,

“capacity”: 3 ‘available capacity’

3. OK

​

4. OK

​

(reservation_id)

Option1: compute allocation request - „no error“ case

Consumer

Res. Mgmt/ shim-layer

allocation_request�(reservation_id, name, flavour, …)

Check if reservation_id exists in timewindow

Check if capacity (reservation-usage) >

capacity(flavour)

Nova

Client

pkgcloud

client

createServer

(name, flavour, …)

Ceilometer

id

createEventAlarm(id, ...)

Allocation process

allocated

allocated

OKAY

compute.createclient

(username, password, authUrl, ...)

Option 2 - hybrid solution

​

Gaps:

• API extension work on OS to enable passing of reservation identifier from Shim-Layer to OS
• API extension work on OS to enable passing of reservation identifier during allocation requests
• API extension work on OS to notify SL about allocation/ termination requests required to update data model in SL,�e.g. to enable policies for expiryTime
• (API extension work on OS to synchronize capacity with OS)

​

Open issues/questions:

• How to reserve resources with specific requirements, e.g. affinity/anti-affinity? Does/can the SL know about such level of details? Will this require further API extensions?

​

​

​

Peter: current Promise implementation is most closely aligned with this Hybrid option (2). Gerald disagrees as we don’t have notion of reservationID in OS yet, so reservationID cannot be used in allocation requests.

​

Hybrid

Consumer A

Consumer B

Shim-layer�(w/ reserv. logic+policies)

OpenStack�w/ policies for dealing with reserved resources

Pros & Cons:

+ removes limitation to force all signaling� via Shim-layer

+ multi-site support

- Requires reservation-related policies in OS�- Requires OS to handle ReservationId

- Sychronization gap/issue betwen OS and SL�- No support of e.g. affinity-rules etc. ?

Reservation�requests

Allocation/termination�(optional: using Reserv.Id)

ReservationId

Sync�capacity

Notify alloc/term

Option 2 - flow chart

Option 3 - pure OpenStack

Main advantages:

• Closely integrate with Nova, which has scheduling functionality
• Better way to use OpenStack’s knowledge about the host capabilities
• The codebase lives together with the rest of the OpenStack code, no need to handle compatibility as an extra effort

​

Disadvantages:

• Several integration points are needed with OpenStack, which makes the goal harder to achieve

Pure OpenStack

Consumer A

Consumer B

Pros & Cons:

+ no shim-layer required, i.e.� no sychronization gap etc.� and no limitations for signalling

+ code maintainted by OS

- Requires eXtended Blazar

- Requires OS to handle all reservation� policies/logic and reservation database

- no multi-site functionality per se?

Reservation + �alloc./termin. requests

OpenStack + BlazarX�w/ policies for dealing with reserved resources

Option 3 - flow chart

Option 4 - Super-VIM

Super-VIM

Consumer A

Consumer B

Pros & Cons:

+ code maintainted by OS

- Requires eXtended Blazar

- Requires OS to handle all reservation� policies/logic and reservation database

​

Reservation + �alloc./termin. requests

Shim-layer / Super-VIM�(w/ API translation)

OpenStack + BlazarX�w/ policies for dealing with reserved resources

Another Resource Provider�w/ policies for dealing with reserved resources

Shim-layer is providing abstraction layer to provide:

• multisite support
• multi-provider support: API translation from ETSI NFV to OpenStack/VMWare/...

Option 3 - flow chart

BACKUP SLIDES

Implementation Architecture

(To Be Updated)

Demo Implementation Status

​

​

Consumers (NFVO, VNFM)

OpenStack

Simulator, Release X/Y, Distro A/B�

​

​

​

​

​

​

​

​

Shim-layer�

​

​

​

​

​

​

​

OPNFV Promise Module

​

​

​

​

Capacity Mgt

​

​

​

​

Reservation

Capacity

Utilization

Policies

​

​

​

​

Allocation

​

​

​

​

​

​

NFV-MANO

Module

Pkgcloud

• Implemented
• 3 Capacity Intent NBIs
• query/increase/decrease capacity (See p13)
• 4 Reservation Intent NBIs
• create/query/update/cancel reservation (See p14)

​

Query Capacity

• Extract of the input schema
• curl -X OPTIONS localhost:5000/restjson/opnfv-promise/query-capacity

{

“POST”: {

“description”: “Check available capacity information about

a specified resource collection”,

“input”: {

“synth”: “object”,

“leaf”: {

“capacity”: {

“type”: {

“enumeration”: {

“enum”: {

“total”:  {

“value”: 0

},

“reserved”: {

“value”: 1

},

“usage”: {

“value”: 2

},

“available”: {

“value”: 3

....

​

• Query for available capacity over a time window
• Default Resource Pool is defined here: https://github.com/opnfv/promise/blob/master/opnfv-promise.json
• curl -X POST localhost:5000/restjson/opnfv-promise/query-capacity -H ‘Content-Type: application/json’ -d ‘{ “capacity”: 3, “start”: “2015-10-15T00:00:00Z”, “end”: “2015-10-17T00:00:00Z”}’

​

“zone”: {

“type”: {

“instance-identifier”: {

“ct: instance-type”: “nfvi:AvailabilityZone”

}

}

},

“window”: {

“description”: “Matches entries that are within the specified start/end time window”,

“leaf”: {

“start”: {

“type”: “yang:date-and-time”

},

“end”: {

“type”: “yang:date-and-time”

},

“scope”: {

“type”: {

“enumeration”: {

“enum”: {

“exclusive”: {

“description”: “Matches entries that start AND end within the window”,

“value”: 0

},

“inclusive”: {

“description”: “Matches entries that start OR end within the window”,

“value”: 1

….

Create Reservation

• Extract of the input schema
• curl -X OPTIONS localhost:5000/restjson/opnfv-promise/create-reservation

​

{

“POST”: {

“description”: “Make a request to the reservation system to

reserve resources”,

“status”: “unavailable”,

“input”: {

“synth”: “object”,

“description”: “Information model capturing parameters for

describing a collection of resource capacity and resource

elements”

….

“start”: {

“type”: “yang:date-and-time”

},

“end”: {

“type”: “yang:date-and-time”

…

​

​

​

​

​

​

​

​

​

​

​

​

​

“container”: {

“capacity: {

“uses”: {},

“leaf”: {

“cores”: {

“type: “int16”,

“default”: “0”

},

“ram”: {

“type”: “int32”,

“default”: “0”,

“units”: “MB”

…

“leaf-list”: {

“elements”: {

“type”: {

“instance-identifier”: {

“ct:instance-type”: “nfvi:ResourceElement”,

“require-instance”: true

....

• Create reservation for future use
• curl -X POST localhost:5000/restjson/opnfv-promise/create-reservation -H ‘Content-Type: application/json’ -d ‘{“start”: “2015-10-19T00:00:00Z”, “capacity”: {“instances”: 2, “addresses”: 1, “gigabytes”: 10}}’

Promise – Resource Reservation

17

�

Information Elements

Promise – Resource Reservation

18

�

Promise – Capacity Management

19

�

Information Elements

Promise – Capacity Management

20

�