In this section:
Related articles:
Modified: for 6.2.1
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.
The steps to perform a volume-based upgrade from 5.1.0Sxxx to 6.2.1 are:
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.
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.
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.
Ensure that the new volumes are created in the same "Availability zone" as that of the running 5.1.0Sxxx instance.
Shutdown the 5.1.0Sxxx instance (both active and standby volumes).
Volume-based upgrade is applicable only for offline upgrade. All participating HA pair instances should be turned off during the upgrade.
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.
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.
The new volumes must be associated as root volumes (device name: /dev/sda1
) to the corresponding instances.
Do not start the instance immediately after attaching the new volumes. You must execute the next steps.
Select the instance, right click and navigate to Instance Settings > View/Change User Data.
Modify the userdata and click Save.
Userdata template for 6.2.1 ACTIVE: | Userdata template for 6.2.1 STANDBY: |
---|---|
|
|
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:
ClusterIp
in userdata and subsequent rebooting of the instance does not work if wrong ClusterIp
is provided in the userdata.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.Start the upgraded instances.
linuxadmin
, ssh to root,
and perform the following steps: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 -t 1 |
Check for the correctness of the upgrade by executing the following command:
Before Upgrade: | After Upgrade: |
---|---|
=================================================== 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 |
=================================================== 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 |
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
.
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: |
---|---|
|
|
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 | > show table system licenseInfo |
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.