1 Detailed architecture and message flows
2 =======================================
4 Within the Promise project we consider two different architectural options, i.e.
5 a *shim-layer* based architecture and an architecture targeting at full
6 OpenStack *integration*.
8 Shim-layer architecture
9 -----------------------
11 The *shim-layer architecture* is using a layer on top of OpenStack to provide
12 the capacity management, resource reservation, and resource allocation features.
15 Detailed Message Flows
16 ^^^^^^^^^^^^^^^^^^^^^^
18 Note, that only selected parameters for the messages are shown. Refer to
19 :ref:`northbound_API` and Annex :ref:`yang_schema` for a full set of message
22 Resource Capacity Management
23 """"""""""""""""""""""""""""
25 .. figure:: images/figure5_new.png
29 Capacity Management Scenario
31 :numref:`figure5` shows a detailed message flow between the consumers and the
32 capacity management functional blocks inside the shim-layer. It has the
35 * Step 1a: The Consumer sends a *query-capacity* request to Promise
36 using some filter like time-windows or resource type. The capacity is
37 looked up in the shim-layer capacity map.
39 * Step 1b: The shim-layer will respond with information about the
40 total, available, reserved, and used (allocated) capacities matching the
43 * Step 2a: The Consumer can send *increase/decrease-capacity* requests
44 to update the capacity available to the reservation system. It can be
45 100% of available capacity in the given provider/source or only a subset,
46 i.e., it can allow for leaving some "buffer" in the actual NFVI to be
47 used outside the Promise shim-layer or for a different reservation
48 service instance. It can also be used to inform the reservation system
49 that from a certain time in the future, additional resources can be
50 reserved (e.g. due to a planned upgrade of the capacity), or the
51 available capacity will be reduced (e.g. due to a planned downtime of
52 some of the resources).
54 * Step 2b: The shim-layer will respond with an ACK/NACK message.
56 * Step 3a: Consumers can subscribe for capacity-change events using a
59 * Step 3b: Each successful subscription is responded with a
62 * Step 4: The shim-layer monitors the capacity information for the
63 various types of resources by periodically querying the various
64 Controllers (e.g. Nova, Neutron, Cinder) or by creating event alarms in
65 the VIM (e.g. with Ceilometer for OpenStack) and updates capacity
66 information in its capacity map.
68 * Step 5: Capacity changes are notified to the Consumer.
73 .. figure:: images/figure6_new.png
77 Resource Reservation for Future Use Scenario
79 :numref:`figure6` shows a detailed message flow between the Consumer and the
80 resource reservation functional blocks inside the shim-layer. It has the
83 * Step 1a: The Consumer creates a resource reservation request for
84 future use by setting a start and end time for the reservation as well as
85 more detailed information about the resources to be reserved. The Promise
86 shim-layer will check the free capacity in the given time window and in
87 case sufficient capacity exists to meet the reservation request, will
88 mark those resources "reserved" in its reservation map.
90 * Step 1b: If the reservation was successful, a reservation_id and
91 status of the reservation will be returned to the Consumer. In case the
92 reservation cannot be met, the shim-layer may return information about
93 the maximum capacity that could be reserved during the requested time
94 window and/or a potential time window where the requested (amount of)
95 resources would be available.
97 * Step 2a: Reservations can be updated using an *update-reservation*,
98 providing the reservation_id and the new reservation_data. Promise
99 Reservation Manageer will check the feasibility to update the reservation
102 * Step 2b: If the reservation was updated successfully, a
103 reservation_id and status of the reservation will be returned to the
104 Consumer. Otherwise, an appropriate error message will be returned.
106 * Step 3a: A *cancel-reservation* request can be used to withdraw an
107 existing reservation. Promise will update the reservation map by removing
108 the reservation as well as the capacity map by adding the freed capacity.
110 * Step 3b: The response message confirms the cancelation.
112 * Step 4a: Consumers can also issue *query-reservation* requests to
113 receive a list of reservation. An input filter can be used to narrow down
114 the query, e.g., only provide reservations in a given time window.
115 Promise will query its reservation map to identify reservations matching
118 * Step 4b: The response message contains information about all
119 reservations matching the input filter. It also provides information
120 about the utilization in the requested time window.
122 * Step 5a: Consumers can subscribe for reservation-change events using
125 * Step 5b: Each successful subscription is responded with a
128 * Step 6a: Promise synchronizes the available and used capacity with
131 * Step 6b: In certain cases, e.g., due a failure in the underlying
132 hardware, some reservations cannot be kept up anymore and have to be
133 updated or canceled. The shim-layer will identify affected reservations
134 among its reservation records.
136 * Step 7: Subscribed Consumers will be informed about the updated
137 reservations. The notification contains the updated reservation_data and
138 new status of the reservation. It is then up to the Consumer to take
139 appropriate actions in order to ensure high priority reservations are
140 favored over lower priority reservations.
145 .. figure:: images/figure7_new.png
151 :numref:`figure7` shows a detailed message flow between the Consumer, the
152 functional blocks inside the shim-layer, and the VIM. It has the following
155 * Step 1a: The Consumer sends a *create-instance* request providing
156 information about the resources to be reserved, i.e., provider_id
157 (optional in case of only one provider), name of the instance, the
158 requested flavour and image, etc. If the allocation is against an
159 existing reservation, the reservation_id has to be provided.
161 * Step 1b: If a reservation_id was provided, Promise checks if a
162 reservation with that ID exists, the reservation start time has arrived
163 (i.e. the reservation is active), and the required capacity for the
164 requested flavor is within the available capacity of the reservation. If
165 those conditions are met, Promise creates a record for the allocation
166 (VMState="INITIALIZED") and update its databases. If no reservation_id
167 was provided in the allocation request, Promise checks whether the
168 required capacity to meet the request can be provided from the available,
169 non-reserved capacity. If yes, Promise creates a record for the
170 allocation and update its databases. In any other case, Promise rejects
171 the *create-instance* request.
173 * Step 2: In the case the *create-instance* request was rejected,
174 Promise responds with a "status=rejected" providing the reason of the
175 rejection. This will help the Consumer to take appropriate actions, e.g.,
176 send an updated *create-instance* request. The allocation work flow will
177 terminate at this step and the below steps are not executed.
179 * Step 3a: If the *create-instance* request was accepted and a related
180 allocation record has been created, the shim-layer issues a
181 *createServer* request to the VIM Controller providing all information to
182 create the server instance.
184 * Step 3b: The VIM Controller sends an immediate reply with an
185 instance_id and starts the VIM-internal allocation process.
187 * Step 4: The Consumer gets an immediate response message with
188 allocation status "in progress" and the assigned instance_id.
190 * Step 5a+b: The consumer subscribes to receive notifications about
191 allocation events related to the requested instance. Promise responds
192 with an acknowledgment including a subscribe_id.
194 * Step 6: In parallel to the previous step, Promise shim-layer creates
195 an alarm in Aodh to receive notifications about all changes to the
196 VMState for instance_id.
198 * Step 7a: The VIM Controller notifies all instance related events to
199 Ceilometer. After the allocation has been completed or failed, it sends
200 an event to Ceilometer. This triggers the OpenStack alarming service Aodh
201 to notify the new VMState (e.g. ACTIVE and ERROR) to the shim-layer that
202 updates its internal allocation records.
204 * Step 7b: Promise sends a notification message to the subscribed
205 Consumer with information on the allocated resources including their new
208 * Step 8a+b: Allocated instances can be terminated by the Consumer by
209 sending a *destroy-instance* request to the shim-layer. Promise responds
210 with an acknowledgment and the new status "DELETING" for the instance.
212 * Step 9a: Promise sends a *deleteServer* request for the instance_id
213 to the VIM Controller.
215 * Step 10a: After the instance has been deleted, an event alarm is
216 sent to the shim-layer that updates its internal allocation records and
217 capacity utilization.
219 * Step 10b: The shim-layer also notifies the subscribed Consumer about
220 the successfully destroyed instance.
226 .. note:: This section is to be updated
228 In the following, the internal logic and operations of the shim-layer will be
229 explained in more detail, e.g. the "check request" (step 1b in
230 :numref:`figure7` of the allocation work flow).
234 Integrated architecture
235 -----------------------
237 The *integrated architecture* aims at full integration with OpenStack.
239 Detailed Message Flows
240 ^^^^^^^^^^^^^^^^^^^^^^
247 .. note:: to be specified