Page History

Info
title Note:
The 12.0 Insight EMS supports two configuration models for SBC 8.0 clusters. SBC clusters comprising multiple active SBC instances must be defined with a configuration type of "OAM." For these clusters, a 1:1 OAM node pair provides the northbound Prior releases supported using one of the SBC nodes within the cluster, referred to as the "HeadEnd" SBC, to configure the other nodes. Release 8.0 introduces a new configuration model 1:1 HA pair of dedicated Operations, Administration, and Maintenance (OAM) nodes to configure and manage SBC nodes in N:1 distributed deployments.OA&M) functions for the cluster. SBC clusters containing a single SBC or a 1:1 SBC HA pair can be defined with a configuration type of "Direct Single." For these clusters, the active SBC is used for OA&M operations. The 12.0 Refer to SBC SWe Configuration Management for more information on the new models. The Insight EMS continues to support the existing HeadEnd model to enable migrating clusters to the new configuration model. However an SBC cluster operating with SBC release 8.0 for SBC 7.2 clusters. However, SBC cluster deployments must migrate to one of the OAM node configuration model. Refer new configuration models when upgrading to SBC 8.0. Refer to Migrating an existing Existing SBC Cluster to OAM Configuration Mode for more informationConfiguration Mode or to Migrating an Existing SBC Cluster to Direct Single Configuration Mode before upgrading an SBC cluster.

Warning
title Warning
In a distributed SBC deployment, the M-SBCs SBC clusters must be upgraded first, followed by the S-SBCsSBC clusters.

 

This section describes the upgrade procedure for SBC instances in an N:1 redundancy group that were orchestrated in an OpenStack environment using Heat templates. "N" N represents the number of active instances and can be a value up to 4. A , so a full 4:1 deployment has 5 total SBC instances. The  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 to release from a pre-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
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 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. After upgrade you will need to 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.

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.  

   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 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; }

Anchor
Upgrade Process Upgrade Process

Upgrade Process

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

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

1. Perform sbxstop on the instance you are upgrading.

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

5. Repeat steps 1 to 4 to upgrade the active instances, one by one. Before upgrading an instance, check the syncStatus field in 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 Upgrading SBCs in an N:1 Redundancy Group.

6. Once the stack updates are completed, all the instances will be running the upgraded image.

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 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; }

Info
title Note
Upgrading a redundancy group impacts the service provided by all the instances of the group may impact transient calls. Stable calls are not affected. 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.

 

Pagebreak