Back up NSP deployer host configuration files

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

Open a console window.

Back up the following NSP Kubernetes registry certificate files:

Note: The files are in the /opt/nsp/nsp-registry/tls directory from Release 22.11 or later.

• nokia-nsp-registry.crt

• nokia-nsp-registry.key

Back up the following Kubernetes deployer configuration file:

/opt/nsp/nsp-k8s-deployer-old-release-ID/config/k8s-deployer.yml

Back up the following NSP deployer configuration file:

/opt/nsp/NSP-CN-DEP-old-release-ID/config/nsp-deployer.yml

Back up the Kubernetes secrets.

1. Enter the following on the NSP deployer host:

   # cd /opt/nsp/NSP-CN-DEP-old-release-ID/bin/ ↵

2. Enter the following:

   # ./nspdeployerctl secret -o backup_file backup ↵

   where backup_file is the absolute path and name of the backup file to create

   As the secrets are backed up, messages like the following are displayed for each Kubernetes namespace:

   Backing up secrets to /opt/backupfile...

     Including secret namespace:ca-key-pair-external

     Including secret namespace:ca-key-pair-internal

     Including secret namespace:nsp-tls-store-pass

   When the backup is complete, the following prompt is displayed:

   Please provide an encryption password for backup_file

   enter aes-256-ctr encryption password:

3. Enter a password.

   The following prompt is displayed:

   Verifying - enter aes-256-ctr encryption password:

4. Re-enter the password.

   The backup file is encrypted using the password.

5. Record the password for use when restoring the backup.

6. Record the name of the data center associated with the backup.

7. Transfer the backup file to a secure location in a separate facility for safekeeping.

Copy the files backed up in Step 3, Step 4, Step 5, and Step 6, and to a separate station outside the NSP cluster for safekeeping.

Disable SELinux enforcing mode

If SELinux enforcing mode is enabled on the NSP deployer host and NSP cluster members, you must switch to permissive mode on each; otherwise, you can skip this step.

Perform “How do I switch between SELinux modes on NSP system components?” in the NSP System Administrator Guide on the NSP deployer host and on each NSP cluster member.

Note: If SELinux enforcing mode is enabled on any NSP component during the upgrade, the upgrade fails.

Apply OS update to NSP deployer host

If the NSP deployer host is deployed in a VM created using an NSP RHEL OS disk image, perform To apply a RHEL update to an NSP image-based OS.

If your Kubernetes version is supported, as determined in To prepare for an NSP system upgrade from Release 25.11 or later, you do not need to upgrade Kubernetes; go to Step 47.

Prepare for Kubernetes upgrade

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

If you performed Step 4, substep c in Steps, perform Step 14 to Step 17.

If you did not perform Step 4, substep c in Steps, perform Step 18 to Step 22.

Copy the downloaded NSP_K8S_DEPLOYER_R_r.tar.gz bundle file to the following directory:

/opt/nsp

Enter the following:

# cd /opt/nsp ↵

Enter the following:

# tar xvf NSP_K8S_DEPLOYER_R_r.tar.gz ↵

where R_r is the NSP release ID, in the form Major_minor

The bundle file is expanded, and the following directories are created:

• /opt/nsp/nsp-k8s-deployer-release-ID

• /opt/nsp/nsp-registry-release-ID

Remove the bundle file to save disk space; enter the following:

# rm -f NSP_K8S_DEPLOYER_R_r.tar.gz ↵

The file is deleted.

Then go to Step 23.

Copy the downloaded NSP_R_r-SPx.tar.gz bundle file to the following directory:

/opt/nsp

R_r is the NSP release ID, in the form Major_minor

x is the latest service pack release

Enter the following:

# cd /opt/nsp ↵

Enter the following:

# tar xvf NSP_R_r-SPx.tar.gz ↵

where R_r-SPx is the NSP service pack ID, in the form Major_minor-SPx

The bundle file is expanded, and the following directories are created in /opt/nsp/patch/R_r_SPx/, for example, /opt/nsp/patch/26_4_SP1/

Enter the following:

# rm -f NSP_R_r-SPx.tar.gz ↵

where R_r-SPx is the NSP service pack ID, in the form Major_minor-SPx

The bundle is deleted.

Enter the following:

# tar xvf patch/R_r_SPx/roles/nsp/files/NSP_DEPLOYER_R_r-SPx.tar.gz ↵

where R_r-SPx is the NSP service pack ID, in the form Major_minor-SPx

The bundle file is expanded, and the following directories are created:

• /opt/nsp/nsp-k8s-deployer-release-ID

• /opt/nsp/nsp-registry-release-ID

Upgrade Kubernetes registry

You must uninstall the Kubernetes registry in one of the following scenarios:

• If you are not upgrading Kubernetes registry from the immediately previous version supported by the NSP, but from an earlier version

• If the system was previously installed by the root user and you want to upgrade as the NSP admin user

Otherwise, you can skip this step.

Enter the following to uninstall the Kubernetes registry:

# cd /opt/nsp/nsp-registry-old-release-ID/bin ↵

# ./nspregistryctl uninstall ↵

The NSP Kubernetes registry is uninstalled.

Note: During the registry upgrade, the registry will be temporarily unavailable. During such a period, an NSP pod that restarts on a new cluster node, or a pod that starts, is in the ImagePullBackOff state until the registry upgrade completes. Any such pods recover automatically after the upgrade, and no user intervention is required.

Enter the following:

# cd /opt/nsp/nsp-registry-new-release-ID/bin ↵

Enter the following to begin the registry upgrade:

# ./nspregistryctl install ↵

When the registry upgrade is complete, verify the upgrade.

1. Enter the following:

   # kubectl get nodes ↵

   NSP deployer node status information like the following is displayed:

   NAME        STATUS    ROLES                  AGE     VERSION

   node_name   status    control-plane,master   xxdnnh   version

2. Verify that status is Ready; do not proceed to the next step otherwise.

3. Enter the following periodically to monitor the NSP cluster initialization:

   # kubectl get pods -A ↵

   The status of each pod is displayed.

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

4. If any pod fails to enter the Running or Completed state, correct the condition; see the NSP Troubleshooting Guide for information about troubleshooting an errored pod.

If you performed Step 23, perform Step 28 to Step 31.

Otherwise, go to Step 32.

Enter the following to import the original NSP images.

# /opt/nsp/NSP-CN-DEP-old_base_load/bin/nspdeployerctl import ↵

where old_base_load is the original deployed version of the installed NSP release

Note: Step 28 to Step 31 are necessary for Step 85 or Step 91 to complete successfully.

If you have applied any NSP service pack since the original deployment of the installed NSP release, you must import the NSP images from the latest service pack you applied.

Enter the following to import the NSP images from the latest service pack.

# /opt/nsp/NSP-CN-DEP-old_latest_load/bin/nspdeployerctl import ↵

where old_latest_load is the version of the latest NSP service pack for the old_base_load that you applied

Enter the following:

# cd /opt/nsp/nsp-k8s-deployer-old_release-ID/bin ↵

Enter the following to push the registries TLS certificate to each NSP cluster member:

# ./nspk8sctl update -r ↵

The update is performed, and the containerd service restarts.

Configure Kubernetes deployer

You must merge the current k8s-deployer.yml settings into the new k8s-deployer.yml file.

Open the following files using a plain-text editor such as vi:

• old configuration file—/opt/nsp/nsp-k8s-deployer-old-release-ID/config/k8s-deployer.yml

• new configuration file—/opt/nsp/nsp-k8s-deployer-new-release-ID/config/k8s-deployer.yml

Apply the settings in the old file to the same parameters in the new file.

Close the old k8s-deployer.yml file.

Edit the following line in the cluster section of the new file to read:

  hosts: "/opt/nsp/nsp-k8s-deployer-new-release-ID/config/hosts.yml"

If you have disabled remote root access to the NSP cluster VMs,configure the following parameters in the cluster section, sshAccess subsection:

  sshAccess:

    userName: "user"

    privateKey: "path"

where

user is the designated NSP ansible user

path is the SSH key path for the NSP admin user, for example, /home/NSP admin user/.ssh/id_rsa

Configure the following parameters for each NSP cluster VM; see the descriptive text at the head of the file for parameter information, and Hostname configuration requirements for general configuration information.

- nodeName: node_name

  nodeIp: private_IP_address

  nodeIpv6: private_IPv6_address

  accessIp: public_IP_address

  isIngress: value

where

node_name is the VM name

private_IP_address is the VM IP address. All nodeIp addresses need to be in the same subnet.  If no accessIp is specified, this needs to be reachable from the deployer host.

private_IPv6_address is the optional VM IPv6 address on the environment; in a NAT environment, this is the private IPv6 address.

public_IP_address is the optional public IP address corresponding to the private_IP_address in a NAT environment. It defaults to the nodeIP if not specified. This should be reachable from the deployer node.

value is true or false, and indicates whether the node acts as a load-balancer endpoint

In the following section, specify the virtual IP addresses for the NSP to use as the internal load-balancer endpoints.

Note: A single-node NSP cluster requires at least the client_IP address.

The addresses are the virtualIP values for NSP client, internal, and mediation access that you specify in Step 63 and Step 64 in the nsp-config.yml file.

loadBalancerExternalIps:

    - client_IP

    - internal_IP

    - mediation_IP

    - trapV4_mediation_IP

    - trapV6_mediation_IP

    - flowV4_mediation_IP

    - flowV6_mediation_IP

Configure the following parameter, which specifies whether dual-stack NE management is enabled:

Note: Dual-stack NE management can function only when the network environment is appropriately configured, for example:

• Only valid, non-link-local static or DHCPv6-assigned addresses are used.

• A physical or virtual IPv6 subnet is configured for IPv6 communication with the NEs.

  enableIpv6Stack: value

where value must be set to true if the cluster VMs support both IPv4 and IPv6 addressing

Note: Each cluster VM must have a hosts.nodeIpv6 value defined in k8s-deployer.yml, or a default IPv6 route must be defined on all of the cluster VMs.

Configure the following parameters for artifact import configuration:

  imageSignatureVerificationFile: "image_path"

where

image_path is the absolute path to a file in PEM format containing the certificates that are to be used to verify the signature of images imported into the NSP registry

The certificate is in the nsp-signing-keys.zip bundle that you downloaded in Obtain installation software.

To extract the contents, enter the following:

# unzip nsp-signing-keys.zip ↵

The contents are extracted to the current directory.

They contain Nokia_Root_Certificate.crt that is used as the value for imageSignatureVerificationFile.

Save and close the new k8s-deployer.yml file.

Enter the following on the NSP deployer host:

# cd /opt/nsp/nsp-k8s-deployer-new-release-ID/bin ↵

Enter the following to create the new hosts.yml file:

# ./nspk8sctl config -c ↵

Enter the following to list the node entries in the new hosts.yml file:

# ./nspk8sctl config -l ↵

Output like the following example for a four-node cluster is displayed:

Note: If NAT is used in the cluster:

• The ip value is the private IP address of the cluster node.

• The access_ip value is the public address of the cluster node.

Otherwise:

• The ip value is the private IP address of the cluster node.

• The access_ip value matches the ip value.

Note: The ansible_host value must match the access_ip value.

Existing cluster hosts configuration is:

node_1_name:

  ansible_host: 203.0.113.11

  ip: private_IP

  access_ip: public_IP

  node_labels:

    isIngress: "true"

node_2_name:

  ansible_host: 203.0.113.12

  ip: private_IP

  access_ip: public_IP

  node_labels:

    isIngress: "true"

node_3_name:

  ansible_host: 203.0.113.13

  ip: private_IP

  access_ip: public_IP

  node_labels:

    isIngress: "true"

node_4_name:

  ansible_host: 203.0.113.14

  ip: private_IP

  access_ip: public_IP

  node_labels:

    isIngress: "false"

Verify the IP addresses.

Enter the following to import the Kubernetes images to the repository:

# ./nspk8sctl import ↵

Restore NSP system files

Transfer the following downloaded file to the /opt/nsp directory on the NSP deployer host:

NSP_DEPLOYER_R_r.tar.gz

Enter the following on the NSP deployer host:

# cd /opt/nsp ↵

if you performed Step 4, substep c in Steps, perform Step 18 to Step 21 in Steps.

Enter the following:

# tar xvf patch/R_r_SPx/roles/nsp/files/NSP_DEPLOYER_R_r-SPx.tar.gz ↵

where R_r-SPx is the NSP service pack ID, in the form Major_minor-SPx

The bundle file is expanded, and the following directory is created:

/opt/nsp/NSP-CN-DEP-release-ID/NSP-CN-release-ID

Enter the following:

# tar xvf NSP_DEPLOYER_R_r.tar.gz ↵

The bundle file is expanded, and the following directory of NSP installation files is created:

/opt/nsp/NSP-CN-DEP-new-release-ID/NSP-CN-new-release-ID

Enter the following:

# rm -f NSP_DEPLOYER_R_r.tar.gz ↵

The bundle file is deleted.

Restore the required NSP configuration files.

1. Enter the following:

   # mkdir /tmp/appliedConfig ↵

2. Enter the following:

   # cd /tmp/appliedConfig ↵

3. Transfer the following configuration backup file saved in To prepare for an NSP system upgrade from Release 25.11 or later to the /tmp/appliedConfig directory:

   nspConfiguratorConfigs.zip

4. Enter the following:

   # unzip nspConfiguratorConfigs.zip ↵

   The configuration files are extracted to the current directory, and include some or all of the following, depending on the previous deployment:

   • license file

   • nsp-config.yml file

   • TLS files; may include subdirectories

   • SSH key files

   • nsp-configurator/generated directory content

Open the following file using a plain-text editor such as vi:

/opt/nsp/NSP-CN-DEP-new_latest_load/config/nsp-deployer.yml

Update hosts attributes.

If you have disabled remote root access to the NSP cluster VMs, configure the following parameters in the cluster section, sshAccess subsection:

  sshAccess:

    userName: "user"

    privateKey: "path"

where

user is the designated NSP ansible user

path is the SSH key path for the NSP admin user, for example, /home/NSP admin user/.ssh/id_rsa

