From 61a851845546300cc2f5ee9f3dd6761c9ecd093e Mon Sep 17 00:00:00 2001 From: Jie Hu Date: Wed, 16 Dec 2015 18:52:19 +0800 Subject: ESCALATOR-31 Adjusting documentation JIRA: ESCALATOR-31 Change-Id: I0b83511a542982f07c2ab9d60517f4b5f357569b Signed-off-by: Jie Hu --- docs/design/201-Reference_Architecture.rst | 54 ++++++++++++++++++++++++ docs/design/202-Information_Flows.rst | 57 ++++++++++++++++++++++++++ docs/design/203-Administrative_Interfaces.rst | 16 ++++++++ docs/design/204-Configuration_and_Logging.rst | 18 ++++++++ docs/design/2A1-Appendix.rst | 50 ++++++++++++++++++++++ docs/design/etc/conf.py | 34 +++++++++++++++ docs/design/etc/opnfv-logo.png | Bin 0 -> 2829 bytes docs/design/images/figure2.png | Bin 0 -> 9196 bytes docs/design/images/figure3.png | Bin 0 -> 25188 bytes docs/design/images/figure4.png | Bin 0 -> 122040 bytes docs/design/images/figure5.png | Bin 0 -> 28490 bytes docs/design/images/figure6.png | Bin 0 -> 46314 bytes docs/design/index.rst | 33 +++++++++++++++ 13 files changed, 262 insertions(+) create mode 100644 docs/design/201-Reference_Architecture.rst create mode 100644 docs/design/202-Information_Flows.rst create mode 100644 docs/design/203-Administrative_Interfaces.rst create mode 100644 docs/design/204-Configuration_and_Logging.rst create mode 100644 docs/design/2A1-Appendix.rst create mode 100644 docs/design/etc/conf.py create mode 100644 docs/design/etc/opnfv-logo.png create mode 100644 docs/design/images/figure2.png create mode 100644 docs/design/images/figure3.png create mode 100644 docs/design/images/figure4.png create mode 100644 docs/design/images/figure5.png create mode 100644 docs/design/images/figure6.png create mode 100644 docs/design/index.rst (limited to 'docs/design') diff --git a/docs/design/201-Reference_Architecture.rst b/docs/design/201-Reference_Architecture.rst new file mode 100644 index 0000000..75aa461 --- /dev/null +++ b/docs/design/201-Reference_Architecture.rst @@ -0,0 +1,54 @@ +====================== +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. + +The software stack on each node is generally as shown in the table below. + +.. figure:: images/figure2.png + :name: figure2 + :width: 100% + +Since the upgrading of control node will not affect the VNFs service in the blue +box, this chapter will focusing on the upgrading of compute nodes. + + +Precondition of Upgrade +======================= + +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. + +.. figure:: images/figure3.png + :name: figure3 + :width: 100% diff --git a/docs/design/202-Information_Flows.rst b/docs/design/202-Information_Flows.rst new file mode 100644 index 0000000..eaa39f0 --- /dev/null +++ b/docs/design/202-Information_Flows.rst @@ -0,0 +1,57 @@ +================= +Information Flows +================= + +This section describes the information flows among the function +entities when Escalator is in actions. + +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 diff --git a/docs/design/203-Administrative_Interfaces.rst b/docs/design/203-Administrative_Interfaces.rst new file mode 100644 index 0000000..5d8148b --- /dev/null +++ b/docs/design/203-Administrative_Interfaces.rst @@ -0,0 +1,16 @@ +========================= +Administrative Interfaces +========================= + +This section describes the required administrative interfaces of Escalator. + +CLI Interface +============= + +This section describes CLI of Escalator. + +RESTful API +=========== + +This section describes the API of Escalator for developer. + diff --git a/docs/design/204-Configuration_and_Logging.rst b/docs/design/204-Configuration_and_Logging.rst new file mode 100644 index 0000000..309b2c8 --- /dev/null +++ b/docs/design/204-Configuration_and_Logging.rst @@ -0,0 +1,18 @@ +========================= +Configuration and Logging +========================= + +This section describes the required configuration and logging of Escalator. + + +Configuration Format +==================== + +This section will suggest a format of the configuration files and how to +deal with it. + +Logging Format +============== + +This section will suggest a format of the log files and how to deal with +it. diff --git a/docs/design/2A1-Appendix.rst b/docs/design/2A1-Appendix.rst new file mode 100644 index 0000000..80fe447 --- /dev/null +++ b/docs/design/2A1-Appendix.rst @@ -0,0 +1,50 @@ +======== +Appendix +======== + +A.1 Impact Analysis +=================== + +Upgrading the different software modules may cause different impact on +the availability of the infrastructure resources and even on the service +continuity of the vNFs. + +**Software modules in the computing nodes** + +#. Host OS patch + +#. Hypervisor, such as KVM, QEMU, XEN, libvirt +#. Openstack agent in computing nodes (like Nova agent, Ceilometer + agent...) + +.. As SW module, we should list the host OS and maybe its + drivers as well. From upgrade perspective do we limit host OS + upgrades to patches only? + +**Software modules in network nodes** + +#. Neutron L2/L3 agent +#. OVS, SR-IOV Driver + +**Software modules storage nodes** + +#. Ceph + +The table below analyses such an impact - considering a single instance +of each software module - from the following aspects: + +- the function which will be lost during upgrade, +- the duration of the loss of this specific function, +- if this causes the loss of the vNF function, +- if it causes incompatibility in the different parts of the software, +- what should be backed up before the upgrade, +- the duration of restoration time if the upgrade fails + +These values provided come from internal testing and based on some +assumptions, they may vary depending on the deployment techniques. +Please feel free to add if you find more efficient values during your +testing. + +https://wiki.opnfv.org/_media/upgrade_analysis_v0.5.xlsx + +Note that no redundancy of the software modules is considered in the table. diff --git a/docs/design/etc/conf.py b/docs/design/etc/conf.py new file mode 100644 index 0000000..0066035 --- /dev/null +++ b/docs/design/etc/conf.py @@ -0,0 +1,34 @@ +import datetime +import sys +import os + +try: + __import__('imp').find_module('sphinx.ext.numfig') + extensions = ['sphinx.ext.numfig'] +except ImportError: + # 'pip install sphinx_numfig' + extensions = ['sphinx_numfig'] + +# numfig: +number_figures = True +figure_caption_prefix = "Fig." + +source_suffix = '.rst' +master_doc = 'index' +pygments_style = 'sphinx' +html_use_index = False + +pdf_documents = [('index', u'OPNFV', u'OPNFV Project', u'OPNFV')] +pdf_fit_mode = "shrink" +pdf_stylesheets = ['sphinx','kerning','a4'] +#latex_domain_indices = False +#latex_use_modindex = False + +latex_elements = { + 'printindex': '', +} + +project = u'OPNFV: Template documentation config' +copyright = u'%s, OPNFV' % datetime.date.today().year +version = u'1.0.0' +release = u'1.0.0' diff --git a/docs/design/etc/opnfv-logo.png b/docs/design/etc/opnfv-logo.png new file mode 100644 index 0000000..1519503 Binary files /dev/null and b/docs/design/etc/opnfv-logo.png differ diff --git a/docs/design/images/figure2.png b/docs/design/images/figure2.png new file mode 100644 index 0000000..70d16c7 Binary files /dev/null and b/docs/design/images/figure2.png differ diff --git a/docs/design/images/figure3.png b/docs/design/images/figure3.png new file mode 100644 index 0000000..38346de Binary files /dev/null and b/docs/design/images/figure3.png differ diff --git a/docs/design/images/figure4.png b/docs/design/images/figure4.png new file mode 100644 index 0000000..e74e24b Binary files /dev/null and b/docs/design/images/figure4.png differ diff --git a/docs/design/images/figure5.png b/docs/design/images/figure5.png new file mode 100644 index 0000000..a49955d Binary files /dev/null and b/docs/design/images/figure5.png differ diff --git a/docs/design/images/figure6.png b/docs/design/images/figure6.png new file mode 100644 index 0000000..efe7d6f Binary files /dev/null and b/docs/design/images/figure6.png differ diff --git a/docs/design/index.rst b/docs/design/index.rst new file mode 100644 index 0000000..993b5e6 --- /dev/null +++ b/docs/design/index.rst @@ -0,0 +1,33 @@ +.. OPNFV Release Engineering documentation, created by + sphinx-quickstart on Tue Jun 9 19:12:31 2015. + You can adapt this file completely to your liking, but it should at least + contain the root `toctree` directive. + +.. image:: etc/opnfv-logo.png + :height: 40 + :width: 200 + :alt: OPNFV + :align: left + +ESCALATOR DESIGN CONSIDERATIONS +======================================= + +Contents: + +.. toctree:: + :maxdepth: 4 + :titlesonly: + + + + 201-Reference_Architecture.rst + 202-Information_Flows.rst + 203-Administrative_Interfaces.rst + 204-Configuration_and_Logging.rst + 300-Gap_Analysis_Report.rst + +* :ref:`search` + +Revision: _sha1_ + +Build date: |today| -- cgit 1.2.3-korg