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 WS-NOC MnCMain 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 

Ensure that the WS-NOC is running and operational.

2 

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

3 

Perform one of the following.

  1. For a standalone WS-NOC deployment:

    1. Perform Step 4 to Step 9.

    2. Go to Step 23.

  2. For a DR WS-NOC deployment, go to Step 10.

Configure integration
 
4 

Log in as the root user on the WS-NOC MnCMain VM.

5 

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.

  4. Save and close the configuration.json file.

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

6 

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. Open a console window.

    3. Enter the following:

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

    4. Enter the following:

      # kubectl get secret -n nsp-psa-restricted ca-key-pair-external-nspdeployer -o jsonpath="{.data.tls\.crt}" | base64 -d > ca.pem ↵

      A ca.pem file is created in the current directory.

    5. Enter the following:

      # kubectl get secret -n nsp-psa-restricted ca-key-pair-external-nspdeployer -o jsonpath="{.data.tls\.key}" | base64 -d > ca.key ↵

      A ca.key file is created in the current directory.

    6. Enter the following:

      # kubectl get secret -n nsp-psa-restricted ca-key-pair-internal-nspdeployer -o jsonpath="{.data.tls\.crt}" | base64 -d > ca_internal.pem ↵

      A ca_internal.pem file is created in the current directory.

    7. Enter the following:

      # kubectl get secret -n nsp-psa-restricted ca-key-pair-internal-nspdeployer -o jsonpath="{.data.tls\.key}" | base64 -d > ca_internal.key ↵

      A ca_internal.key file is created in the current directory.

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

      # tar cvf nspca.tar ca* ↵

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

      Note: In a DR WS-NOC deployment, you must transfer the file to the NOC and the DRC MnCMain VMs.

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

      where address is the NOC or DRC MnCMain VM IP address

    10. 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 ↵

    11. Enter the following to close the console window:

      # exit ↵

7 

Enter the following:

# /install_dir/setup/config.sh ↵

The WS-NOC configuration is updated.

8 

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.

9 

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 reference to remove from system control

  3. Enter the following to close the console shell:

    # exit ↵

DR-specific configuration
 
10 

Perform the following steps.

  1. Stop HA data replication.

  2. Log in as the root user on the WS-NOC NOC MnCMain VM.

  3. Open a console window.

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

    install_dir/config/bench/configuration.json

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

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

  7. Save and close the configuration.json file.

  8. Perform Step 6 to manage security files for the WS-NOC and NSP.

  9. Enter the following:

    # /install_dir/setup/config.sh ↵

    The WS-NOC configuration is updated.

  10. Log in as the root user on the standby WS-NOC MnCMain VM.

  11. Perform Step 8 to apply the TLS certificates.

  12. Perform an activity switch.

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

  13. Log in as the root user on the new standby WS-NOC MnCMain VM.

  14. Perform Step 8 to apply the TLS certificates.

  15. Start HA data replication.

  16. Perform Step 9 on each DR site to remove references to nsp and nspos containers that the WS-NOC no longer requires.

  17. Close the console windows.

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

Log in to the WS-NOC VM.

12 

Enter the following:

# docker exec -ti otntomcat bash ↵

A command shell opens in the otntomcat container.

13 

Enter the following:

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

14 

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

15 

Set the nspIsConfigured parameter to false.

16 

Save and close the file.

17 

Enter the following to close the console shell:

# exit ↵

18 

Refresh the GUI page.

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

Post-integration steps required when using custom TLS certificates
 
19 

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.

20 

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 ↵

21 

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/ ↵

22 

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 ↵

23 

Close the open console windows.

End of steps