In the Artifact import configuration section, configure the following parameters:

  imageSignatureVerificationFile: "/image_path/Nokia_Root_Certificate.crt"

  chartSignatureVerificationFile: "/chart_path/nokia_helm_public_keyring.gpg" 

where

image_path is the absolute path to a file in PEM format containing the certificates that are to be used to verify the signature of images imported into the NSP registry

chart_path is the absolute path to a GNU Privacy Guard (GPG) file that is to be used to verify the provenance of charts imported into the NSP registry

The certificate is in the nsp-signing-keys.zip bundle that you downloaded in Obtain installation software.

To extract the contents, enter the following:

# unzip nsp-signing-keys.zip ↵

The contents are extracted to the current directory.

The contents contain Nokia_Root_Certificate.crt and  nokia_helm_public_keyring.gpg that are used as the values for the imageSignatureVerificationFile and chartSignatureVerificationFile parameters.

Save and close the new nsp-deployer.yml file.

Enter the following:

# ln -f NSP-CN-DEP-new_latest_load/config/nsp-deployer.yml NSP-CN-DEP-new_base_load/config/nsp-deployer.yml ↵

Enter the following to import the NSP images and Helm charts for both the new_latest_load and new_base_load to the NSP Kubernetes registry:

Note: The import operation for each may take 20 minutes or longer.

# /opt/nsp/NSP-CN-DEP-new_latest_load/bin/nspdeployerctl import ↵

# /opt/nsp/NSP-CN-DEP-new_base_load/bin/nspdeployerctl import ↵

Configure NSP software

You must merge the nsp-config.yml file content from the existing deployment into the new nsp-config.yml file.

Open the following files using a plain-text editor such as vi:

• old configuration file—/opt/nsp/NSP-CN-DEP-old_latest_load/NSP-CN-*/config/nsp-config.yml

• new configuration file—/opt/nsp/NSP-CN-DEP-new_latest_load/NSP-CN-*/config/nsp-config.yml

Note: See nsp-config.yml file format for configuration information.

Copy each configured parameter line from the previous nsp-config.yml file and use the line to overwrite the same line in the new file, if applicable. The following parameters are not present in the new nsp-config.yml file, and are not to be merged:

Note: The peer_address value that you specify must match the advertisedAddress value in the configuration of the peer cluster and have the same format; if one value is a hostname, the other must also be a hostname.

• platform section—address configuration now in ingressApplications section

  • advertisedAddress

  • mediationAdvertisedAddress

  • mediationAdvertisedAddressIpv6

  • internalAdvertisedAddress

• elb section—all parameters; section removed

• tls section—information now held in secrets:

  • truststorePass

  • keystorePass

  • customKey

  • customCert

• mtls section—information now held in secrets:

  • mtlsCACert

  • mtlsClientCert

  • mtlsKey

• sso section—parameters moved to Users and System Security in the NSP UI

  • authMode (obsolete)

  • sessionIdleTimeout

  • accessTokenLifespan

  • ldap subsection

  • radius subsection

  • tacacs subsection

Note: You must maintain the structure of the new file, as any new configuration options for the new release must remain.

Note: You must replace each configuration line entirely, and must preserve the leading spaces in each line.

Note: If NSP application-log forwarding to NSP Elasticsearch is enabled, special configuration is required.

• OpenSearch replaces Elasticsearch as the local log-viewing utility. Consequently, the Elasticsearch configuration cannot be directly copied from the current NSP configuration to the new configuration. Instead, you must configure the parameters in the logging—forwarding—applicationLogs—opensearch section of the new NSP configuration file.

• Elasticsearch is introduced as a remote log-forwarding option. You can enable NSP application-log forwarding to a remote Elasticsearch server in the logging—forwarding—applicationLogs—elasticsearch section of the new NSP configuration file.

  See Centralized logging for more information about configuring NSP logging options.

Note: In a DR deployment, if you use a hostname as the advertisedAddress for DC A, ensure that same hostname is used as the advertisedAddress for DC B. This also applies to using IP addresses for the advertisedAddress for DC A and DC B.

Configure the following parameter in the platform section as shown below:

Note: You must preserve the lead spacing of the line.

  clusterHost: "cluster_host_address"

where cluster_host_address is the address of NSP cluster member node1, which is subsequently used for cluster management operations

You must apply the address values from the former configuration file to the new parameters.

Configure the following parameters in the platform section, ingressApplications subsection as shown below.

Each address is an address from the ingressApplications section of the k8s-deployer.yml file described in Step 38.

Note: The client_IP value is mandatory; the address is used for interfaces that remain unconfigured, such as in a single-interface deployment.

Note: If the client network uses IPv6, you must specify the NSP cluster hostname as the client_public_address.

Note: The trapForwarder addresses that you specify must differ from the client_IP value, even in a single-interface deployment.

  ingressApplications:

    ingressController:

      clientAddresses:

        virtualIp: "client_IP"

        advertised: "client_public_address"

      internalAddresses:

        virtualIp: "internal_IP"

        advertised: "internal_public_address"

      mediationAddresses:

        virtualIp: "mediation_IP"

        advertised: "mediation_public_address"

    trapForwarder:

      mediationAddresses:

        virtualIpV4: "trapV4_mediation_IP"

        advertisedV4: "trapV4_mediation_public_address"

        virtualIpV6: "trapV6_mediation_IP"

        advertisedV6: "trapV6_mediation_public_address"

where

client_IP is the address for external client access

internal_IP is the address for internal communication

mediation_IP is the address for network mediation

trapV4_mediation_IP is the address for IPv4 network mediation

trapV6_mediation_IP is the address for IPv6 network mediation

each public_address value is an optional address to advertise instead of the associated _IP value, for example, in a NAT environment

If flow collection is enabled, configure the following parameters in the platform section, ingressApplications subsection as shown below:

    flowForwarder:

      mediationAddresses:

        virtualIpV4: "flowV4_mediation_IP"

        advertisedV4: "flowV4_mediation_public_address"

        virtualIpV6: "flowV6_mediation_IP"

        advertisedV6: "flowV6_mediation_public_address"

where

flowV4_mediation_IP is the address for IPv4 flow collection

flowV6_mediation_IP is the address for IPv6 flow collection

each _public_address value is an optional address to advertise instead of the associated mediation_IP value, for example, in a NAT environment

If you are using your own storage, perform the following steps:

1. Create Kubernetes storage classes.

   The following are examples of storage configurations. For different storage types, see the appropriate storage documentation.

   • See NFS storage configuration for NFS storage class configuration information.

   • See Ceph storage configuration for Ceph storage class configuration information.

   You can also create your own storage classes.

2. Enter the following command to get the storage class names created above:

   # kubectl get sc

   NAME      PROVISIONER                    RECLAIMPOLICY  VOLUMEBINDINGMODE  ALLOWVOLUMEEXPANSION  AGE

   ceph-rbd  rook-ceph.rbd.csi.ceph.com     Delete         Immediate          true                  14d

   cephfs    rook-ceph.cephfs.csi.ceph.com  Delete         Immediate          true                  14d

3. Configure the following parameters in the platform section, kubernetes subsection as shown below:

     storage:

       readWriteOnceLowIOPSClass: "storage_class"

       readWriteOnceHighIOPSClass: "storage_class"

       readWriteOnceClassForDatabases: "storage_class"

       readWriteManyLowIOPSClass: "storage_class"

       readWriteManyHighIOPSClass: "storage_class"

   where

   readWriteOnceLowIOPSClass—for enabling ReadWriteOnce operations and maintaining storage IOPS below 10,000

   readWriteOnceHighIOPSClass—for enabling ReadWriteOnce operations and maintaining storage IOPS above 10,000

   readWriteOnceClassForDatabases—for enabling ReadWriteOnce operations and maintaining storage IOPS below 10,000 for NSP databases

   readWriteManyLowIOPSClass—for enabling ReadWriteMany operations and maintaining storage IOPS below 10,000

   readWriteManyHighIOPSClass—for enabling ReadWriteMany operations and maintaining storage IOPS above10,000

   storage_class is your storage class name

Note: If you are using local or shared storage, the default storage values are used in nsp-config.yml; for example:

  storage:

    readWriteOnceLowIOPSClass: ""

    readWriteOnceHighIOPSClass: ""

    readWriteOnceClassForDatabases: ""

    readWriteManyLowIOPSClass: ""

    readWriteManyHighIOPSClass: ""

Configure the type parameter in the deployment section as shown below:

deployment:

    type: "deployment_type"

where deployment_type is the deployment type provided in your Platform Sizing Response.

If the NSP system currently performs model-driven telemetry or classic telemetry statistics collection, perform the following steps.

1. Enable the following installation option:

   id: networkInfrastructureManagement-gnmiTelemetry

2. Configure the throughputFactor parameter in the nsp—modules—telemetry—gnmi section; see the parameter description in the nsp-config.yml for the required value, which is based on the management scale:

              throughputFactor: n

   where n is the required throughput factor for your deployment

If required, configure NSP collection of accounting statistics. Perform the following steps:

1. Enable the following installation option:

   id: networkInfrastructureManagement-accountingTelemetry

2. Configure the collectFromClassicNes parameter in the nsp—modules—telemetry—accounting section. The default is false; toggle the flag to true to enable the NSP to process accounting files from classic NEs.

Note: If the collectFromClassicNes flag is true, you must disable file rollover traps on the NE to prevent duplicate file collection; see the NE CLI documentation. This change will impact SAA collection: SAA is not supported in NSP.

If all of the following are true, configure the following parameters in the integrations section:

• The NSP system includes the NFM-P.

• You want the NFM-P to forward system metrics to the NSP cluster.

• The NFM-P main server and main database are on separate stations:

    nfmpDB:

      primaryIp: ""

      standbyIp: ""

If both of the following are true, configure the following parameters in the integrations section:

• The NSP system includes the NFM-P.

• You want the NFM-P to forward system metrics to the NSP cluster.

• The NFM-P system includes one or more auxiliary servers:

    auxServer:

      primaryIpList: ""

      standbyIpList: ""

If required, configure the user authentication parameters in the sso section; see NSP SSO configuration parameters for configuration information.

Save and close the new nsp-config.yml file.

Close the previous nsp-config.yml file.

Enter the following to back up nsp-config.yml:

# cp NSP-CN-DEP-new_base_load/NSP-CN-*/config/nsp-config.yml NSP-CN-DEP-new_base_load/NSP-CN-*/config/nsp-config.yml-default ↵

Enter the following:

# ln -f NSP-CN-DEP-new_latest_load/NSP-CN-*/config/nsp-config.yml NSP-CN-DEP-new_base_load/NSP-CN-*/config/nsp-config.yml ↵

If you are using your own storage, perform the following steps.

See the NSP Planning Guide for the required IOPS and latency storage throughput.

1. Check if the storage classes meet the IOPS requirements.

   Run the script to check the IOPS of the configured storage classes.

   1. Enter the following on the NSP deployer host:

      # cd /opt/nsp/NSP-CN-DEP-new-release-ID/NSP-CN-new-release-ID/tools/support/

      storageIopsCheck/bin ↵

   2. Run the script by selecting each storage class individually or by selecting All Storage Classes.

      Output like the following is displayed and indicates if the script passes or fails.

      [root@ ]# ./nspstorageiopsctl 

      date time year -------------------- BEGIN ./nspstorageiopsctl --------------------

       

      [INFO]: SSH to NSP Cluster host ip_address successful

      1) readWriteManyHighIOPSClass            5) readWriteOnceClassForDatabases

      2) readWriteOnceHighIOPSClass            6) All Storage Classes

      3) readWriteManyLowIOPSClass             7) Quit

      4) readWriteOnceLowIOPSClass

      Select an option: 1

      [INFO] **** Calling IOPs check for readWriteManyHighIOPSClass - Storage Class Name (ceph-filesystem) Access Mode (ReadWriteMany) ****

      [INFO] NSP Cluster Host: ip_address

      [INFO] Validate configured storage classes are available on NSP Cluster

      [INFO] Adding helm repo nokia-nsp

      [INFO] Updating helm repo nokia-nsp

      [INFO] Executing k8s job on NSP Cluster ip_address

      [INFO] Creating /opt/nsp/nsp-storage-iops directory on NSP Cluster ip_address

      [INFO] Copying values.yaml to /opt/nsp/nsp-deployer/tools/nsp-storage-iops

      [INFO] Executing k8s job on NSP Cluster ip_address

      [INFO] Waiting for K8s job status...

      [INFO] Job storage-iops completed successfully.

      [INFO] Cleaning up and uninstalling k8s job

      [INFO] Helm uninstall cn-nsp-storage-iops successful

      STORAGECLASS         ACCESS MODE    READIOPS   WRITEIOPS  RESULT    STORAGECLASSTYPE

      ------------         -----------    --------   ---------  ------    ----------------

      storage_class     ReadWriteMany  12400      12500      true      readWriteManyHighIOPSClass

      [INFO] READ IOPS and WRITE IOPS meet the threshold of 10000.

      date time year ------------------- END ./nspstorageiopsctl - SUCCESS --------------------

   If these requirements are not met, this may result in system performance degradation.

The steps in the following section align with the DR cluster-specific actions described in Pathway for DR NSP system upgrade from Release 25.11 or later.

If you are upgrading a standalone NSP system, go to Step 83.

DR-specific instructions

Perform Step 83 to Step 98 on the standby NSP cluster.

Perform Step 83 to Step 128 on the primary NSP cluster.

Perform Step 99 to Step 128 on the standby NSP cluster.

Perform Step 129 to Step 134 on each NSP cluster.

Go to Step 135.

Stop and undeploy NSP cluster, scenario 1

Perform the steps in this section if you are using local storage.

Perform the following steps on the NSP deployer host to completely remove the existing NSP deployment.

1. Open the following file using a plain-text editor such as vi:

   /opt/nsp/NSP-CN-DEP-old-ID/NSP-CN-old-ID/config/nsp-config.yml

2. Edit the following line in the platform section, kubernetes subsection as shown below:

     deleteOnUndeploy:true

3. Save and close the nsp-config.yml file.

Enter the following on the NSP deployer host to undeploy the NSP cluster:

Note: If you are upgrading a standalone NSP system, or the primary NSP cluster in a DR deployment, this step marks the beginning of the network management outage associated with the upgrade.

