requirements/02-use_cases.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3
   4 Use cases and scenarios
   5 =======================
   6
   7 Telecom services often have very high requirements on service performance. As a
   8 consequence they often utilize redundancy and high availability (HA) mechanisms
   9 for both the service and the platform. The HA support may be built-in or
  10 provided by the platform. In any case, the HA support typically has a very fast
  11 detection and reaction time to minimize service impact. The main changes
  12 proposed in this document are about making a clear distinction between fault
  13 management and recovery a) within the VIM/NFVI and b) High Availability support
  14 for VNFs on the other, claiming that HA support within a VNF or as a service
  15 from the platform is outside the scope of Doctor and is discussed in the High
  16 Availability for OPNFV project. Doctor should focus on detecting and remediating
  17 faults in the NFVI. This will ensure that applications come back to a fully
  18 redundant configuration faster than before.
  19
  20 As an example, Telecom services can come with an Active-Standby (ACT-STBY)
  21 configuration which is a (1+1) redundancy scheme. ACT and STBY nodes (aka
  22 Physical Network Function (PNF) in ETSI NFV terminology) are in a hot standby
  23 configuration. If an ACT node is unable to function properly due to fault or any
  24 other reason, the STBY node is instantly made ACT, and affected services can be
  25 provided without any service interruption.
  26
  27 The ACT-STBY configuration needs to be maintained. This means, when a STBY node
  28 is made ACT, either the previously ACT node, after recovery, shall be made STBY,
  29 or, a new STBY node needs to be configured. The actual operations to
  30 instantiate/configure a new STBY are similar to instantiating a new VNF and
  31 therefore are outside the scope of this project.
  32
  33 The NFVI fault management and maintenance requirements aim at providing fast
  34 failure detection of physical and virtualized resources and remediation of the
  35 virtualized resources provided to Consumers according to their predefined
  36 request to enable applications to recover to a fully redundant mode of
  37 operation.
  38
  39 1. Fault management/recovery using ACT-STBY configuration (Triggered by critical
  40    error)
  41 2. Preventive actions based on fault prediction (Preventing service stop by
  42    handling warnings)
  43 3. VM Retirement (Managing service during NFVI maintenance, i.e. H/W,
  44    Hypervisor, Host OS, maintenance)
  45
  46 Faults
  47 ------
  48
  49 .. _uc-fault1:
  50
  51 Fault management using ACT-STBY configuration
  52 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  53
  54 In :numref:`figure1`, a system-wide view of relevant functional blocks is
  55 presented. OpenStack is considered as the VIM implementation (aka Controller)
  56 which has interfaces with the NFVI and the Consumers. The VNF implementation is
  57 represented as different virtual resources marked by different colors. Consumers
  58 (VNFM or NFVO in ETSI NFV terminology) own/manage the respective virtual
  59 resources (VMs in this example) shown with the same colors.
  60
  61 The first requirement in this use case is that the Controller needs to detect
  62 faults in the NVFI ("1. Fault Notification" in :numref:`figure1`) affecting
  63 the proper functioning of the virtual resources (labelled as VM-x) running on
  64 top of it. It should be possible to configure which relevant fault items should
  65 be detected. The VIM (e.g. OpenStack) itself could be extended to detect such
  66 faults. Alternatively, a third party fault monitoring tool could be used which
  67 then informs the VIM about such faults; this third party fault monitoring
  68 element can be considered as a component of VIM from an architectural point of
  69 view.
  70
  71 Once such fault is detected, the VIM shall find out which virtual resources are
  72 affected by this fault. In the example in :numref:`figure1`, VM-4 is
  73 affected by a fault in the Hardware Server-3. Such mapping shall be maintained
  74 in the VIM, depicted as the "Server-VM info" table inside the VIM.
  75
  76 Once the VIM has identified which virtual resources are affected by the fault,
  77 it needs to find out who is the Consumer (i.e. the owner/manager) of the
  78 affected virtual resources (Step 2). In the example shown in :numref:`figure1`,
  79 the VIM knows that for the red VM-4, the manager is the red Consumer
  80 through an Ownership info table. The VIM then notifies (Step 3 "Fault
  81 Notification") the red Consumer about this fault, preferably with sufficient
  82 abstraction rather than detailed physical fault information.
  83
  84 .. figure:: images/figure1.png
  85    :name: figure1
  86    :width: 100%
  87
  88    Fault management/recovery use case
  89
  90 The Consumer then switches to STBY configuration by switching the STBY node to
  91 ACT state (Step 4). It further initiates a process to instantiate/configure a
  92 new STBY. However, switching to STBY mode and creating a new STBY machine is a
  93 VNFM/NFVO level operation and therefore outside the scope of this project.
  94 Doctor project does not create interfaces for such VNFM level configuration
  95 operations. Yet, since the total failover time of a consumer service depends on
  96 both the delay of such processes as well as the reaction time of Doctor
  97 components, minimizing Doctor's reaction time is a necessary basic ingredient to
  98 fast failover times in general.
  99
 100 Once the Consumer has switched to STBY configuration, it notifies (Step 5
 101 "Instruction" in :numref:`figure1`) the VIM. The VIM can then take
 102 necessary (e.g. pre-determined by the involved network operator) actions on how
 103 to clean up the fault affected VMs (Step 6 "Execute Instruction").
 104
 105 The key issue in this use case is that a VIM (OpenStack in this context) shall
 106 not take a standalone fault recovery action (e.g. migration of the affected VMs)
 107 before the ACT-STBY switching is complete, as that might violate the ACT-STBY
 108 configuration and render the node out of service.
 109
 110 As an extension of the 1+1 ACT-STBY resilience pattern, a STBY instance can act as
 111 backup to N ACT nodes (N+1). In this case, the basic information flow remains
 112 the same, i.e., the consumer is informed of a failure in order to activate the
 113 STBY node. However, in this case it might be useful for the failure notification
 114 to cover a number of failed instances due to the same fault (e.g., more than one
 115 instance might be affected by a switch failure). The reaction of the consumer
 116 might depend on whether only one active instance has failed (similar to the
 117 ACT-STBY case), or if more active instances are needed as well.
 118
 119 Preventive actions based on fault prediction
 120 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 121
 122 The fault management scenario explained in :ref:`uc-fault1` can also be
 123 performed based on fault prediction. In such cases, in VIM, there is an
 124 intelligent fault prediction module which, based on its NFVI monitoring
 125 information, can predict an imminent fault in the elements of NFVI.
 126 A simple example is raising temperature of a Hardware Server which might
 127 trigger a pre-emptive recovery action. The requirements of such fault
 128 prediction in the VIM are investigated in the OPNFV project "Data Collection
 129 for Failure Prediction" [PRED]_.
 130
 131 This use case is very similar to :ref:`uc-fault1`. Instead of a fault
 132 detection (Step 1 "Fault Notification in" :numref:`figure1`), the trigger
 133 comes from a fault prediction module in the VIM, or from a third party module
 134 which notifies the VIM about an imminent fault. From Step 2~5, the work flow is
 135 the same as in the "Fault management using ACT-STBY configuration" use case,
 136 except in this case, the Consumer of a VM/VNF switches to STBY configuration
 137 based on a predicted fault, rather than an occurred fault.
 138
 139 NVFI Maintenance
 140 ----------------
 141
 142 VM Retirement
 143 ^^^^^^^^^^^^^
 144
 145 All network operators perform maintenance of their network infrastructure, both
 146 regularly and irregularly. Besides the hardware, virtualization is expected to
 147 increase the number of elements subject to such maintenance as NFVI holds new
 148 elements like the hypervisor and host OS. Maintenance of a particular resource
 149 element e.g. hardware, hypervisor etc. may render a particular server hardware
 150 unusable until the maintenance procedure is complete.
 151
 152 However, the Consumer of VMs needs to know that such resources will be
 153 unavailable because of NFVI maintenance. The following use case is again to
 154 ensure that the ACT-STBY configuration is not violated. A stand-alone action
 155 (e.g. live migration) from VIM/OpenStack to empty a physical machine so that
 156 consequent maintenance procedure could be performed may not only violate the
 157 ACT-STBY configuration, but also have impact on real-time processing scenarios
 158 where dedicated resources to virtual resources (e.g. VMs) are necessary and a
 159 pause in operation (e.g. vCPU) is not allowed. The Consumer is in a position to
 160 safely perform the switch between ACT and STBY nodes, or switch to an
 161 alternative VNF forwarding graph so the hardware servers hosting the ACT nodes
 162 can be emptied for the upcoming maintenance operation. Once the target hardware
 163 servers are emptied (i.e. no virtual resources are running on top), the VIM can
 164 mark them with an appropriate flag (i.e. "maintenance" state) such that these
 165 servers are not considered for hosting of virtual machines until the maintenance
 166 flag is cleared (i.e. nodes are back in "normal" status).
 167
 168 A high-level view of the maintenance procedure is presented in :numref:`figure2`.
 169 VIM/OpenStack, through its northbound interface, receives a maintenance notification
 170 (Step 1 "Maintenance Request") from the Administrator (e.g. a network operator)
 171 including information about which hardware is subject to maintenance.
 172 Maintenance operations include replacement/upgrade of hardware,
 173 update/upgrade of the hypervisor/host OS, etc.
 174
 175 The consequent steps to enable the Consumer to perform ACT-STBY switching are
 176 very similar to the fault management scenario. From VIM/OpenStack's internal
 177 database, it finds out which virtual resources (VM-x) are running on those
 178 particular Hardware Servers and who are the managers of those virtual resources
 179 (Step 2). The VIM then informs the respective Consumer (VNFMs or NFVO) in Step 3
 180 "Maintenance Notification". Based on this, the Consumer takes necessary actions
 181 (Step 4, e.g. switch to STBY configuration or switch VNF forwarding graphs) and
 182 then notifies (Step 5 "Instruction") the VIM. Upon receiving such notification,
 183 the VIM takes necessary actions (Step 6 "Execute Instruction" to empty the
 184 Hardware Servers so that consequent maintenance operations could be performed.
 185 Due to the similarity for Steps 2~6, the maintenance procedure and the fault
 186 management procedure are investigated in the same project.
 187
 188 .. figure:: images/figure2.png
 189    :name: figure2
 190    :width: 100%
 191
 192    Maintenance use case
 193
 194 ..
 195  vim: set tabstop=4 expandtab textwidth=80: