In this section:

Modified: for 6.2.1

 

Volume-based Upgrade

Note

For 6.2.1 release, the volume-based upgrade procedure is only supported on AWS platform for SBC SWe Cloud deployments. 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.

Volume-based upgrade is a procedure in which the computing and the network resources can be reused.

Procedure

The steps to perform a volume-based upgrade from 5.1.0Sxxx to 6.2.1 are:

Tip

Before you start the upgrade process, you must have all the CLI commands used for configuring the 5.1.0Sxxx instance saved as a text (.txt) file in 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.

  1. Ensure that you have taken back-up of configurations and userdata from the 5.1.0Sxxx instances (both active and standby). Also, ensure that in your local machine, you have a copy of the license bundle you downloaded from Salesforce and used in the 5.1.0Sxxx instance.

  2. Using a 6.2.1 AMI snapshot, create two new volumes - an active and a standby volume. 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 5.1.0Sxxx instance.

  3. Shutdown the 5.1.0Sxxx 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.

  4. After the 5.1.0Sxxx 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.

  5. Attach the new active and standby volumes created using 6.2.1 AMI snapshot to the 5.1.0Sxxx 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.

  6. While in stopped state, modify the userdata. You must provide the new userdata variables for 6.2.1, as described in Table 1: Mandatory New Userdata Variables and Table 2: Optional New Userdata Variables. To view/modify userdata, on your AWS dashboard:
    1. Select the instance, right click and navigate to Instance Settings > View/Change User Data.

      Select Instance

    2. Modify the userdata and click Save.

      View/Change User Data


      For assistance in modifying the userdata to suit the 6.2.1 requirements, use the following templates:

      Userdata template for 6.2.1 ACTIVE:

      Userdata template for 6.2.1 STANDBY:

      {

      "ALT_Mgt0_00": "LOGICAL_MGMT_IP",

      "ALT_Pkt0_00": "VIP1",

      "ALT_Pkt1_00": "VIP2",

      "CEName": "vsbc1",

      "CERole": "ACTIVE",

      "NodeName": "Vol",

      "PeerCEHa0IPv4Address": "172.31.11.44",

      "PeerCEName": "vsbc1",

      "ReverseNatPkt0": "True",

      "ReverseNatPkt1": "True",

      "SystemName": "vsbcSystem",

      "ClusterIp": "<MODIFY - Provide Ha0 IP address of the peer instance. The value should be same as that of the value for the variable PeerCEHa0IPv4Address>",                               

      "ActiveRoleMgtId": "<MODIFY - Provide eth0 interface ID of the instance having assigned role (CERole) as  ACTIVE.>",                          

      "SbcMgmtMode": "centralized",                               

      "SbcPersonalityType": "isbc",                               

      "TemplateName": "AWS_HA_template.json",                     

      "TemplateVersion": "V06.02.01R000"

      }

      {

      "ALT_Mgt0_00": "LOGICAL_MGMT_IP",

      "ALT_Pkt0_00": "VIP1",

      "ALT_Pkt1_00": "VIP2",

      "CEName": "vsbc2",

      "CERole": "STANDBY",

      "NodeName": "Vol",

      "PeerCEHa0IPv4Address": "172.31.11.44",

      "PeerCEName": "vsbc1",

      "ReverseNatPkt0": "True",

      "ReverseNatPkt1": "True",

      "SystemName": "vsbcSystem",

      "ClusterIp": "<MODIFY - Provide Ha0 IP address of the peer instance. The value should be same as that of the value for the variable PeerCEHa0IPv4Address>",                               

      "ActiveRoleMgtId": "<MODIFY - Provide eth0 interface ID of the instance having assigned role (CERole) as  ACTIVE.>",                          

      "SbcMgmtMode": "centralized",                               

      "SbcPersonalityType": "isbc",                               

      "TemplateName": "AWS_HA_template.json",

      "TemplateVersion": "V06.02.01R000"

      }

      Note

      The text within <> brackets are only for your understanding, and not part of the actual userdata in JSON format. Using the instructions given within <> brackets, modify the templates with actual values.

      Ensure that you only modify the values for the parameters ClusterIp and ActiveRoleMgtId.

      Do not modify the values of the following variables inherited from the 5.1.0Sxxx instance:

      ALT_Mgt0_00

      ALT_Pkt0_00

      ALT_Pkt1_00

      CEName

      CERole

      NodeName

      PeerCEHa0IPv4Address

      PeerCEName

      ReverseNatPkt0

      ReverseNatPkt1

      SystemName

      For information on the new userdata variables for 6.2.1, see Table 1: Mandatory New Userdata Variables and Table 2: Optional New Userdata Variables.

      The following new userdata variables are added for 6.2.1:

      Mandatory New Userdata Variables

      New Mandatory Userdata VariablesDescription/Required Action
      ClusterIpProvide Ha0 IP address of the peer instance. The value should be same as that of the value for the variable PeerCEHa0IPv4Address.
      ActiveRoleMgtIdProvide eth0 interface ID of the instance having assigned role (CERole) as  ACTIVE. For standalone upgrade, this variable should have eth0 interface ID of the sole instance.
      Note: The value of this variable will also be the default password for the upgraded instance when you log on as admin. You must change when prompted by the SBC.
      SbcMgmtModeThe management mode of the instances constituting a 1:1 HA pair. For AWS, the default value (and the only supported value)  is centralized.
      Note: This user data should only be passed for an HA pair and is not applicable for a standalone instance.

      Warning
      Changing ClusterIp in userdata and subsequent rebooting of the instance does not work if wrong ClusterIp is provided in the userdata.
      If you provide wrong ClusterIp, detach the volumes with wrong ClusterIp, create two new fresh volumes (active and standby, or one volume for standalone scenario) and provide correct ClusterIp, and then attach them. Rebooting after this procedure does not cause any problem.

      Optional New Userdata Variables

      New Optional Userdata VariablesDescription/Required Action
      SbcPersonalityTypeThe personality type of the SBC instance (default = isbc).
      TemplateNameName of the template (<file_name>.json) used for configuration.
      TemplateVersionVersion of the template used for configuration.

  7. Start the upgraded instances.

  8. Log on to the CLI of the upgraded instance as linuxadmin, ssh to root, and perform the following steps:
    1. Check for the persistence of the UUID of the instance. On successful upgrade, it must remain same.

      Before Upgrade:

      After Upgrade:

      # dmidecode -t 1

      # dmidecode 2.11 SMBIOS 2.4 present. Handle 0x0100, DMI type 1, 27 bytes System Information Manufacturer: Xen Product Name: HVM domU Version: 4.2.amazon Serial Number: ec2f0c2d-XXXX-cece-ad6e-1c52309ecf6b UUID: EC2F0C2D-XXXX-CECE-AD6E-1C52309ECF6B Wake-up Type: Power Switch SKU Number: Not Specified Family: Not Specified
      # dmidecode -t 1

      # dmidecode 2.11 SMBIOS 2.4 present. Handle 0x0100, DMI type 1, 27 bytes System Information Manufacturer: Xen Product Name: HVM domU Version: 4.2.amazon Serial Number: ec2f0c2d-XXXX-cece-ad6e-1c52309ecf6b UUID: EC2F0C2D-82E9XXXX-CECE-AD6E-1C52309ECF6B Wake-up Type: Power Switch SKU Number: Not Specified Family: Not Specified
    2. Check for the correctness of the upgrade by executing the following command:

      Before Upgrade:

      After Upgrade:

      # swinfo

      ===================================================
      SERVER:        vsbc1
      OS:            V03.01.00-Sxxx
      SonusDB:       V05.01.00-Sxxx
      EMA:           V05.01.00-Sxxx
      SBC:           V05.01.00-Sxxx
      SBC Type:      isbc
      ===================================================
      Installed host role:   active
      Current   host role:   active

      # swinfo

      ===================================================
      SERVER:        vsbc1
      OS:            V05.01.00-xxx
      SonusDB:       V06.02.01-xxx
      EMA:           V06.02.01-xxx
      SBC:           V06.02.01-xxx
      SBC Type:      isbc
      ===================================================
      Installed host role:   active
      Current   host role:   active
      Note

      On successful upgrade, the values for the fields OS, SonusDB, EMA, and SBC must change to reflect the  6.2.1 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. For information on how to view the userdata, see Step 6 - View/Change User Data.

      Before Upgrade:

      After Upgrade:

      {

          "ALT_Mgt0_00": "LOGICAL_MGMT_IP",

          "ALT_Pkt0_00": "VIP1",

          "ALT_Pkt1_00": "VIP2",

          "CEName": "vsbc2",

          "CERole": "STANDBY",

          "NodeName": "Vol",

          "PeerCEHa0IPv4Address": "172.31.11.44",

          "PeerCEName": "vsbc1",

          "ReverseNatPkt0": "True",

          "ReverseNatPkt1": "True",

          "SystemName": "vsbcSystem"

      }

      {

          "ALT_Mgt0_00": "LOGICAL_MGMT_IP",

          "ALT_Pkt0_00": "VIP1",

          "ALT_Pkt1_00": "VIP2",

          "CEName": "vsbc2",

          "CERole": "STANDBY",

          "NodeName": "Vol",

          "PeerCEHa0IPv4Address": "172.31.11.44",

          "PeerCEName": "vsbc1",

          "ReverseNatPkt0": "True",

          "ReverseNatPkt1": "True",

          "SystemName": "vsbcSystem",

          "ClusterIp": "172.31.11.44",                               

          "ActiveRoleMgtId": "eni-46bdfdbf",                          

          "SbcMgmtMode": "centralized",                               

          "SbcPersonalityType": "isbc",                               

          "TemplateName": "AWS_HA_template.json",                     

          "TemplateVersion": "V06.02.01R000"                          

      }

  9. Log on to the SBC Configuration Manager/EMA and reapply the same licenses used for the 5.1.0Sxxx instances. For more information, refer to License Management - Legacy License Settings.
  10. Log on to the CLI of the upgraded instance as linuxadmin, ssh to admin (see Default Password), and check whether the licenses are correctly re-applied by using the following command:

    Before Upgrade:

    After Upgrade:

    > show table system licenseInfo
    LICENSE EXPIRATION USAGE IN FEATURE NAME ID DATE LIMIT SOURCE USE -------------------------------------------------------------- SRTP 3772 2020-12-31-05:00 1 Legacy 0 ENCRYPT 3772 2020-12-31-05:00 1000 Legacy 0 SBC-RTU 3772 2020-12-31-05:00 150000 Legacy 0 DSP-EVRC 3772 2020-12-31-05:00 1 Legacy 0 DSP-G722 3772 2020-12-31-05:00 1 Legacy 0 POL-BASE 0000 1 BuiltIn 0 SBC-MSRP 3772 2020-12-31-05:00 1 Legacy 0 VDSP-RTU 3772 2020-12-31-05:00 1000 Legacy 0 DSP-AMRNB 3772 2020-12-31-05:00 1 Legacy 0 DSP-AMRWB 3772 2020-12-31-05:00 1 Legacy 0 SBC-SIP-I 3772 2020-12-31-05:00 1 Legacy 0 SBC-VIDEO 3772 2020-12-31-05:00 1 Legacy 0 SBC-4X1GMP 3772 2020-12-31-05:00 1 Legacy 0 SBC-SIP323 3772 2020-12-31-05:00 1 Legacy 0 SBC-SIPREC 3772 2020-12-31-05:00 1 Legacy 0 SBC-1X10GMP 3772 2020-12-31-05:00 1 Legacy 0 SBC-POL-RTU 3772 2020-12-31-05:00 1000 Legacy 0 SBC-POL-E911 3772 2020-12-31-05:00 1 Legacy 0 SBC-POL-ENUM 3772 2020-12-31-05:00 1 Legacy 0 SWE-INSTANCE 3772 2020-12-31-05:00 1 Legacy 0
    > show table system licenseInfo
    LICENSE EXPIRATION USAGE IN FEATURE NAME ID DATE LIMIT SOURCE USE -------------------------------------------------------------- SRTP 3772 2020-12-31-05:00 1 Legacy 0 ENCRYPT 3772 2020-12-31-05:00 1000 Legacy 0 SBC-RTU 3772 2020-12-31-05:00 150000 Legacy 0 DSP-EVRC 3772 2020-12-31-05:00 1 Legacy 0 DSP-G722 3772 2020-12-31-05:00 1 Legacy 0 POL-BASE 0000 1 BuiltIn 0 SBC-MSRP 3772 2020-12-31-05:00 1 Legacy 0 VDSP-RTU 3772 2020-12-31-05:00 1000 Legacy 0 DSP-AMRNB 3772 2020-12-31-05:00 1 Legacy 0 DSP-AMRWB 3772 2020-12-31-05:00 1 Legacy 0 SBC-SIP-I 3772 2020-12-31-05:00 1 Legacy 0 SBC-VIDEO 3772 2020-12-31-05:00 1 Legacy 0 SBC-4X1GMP 3772 2020-12-31-05:00 1 Legacy 0 SBC-SIP323 3772 2020-12-31-05:00 1 Legacy 0 SBC-SIPREC 3772 2020-12-31-05:00 1 Legacy 0 SBC-1X10GMP 3772 2020-12-31-05:00 1 Legacy 0 SBC-POL-RTU 3772 2020-12-31-05:00 1000 Legacy 0 SBC-POL-E911 3772 2020-12-31-05:00 1 Legacy 0 SBC-POL-ENUM 3772 2020-12-31-05:00 1 Legacy 0 SWE-INSTANCE 3772 2020-12-31-05:00 1 Legacy 0

    Note

    The value of the ActiveRoleMgtId userdata variable is the default password for the upgraded instance when you log on as admin. You must change when prompted by the SBC.