Note: If the NSP cluster VMs do not have the required SSH key, you must include the --ask-pass argument in the command, as shown in the following example, and are subsequently prompted for the root password of each cluster member:

nspdeployerctl --ask-pass uninstall --undeploy --clean

# /opt/nsp/NSP-CN-DEP-old-release-ID/bin/nspdeployerctl uninstall --undeploy --clean ↵

The NSP cluster is undeployed.

Check that all NSP pods are removed from the NSP cluster.

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

2. Enter the following:

   # kubectl get pods -A |grep psa ↵

   The output should not display any pod details.

Enter the following:

# cd /opt/nsp/NSP-CN-DEP-old-release-ID/bin ↵

Enter the following:

# ./nspdeployerctl unconfig ↵

Note: If a label was set manually on a node, you must remove it.

Go to Step 93.

Stop and undeploy NSP cluster, scenario 2

If you are using your own storage, perform the following steps on the NSP deployer host to preserve the existing cluster data.

1. Open the following file using a plain-text editor such as vi:

   /opt/nsp/NSP-CN-DEP-old-ID/NSP-CN-old-ID/config/nsp-config.yml

2. Confirm that deleteOnUndeploy is set to false in the platform section, kubernetes subsection:

     deleteOnUndeploy:false

3. Save and close the nsp-config.yml file.

Enter the following on the NSP deployer host to undeploy the NSP cluster:

Note: If you are upgrading a standalone NSP system, or the primary NSP cluster in a DR deployment, this step marks the beginning of the network management outage associated with the upgrade.

Note: If the NSP cluster VMs do not have the required SSH key, you must include the --ask-pass argument in the command, as shown in the following example, and are subsequently prompted for the root password of each cluster member:

nspdeployerctl --ask-pass uninstall --undeploy --clean

# /opt/nsp/NSP-CN-DEP-old-release-ID/bin/nspdeployerctl uninstall --undeploy --clean ↵

The NSP cluster is undeployed.

As the root or NSP admin user on the NSP cluster host, enter the following periodically to display the status of the Kubernetes system pods:

Note: You must not proceed to the next step until the output lists only the following:

• pods in external storage only when using your own storage

• pods in kube-system namespace

• nsp-backup-storage pod

# kubectl get pods -A ↵

The pods are listed.

Upgrade auxiliary database

If your system includes NFM-P and an auxiliary database, go to Step 98.

If the NSP system includes NFMP and auxdb, the auxdb upgrade is performed as part of the the NFM-P upgrade; go to Step 98.

If the system has an auxiliary database and no NFM-P, the auxiliary database upgrade is performed as part of the NSP upgrade.

On a standalone NSP cluster where NFM-P is not deployed, perform Step 96 or Step 97, depending on the auxiliary database deployment.

On a DR NSP cluster where NFM-P is not deployed, perform Step 96 or Step 97 after the primary NSP cluster is undeployed, depending on the auxiliary database deployment.

If a standalone auxiliary database is installed, perform To upgrade a standalone Release 25.11 or earlier auxiliary database to upgrade the auxiliary database.

If a geo-redundant auxiliary database is installed, perform the following steps:

1. Perform concurrently:

   • Upgrade the primary (second) auxiliary database cluster; see Upgrade former primary auxiliary database cluster.

     Perform To upgrade a geo-redundant Release 25.11 or earlier auxiliary database.

   • Upgrade the standby (first) auxiliary database cluster; see Upgrade standby auxiliary database cluster.

     Perform To upgrade a geo-redundant Release 25.11 or earlier auxiliary database.

2. Activate the primary (second) auxiliary database cluster; see Disable maintenance mode for auxiliary database agents.

3. Verify that the auxiliary database is functioning correctly; see Verify auxiliary database status.

Apply OS update to NSP cluster VMs

If the NSP cluster VMs were created using an NSP RHEL OS disk image, perform the following steps on each NSP cluster VM to apply the required OS update.

1. Log in as the root user on the VM.

2. Perform To apply a RHEL update to an NSP image-based OS on the VM.

Upgrade Kubernetes deployment environment

If your Kubernetes version is supported, as determined in To prepare for an NSP system upgrade from Release 25.11 or later, go to Install Kubernetes secrets.

See the Host Environment Compatibility Guide for NSP and CLM for Kubernetes version-support information.

You must uninstall Kubernetes in one of the following scenarios:

• If you are not upgrading Kubernetes from the immediately previous version supported by the NSP, but from an earlier version

• If the system was previously installed by the root user and you want to upgrade as the NSP admin user

Otherwise, you can skip this step.

Enter the following on the NSP deployer host to uninstall Kubernetes:

Note: If the NSP cluster VMs do not have the required SSH key, you must include the --ask-pass argument in the command, as shown in the following example, and are subsequently prompted for the root password of each cluster member:

nspk8sctl --ask-pass uninstall

# /opt/nsp/nsp-k8s-deployer-old-release-ID/bin/nspk8sctl uninstall ↵

The Kubernetes software is uninstalled.

Enter the following on the NSP deployer host to install Kubernetes:

Note: If the NSP cluster VMs do not have the required SSH key, you must include the --ask-pass argument in the command, as shown in the following example, and are subsequently prompted for the root password of each cluster member:

nspk8sctl --ask-pass install

# /opt/nsp/nsp-k8s-deployer-new-release-ID/bin/nspk8sctl install ↵

Note: If Kubernetes was not uninstalled in Step 100, the installation takes considerable time; during the process, each cluster node is cordoned, drained, upgraded, and uncordoned, one node at a time. The operation on each node may take 15 minutes or more.

The NSP Kubernetes environment is deployed.

Install Kubernetes secrets

Enter the following:

Note: Ensure that you are upgrading to the latest NSP service pack in NSP-CN-DEP-new_latest_load.

# cd /opt/nsp/NSP-CN-DEP-new-release-ID/bin ↵

If you uninstalled Kubernetes in Step 100, obtain and restore the secrets backup file.

Note: Ensure that you are upgrading to the latest NSP service pack in NSP-CN-DEP-new_latest_load.

1. Enter the following:

   # scp address:path/backup_file /tmp/ ↵

   where

   address is the address of the NSP deployer host in the primary cluster

   path is the absolute file path of the backup file created in Step 100

   backup_file is the secrets backup file name

   The backup file is transferred to the local /tmp directory.

2. Enter the following:

   # cd /opt/nsp/NSP-CN-DEP-new-release-ID/bin ↵

3. Enter the following:

   ./nspdeployerctl secret -i /tmp/backup_file restore ↵

   The following prompt is displayed:

   Please provide the encryption password for /opt/backupfile

   enter aes-256-ctr decryption password:

4. Enter the password recorded in Step 6.

   As the secrets are restored, messages like the following are displayed for each Kubernetes namespace:

   Restoring secrets from backup_file...

   secret/ca-key-pair-external created

     Restored secret namespace:ca-key-pair-external

   secret/ca-key-pair-internal created

     Restored secret namespace:ca-key-pair-internal

   secret/nsp-tls-store-pass created

     Restored secret namespace:nsp-tls-store-pass

Perform the following steps.

Note: The Kubernetes secrets from the previous release already exist; you are subsequently prompted for new or optional secrets that were not created in the previous release. An example of an optional secret is custom certificates.

