diff options
author | zhang-jun3g <zhang.jun3g@zte.com.cn> | 2015-11-09 16:31:16 +0800 |
---|---|---|
committer | zhang-jun3g <zhang.jun3g@zte.com.cn> | 2015-11-09 16:31:16 +0800 |
commit | f24247660e9f6539737d460c59ab66ec2068333b (patch) | |
tree | 349ba7d21b8eb684b1fcaf700524fdd3d5375e67 /doc/05-Reference_Architecture.rst | |
parent | 38709b4780c336ac5ac8fbcd34217dcf71a33d6d (diff) |
Move files from doc to docs
Move files to docs for automation html release.
JIRA:ESCALATOR-27
Change-Id: I3654b18ad6c7fc94614fd55afe5e3140bf467752
Signed-off-by: zhang-jun3g <zhang.jun3g@zte.com.cn>
Diffstat (limited to 'doc/05-Reference_Architecture.rst')
-rw-r--r-- | doc/05-Reference_Architecture.rst | 83 |
1 files changed, 0 insertions, 83 deletions
diff --git a/doc/05-Reference_Architecture.rst b/doc/05-Reference_Architecture.rst deleted file mode 100644 index 4d5a64f..0000000 --- a/doc/05-Reference_Architecture.rst +++ /dev/null @@ -1,83 +0,0 @@ -Reference Architecture ----------------------- - -This section describes the reference architecture, the function blocks, -and the function entities of Escalator for the reader to well understand how -the basic functions to be organized. - -1. Upgrade Scope -~~~~~~~~~~~~~~~~ -Upgrade objects described in this document are software programs covered by -red box in the picture below which includes: VIM and NFVI. -The target of the upgrade is to reduce the impact on the applications in the -blue box below as much as possible. -Note that this upgrade process does not take into consideration the effects -of Vi-Vnfm and Or-Vi. In other words, the unserviceability of the two -interfaces during upgrade can be accepted. - -.. figure:: images/figure1.png - :name: figure1 - :width: 100% - -The software stack on each node is generally as shown in the table below. - -.. figure:: images/figure2.png - :name: figure2 - :width: 100% - -Because the control node upgrade will not affect the business in the blue box, -this scheme focuses on upgrading of compute nodes. - -2. Precondition of Upgrade -~~~~~~~~~~~~~~~~~~~~~~~~~~ -2.1 The environmental requirements -1. System is running normally. If there are any faults before the upgrade, it -is difficult to distinguish between upgrade introduced and the environment -itself. -2. The environment should have the redundant resources. Because the upgrade -process is based on the business migration, in the absence of resource -redundancy,it is impossible to realize the business migration, as well as to -achieve a smooth upgrade. - -Resource redundancy in two levels: -1) NFVI level: This level is mainly the compute nodes resource redundancy. -During the upgrade, the virtual machine on business can be migrated to another -free compute node. -2) VNF level: This level depends on backup mechanism in VNF, such as: -active-standby, load balance. In this case, as long as business of the target -node on VMs is migrated to other free nodes, the migration of VM might not be -necessary. - -The way of redundancy to be used is subject to the specific environment. -Generally speaking, the impact of using NFVI redundancy on the VMs is larger -than the rearrangement of the business on VNF level. - -2.2 The demand for version -This is primarily a compatibility requirement. You can refer to Linux/Python -Compatible Semantic Versioning 3.0.0: - -Given a version number MAJOR.MINOR.PATCH, increment the: -1. MAJOR version when you make incompatible API changes, -2. MINOR version when you add functionality in a backwards-compatible manner, -3. PATCH version when you make backwards-compatible bug fixes. - -The upgrade process needs to use some interfaces which require these -interfaces to be backward compatible. Refer to "Interface" chapter for details. - -3.Upgrade related modules in VIM -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Upgrade operations are initiated by the user through the VIM. For VIM, upgrade -management mainly contains the object: -**Upgrade Manager**:Mainly responsible for upgrading process control. Physical -nodes information of each node is saved in upgrade manager. -**VIM Interface**:Mainly responsible for the external interface, include -Vi-Vnfm, Or-Vi. This module stores VNFO and VNFM external information such as -address and authentication. -**Cloud Manager**:Mainly responsible for virtualization resources management, -which might be considered made up of Openstack and SDN control node. -**System Support**:Provide the upper software running environment, including: -OS, HA, etc. To upgrade the upper software is based on this module. - -.. figure:: images/figure3.png - :name: figure3 - :width: 100%
\ No newline at end of file |