Back up NSP databases, system data

Log in as the root 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: This step applies only when using an NSP OEM disk image.

1. If the NSP Kubernetes version recorded in Step 8 is not supported, download the following file, which is the bundle for upgrading the Kubernetes registry and deployment environment:

   NSP_K8S_DEPLOYER_R_r.tar.gz

   where

   R_r is the NSP release ID, in the form Major_minor

   yy_mm represents the year and month of issue

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

   • NSP_K8S_PLATFORM_RHEL8_yy_mm.qcow2

   • NSP_K8S_PLATFORM_RHEL8_yy_mm.ova

3. Download the following file, which is the bundle for installing the NSP application software:

   NSP_DEPLOYER_R_r.tar.gz

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.qcow2 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 Envirnoment 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.

Back up Elasticsearch log data

If log forwarding to Elasticsearch is not enabled in the NSP system, go to Step 23.

Starting in NSP Release 23.4, OpenSearch replaces Elasticsearch as the NSP log-viewing utility. If you are upgrading from an NSP release that uses Elasticsearch for viewing NSP logs, it is strongly recommended that you preserve the Elasticsearch log data collected by the NSP before you upgrade the NSP.

You can later restore the backed-up data for import by an Elasticsearch server in order to review the log data, if required, as described in “How do I restore the NSP Elasticsearch log data?” in the NSP System Administrator Guide.

Log in as the root user on the station that has the downloaded NSP_DEPLOYER_R_r.tar.gz file.

Navigate to the directory that contains the NSP_DEPLOYER_R_r.tar.gz file.

Enter the following:

# tar xvf NSP_DEPLOYER_R_r.tar.gz '*nsp-log-collector.zip' '*README.txt' ↵

The nsp-log-collector.zip file and a README.txt file are extracted to the following directory path below the current directory:

NSP-CN-DEP-release-ID/NSP-CN-release-ID/tools/support/logCollector

Note: The README.txt contains information about using the backup utility.

Log in as the root user on the NSP cluster host:

Open a console window.

Navigate to a directory that has sufficient free space for the backup log data, such as /opt.

Note: The space required for the log backup is based on the number of days for which log data is stored by the NSP, which is specified by the logRetentionPeriodInDaysOverride parameter value in the NSP cluster configuration file, and the average amount of log data per day.

Transfer the extracted nsp-log-collector.zip and README.txt files to the current directory.

In order to perform an ElasticSearch data backup, the java-1.8.0-openjdk RHEL OS package must be installed. However, the package may not be present on an earlier system.

Enter the following:

# yum -y install java-1.8.0-openjdk ↵

If the package is not installed, the yum utility installs the package. Otherwise, the utility indicates that the package is installed, and nothing is done.

Enter the following:

# unzip nsp-log-collector.zip ↵

The following files are created in an nsp-log-collector-release-ID/bin directory in the current directory:

• nsp-log-collector

• nsp-log-collector.bat

After the files are extracted, enter the following:

# cd nsp-log-collector-release-ID/bin ↵

Enter the following to back up all collected Elasticsearch log data:

# ./nsp-log-collector --getAll path ↵

where path is the local directory in which to store the backed-up log data

The following prompt is displayed:

Do you want to proceed with log collection? (y/n) :

Enter y.

The backup process begins.

The backup process creates the following .zip file in the specified path directory:

Logs-timestamp.zip

where timestamp is the backup creation date and fime

Transfer the Logs-timestamp.zip file for safekeeping to a secure location on a station that is not part of the NSP deployment.

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.

Identify the dedicated MDM nodes in the NSP cluster; you require the information for restoring the cluster configuration later in the procedure.

1. Log in as the root user on any NSP cluster node.

2. Open a console window.

3. Enter the following:

   # kubectl get nodes --show-labels ↵

4. Identify the dedicated MDM nodes, which have only the following label and no other NSP labels:

   mdm=true

   For example:

   /os=linux,mdm=true

5. Record the name of each dedicated MDM node.

End of steps