diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/04-Use_Cases_and_Scenarios.rst | 219 |
1 files changed, 199 insertions, 20 deletions
diff --git a/doc/04-Use_Cases_and_Scenarios.rst b/doc/04-Use_Cases_and_Scenarios.rst index 13d16cf..ee9b488 100644 --- a/doc/04-Use_Cases_and_Scenarios.rst +++ b/doc/04-Use_Cases_and_Scenarios.rst @@ -1,32 +1,211 @@ Use Cases and Scenarios ----------------------- -This section describes the use cases and scenarios to verify the +This section describes the use cases and scenarios to verify the requirements of Escalator. -Upgrade a system with minimal configuration -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Scenarios +~~~~~~~~~ +1. Upgrade a system with HA configuration +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -A minimal configuration system is normally deployed for experimental or -development usages, such as a OPNFV test bed. Although it dose not have -large workload, but it is a typical system to be upgraded frequently. +A HA configuration system is very popular in the operator's data centre. +It is a typical product environment. It is always running 7\*24 with VNFs +running on it to provide services to the end users. -Upgrade a system with HA configuration -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -A HA configuration system is very popular in the operator's data centre. -And it is a typical product environment. It always running 7 \* 24 a -week with VNFs running on it to provide services to the end users. +2. Upgrade a system with non-HA configuration +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A non-HA configuration system is normally deployed for experimental or +development usages, such as a Vagrant/VM environment. + +Escalator supports the upgrade in this scenario, but it does not guarantee a +smooth upgrade. + +Use cases +~~~~~~~~~ +Use case #1: Smooth upgrade in a HA configuration +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +For a system with HA configuration, the operator can use Escalator to +smooth-upgrade NFVI/VIM components into a new version without any service +outage. + +When a compute node being upgraded, the VMs on the node may need to be migrated +to other compute nodes to avoid service outage, so it is requred that there are +enough redundant resources to migrate VMs on this compute node. + +Before upgrade, the operator can use Escalator to check whether smooth upgrade +conditions are all satisfied. These conditions include whether there are enough +idle resources to migrate VMs during updrading, and whether the new version is +compatible with the current one, etc. If there are some conditions not +satisfied, Escalator will show them. Escalator can also provide the solutions if +there is any, such as the number and configuration of spare compute nodes which +are needed. + +When upgrade starts, Escalator will also automatically check whether smooth +upgrade conditions are all satisfied. If some smooth upgrade conditions are not +satisfied, Escalator will show the failure of smooth upgrade. + +- Pre-Conditions + + 1. The system is running as normal. + 2. The VNFs are providing services as usual. + +- Upgrading steps + + 1. The VNFs are continually providing services during the upgrade. + 2. The operator successfully logged in the GUI of Escalator to select the + software packages including Linux OS, Hypervisor, OpenStack, ODL and other + OPNFV components, ect. (All or part of components could be selected.) + 3. Select the nodes to be upgraded. i.e. controller node, network node, + storage node and compute node, etc. + 4. Select "Disable Scale-up". It will limit the scale-up operation when + upgrade is in progress to prevent failures due to the shortage of + resources. + 5. Select "Check Smooth Upgrade Conditions". If Escalator shows that there are + some conditions not satisfied, try to resolve them according to the + solutions provided. + 6. Select "Smooth Upgrade", then apply the upgrade operation. + 7. Select "Restore Scale-up" after the upgrade. It will restore scale-up to + the original enabled/disabled state before upgrade. + +- Post-Conditions + + 1. The system is upgraded successfully. + 2. There is no service outage during the upgrade. + 3. The VNFs are providing services as usual after the upgrade. + +Use case #2: Roll-back after a failed smooth upgrade in a HA configuration +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +For a system with HA configuration, if the upgrade fails when the operator is +smooth-upgrading NFVI/VIM components into a new version using Escalator, the +operator can roll-back the system without any service outage. + +- Pre-Conditions + + 1. The system is running as normal. + 2. The VNFs are providing services as usual. + 3. Scale-up operation is disabled. + 4. Smooth upgrade failed. + +- Roll-back steps + + 1. Escalator concludes that the upgrade has failed and provides the operator + with the reason. + 2. Select the "Roll-back" operation. + 3. If the roll-back is successful, go to step 4, otherwise the operator can + select "Restore Backup" to restore the system from the backup data. + 4. Select "Restore Scale-up" after the roll-back. It will restore scale-up to + the original enabled/disabled state before upgrade. + +- Post-Conditions + + 1. The system is rolled-back successfully when the upgrade failed. + 2. There is no service outage during the roll-back. + 3. The VNFs are providing services as usual after the roll-back. + +Use case #3: Roll-back after a successful smooth upgrade in a HA configuration +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +When a smooth upgrade in a HA configuration is successful, the operator may want +to roll-back for some reasons, such as performance issues. +Escalator supports roll-back after a successful smooth upgrade without any +service outage. + +- Pre-Conditions + + 1. The system is running as normal. + 2. The VNFs are providing services as usual. + 3. Smooth upgrade succeeded. + +- Roll-back steps + + 1. Select "Disable Scale-up". It will limit the scale-up operation when roll- + back is in progress to prevent failures due to the shortage of resources. + 2. Select "Check Smooth Roll-back Conditions". If Escalator shows that there + are some conditions not satisfied, try to resolve them according to the + solutions provided. + 3. Select "Roll-back", then apply the roll-back operation. + 4. If the roll-back is successful, go to step 5, otherwise the operator can + select "Restore Backup" to restore the system from the backup data. + 5. Select "Restore Scale-up" after the roll-back. It will restore scale-up to + the original enabled/disabled state before roll-back. + +- Post-Conditions + + 1. The system is rolled-back successfully. + 2. There is no service outage during the roll-back. + 3. The VNFs are providing services as usual after the roll-back. + +Use case #4: Non-smooth upgrade in a non-HA/HA configuration +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +For a system with non-HA configuration, the operator can also use Escalator to +upgrade NFVI/VIM components into a new version. In this case, the upgrade may +result in service outage. In other words, the upgrade is non-smooth. +For a system with HA configuration, if the service outage is acceptable or +inevitable, the operator can also use Escalator to non-smoothly upgrade the +system. + +- Pre-Conditions + + 1. The system is running as normal. + +- Upgrading steps + + 1. The operator successfully logged in the GUI of Escalator to select the + software packages including Linux OS, Hypervisor, OpenStack, ODL and other + OPNFV components, ect. (All or part of components could be selected.) + 2. Select the nodes to be upgraded. i.e. controller node, network node, + storage node and compute node, etc. + 3. Select "Non-Smooth Upgrade", then apply the upgrade operation. + +- Post-Conditions + + 1. The system is upgraded successfully. + +Use case #5: Roll-back after a failed non-smooth upgrade in a non-HA/HA configuration +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +For a system with non-HA/HA configuration, if the upgrade fails when the +operator is non-smoothly upgrading NFVI/VIM components into a new version using +Escalator, the operator can roll-back the system. In this case, the roll-back +may result in service outage. + +- Pre-Conditions + + 1. The system is running as normal. + 2. Non-smooth upgrade failed. + +- Roll-back steps + + 1. Escalator concludes that the upgrade has failed and provides the operator + with the reason. + 2. Select the "Roll-back" operation. + 3. If the roll-back fails, the operator can select "Restore Backup" to restore + the system from the backup data. + +- Post-Conditions + + 1. The system is rolled-back successfully when the upgrade failed. + +Use case #6: Roll-back after a successful non-smooth upgrade in a non-HA/HA configuration +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +When a non-smooth upgrade in a non-HA/HA configuration is successful, the +operator may want to roll-back for some reasons, such as performance issues. +Escalator supports roll-back after a successful non-smooth upgrade. In this +case,the roll-back may result in service outage. + +- Pre-Conditions + + 1. The system is running as normal. + 2. Non-smooth upgrade succeeded. + +- Roll-back steps -Upgrade a system with Multi-Site configuration -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + 1. Select the "Roll-back" operation. + 2. If the roll-back fails, the operator can select "Restore Backup" to restore + the system from the backup data. -Upgrade in one site may cause service interruption to other site, if -both sites are depended and sharing the same modules/data base (e.g. a -keystone for both sites). +- Post-Conditions -If a site failure during an upgrade, the roll-back missing any minimal -state/data loss can cause an affect/failure to the depended site. + 1. The system is rolled-back successfully when the upgrade failed. -.. <hujie> Consider one site of ARNO release first. Then, multi-site - in the future.
\ No newline at end of file |