13. Software Upgrade

13.1. Release Notes

The Sipwise C5 version mr6.4.2 has the following important changes:

  • Enable new customer self-care interface by default [TT#37657]
  • Implement topology hiding on load-balancer [TT#40617]
  • [PRO/Carrier] Enable licensing restrictions by default [TT#39650]
  • Add Sipwise C5 support for Hyper-V [TT#39302]
  • Install systemd dbus and libpam-systemd by default [TT#36228]
  • Add ngcp-service --group to act with group of services [TT#38753]
  • Manage /etc/hosts and /etc/network/interfaces via ngcpcfg tt2 templates [TT#36756]
  • Optimize performance for billing customers, contracts, subscribers, billing_profiles, fraud checks and callrating on large data sets [TT#23701]
  • Remove restrictions for switching billing profiles from postpaid to prepaid and vice versa [TT#40512]
  • Improve libinewrate logging for scenarios with inactive external subscribers [TT#39358]
  • [PRO/Carrier] Fix Panasonic RPS provisioning [TT#39605]
  • [PRO/Carrier] Enhance LNPD and add support for Furnished Charging Info in TCAP [TT#38156]
  • Export Furnished Charging Info data and P-Asserted-Identity headers into CDRs [TT#38155]
  • Introduce new Call Forwardings type "Rerouting" [TT#14596]
  • Support B-number regex matching in Call Forwards [TT#14600]
  • Add outbound socket lb_set support for permanent registration entries [TT#37459]
  • Introduce new clip_no_screening and pai_clir subscriber preferences [TT#40081]

Please find the complete changelog in our release notes on our WEB site.

13.2. Overview

The Sipwise C5 software upgrade procedure to mr6.4.2 will perform several fundamental tasks:

  • upgrade the NGCP software packages
  • upgrade the NGCP configuration templates
  • upgrade the NGCP DB schema
  • upgrade the NGCP configuration schema
  • upgrade the base system within Debian 9 (stretch) to the latest package versions

The software upgrade is usually performed by Sipwise engineers according to the following steps:

  • create the software upgrade plan
  • execute pre-upgrade steps: customtt, backups
  • make the sp2 node active
  • ensure that the sp1 node is standby
  • perform the software upgrade on the sp1 node
  • schedule and make services switchover to the sp1 node
  • ensure that the sp1 node performs well (otherwise, perform a switch back)
  • perform the software upgrade on the sp2 node
  • perform the system post-upgrade testing and cleanup
warning

The only allowed software upgrade path is the one described above. All the other theoretically possible upgrade scenarios can lead to unpredictable results.

13.3. Planning a software upgrade

Confirm the following information:

  • which system should be upgraded (LAB/LIVE, country, etc.)
  • the date and time schedule for each of the steps above (keeping the time zone in mind)
  • a confirmed timeframe for the upgrade operation (allowed switchover timeframe)
  • the basic functionality test (BFT) to be executed before the start of the software upgrade and after the switchovers to ensure that the new release does not show critical issues (the BFT scenario should be prepared by the customer engineers)
  • actions to be taken if the software upgrade operation cannot be completed within the defined maintenance window
  • contact persons and ways of communication in case of emergency
  • ensure that the customer and/or Sipwise engineers have access to the virtual consoles of the servers: KVM, iDRAC, AMM

13.4. Preparing the software upgrade

warning

Make sure that all the SIP domains and peering servers have the appropriate rtp_interface option (e.g. ext) selected in the NAT and Media Flow Control section. If you leave default there, the incorrect network interface may be used for sending and receiving RTP traffic after the software upgrade.

It is recommended to execute the preparatory steps in this chapter a few days before the actual software upgrade. They do not cause a service downtime, so it is safe to execute them during peak hours.

13.4.1. Log into the C5 standby node

tip

Use the static server IP address so you can switch between the nodes.

Run the terminal multiplexer under the sipwise user (to reuse the Sipwise .screenrc settings that are convenient for working in multiple windows):

screen -S ngcp-pre-upgrade-checks

Become root inside your screen session:

sudo -s

Check the overall system status:

ngcp-status --all

Make sure that the cluster health status is OK: Check the nodes in parallel, using the clish command:

  • ngcp-clish "ngcp version summary" - ensure that all cluster nodes have correct/expected from version
  • ngcp-clish "ngcp version package installed ngcp-ngcp-pro" - ensur that the metapackages version is equal to the ngcp version above
  • ngcp-clish "ngcp version package check" - ensure that all nodes have the identical Debian package installed
info

Software must be identical on all nodes (before and after the upgrade!)

  • ngcp-clish "ngcp cluster ssh connectivity" - check SSH connectivity from the current node to the peer
  • ngcp-clish "ngcp cluster ssh crossconnectivity" - check SSH cross-connectivity
  • ngcp-clish "ngcp monit summary" - all required services must be running on corresponding nodes
  • ngcp-clish "ngcp cluster status" - active node(s) (with all services running) must print "all", the other(s) must print "none"
  • ngcp-clish "ngcp status collective-check" - all checks must be OK
  • ngcp-clish "ngcp show date" - date and time must be in sync on all the servers
  • ngcp-clish "ngcp show dns-servers" - ensure that the DNS configuration is consistent among the nodes
info

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

# ngcp-clish
Entering 'clish-enable' view (press Ctrl+Z to exit)...
# exit
#

For the below steps, investigate and make sure you understand why the custom modifications were introduced and if they are still required after the software upgrade. If the custom modifications are not required anymore, remove them (e.g. if a bug was fixed in the target release and the existing patch becomes irrelevant).

Create tickets to Sipwise developers to make relevant custom modifications part of the product in future releases. This allows you to get rid of the customtt files one day.

warning

If you directly change the working configuration (e.g. add custom templates or change the existing ones) for some reason, then the system must be thoroughly tested after these changes have been applied. Continue with the software upgrade preparation only if the results of the tests are acceptable.

Find the local changes to the template files:

ngcp-customtt-diff-helper

The script will also ask you if you would like to download the templates for your target release. To download the new templates separately, execute:

ngcp-customtt-diff-helper -d

In the tmp folder provided by the script, you can merge the current customtt with the new tt2 templates, creating the new customtt.tt2 files. Once this is done, archive the new customtt files to deploy the new templates after the software upgrade:

ngcp-customtt-diff-helper -t

Find all available script options with the "-h" parameter.

Check if there are any *.tt2.dpkg-dist files among the templates. They usually appear when tt2 files are modified directly instead of creating customtt files. If you find any *.tt2.dpkg-dist files, treat the corresponding tt2 files as if they were customtt.tt2 and introduce the changes from the existing tt2 files into the new templates (create associated *.customtt.tt2) before the software upgrade.

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

Note that in the end all *.tt2.dpkg-dist files must be removed before the software upgrade as they prevent the upgrade script from updating the tt2 files.

Check and remove dpkg files left from previous software upgrades.

Make sure that the list is empty before you continue:

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

Log into all the servers.

Open separate windows for all the servers inside your "screen" session. (Press Ctrl+a + c to open a new window, Ctrl+a + a or Ctrl+a + [0-9] to change the window. Ctrl+a + " shows the list of all your windows. Use Ctrl+a + A to change the window names to corresponding hosts).

Changes made directly in tt2 templates will be lost after the software upgrade. Only custom changes made in customtt.tt2 files will be kept. Hence, check the system for locally modified tt2 files on all nodes:

ngcp-status --integrity

Check the configuration framework status on all nodes. All checks must show the "OK" result and there must be no actions required:

ngcpcfg status

Check the replication on both nodes. The result must always show:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0

Test the cluster failover to see if everything works fine on the second node as well. On the standby node execute:

ngcp-make-active

Create two test subscribers or use the credentials for existing ones. Register subscribers with the platform and perform a test call to ensure that call routing and media flow are working fine.

Run "apt-get update" on all nodes and ensure that you do not have any warnings and errors in the output.

warning

If the installation uses locally specified mirrors, then the mirrors must be switched to the Sipwise APT repositories (at least for the software upgrade). Otherwise, the public Debian mirrors may not provide packages for old Releases anymore or at least provide outdated ones!

13.5. Upgrading Sipwise C5

Make sure you are prepared to spend about two hours upgrading the system. Note that a short service downtime is possible during the services switchover to the upgraded node.

Start with the software upgrade on the standby sp1 node. Then, switch the services over to the upgraded node and upgrade the other (now standby) sp2 node, as described in the steps below.

13.5.1. Preparing for maintenance mode

Sipwise C5 introduces Maintenance Mode with its mr5.4.1 release. The maintenance mode of Sipwise C5 will disable some background services (for instance: mediator) during the software upgrade. It thus prevents the system from getting into an inconsistent state while the upgrade is being performed. You can activate maintenance mode by applying a simple configuration change as described later.

  • Pull pending configuration (if any):
ngcpcfg pull
  • Enable maintenance mode:
ngcpcfg set /etc/ngcp-config/config.yml "general.maintenance=yes"
  • Apply configuration changes by executing:
ngcpcfg apply 'Enabling maintenance mode before the upgrade to mr6.4.2'
ngcpcfg push all

13.5.2. Switch to the new repositories

To specify the new list of APT data sources, execute the following commands on both nodes:

NGCP_CURRENT_VERSION=$(cat /etc/ngcp_version)
sed -i "s/${NGCP_CURRENT_VERSION}/mr6.4.2/" /etc/apt/sources.list.d/sipwise.list
warning

Do not use "ngcpcfg apply/build" after executing the above commands, as otherwise the changes will be overwritten and you will have to redo this step.

13.5.3. Download the new packages into the approx cache (on standby node only)

To download the new packages into the approx cache, execute the following command on the standby node. This will ensure that both nodes have identical packages:

ngcp-approx-cache-helper --auto --node localhost

13.5.4. Install the package used to upgrade C5

Run the following commands on both nodes to install the package responsible for upgrading C5 to a newer release:

apt-get update
apt-get install ngcp-upgrade-pro

13.5.5. Upgrade the first PRO node

Execute the upgrade script on the standby node as root:

ngcp-upgrade
info

Sipwise C5 can be upgraded to mr6.4.2 from previous release or previous build only. The script ngcp-upgrade will find all the possible destination releases for the upgrade and allow one to choose the proper one.

info

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

The upgrade script will ask you to confirm that you want to start. Read the given information carefully, and if you agree, proceed with y.

The upgrade process will take several minutes, depending on your network connection and server performance. After everything has been updated successfully, it will finally ask you to reboot your system. Confirm to let the system reboot (it will boot with an updated kernel).

13.5.6. The customtt files handling (if necessary)

Merge/add the custom configuration templates if needed. Apply the changes to configuration templates and send them to the shared storage and the other node:

ngcpcfg apply 'The first node upgraded'
ngcpcfg push --nobuild --noapply

13.5.7. Promote the upgraded standby node to active

Execute on the current standby node as root:

ngcp-make-active

13.5.8. Upgrade the second PRO node

Go to the new standby node. Run the upgrade script as root:

ngcp-upgrade

The upgrade script will ask you to confirm that you want to start. Read the given information carefully, and if you agree, proceed with y.

The upgrade process will take several minutes, depending on your network connection and server performance. After everything has been updated successfully, it will finally ask you to reboot your system. Confirm to let the system reboot (it will boot with an updated kernel).

13.6. Post-upgrade tasks

13.6.1. Disabling maintenance mode

In order to disable the maintenance mode, do the following:

  • Pull outstanding ngcpcfg changes (if any):
ngcpcfg pull
  • Disable the maintenance mode:
ngcpcfg set /etc/ngcp-config/config.yml "general.maintenance=no"
  • Apply the changes to configuration templates:
ngcpcfg apply 'Disable the maintenance mode after the upgrade to mr6.4.2'
ngcpcfg push all

13.6.2. Post-upgrade checks

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

info

You can find a backup of some important configuration files of your existing installation under /var/backup/ngcp-mr6.4.2-* (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-mr6.4.2-*/upgrade.log.

13.7. Applying the Latest Hotfixes

If your current release is already the latest or you prefer to be on the LTS release, we still suggest appling the latest hotfixes and critical bug fixes.

Execute all steps as described in Section 13.4, “Preparing the software upgrade”. They include the system checks, customtt preparation and others. It is important to execute all the steps from the above chapter.

13.7.1. Update the approx cache on the standby node

The main goal of the following command is to download the new packages into the approx cache. So all the nodes in the cluster will get identical packages.

ngcp-approx-cache-helper --auto --node localhost

13.7.2. Apply hotfixes on the standby node

ngcp-update

13.7.3. Recheck or update the custom configuration tempates

Merge/add the custom configuration templates if needed.

Apply the changes to configuration templates:

ngcpcfg apply 'applying customtt after installing the latest packages'

Send the new templates to the shared storage and the other node.

ngcpcfg push --nobuild --noapply all

13.7.4. Promote the standby node to active

Execute on the standby node as root:

ngcp-make-active

Check in a minute that the node became active:

ngcp-check-active

13.7.5. Apply hotfixes on the second node

ngcp-update

Execute the final checks as described in the Post-upgrade checks section.