This section documents information concerning the upgrade. Be sure you are also familiar with the new features and new configuration introduced in the uplevel Sentinel Authentication Gateway software.

Information required

Maintenance window

In general an upgrade of a Rhino cluster running Sentinel Authentication Gateway can be completed in a single maintenance window, though for operational reasons you may wish to use more than one. The maintenance window should be of adequate length (at least 15 minutes for the first node, 10 minutes for subsequent nodes, plus additional time for traffic draining, and validation tests according to your test plan).

Manual reconfiguration steps

For deployments utilizing any or all of:

  • extensive customizations to the standard Sentinel Authentication Gateway software

  • feature script modifications

  • a cluster with 3 or mode nodes

  • multiple clusters running the same product

it is strongly recommended that the upgrade is trialled in a lab deployment first. This will allow you to identify any breaking issues with the upgrade, and to note any customizations to feature scripts and other configuration that needs to be applied after the upgrade.

Traffic impact

Traffic capacity will be reduced by a fraction of 1/N where N is the number of nodes in the cluster to be upgraded. That is to say, at any given point during the upgrade one node will be unavailable but the rest will still be able to handle traffic. As such the maintenance window should be planned for a period where call traffic volumes are quieter.

Product upgrade order

A Sentinel deployment may consist of multiple products: REM, GAA, VoLTE, and IPSMGW. The clusters must be upgraded in the following order: REM (with plugins), then GAA, then VoLTE, then IPSMGW. (For clarity, all GAA nodes must be upgraded before any VoLTE nodes, and all VoLTE before any IPSMGW.)

For major upgrades, you will need to upgrade all products in close succession, since having upgraded REM to a new version first, you need to upgrade all the other products soon after to ensure that the REM plugins for the products retain maximum compatibility, and are able to provide the best management interface.

Node order

The first node in each Rhino cluster is handled separately to the rest, since the software upgrade only needs to actually be performed on one node and the rest can pick up the upgraded software by joining the new cluster (see Cluster Migration Workflow).

Always specify the hosts in reverse order of their node IDs, i.e. from highest to lowest. This is necessary since certain Rhino features use the node ID as a tie-breaker when they can otherwise not determine which node has preference, so we want to make sure the highest number node is processed first to avoid problems.

orca takes a list of hosts. The hosts are upgraded in the order specified, and only the nodes specified are upgraded. As such, orca supports splitting the upgrade across multiple maintenance windows by specifying only a subset of hosts on each window.

Limitation of one cluster

orca only supports working with a list of hosts where all hosts are part of the same cluster. If your deployment has multiple clusters to be upgraded, then these upgrades need to be done separately. This does mean that (if such an approach is suitable for your overall deployment architecture) you can use multiple machines to run orca, each upgrading a single cluster, to parallelize the upgrade; however, this will increase correspondingly the service impact..

Files required

Upgrade bundle

Your Metaswitch Customer Care Representative should have provided you with an upgrade bundle, normally named gaa-<uplevel-version> or similar. unzip the bundle to a directory of your choice and cd to it.

orca working directory

orca must always be run from the directory where it resides. It will fail to operate correctly if run from any other location.

Verify the orca script is present and executable by running ./orca --help. You should see usage information.

Verify that orca can contact the hosts you wish to upgrade by running ./orca --hosts <host1,host2,…​> status. You should see status information, such as the current live cluster and lists of services, about all the hosts specified.

SSH access to hosts

orca requires passwordless SSH access to hosts, i.e. all hosts in the cluster must be accessible from the machine running orca using SSH keys. If this is not the case, orca will throw an error saying it is unable to contact one or more of the hosts. Ensure SSH key-based access is set up to all such hosts and retry the status command until it works.

Upgrading any product requires an file. If you are familiar with some of the other Sentinel products, specifically VoLTE or IPSMGW, then you may be aware that for those products an file is generated when you install them, and can serve as the basis for the one used to upgrade with.

However, Sentinel Authentication Gateway does not have such an installer, and thus does not generate an file in the same way.

Instead you should manually create the file containing the following lines:<platform-operator-name>

where <platform-operator-name> is the name your installation uses as the operator name, and <rhino-client-dir> is the full path of the directory where the Rhino client is installed in your installation.

In addition, you should include the other settings described in Default configuration for the BSF server.

The file can be placed anywhere, though normal practice would be to put it in the same directory as orca in the unzipped bundle so as to associate the file with this upgrade.

Note that some new releases may introduce new mandatory fields. If so, and these are missing from the provided, orca will raise this early on in the upgrade process. Edit the file to add the missing values (your Support Representative can tell you the keys and values required).

Previous page Next page