Upgrading SBCs in an N:1 Redundancy Group

This section describes the upgrade procedure for SBC instances in an N:1 redundancy group orchestrated in an OpenStack environment using Heat templates. N represents the number of active instances and can be up to 4, so a full 4:1 deployment has 5 total SBC instances. The following procedure shows example data for a full 4:1 deployment. Your implementation could include fewer instances and therefore require fewer steps.

Prerequisites

Perform the following activities prior to upgrading the SBC instances in the redundancy group.

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

Check the Status of the Instances

Ensure all the SBC instances (five, in a 4:1 redundancy group) and the EMS 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 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.  

   > 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      V07.02.00;
   }
   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      V07.02.00;
   }
   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      V07.02.00;
   }
   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      V07.02.00;
   }
   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      V07.02.00;
   }

Upgrade Process

Perform the following steps to upgrade, beginning with the instance you identified as the assigned standby instance.

1. Using EMA or the SBC CLI, determine the current role of the SBC instance to be upgraded. If the current role is active:

   1. Check the syncStatus field in the output of the rgStatus command to ensure that the sync status of the instance is syncCompleted. It may take up to 10 minutes after the previous SBC was upgraded before sync is achieved. 

   2. Use EMA or the SBC CLI to force a switchover of the SBC instance. 

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

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

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

5. 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. This step is not required if you use network-wide domain licensing (NWDL).

6. Select the next SBC instance to be upgraded. Repeat steps 1 through 5 on the instance.

7. Repeat step 6 for each subsequent instance until all instances are upgraded.

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.

   > 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      V08.00.00;
   }
   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      V08.00.00;
   }
   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      V08.00.00;
   }
   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      V08.00.00;
   }
   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      V08.00.00;
   }