10. Software Upgrade

10.1. Release Notes
10.2. Overview
10.3. Planning a Software Upgrade
10.4. Preparing for a Software Upgrade
10.4.1. Log into the inactive management server (web01a/db01a).
10.4.2. Log into all servers.
10.5. Upgrade sip:carrier from previous mr4.4/mr4.5 versions to mr4.5.6 LTS version
10.5.1. Upgrading the first inactive management node "A" ONLY (web01a/db01a)
10.5.2. Upgrading inactive database node "A" (db*a)
10.5.3. Upgrading other inactive nodes "A" (lb*a/prx*a)
10.5.4. Promote ALL inactive nodes "A" to active.
10.5.5. Upgrading ALL inactive nodes "B" (web*b/db*b/lb*b/prx*b)
10.6. Post-upgrade Checks
10.7. Upgrade sip:carrier from previous mr3.8 LTS version to mr4.5.6 LTS version

10.1. Release Notes

The sip:carrier version mr4.5.6 has several important changes comparing to the previous release. Please find the complete changelog in our release notes on our WEB site.

10.2. Overview

The sip:carrier system upgrade to mr4.5.6 will perform a couple of fundamental steps:

  • Upgrade NGCP software packages
  • Upgrade NGCP configuration templates
  • Upgrade NGCP DB schema
  • Upgrade the base system within Debian (v8) to the latest package versions

sip:carrier is a PRO-style system which has "A" and "B" pairs of nodes which execute specific roles. The nodes amount here is different and must be clarified ahead of the upgrade on the planning stage.

The way to upgrade sip:carrier is clean and simple:

  • upgrade planning
  • pre-upgrade steps: customtt, backups
  • ensure all nodes "B" are active
  • ensure all nodes "A" are inactive
  • upgrade all nodes "A" first to the new release
  • schedule and perform a switchover to all nodes "A"
  • ensure nodes "A" work well (otherwise switchover back to nodes "B")
  • upgrade all nodes "B" to the new release
  • perform system post-upgrade testing/cleanup
[Warning]

the only allowed way to upgrade sip:carrier is described above. All the other theoretically possible upgrade scenarios can lead to unpredictable results.

[Warning]

Nodes "A" and "B" MUST be used as described in this document. It is NOT allowed to swipe them unless proxy replication (of MySQL on port 3308) is configured on the db01b node.

10.3. Planning a Software Upgrade

Have a written answer on the following questions:

  • which system should be upgraded (ensure about LAB/LIVE, country, etc.)
  • clarify upgrade date and time (ensure timezone) for each stage above
  • clarify allowed timeframe for the upgrade (allowed switchover timeframe)
  • what should happen if upgrade does not fit allowed timeframe
  • request the customer availability on all switchover stages
  • gather urgent contact credentials to contact the customer in case of emergency
  • force the customer to prepare basic and fast tests to be executed after switchovers to ensure new release works well
  • share with the customer the steps you are going to perform and request written confirmation
  • ensure that you and the customer have an access to the remote console of the servers: KVM, DRAC

10.4. Preparing for a Software Upgrade

10.4.1. Log into the inactive management server (web01a/db01a).

[Tip]

Use their real IP so you can switch the cluster forth and back later on.

Switch to the terminal multiplexer under the user sipwise (to reuse Sipwise .screenrc settings which are user-friendly for handling upgrade in multiple windows):

screen -S ngcp-upgrade

Become a root inside your screen session:

sudo -s

Check the system overall status:

ngcp-status --all

Ensure that all proxy nodes replicate read-only DB (MySQL on 127.0.0.1:3308) from the node db01a. Otherwise, inform your manager about the special state here.

Try to find local changes to the template files by issuing:

find /etc/ngcp-config -name \*customtt.tt2

You will also need to find the dpkg-dist files under the templates files because people sometimes forget about creating customtt files and edit tt2 files directly. That makes upgrades not to replace the tt2 files. If so, you need to treat the tt2 files as if they were customtt files and make sure you merge the new templates with the changes of the old ones.

