To integrate a Release 24.6 or later WS-NOC and the NSP

Purpose
CAUTION 

CAUTION

System Degradation

The integration requires that the NSP and WS-NOC are at compatible releases. Attempting to integrate an incompatible WS-NOC system with the NSP may seriously damage the NSP or the WS-NOC.

NSP and WS-NOC release compatibility varies by Release; see the NSP compatibility matrix in the NSP Release Notice for information about the following:

  • supported release combinations

  • compatibility patches required by either system

CAUTION 

CAUTION

Data loss

Adding an WS-NOC system to an existing NSP deployment does not restore the WS-NOC Neo4j or PostgreSQL databases. The WS-NOC system is synchronized with the NSP, after which manual actions are required to recreate the data.

When the integration is complete, you must recreate the WS-NOC system and user settings in the NSP.

CAUTION 

CAUTION

Service Disruption

Performing the procedure requires stopping and starting the WS-NOC, which is service-affecting.

Perform the procedure only during a maintenance period of low network activity.

Perform this procedure to add an existing Release 24.6 or later WS-NOC to an existing NSP system, thus creating an integrated deployment. In the event of an integration failure, you can roll back the integration, as described in To roll back WS-NOC and NSP integration.

Note: You must perform the steps in each WS-NOC data center of a redundant WS-NOC deployment.

Note: The WS-NOC supports only IPv4, so can be integrated only with an NSP system that uses IPv4 in the client and internal networks.

Note: Nokia recommends that you use a common root CA in order to ensure trust among the components in the deployment.

Note: You require the following user privileges to perform the procedure:

  • on each WS-NOC server station—root

  • on each WS-NOC main VM—mncmaintuser

  • on each NSP cluster VM—root or NSP admin

Note: install_dir in a command is the WS-NOC base installation directory.

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

Note: A leading # symbol in a command represents the root user prompt, and is not to be included in the command.

Steps
 
1 

Perform one of the following.

If the WS-NOC is a DR deployment: • (For Ex : Site2 ) • Perform WS-NOC switchover (Site1 -> Site2) • Integrate with new standby WSNOC server ( site1 which is now standby)

  1. If the WS-NOC is standalone, perform Step 3 to Step 12.

  2. If the WS-NOC is a DR deployment:

    1. Integrate the standby WS-NOC server; perform Step 3 to Step 12 in the standby data center.

    2. Perform a WS-NOC switchover from the primary server to the integrated standby server, which becomes the new primary server. The former primary server is the new standby.

    3. When the new primary WS-NOC server is fully operational, perform Step 3 to Step 12 to integrate the now standby server.

2 

Go to Step 1.

Configure integration
 
3 

Ensure that the WS-NOC is running and operational.

4 

Install IPCalc on each WS-NOC VM, if not already installed.

5 

Log in to the WS-NOC server as the root user.

6 

Perform the following steps.

Note: When NSP is set as the authentication server for WS-NOC, a corresponding WS-NOC user with the required permissions must exist for each NSP user created for the WS-NOC. See the WS-NOC Administration Guide for information about WS-NOC user management.

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

    install_dir/config/bench/configuration.json

  2. Configure the parameters as shown in Table 11-4, WS-NOC remote authentication parameters.

  3. If the NSP is a DR deployment, configure the parameters in the remoteAuthentication.drc section.

Table 11-4: WS-NOC remote authentication parameters

Parameter

Value

remoteAuthentication.active

nsp

remoteAuthentication.nsp.noc.ipv4

If IPv4 communication is in use, the NSP client network IP address

remoteAuthentication.noc.ipv6

If IPv6 communication is in use, the NSP client network IP address

remoteAuthentication.nsp.noc.alias

NSP alias

7 

Perform one of the following:

  1. If you are using a customer-signed TLS certificate, perform the required configuration steps in “H.4 Customer Certificate” in the WaveSuite Installation/Migration Guide.

  2. If you are using the NSP TLS certificate, perform the following steps.

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

    2. Enter the following:

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

    3. Enter the following to obtain the NSP master-realm secret content:

      # kubectl get secret keycloak-masterrealm-secret -n namespace -o yaml | grep "keycloak-masterrealm-secret:" | awk '{print $2}' | base64 -d ↵

      where namespace is the name of the restricted namespace

      A base64 decode is performed on the hashed secret, and the resulting plain-text randomly generated string is displayed.

    4. Use the string to extract the secret content and create the following files:

      • ca.key

      • ca.pem

      • ca_internal.key

      • ca_internal.pem

    5. Enter the following to create an archive that contains the files:

      # tar cvf nspca.tar ca* ↵

    6. Enter the following to transfer the certificate archive file to the WS-NOC server:

      # scp nspca.tar root@address:/install_dir/config/bench/ ↵

      where address is the WS-NOC IP address

8 

Enter the following to delete the nspca.tar file, which presents a security risk.