1. Enter the following:

   # ./nspdeployerctl secret install ↵

   A prompt may be displayed, depending on whether new or optional secrets were created.

2. If any prompts are displayed, enter no ↵.

Back up the Kubernetes secrets on a standalone or primary NSP cluster.

1. Enter the following:

   # ./nspdeployerctl secret -o backup_file backup ↵

   where backup_file is the absolute path and name of the backup file to create

   As the secrets are backed up, messages like the following are displayed for each Kubernetes namespace:

   Backing up secrets to /opt/backupfile...

     Including secret namespace:ca-key-pair-external

     Including secret namespace:ca-key-pair-internal

     Including secret namespace:nsp-tls-store-pass

   When the backup is complete, the following prompt is displayed:

   Please provide an encryption password for backup_file

   enter aes-256-ctr encryption password:

2. Enter a password.

   The following prompt is displayed:

   Verifying - enter aes-256-ctr encryption password:

3. Re-enter the password.

   The backup file is encrypted using the password.

4. Record the password for use when restoring the backup.

5. Record the name of the data center associated with the backup.

6. Transfer the backup file to a secure location in a separate facility for safekeeping.

Add TLS certificates

Enter the following on the NSP deployer host:

# cd /opt/nsp/NSP-CN-DEP-old-release-ID/NSP-CN-old-release-ID/tls ↵

Copy all TLS certificates from the tls subdiretories in Step 106 to the appropriate subdirectories in /opt/nsp/NSP-CN-DEP-new-release-ID/NSP-CN-new-release-ID/tls directory.

Note: Ensure that you are upgrading to the latest NSP service pack in NSP-CN-DEP-new_latest_load.

Copy certificate for secure connections

The ca.pem certificate is required for secure gRPC communication and is not required for unsecure telemetry subscriptions.

Note: Ensure that you are upgrading to the latest NSP service pack in NSP-CN-DEP-new_latest_load.

If your system uses secure telemetry subscriptions, for example, secure gRPC secure with SR Linux, copy all files except .key files from the old telemetry TLS directory to the new directory.

# cp /opt/build/NSP-CN-DEP-old-release-ID/NSP-CN-old-release-ID/tls/telemetry/*  /opt/build/NSP-CN-DEP-new-release-ID/NSP-CN-new-release-ID/tls/telemetry/ ↵

Note: If this step is not performed, secure telemetry subscriptions fail with a context deadline exceeded error due to missing TLS certificate.

Restore NSP Data

Perform the steps in this section on the standalone or primary NSP cluster if you performed Stop and undeploy NSP cluster, scenario 1 and are using local storage.

Note: If you are using your own storage, you must perform the steps in this section and in Reconfigure storage settings to restore NSP data and reconfigure your own storage settings.

The storage configuration is removed when Kubernetes in uninstalled.

Enter the following:

Note: Ensure that you are upgrading to the latest NSP service pack in NSP-CN-DEP-new_latest_load.

# cd /opt/nsp/NSP-CN-DEP-new-release-ID/bin ↵

Enter the following:

Note: If the NSP cluster VMs do not have the required SSH key, you must include the --ask-pass argument in the command, as shown in the following example, and are subsequently prompted for the root password of each cluster member:

nspdeployerctl --ask-pass config

# ./nspdeployerctl config ↵

Enter the following:

Note: If the NSP cluster VMs do not have the required SSH key, you must include the --ask-pass argument in the command, as shown in the following example, and are subsequently prompted for the root password of each cluster member:

nspdeployerctl --ask-pass install --config --restore

# ./nspdeployerctl install --config --restore ↵

The NSP cluster is deployed in restore mode.

Perform the steps starting from the “Restore data” section in “How do I restore the NSP cluster databases?” in the NSP System Administrator Guide.

Reconfigure storage settings

If you are using your own storage and performed Stop and undeploy NSP cluster, scenario 1, you must reconfigure the storage classes for the NSP cluster.

Step 65 has examples of storage class configurations; if you are using other types of storage, see the appropriate storage documentation.

Upgrade NSP software

Return to the console window on the NSP deployer host.

If you are configuring the standby cluster in a DR deployment, obtain and restore the secrets backup file from the NSP cluster in the primary data center.

Note: Ensure that you are upgrading to the latest NSP service pack in NSP-CN-DEP-new_latest_load.

1. Enter the following:

   # scp address:path/backup_file /tmp/ ↵

   where

   address is the address of the NSP deployer host in the primary cluster

   path is the absolute file path of the backup file created in Step 105

   backup_file is the secrets backup file name

   The backup file is transferred to the local /tmp directory.

2. Enter the following:

   # cd /opt/nsp/NSP-CN-DEP-new-release-ID/bin ↵

3. Enter the following:

   ./nspdeployerctl secret -i /tmp/backup_file restore ↵

   The following prompt is displayed:

   Please provide the encryption password for /opt/backupfile

   enter aes-256-ctr decryption password:

4. Enter the password recorded in Step 105.

   As the secrets are restored, messages like the following are displayed for each Kubernetes namespace:

   Restoring secrets from backup_file...

   secret/ca-key-pair-external created

     Restored secret namespace:ca-key-pair-external

   secret/ca-key-pair-internal created

     Restored secret namespace:ca-key-pair-internal

   secret/nsp-tls-store-pass created

     Restored secret namespace:nsp-tls-store-pass

5. If you configured custom client access certificates when installing Kubernetes secrets on the primary NSP cluster, you must update the standby server secret for client access using the custom certificate and key files that are specific to the standby cluster.

   Enter the following:

   # ./nspdeployerctl secret -s nginx-nb-tls-nsp -n psaRestricted -f tls.key=customKey -f tls.crt=customCert -f ca.crt=customCaCert update ↵

   where

   customKey is the full path of the private server key file

   customCert is the full path of the server public certificate file

   customCaCert is the full path of the CA public certificate file

   Custom certificate and key files are created by performing To generate custom TLS certificates for NSP.

   Messages like the following are displayed as the server secret is updated:

   secret/nginx-nb-tls-nsp patched

   The following files may contain sensitive information. They are no longer required by NSP and may be removed.

     customKey

     customCert

     customCaCert

Enter the following:

Note: Ensure that you are upgrading to the latest NSP service pack in NSP-CN-DEP-new_latest_load.

# cd /opt/nsp/NSP-CN-DEP-new-release-ID/bin ↵

Enter the following:

Note: If the NSP cluster VMs do not have the required SSH key, you must include the --ask-pass argument in the command, as shown in the following example, and are subsequently prompted for the root password of each cluster member:

nspdeployerctl --ask-pass install --config --deploy

# ./nspdeployerctl install --config --deploy ↵

The NSP is upgraded.

Monitor NSP initialization

Return to the console window on the NSP cluster host.

Monitor and validate the NSP cluster initialization.

Note: You must not proceed to the next step until each NSP pod is operational.

Note: nfs-storage over linstor is available on two or more nodes for all profile types.

nfs-storage uses RWX for access and local-provisioner uses RWO for access.

1. Enter the following every few minutes:

   # kubectl get pods -A ↵

   The status of each NSP cluster pod is displayed; the NSP cluster is operational when the status of each pod is Running or Completed.

