You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

In this section:

Related articles:

Important

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


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 a

Unable to show "metadata-from": No such page "_space_variables"
system in the deployment. 

Prerequisites

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

StepAction
1

Upgrade the

Unable to show "metadata-from": No such page "_space_variables"

If there is a

Unable to show "metadata-from": No such page "_space_variables"
in your deployment, upgrade it first before upgrading the SBC nodes.

Refer to one of the following pages:

2

Download the Software Image

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

3

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.

4

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 

Unable to show "metadata-from": No such page "_space_variables"
 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. 

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


Start

StepAction
1

Check the Status of the Instances

  1. Ensure both the SBC instances and the
    Unable to show "metadata-from": No such page "_space_variables"
    (if present) are up and running.
  2. Navigate to Project > Compute > Instances in the Horizon GUI to check the instance status in the "Instances" window.
2

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. 
3

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 the
    Unable to show "metadata-from": No such page "_space_variables"
    , this upgrade also triggers updating the configuration stored for the HA pair on
    Unable to show "metadata-from": No such page "_space_variables"
    to the format for the target release. 


Post-Upgrade Monitoring

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


StepAction
1Log on to CLI of the active SBC instance as an admin user.
2Execute the following command: show status system serverStatus
3Check the value of the parameter appVersion. The output identifies the software version.
4Check the syncStatus field in the output to ensure that the status is in the syncCompleted state.


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.

  • No labels