Modular Cluster Topology: Upgrade a Multinode Environment with the ISO and Template¶
Note
When upgrading from an existing Modular Cluster Topology that was available since VOSS Automate 21.1, use the steps listed here.
Tasks that are marked Prior to Maintenance Window can be completed a few days prior to the scheduled maintenance window so that VOSS support can be contacted if needed and in order to allow for reduce down time.
The standard screen command should be used where indicated. See: Using the screen command.
Primary database and application node in a Modular Cluster Topology
Verify the primary application node (UN2) with the cluster primary role application command run on the node. The output should be true, for example:
platform@UN2:~$ cluster primary role application is_primary: true
Verify the primary database node (UN1) with the cluster primary role database command run on the node. The output should be true, for example:
platform@UN1:~$ cluster primary role database is_primary: true
Download Files and Check (Prior to Maintenance Window)¶
Description and Steps |
Notes and Status |
|---|---|
VOSS files: https://voss.portalshape.com > Downloads > VOSS Automate > XXX > Upgrade Download
Two transfer options: Either using SFTP:
Or using SCP:
Verify that the
Verify that the original
|
Security and Health Check Steps (Prior to Maintenance Window)¶
Description and Steps |
Notes and Status |
|---|---|
Verify that the primary database node is the active primary node at the time of upgrade. database config Ensure that the node on which the installation will be initiated has the Example output <ip address>:27020:
priority: <number>
stateStr: PRIMARY
storageEngine: WiredTiger
Note If you run cluster status after installing the new version of cluster check, any error message regarding a failed command can be ignored. This error message will not show after upgrade.
|
Schedules, Transactions and Version Check (Maintenance Window)¶
Description and Steps |
Notes and Status |
|---|---|
Run cluster check and verify that no warnings and errors show. Turn off any scheduled imports to prevent syncs triggering part way through the upgrade. Two options are available: Individually for each job:
Mass modify:
Schedules enabled on the primary application node CLI:
|
|
Check for running imports. Either wait for them to complete or cancel them:
|
|
Version Record the current version information. This is required for upgrade troubleshooting.
|
Pre-Upgrade Steps (Maintenance Window)¶
As part of the rollback procedure, ensure that a suitable restore point is obtained prior to the start of the activity, as per the guidelines for the infrastructure on which the VOSS Automate platform is deployed. Optional: If a backup is also required - on the primary database node, use the backup add <location-name> and backup create <location-name> commands. For details, refer to the Platform Guide. |
Description and Steps |
Notes and Status |
|---|---|
After restore point creation and before upgrading: validate system health and check all services, nodes and weights for the cluster:
On the primary application node, verify there are no pending Security Updates on any of the nodes:
|
Upgrade (Maintenance Window)¶
Note
By default, the cluster upgrade is carried out in parallel on all nodes and without any backup in order to provide a fast upgrade.
Description and Steps |
Notes and Status |
|---|---|
It is recommended that the upgrade steps are run in a terminal opened with the screen command. Verify that the ISO has been uploaded to the On the primary database node:
Close screen: |
All unused docker images except selfservice and voss_ubuntu images
will be removed from the system at this stage.
Post-Upgrade and Health Steps (Maintenance Window)¶
Description and Steps |
Notes and Status |
|---|---|
On the primary database node, verify the cluster status:
|
|
To remove a mount directory cluster run all app cleanup on the primary database node. |
|
Check for needed security updates. On the primary application node, run:
If one or more updates are required for any node, run on the primary application node:
Note: if the system reboots, do not carry out the next manual reboot step. Manual reboot only if needed:
If node messages:
Since all services will be stopped, this takes some time. |
|
If upgrade is successful, the screen session can be closed by typing exit in the screen terminal. If errors occurred, keep the screen terminal open for troubleshooting purposes and contact VOSS support. |
Database Schema Upgrade (Maintenance Window)¶
Description and Steps |
Notes and Status |
|---|---|
It is recommended that the upgrade steps are run in a terminal opened with the screen command. On the primary database node:
Check cluster status
|
Template Upgrade (Maintenance Window)¶
Description and Steps |
Notes and Status |
|---|---|
It is recommended that the upgrade steps are run in a terminal opened with the screen command. On the primary application node:
|
The following message appears:
Running the DB-query to find the current environment's
existing solution deployment config...
Python functions are deployed
System artifacts are imported.
Note
In order to carry out fewer upgrade steps, the updates of instances of the some models are skipped in the cases where:
data/CallManagerinstance does not exist as instance indata/NetworkDeviceListdata/CallManagerinstance exists, butdata/NetworkDeviceListis emptyCall Manager AXL Generic Driver and Call Manager Control Center Services match the
data/CallManagerIP
The template upgrade automatically detects the deployment mode: “Enterprise”, “Provider with HCM-F” or “Provider without HCM-F”. A message displays according to the selected deployment type. Check for one of the messages below:
Importing EnterpriseOverlay.json
Importing ProviderOverlay_Hcmf.json ...
Importing ProviderOverlay_Decoupled.json ...
The template install automatically restarts necessary applications. If a cluster is detected, the installation propagates changes throughout the cluster.
Description and Steps |
Notes and Status |
|---|---|
Review the output from the app template command and confirm that the upgrade message appears: |
Deployment summary of PREVIOUS template solution
(i.e. BEFORE upgrade):
-------------------------------------------------
Product: [PRODUCT]
Version: [PREVIOUS PRODUCT RELEASE]
Iteration-version: [PREVIOUS ITERATION]
Platform-version: [PREVIOUS PLATFORM VERSION]
This is followed by updated product and version details:
Deployment summary of UPDATED template solution
(i.e. current values after installation):
-----------------------------------------------
Product: [PRODUCT]
Version: [UPDATED PRODUCT RELEASE]
Iteration-version: [UPDATED ITERATION]
Platform-version: [UPDATED PLATFORM VERSION]
Description and Steps |
Notes and Status |
|---|---|
|
|
For an unsupported upgrade path, the install script stops with the message: Upgrade failed due to unsupported upgrade path.
Please log in as sysadmin
and see Transaction logs for more detail.
You can roll back as per the guidelines for the infrastructure on which the VOSS Automate platform is deployed. |
|
If there are errors for another reason, the install script stops with a failure message listing the problem. Contact VOSS support. |
|
On the primary application node,
verify the
|
|
Post upgrade migrations: On a single application node of a cluster, run:
|
Data migrations that are not critical to system operation can have significant execution time at scale. These need to be performed after the primary upgrade, allowing the migration to proceed whilst the system is in use - thereby limiting upgrade windows.
A transaction is queued on VOSS Automate and its progress is displayed as it executes.
Description and Steps |
Notes and Status |
|---|---|
|
Post Template Upgrade Tasks (Maintenance Window)¶
Description and Steps |
Notes and Status |
|---|---|
SSO Login URL check if needed Verify the SSO Login URL if needed. Go to Single Sign On > SSO Identity Provider and ensure your URL matches the SSO Login URL value. Customized ``data/Settings`` Merge the previously backed up customized Support for VG400 and VG450 Analogue Gateways Before adding the VG400 or VG450 Gateway, the
Verify the upgrade Log in on the Admin Portal and check the information contained in the About > Version menu. Confirm that versions have upgraded.
|
|
|
|
|
Restore Schedules (Maintenance Window)¶
Description and Steps |
Notes and Status |
|---|---|
Re-enable scheduled imports if any were disabled prior to the upgrade. Two options are available: Individually for each job:
Mass modify:
Note Select the Skip next execution option if you do not wish to execute schedules overlapping the maintenance window, but only execute thereafter. Schedules enabled on the CLI of the primary application node:
|
Release Specific Updates (Maintenance Window)¶
Description and Steps |
Notes and Status |
|---|---|
When upgrading from CUCDM 11.5.3 Patch Bundle 2 or VOSS-4-UC 18.1 Patch Bundle 2 and earlier, re-import the following from all CUCM devices, since this upgrade deleted obsolete CUC timezone codes from the VOSS Automate database:
Note: This is a once off data migration step. If this was performed previously when upgrading to 19.1.x, then it does not have to be repeated. |
|
After upgrading, obtain and install the following patch according to its accompanying MOP file:
Note: This is a once off data migration step. If this was performed previously when upgrading to 19.1.x, then it does not have to be repeated. |
|
Re-import the following from all CUCM devices:
For steps to create a custom data sync, refer to the chapter on Data Sync in the Core Feature Guide. Note: This is a once off data migration step. If this was performed previously when upgrading to 19.1.x, then it does not have to be repeated. |
|
User Management migration updates default authentication types on SSO Identity Providers. If an SSO Identity Provider exists at the provider hierarchy level, the default authentication settings:
will not allow any non-SSO user logins (typically local administrators). The solution is to log in as higher level administrator account (full access) and set the SSO Identity Provider:
Please refer to the SSO Identity Provider: Field Reference topic in the Core Feature Guide. |
|
When upgrading to release 21.3, users of Microsoft apps should after upgrade, select each
Microsoft Tenant ( This step is required so that VOSS Automate can communicate with the Tenant post upgrade. |
Log Files and Error Checks (Maintenance Window)¶
Description and Steps |
Notes and Status |
|---|---|
Inspect the output of the command line interface for upgrade errors,
for example On the primary application node, use the log view command to view any log files indicated in the error messages, for example, run the command if the following message appears: For more information refer to the execution log file with
'log view platform/execute.log'
For example, if it is required send all the install log files in the
|
|
Log in on the Admin Portal as system level administrator, go to Administration Tools > Transaction and inspect the transactions list for errors. |