In this section:
The 12.x Insight EMS supports two configuration models for SBC clusters, beginning with SBC release 8.0. SBC N:1 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 Operations, Administration, and Maintenance (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.x Insight EMS continues to support the existing HeadEnd model for SBC 7.2 clusters. However, SBC cluster deployments must migrate to one of the new configuration models when upgrading to SBC 8.0 or later. Refer to Migrating an Existing SBC Cluster to OAM Configuration Mode or to Migrating an Existing SBC Cluster to Direct Single Configuration Mode before upgrading an SBC cluster.
In a distributed SBC deployment, upgrade the clusters in the following order: OAM nodes, then T-SBC clusters, then M-SBC clusters, then S-SBC clusters.
This section describes the upgrade process 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. If the deployment you are upgrading includes OAM nodes, the OAM nodes should be upgraded before you upgrade the SBC nodes.
The following procedure describes the upgrade procedure for a full 4:1 SBC deployment that includes OAM nodes. Your implementation could include fewer instances and therefore require fewer steps.
Perform the following activities prior to upgrading the SBC instances within the deployment.
Upgrade the EMS in your deployment before upgrading the OAM nodes or the SBC nodes. Refer to EMS SWe on OpenStack.
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 on OpenStack for more information on generating and including the login userdata that must be provided.
Ensure all the SBC instances (five, in a 4:1 redundancy group), the OAM nodes, 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.
For deployments that include existing OAM nodes, upgrade the OAM nodes before upgrading the SBC nodes in the deployment. The nodes must be upgraded in the order given in these procedures (EMS, followed by OAM nodes, followed by SBC nodes) to ensure that the existing SBC configuration data is preserved and upgraded to the current format.
Begin by upgrading the standby OAM node, followed by the active OAM node.
To identify the standby OAM node:
show status system serverStatus
mgmtRedundancyRole.
The output identifies the node as either active
or standby
. Perform the following steps to upgrade the OAM 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 on OpenStack and Developing a Heat Template.
In OpenStack, use either the Horizon dashboard or the CLI (heat stack-update
command) to replace the instance.
request system admin <SYSTEM NAME> switchover
The standby instance that you just upgraded becomes the active node.
show table system admin <SYSTEM NAME> savedConfigurations
Verify that the output includes a revision showing software version matching the target version to which you are upgrading. For upgrades from release 7.2, if the OAM nodes go to an unregistered state on the EMS while coming up, reboot the OAM nodes to get them back to a registered online state. If needed, this reboot is not service impacting because the OAM nodes are not processing calls.
Upgrade the nodes in an SBC redundancy group beginning with the standby node.
To identify the assigned standby instance:
show status system rgStatus
assignedRole
. In the following example output, the second node listed is the standby node.> 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; }
assignedRole
standby
instance must be upgraded first, followed by the assignedRole active instances.Perform the following steps to upgrade, beginning with the instance you identified as the assigned standby instance.
Using EMA or the SBC CLI, determine the current role of the SBC instance to be upgraded. If the current role is active:
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.
Use EMA or the SBC CLI to force a switchover of the SBC instance.
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 on OpenStack and Developing a Heat Template.
In OpenStack, use either the Horizon dashboard or the CLI (heat stack-update
command) to replace the instance.
Select the next SBC instance to be upgraded. Repeat steps 1 through 5 on the instance.
To verify if the instances are up and running with the upgraded software image:
admin
user.Execute the following command and check the appVersion
field for each of the instances. Check the syncStatus
field in the rgStatus
output to ensure that all the currently active instances are in the 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.01.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.01.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.01.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.01.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.01.00; }
In the earlier releases, on the N:1 SWe and Cloud SBC instances, the processor indices (which are used for call capacity estimates) were hard-coded to the following values :
This was made so that all the instances constituting a redundancy group uses the same indices, resulting in same call capacity estimate.
In the current release, these processor indices are calculated and exchanged across the instances in a redundancy group, resulting in all the instances locking themselves to the same set of indices in a redundancy group. This also results in more realistic call capacity estimate by the instances in N:1 SWe and Cloud SBC scenario.
If you wish to continue using the hard-coded processor indices after upgrading to the current release, you need to provide an additional metadata parameter to the standby instance prior to the upgrade. Following is the key value pair to be updated in the metadata:
(No changes are required during the upgrade in the metadata/userdata if you wish to use the calculated processor indices.)