1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
|
Detailed architecture and message flows
=======================================
Within the Promise project we consider two different architectural options,
i.e. a *shim-layer* based architecture and an architecture targeting at full
OpenStack *integration*.
Shim-layer architecture
-----------------------
The *shim-layer architecture* is using a layer on top of OpenStack to provide
the capacity management, resource reservation, and resource allocation
features.
Detailed Message Flows
^^^^^^^^^^^^^^^^^^^^^^
.. note:: This section has to be updated.
Resource Capacity Management
""""""""""""""""""""""""""""
.. figure:: images/figure5.png
:name: figure5
:width: 90%
Capacity Management Scenario
:numref:`figure5` shows a detailed message flow between the consumers and the
functional blocks inside the VIM and has the following steps:
Step 1: The consumer subscribes to capacity change notifications
Step 2: The Capacity Manager monitors the capacity information for the various
types of resources by querying the various Controllers (e.g. Nova, Neutron,
Cinder), either periodically or on demand and updates capacity information in
the Capacity Map
Step 3: Capacity changes are notified to the consumer
Step 4: The consumer queries the Capacity Manager to retrieve capacity detailed
information
Resource Reservation
""""""""""""""""""""
.. figure:: images/figure6.png
:name: figure6
:width: 90%
Resource Reservation for Future Use Scenario
:numref:`figure6` shows a detailed message flow between the consumers and the
functional blocks inside the VIM and has the following steps:
Step 1: The consumer creates a resource reservation request for future use by
setting a start and end time for the allocation
Step 2: The consumer gets an immediate reply with a reservation status message
"reservationStatus" and an identifier to be used with this reservation instance
"reservationID"
Step 3: The consumer subscribes to reservation notification events
Step 4: The Resource Reservation Manager checks the feasibility of the
reservation request by consulting the Capacity Manager
Step 5: The Resource Reservation Manager reserves the resources and stores the
list of reservations IDs generated by the Controllers (e.g. Nova, Neutron,
Cinder) in the Reservation Map
Step 6: Once the reservation process is completed, the VIM sends a notification
message to the consumer with information on the reserved resources
Step 7: When start time arrives, the consumer creates a resource allocation
request.
Step 8: The consumer gets an immediate reply with an allocation status message
"allocationStatus".
Step 9: The consumer subscribes to allocation notification events
Step 10: The Resource Allocation Manager allocates the reserved resources. If
not all reserved resources are allocated before expiry, the reserved resources
are released and a notification is sent to the consumer
Step 11: Once the allocation process is completed, the VIM sends a notification
message to the consumer with information on the allocated resources
Integrated architecture
-----------------------
The *integrated architecture* aims at full integration with OpenStack.
This means that it is planned to use the already existing OpenStack APIs
extended with the reservation capabilities.
The advantage of this approach is that we don't need to re-model the
complex resource structure we have for the virtual machines and the
corresponding infrastructure.
The atomic item is the virtual machine with the minimum set of resources
it requires to be able to start it up. It is important to state that
resource reservation is handled on VM instance level as opposed to standalone
resources like CPU, memory and so forth. As the placement is an important
aspect in order to be able to use the reserved resources it provides the
constraint to handle resources in groups.
The placement constraint also makes it impossible to use a quota management
system to solve the base use case described earlier in this document.
OpenStack had a project called Blazar, which was created in order to provide
resource reservation functionality in cloud environments. It uses the Shelve
API of Nova, which provides a sub-optimal solution. Due to the fact that this
feature blocks the reserved resources this solution cannot be considered to
be final. Further work is needed to reach a more optimal stage, where the
Nova scheduler is intended to be used to schedule the resources for future
use to make the reservations.
Phases of the work
^^^^^^^^^^^^^^^^^^
The work has two main stages to reach the final solution. The following main work items
are on the roadmap for this approach:
#. Sub-optimal solution by using the shelve API of Nova through the Blazar project:
* Fix the code base of the Blazar project:
Due to integration difficulties the Blazar project got suspended. Since the last
activities in that repository the OpenStack code base and environment changed
significantly, which means that the project's code base needs to be updated to the
latest standards and has to be able to interact with the latest version of the
other OpenStack services.
* Update the Blazar API:
The REST API needs to be extended to contain the attributes for the reservation
defined in this document. This activity shall include testing towards the new API.
#. Use Nova scheduler to avoid blocking the reserved resources:
* Analyze the Nova scheduler:
The status and the possible interface between the resource reservation system and
the Nova scheduler needs to be identified. It is crucial to achieve a much more
optimal solution than what the current version of Blazar can provide. The goal is
to be able to use the reserved resources before the reservation starts. In order to
be able to achieve this we need the scheduler to do scheduling for the future
considering the reservation intervals that are specified in the request.
* Define a new design based on the analysis and start the work on it:
The design for the more optimal solution can be defined only after analyzing the
structure and capabilities of the Nova scheduler.
* This phase can be started in parallel with the previous one.
Detailed Message Flows
^^^^^^^^^^^^^^^^^^^^^^
.. note:: to be done
Resource Reservation
""""""""""""""""""""
.. note:: to be specified
|
