12. Software Upgrade

12.1. Release Notes
12.2. Overview
12.3. Planning a software upgrade
12.4. Preparing the software upgrade
12.4.1. Log into the standby management server (web01a/db01a).
12.4.2. Log into the remaining servers
12.5. Upgrading the sip:carrier
12.5.1. Preparing for maintenance mode
12.5.2. ngcp-upgrade options
12.5.3. Upgrading ONLY the first standby management node "A" (web01a/db01a)
12.5.4. Upgrading the standby database node "A" (db*a)
12.5.5. Upgrading other standby nodes "A" (lb*a/prx*a)
12.5.6. Promote ALL standby nodes "A" to active.
12.5.7. Upgrading ALL standby nodes "B" (web*b/db*b/lb*b/prx*b)
12.6. Post-upgrade steps
12.6.1. Disabling maintenance mode
12.6.2. Post-upgrade checks

12.1. Release Notes

The sip:carrier version mr5.5.10 has the following important changes:

  • Upgrade Debian from Debian 8 (jessie) to Debian 9 (stretch). SysV is still the init system in use. [TT#21905]
  • Migration from MariaDB 10.0 to MariaDB 10.1 [TT#21824]
  • [PRO/Carrier] Upgrade GlusterFS from 3.8.4 to 3.12.1 [TT#21896]
  • [PRO/Carrier] Remove now unused ngcp-glusterfs-config package. [TT#23433]
  • The monitoring backend has been migrated away completely from Redis to InfluxDB [TT#18250]
  • [PRO/Carrier] ngcp-collective-check will now check the free swap space. [TT#22752]
  • [PRO/Carrier] The ngcp-snmp-agent supports logging to syslog. [TT#21756]
  • Add ability to configure supported SSL protocols/ciphers in config.yml [TT#12195]
  • [PRO/Carrier] Discontinued and removed sems-app and sems-ha (sems-pbx takes over their tasks) [TT#22069] [TT#22070]
  • [PRO/Carrier] Presence event as-feature-event is now supported in kamailio with optional CloudPBX module [TT#18851]
  • [PRO/Carrier] Extension dialing within Auto-Attendant is now possible with CloudPBX module [TT#18736]
  • Implemented request and response processing runtime logging in proxy [TT#22659]
  • Updated asterisk to 13.14.1 [TT#20081]
  • Updated kamailio to 4.4.6 [TT#18950]
  • Implemented ability to check History-Info against allowed_clis or aliases per preference [TT#19559]
  • [PRO/Carrier] Add support for the new HTTP/2 and JWT based protocol for sending push messages to Apple/iOS devices (APNs) [TT#14952]
  • [PRO/Carrier] Different SIP domains can now be configured with distinct authentication data for sending push messages (Google GCM and Apple/iOS APNs) [TT#18841]
  • Add support for dynamically adding iptables firewall rules for RTP proxy media ports as they are opened and closed [TT#19350]
  • [PRO/Carrier] Add license management and enforcement system [TT#23200]
  • Optionally send anonymous usage statistics [TT#23200]
  • Adressed an issue in ngcp-credit-warning where it reported only 10 customers [TT#10964]
  • Adressed an issue with reseller termination via the API and his related contract remained active [TT#21106]
  • Adressed issues with customer and susbcriber lock level settings [TT#21271, TT#14285, TT#19656, TT#18765]
  • Addressed an issue with the fraud notification script not enlisting all the automatically locked subscribers [TT#18755]
  • Improved NGCP Panel UI and the API performance [TT#22827]
  • Added partitioning support for accounting.cdr [TT#3668]
  • Optimised performance, addressed several minor issues and introduced partitioning support in the acc-cleanup tool [TT#3668]
  • Added a "Manager Secretary" feature, currently only supports Polycom phones [TT#20302]
  • Addressed several minor issues in the rewrite rules data representation [TT#23426]
  • Added POST method support in the API to generate invoices [TT#17848]
  • libmyodbc is no longer supported in Debian and replaced by the MariaDB odbc connector library [TT#21307]
  • [PRO/Carrier] - Addressed an issue with reseller manipulation and the rtcengine provisioning when the rtcengine access was not configured [TT#20690]
  • [PRO/Carrier] Added Polycom phones provisioning support [TT#7515]
  • [PRO/Carrier] Improved Yealink phones provisioning support [TT#18335]
  • [PRO/Carrier] Improved error handling for the SMS delivery [TT#20095]
  • [PRO/Carrier] Improved Glusterfs server ngcp volume control [TT#22435]
  • [PRO/Carrier] Improved ngcp-sync-db to handle large blobs of data [TT#22806]
  • Performance tuning:

    • Disable Transparent Huge Pages (THP) support [TT#22160] (Redis performance tuning)
    • Linux sysctl changes:

      • net.core.somaxconn = 512 [TT#22160] (Redis performance tuning)
      • vm.overcommit_memory = 1 [TT#22160] (Redis performance tuning)
      • vm.swappiness = 10 [TT#22407] (prevent unnecessary swapping with available RAM)
      • sunrpc.min_resvport = 700 [TT#22658] (prevent heartbeat and NFS ports collisions)

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

12.2. Overview

The sip:carrier software upgrade procedure to mr5.5.10 will perform several fundamental tasks:

  • Upgrade the base system from Debian 8 (jessie) to Debian 9 (stretch)
  • 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

sip:carrier is a PRO-style system that has "A" and "B" sets of nodes with specific roles. The number of nodes can differ between installations and must be clarified before the upgrade at the planning stage.

The software upgrade is performed by Sipwise engineers with the following steps:

  • software upgrade planning
  • pre-upgrade steps: customtt, backups
  • making all "B" nodes active
  • ensure that all "A" nodes are standby
  • upgrading all "A" nodes to the new release
  • scheduling and performing a switchover to all "A" nodes
  • ensuring that "A" nodes work well (otherwise, switch over back to "B" nodes)
  • upgrading all "B" nodes to the new release
  • performing system post-upgrade testing/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.

warning

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

12.3. Planning a software upgrade

warning

Debian 9 (stretch) provides OpenSSH 7 with the ssh-dss (DSA) public key algorithm disabled (see more information here). Please ensure you are NOT using ssh-dss (DSA) based SSH keys, otherwise migrate to modern ssh-ed25519 (ED25519) algorithm BEFORE the upgrade.

warning

The license key for the sip:carrier must be installed and applied on all the servers before the software upgrade. Please contact the Sipwise support team to receive the license key.

Specify the provided license key in /etc/ngcp-config/config.yml

general:
  license_key: XXX_XXX_XXX

Have the following information prepared in writing:

  • which system should be upgraded (clarify about 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)
  • a 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 produce critical issues (the BFT should usually 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
  • confirm the steps that will be performed in writing
  • ensure that the customer and/or Sipwise engineers have access to the remote console of the servers: KVM, iDRAC, AMM

12.4. Preparing the software upgrade

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

12.4.1. Log into the standby management server (web01a/db01a).

tip

Use the physical IP addresses instead of the shared one, so you can jump between the nodes later on.

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-upgrade

Become root inside your screen session:

sudo -s

Check the overall system status:

ngcp-status --all

Ensure that all the proxy nodes replicate the read-only DB (127.0.0.1:3308) from the db01a node. Otherwise, discuss a special plan to address this particularity.

For the following 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 the future releases. This will allow you to get rid of the customtt files.

Find local changes to the template files by executing:

ngcp-customtt-diff-helper

ngcp-customtt-diff-helper can help you to download the templates for you target release. To do so, you can run the following command:

ngcp-customtt-diff-helper -d

In the tmp folder provided by the script you can, now, merge the current customtt with the new tt2, creating the new customtt.tt2 files. Once did that, you can TAR the new customtts in a tar.gz file and you can use that after the upgrade to deploy the new customtt.

ngcp-customtt-diff-helper -t

You can check further details regarding the ngcp-customtt-diff-help with the option "-h".

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, then treat the corresponding tt2 files as if they were custom templates and introduce the changes from the existing tt2 files into the new templates (by creating 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.

If you changed the configuration (e.g. added custom templates or changed the existing ones), then the system must be thoroughly tested when these changes are applied. Continue with the software upgrade preparation only when the results of the tests are successful.

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\*
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!

12.4.2. Log into the remaining 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).

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 manually run:

  • ngcpcfg status - must print OK on all nodes

Check all nodes in parallel, using clish and parallel-ssh:

  • ngcp-clish "ngcp version summary" - ensure that all cluster nodes have correct/expected from version
  • ngcp-clish "ngcp version package installed ngcp-ngcp-carrier" - ensure 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 on 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 all nodes to all other nodes
  • ngcp-clish "ngcp monit summary" - should not report any problems
  • ngcp-clish "ngcp cluster status" - active nodes (with all services running) must print "all", the others must print "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 that DNS records are correct
info

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" on all nodes. Ensure that you have no warnings/errors here.

Test the cluster failover to see if everything works fine on "B" nodes as well. On all the standby nodes execute:

ngcp-make-active

Afterwards, check ngcp-status --all again.

12.5. Upgrading the sip:carrier

Log in to all nodes and execute the checks from Section 12.4, “Preparing the software upgrade” again. This will ensure that nothing was broken since the preparation steps were finished. Also, execute ngcpcfg show and ngcpcfg status to check the latest configuration changes.

Perform the BFT test.

12.5.1. Preparing for maintenance mode

Sipwise NGCP introduced Maintenance Mode with its mr5.4.1 release. The maintenance mode of NGCP 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.

important

For sip:carrier systems running NGCP release older than mr5.4.1: As upgrading from an earlier release to mr5.4.1 or later will result in a system being aware and making use of the maintenance mode, it is necessary to prepare the NGCP for it before the software upgrade.

Enable maintenance mode:

  • Pull pending configuration (if any):
ngcpcfg pull
  • Edit /etc/ngcp-config/config.yml file:

    • For systems running NGCP release older than mr5.4.1: insert a new line: "maintenance: yes" in the general section of the configuration file
    • For systems running NGCP release mr5.4.1 or later: set the general.maintenance parameter to yes
general:
  maintenance: yes

Disabling background services. These tasks are for systems currently running NGCP release older than mr5.4.1. The maintenance mode of NGCP is not available in your system prior to the software upgrade. It is therefore necessary to manually disable the following background services to avoid a potential system inconsistency:

  • Heartbeat watchdog
  • Mediator
  • Rate-o-mat
  • CDR Exporter

Execute the following:

  1. Stop HB watchdog on all nodes:

    monit stop hb_watchdog
  2. Stop mediator and rate-o-mat services on proxy (prxNNy) nodes :

    monit stop mediator
    monit stop rate-o-mat
  3. Prevent background services from (re)starting. You need to change configuration in the /etc/ngcp-config/config.yml file: set the enable parameter to "no":

    heartbeat:
      hb_watchdog:
        enable: no
    ...
    mediator:
      enabled: no
    ...
    rateomat:
      enable: no
  4. In order to disable the CDR exporter process, add a new custom template file because there is no such file by default:

    config="/etc/cron.d/ngcp-cdr-exporter"
    customtt="/etc/ngcp-config/templates/etc/cron.d/ngcp-cdr-exporter.customtt.tt2"
    [ -f "${customtt}" ] || cp "${config}" "${customtt}"
    vim "${customtt}"

    Comment out this single line in the file:

    # 25,55 * * * *   root    . /etc/default/ngcp-roles; if ...

Please don’t forget to reverse the manual changes after the software upgrade as described in Enabling background services section of the handbook!

For all NGCP systems, regardless of their version:

Apply configuration changes by executing s:

ngcpcfg apply 'Enabling maintenance mode before the upgrade to mr5.5.10'
ngcpcfg push all

To upgrade the sip:carrier to mr5.5.10 release, execute the following commands on the standby management "A" node:

12.5.2. ngcp-upgrade options

The following options in ngcp-upgrade can be specially useful in some instances of upgrade:

  • --step-by-step: confirm before proceeding to next step. With this option the upgrade operation is performed confirming every step before execution, with the possibility to instruct to continue without confirming further steps until the end (if confirmation is only needed for some steps at the beginning).
  • --pause-before-step STEP_NAME: pause execution before step, given by the name of the script (e.g. "backup_mysql_db"). This option can be useful in several scenarios, for example:

    • to help to debug problems or work around known problems during upgrades. In this case the operator can pause at a given step known to be problematic or just before a problematic set, perform some manual checks or changes, then continue the upgrade until another step (with confirmation like with the recent option --step-by-step), or just continue without stop until the end
    • another use might be to help to speed up upgrades when it involves several nodes: they can all proceed in parallel when it’s known to be safe to do so; then perform some parts in lock-step (some nodes waiting until others finish with some stage); then continue in parallel until the end
  • --skip-db-backup: This will speed-up the process in cases where it’s deemed unnecessary, and this is very likely in the upgrade of nodes other than the first.

12.5.3. Upgrading ONLY the first standby management node "A" (web01a/db01a)

info

Sometimes the DB and MGMT roles are assigned to the same host. This is OK.

warning

Do NOT execute the software upgrade on web01a and db01a in parallel!

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

NGCP_CURRENT_VERSION=$(cat /etc/ngcp_version)
sed -i "s/$NGCP_CURRENT_VERSION/mr5.5.10/" /etc/apt/sources.list.d/sipwise.list
sed -i "s/jessie/stretch/g" /etc/apt/sources.list.d/sipwise.list /etc/apt/sources.list.d/debian.list

[ -r /etc/default/ngcp-proxy ] && source /etc/default/ngcp-proxy
mgmt_node=$(cat /etc/ngcp_mgmt_node)
grep -q "debian-debug" /etc/apt/sources.list.d/debian.list || \
  echo "deb http://${mgmt_node:-web01}:${APPROX_RO_PORT:-9998}/debian-debug/ stretch-debug main contrib non-free" >> /etc/apt/sources.list.d/debian.list
grep -q "debian-debug" /etc/approx/approx.conf || \
  echo "debian-debug  https://debian.sipwise.com/debian-debug" >> /etc/approx/approx.conf

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

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

Don’t worry, ngcp-upgrade-carrier does not exist, use ngcp-upgrade-pro as outlined above.

warning

Do not use "ngcpcfg apply/build" after executing the steps from the above section, otherwise the changes will be overwritten and you will have to redo these steps. The same applies to similar sections below.

Execute ngcp-upgrade on the standby node as root:

ngcp-upgrade
info

sip:carrier can be upgraded to mr5.5.10 from previous release or previous build only. The script ngcp-upgrade will find all the possible destination releases for the upgrade and allow 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.

Merge/add the custom configuration templates if needed.

Apply the changes to configuration templates:

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

Send the new templates to the shared storage and the other nodes

ngcpcfg push --nobuild --noapply all
warning

Do NOT execute ngcpcfg push --shared-only at this stage, as 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 glusterfs.

12.5.4. Upgrading the standby database node "A" (db*a)

info

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

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

NGCP_CURRENT_VERSION=$(cat /etc/ngcp_version)
sed -i "s/$NGCP_CURRENT_VERSION/mr5.5.10/" /etc/apt/sources.list.d/sipwise.list
sed -i "s/jessie/stretch/g" /etc/apt/sources.list.d/sipwise.list /etc/apt/sources.list.d/debian.list

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

It is important to upgrade db01a node before upgrading any proxy nodes. Otherwise, the "local" MySQL (127.0.0.1:3308) on proxy nodes may become out of sync in case the new release has _not_replicated.up DB statements.

12.5.5. Upgrading other standby nodes "A" (lb*a/prx*a)

Run the below commands selecting the same release version and follow the on-screen recommendations:

NGCP_CURRENT_VERSION=$(cat /etc/ngcp_version)
sed -i "s/$NGCP_CURRENT_VERSION/mr5.5.10/" /etc/apt/sources.list.d/sipwise.list
sed -i "s/jessie/stretch/g" /etc/apt/sources.list.d/sipwise.list /etc/apt/sources.list.d/debian.list

apt-get update
apt-get install ngcp-upgrade-pro
ngcp-upgrade
12.5.5.1. Useful options in ngcp-upgrade

The following options in ngcp-upgrade can be useful for this phase of upgrades, because it is very likely that the backup was already performed:

  • --skip-db-backup: This will speed-up the process in cases where it’s deemed unnecessary.

See a more detailed description of the options in: ngcp-upgrade options

12.5.6. Promote ALL standby nodes "A" to active.

warning

Ensure that all standby nodes "A" are: * upgraded to the new release (check /etc/ngcp_version or use ngcp-clish) * have been rebooted (run ngcp-status on each standby node)

On all "A" nodes run:

ngcp-make-active

Ensure that the "A" nodes became active, by executing the 'ngcp-status' and 'ngcp-clish' commands described above.

Ensure that ALL "B" nodes are standby now!

12.5.7. Upgrading ALL standby nodes "B" (web*b/db*b/lb*b/prx*b)

Run the following commands selecting the same release version and following the on-screen recommendations:

NGCP_CURRENT_VERSION=$(cat /etc/ngcp_version)
sed -i "s/$NGCP_CURRENT_VERSION/mr5.5.10/" /etc/apt/sources.list.d/sipwise.list
sed -i "s/jessie/stretch/g" /etc/apt/sources.list.d/sipwise.list /etc/apt/sources.list.d/debian.list

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

You can upgrade all standby "B" nodes simultaneously (including the ones with the mgmt and db roles).

12.5.7.1. Useful options in ngcp-upgrade

The following options in ngcp-upgrade can be useful for this phase of upgrades:

  • --step-by-step: confirm before proceeding to next step.
  • --pause-before-step STEP_NAME: pause execution before step, given by the name of the script (e.g. "backup_mysql_db").

See a more detailed description of the options in: ngcp-upgrade options

12.6. Post-upgrade steps

12.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"

Enabling background services. If you upgraded from NGCP release earlier than mr5.4.1, you have to manually reverse the changes you applied before the upgrade in the (Disabling background services) section.

  1. Enable background services:

    ngcpcfg set /etc/ngcp-config/config.yml "heartbeat.hb_watchdog.enable=yes"
    ngcpcfg set /etc/ngcp-config/config.yml "mediator.enabled=yes"
    ngcpcfg set /etc/ngcp-config/config.yml "rateomat.enable=yes"
  2. In order to enable the CDR exporter process, remove the corresponding customtt file:

    rm /etc/ngcp-config/templates/etc/cron.d/ngcp-cdr-exporter.customtt.tt2

For all NGCP systems, regardless of their previous version:

  • Execute the commands:
ngcpcfg apply 'Disable the maintenance mode after the upgrade to mr5.5.10'
ngcpcfg push all

12.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-mr5.5.10-* (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-mr5.5.10-*/upgrade.log.