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: 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 116 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 |