Back up NSP databases, system data

Log in as the root user or NSP admin user on the NSP deployer host.

Transfer the following file to a secure location on a separate station that is unaffected by the upgrade activity:

/opt/nsp/NSP-CN-DEP-release-ID/NSP-CN-release-ID/appliedConfigs/nspConfiguratorConfigs.zip

If you are upgrading a standalone NSP cluster, or the primary cluster in a DR deployment, perform “How do I back up the NSP cluster databases?” in the NSP System Administrator Guide for the installed release.

Note: The backup operation may take considerable time, during which you can start the software download described in Step 4.

Obtain installation software

Download the required software bundles from the NSP downloads page on the Nokia Support portal to a local station that is not affected by the upgrade activity:

Note: You must also download the .cksum file associated with each bundle file.

Note: The download takes considerable time, during which you can proceed to the next step.

Note: The file content may change between releases; check the file content and merge in any new content when you download files to create the NSP deployer host and NSP cluster VMs.

1. This step applies only when using an NSP OEM disk image.

   Download one of the following RHEL OS images for creating the NSP deployer host and NSP cluster VMs:

   • NSP_K8S_PLATFORM_RHEL9_yy_mm.qcow2

   • NSP_K8S_PLATFORM_RHEL9_yy_mm.ova

2. Download the following:

   • NSP_R_r-SPx.zip—bundle for installing patches in the service pack

   • NSP_DEPLOYER_R_r.tar.gz—base (GA) bundle for installing the NSP application software

3. If the NSP Kubernetes version recorded in Step 8 in Steps is not supported, check the service pack.

   See the documentation about the service pack.

   If the service pack does not include NSP_K8S_DEPLOYER, download the base bundle, for example, NSP_K8S_DEPLOYER_26_4.tar.gz.

4. Select the Public_GPG_Key bundle and download the nsp-signing-keys.zip and Public_GPG_Key.cksum files.

Record benchmarks such as system KPIs, equipment inventories, and service lists for verification after the upgrade.

It is strongly recommended that you verify the message digest of each NSP image file or software bundle that you download from the Nokia Support portal. The download page includes checksums for comparison with the output of the RHEL md5sum, sha256sum, or sha512sum command.

When the bundle downloads are complete, verify each file checksum.

1. Enter the following:

   # command file ↵

   where

   command is md5sum, sha256sum, or sha512sum

   file is the name of the file to check

   A file checksum is displayed.

2. Compare the checksum value and the value in the .cksum file.

3. If the values do not match, the file download has failed. Download a new copy of the file, and then repeat this step.

If the downloaded NSP_DEPLOYER_R_r.tar.gz file has multiple parts, enter the following to create one NSP_DEPLOYER_R_r.tar.gz file from the partial image files:

# cat filename.part* >filename.tar.gz ↵

where filename is the image file name

A filename.tar.gz file is created in the current directory.

Check current Kubernetes version

Record the current Kubernetes version.

1. Log in as the root user on the NSP cluster host.

2. Enter the following:

   # kubectl get nodes ↵

   NSP cluster node status information like the following is displayed:

   NAME        STATUS    ROLES                  AGE     VERSION

   node_name   status    control-plane,master   xxdnnh   version

3. Record the version value, which is the current Kubernetes version.

4. Compare the Kubernetes version with the supported versions for the NSP software release in the Host Environment Compatibility Guide for NSP and CLM.

   If your current version is not supported, the procedure directs to upgrade your Kubernetes version in a later step.

Prepare NFM-P migration to OAUTH2 user authentication

If your NSP deployment currently uses CAS user authentication, you must migrate to OAUTH2 authentication.

If your NSP deployment includes the NFM-P, edit NFM-P user accounts as required to prepare for importing the users to the NSP local user database. For example, remove duplicate user IDs, or assign e-mail addresses.

Note: For users whose user account includes an e-mail address, the import operation sends a new randomly generated temporary password. Users who lack an e-mail address are assigned a global temporary password.

Check and prepare NSP cluster

Perform the following steps to verify that the local NSP cluster is fully operational.

1. Log in as the root user on an NSP cluster member in the data center.

2. Enter the following to display the status of the NSP cluster nodes:

   # kubectl get nodes -A ↵

   The status of each cluster node is displayed.

   The NSP cluster is fully operational if the status of each node is Ready.

3. If any node is not in the Ready state, you must correct the condition; contact technical support for assistance, if required.

   Do not proceed to the next step until the issue is resolved.

4. Enter the following to display the NSP pod status:

   # kubectl get pods -A ↵

   The status of each pod is displayed.

   The NSP cluster is operational if the status of each pod is Running or Completed.

5. If any pod is not in the Running or Completed state, you must correct the condition; see the NSP Troubleshooting Guide for information about troubleshooting an errored pod.

Ensure that the RHEL chronyd time-synchronization service is running on each component, and that chronyd is actively tracking a central time source. See the RHEL documentation for information about using the chronyc command to view the chronyd synchronization status.

Note: NSP deployment is blocked if the chronyd service is not active.

End of steps