Page History

Info
title Important
This replacement-based upgrade process applies only if you are upgrading from release 8.1 or later. HA model changes introduced in release 8.1 must already be in effect in your deployment to follow this procedure. If you are upgrading from an earlier release, refer to Upgrading pre-8.1 SBC SWe 1:1 HA Nodes on OpenStack.

Info
You can use the existing Cinder when upgrading.  Detach the cinder before deleting the SBC node, and then attach the same cinder while spawning the node in new build.

This section describes the upgrade process for SBC instances in an 1:1 HA redundancy model orchestrated in an OpenStack environment using Heat templates. In a 1:1 HA deployment, the currently active SBC node provides the configuration interface for the pair. The configuration data for the HA pair is automatically synchronized from the active node to the standby node.

When configured in 1:1 HA mode, the SBC supports a replacement-based upgrade process. The configuration data for the pair is maintained during the upgrade process as each node is upgraded, one at a time, beginning with the standby node.

The SBC SWe can be deployed in 1:1 HA mode either with or without an Insight EMS system in the deployment. 

Prerequisites

Perform the following activities prior to upgrading the SBC instances within the deployment.

Upgrade the Insight EMS

If there is an EMS in your deployment, upgrade it first before upgrading the SBC nodes. Refer to Steps for Migrating EMS SWe Standalone Upgradeon OpenStack or Steps for EMS Migrating GR Upgradeon OpenStack. 

Download the Software Image

Download the required .QCOW2 and .md5 files from the Customer Portal.

Upload the Software Image to OpenStack

To upload the .QCOW2 file to OpenStack, navigate to Project > Compute > Images. For more information, refer to Creating a Glance Image.

Update the Heat Templates with Mandatory Login Information

Beginning with release 7.1, you must include SSH keys or passwords for the admin and linuxadmin accounts in the userdata you provide during orchestration of an SBC instance. Therefore during upgrade from a pre-7.1 release, an updated Heat template that contains the mandatory keys or passwords must be applied.

Prior to upgrade, you must update the template used to deploy the instance to include the mandatory SSH key or password userdata. The example templates 

Spacevars
0 company

 provides include information on how to include this data in a template. Because they are more secure, SSH key fields are mandatory in the example Heat templates. Passwords are optional fields.The password input is not plain text, it is a hash of the password. Refer to Metadata and Userdata Format on OpenStack for more information on generating and including the login userdata that must be provided. 

Info
title Note
During upgrade, the changed userdata in the Heat template results in the SBC instance being recreated in OpenStack with a new Universal Unique Identifier (UUID) value. If a node is configured to use node-locked licensing, after upgrading the node you must generate a new license for the node using the new UUID.

Upgrade Process

Complete the following procedures to upgrade a 1:1 HA pair of SBC SWe nodes.

Check the Status of the Instances

Ensure both the SBC instances and the EMS, if present, are up and running.

To check the instance status in the Instances window, navigate to Project > Compute > Instances in the Horizon GUI.

Identify the Standby SBC Node

To identify the standby SBC node:

1. Log onto the CLI of one of the SBC nodes.
2. Execute the following command: show status system serverStatus
3. Check the value of the parameter mgmtRedundancyRole. The output identifies the node as either active or standby. 

Upgrade each SBC Node

Perform the following steps to upgrade the SBC nodes, beginning with the instance you identified as the standby node.

1. In OpenStack, use either the Horizon dashboard or the CLI to shut down the instance (Shut off Instance option in Horizon).

2. Ensure you have updated any metadata or other parameters in Heat templates as required for the target release. Refer to Metadata and Userdata Format on OpenStack and Developing a Heat Template.

3. In OpenStack, use either the Horizon dashboard or the CLI (heat stack-update command) to replace the instance. 

4. If you use node-locked licensing, use the new VM UUID to generate a new license file bundle and install the license.To regenerate a license based on a new UUID, follow the license instructions that you received when licenses were originally purchased. Refer to License Management - Node Locked License Settings for information on installing the new license on the instance using EMA. 
5. After the upgrade of the standby instance completes, repeat the steps to upgrade the active SBC node instance. Initiating this process triggers a switchover so that the standby instance that you previously upgraded becomes the active node. For deployments that include an EMS, this also triggers updating the configuration stored for the HA pair on the EMS to the format for the target release. 

Post-Upgrade Monitoring

To verify that the active instance is running the upgraded software image:

1. Log on to CLI of the active SBC instance as an admin user.
2. Execute the following command: show status system serverStatus
3. Check the value of the parameter appVersion. The output identifies the software version.

4. Check the syncStatus field in the output to ensure that the status is in the syncCompleted state.

Info
title Note
If the upgrade fails for either instance, you must revert back both instances to the previous build. Reverting instances in a cloud environment is service-impacting.

 

Pagebreak