To integrate a Release 24.12 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 updates required by either system

CAUTION 

CAUTION

Data loss

Adding an WS-NOC system to an existing NSP deployment does not restore the WS-NOC 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.12 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 WaveSuite and NSP integration.

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: For WS-NOC Release 24.12 and later, the WS-SE and WS-HA applications should be added in WS-NOC only after the completion of WS-NOC integration with NSP.

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

    Note: For shared-mode deployments, Subject Alternative Name (SAN) must contain the same list included in WaveSuite CSR, along with ws-ingress and NSP_IP/FQDN.

  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 cluster host. In a DR deployment, this can be either the primary or standby NSP cluster host.

    2. Open a console window.

    3. Enter the following:

      # mkdir /root/ca ↵

    4. Enter the following:

      # cd /root/ca ↵

    5. 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.

    6. 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.

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

    8. 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.

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

      # tar cvf nspca.tar ca* ↵

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

      Note: In an HA WS-NOC deployment, you must transfer the file to the NOC (primary) and the DRC (standby) VMs.

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

      where address is the NOC or DRC MnCMain VM IP address

    11. Enter the following to delete the nspca.tar file and generated certificate files, which present a security risk.

      # rm -rf /root/ca/* ↵

    12. Enter the following to close the console window:

      # exit ↵

4 

Perform Step 5 to Step 14 on your standalone WS-NOC system. In an HA deployment, perform these steps on your DRC (standby) WS-NOC system.

Configure integration
 
5 

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

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:

    $MNC_HOME/config/bench/configuration.json

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

  3. If the NSP is an HA 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

Note: When NSP is installed with FQDN, it is mandatory to provide the IPv4/IPv6 parameters along with the NSP alias.

7 

Perform one of the following:

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

    # $MNC_HOME/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 $MNC_HOME/setup/generateAndAlignCertificates.sh ↵

    The WS-NOC server restarts.

  3. Restart the ws-ingress process after the WS-NOC server restart is completed:

    # docker restart ws-ingress ↵

Note: It may take up to 20 minutes for the WS-NOC option to appear in the NSP menu.

8 

Copy the required Avro files from OLCS to $MNC_HOME/app/addon/patchJARS.

Note: To determine the Avro files that are required for your deployment, refer to the NSP Release Notice.

9 

Execute:

# touch /mcp/config/bench/patchJarsEnable.cfg and enter the NSP version in the file.

10 

If the NSP deployment is not a 3 NIC deployment, edit the $MNC_HOME/config/mnc-fm/env.cfg file, adding the following as the last entry:

env;KAFKA_MULTI_ITF_ORDER=CLIENT

11 

Execute:

# $MNC_HOME/app/common/bench_config.sh ↵

# ws.sh restart containerName=mnc-fm ↵

12 

Execute the following command to verify that the correct Avro files are being used by WaveSuite:

# docker logs mnc-fm ↵

13 

On the WS-NOC VM, enter the following:

# $MNC_HOME/setup/config.sh ↵

The WS-NOC configuration is updated.

14 

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

    where component is the entry that you want to remove from "System Control"; for example, "nsp-assurance-tomcat", "nsp-platform-tomcat" and so on.

  3. Enter the following to close the console shell:

    # exit ↵

15 

Perform one of the following:

  1. For a standalone WS-NOC deployment, this procedure is now complete. Close the console windows and proceed to To enable NSP and WS-NOC Release 24.12 or later compatibility.

  2. For an HA WS-NOC deployment, proceed to Step 16.

HA-specific configuration
 
16 

Perform the following steps.

  1. Stop HA data replication as described in the WaveSuite HA User Guide.

  2. Log in as the root user on the WS-NOC NOC (primary) VM.

  3. Perform a WS-NOC HA switchover.

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

  4. Log in as the root user on the new WS-NOC DRC (standby) VM.

  5. Start HA data replication as described in the WaveSuite HA User Guide.

  6. Close the console windows.

17 

Repeat Step 5 to Step 14 on the new WS-NOC DRC (standby) VM — which was formerly the NOC (primary) VM.

Afterwards, go to Step 18.

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

Log in to the WS-NOC VM.

19 

Enter the following:

# docker exec -ti otntomcat bash ↵

A command shell opens in the otntomcat container.

20 

Enter the following:

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

21 

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

22 

Set the nspIsConfigured parameter to false.

23 

Save and close the file.

24 

Enter the following to close the console shell:

# exit ↵

25 

Refresh the GUI page.

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

Post-integration steps required when using custom TLS certificates
 
26 

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.

Note: For shared-mode deployments, Subject Alternative Name (SAN) must contain the same list included in WaveSuite CSR, along with ws-ingress and NSP_IP/FQDN.

27 

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 ↵

28 

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

29 

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 ↵

30 

Close the open console windows.

31 

Perform To enable NSP and WS-NOC Release 24.12 or later compatibility.

End of steps