In this section:
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 1:1 HA SBC SWe Nodes on OpenStack to SBC 8.1.
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.
Perform the following activities prior to upgrading the SBC instances within the deployment.
If there is an EMS in your deployment, upgrade it first before upgrading the SBC nodes. Refer to Steps for EMS SWe Standalone Upgrade or Steps for EMS GR Upgrade.
Download the required .QCOW2
and .md5
files from the Customer Portal.
To upload the .QCOW2
file to OpenStack, navigate to Project > Compute > Images. For more information, refer to Creating a Glance Image.
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 Ribbon 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 for more information on generating and including the login userdata that must be provided.
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.
Complete the following procedures to upgrade a 1:1 HA pair of SBC SWe cloud nodes.
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.
To identify the standby SBC node:
show status system serverStatus
mgmtRedundancyRole
. The output identifies the node as either active
or standby
. Perform the following steps to upgrade the SBC nodes, beginning with the instance you identified as the standby node.
In OpenStack, use either the Horizon dashboard or the CLI to shut down the instance (Shut off Instance option in Horizon).
Ensure you have updated any metadata or other parameters in Heat templates as required for the target release. Refer to Metadata and Userdata Format and Developing a Heat Template.
In OpenStack, use either the Horizon dashboard or the CLI (heat stack-update
command) to replace the instance.
To verify that the active instance is running the upgraded software image:
admin
user. show status system serverStatus
appVersion
.
The output identifies the software version.Check the syncStatus
field in the output to ensure that the status is in the syncCompleted
state.
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.