doc/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 1. Upgrade Scope
   9 ~~~~~~~~~~~~~~~~
  10 Upgrade objects described in this document are software programs covered by
  11 red box in the picture below which includes: VIM and NFVI.
  12 The target of the upgrade is to reduce the impact on the applications in the
  13 blue box below as much as possible.
  14 Note that this upgrade process does not take into consideration the effects
  15 of Vi-Vnfm and Or-Vi. In other words, the unserviceability of the two
  16 interfaces during upgrade can  be accepted.
  17
  18 .. figure:: images/figure1.png
  19    :name: figure1
  20    :width: 100%
  21
  22 The software stack on each node is generally as shown in the table below.
  23
  24 .. figure:: images/figure2.png
  25    :name: figure2
  26    :width: 100%
  27
  28 Because the control node upgrade will not affect the business in the blue box,
  29 this scheme focuses on upgrading of compute nodes.
  30
  31 2. Precondition of Upgrade
  32 ~~~~~~~~~~~~~~~~~~~~~~~~~~
  33 2.1 The environmental requirements
  34 1.  System is running normally. If there are any faults before the upgrade, it
  35 is difficult to distinguish between upgrade introduced and the environment
  36 itself.
  37 2.  The environment should have the redundant resources. Because the upgrade
  38 process is based on the business migration, in the absence of resource
  39 redundancy,it is impossible to realize the business migration, as well as to
  40 achieve a smooth upgrade.
  41
  42 Resource redundancy in two levels:
  43 1)  NFVI level: This level is mainly the compute nodes resource redundancy.
  44 During the upgrade, the virtual machine on business can be migrated to another
  45 free compute node.
  46 2)  VNF level: This level depends on backup mechanism in VNF, such as:
  47 active-standby, load balance. In this case, as long as business of the target
  48 node on VMs is migrated to other free nodes, the migration of VM might not be
  49 necessary.
  50
  51 The way of redundancy to be used is subject to the specific environment.
  52 Generally speaking, the impact of using NFVI redundancy on the VMs is larger
  53 than the rearrangement of the business on VNF level.
  54
  55 2.2 The demand for version
  56 This is primarily a compatibility requirement. You can refer to Linux/Python
  57 Compatible Semantic Versioning 3.0.0:
  58
  59 Given a version number MAJOR.MINOR.PATCH, increment the:
  60 1.  MAJOR version when you make incompatible API changes,
  61 2.  MINOR version when you add functionality in a backwards-compatible manner,
  62 3.  PATCH version when you make backwards-compatible bug fixes.
  63
  64 The upgrade process needs to use some interfaces which require these
  65 interfaces to be backward compatible. Refer to "Interface" chapter for details.
  66
  67 3.Upgrade related modules in VIM
  68 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  69 Upgrade operations are initiated by the user through the VIM. For VIM, upgrade
  70 management mainly contains the object:
  71 **Upgrade Manager**:Mainly responsible for upgrading process control. Physical
  72 nodes information of each node is saved in upgrade manager.
  73 **VIM Interface**:Mainly responsible for the external interface, include
  74 Vi-Vnfm, Or-Vi. This module stores VNFO and VNFM external information such as
  75 address and authentication.
  76 **Cloud Manager**:Mainly responsible for virtualization resources management,
  77 which might be considered made up of Openstack and SDN control node.
  78 **System Support**:Provide the upper software running environment, including:
  79 OS, HA, etc. To upgrade the upper software is based on this module.
  80
  81 .. figure:: images/figure3.png
  82    :name: figure3
  83    :width: 100%