# rm -f /opt/nsp/NSP-CN-DEP-release-ID/NSP-CN-release-ID/tls/ca/nspca.tar ↵

9 

Enter the following:

# /install_dir/setup/config.sh ↵

The WS-NOC configuration is updated.

10 

Perform one of the following:

  1. If you are providing your own signed TLS certificates, enter the following to restart the WS-NOC:

    # /install_dir/setup/mnc.sh restart system ↵

    The WS-NOC restarts.

  2. If you are using the NSP TLS certificates, enter the following on each WS-NOC server to generate and align the TLS certificates:

    # sudo /install_dir/setup/generateAndAlignCertificates.sh ↵

    The WS-NOC server restarts.

11 

Remove references to all nsp and nspos containers that the WS-NOC no longer requires.

  1. Enter the following:

    # docker exec -u otn -it mnc-admin bash ↵

    A console shell opens in the mnc-admin container.

  2. Enter the following:

    # /nfmt/system-monitor/scripts/remove_oldref.sh process ↵

    where process is the process ID of the container whose reference is to be removed

  3. Enter the following to close the console shell:

    # exit ↵

12 

If you are integrating a DR WS-NOC system, perform the following steps.

Note: You must perform the steps on each DR site, and must perform the steps on the standby site first.

Note: You must perform the steps on each DR site before you perform any functional tests.

  1. Stop HA data replication.

  2. Log in as the mncmaintuser user on the WS-NOC main VM.

  3. Open a console window.

  4. Edit the configuration.json file as described in Step 6.

  5. Enter the following to stop the WS-NOC system:

    # sudo /install_dir/setup/mnc.sh stop system ↵

  6. Log in as the root user on the MncMain VM.

  7. Enter the following:

    # sudo /install_dir/setup/config.sh site=site ↵

    where site is the name of the site that you are currently configuring

  8. Enter the following to start the WS-NOC:

    # sudo /install_dir/setup/mnc.sh start system ↵

  9. Enter the following to generate and align the TLS certificates:

    # sudo /install_dir/setup/generateAndAlignCertificates.sh ↵

  10. Perform an activity switch.

    The former standby WS-NOC is the new primary WS-NOC, and the former primary is the new standby.

  11. Perform substeps 1 to 9 on the new standby WS-NOC.

  12. Start HA data replication.

  13. Close the console windows.

Enable the Back to Launchpad option in the WS-NOC GUI
 
13 

Log in to the WS-NOC VM.

14 

Enter the following:

# docker exec -ti otntomcat bash ↵

A command shell opens in the otntomcat container.

15 

Enter the following:

# cd /nokia/1350OMS/NMA/WDM_WEB/nfmt/lib/otn/resources/common/menu ↵

16 

Open the systemProperty.json file in the directory using a plain-text editor such as vi:

17 

Set the nspIsConfigured parameter to false.

18 

Save and close the file.

19 

Open the systemProperty.json.VMs file in the directory using a plain-text editor such as vi:

20 

Set the nspIsConfigured parameter to false.

21 

Save and close the file.

22 

Enter the following to close the console shell:

# exit ↵

23 

Refresh the GUI page.

Note: The otntomcat container does not need to be restarted.

Post-integration steps required when using custom TLS certificates
 
24 

If you are providing your own TLS certificates and the WS-NOC is a DR deployment, perform the actions described in “H.4 Customer Certificate” in the WaveSuite Installation/Migration Guide to align the HA status.

25 

Perform the following steps on each of the following containers:

  • mnc-admin

  • nrct-tapi

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

  2. Enter the following sequence of commands:

    # chmod 644 /nfmt/instance/certificates/External/keystore.ks ↵

    # chmod 644 /nfmt/instance/certificates/External/key.pem ↵

    # mkdir -p /nfmt/config/tempcustom/nfmt/instance/certificates/External ↵

    # cp /nfmt/instance/certificates/External/keystore.ks /nfmt/config/tempcustom/nfmt/instance/certificates/External ↵

    # cp /nfmt/instance/certificates/External/key.pem /nfmt/config/tempcustom/nfmt/instance/certificates/External ↵

26 

Perform the following steps on each of the following containers:

  • mnc-fm

  • pm-components

  • pm-hadoop

  • pm-kafka

  • pm-spark

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

  2. Enter the following sequence of commands

    # chmod 644 /nfmt/instance/certificates/External/keystore.ks ↵

    # mkdir -p /nfmt/config/tempcustom/nfmt/instance/certificates/External/ ↵

    # cp /nfmt/instance/certificates/External/keystore.ks /nfmt/config/tempcustom/nfmt/instance/certificates/External/ ↵

27 

Navigate to System Control in the WS-NOC GUI. If the status of any process is shown as 'down', log in to the process container and restart the container by entering the following:

# /umc/plat/script/mngApp startup process_name ↵

28 

Close the open console windows.

End of steps