This page describes the actions to take after the upgrade is completed and all relevant validation tests have passed.

Clean up REM connections

You should be able to access the entire Rhino cluster using the original connection configured in REM. If you created an additional connection to monitor the new cluster during the upgrade, delete it now.

Note that when refreshing the REM web application, be sure to do a "hard refresh" (Ctrl+F5 in most browsers) so that the browser retrieves up-to-date information from the REM server rather than reloading from its cache.

Check service state and alarms

Symmetric activation state mode

Symmetric activation state mode must be enabled prior to the upgrade. If your deployment normally operates with it disabled, you will need to manually disable it at this point. See Symmetric Activation State in the Rhino documentation. You may also need to update RA entity activation states.

Log into REM and access the connection to the Rhino cluster. Check that all services are active on all nodes. Also check that the RA entity activation state is as expected on all nodes. Check for unexpected alarms.

Verify SAS configuration

If your deployment is now running Rhino 2.6.0 or later and includes a MetaView Service Assurance Server (SAS), verify the SAS configuration in Rhino is as expected. See SAS Tracing in the Rhino documentation.

Check that calls made in your validation tests appear in SAS.

Restore external network element configuration

If you made any changes to external network elements (for example to timeout INVITEs more quickly or to redirect traffic), then restore the original configuration on those elements.

Archive the downlevel export generated during the upgrade, and generate a new export

On the first node, orca will have generated an export of the Rhino installation at the downlevel version, prior to any migration or upgrade steps. This can be found in the ~/export directory, labelled with the version and cluster ID, and is a useful "restore point" in case problems with the upgrade are encountered later that cannot be simply undone with the rollback command. Copy (for example using rsync) the downlevel export directory with all its contents to your backup storage, if you have one.

Follow the Rhino documentation to generate a post-upgrade export and archive this too.

Uplevel exports generated during major upgrade

Note that during major upgrade orca will automatically generate an export of the uplevel installation. However, this export is intended for orca's use only and is not suitable to restore from - for example, it will not include a large amount of Rhino configuration nor any feature script changes made during the merge feature scripts step. There will also be an export labelled with transformed-for-<uplevel version>, to which the same caveat applies.

These exports can be ignored, and deleted at a later date.

Archive the upgrade logs

In the directory from which orca was run, there will be a directory logs containing many subdirectories with log files. Copy (for example using rsync) this logs directory with all its contents to your backup storage, if you have one. These logs can be useful for Metaswitch Customer Care in the event of a problem with the upgrade.

Save the file

It is a good idea to save the file for use in a future upgrade.

Remember that the file is currently on the machine that you chose to run orca from, and that may not be the same machine chosen by someone doing a future upgrade.

A good location to put the file is in a /home/sentinel/install directory on whatever you regard as the main Rhino host. This may be the one you always provide first in the list of hosts for example, or the one originally used to install Rhino in the first place.

Configure new features

If the uplevel software introduced new features that you plan to use in your deployment, you may wish to configure and verify them here. Refer to the Sentinel VoLTE manuals and changelogs for more information.

If required, clean up downlevel clusters and unneeded exports

Once the upgrade is confirmed to be working, you may wish to clean up old downlevel cluster(s) to save disk space.

Run the status command to view existing clusters and exports

Run the status command and observe the clusters and exports sections of the output.

./orca --hosts <host1,host2,host3,…​> status


For upgrades, exports are only generated on the first node.

Identify any clusters or exports you no longer wish to keep. Note their cluster IDs, which is the last part of the name. For example, given this output:

Status of host host1

 - volte-
 - volte-
 - volte- - LIVE


 - volte-
 - volte-
 - volte-
 - volte-


Status of host host2

 - volte-
 - volte-
 - volte- - LIVE


you may decide to delete cluster 41 and exports 41 and 42.

Retain one old cluster

You are advised to always leave the most recent downlevel cluster in place as a fallback.

Be sure you have an external backup of any export directories you plan to delete, unless you are absolutely sure that you will not need them in the future.

Run the cleanup command to delete clusters and exports

Run the cleanup command, specifying the clusters and exports to delete as comma-separated lists of IDs (without whitespace). For example:

./orca --hosts <host1,host2,host3,...> cleanup --clusters 41
./orca --hosts <host1> cleanup --exports 41,42

Update Java version of other applications running on the hosts

If performing a major upgrade with a new version of Java, orca will install the new Java but it will only be applied to the new Rhino installation. Global environment variables such as JAVA_HOME, or other applications that use Java, will not be updated.

The new Java installation can be found at ~/java/<version> where <version> is the JDK version that orca installed, e.g. 8u162. If you want other applications running on the node to use this new Java installation, update the appropriate environment variables and/or configuration files to reference this directory.

Previous page Next page