Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: added Akshat to approvers as suggested by Sriram

Add_workflow_for_techpubs
AUTH1
REV5
REV6
REV3
REV1
REV2

 

Panel

In this section:

Table of Contents
maxLevel4

Info
titleNote:

Prior releases supported the use of a dedicated SBC Configurator cluster to configure other SBC SWe clusters. This approach is replaced by using one of the SBC nodes within the cluster, referred to as the "Headend" SBC, to configure the other nodes. While the SBC Configurator currently remains supported for backward compatibility, it will be deprecated in a subsequent release. It is strongly recommended that you adopt the Headend SBC configuration model. Refer to Configuring an SBC SWe Cluster using the EMS.

Warning
titleWarning

In an N:1 Redundancy Group, the M-SBCs must be upgraded first, followed by the S-SBCs.

 

This section describes the upgrade procedure of M-SBC instances in an N:1 Redundancy Group (RG) that were orchestrated in an OpenStack environment using Heat templates.

Prerequisite

Prerequisites

Perform the following activities prior to upgrading the M-SBC instances in an RG.

Download the Software Image

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

Upload the Software Image to OpenStack

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

Update the Heat Template 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 to release 7.1 from a prior 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
0company
 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. 

Info
titleNote:

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. After upgrade you will need to generate a new license using the new UUID.

Check the Status of the Instances

In an M-SBC Redundancy Group, ensure all the five instances (4:1) and the EMS are up and running.

To check the instancesinstance status in the Instances window, navigate to Project > Compute > Instances. The Instances window is displayed. The Instances window displays the status of the current image.

Caption
0Figure
1M-SBC Instances in an RG

Image Removed

Identify the Assigned

 in the Horizon GUI.

Identify the Standby Instance

To identify the assigned standby instance, perform the following steps:

  1. Log on to CLI of any of the instances as the admin user. Execute the following command and check the value of the parameter assignedRole.  

    Code Block
    > show status system rgStatus
    rgStatus vsbc1-192.168.2.3 {
        actualCeName    vsbc1;
        assignedRole    active;
        currentRole     active;
        nodeId          1;
        serviceId       0;
        syncStatus      syncCompleted;
        usingMetavarsOf vsbc1-192.168.2.3;
        appVersion      V06V07.0200.01A01300;
    }
    rgStatus vsbc1-192.168.2.4 {
        actualCeName    vsbc1;
        assignedRole    standby;
        currentRole     standby;
        nodeId          2;
        serviceId       1;
        syncStatus      unprotectedRunningStandby;
        usingMetavarsOf vsbc1-192.168.2.4;
        appVersion      V06V07.0200.01A01300;
    }
    rgStatus vsbc1-192.168.2.5 {
        actualCeName    vsbc1;
        assignedRole    active;
        currentRole     active;
        nodeId          3;
        serviceId       2;
        syncStatus      syncCompleted;
        usingMetavarsOf vsbc1-192.168.2.5;
        appVersion      V06V07.0200.01A01300;
    }
    rgStatus vsbc1-192.168.2.6 {
        actualCeName    vsbc1;
        assignedRole    active;
        currentRole     active;
        nodeId          4;
        serviceId       3;
        syncStatus      syncCompleted;
        usingMetavarsOf vsbc1-192.168.2.6;
        appVersion      V06V07.0200.01A01300;
    }
    rgStatus vsbc1-192.168.2.7 {
        actualCeName    vsbc1;
        assignedRole    active;
        currentRole     active;
        nodeId          5;
        serviceId       4;
        syncStatus      syncCompleted;
        usingMetavarsOf vsbc1-192.168.2.7;
        appVersion      V06V07.020.01A01300;
    }

Anchor
Upgrade Process
Upgrade Process
Upgrade Process

Info
titleNote
  • The assignedRole standby instance must be upgraded first, followed by the active instances.
  • Only Upgrade only one instance must be upgraded at a time.

