To migrate from an independent NFM-P system to an NSP cluster deployment
Purpose
Perform this procedure to transfer the nspOS functions of an independent NFM-P system to a greenfield NSP cluster deployment that includes the NFM-P.
Note: The migration transfers the NFM-P service groups to the NSP. The transfer may take hours, depending on the number of services. During this time, you must not auto-create any service groups. You can use the Find Ungrouped members count in Map Layouts and Groups to help determine when the upload is complete, after which you can auto-create groups.
Note: Before you attempt an NSP migration, ensure that any third-party software installed on the NSP deployer host or any NSP cluster VM is disabled and stopped.
Note: release-ID in a file path has the following format:
R.r.p-rel.version
where
R.r.p is the NSP release, in the form MAJOR.minor.patch
version is a numeric value
Steps
Prepare for migration | |
1   | 
 Perform Step 1 to Step 50 of To install the NSP to do the following.  | 
2   | 
 Using the specifications in the response to your Nokia Platform Sizing Request, create a VM for each additional RPM-based NSP component.  | 
3   | 
 Perform the steps in the “To back up the main database from the client GUI” procedure in one of the following guides, depending on the installed NFM-P release:  | 
4   | 
 Perform Step 6 to Step 10 on each NSP cluster. Note: In a DR deployment, you must perform the steps first on the NSP cluster that you want to be the primary cluster after the upgrade.  | 
5   | 
 Go to Step 11.  | 
Deploy NSP clusters | |
6   | 
 Perform Step 51 to Step 117 of To install the NSP to deploy the NSP Kubernetes environment and configure the NSP deployment parameters.  | 
Restore NSP databases | |
7   | 
 Copy the following Neo4j and PostgreSQL database backup files created in Step 3 to an empty temporary directory on the NSP deployer host: where timestamp is the backup creation time  | 
8   | 
 Perform “How do I restore the NSP cluster databases?” in the NSP System Administrator Guide to restore only the following databases on the NSP cluster: Note: Performing the procedure also starts the NSP.  | 
9   | 
 Monitor the NSP initialization; if the status of any pod is Error, you must correct the error; see the NSP System Administrator Guide for information about recovering an errored pod. Note: You must not proceed to the next step until the cluster is operational and no pods are in error.  | 
Set IGP topology data source | |
10   | 
 In order for the IGP maps to function after the migration, you may need to change the IGP topology data source; see Configuring the IGP topology data source for information.  | 
Reconfigure NFM-P | |
11   | 
 Perform Step 12 to Step 32 of To add an independent NFM-P to an existing NSP deployment.  | 
Synchronize system data | |
12   | 
 Verify that the NFM-P main server is fully initialized. Note: You must not advance to the next step until the server is fully initialized. 
  | 
13   | 
 Log in as the root or NSP admin user on the NSP deployer host in the primary data center.  | 
14   | 
 Enter the following: # cd /opt/nsp/NSP-CN-DEP-release-ID/NSP-CN-release-ID/tools/database ↵  | 
15   | 
 Enter the following: # ./nfmp-resync.sh ↵ The following time-stamped lines are displayed as the script synchronizes the NFM-P and NSP system data: timestamp: Running with namespace/nsp-platform-tomcat-pod_ID timestamp: Resync triggered successfully where namespace is the Kubernetes namespace pod_ID is an alphanumeric pod ID  | 
Reconfigure NSP analytics servers | |
16   | 
 If the system from which you are migrating includes one or more NSP analytics servers, perform the following steps on each NSP analytics server station. 
  | 
17   | 
 Enter the following: bash$ ./AnalyticsAdmin.sh start ↵ The analytics server starts.  | 
Reconfigure WS-NOC | |
18   | 
 If the deployment includes the WS-NOC, configure the WS-NOC to use the new nspOS instance by specifying the advertised address of the NSP cluster as the nspOS address. End of steps  |