2. Check PVCs are bound to PVs and PVs are created with STORAGECLASS as shown below.

   # kubectl get pvc -A ↵

   NAMESPACE             NAME                                                   STATUS  VOLUME    CAPACITY   ACCESS MODES  STORAGECLASS         AGE

   nsp-psa-privileged    nfs-server-pvc                                         Bound   pvc-ID    47Gi       RWO           piraeus-storage      2d

   nsp-psa-privileged    pvc-nfs-subdir-provisioner                             Bound   pvc-ID    10Mi       RWO                                2d

   nsp-psarestricted     data-nspos-kafka-broker-0                              Bound   pvc-ID    10Gi       RWO           local-provisioner    2d

   nsp-psa-restricted    data-nspos-kafka-controller-0                          Bound   pvc-ID    10Gi       RWO           local-provisioner    2d

   nsp-psarestricted     data-nspos-zookeeper-0                                 Bound   pvc-ID    2Gi        RWO           local-provisioner    2d

   nsp-psa-restricted    datadir-nspos-neo4j-core-dc2-250b-0                    Bound   pvc-ID    10Gi       RWO           local-provisioner    2d

   nsp-psa-restricted    nsp-backup-storage                                     Bound   pvc-ID    10G        RWX           nfs-storage          2d

   nsp-psa-restricted    nspos-fluentd-logs-data                                Bound   pvc-ID    50Mi       ROX                                2d 

   nsp-psa-restricted    nspos-fluentd-posfile-data                             Bound   pvc-ID    1Gi        RWO                                2d

   nsp-psa-restricted    nspos-postgresql-data-nspos-postgresql-primary-0       Bound   pvc-ID    15Gi       RWO           local-provisioner    2d 

   nsp-psa-restricted    opensearch-backup-pv                                   Bound   pvc-ID    1Gi        RWX           nfs-storage          2d 

   nsp-psa-restricted    opensearch-cluster-master-opensearch-cluster-master-0  Bound   pvc-ID    50Gi       RWO           local-provisioner    2d..

   nsp-psa-restricted    solr-pvc-nspos-solr-statefulset-0                      Bound   pvc-ID    1Gi        RWO           local-provisioner    2d

   nsp-psa-restricted    storage-volume-nspos-prometheus-server-0               Bound   pvc-ID    10Gi       RWO           local-provisioner    2d

   # kubectl get pv ↵

   NAME                          CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                                                                          STORAGECLASS            REASON      AGE

   nspos-fluentd-logs-data       50Mi       ROX            Retain           Bound       nsp-psa-restricted/nspos-fluentd-logs-data                                                                         2d

   nspos-fluent-posfile-data     1Gi        RWO            Retain           Bound       nsp-psa-restricted/nspos-fluentd-posfile-data                                                                      2d

   pv-nfs-subdir-provisioner     10Mi       RWO            Delete           Bound       nsp-psa-privileged/pvc-nfs-subdir-provisioner                                                                      2d

   pvc-0c8d9fdf-6ffc-4208-...    47Gi       RWO            Delete           Bound       nsp-psa-privileged/nfs-server-pvc                                              piraeus-storage                     2d 

   pvc-4ccbe6ef-e38c-4739-...    10G        RWX            Delete           Bound       nsp-psa-restricted/nsp-backup-storage                                          nfs-storage                         2d

   pvc-5b21e2e2-eec5-49a7-...    10Gi       RWO            Delete           Bound       nsp-psa-restricted/data-nspos-kafka-broker-0                                   local-provisioner                   2d

   pvc-50df27c7-fcf3-462d-...    10Gi       RWO            Delete           Bound       nsp-psa-restricted/storage-volume-nspos-prometheus-server-0                    local-provisioner                   2d

   pvc-59c23b56-95fb-4cf6-...    50Gi       RWO            Delete           Bound       nsp-psa-restricted/opensearch-cluster-master-opensearch-cluster-master-0       local-provisioner                   2d

   pvc-96d2ceb0-e490-470d-...    2Gi        RWO            Delete           Bound       nsp-psa-restricted/data-nspos-zookeeper-0                                      local-provisioner                   2d

   pvc-370ee803-cd02-4eac-...    15Gi       RWO            Delete           Bound       nsp-psa-restricted/nspos-postgresql-data-nspos-postgresql-primary-0            local-provisioner                   2d

   pvc-32991a91-1b35-42c9-...    1Gi        RWX            Delete           Bound       nsp-psa-restricted/opensearch-backup-pv                                        nfs-storage                         2d

   pvc-86581df8-026b-4b80-...    10Gi       RWO            Delete           Bound       nsp-psa-restricted/data-nspos-kafka-controller-0                               local-provisioner                   2d

   pvc-bf1c522b-985c-485c-...    1Gi        RWO            Delete           Bound       nsp-psa-restricted/solr-pvc-nspos-solr-statefulset-0                           local-provisioner                   2d

   pvc-ccee060b-6268-4601-...    10Gi       RWO            Delete           Bound       nsp-psa-restricted/datadir-nspos-neo4j-core-dc2-250b-0                         local-provisioner                   2d

3. Verify that all pods are in the Running state.

4. If the Network Operations Analytics - Baseline Analytics installation option is enabled, ensure that the following pods are listed; otherwise, see the NSP Troubleshooting Guide for information about troubleshooting an errored pod:

   Note: The output for a non-HA deployment is shown below; an HA cluster has one baseline pod, two rta-ignite pods, and the remaining pods have one instance.

   • analytics-rtanalytics-tomcat

   • baseline-anomaly-detector-n-exec-1

   • baseline-trainer-n-exec-1

   • baseline-window-evaluator-n-exec-1

   • rta-anomaly-detector-app-driver

   • rta-ignite-0

   • rta-trainer-app-driver

   • rta-windower-app-driver

   • spark-operator-m-n

5. If any pod fails to enter the Running or Completed state, see the NSP Troubleshooting Guide for information about troubleshooting an errored pod.

6. Enter the following to display the status of the NSP cluster members:

   # kubectl get nodes ↵

   The NSP Kubernetes deployer log file is /var/log/nspk8sctl.log.

Enter the following on the NSP cluster host to ensure that all pods are running:

# kubectl get pods -A ↵

The status of each pod is listed; all pods are running when the displayed STATUS value is Running or Completed.

The nsp deployer log file is /var/log/nspdeployerctl.log.

To remove the sensitive NSP security information from the local file system enter the following:

# rm -rf /tmp/appliedConfig ↵

The /tmp/appliedConfigs directory is deleted.

Verify upgraded NSP cluster operation

Use a browser to open the NSP cluster URL.

Verify the following.

• The NSP sign-in page opens.

• The NSP UI opens after you sign in.

• In a DR deployment, if the standby cluster is operational and you specify the standby cluster address, the browser is redirected to the primary cluster address.

Note: If the UI fails to open, perform “How do I remove the stale NSP allowlist entries?” in the NSP System Administrator Guide to ensure that unresolvable host entries from the previous deployment do not prevent NSP access.

Upgrade MDM adaptors

If the NSP system currently performs model-driven telemetry or classic telemetry statistics collection, you must upgrade your MDM adaptors to the latest in the adaptor suite delivered as part of the new NSP release, and install the required Custom Resources, or CRs.

