In this section:

Customer Method to Install Life Cycle Manager 

The Ribbon Life Cycle Manager (LCM) provides standalone SBC upgrades in GCP. Once the LCM Image is launched, files gcp_access.yml and upgrade-revert.yml templates (needed for upgrade) are located in the user-specified path.

Example:  /home/ubuntu-user/10.0/iac-270/management/SBC/upgrade directory.

Prerequisite

Steps

  1. Launch a n1-standard-1 instance with LCM Image

  2. Once successfully instantiated, log into the instance as ubuntu-user and switch to root:

    ssh -i lcm.pem ubuntu-user@<LCM instance IP address>
sudo su -

  3. Create a directory within /home/ubuntu-user/ using the command:

    mkdir /home/ubuntu-user/iac-270
  4. Copy the LCM tarball "iac_sustaining_21.06_b270.tar.gz" to /home/ubuntu-user/iac-270.

  5. Untar the tarball inside /home/ubuntu-user/iac-270 using the command: 

    tar -xzvf iac_sustaining_21.06_b270.tar.gz
  6. Change to the /home/ubuntu-user/iac-270 directory and view the README file for any updated instructions.

  7.  Install python-pip package using method appropriate for OS - see examples:

    1. Amazon Linux 2 Image (HVM), SSD Volume Type (x86_64): amazon-linux-extras install epel; yum install -y python-pip
    2. CentOS7 : yum install -y epel-release; yum install -y python2-pip
    3. RHEL7: yum install -y python2-pip
    4. Debian9/Ubuntu18: apt-get install python-pip
  8. 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
  9. Activate the python virtualenv with command "python -m virtualenv rafenv"

  10. Run the IAC activate script  using command:

    sudo source /home/ubuntu-user/iac-270/rafenv/bin/activate


  11. Complete the LCM instance setup by running the command: 
    /setup.py
  12. Change directory to /home/ubuntu-user/iac-270/management/SBC/upgrade.
  13. List the contents of the directory.
  14. Ensure the following files are present:
    1. upgrade.py
    2. gcp_access.yml
    3. upgrade-revert.yml


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 /var/log/ribbon which is required for future reversions and debugging.

Customer Methods for Upgrading and Reverting

Prerequisites

  • The new SBC and LCM Image must be uploaded and available in GCP.
  • You must have an GCP Instance (n1-standard-1) with installed Life Cycle Manager (LCM) Image. (The default gcp_access.yml, upgrade-revert.yml, will be present in the /home/ubuntu-user/iac-270/management/SBC/upgrade/ directory of the LCM instance.)


  • Make sure that the SBC instances' security group setting allow the LCM instances to reach the SBC instances' mgmt IP on ports 22, 443 and 444 for ssh, sftp and http services.
  • The LCM instance must have enough privileges to access Image, start/stop instances, make volume, attach, detach volume, show, start, stop, reboot and update instances.


Steps

  1. Open a session to the Life Cycle Manager instance (LCM) and switch to root.
  2. Enter the LCM virtual environment using command "source rafenv/bin/activate".

  3. Change to /home/ubuntu-user/iac-270/management/SBC/upgrade and enter the workflow directory:

    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

  4. Edit the file /home/ubuntu-user/iac-270/management/SBC/upgrade/gcp_access.yml to provide GCP access details and HA pairing information. This information is used for mapping HA pairs. An example of a completed gcp_access.yml file is shown below.

    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.

    gcp_access.yml
    ########################################################################
# This file has 2 blocks of information:
#   1) GCP access details
#   2) SBC Instance/group details
# Update this file as per the directions provided at respective fields
########################################################################
#
# Update GCP region and zone
#
provider: "gcp"
region: "us-central1"
zone: "us-central1-a"
 
#
# Update GCP access and security keys
#
access_data:
      gcp_auth_kind: "serviceaccount"
      gcp_service_account_file: "/home/ubuntu-user/account.json"
      gcp_project: "sonus-svt-gc-poc"
# Update SBC instance's CLI login details, user must be Administrator group, e.g. default user 'admin'
#
login_details:
      username: "admin"
      password: "Sonus@123"
 
#
# Update redundancy group details, in case of active/standby (1:1) configuration,
# provide details of both the instances. Order doesn't matter.
# If username and password are same for all the instances and same as in "login_details" above,
# can remove those lines, e.g. a simpler version looks like this:
#      instance1:
#            instance_id: i-my-instance-id-1
#            instance_ip: 1.2.3.4
#
# 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: "1496492748014486928"
            instance_ip: "35.202.116.196"
                          login_details:
                              username: "admin"
                 password: "myAdminPassword"
                  instance2:
                        instance_id: "i-my-instance-id-2"
                        instance_ip: "1.2.3.5"
                        login_details:
                              username: "admin"
                 password: "myAdminPassword"

Upgrading


  1. Edit the file /home/ubuntu-user/iac-270/management/SBC/upgrade/upgrade-revert.yml to provide Image ID, Upgrade Tag and order of instance upgrade to the new SBC version. The following example provides the  Image version to use for the upgrade and specifies to upgrade instance i-0987654321dcba and then instance i-0123456789abcd.

    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: "image_or_ami_use-for-upgrade"
#
# 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: "test1"
            instances:
                  - "i-instance-id-2"
                  - "i-instance-id-4"
      upgradeGroup2:
            tag: "test2"
            instances:
                  - "i-instance-id-1"
                  - "i-instance-id-3"

  2. From the LCM session /home/ubuntu-user/iac-270/management/SBC/upgrade, run the upgrade command with gcp_access.yml and upgrade-revert.yml as inputs:

    ./upgrade.py -a gcp_access.yml -u upgrade-revert.yml

    For an offline upgrade, use the command:  ./upgrade.py -a gcp_access.yml -u upgrade-revert.yml -o

    Upgrade progress and logs are shown on-screen and also logged in /home/ubuntu-user/9.2/iac-270/management/log/SBC/upgrade/gcp/latest.

  3. 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/gcp/history.

    Volumes with older software versions are left intact on GCP 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

  1. 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. 

    • 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 reverted to same SBC version, failure to maintain the same version within a group will cause unknown behavior and could cause a service outage.
    upgrade-revert.yml
    #
# Image/AMI id to use for upgrade
#
image_id: image_or_ami_use-for-upgrade
#
# 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.
#
upgrade_tag: RAF_UPGRADE_70S406_72S400_344
#
# 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 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
#
tasks:
      # Each upgrade group should have a list of instance that will be upgraded in parallel
      upgradeGroup1:
            tag: RAF_UPGRADE_ACTIVENEW-1
            instances:
                  - i-0987654321dcba
      upgradeGroup2:
            tag: RAF_UPGRADE_STDBYNEW-1
            instances:
                  - i-0123456789abcd

  2. From the LCM session //home/ubuntu-user/iac-270/management/SBC/upgrade/, run the revert command with gcp_access.yml and upgrade-revert.yml as inputs:

     ./revert.py -a gcp_access.yml -u upgrade-revert.yml

    Reversion progress and logs are shown on-screen and also logged in /home/ubuntu-user/9.2/iac-270/management/log/SBC/revert/gcp/latest.

  3. After successfully reverting all nodes listed in upgrade-revert.yml, timestamped logs are moved to /home/ubuntu-user/9.2/iac-270/management/log/SBC/revert/gcp/history.

    Volumes with older software versions are left intact on GCP 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.

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.