This page describes the steps required to abort an upgrade partway through, or revert back to the downlevel system after the upgrade is complete.
Rolling back the upgrade will take approximately {product-time-other-nodes} per affected node. Which nodes are affected depends on which nodes were partially or fully upgraded.
Be sure you know the original cluster ID as noted in the pre-upgrade checklist.
Note that in the normal case there should be no need to restore the Rhino cluster from an export. The cluster directory being rolled back to will contain all relevant configuration. However, any configuration changes made since the upgrade started will be lost.
Restore network element configuration
If, in preparation to the upgrade, you made changes to other elements in your network, you should undo these changes before starting the rollback procedure.
Check the current cluster status
Use orca's status command to check the current cluster status.
./orca --hosts <host1,host2,host3,…> status
For each host there may be multiple clusters listed, but only one of those will be marked as LIVE, so note its ID,
which is the last part of the cluster name. If the various hosts have nodes in different 'LIVE' clusters, then
any nodes in a 'LIVE' cluster that is not the original live cluster will need to have their hosts rolled back.
(In most circumstances, the original live cluster will have a lower ID number, so rollback will normally be needed
for any host that does not have that lowest number cluster ID marked as being 'LIVE').
If required, run the rollback command
If you identified any hosts that need to be rolled back, run the rollback command. Hosts are specified as a
comma-separated list without whitespace, e.g. --hosts host1,host2. Specify the hosts in reverse order of node ID (that is,
highest node ID first).
./orca --hosts <hosts to be rolled back> rollback --stop-timeout <timeout>
where <timeout> is the time you wish to allow for traffic to drain on each node.
If you are rolling back every host in the cluster (or more specifically, the cluster ID that you are rolling back to
currently contains no members), then append the parameter --special-first-node to the above command line.
This instructs orca that the first node specified will need to be made primary so that the cluster starts correctly.
This procedure will take approximately {product-time-other-nodes} per host specified.
If required, run the cleanup command
Follow the instructions here.
Perform validation tests
Ensure you can log into REM and connect to the cluster.
-
Ensure all services are started.
-
Ensure RA entity activation state is as expected. Start or stop any RA entities as required.
-
Check for and resolve unexpected alarms.
Perform test calls and other validation tests to ensure the rolled-back cluster is operating normally.
The rollback procedure is now complete.
Next steps
Discuss with your Metaswitch Customer Care Representative the next steps, for example obtaining a patch or more recent release that addresses any problems encountered during the upgrade, or retrying the upgrade at a later date.
