Prerequisites
Important |
During the migration process, do not make policy configuration changes, CRD table updates, or other system configuration changes. These type of changes should only be performed after the migration has been successfully completed and properly validated. |
Note |
During migration, the value of Session Limit Overload Protection under System configuration in Policy Builder can be set to 0 (default) which indefinitely accepts all the messages so that the traffic is not impacted but SNMP traps are raised. Once migration is complete, you must change the value as per the session capacity of the setup and publish it without restarting the Policy Server (QNS) process. For more information, contact your Cisco Account representative. |
Before beginning the migration:
-
Create a backup (snapshot/clone) of the Cluster Manager VM following the guidelines of the prior release. If errors occur during the migration process, this backup is required to successfully roll back the migration. For more information refer to CPS Backup and Restore Guide.
-
Back up any nonstandard customizations or modifications to system files. Only customizations which are made to the configuration files on the Cluster Manager are backed up. Refer to the CPS Installation Guide for VMware for an example of this customization procedure. Any customizations which are made directly to the CPS VMs must be reapplied manually after the migration is complete.
-
Remove /etc/broadhop/repositories files before starting the Cluster Manager migration.
Note
Before removing the repositories, contact your Cisco Technical Representative.
-
If necessary, upgrade the underlying hypervisor before performing the CPS in-service software migration. The steps to upgrade the hypervisor or troubleshoot any issues that may arise during the hypervisor upgrade is beyond the scope of this document. Refer to the CPS Installation Guide for VMware for a list of supported hypervisors for this CPS release.
Note
As CPS 24.1.0 supports ESXi 7.0 version until 7.0.3, make sure OVF tool version 4.3.0 is installed in CPS 23.1.0/CPS 23.2.0 from where you are migrating.
Version 4.3.0 for VMware 6.5/6.7/7.0: VMware-ovftool-4.3.0-13981069-lin.x86_64.bundle
https://code.vmware.com/web/tool/4.3.0/ovf
-
Verify that the Cluster Manager VM has at least 10 GB of free space. The Cluster Manager VM requires this space when it creates the backup archive at the beginning of the migration process.
-
Synchronize the Grafana information between the OAM (pcrfclient) VMs by running the following command from pcrfclient01:
/var/qps/bin/support/grafana_sync.sh
Also verify that the
/var/broadhop/.htpasswd
files are the same on pcrfclient01 and pcrfclient02 and copy the file from pcrfclient01 to pcrfclient02 if necessary.Refer to Copy Dashboards and Users to pcrfclient02 in the CPS Operations Guide for more information.
-
Check the health of the CPS cluster as described in Check the System Health.
-
The following logs must be enabled/set to debug before starting ISSM in logback.xml file.
<logger name="com.broadhop.utilities.zmq.upgrade.ZMQInServiceUpgradeMgr" level="debug"/>
Once ISSM is complete, remove the entry from logback.xml file.
-
The contents of logback.xml file are overwritten during an upgrade or a migration. Make sure to update the logback.xml file as per your requirements after an upgrade or a migration.
-
If you are using IPv6 address, make sure the address you are using is in uncompressed format before starting the migration.
For example,
IPv6 in uncompressed format: 2345:f170:8306:8118:e0:208:0:100
-
If you are using Balance feature and Recurring Quota templates in the Policy Builder with Recurrence Frequency as Bill Cycle (RFAmt ignored), refer to the Recurring Quota not Working section in the CPS Troubleshooting Guide.
-
Take the backup of the static route (i.e. route-ifname) and
route -n
collection files. -
To upgrade the mongoDB version to 5.0, you must upgrade to CPS version 24.1.0, which uses the mongoDB 5.0 version. For example, if you are running mongoDB 4.0 series in your CPS release, it is required to first upgrade to 4.2 and then to 4.4 before planning for any upgrade to 5.0.
Note
Any CPS version prior to CPS 23.1.0 such as CPS 22.1.1 (using mongoDB version 4.0.27) and previous versions of CPS (using mongoDB version 3.x) does not support direct upgrade to CPS 24.1.0 (using mongoDB version 5.0).
For more information, consult your Cisco Technical Representative.
Refer also to Rollback Considerations for more information about the process to restore a CPS cluster to the previous version if the migration is not successful.