find /etc/ngcp-config -name \*.tt2.dpkg-dist

Also, please check/clean old dpkg backup files (just in case if another engineer did the previous step not carefully enough).

Normally the list should be empty:

find /etc/ngcp-config -name \*.tt2.dpkg\*

You will have to understand why the changes are there and if they are still needed after the upgrade.

You must create a ticket in the bug tracker to include customtt changes in the following releases (to remove customtt one day).

[Warning]

Installation may use locally specified apt Debian mirrors. Discuss with a customer possibility to switch on Sipwise APT repositories (at least for the time of upgrades), the public Debian mirrors may not provide packages for old Releases anymore or be at least outdated!

10.4.2. Log into all servers.

Open separate windows for all the servers inside your screen session. (Press Ctrl+a + c to open new window, Ctrl+a+a or Ctrl+a + [0-9] to change the window. Ctrl+a + " can open list of all windows for you. C+a + A can be used to change the screen name, so you can mark hosts here).

Check the system for locally modified files (move them to appropriate customtt.tt2 files if necessary) on all servers:

ngcp-status --integrity

Make sure the cluster status is ok - on all nodes issue manually:

  • ngcpcfg status - should print OK all the times

Can be checked on all nodes in parallel, using clish and parallel-ssh:

  • ngcp-clish "ngcp version summary" - ensure all nodes have proper/expected from version across all cluster
  • ngcp-clish "ngcp version package installed ngcp-ngcp-carrier" - ensure the metapackages version is equal to the ngcp version above
  • ngcp-clish "ngcp version package check" - ensure all nodes have identical list of debian package installed.

    [Note]

    All nodes must be identical before and after the upgrade!

  • ngcp-clish "ngcp cluster ssh connectivity" - check SSH connectivity from the current node to all other nodes
  • ngcp-clish "ngcp cluster ssh crossconnectivity" - check SSH connectivity from the all nodes to all other nodes
  • ngcp-clish "ngcp monit summary" - ensure no errors are there
  • ngcp-clish "ngcp cluster status" - active nodes (with all services running) should print "all", the other "none"
  • ngcp-clish "ngcp status collective-check" - should not report any problems.
  • ngcp-clish "ngcp show date" - date and time must be in sync on all the servers
  • ngcp-clish "ngcp show dns-servers" - ensure DNS records are correct
[Note]

to exit from ngcp-clish press Ctrl+Z (or type exit):

root@web01b:~# ngcp-clish
Entering 'clish-enable' view (press Ctrl+Z to exit)...
# exit
root@web01b:~#

Run "apt-get update", ensure you have no warnings/errors here.

A cluster failover could be a good idea to see if everything works on the second node too. On the standby node issue:

/usr/share/heartbeat/hb_takeover

Afterwards, again check ngcp-status --all.

Create two test subscribers or retrieve the credentials for two of them. Register a client to the platform and perform a test call between the two to ensure call routing works.

10.5. Upgrade sip:carrier from previous mr4.4/mr4.5 versions to mr4.5.6 LTS version

[Warning]

ensure you have read and performed all the steps described in the section "Preparing for a Software Upgrade" above!

For upgrading the sip:carrier to mr4.5.6 release, execute the following commands on inactive management "A" node:

10.5.1. Upgrading the first inactive management node "A" ONLY (web01a/db01a)

[Note]

sometimes DB and MGMT roles are assigned to the same host. It is OK.

[Warning]

do NOT execute the current step on web01a and db01a in parallel!

The main goal here is to fill the approx cache with new version of packages. So all the other nodes will get identical version of packages as the first one.

NGCP_CURRENT_VERSION=$(cat /etc/ngcp_version)
sed -i "s/$NGCP_CURRENT_VERSION/mr4.5.6/" /etc/apt/sources.list.d/sipwise.list
ngcp-approx-cache-helper --auto --node localhost
apt-get update
apt-get install ngcp-upgrade-pro
[Note]

do NOT worry, ngcp-upgrade-carrier does not exist, use ngcp-upgrade-pro above.

Execute ngcp-upgrade in inactive node as root:

ngcp-upgrade
[Note]

sip:carrier can be upgraded to mr4.5.6 from previous release or previous build only. The script ngcp-upgrade will find all the possible target releases for the upgrade and allow to choose the proper one.

[Note]

If there is an error during upgrade, the ngcp-upgrade script will request you to solve it. Once you’ve fixed the problem just re-execute ngcp-upgrade again and it will continue from the previous step.

Merge/add the customtt configuration templates if needed. Apply the changes to configuration templates if any:

ngcpcfg apply 'applying customtt for new release mrX.X on node xxx01a'

Send new templates to the shared storage and the other nodes

ngcpcfg push --nobuild --noapply all
[Note]

do NOT execute ngcpcfg push --shared-only on this stage, it will affect further upgrades due to noticed outdated local ngcpcfg storage. If you did so, run ngcpcfg push --nobuild --noapply all once again to pull ngcpcfg changes on all the nodes from glustefs.

10.5.2. Upgrading inactive database node "A" (db*a)

[Note]

If DB and MGMT roles are assigned to the same host, skip this step as you have upgraded inactive MGMT node "A" above already.

Run the following commands to upgrade inactive DB node "A" (choose the same release version as above and follow on-screen recommendations):

NGCP_CURRENT_VERSION=$(cat /etc/ngcp_version)
sed -i "s/$NGCP_CURRENT_VERSION/mr4.5.6/" /etc/apt/sources.list.d/sipwise.list
apt-get update
apt-get install ngcp-upgrade-pro
ngcp-upgrade
[Note]

it is important to upgrade db01a node before upgrading any proxy nodes. Otherwise "local" MySQL (127.0.0.1:3308) on proxy nodes may be out of sync if new release has _not_replicated.up DB statements.

10.5.3. Upgrading other inactive nodes "A" (lb*a/prx*a)

Run the following commands here (choose the same release version and follow on-screen recommendations):

NGCP_CURRENT_VERSION=$(cat /etc/ngcp_version)
sed -i "s/$NGCP_CURRENT_VERSION/mr4.5.6/" /etc/apt/sources.list.d/sipwise.list
apt-get update
apt-get install ngcp-upgrade-pro
ngcp-upgrade

10.5.4. Promote ALL inactive nodes "A" to active.

[Warning]

ensure all inactive nodes "A" are:

  • upgraded to new release (check /etc/ngcp_version or use ngcp-clish)
  • have been reboot (run ngcp-status on each node)

Run on all "A" nodes:

/usr/share/heartbeat/hb_takeover

Ensure "A" node became active, feel free to reuse 'ngcp-status' and 'ngcp-clish' commands described above.

Ensure ALL "B" nodes are inactive now!

10.5.5. Upgrading ALL inactive nodes "B" (web*b/db*b/lb*b/prx*b)

Run the following commands here (choose the same release version and follow on-screen recommendations):

NGCP_CURRENT_VERSION=$(cat /etc/ngcp_version)
sed -i "s/$NGCP_CURRENT_VERSION/mr4.5.6/" /etc/apt/sources.list.d/sipwise.list
apt-get update
apt-get install ngcp-upgrade-pro
ngcp-upgrade
[Note]

you can upgrade all inactive "B" nodes together (including mgmt and db roles).

10.6. Post-upgrade Checks

When all finishes successfully check that replication is running. Check ngcp-status --all. Finally, do a basic functionality test. Check web interface, register two test subscribers and perform a test call between them to ensure call routing works.

[Note]

You can find a backup of some important configuration files of your existing installation under /var/backup/ngcp-mr4.5.6-* (where * is a place holder for a timestamp) in case you need to roll back something at any time. A log file of the upgrade procedure is available at /var/backup/ngcp-mr4.5.6-*/upgrade.log.

10.7. Upgrade sip:carrier from previous mr3.8 LTS version to mr4.5.6 LTS version

Please contact support@sipwise.com to schedule the upgrade.