This page describes steps required to prepare for a major upgrade from 4.1.
They can be performed before the upgrade, outside of a maintenance window. However, the prerequisites might reveal the need for additional maintenance windows, so confirm the prerequisites prior to making a detailed upgrade plan.
We recommend that you upgrade to the latest available minor release of RVT 4.2. |
1. Check prerequisites
1.1. Preparation steps
Before starting the upgrade, check the following:
-
All RVT nodes need to be on version at least 4.1-3-1.0.0. If not, perform an upgrade of the RVT nodes to the latest available version of RVT 4.1 first. This requires you to plan a separate maintenance window before starting the upgrade to RVT 4.2.
-
The TSN nodes need to be running Cassandra 4.1 container. If they are running Cassandra 3.11 container, then perform a Cassandra Switch procedure to Cassandra 4.1 first.
-
You have deployed a SIMPL VM, version 6.15.3 or later. Output shown in this document is correct for version 6.15.3 of the SIMPL VM; it may differ slightly on later versions.
If it is still on a lower version, upgrade it as per the SIMPL VM Documentation. SIMPL VM upgrades are out of scope for this document.
-
You have deployed a MDM VM version 3.8.0 or later.
If it is still on a lower version, refer to MDM Upgrade to upgrade it.
-
Confirm all other node types are running compatible software versions (MDM etc).
-
You have access to the SSH keys used to access the SIMPL VM.
-
You have access to the SIMPL and MDM documentation.
1.2. VM health checks
Before starting the upgrade, check the health of the VMs.
Any unhealthy VMs should be fixed before proceeding with the upgrade. Failure to do so will likely cause the upgrade to fail. |
-
Follow the VNF validation checks and tests here for each RVT node type.
-
Confirm that MDM and SIMPL are currently healthy. Refer to each product’s set of documentation for instructions on checking node health.
-
Additionally, confirm the certificates for MDM are valid, and will not expire before the upgrade.
-
1.3. Prepare SIMon for upgrade
If you use SIMon to monitor your system health, then get the latest VoLTE Solution Bundle from your Customer Care Representative and follow this document to prepare your SIMon for the upgrade: Managing SIMon configuration files when upgrading VoLTE Solution components.
If you do not use SIMon to monitor system health then please consider integrating this into your deployment by following this doc: Integrating RVT 4.1+ with SIMon - MOP. It is not an upgrade requirement to have SIMon integration, but it is recommended for monitoring and alarming purposes.
2. Upload uplevel CSARs
Your Customer Care Representative will have provided you with the uplevel TSN, MAG, ShCM, MMT GSM, and SMO CSARs.
Use scp
to copy these to /csar-volume/csar/
on the SIMPL VM.
Once the copy is complete, for each CSAR, run csar unpack /csar-volume/csar/<filename>
on the SIMPL VM
(replacing <filename>
with the filename of the CSAR, which will end with .zip
).
The csar unpack
command may fail if there is insufficient disk space available.
If this occurs, SIMPL VM will report this with instructions
to remove some CSARs to free up disk space.
You can list all unpacked CSARs with csar list
and remove a CSAR with csar remove <node type>/<version>
.
3. Update the configuration files for RVT 4.2
3.1. Prepare the downlevel config directory
If you keep the configuration hosted on the SIMPL VM,
then the existing config should already be located in /home/admin/current-config
(your configuration folder may have a different name, as the folder name is not policed e.g. yours may be named rvt-config
, if this is the case then rename it to current-config
).
Verify this is the case by running ls /home/admin/current-config
and checking that the directory contains:
-
The Rhino license.
-
The current SDF for the deployment (in the format used by SIMPL 6.13). This is the SDF titled 'sdf-rvt.yaml' which you will previously have used to manage the RVT 4.2 VMs.
-
Any certificates and private key files for REM, BSF, and/or XCAP:
<type>-cert.crt
and<type>-cert.key
, where<type>
is one ofrem
,bsf
, orxcap
.
If it isn’t, or you prefer to keep your configuration outside of the SIMPL VM, then create this directory on the SIMPL VM:
mkdir /home/admin/current-config
Use scp
to upload the files described above to this directory.
3.2. Create directories for RVT 4.2 configuration and for rollbacks
To create the directory for holding the uplevel configuration files, on the SIMPL VM, run:
mkdir /home/admin/uplevel-config
Then run
cp /home/admin/current-config/* /home/admin/uplevel-config
to copy the configuration, which you will edit in place in the steps below.
At this point you should have the following directories on the SIMPL VM:
|
3.3. Make product-specific changes to the SDF for RVT 4.2
Open the /home/admin/uplevel-config/sdf-rvt.yaml
file using vi
.
Find the vnfcs
section, and within that every RVT VNFC (tsn
, mag
, shcm
, mmt-gsm
, or smo
).
For each of them, make changes as follows :
-
Update the VM versions for all the VM types (
tsn
,mag
,shcm
,mmt-gsm
, orsmo
). Find thevnfcs
section, and within each VNFC, locate theversion
field and change its value to the uplevel version, for example4.2-8-1.0.0
.
type: mag
- version: 4.1-7-1.0.0
+ version: 4.2-8-1.0.0
vim-configuration:
Save and close the file.
3.4. Identify if any RVT nodes are misordered
Inside /home/admin/uplevel-config
, check the files mag-vmpool-config.yaml
, mmt-gsm-vmpool-config.yaml
and smo-vmpool-config.yaml
.
Within each of these files, confirm that the first occurrence of rhino-node-id: xxx
is set to the smallest value of all occurrences of rhino-node-id: yyy
in that particular file.
If not, contact your Customer Care Representative to adjust the upgrade steps in this MOP.
4. Validate the new configuration
4.1. Validate the configuration
We now check that the uplevel configuration files are correctly formatted, contain valid values, and are self-consistent.
For each node type tsn
, mag
, shcm
, mmt-gsm
, or smo
,
run the command /home/admin/.local/share/csar/<node type>/<uplevel version>/resources/rvtconfig validate -t <node type> -i /home/admin/uplevel-config
For example …
/home/admin/.local/share/csar/mag/4.2-X-1.0.0/resources/rvtconfig validate -t mag -i /home/admin/uplevel-config
A successful validation with no errors or warnings produces the following output.
Validating node type against the schema: <node type>
YAML for node type(s) ['<node type>'] validates against the schema
If the output contains validation errors,
fix the configuration in the /home/admin/uplevel-config
directory
and refer to the previous steps to fix the issues.
If the output contains validation warnings, consider whether you wish to address them before performing the upgrade. The VMs will accept configuration that has validation warnings, but certain functions may not work.
4.2. Carry out a csar update dry run
The csar update dry run command carries out more extensive validation of the SDF and VM states than rvtconfig validate does.
Carrying out this step now, before the upgrades are due to take place, ensures problems with the SDF files are identified early and can be rectified beforehand.
The --dry-run operation will not make any changes to your VMs, it is safe to run at any time, although we always recommend running it during a maintenance window if possible. |
The major upgrade from 4.1 to 4.2 version does not support csar udpate for SMO node, so it is not passed to the list of nodes under the --vnf parameter. |
Please run the following command (replacing mmt-gsm with mmt-cdma if your deployment uses CDMA) to execute the dry run.
csar update --sdf /home/admin/uplevel-config/sdf-rvt.yaml --vnf shcm,tsn,mmt-gsm,mag --sites <site name> --skip force-in-series-update-with-l3-permission --dry-run
Confirm the output does not flag any problems or errors. The end of the command output should look similar to this.
You are about to update VMs as follows:
- VNF shcm:
- For site grsite1:
- update all VMs in VNFC service group gr1-shcm/4.1-7-1.0.0:
- gr1-shcm-1 (index 0)
- gr1-shcm-2 (index 1)
- VNF tsn:
- For site grsite1:
- update all VMs in VNFC service group gr1-tsn/4.1-7-1.0.0:
- gr1-tsn-1 (index 0)
- gr1-tsn-2 (index 1)
- gr1-tsn-3 (index 2)
- VNF mmt-gsm:
- For site grsite1:
- update all VMs in VNFC service group gr1-mmt-gsm/4.1-7-1.0.0:
- gr1-mmt-1 (index 0)
- gr1-mmt-2 (index 1)
- gr1-mmt-3 (index 2)
- VNF mag:
- For site grsite1:
- update all VMs in VNFC service group gr1-mag/4.1-7-1.0.0:
- gr1-mag-1 (index 0)
- gr1-mag-2 (index 1)
- gr1-mag-3 (index 2)
Please confirm the set of nodes you are upgrading looks correct, and that the software version against each service group correctly indicates the software version you are planning to upgrade to.
If you see any errors, please address them, then re-run the dry run command until it indicates success.