Upgrading the adaptors to the latest version is mandatory in order for gNMI telemetry collection to function.

Note: After an NSP upgrade, verify all functionality before upgrading installed adaptors or artifact bundles. This activity is best performed during a secondary maintenance window.

Perform the following steps.

1. Upgrade the adaptor suites; see “How do I install artifacts that are not supported in the Artifacts view?” in the NSP System Administrator Guide for information.

2. When the adaptor suites are upgraded successfully, use NSP Artifacts to install the required telemetry artifact bundles that are packaged with the adaptor suites.

   • nsp-telemetry-cr-nodeType-version.rel.release.ct.zip

   • nsp-telemetry-cr-nodeType-version.rel.release-va.zip

3. View the messages displayed during the installation to verify that the artifact installation is successful.

Upgrade or enable additional components and systems

If the NSP deployment includes the VSR-NRC, upgrade the VSR-NRC as described in the VSR-NRC documentation.

If you are including an existing NFM-P system in the deployment, perform one of the following.

1. Upgrade the NFM-P to the NSP release; see NFM-P system upgrade from Release 25.11 or earlier.

2. Enable NFM-P and NSP compatibility; perform To enable NSP compatibility with an earlier NFM-P system.

Note: An NFM-P system upgrade procedure includes steps for upgrading the following components in an orderly fashion:

• NSP auxiliary database

If the NSP system includes the WS-NOC, perform the appropriate procedure in WaveSuite and NSP integration to enable WS-NOC integration with the upgraded NSP system.

Purge Kubernetes image files

Note: Perform this and the following step only after you verify that the NSP system is operationally stable and that an upgrade rollback is not required.

Enter the following on the NSP deployer host:

# cd /opt/nsp/nsp-k8s-deployer-new-release-ID/bin ↵

Enter the following:

# ./nspk8sctl purge-registry -e ↵

The images are purged.

Purge NSP image files

Note: Perform this and the following step only after you verify that the NSP system is operationally stable and that an upgrade rollback is not required.

Note: Ensure that you are upgrading to the latest NSP service pack in NSP-CN-DEP-new_latest_load.

Enter the following on the NSP deployer host:

# cd /opt/nsp/NSP-CN-DEP-new-release-ID/bin ↵

Enter the following:

# ./nspdeployerctl purge-registry -e ↵

The charts and images are purged.

Restore SELinux enforcing mode

If either of the following is true, perform “How do I switch between SELinux modes on NSP system components?” in the NSP System Administrator Guide on the NSP deployer host and each NSP cluster VM.

• You switched from SELinux enforcing mode to permissive mode before the upgrade, and want to restore the use of enforcing mode.

• The upgrade has enabled SELinux in the NSP cluster for the first time, but in permissive mode, and you want the more stringent security of enforcing mode.

Close the open console windows.

Import NFM-P users and groups

If you need to import NFM-P users to the NSP local user database as you transition to OAUTH2 user authentication, perform “How do I import users and groups from NFM-P?” in the NSP System Administrator Guide.

Configure remote authentication sources

If the NSP deployment used remote authentication before the upgrade, perform “How do I configure a remote authentication server?” in the NSP System Administrator Guide.

Remove path-control subscriptions

If your NSP system has path-control telemetry flow integration enabled, you must remove the older subscriptions, which can no longer be used.

Issue the following REST API call:

Note: In order to issue a REST API call, you require a token; see the My First NSP API Client tutorial on the Network Developer Portal for information.

POST https://address:8443/rest/flow-collector-controller/rest/api/v1/export/unsubscribe

where address is the NSP advertised address

The message body is the following:

{

"subscription" : "nrcp-sub"

}

The subscriptions are removed.

Synchronize LSP paths

You must update the path properties for existing LSP paths.

For each model-driven NE that the NSP manages, Issue the following RESTCONF API call to ensure that the tunnel-id and signaling-type LSP values are updated with the correct device mappings.

Note: This step is required for MDM NEs only, and is not required for classically managed NEs.

POST https://address/restconf/operations/nsp-admin-resync:trigger-resync

where address is the advertised address of the NSP cluster

The request body is the following:

{

  "nsp-admin-resync:input": {

    "plugin-id": "mdm",

    "network-element": [

      {

        "ne-id": NE_IP,

        "sbi-classes": [

          {

            "class-id": "nokia-state:/state/router/mpls/lsp/primary"

          },

          {

            "class-id": "nokia-state:/state/router/mpls/lsp/secondary"

          }

        ]

      }

    ]

  }

}

where NE_IP is the IP address of the NE

Confirm the completion of the resync operation for the affected MDM NEs by performing the following steps:

1. On the nspos-resync-fw-0 pod, enter the following command:

   # kubectl exec -it -n nsp-psa-restricted nspos-resync-fw-0 -- /bin/bash ↵

2. Run a tail on mdResync.log:

   # tail -f /opt/nsp/os/resync-fw/logs/mdResync.log ↵

3. The log contains messages similar to the following after completing sync on an NE:

   done resync neId=3.3.3.3, resync task id=48, isFullResync=false, isScheduleResync=false, device classes=[nokia-state:/state/router/mpls/lsp/primary, nokia-state:/state/router/mpls/lsp/secondary]

4. Verify that the sync is completed for all required MDM NEs.

The following API call updates path control UUIDs and properties in existing IETF TE tunnel primary-paths and secondary-paths. This API syncs values from the path control database to the YANG database. The synchronization process occurs in the background when the API call is executed.

https://server_IP/lspcore/api/v1/syncLspPaths

Method: GET

Sample result:

HTTP Status OK/40X

{    response: {

        data: null,

        status:  40x,

        errors: {

            errorMessage: ""

        },

        startRow: 0,

        endRow: 0,

        totalRows: {}

    }

}

HTTP Status OK

{

    response: {

        data: null,

        status:  200,

        startRow: 0,

        endRow: 0,

        totalRows: {}

    }

}

Perform post-upgrade tasks

Modify your UAC configuration to maintain user access to the Service Health dashlet in the Network Map and Health view.

At a minimum, to maintain user access to the Service Health dashlet, you must open all role objects that control access to the Network Map and Health view, make at least one change to each role (even if only to the Description field), and save your changes. This action is essential to maintain user access to the Service Health dashlet after an upgrade.

See “How do I configure a role?” in the NSP System Administrator Guide for information on modifying roles.

If you want to remove NFM-P information from the auxiliary database, see Removing NFM-P information.

Perform the following steps.

1. Complete the setup of the NSP deployment.

2. Go to Centralized License Manager in the NSP UI to get the CLM UUID and security key for the installed NSP system.

3. Contact Nokia to obtain a unique NSP license key for the NSP system.

4. Apply the NSP license key through the NSP Centralized License Manger.

Note: NSP uses the same UUID for both active and standby instances. The same UUID is also used after switchover.

To install your NSP license, see “How do I install the NSP license?” in the NSP System Administrator Guide.

Note: See “How do I update the NSP license from Release 25.x to 26.4 or later?” in the NSP System Administrator Guide to update your NSP license from Release 25.x to Release 26.4 or later.

End of steps