From f1b8f0bf74f1f436e8e075399f73de6ba306f6c7 Mon Sep 17 00:00:00 2001 From: chaozhong-zte Date: Thu, 3 Dec 2015 01:12:48 +0800 Subject: ESCALATOR-29: Reference Architecture format bugfix JIRA: ESCALATOR-29 Change-Id: Ie1e31bfa55ab0fccf4ee9c1e7723c6254fec4b85 Signed-off-by: chaozhong-zte --- docs/05-Reference_Architecture.rst | 67 +++++++++++++++++++++++++------------- 1 file changed, 44 insertions(+), 23 deletions(-) (limited to 'docs') diff --git a/docs/05-Reference_Architecture.rst b/docs/05-Reference_Architecture.rst index 00774b8..63b54c2 100644 --- a/docs/05-Reference_Architecture.rst +++ b/docs/05-Reference_Architecture.rst @@ -7,6 +7,7 @@ the basic functions to be organized. 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 @@ -29,22 +30,27 @@ Because the control node upgrade will not affect the VNFs service in the blue box, this scheme focuses on upgrading of compute nodes. Precondition of Upgrade -~~~~~~~~~~~~~~~~~~~~~~~~~~ -1 The environmental requirements -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- 1. System is running normally. If there are any faults before the upgrade, +~~~~~~~~~~~~~~~~~~~~~~~ + +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 + +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. + +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 HA mechanism in VNF, such as: + +2 VNF level: This level depends on HA 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. @@ -56,13 +62,17 @@ us to reduce the service outage. 2 The requirements for component release 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. + +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. Some internal interfaces of OpenStack will be used by Escalator indirectly, such as VM migration related interface between VIM and NFVI. So it is required @@ -73,19 +83,30 @@ 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 control of the upgrade process. -The Escalator is required to know the software deployment information of the -platform and will use these information during the upgrading. It will be -collected from some place, such as the Installer, Deploy Manager and Escalator -itself, etc. -- **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**:This layer is the runtime support environment of upper -layers, e.g. Cloud Manager and VIM interface., including:OS, HA, etc. To -upgrade the upper software is based on this module. + +- **Upgrade Manager** + +Mainly responsible for control of the upgrade process.The Escalator is required +to know the software deployment information of the platform and will use these +information during the upgrading. It will be collected from some place, such +as the Installer, Deploy Manager and Escalator itself, etc. + +- **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**: + +This layer is the runtime support environment of upper layers, e.g. Cloud +Manager and VIM interface., including:OS, HA, etc. To upgrade the upper +software is based on this module. .. figure:: images/figure3.png :name: figure3 -- cgit 1.2.3-korg