1 General Requirements Background and Terminology
\r
2 -----------------------------------------------
\r
4 Terminologies and definitions
\r
5 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\r
8 The term is an abbreviation for Network Function Virtualization
\r
9 Infrastructure; sometimes it is also referred as data plane in this
\r
13 The term is an abbreviation for Virtual Infrastructure Management;
\r
14 sometimes it is also referred as control plane in this document.
\r
17 The term refers to network service providers and Virtual Network
\r
18 Function (VNF) providers.
\r
21 The term refers to a subscriber of the Operator's services.
\r
24 The term refers to a service provided by an Operator to its
\r
25 End-users using a set of (virtualized) Network Functions
\r
27 Infrastructure Services
\r
28 The term refers to services provided by the NFV Infrastructure and the
\r
29 the Management & Orchestration functions to the VNFs. I.e.
\r
30 these are the virtual resources as perceived by the VNFs.
\r
33 The term refers to an upgrade that results in no service outage
\r
37 The term refers to an upgrade strategy that upgrades each node or
\r
38 a subset of nodes in a wave style rolling through the data centre. It
\r
39 is a popular upgrade strategy to maintain service availability.
\r
41 Parallel Universe Upgrade
\r
42 The term refers to an upgrade strategy that creates and deploys
\r
43 a new universe - a system with the new configuration - while the old
\r
44 system continues running. The state of the old system is transferred
\r
45 to the new system after sufficient testing of the new system.
\r
47 Infrastructure Resource Model
\r
48 The term refers to the representation of infrastructure resources,
\r
49 namely: the physical resources, the virtualization
\r
50 facility resources and the virtual resources.
\r
53 The term refers to a hardware pieces of the NFV infrastructure, which may
\r
54 also include the firmware which enables the hardware.
\r
57 The term refers to a resource, which is provided as services built on top
\r
58 of the physical resources via the virtualization facilities; in particular,
\r
59 they are the resources on which VNF entities are deployed, e.g.
\r
60 the VMs, virtual switches, virtual routers, virtual disks etc.
\r
62 Visualization Facility
\r
63 The term refers to a resource that enables the creation
\r
64 of virtual environments on top of the physical resources, e.g.
\r
65 hypervisor, OpenStack, etc.
\r
68 The term refers to a choreography that describes how the upgrade should
\r
69 be performed in terms of its targets (i.e. upgrade objects), the
\r
70 steps/actions required of upgrading each, and the coordination of these
\r
71 steps so that service availability can be maintained. It is an input to an
\r
72 upgrade tool (Escalator) to carry out the upgrade.
\r
75 The duration of an upgrade characterized by the time elapsed between its
\r
76 initiation and its completion. E.g. from the moment the execution of an
\r
77 upgrade campaign has started until it has been committed. Depending on
\r
78 the upgrade method and its target some parts of the system may be in a more
\r
82 The period of time during which a given service is not provided is referred
\r
83 as the outage of that given service. If a subsystem or the entire system
\r
84 does not provide any service, it is the outage of the given subsystem or the
\r
85 system. Smooth upgrade means upgrade with no outage for the user plane, i.e.
\r
86 no VNF should experience service outage.
\r
89 The term refers to a failure handling strategy that reverts the changes
\r
90 done by a potentially failed upgrade execution one by one in a reverse order.
\r
91 I.e. it is like undoing the changes done by the upgrade.
\r
94 The term refers to a failure handling strategy that reverts the changes
\r
95 done by an upgrade by restoring the system from some backup data. This
\r
96 results in the loss of any data persisted since the backup has been taken.
\r
99 The term refers to a failure handling strategy applied after a restore
\r
100 (from a backup) opertaion to recover any loss of data persisted between
\r
101 the time the backup has been taken and the moment it is restored. Rollforward
\r
102 requires that data that needs to survive the restore operation is logged at
\r
103 a location not impacted by the restore so that it can be re-applied to the
\r
104 system after its restoration from the backup.
\r
107 The term refers to an upgrade in which an earlier version of the software
\r
108 is restored through the upgrade procedure. A system can be downgraded to any
\r
109 earlier version and the compatibility of the versions will determine the
\r
110 applicable upgrade strategies and whether service outage can be avoided.
\r
111 In particular any data conversion needs special attention.
\r
121 Most cloud infrastructures support the dynamic addition/removal of
\r
122 hardware. Accordingly a hardware upgrade could be done by adding the new
\r
123 piece of hardware and removing the old one. From the persepctive of smooth
\r
124 upgrade the orchestration/scheduling of this actions is the primary concern.
\r
125 Upgrading a physical resource may involve as well the upgrade of its firmware
\r
126 and/or modifying its configuration data. This may require the restart of the
\r
134 Addition and removal of virtual resources may be initiated by the users or be
\r
135 a result of an elasticity action. Users may also request the upgrade of their
\r
136 virtual resources using a new VM image.
\r
138 .. Needs to be moved to requirement section: Escalator should facilitate such an
\r
139 option and allow for a smooth upgrade.
\r
141 On the other hand changes in the infrastructure, namely, in the hardware and/or
\r
142 the virtualization facility resources may result in the upgrade of the virtual
\r
143 resources. For example if by some reason the hypervisor is changed and
\r
144 the current VMs cannot be migrated to the new hypervisor - they are
\r
145 incompatible - then the VMs need to be upgraded too. This is not
\r
146 something the NFVI user (i.e. VNFs ) would know about. In such cases
\r
147 smooth upgrade is essential.
\r
150 Virtualization Facility Resources
\r
151 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
\r
153 Based on the functionality they provide, virtualization facility
\r
154 resources could be divided into computing node, networking node,
\r
155 storage node and management node.
\r
157 The possible upgrade objects in these nodes are addressed below:
\r
158 (Note: hardware based virtualization may be considered as virtualization
\r
159 facility resource, but from escalator perspective, it is better to
\r
160 consider it as part of the hardware upgrade. )
\r
166 2. Hypvervisor and virtual switch
\r
168 3. Other kernel modules, like driver
\r
170 4. User space software packages, like nova-compute agents and other
\r
171 control plane programs.
\r
173 Updating 1 and 2 will cause the loss of virtualzation functionality of
\r
174 the compute node, which may lead to data plane services interruption
\r
175 if the virtual resource is not redudant.
\r
177 Updating 3 might result the same.
\r
179 Updating 4 might lead to control plane services interruption if not an
\r
182 **Networking node**
\r
184 1. OS kernel, optional, not all switches/routers allow the upgrade their
\r
185 OS since it is more like a firmware than a generic OS.
\r
187 2. User space software package, like neutron agents and other control
\r
190 Updating 1 if allowed will cause a node reboot and therefore leads to
\r
191 data plane service interruption if the virtual resource is not
\r
194 Updating 2 might lead to control plane services interruption if not an
\r
199 1. OS kernel, optional, not all storage nodes allow the upgrade their OS
\r
200 since it is more like a firmware than a generic OS.
\r
204 3. User space software packages, control plane programs
\r
206 Updating 1 if allowed will cause a node reboot and therefore leads to
\r
207 data plane services interruption if the virtual resource is not
\r
210 Update 2 might result in the same.
\r
212 Updating 3 might lead to control plane services interruption if not an
\r
215 **Management node**
\r
219 2. Kernel modules, like driver
\r
221 3. User space software packages, like database, message queue and
\r
222 control plane programs.
\r
224 Updating 1 will cause a node reboot and therefore leads to control
\r
225 plane services interruption if not an HA deployment. Updating 2 might
\r
226 result in the same.
\r
228 Updating 3 might lead to control plane services interruption if not an
\r
235 Upgrade Granularity
\r
236 ~~~~~~~~~~~~~~~~~~~
\r
238 The granularity of an upgrade can be characterized from two perspective:
\r
239 - the physical dimension and
\r
240 - the software dimension
\r
246 The physical dimension characterizes the number of similar upgrade objects
\r
247 targeted by the upgrade, i.e. whether it is full / partial upgrade of a
\r
248 data centre, cluster, zone.
\r
249 Because of the upgrade of a data centre or a zone, it may be divided into
\r
250 several batches. Thus there is a need for efficiency in the execution of
\r
251 upgrades of potentially huge number of upgrade objects while still maintain
\r
252 availability to fulfill the requirement of smooth upgrade.
\r
254 The upgrade of a cloud environment (cluster) may also
\r
255 be partial. For example, in one cloud environment running a number of
\r
256 VNFs, we may just try to upgrade one of them to check the stability and
\r
257 performance, before we upgrade all of them.
\r
258 Thus there is a need for proper organization of the artifacts associated with
\r
259 the different upgrade objects. Also the different versions should be able
\r
260 to coextist beyond the upgrade period.
\r
262 From this perspective special attention may be needed when upgrading
\r
263 objects that are collaborating in a redundancy schema as in this case
\r
264 different versions not only need to coexist but also collaborate. This
\r
265 puts requirement on the upgrade objects primarily. If this is not possible
\r
266 the upgrade campaign should be designed in such a way that the proper
\r
267 isolation is ensured.
\r
272 The software dimension of the upgrade characterizes the upgrade object
\r
273 type targeted and the combination in which they are upgraded together.
\r
275 Even though the upgrade may
\r
276 initially target only one type of upgrade object, e.g. the hypervisor
\r
277 the dependency of other upgrade objects on this initial target object may
\r
278 require their upgrade as well. I.e. the upgrades need to be combined. From this
\r
279 perspective the main concern is compatibility of the dependent and
\r
280 sponsor objects. To take into consideration of these dependencies
\r
281 they need to be described together with the version compatility information.
\r
282 Breaking dependencies is the major cause of outages during upgrades.
\r
284 In other cases it is more efficient to upgrade a combination of upgrade
\r
285 objects than to do it one by one. One aspect of the combination is how
\r
286 the upgrade packages can be combined, whether a new image can be created for
\r
287 them before hand or the different packages can be installed during the upgrade
\r
288 independently, but activated together.
\r
290 The combination of upgrade objects may span across
\r
291 layers (e.g. software stack in the host and the VM of the VNF).
\r
292 Thus, it may require additional coordination between the management layers.
\r
294 With respect to each upgrade object type and even stacks we can
\r
295 distingush major and minor upgrades:
\r
299 Upgrades between major releases may introducing significant changes in
\r
300 function, configuration and data, such as the upgrade of OPNFV from
\r
301 Arno to Brahmaputra.
\r
305 Upgrades inside one major releases which would not leads to changing
\r
306 the structure of the platform and may not infect the schema of the
\r
312 Considering availability and therefore smooth upgrade, one of the major
\r
313 concerns is the predictability and control of the outcome of the different
\r
314 upgrade operations. Ideally an upgrade can be performed without impacting any
\r
315 entity in the system, which means none of the operations change or potentially
\r
316 change the behaviour of any entity in the system in an uncotrolled manner.
\r
317 Accordingly the operations of such an upgrade can be performed any time while
\r
318 the system is running, while all the entities are online. No entity needs to be
\r
319 taken offline to avoid such adverse effects. Hence such upgrade operations
\r
320 are referred as online operations. The effects of the upgrade might be activated
\r
321 next time it is used, or may require a special activation action such as a
\r
322 restart. Note that the activation action provides more control and predictability.
\r
324 If an entity's behavior in the system may change due to the upgrade it may
\r
325 be better to take it offline for the time of the relevant upgrade operations.
\r
326 The main question is however considering the hosting relation of an upgrade
\r
327 object what hosted entities are impacted. Accordingly we can identify a scope
\r
328 which is impacted by taking the given upgrade object offline. The entities
\r
329 that are in the scope of impact may need to be taken offline or moved out of
\r
330 this scope i.e. migrated.
\r
332 If the impacted entity is in a different layer managed by another manager
\r
333 this may require coordination because taking out of service some
\r
334 infrastructure resources for the time of their upgrade which support virtual
\r
335 resources used by VNFs that should not experience outages. The hosted VNFs
\r
336 may or may not allow for the hot migration of their VMs. In case of migration
\r
337 the VMs placement policy should be considered.
\r
344 As the OPNFV end-users are primarily Telecom operators, the network
\r
345 services provided by the VNFs deployed on the NFVI should meet the
\r
346 requirement of 'Carrier Grade'.::
\r
348 In telecommunication, a "carrier grade" or"carrier class" refers to a
\r
349 system, or a hardware or software component that is extremely reliable,
\r
350 well tested and proven in its capabilities. Carrier grade systems are
\r
351 tested and engineered to meet or exceed "five nines" high availability
\r
352 standards, and provide very fast fault recovery through redundancy
\r
353 (normally less than 50 milliseconds). [from wikipedia.org]
\r
355 "five nines" means working all the time in ONE YEAR except 5'15".
\r
359 We have learnt that a well prepared upgrade of OpenStack needs 10
\r
360 minutes. The major time slot in the outage time is used spent on
\r
361 synchronizing the database. [from ' Ten minutes OpenStack Upgrade? Done!
\r
364 This 10 minutes of downtime of the OpenStack services however did not impact the
\r
365 users, i.e. the VMs running on the compute nodes. This was the outage of
\r
366 the control plane only. On the other hand with respect to the
\r
367 preparations this was a manually tailored upgrade specific to the
\r
368 particular deployment and the versions of each OpenStack service.
\r
370 The project targets to achieve a more generic methodology, which however
\r
371 requires that the upgrade objects fulfil certain requirements. Since
\r
372 this is only possible on the long run we target first the upgrade
\r
373 of the different VIM services from version to version.
\r
377 1. Can we manage to upgrade OPNFV in only 5 minutes?
\r
379 .. <MT> The first question is whether we have the same carrier grade
\r
380 requirement on the control plane as on the user plane. I.e. how
\r
381 much control plane outage we can/willing to tolerate?
\r
382 In the above case probably if the database is only half of the size
\r
383 we can do the upgrade in 5 minutes, but is that good? It also means
\r
384 that if the database is twice as much then the outage is 20
\r
386 For the user plane we should go for less as with two release yearly
\r
387 that means 10 minutes outage per year.
\r
389 .. <Malla> 10 minutes outage per year to the users? Plus, if we take
\r
390 control plane into the consideration, then total outage will be
\r
391 more than 10 minute in whole network, right?
\r
393 .. <MT> The control plane outage does not have to cause outage to
\r
394 the users, but it may of course depending on the size of the system
\r
395 as it's more likely that there's a failure that needs to be handled
\r
396 by the control plane.
\r
398 2. Is it acceptable for end users ? Such as a planed service
\r
399 interruption will lasting more than ten minutes for software
\r
402 .. <MT> For user plane, no it's not acceptable in case of
\r
403 carrier-grade. The 5' 15" downtime should include unplanned and
\r
406 .. <Malla> I go agree with Maria, it is not acceptable.
\r
408 3. Will any VNFs still working well when VIM is down?
\r
410 .. <MT> In case of OpenStack it seems yes. .:)
\r
412 The maximum duration of an upgrade
\r
413 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
\r
415 The duration of an upgrade is related to and proportional with the
\r
416 scale and the complexity of the OPNFV platform as well as the
\r
417 granularity (in function and in space) of the upgrade.
\r
419 .. <Malla> Also, if is a partial upgrade like module upgrade, it depends
\r
420 also on the OPNFV modules and their tight connection entities as well.
\r
422 .. <MT> Since the maintenance window is shrinking and becoming non-existent
\r
423 the duration of the upgrade is secondary to the requirement of smooth upgrade.
\r
424 But probably we want to be able to put a time constraint on each upgrade
\r
425 during which it must complete otherwise it is considered failed and the system
\r
426 should be rolled back. I.e. in case of automatic execution it might not be clear
\r
427 if an upgrade is long or just hanging. The time constraints may be a function
\r
428 of the size of the system in terms of the upgrade object(s).
\r
430 The maximum duration of a roll back when an upgrade is failed
\r
431 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
\r
433 The duration of a roll back is short than the corresponding upgrade. It
\r
434 depends on the duration of restore the software and configure data from
\r
435 pre-upgrade backup / snapshot.
\r
437 .. <MT> During the upgrade process two types of failure may happen:
\r
438 In case we can recover from the failure by undoing the upgrade
\r
439 actions it is possible to roll back the already executed part of the
\r
440 upgrade in graceful manner introducing no more service outage than
\r
441 what was introduced during the upgrade. Such a graceful roll back
\r
442 requires typically the same amount of time as the executed portion of
\r
443 the upgrade and impose minimal state/data loss.
\r
445 .. <MT> Requirement: It should be possible to roll back gracefully the
\r
446 failed upgrade of stateful services of the control plane.
\r
447 In case we cannot recover from the failure by just undoing the
\r
448 upgrade actions, we have to restore the upgraded entities from their
\r
449 backed up state. In other terms the system falls back to an earlier
\r
450 state, which is typically a faster recovery procedure than graceful
\r
451 roll back and depending on the statefulness of the entities involved it
\r
452 may result in significant state/data loss.
\r
454 .. <MT> Two possible types of failures can happen during an upgrade
\r
456 .. <MT> We can recover from the failure that occurred in the upgrade process:
\r
457 In this case, a graceful rolling back of the executed part of the
\r
458 upgrade may be possible which would "undo" the executed part in a
\r
459 similar fashion. Thus, such a roll back introduces no more service
\r
460 outage during an upgrade than the executed part introduced. This
\r
461 process typically requires the same amount of time as the executed
\r
462 portion of the upgrade and impose minimal state/data loss.
\r
464 .. <MT> We cannot recover from the failure that occurred in the upgrade
\r
465 process: In this case, the system needs to fall back to an earlier
\r
466 consistent state by reloading this backed-up state. This is typically
\r
467 a faster recovery procedure than the graceful roll back, but can cause
\r
468 state/data loss. The state/data loss usually depends on the
\r
469 statefulness of the entities whose state is restored from the backup.
\r
471 The maximum duration of a VNF interruption (Service outage)
\r
472 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
\r
474 Since not the entire process of a smooth upgrade will affect the VNFs,
\r
475 the duration of the VNF interruption may be shorter than the duration
\r
476 of the upgrade. In some cases, the VNF running without the control
\r
477 from of the VIM is acceptable.
\r
479 .. <MT> Should require explicitly that the NFVI should be able to
\r
480 provide its services to the VNFs independent of the control plane?
\r
482 .. <MT> Requirement: The upgrade of the control plane must not cause
\r
483 interruption of the NFVI services provided to the VNFs.
\r
485 .. <MT> With respect to carrier-grade the yearly service outage of the
\r
486 VNF should not exceed 5' 15" regardless whether it is planned or
\r
487 unplanned outage. Considering the HA requirements TL-9000 requires an
\r
488 end-to-end service recovery time of 15 seconds based on which the ETSI
\r
489 GS NFV-REL 001 V1.1.1 (2015-01) document defines three service
\r
490 availability levels (SAL). The proposed example service recovery times
\r
491 for these levels are:
\r
493 .. <MT> SAL1: 5-6 seconds
\r
495 .. <MT> SAL2: 10-15 seconds
\r
497 .. <MT> SAL3: 20-25 seconds
\r
499 .. <Pva> my comment was actually that the downtime metrics of the
\r
500 underlying elements, components and services are small fraction of the
\r
501 total E2E service availability time. No-one on the E2E service path
\r
502 will get the whole downtime allocation (in this context it includes
\r
503 upgrade process related outages for the services provided by VIM etc.
\r
504 elements that are subject to upgrade process).
\r
506 .. <MT> So what you are saying is that the upgrade of any entity
\r
507 (component, service) shouldn't cause even this much service
\r
508 interruption. This was the reason I brought these figures here as well
\r
509 that they are posing some kind of upper-upper boundary. Ideally the
\r
510 interruption is in the millisecond range i.e. no more than a
\r
511 switch-over or a live migration.
\r
513 .. <MT> Requirement: Any interruption caused to the VNF by the upgrade
\r
514 of the NFVI should be in the sub-second range.
\r
516 .. <MT]> In the future we also need to consider the upgrade of the NFVI,
\r
517 i.e. HW, firmware, hypervisors, host OS etc.