This page includes instructions for doing a live upgrade from an existing Rhino cluster that is receiving traffic through CGIN, to a new cluster that has the same configuration but different software versions (such as a new Rhino or CGIN version, or new service version if it can’t be done in a single cluster).

Below are general information about and then instructions for performing upgrades using STP redirection, and Signalware In-place upgrades.

About cluster upgrades with CGIN

Below is a table of possible upgrade paths for clusters using the CGIN Signalware TCAP stack:

Old version New version Upgrade using STP redirect? Upgrade in-place? 
1.4.x
 
1.5.x

Yes

Yes

 
1.5.x
 
1.5.x

Yes

Yes
Warning
A warning about ETC/ARI dialog correlation

ETC/ARI dialog correlation arranges for inbound ARI dialogs to be directed to the same cluster node that sent the corresponding ETC. In general, dialog correlation can only happen within a single cluster. During an upgrade, there are two clusters present and receiving traffic.

If an ARI dialog is received by the "wrong" cluster (a cluster that did not send the corresponding ETC), then correlation will fail, and the ARI will not be directed to the correct cluster node. If dialog correlation is used, then care should be taken to ensure that ARI dialogs are directed to the correct cluster — for example, by configuring the service deployed in the new cluster to send ETCs that direct the ARI dialogs to an SCP address associated with the new cluster only.

Upgrades using STP redirection

Note

This approach manages the upgrade externally to Rhino and Signalware, and requires support from the STP and surrounding network, as well as support in the existing service.
It can be used for all types of upgrade.

Prerequisites

Before upgrading using STP redirection, make sure that:

  • Inbound TC-BEGINs are addressed to a "logical" GT. The STP translates this GT to one-of-N "physical" addresses using a load-balancing mechanism. These "physical" addresses route to a particular cluster.

  • The STP needs the ability to reconfigure the translation addresses in use at runtime.

  • The old and new clusters are assigned different "physical" addresses.

  • The service ensures that initial responding TC-CONTINUEs provide an SCCP Calling Party Address that is the "physical" address for the cluster that is responding.

  • Subsequent traffic uses the "physical" address using normal TCAP procedures.{note}

Upgrade process

To upgrade using STP redirection:

1

Set up the new cluster with a new "physical" address.

2

Configure and activate the new cluster.

3

Reconfigure the STP to include the new cluster’s physical address when translating the logical GT.

4

Verify that traffic is processed by the new cluster correctly.

5

Reconfigure the STP to exclude the old cluster’s physical address when translating the logical GT.

6

Wait for all existing dialogs to drain from the old cluster.

7

Halt the old cluster.

Signalware In-place upgrade procedure

Note

This upgrade process supports upgrades where the service in use may initiate outbound CGIN dialogs.
It is supported when using Signalware for upgrades from CGIN 1.4.x to 1.5.x and from 1.5.x to 1.5.x

1
Set up the new cluster

  • Install the new cluster. Ensure that the cluster ID used is different to that of the old cluster, and that files, databases, and ports used by the new cluster don’t overlap with the old cluster.

  • Boot the new cluster.

  • Ensure that Rhino is in the STOPPED state

  • Deploy and configure RAs and services. Configure CGIN RA entities in the same way as on the "old" cluster, pointing to the same backend addresses.

Tip A Rhino export from the old cluster may be useful for this step.

Now you should have the "new" cluster configured, but STOPPED, so that it is not receiving traffic.

Caution To roll back this step, just discard your new cluster install. (No traffic is being processed by the new cluster yet.)

2
Start the new cluster

  • To start the "new" cluster, change the SLEE state to RUNNING. The new cluster RAs will connect to the same backends as the old cluster. New incoming traffic will be loadbalanced between the old and new clusters.

Note Initially, not much traffic will be loadbalanced to the new cluster. With the default settings, initially only 1% of traffic will be allocated to the new cluster; so at low call rates, it may take some time before traffic is processed by the new cluster.

  • Verify that the new cluster is processing calls correctly.

Caution

To roll back this step:

  1. Reconfigure each CGIN resource adaptor entity in the new cluster to set the RA property signalware.base-weight to 0. For example:

    updateraentityconfigproperties entityname signalware.base-weight=0

  2. Wait for all dialogs in the new cluster to end.

  3. Stop the new cluster — change the SLEE state to STOPPED.

3
Drain calls from the old cluster

  • For each CGIN RA entity in the old cluster, reconfigure the RA entity to set the RA property signalware.base-weight to 0:

    updateraentityconfigproperties entityname signalware.base-weight=0

At this point, all new dialogs will be directed to the new cluster only. The old cluster will only continue to process existing dialogs established before the draining process started.

  • Wait for all dialogs in the old cluster to end.

Now the old cluster should be still connected to the CGIN backends, but completely idle — no traffic is being handled by the old cluster.

Caution To roll back this step, for each CGIN RA entity in the "old" cluster, reconfigure the RA entity to restore the original value of signalware.base-weight, by default 100.

4
Stop the old cluster

  • Stop the SLEE using the stop management command.

  • Wait for the SLEE to reach the STOPPED state.

Caution To roll back this step, start the SLEE.

5
Shut down the old cluster

  • Shut down the old cluster using the shutdown management command.

Caution To roll back this step, restart the "old" cluster processes.

6
Schedule upgrade of old backends to the new version

(if needed)
Previous page Next page