Upgrading SBC SWe Cloud Instances using VNFM

Prerequisites

Before initiating the upgrade make sure you:

Download the required files for the new version of SBC software. Refer to the release notes for the new SBC software release. These include:
- .qcow2 file that contains the SBC software
- Script to generate a customized Cloud Service Archive (CSAR) package file
- Virtual Network Function Descriptor (VNFD) template file to use with the script
Run the script to generate a custom CSAR package file for your deployment. Refer to Creating a CSAR Package File.
Create an OpenStack Glance image using the SBC application software .qcow2 file. Refer to Creating a Glance Image.
Onboard the CSAR package file you created for your deployment. Refer to Onboarding the SBC CSAR package file.
Check the VNF Status window. The VNF you want to upgrade must be in Ready status, meaning that the status of each VM within it is Available.
Ensure the pre-upgrade cluster configuration is saved to the EMS. Note that for N:1 HA upgrades, the Load Balancing Service (LBS) must be configured on the nodes prior to upgrading.
Use the EMS to determine which node within the VNF currently has the standby role, or use the following CLI procedure:
1. Log into the CLI of one of the nodes.
2. Issue the command: show status system rgStatus
3. Check the output to determine which node shows its assignedRole as standby.

Upgrade Procedure

Monitoring Node Status During Upgrade

Before and during the upgrade procedure, use the SBC CLI to check the status of the nodes you are upgrading:

Log into the CLI of one of the nodes.
Issue the command: show status system rgStatus and check the output to:
- Determine which node shows its assignedRole as standby. This is the node to upgrade first.
- Verify that the syncStatus of all the currently active SBC VM(s) is syncCompleted.
- Verify that the syncStatus of the current standby SBC VM is unprotectedRunningStandby.

The following is an example of the type of output that would appear in a 4:1 HA deployment:

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

Throughout the upgrade process, maintain a CLI session in one of the VMs to monitor rgStatus. When it is time to upgrade the VM where you are monitoring rgStatus, start a CLI session in an upgraded VM to continue monitoring rgStatus. While upgrading it is also helpful to keep track of which node is the leader node for the cluster by issuing the command:
show table system loadBalancingService leaderStatus

The command output lists all of the active nodes in the cluster and the leader node is the first node listed, for example:

> show table system loadBalancingService leaderStatus
LEADER  LEADER
ID      IPADDRESS  STATE
--------------------------
0 192.168.10.6 completed
1 192.168.10.10 completed
[ok][2018-11-15 21:52:51]

The upgrade procedure on VNFM occurs in two phases: specifying the software version at the VNF level followed by upgrading the individual VM nodes.

Specifying the Upgrade Version

Complete the following steps to specify to which version of software you want to upgrade the VM nodes within the VNF. Be aware that all nodes must be in "Available" status when you begin this process or the option to upgrade will not be available.

Log into VNFM with the credentials provided by the VNFM administrator.
Click VNF Status in the left pane of VNFM to open the VNF Status window where a list of deployed VNFs appears.
In the Select Action list adjacent to the VNF you want to upgrade, select Upgrade. An Upgrade VNF window opens.

Upgrade VNF Window
In the Upgrade Version list, select the software version you want to upgrade to. The list contains the available, onboarded software versions.
Optionally, enter an Upgrade Reason.
Click Save. VNFM changes the status of the VNF from "Ready" to "Upgrading."

Upgrading the VM nodes

Complete the following steps to upgrade the VM nodes, beginning with the standby node.

On the VNF Status window, click on the cluster to open the Deployed VNF Summary window. This window shows detailed information on the VM nodes within the VNF. The status for the individual nodes appears as "Upgrade Required."
Log into the CLI of the node you are upgrading and issue the command: sbxstop
Note: Make sure the process to stop the SBC has completed before continuing.
In the Select Action list adjacent to the VM node you are upgrading, select UPGRADE. The Upgrade VM window opens.
Select one of the Upgrade options: Rebuild or Recreate_reuse. Refer to the following figure for descriptions of each option. Note that if the VM has an attached Cinder boot volume, the Rebuild option is not offered, you must use Recreate_reuse.

Upgrade VM Options
Click Upgrade VM. VNFM initiates the upgrade and the status of the VM appears as "Upgrade in Progress."
After the VM status changes to "Upgraded" and the node is back in service, determine the next node to upgrade. In a 1:1 HA deployment, this will be the currently active node. In an N:1 HA deployment, select one of the active nodes. 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.
Repeat steps 2 through 6 for the active node in a 1:1 HA deployment. In an N:1 HA deployment, repeat steps 2 through 6 for each active node, one by one, until all VMs are upgraded.

After each node is upgraded, its status changes to "Upgraded." After the last node in the VNF is upgraded, the status of the active node(s) changes to "Available." The status of the standby node changes to "Maintenance" for a short time before it comes into service and then it also becomes "Available."

You can then return to the VNF Status window where the status for the VNF as a whole changes to "Ready."

Post-Upgrade Verification

To verify that the nodes instances are up and running with the upgraded software version:

Log into the CLI of one of the nodes.
Issue the command: show status system rgStatus
In the output, check that the value for syncStatus for the currently active instance is syncCompleted. The value for the standby instance should appear as unprotectedRunningStandby.

Space shortcuts

Page tree