DO NOT SHARE THESE DOCS WITH CUSTOMERS!

This is an LA release that will only be provided to a select number of PLM-sanctioned customers (PDFs only). Contact PLM for details.


Volume-based Upgrade Overview


Note

In this section, the upgrade procedure for a redundancy group consisting of one active and one standby is illustrated. However, the same procedure is applicable for a standalone instance upgrade. If you are doing volume-based upgrade of a standalone instance, ignore the instructions involving the standby.


A volume-based upgrade is a procedure which reuses the computing and network resources. Use this document to upgrade SBC software from release 7.x.


Tip

Before you start the upgrade process, ensure the following:

  • Save all of the CLI commands used for configuring the instance as a text file (.txtin your local machine. To reapply the existing configuration on the upgraded instance, copy this file to the upgraded instance using SCP or SFTP, and source it using the source <file_name/full_path> command. Reapply the configuration after you have completed executed the procedure described in this section.
  • Do not use any SBC Configuration Manager/EMA-based tool for downloading and reapplying the configurations.
  • Take a sysdump before the upgrade.

Procedure

  1. Login to the Active SBC CLI admin, and execute the following command to perform a backup of the configuration. The backup file is stored in the path as shown.

    % requests system admin vsbcSystem saveConfig







  2. SCP this configuration file from SBC to local server as below.


  3. Check the Status on SBC before upgrade.


    Ensure that you complete the configuration and userdata backup from the existing instances (both active and standby).
    Also, ensure that in your local machine, you have a copy of the license bundle you downloaded from the Ribbon Support Portal and used in the existing instance.

    The hypervisor changes when migrating from C4/M4 to C5/M5, rendering existing hypervisor licenses invalid. Contact your Ribbon representatives for new licenses.

  4. If user-data changes are required before the upgrade, then perform the substeps below. Otherwise, skip to step 5
    1. Shut down both the active and standby instances.
      1. Select the instance, right-click and select Stop Instance.
    2. While in stopped state, modify the userdata. You must provide the new userdata variables for the upgraded instance. Refer to Metadata and Userdata Formats on AWS for additional details.
    3. To view and modify userdata, on your AWS dashboard,
      1. Select the instance, right-click and select Instance Settings > View/Change User Data.
      2. Modify the userdata and then click Save.

        Note

        For assistance in modifying the userdata to suit the the upgraded instance requirements, refer to Metadata and Userdata Formats on AWS.

        The following new userdata variables are added for the upgraded instance:



        HA user-data
        {
            "ALT_Mgt0_00": "LOGICAL_MGMT_IP",
            "ALT_Pkt0_00": "VIP1",
            "ALT_Pkt1_00": "VIP2",
            "AdminSshKey": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCJnrFMr/RXJD3rVLMLdkJBYau+lWQ+F55Xj+KjunVBtw/zXURV38QIQ1zCw/GDO2CZTSyehUeiV0pi2moUs0ZiK6/TdWTzcOP3RCUhNI26sBFv/Tk5MdaojSqUc2NMpS/c1ESCmaUMBv4F7PfeHt0f3PqpUsxvKeNQQuEZyXjFEwAUdbkCMEptgaroYwuEz4SpFCfNBh0obUSoX5FNiNO/OyXcR8poVH0UhFim0Rdneo7VEH5FeqdkdGyZcTFs7A7aWpBRY3N8KUwklmNSWdDZ9//epEwgaF3m5U7XMd4M9zHURF1uQ/Nc+aiyVId9Mje2EU+nh6npaw/tEOPUiC1v",
            "CEName": "ISBC90R0SBC01",
            "CERole": "ACTIVE",
            "ClusterIp": "172.31.11.32",
            "HFE": "172.31.10.161",
            "IAM_ROLE": "SWe",
            "NodeName": "MA-90R0-91-Upgrade-HFEHA",
            "PeerCEHa0IPv4Address": "172.31.11.32",
            "PeerCEName": "ISBC90R0SBC02",
            "ReverseNatPkt0": "True",
            "ReverseNatPkt1": "False",
            "SbcHaMode": "1to1",
            "SbcPersonalityType": "isbc",
            "SortHfeEip": "True",
            "SystemName": "ISBC90R0SBC",
            "TemplateName": "AWS_HA_template.json",
            "TemplateVersion": "V09.00.00R000",
            "ThirdPartyCpuAlloc": "0",
            "ThirdPartyMemAlloc": "0"
        }

        Note

        You need to set the SbcHaMode from "Nto1" to "1to1" before performing an upgrade in the instance of a standalone system.

    4. Start both the active and standby instances
      1. Select the instance, right-click and select Start Instance.
  5. If IAC is used for upgrade, proceed to Replacement Upgrade for AWS and then continue from step 11 for restoring the config. Otherwise if IAC is not used for the upgrade, follow the steps below and continue to the end of this procedure. 

  6. Create two new volumes using the new AMI ID snapshot provided for the volume-based upgrade. For information on creating volumes, refer to Create, Detach, and Attach Volumes in AWS.

    Note

    Ensure that the new volumes are created in the same "Availability zone" as that of the running the existing instance.

  7. Shut down the existing instance (both active and standby volumes).

    Note

    Volume-based upgrade is applicable only for offline upgrade. All participating HA pair instances should be turned off during the upgrade.

  8. After the existing instance is completely shut down, detach the active and standby volumes from the instance. For information on detaching volumes, refer to Create, Detach, and Attach Volumes in AWS.

  9. Attach the new active and standby volumes created using the upgraded instance AMI snapshot to the existing instance. For information on attaching volumes, refer to Create, Detach, and Attach Volumes in AWS.

    Note

    The new volumes must be associated as root volumes (device name: /dev/sda1) to the corresponding instances.

    Caution

    Do not start the instance immediately after attaching the new volumes. You must execute the next steps.

    The following step applies only for volume-based upgrades from 5.1 to 6.2.1. Skip this step if you are not upgrading on this specific path.

  10. Start the upgraded instances.

  11. Login to the CLI of the upgraded instance as linuxadmin and perform the following steps:
    1. Check for the persistence of the UUID of the instance. On successful upgrade, it must remain same.
      (Refer to Metadata and Userdata Formats on AWS for details)

    2. Check for the correctness of the upgrade by executing the command swinfo.
      (Refer to Metadata and Userdata Formats on AWS for details)

      Note

      On successful upgrade, the values for the fields OS, SonusDB, EMA, and SBC must change to reflect the new build.

      The values displayed against the fields Installed host role and Current host role varies depending on whether the volume to which you have logged on is active or standby.

    3. Check whether the userdata variables reflect the modified values.
      (Refer to Metadata and Userdata Formats on AWS for additonal details)

  12. Copy the saved configuration from release 7.x on local server to the upgraded Active SBC.

  13. Run below command to load the 7.x configuration. After loading the configuration, both SBCs will go for restart. This will take approximately 10 minutess (depending on the configuration size) for the 7.x configuration to load.



  14. After loading the configuration, check the server status using the CLI ‘show table system serverStatus’ to ensure that calls are running successfully.


  15. Login to the CLI of the upgraded instance as linuxadmin, and then SSH to admin to verify the licenses are correctly retained using the command:
    > show table system licenseInfo

    Note

    Login is via the AdminSshKey in the userdata.

Volume-based Revert

Procedure

Use the following procedure to perform the revert operation:

  1. Shut down both the active and standby instances.
    1. Select the instance and then right-click and select Stop Instance.
    2. In the stopped state, modify the user data to an older release, if changed while upgrading. For more information, refer to Metadata and Userdata Formats on AWS.
    3. To view and modify the user data:
      1. Select the instance on your AWS dashboard.
      2. Right-click and select Instance SettingsView/Change User Data.
      3. Modify the user data and then click Save.
  2. Detach the Upgrade Volume from the Active instance and then from the Standby instance from the AWS Dashboard. For information, refer to Create, Detach, and Attach Volumes in AWS.
  3. Attach the older version SBC Active volume to Active instance and Standby volume to Standby instance. For more information, refer to Create, Detach, and Attach Volumes in AWS.
  4. Once step 3 is completed for the Active and Standby instances, start the Active instance first and make sure the application is up on Active. Then start the Standby instance and make sure the application is up on Standby.
    To see the older version, run the command "show table system severStatus" on the Active SBC.

Recover SBC SWe on Public Cloud After Reverting to a pre-11.0 Release

Use the following procedure to recover the SBC SWe HA on public cloud after reverting to a pre-11.0 release if the SBC application does not come up on both the active and standby nodes.

Note

This procedure is only applicable if the system is upgraded from a pre-11.0 release to this release using the following method:

  • Bring up the SBC HA application with a pre-11.0 release on public cloud (For example, AWS).
  • Upgrade both the active and standby SBC to this release using the recommended upgrade method.


StepAction
1
  1. Revert the SBC application to pre-11.0 release.
  2. Once complete, check to see if application is coming up fine on both active and standby nodes.

  3. If the SBC application is stuck and unable to receive the assigned role, stop the SBC application on both active and standby nodes using the
    command sbxstop.
2

If present, remove the following file/directories from both the active and standby SBC:

  • rm -rf /home/cnxipmadmin/peerDynamicHANewComps
  • rm -rf /opt/sonus/sbx/openclovis/var
3
  1. Start the SBC application on both the active and standby nodes using the ‘sbxstart’ command.
  2. Check to make sure that the application starts up on both nodes. 

    Note

    If you are using the RAF for upgrade/revert, perform the steps 1.3 to 3.1 within 30 minutes after running the revert operation. This ensures that the RAF can detect the correct state of VNF and mark the operation as complete.