|
The offline upgrade process involves a period of complete outage for the cluster being upgraded. |
The offline upgrade process allows for the upgrade of a cluster without the use of STP redirection or a second point code. This process involves terminating the existing cluster and replacing it with a new cluster.
Consequences of this approach include:
-
A complete service outage at the site being upgraded during the upgrade window.
-
In progress dialogs will be terminated unless the operator is able to switch new traffic to an alternate site and configure calls to drain prior to starting the upgrade.
This upgrade involves two phases which are carried out sequentially. These are preparation and execution.
Preparation
The preparatory phase of the upgrade may carried out in advance of the upgrade window provided that no further configuration changes are expected or permitted to the existing cluster between the preparation phase starting and the execution phase of the upgrade being performed.
|
|
Any configuration changes applied to the SGC after preparation has started will not be migrated to the upgraded cluster. |
The following operations should be carried out in the listed order:
1. Backup the Existing Cluster
Create a backup of the existing cluster. This ensures that it will be possible to reinstate the original cluster in the event that files from the original cluster are inadvertently modified or removed and it becomes necessary to revert or abort the upgrade.
2. Export the Configuration MML from the Existing Cluster
Use the SGC CLI to export the configuration MML from the existing cluster to a file:
$SGC_HOME/cli/sgc-cli.sh -x <file.mml>
3. Install the Replacement Cluster
Configuration files from prior OCSS7 releases may not be used with OCSS7 5.0.x. The cluster should be installed as though it were a new OCSS7 installation. See Installing the SGC for more information.
4. Backup the Replacement Cluster
Create a backup of the replacement cluster prior to starting the execution phase.
Execution
The execution phase should be carried out during a scheduled upgrade window. The preparation phase must have been completed prior to starting this phase.
|
|
The execution phase involves a period of complete outage for the cluster being upgraded. |
The execution phase is comprised of the following actions:
1. (Optional) Switch Traffic to an Alternate Site
Optionally, traffic may be switched to an alternate site.
How to do this is site specific and out of the scope of this guide.
2. Terminate the Existing Cluster
For each node in the existing cluster execute sgc stop:
$SGC_HOME/bin/sgc stop
Stopping processes:
SGC:7989
DAEMON:7974
Initiating graceful shutdown for [7989] ...
Sleeping for max 32 sec waiting for graceful shutdown to complete.
Graceful shutdown successful
Shutdown complete (graceful)
|
If the node has active calls the graceful shutdown may become a forced shutdown, resulting in active calls being terminated. This is a normal and expected consequence of an offline upgrade when calls have not been redirected and/or drained from the site to be upgraded. |
And validate the state of the node using sgc status:
$SGC_HOME/bin/sgc status SGC is down
3. Start the Replacement Cluster
Start each node in the replacement cluster using sgc start:
$SGC_HOME/bin/sgc start SGC starting - daemonizing ... SGC started successfully
And validate the state of the node using sgc status:
$SGC_HOME/bin/sgc status SGC is alive
The CLI’s display-info-nodeversioninfo and display-info-clusterversioninfo commands may also be used to view the node and cluster status respectively. Also, display-node may be used to view configured nodes that are in the active state.
|
|
display-info-nodeversioninfo and display-info-clusterversioninfo are OCSS7 3.0.0.0+ only commands.
|
4. Install Cluster Configuration
Load the cluster configuration MML that was prepared during the preparation stage.
$SGC_HOME/cli/sgc-cli.sh -b <file.mml>
5. Verify Cluster Operation
It is strongly recommended that correct cluster operation is verified with either test calls or a very small number of live calls prior to resuming full operation.
The process of generating test calls or sending a small number of live calls to the cluster is unique to the site and therefore out of the scope of this guide.
