To integrate a Release 25.12 or later WS-NOC/RC and the NSP

Purpose
CAUTION 

CAUTION

System Degradation

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

NSP and WavseSuite 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 a WS-NOC/RC system to an existing NSP deployment does not restore the WS-NOC/RC databases. The WS-NOC/RC 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/RC system and user settings in the NSP.

CAUTION 

CAUTION

Service Disruption

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

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

Perform this procedure to add an existing Release 25.12 or later WS-NOC/RC 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/RC supports only IPv4, so can be integrated only with an NSP system that uses IPv4 in the client and internal networks.

Note: WS-NOC/RC should be installed with SELinux in disabled state.

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/RC server station—root

  • on each WS-NOC/RC main VM—mncmaintuser

  • on each WS-NOC/RC MnCMain VM—root or NSP admin

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/RC is running and operational.

2 

Install IPCalc on each WS-NOC/RC 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/RC server:

      Note: In an HA (high availability) WS-NOC/RC 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 16 on your standalone WS-NOC/RC system. In an HA (high availability) deployment, stop HA data replication as described in the WaveSuite HA User Guide and perform these steps on your standby WS-NOC/RC system.

Configure integration
 
5 

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

6 

Perform the following steps.

Note: When NSP is set as the authentication server for WS-NOC/RC, a corresponding WS-NOC/RC user with the required permissions must exist for each NSP user created for the WS-NOC/RC. See the WS-NOC Administration Guide for information about WS-NOC/RC 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/RC remote authentication parameters.

  3. If the NSP is an HA (high availability) deployment, you must also configure the parameters in the remoteAuthentication.drc section.

  4. Save and close the configuration.json file.

Table 11-4: WS-NOC/RC 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 

If the NSP uses FQDNs to communicate, add each NSP FQDN to the WS-NOC/RC configuration.

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

    $MNC_HOME/config/bench/fqdn.cfg file

  2. Edit the following lines to read as shown below:

    nsp-a;FQDN_a;address_a

    nsp-b;FQDN_b;address_b

    where

    FQDN_a is the primary NSP cluster FQDN

    FQDN_b is the standby NSP cluster FQDN

    address_a is the IPv4 address of the primary NSP cluster

    address_b is the IPv4 address of the standby NSP cluster

8 

Execute:

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

9 

Execute:

# $MNC_HOME/setup/config.sh ↵

Note: This command must be run only once — on the WS-NOC/RC NOC (primary) VM — whether integration is being performed on the active or standby WS-NOC/RC.

10 

Perform one of the following:

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

    # $MNC_HOME/setup/mnc.sh restart system ↵

    The WS-NOC/RC restarts.

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

    # sudo $MNC_HOME/setup/generateAndAlignCertificates.sh ↵

    The WS-NOC/RC server restarts.

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

11 

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.

12 

Edit the $MNC_HOME/app/addon/patchJARS/patchJARS.cfg file, ensuring the following content is present:

#container name;jar path;jar name

#JAR COPY

mnc-fm;/nfmt/instance/nfmt-adapters/lib/common;shared-equipment-model-*-avro.jar

mnc-fm;/nfmt/instance/nfmt-adapters/lib/common;shared-fm-model-*-avro.jar

mnc-fm;/nfmt/instance/nfmt-adapters/lib/common;shared-service-model-*-avro.jar

mnc-fm;/nfmt/instance/EVT/evt-lib;shared-fm-model-*-avro.jar

mnc-fm;/nfmt/instance/EVT/evt-lib;shared-fm-model-[0-9]*.jar

mnc-fm;/nfmt/instance/nfmt-adapters/lib/common;shared-registration-service-core*.jar

#container name;war path;jar name

#WAR COPY

mnc-fm;/nfmt/instance/nfmt-adapters/nfmt-adapters.war;shared-fm-model-*-avro.jar

mnc-fm;/nfmt/instance/nfmt-adapters/nfmt-adapters.war;shared-equipment-model-*-avro.jar

mnc-fm;/nfmt/instance/nfmt-adapters/nfmt-adapters.war;shared-service-model-*-avro.jar

mnc-fm;/nfmt/instance/nfmt-adapters/nfmt-adapters.war;shared-registration-service-core*.jar

13 

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

14 

Execute:

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

# ws.sh restart containerName=mnc-fm ↵

15 

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

# docker logs mnc-fm ↵

The following is an example of what should be observed in the logs:

deleting: WEB-INF/lib/shared-equipment-model-3.2.0-rel.35-avro.jar

Copying new version: shared-equipment-model-2.2.0-rel.42-avro.jar

Successfully updated JAR in WAR

16 

Remove references to all nsp and nspos containers that the WS-NOC/RC 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 ↵

HA-specific configuration
 
17 

Perform the following steps.

  1. Log in as the root user on the active WS-NOC/RC.

  2. Perform a WS-NOC/RC HA (high availability) switchover.

    The former standby WS-NOC/RC is the new active WS-NOC/RC.

  3. Log in as the root user on the new standby WS-NOC/RC.

  4. Repeat Step 5 to Step 16 on the new standby WS-NOC/RC.

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

  6. Close the console windows.

Post-integration steps required when using custom TLS certificates
 
18 

If you are providing your own TLS certificates and the WS-NOC/RC is a DR deployment, perform the actions described in “H.4 Customer Certificate” in the WaveSuite Installation/Migration Guide to align the HA (high availability) 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.

19 

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 ↵

20 

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

21 

Navigate to System Control in the WS-NOC/RC 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 ↵

22 

Close the open console windows.

23 

Perform To enable NSP and WS-NOC/RC Release 25.12 or later compatibility.

End of steps