docs/05-Reference_Architecture.rst

   1 Reference Architecture
   2 ----------------------
   3
   4 This section describes the reference architecture, the function blocks,
   5 and the function entities of Escalator for the reader to well understand how
   6 the basic functions to be organized.
   7
   8 Upgrade Scope
   9 ~~~~~~~~~~~~~~~~
  10
  11 Upgrade objects described in this document are software programs covered by
  12 red box in the picture below which includes: VIM and NFVI.
  13 The target of the upgrade is to reduce the impact on the applications in the
  14 blue box below as much as possible.
  15 Note that this upgrade process does not take into consideration the effects
  16 of Vi-Vnfm and Or-Vi. In other words, the unserviceability of the two
  17 interfaces during upgrade can  be accepted.
  18
  19 .. figure:: images/figure1.png
  20    :name: figure1
  21    :width: 100%
  22
  23 The software stack on each node is generally as shown in the table below.
  24
  25 .. figure:: images/figure2.png
  26    :name: figure2
  27    :width: 100%
  28
  29 Because the control node upgrade will not affect the VNFs service in the blue
  30 box, this scheme focuses on upgrading of compute nodes.
  31
  32 Precondition of Upgrade
  33 ~~~~~~~~~~~~~~~~~~~~~~~
  34
  35 1  The environmental requirements
  36 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  37
  38 1. System is running normally. If there are any faults before the upgrade,
  39 it is difficult to distinguish between upgrade introduced and the environment
  40 itself.
  41
  42 2. The environment should have the redundant resources. Because the upgrade
  43 process is based on the business migration, in the absence of resource
  44 redundancy,it is impossible to realize the business migration, as well as to
  45 achieve a smooth upgrade.
  46
  47 Resource redundancy in two levels:
  48
  49 1  NFVI level: This level is mainly the compute nodes resource redundancy.
  50 During the upgrade, the virtual machine on business can be migrated to another
  51 free compute node.
  52
  53 2  VNF level: This level depends on HA mechanism in VNF, such as:
  54 active-standby, load balance. In this case, as long as business of the target
  55 node on VMs is migrated to other free nodes, the migration of VM might not be
  56 necessary.
  57
  58 The way of redundancy to be used is subject to the specific environment.
  59 Generally speaking, During the upgrade, the VNF's service level availability
  60 mechanism should be used in higher priority than the NFVI's. This will help
  61 us to reduce the service outage.
  62
  63 2 The requirements for component release version
  64 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  65
  66 This is primarily a compatibility requirement. You can refer to Linux/Python
  67 Compatible Semantic Versioning 3.0.0:
  68
  69 Given a version number MAJOR.MINOR.PATCH, increment the:
  70
  71 1. MAJOR version when you make incompatible API changes,
  72
  73 2. MINOR version when you add functionality in a backwards-compatible manner,
  74
  75 3. PATCH version when you make backwards-compatible bug fixes.
  76
  77 Some internal interfaces of OpenStack will be used by Escalator indirectly,
  78 such as VM migration related interface between VIM and NFVI. So it is required
  79 to be backward compatible on these interfaces. Refer to "Interface" chapter
  80 for details.
  81
  82 Upgrade related modules in VIM
  83 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  84 Upgrade operations are initiated by the user through the VIM. For VIM, upgrade
  85 management mainly contains the object:
  86
  87 - **Upgrade Manager**
  88
  89 Mainly responsible for control of the upgrade process.The Escalator is required
  90 to know the software deployment information of the platform and will use these
  91 information during the upgrading. It will be collected from some place, such
  92 as the Installer, Deploy Manager and Escalator itself, etc.
  93
  94 - **VIM Interface**:
  95
  96 Mainly responsible for the external interface, include Vi-Vnfm, Or-Vi. This
  97 module stores VNFO and VNFM external information such as address and
  98 authentication.
  99
 100 - **Cloud Manager**:
 101
 102 Mainly responsible for virtualization resources management,which might be
 103 considered made up of Openstack and SDN control node.
 104
 105 - **System Support**:
 106
 107 This layer is the runtime support environment of upper layers, e.g. Cloud
 108 Manager and VIM interface., including:OS, HA, etc. To upgrade the upper
 109 software is based on this module.
 110
 111 .. figure:: images/figure3.png
 112    :name: figure3
 113    :width: 100%