Perform the following steps to upgrade, beginning on the standby instance.

  1. Perform sbxstop on the instance you are upgrading.On

  2. In OpenStack, use either the Horizon dashboard or the CLI to shut down (Shut off Instance option in Horizon) the instance. 
  3. In OpenStack, use either the Horizon dashboard or the CLI (heat stack-update command) to update the stack using the template you modified to include login userdata. 

  4. 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 - Legacy License Settings for information on installing the new license on the instance using EMA.
  5. Repeat steps 1 to 4 to upgrade the active instances, navigate to Project > Compute > Instances. The Instances window is displayed. AnchorRebuildRebuildFrom the drop-down list corresponding to the standby instance, select the option Rebuild Instance.

    Caption
    0Figure
    1Selecting Rebuild Instance Option

    Image Removed

    The Rebuild Instance window is displayed.Click Rebuild Instance to rebuild the instance with the upgraded image details.
    Caption
    0Figure
    1Rebuild Instance

    Image Removed

    The status of the Task column is displayed as Rebuilding.
    Caption
    0Figure
    1Rebuilding Process

    Image Removed

    Repeat the steps (1 to 3 from the Upgrading M-SBC in N:1 Redundancy Group section) to upgrade the active instances one by one. Before upgrading an instance,
    check the syncStatus field in rgStatus output to the output of the rgStatus command to ensure that all the currently active instances are in the syncCompleted state. The standby instance displays syncStatus as unprotectedRunningStandby. For more information, see section see Upgrading M-SBC in N:1 Redundancy Group.

  6. Once the rebuilds stack updates are completed, all the instances will be running with the upgraded image details. Caption0Figure1Rebuilding Process Completed for All the Instances

    Image Removed

Anchor
Post-Upgrade Monitoring
Post-Upgrade Monitoring
Post-Upgrade Monitoring

To verify if the instances are up and running with the upgraded software image:

  1. Log on to CLI of any of the instances as admin user.
  2. Execute the following command and check the appVersion field for each of the instances. Check syncStatus field in rgStatus output to ensure that all the currently active instances are in syncCompleted state. The standby instance displays syncStatus as unprotectedRunningStandby.

    Code Block
    > show status system rgStatus
    rgStatus vsbc1-192.168.2.3 {
        actualCeName    vsbc1;
        assignedRole    active;
        currentRole     active;
        nodeId          1;
        serviceId       0;
        syncStatus      syncCompleted;
        usingMetavarsOf vsbc1-192.168.2.3;
        appVersion      V06V07.0201.01A02200;
    }
    rgStatus vsbc1-192.168.2.4 {
        actualCeName    vsbc1;
        assignedRole    standby;
        currentRole     standby;
        nodeId          2;
        serviceId       1;
        syncStatus      unprotectedRunningStandby;
        usingMetavarsOf vsbc1-192.168.2.4;
        appVersion      V06V07.0201.01A02200;
    }
    rgStatus vsbc1-192.168.2.5 {
        actualCeName    vsbc1;
        assignedRole    active;
        currentRole     active;
        nodeId          3;
        serviceId       2;
        syncStatus      syncCompleted;
        usingMetavarsOf vsbc1-192.168.2.5;
        appVersion      V06V07.0201.01A02200;
    }
    rgStatus vsbc1-192.168.2.6 {
        actualCeName    vsbc1;
        assignedRole    active;
        currentRole     active;
        nodeId          4;
        serviceId       3;
        syncStatus      syncCompleted;
        usingMetavarsOf vsbc1-192.168.2.6;
        appVersion      V06V07.0201.01A02200;
    }
    rgStatus vsbc1-192.168.2.7 {
        actualCeName    vsbc1;
        assignedRole    active;
        currentRole     active;
        nodeId          5;
        serviceId       4;
        syncStatus      syncCompleted;
        usingMetavarsOf vsbc1-192.168.2.7;
        appVersion      V06V07.0201.01A02200;
    }
Info
titleNote
  • Upgrading a Redundancy Group impacts the service provided by all the instances of the group.
  • The upgrade process of a Redundancy Group is completed only after all the instances of the group are upgraded to the same build.
  • If the upgrade fails for any of the instances, you must revert back all the instances of the group to the previous build using the Rebuild Instance process.

 

Pagebreak