Page History
Add_workflow_for_techpubs | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Panel | ||||
---|---|---|---|---|
In this section:
|
Info | ||
---|---|---|
| ||
Related articles:
|
Procedure
Perform the following steps to upgrade the SBC SWE on Azure using IaC. The Azure CLI version used for this documentation is 2.24.
- Create an Ubuntu 18.04 LTS instance in Azure.
Create Network Security Group rules to allow the instance to allow SSH access to SBC MGT IP on ports 22, 2024, 444, and 443. Refer to Create Network Security Group.
Info title Note If the NIC for the IaC instance was created in the same subnet as the SBC MGT, this step is not needed.
Run az login and sign in as a user with the role 'owner' for the subscription.
If not yet created, create a Service Principal that contains 'owner' permissions for the subscription. For example:
Code Block az ad sp create-for-rbac -n rbbn-iac --role="owner" --scopes="/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXa511"
Export the following values from the Service Principal:
Code Block export ARM_SUBSCRIPTION_ID="<subscription_id>" export ARM_TENANT_ID="<tenant_id>" export ARM_CLIENT_ID="<client_id>" export ARM_CLIENT_SECRET="<client_secret>"
Info title Note You can add this values to the file and source it before running the upgrade command.
Customer Method to Install Life Cycle Manager
The Ribbon Life Cycle Manager (LCM) provides SBC upgrades in Azure. Once the LCM Image is
Customer Method to Install Life Cycle Manager
The Ribbon Life Cycle Manager (LCM) provides SBC upgrades in Azure. Once the LCM Image is launched, files azure_access.yml
and upgrade-revert.yml
templates (needed for upgrade) are located in the user-specified path.
Example: /home/ubuntu-user/
10.0xx/iac
-270/management/SBC/upgrade
.
Here 'xx
' refers to the folder name.
Prerequisite
- Determine a Ubuntu Image to use for the LCM using the procedure in Locate Locate Ubuntu Image ID for use Use in LCM deployments.
- Retrieve the RBBN LCM scripts from the Ribbon Support Portal.Support Portal.
- The minimum supported version is iac_sustaining_22.05_b296.tar.gz
Steps
- Launch a
standard F4s
instance instance with LCM Image. Once successfully instantiated, log into the instance as ubuntu-user and switch to
root
:Code Block ssh -i lcm.pem ubuntu-user@<LCM instance IP address> sudo su -
Create a directory within
/home/ubuntu-user/
using the command:Code Block mkdir /home/ubuntu-user/iac-270
- Copy the latest LCM tarball "iac_sustaining_21.05_b270.tar.g" to IAC package from Salesforce to
/home/ubuntu-user/iac-270
. Untar the tarball inside
/home/ubuntu-user/iac-270
using the command:Code Block tar -xzvf iacxzvf iac_sustaining_21*.05_b270.tar.ggz
- Change to the
/home/ubuntu-user/iac-270
directory and view the README file for any updated instructions. Install pythonpython2-pip package using method appropriate for OS - see examples:
- Redhat:
yum install -y python2-pip
- Amzn2 AMIAmazon Ubuntu 2 Image (HVM), SSD Volume Type (x86_64):
amazon-Ubuntulinux-extras install epel; yum install -y python2-pip
- Centos
: curl 'https://bootstrap.pypa.io/pip/2.7/get-pip.py' -o 'get-pip.py'; python get-pip.py
CentOS7 : yum install -y epel-release; yum install -y python2-pip
RHEL7: yum install -y python2-pip
Debian/Ubuntu:
apt-get update; apt-get install python-pip
Warning The Ribbon LCM package requires python2 and python2-pip to run. The examples above show the linux distributions version that support python2. In newer versions; the python2 package is not avaiable from the standard package repositories and instead will need to be installed from a different source.
Debian9/Ubuntu18: apt-get install python-pip
- Redhat:
Install Python virtual environment
using command "pip install virtualenv".
Refer to: https://packaging.python.org/guides/installing-using-pip-and-virtualenv/ for additional info on pip virtualenv- Activate the python virtualenv with command "python -m virtualenv rafenv"
.
Code Block pip2 install virtualenv
Create virtual environment and provide a name e.g. 'iacenv'.
Code Block virtualenv -p /usr/bin/python2 iacenv
Activate virtual environment.
Code Block source iacenv
Run the RAF activate script using command:
Code Block sudo source /home/ubuntu-user/iac-270/rafenv/bin/activate
Complete
the LCM instance setup by running the command:the LCM setup by installing the required packages and setup the environment/
Code Block ./setup.py --azure
- Change directory to
/home/ubuntu-user/iac-270/management/SBC/upgrade
. - List the contents of the directory.
- Ensure the following files are present:
upgrade.py
azure_access.yml
upgrade-revert.yml
Info |
---|
It is safe to shut down the LCM instance after the process finishes. If you decide to terminate/remove the LCM instance, you must make a backup of |
Customer Methods for Upgrading and Reverting
Prerequisites
- A snapshot of the target SBC image in the same Resource Group as the SBC setup being upgraded
- See the following link to create a snapshot: Access and Share SBC Image in Azure.
- Copy the latest LCM tarball IAC package from Salesforce and upload to LCM instance and extractThe new SBC and LCM Image must be uploaded and available in Azure
- .
- You must have an Azure Instance (Standard F4s) with installed Life Cycle Manager (LCM) Image. (The default
azure_access.yml
,upgrade-revert.yml,
will be present in the/home/ubuntu-user/iac-270/management/SBC/upgrade/
directory directory of the LCM instance.)
Info |
---|
|
Steps
Open a session to the Life Cycle Manager instance (
LCM) and switch to root.LCM) and switch to root.
Code Block ssh -i lcm.pem ubuntu-user@<LCM instance IP address> sudo su
Activate virtual environment.
Enter the LCM virtual environment using command "source rafenvCode Block source iacenv
"./bin/activate
Change to
/home/ubuntu-user/iac-270/management/SBC/upgrade
and enter the workflow directory:Code Block ssh -i lcm.pem ubuntu-user@<LCM instance IP address> sudo su - source rafenv/bin/activate cd /home/ubuntu-user/iac-270/management/SBC/upgrade
Edit the file
/home/ubuntu-user/iac
-270/management/SBC/upgrade/azure_access.yml
to provide Azure access details and HA pairing information. This information is used for mapping HA pairs. An example of a completedazure
_access.yml
file is shown below.Info title Note Use either the private managment IP address or the elastic IP address of instance1/instance2. Whichever you chose, ensure the IP address is reachable from the RAF/ LCM server to the SBC SWe.
Code Block title azure_access.yml ######################################################################## # This file has 2 blocks of information: # 1) Azure general resources details # 2) SBC Instance/group details # Update this file as per the directions provided at respective fields ######################################################################## ############################################################################# # Azure authentication details should be supplied via azure CLI login: # - For service principal: az login --service-principal -u '<clientId>' -p '<clientSecret>' --tenant '<tenantId>' # - For Azure Active Directory: az login ############################################################################## provider: "azure" # # Update subscription, resource group, location # subscription_id: "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXX8b96" resource_group: "SBC-Core-RG" location: "East US" availability_zone: 0 # # Update redundancy group details, in case of active/standby (1:1) configuration, # provide details of both the instances. Order doesn't matter. # # Note: The script is limited to support just 1 redundancy group. Please dont add other redundancy group to this file else it will fail. redundancy_group1: instance1: instance_id: "ap-sbc02-active" instance_ip: "20.75.155.181" login_details: username: "admin" password: "Sonus@123" linuxadmin_key_file: "/home/rbbntest/Mahesh-Key.pem" instance2: instance_id: "ap-sbc02-standby" instance_ip: "20.75.155.206" login_details: username: "admin" password: "Sonus@123" linuxadmin_key_file: "/home/rbbntest/Mahesh-Key.pem"
Upgrading
Edit the file
/home/ubuntu-user/iac-270/management/SBC/upgrade/upgrade-revert.yml
to to provide Image ID, Upgrade Tag and order of instance upgrade to the new SBC version. The following example provides the the Image version to use for the upgrade and specifies to upgrade instance instanceap-sbc02-active
and thenap-sbc02-standby
.Code Block title upgrade-revert.yml ####################################################################### # This file defines which instances to upgrade and in which order # Update this file as per the directions provided at respective fields ######################################################################## # # image_id - new image to use for upgrade. Use it as follows for different providers: # aws - AMI id with new SBC image # gcp - Name of the new SBC image # openstack - image id with new SBC image # vmware - Absolute path to vmdk with new SBC image # rhv/kvm - Absolute path to qcow2 image # azure - Snapshot name # image_id: "release-sbc-v10-00-00r000-05-19-21-22-06.snap" # # A tag to uniquely identify this upgrade. Logs and directory structure of logs are tagged # with these so that future reference to these will be easier with appropriate tag. # When the same system goes through multiple upgrades, this becomes a very handy way to jump to right set of logs. # # If multiple upgrades are done by using same upgrade-revert.yml file, use different upgrade_tag each time. Refer # the corresponding upgrade_tag while doing the revert. upgrade_tag: "IAC_TEST" # Order of upgrade: # All the instances listed under one group gets upgraded in parallel, so they get stopped, rebuilt and started in parallel. # # WARNING: If both active and standby of a HA pair are listed in the same upgrade group, that will impact service. # # On successful upgrade of instances in one group, instances in next group will be picked. # Example Usecases: # 1) While upgrading a 1:1(active/standby), list standby in first group and active in second group # 2) If want to upgrade just standby, list that in first group and remove group 2 # 3) While upgrading a standalone, list instance in first group and remove group 2 # tasks: # Each upgrade group should have a list of instance that will be upgraded in parallel upgradeGroup1: tag: "standby" instances: - "ap-sbc02-standby" upgradeGroup2: tag: "active" instances: - "ap-sbc02-active"
From the LCM session
/home/ubuntu-user/iac
-270/management/SBC/upgrade
, run the upgrade command with azure_access.yml and upgrade-revert.yml as inputs:Code Block ./upgrade.py -a azure_access.yml -u upgrade-revert.yml
Info title Note For an offline upgrade, use the command:
./upgrade.py -a azure_access.yml -u upgrade-revert.yml -o
Info title Note Upgrade progress and logs are shown on-screen and also logged in
/home/ubuntu-user/9.2/iac-270/management/log/SBC/upgrade/azure/latest
.
After successfully upgrading all nodes listed in
upgrade-revert.yml
, timestamped logs are moved to/home/ubuntu-user/9.2/iac
-270/management/log/SBC/upgrade/azure/history
.Info title Note Volumes with older software versions are left intact on Azure in case they are needed for future reversions. Information about these volumes is stored in the file with instance-id as part of its name. Do not delete these older volumes – you must have these volumes in order to perform a reversion.
Reverting
Edit the file
/home/ubuntu-user/iac-270/management/SBC/upgrade/upgrade-revert.yml
by designating the instances to revert. The following example provides a list of instances.Infonote - The reversion process runs in parallel on all the instances, and could impact service.
- Make sure that all the instances of a redundancy group get are reverted to the same SBC version, failure . Failure to maintain the same version within a group will cause unknown behavior and could cause a service outage.
Code Block title upgrade-revert.yml ####################################################################### # This file defines which instances to upgrade and in which order # Update this file as per the directions provided at respective fields ######################################################################## # # image_id - new image to use for upgrade. Use it as follows for different providers: # aws - AMI id with new SBC image # gcp - Name of the new SBC image # openstack - image id with new SBC image # vmware - Absolute path to vmdk with new SBC image # rhv/kvm - Absolute path to qcow2 image # azure - Snapshot name # image_id: "release-sbc-v10-00-00r000-05-19-21-22-06.snap" # # A tag to uniquely identify this upgrade. Logs and directory structure of logs are tagged # with these so that future reference to these will be easier with appropriate tag. # When the same system goes through multiple upgrades, this becomes a very handy way to jump to right set of logs. # # If multiple upgrades are done by using same upgrade-revert.yml file, use different upgrade_tag each time. Refer # the corresponding upgrade_tag while doing the revert. upgrade_tag: "IAC_TEST" # Order of upgrade: # All the instances listed under one group gets upgraded in parallel, so they get stopped, rebuilt and started in parallel. # # WARNING: If both active and standby of a HA pair are listed in the same upgrade group, that will impact service. # # On successful upgrade of instances in one group, instances in next group will be picked. # Example Usecases: # 1) While upgrading a 1:1(active/standby), list standby in first group and active in second group # 2) If want to upgrade just standby, list that in first group and remove group 2 # 3) While upgrading a standalone, list instance in first group and remove group 2 # tasks: # Each upgrade group should have a list of instance that will be upgraded in parallel upgradeGroup1: tag: "standby" instances: - "ap-sbc02-standby" upgradeGroup2: tag: "active" instances: - "ap-sbc02-active"
From the LCM session
/
/home/ubuntu-user/iac
-270/management/SBC/upgrade/
, run the revert command with azure_access.yml and upgrade-revert.yml as inputs:Code Block ./revert.py -a azure_access.yml -u upgrade-revert.yml
Info title Note Reversion progress and logs are shown on-screen and also logged in
/home/ubuntu-user/9.2/iac-270/management/log/SBC/revert/azure/latest.
After successfully reverting all nodes listed in upgrade-revert.yml, the timestamped logs are moved to to
/home/ubuntu-user/9.2/iac
-270/management/log/SBC/revert/azure/history
.
Info title Note Volumes with older software versions are left intact on Azure in case they are needed for future reversions. Information about these volumes is stored in the file with instance-id as part of its name. Do not delete these older volumes – you must have these volumes in order to perform a reversion.