Upgrading from Release 22.6 or earlier

NSP system upgrade process

CAUTION

Service Disruption

An NSP system upgrade requires a thorough understanding of NSP system administration and platform requirements, and is supported only under the conditions described in this guide, the NSP Planning Guide, and the NSP Release Notice.

Such an operation must be planned, documented, and tested in advance on a trial system that is representative of the target live network. Contact NSP professional services to assess the requirements of your NSP deployment, and for information about the upgrade service, which you are strongly recommended to engage for any type of deployment.

The following workflows provide comprehensive overviews of the required upgrade activities for advance planning purposes:

Each workflow includes links to the required procedures and procedure sections for completing the upgrade.

Note: An NSP system that manages a large number of NEs may require several hours, or potentially a full day for a very large network, to resynchronize the network following an NSP upgrade. It is important to consider the resynchronization time when planning a maintenance window for NSP upgrade activity.

Note: Before you attempt an NSP upgrade, ensure that any third-party software installed on the NSP deployer host or any NSP cluster VM is disabled and stopped.

Licensing

Your NSP system may require a new or updated license, depending on your deployment and the NSP release from which you upgrade. It is recommended that you contact Nokia early in the planning process to obtain the required license for your upgraded deployment.

Migrating to RHEL 8

An NSP system upgrade from Release 22.6 or earlier involves a migration to version 8 of the RHEL OS on each NSP station, so is essentially a platform migration. If new stations are not to be used, the existing stations must be decommissioned and then recommissioned.

DR NSP system upgrade

In order to minimize the network visibility loss during a DR system upgrade, the primary NSP cluster remains active while a new standby cluster is deployed.

After a system database backup from the primary cluster is restored on the standby, the primary cluster is stopped, and the standby cluster is activated as a primary cluster. The former primary cluster is then upgraded, and subsequently assumes the standby role.

The loss of network visibility begins when the initial primary cluster is stopped, and ends when the NSP software initialization on the new primary cluster completes.