Unified Node Topology: Upgrade a Multinode Environment with the Delta Bundle¶
Note
While system upgrade takes approximately two hours at a single site, this may vary in accordance with your topology, number of devices and subscribers. Adjust your upgrade maintenance window to allow for your configuration.
The standard screen command should be used where indicated, and the reconnect parameter is available if needed:
screen - start a new session
screen -ls - show sessions already available
screen -r [screen PID] - reconnect to a disconnected session
We recommend using the screen
command to avoid failures if the connection is interrupted whilst
running the command. If the connection is interrupted whilst running
the command in screen then the session can be retrieved by first
listing the sessions PID currently running in screen:
screen -ls, and then reconnecting to the session using
screen -r [screen PID].
The version of screen used in VOSS Automate also supports the creation of a log file. If long-running commands will be run, the log file captures screen console output up to the session timeout. A message shows:
timed out waiting for input: auto-logout
To create a screen log file:
Run screen and wait for screen to open.
Press <Ctrl>-a then : (colon). This will enter screen command mode at the bottom of the console.
Create your screen logfile in the
media/directory:In screen command mode, type logfile media/<screen-logfilename>.log
Press <Enter>
Press <Ctrl>-a and then H to start writing to the log file
Run your commands.
If the screen session times out, you can obtain console output from the log file, for example:
$ sftp platform@<host>:media/<screen-logfilename>.log
Download Files and Check¶
Description and Steps |
Notes and Status |
|---|---|
VOSS files: https://voss.portalshape.com > Downloads > VOSS Automate > XXX > Upgrade Download Either using SFTP:
Or using SCP:
On the primary Unified node, verify that the
On the primary Unified node, verify that the original
|
Adaptations Check¶
Description and Steps |
Notes and Status |
|---|---|
Identify installed adaptations and determine any effect on the upgrade plan. If the release is accompanied by Upgrade Notes, refer to the details. |
Schedules, Transactions and Version Check¶
Description and Steps |
Notes and Status |
|---|---|
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 CLI:
|
|
Check for running imports. Either wait for them to complete or cancel them:
|
|
Customized ``data/Settings`` If The modifications can be re-applied or exported JSON instances can be merged following the upgrade. See: Post Template Upgrade Tasks. Version Record the current version information. This is required for upgrade troubleshooting.
|
Pre-Upgrade, Security and Health Steps¶
Description and Steps |
Notes and Status |
|---|---|
Verify that the primary 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
Validate the system health. On the Primary Unified Node, verify cluster connectivity:
On each node verify network connectivity, disk status and NTP.
If there is any sign of the paths below are over 80% full, a clean-up is needed to avoid risk of for example full logs occurring during upgrade. Clean-up steps are indicated next to the paths: / (call support if over 80%)
/var/log (run: log purge)
/opt/platform (remove any unnecessary files from /media directory)
/tmp (reboot)
On the Primary Unified Node, verify there are no pending Security Updates on any of the nodes:
|
|
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. VOSS cannot guarantee that a restore point can be used to successfully restore VOSS Automate. If you cannot restore the application from a restore point, your only recourse is to reinstall the application. Optional: If a backup is also required, 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 |
|---|---|
Before upgrading, check all services, nodes and weights for the cluster: Make sure no services are stopped/broken. The message ‘suspended waiting for mongo’ is normal on the fresh unified nodes.
Make sure all application nodes show 3 or 5 nodes.
Check that the database weights are set. It is critical to ensure the weights are set before upgrading a cluster.
Example output: 172.29.21.240:
weight: 80
172.29.21.241:
weight: 70
172.29.21.243:
weight: 60
172.29.21.244:
weight: 50
Verify the primary node in the primary site and ensure no nodes are in the
‘recovering’ state (
|
Upgrade¶
Description and Steps |
Notes and Status |
|---|---|
On the primary unified node:
Run (optionally with command parameters below):
The upgrade will also silently run an updated version of cluster check and the upgrade will fail to proceed if any error conditions exist. Fix before proceeding. Refer to the Platform Guide for details on the new version of the cluster check command. Run:
and verify the number of nodes are uneven, i.e. either 5 or 7.
If not, run: cluster provision role database and ensure an arbitrator shows
when you run database config again ( From release 19.1.2 and later, the Note that during the upgrade, phone registration data is cleared. A message will
show in the log: |
Post-Upgrade, Security and Health Steps¶
Description and Steps |
Notes and Status |
|---|---|
On the primary unified node, verify the cluster status:
|
|
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. |
|
Check for needed security updates. On the primary node, run:
If one or more updates are required for any node, run on the primary Unified 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. |
Post Template Upgrade Tasks¶
Description and Steps |
Notes and Status |
|---|---|
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 GUI and check the information contained in the About > Extended Version menu. Confirm that versions have upgraded:
If your web browser cannot open the user interface, clear your browser cache before trying to open the interface again. |
|
|
Restore Adaptations¶
Description and Steps |
Notes and Status |
|---|---|
Restore and adaptations prior to upgrade. If the release is accompanied by Upgrade Notes, refer to the details on adaptation impact. |
Restore Schedules¶
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 if you do not wish to execute schedules overlapping the maintenance window, but only execute thereafter. Schedules enabled on the CLI:
|
For overlapping schedules, disable. Run schedule disable <job-name>.
Log Files and Error Checks¶
Description and Steps |
Notes and Status |
|---|---|
Inspect the output of the command line interface for upgrade errors. 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 GUI as system level administrator, go to Administration Tools > Transaction and inspect the transactions list for errors. |