From 88d977794c178b50ad47ea622edc7c565565ddab Mon Sep 17 00:00:00 2001 From: chaozhong-zte Date: Fri, 30 Oct 2015 11:01:52 +0800 Subject: Contribute a RA/Information flows from ZTE's implementation JIRA:ESCALATOR-25 JIRA:ESCALATOR-26 Change-Id: I1bd5abd0d7264eb0f50bf5799c9bd560a2661acf Signed-off-by: chaozhong-zte --- doc/05-Reference_Architecture.rst | 81 +++++++++++++++++++++++++++++++++++++- doc/06-Information_Flows.rst | 52 +++++++++++++++++++++++- doc/images/figure1.png | Bin 0 -> 118302 bytes doc/images/figure2.png | Bin 0 -> 25188 bytes doc/images/figure3.png | Bin 0 -> 9196 bytes doc/images/figure4.png | Bin 0 -> 122040 bytes doc/images/figure5.png | Bin 0 -> 28490 bytes doc/images/figure6.png | Bin 0 -> 46314 bytes 8 files changed, 129 insertions(+), 4 deletions(-) create mode 100644 doc/images/figure1.png create mode 100644 doc/images/figure2.png create mode 100644 doc/images/figure3.png create mode 100644 doc/images/figure4.png create mode 100644 doc/images/figure5.png create mode 100644 doc/images/figure6.png diff --git a/doc/05-Reference_Architecture.rst b/doc/05-Reference_Architecture.rst index 1b16dbe..4d5a64f 100644 --- a/doc/05-Reference_Architecture.rst +++ b/doc/05-Reference_Architecture.rst @@ -2,5 +2,82 @@ Reference Architecture ---------------------- This section describes the reference architecture, the function blocks, -the function entities of Escalator for the reader to well understand how -the basic functions be organized. \ No newline at end of file +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 diff --git a/doc/06-Information_Flows.rst b/doc/06-Information_Flows.rst index 14f2908..641b59b 100644 --- a/doc/06-Information_Flows.rst +++ b/doc/06-Information_Flows.rst @@ -4,5 +4,53 @@ Information Flows This section describes the information flows among the function entities when Escalator is in actions. -.. We should consider a generic procedure / frameworks of upgrading. And - may provide plug-ins interface for specialized tasks \ No newline at end of file +1. Upgrade process of Compute nodes + +1.1 consider VIM as a whole + +.. figure:: images/figure4.png + :name: figure4 + :width: 100% + +process is: +1. Operators add new version files on the VIM,initiate the upgrade. +2. VIM chooses some compute nodes as the upgrade target nodes, and set them +into maintenance mode. VIM queries the list of running VMs on target nodes. +3. VIM notice VNFM corresponding to the virtual machine, to migrate the +business. +4. VNFM migrates the business. If the business is in active of active-standby +mode, it will initiate switch-over. If the business is in loading balance mode, +it will move the business to other node. +5. After VNFM moves business, it notifies the VIM. +6. VIM judges whether the business on the target VM has all been moved. If +not, VIM migrates the VM with business loaded to other free nodes. Then VIM +upgrades the target computer nodes. After upgrade, VIM set the target compute +nodes into normal nodes. +7. If there are computer nodes remained to be upgraded, goto step 2. + +4.2 from inside VIM + +.. figure:: images/figure5.png + :name: figure5 + :width: 100% + +.. figure:: images/figure6.png + :name: figure6 + :width: 100% + +process is: +1. Upgrade manager receives user operation commands. Add new version files. +Upgrade is began. +2. Upgrade Manager selects compute node A to Upgrade. Query list of the VMs +running the compute nodes A to the Cloud Manager, and set the node to +maintenance mode, that is to say creation or migration of new VM on this node +is impossible anymore. +3. Upgrade Manager notifies VNFM compute node A into maintenance mode by VIM +interface, temporarily disabling the inserting of business, and business on +compute node A need move to the other available compute nodes. +4. When receives the VNFM reply, or waited for a timeout, Upgrade Manager +notifies the system support on compute node A to do software upgrade. +5. After upgraded, Upgrade Manager removes maintenance mode for the compute +node A. +6. Upgrade Manager claims VNFM computing nodes A available. +7. Select computer node B to upgrade \ No newline at end of file diff --git a/doc/images/figure1.png b/doc/images/figure1.png new file mode 100644 index 0000000..da48655 Binary files /dev/null and b/doc/images/figure1.png differ diff --git a/doc/images/figure2.png b/doc/images/figure2.png new file mode 100644 index 0000000..38346de Binary files /dev/null and b/doc/images/figure2.png differ diff --git a/doc/images/figure3.png b/doc/images/figure3.png new file mode 100644 index 0000000..70d16c7 Binary files /dev/null and b/doc/images/figure3.png differ diff --git a/doc/images/figure4.png b/doc/images/figure4.png new file mode 100644 index 0000000..e74e24b Binary files /dev/null and b/doc/images/figure4.png differ diff --git a/doc/images/figure5.png b/doc/images/figure5.png new file mode 100644 index 0000000..a49955d Binary files /dev/null and b/doc/images/figure5.png differ diff --git a/doc/images/figure6.png b/doc/images/figure6.png new file mode 100644 index 0000000..efe7d6f Binary files /dev/null and b/doc/images/figure6.png differ -- cgit 1.2.3-korg