Create NSP deployer host VM

Download the following from the NSP downloads page on the Nokia Support portal:

Note: You must also download the .cksum file associated with each.

• NSP_K8S_DEPLOYER_R_r.tar.gz—bundle for installing the registry and deploying the container environment

• one of the following RHEL OS images for creating the NSP deployer host and NSP cluster VMs:

  • NSP_K8S_PLATFORM_RHEL8_yy_mm.qcow2

  • NSP_K8S_PLATFORM_RHEL8_yy_mm.ova

• NSP_DEPLOYER_R_r.tar.gz—bundle for installing the NSP application software

where

R_r is the NSP release ID, in the form Major_minor

yy_mm represents the year and month of issue

It is strongly recommended that you verify the message digest of each NSP image file or software bundle that you download from the Nokia Support portal. The download page includes checksums for comparison with the output of the RHEL md5sum, sha256sum, or sha512sum command.

To verify a file checksum, perform the following steps.

1. Enter the following:

   # command file ↵

   where

   command is md5sum, sha256sum, or sha512sum

   file is the name of the file to check

   A file checksum is displayed.

2. Compare the checksum value and the value in the .cksum file.

3. If the values do not match, the file download has failed. Download a new copy of the file, and then repeat this step.

Log in as the root user on the station designated for the NSP deployer host VM.

Open a console window.

Perform one of the following to create the NSP deployer host VM.

Note: The NSP deployer host VM requires a hostname; you must change the default of ‘localhost’ to an actual hostname.

1. Deploy the downloaded NSP_K8S_PLATFORM_RHEL8_yy_mm.qcow2 disk image; perform Step 6 to Step 16 of To deploy an NSP RHEL qcow2 disk image.

2. Deploy the NSP_K8S_PLATFORM_RHEL8_yy_mm.ova disk image; see the documentation for your virtualization environment for information.

   Note: For OVA-image deployment, it is strongly recommended that you mount the /opt directory on a separate hard disk that has sufficient capacity to allow for future expansion.

3. Manually install the RHEL OS and configure the disk partitions, as described in Manual NSP RHEL OS installation and Chapter 2, NSP disk setup and partitioning.

Configure NSP deployer host networking

Enter the following to open a console session on the NSP deployer host:

# virsh console deployer_host ↵

You are prompted for credentials.

Enter the following credentials:

• username—root

• password—available from technical support

A virtual serial console session opens on the deployer host VM.

Enter the following:

# ip a ↵

The available network interfaces are listed; information like the following is displayed for each:

if_n: if_name: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000

    link/ether MAC_address

    inet IPv4_address/v4_netmask brd broadcast_address scope global noprefixroute if_name

       valid_lft forever preferred_lft forever

    inet6 IPv6_address/v6_netmask scope link

       valid_lft forever preferred_lft forever

Record the if_name and MAC_address values of the interface that you intend to use.

Enter the following:

# nmcli con add con-name con_name ifname if_name type ethernet mac MAC_address ↵

where

con_name is a connection name that you assign to the interface for ease of identification

if_name is the interface name recorded in Step 9

MAC_address is the MAC address recorded in Step 9

Enter the following:

# nmcli con mod con_name ipv4.addresses IP_address/netmask ↵

where

con_name is the connection name assigned in Step 10

IP_address is the IP address to assign to the interface

netmask is the subnet mask to assign

Enter the following:

# nmcli con mod con_name ipv4.method static ↵

Enter the following:

# nmcli con mod con_name ipv4.gateway gateway_IP ↵

gateway_IP is the gateway IP address to assign

Enter the following:

Note: You must specify a DNS name server. If DNS is not deployed, you must use a non-routable IP address as a nameserver entry.

Note: Any hostnames used in an NSP deployment must be resolved by a DNS server.

Note: An NSP deployment that uses IPv6 networking for client communication must use a hostname configuration.

# nmcli con mod con_name ipv4.dns nameserver_1,nameserver_2...nameserver_n ↵

where nameserver_1 to nameserver_n are the available DNS name servers

To optionally specify one or more DNS search domains, enter the following:

# nmcli con mod con_name ipv4.dns-search search_domains ↵

where search_domains is a comma-separated list of DNS search domains

Enter the following to reboot the VM:

# systemctl reboot ↵

Install NSP Kubernetes registry

Enter the following on the deployer host VM:

# mkdir /opt/nsp ↵

Copy the downloaded NSP_K8S_DEPLOYER_R_r.tar.gz bundle file to the following directory:

/opt/nsp

Enter the following:

# cd /opt/nsp ↵

Enter the following:

# tar xvf NSP_K8S_DEPLOYER_R_r.tar.gz ↵

where R_r is the NSP release ID, in the form Major_minor

The bundle file is expanded, and the following directories are created:

• /opt/nsp/nsp-k8s-deployer-release-ID

• /opt/nsp/nsp-registry-release-ID

Remove the bundle file to save disk space; enter the following:

# rm -f NSP_K8S_DEPLOYER_R_r.tar.gz ↵

The file is deleted.

Enter the following:

# cd nsp-registry-release-ID/bin ↵

Enter the following:

# ./nspregistryctl install ↵

The following prompt is displayed.

Enter a registry admin password:

Create a registry administrator password, and enter the password.

The following prompt is displayed.

Confirm the registry admin password:

Re-enter the password.

The registry installation begins, and messages like the following are displayed.

✔ New installation detected.

✔ Initialize system.

date time Copy container images ...

date time Install/update package [container-selinux] ...

✔ Installation of container-selinux has completed.

date time Install/update package [k3s-selinux] ...

✔ Installation of k3s-selinux has completed.

date time Setup required tools ...

✔ Initialization has completed.

date time Install k3s ...

date time Waiting for up to 10 minutes for k3s initialization ...

..............................................

✔ Installation of k3s has completed.

➜ Generate self-signed key and cert.

date time Registry TLS key file: /opt/nsp/nsp-registry/tls/nokia-nsp-registry.key

date time Registry TLS cert file: /opt/nsp/nsp-registry/tls/nokia-nsp-registry.crt

date time Install registry apps ...

date time Waiting for up to 10 minutes for registry services to be ready ...

..........

✔ Registry apps installation is completed.

date time Generate artifacts ...

date time Apply artifacts ...

date time Setup registry.nsp.nokia.local certs ...

date time Setup a default project [nsp] ...

date time Setup a cron to regenerate the k3s certificate [nsp] ...

✔ Post configuration is completed.

✔ Installation has completed.

Enter the following periodically to display the status of the Kubernetes system pods:

Note: You must not proceed to the next step until each pod STATUS reads Running or Completed.

# kubectl get pods -A ↵

The pods are listed.

Create NSP cluster VMs

For each required NSP cluster VM, perform one of the following to create the VM.

Note: Each NSP cluster VM requires a hostname; you must change the default of ‘localhost’ to an actual hostname.

1. Deploy the downloaded NSP_K8S_PLATFORM_RHEL8_yy_mm.qcow2 disk image; perform Step 6 to Step 16 of To deploy an NSP RHEL qcow2 disk image.

2. Deploy the NSP_K8S_PLATFORM_RHEL8_yy_mm.ova disk image; see the documentation for your virtualization environment for information.

   Note: For OVA-image deployment, it is strongly recommended that you mount the /opt directory on a separate hard disk that has sufficient capacity to allow for future expansion.

3. Manually install the RHEL OS and configure the disk partitions, as described in Manual NSP RHEL OS installation and Chapter 2, NSP disk setup and partitioning.

Record the MAC address of each interface on each VM.

Perform Step 30 to Step 48 for each NSP cluster VM to configure the required interfaces.

Configure NSP cluster networking

Enter the following to open a console session on the VM:

# virsh console NSP_cluster_VM ↵

where NSP_cluster_VM is the VM name

You are prompted for credentials.

Enter the following credentials:

• username—root

• password—available from technical support

A virtual serial console session opens on the NSP cluster VM.

Enter the following:

# ip a ↵

The available network interfaces are listed; information like the following is displayed for each:

if_n: if_name: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000

    link/ether MAC_address

    inet IPv4_address/v4_netmask brd broadcast_address scope global noprefixroute if_name

       valid_lft forever preferred_lft forever

    inet6 IPv6_address/v6_netmask scope link

       valid_lft forever preferred_lft forever

Record the if_name and MAC_address values of the interfaces that you intend to use.

Enter the following for each interface:

# nmcli con add con-name con_name ifname if_name type ethernet mac MAC_address ↵

where

con_name is a connection name that you assign to the interface for ease of identification; for example, ClientInterface or MediationInterface

if_name is the interface name recorded in Step 33

MAC_address is the MAC address recorded in Step 33

Enter the following for each interface:

# nmcli con mod con_name ipv4.addresses IP_address/netmask ↵

where

con_name is the connection name assigned in Step 34

IP_address is the IP address to assign to the interface

netmask is the subnet mask to assign

Enter the following for each interface:

# nmcli con mod con_name ipv4.method static ↵

Enter the following for each interface:

# nmcli con mod con_name ipv4.gateway gateway_IP ↵

gateway_IP is the gateway IP address to assign

Note: This command sets the default gateway on the primary interface and the gateways for all secondary interfaces.

Enter the following for all secondary interfaces:

# nmcli con mod con_name ipv4.never-default yes ↵

Enter the following for each interface:

Note: You must specify a DNS name server. If DNS is not deployed, you must use a non-routable IP address as a nameserver entry.

Note: Any hostnames used in an NSP deployment must be resolved by a DNS server.

Note: An NSP deployment that uses IPv6 networking for client communication must use a hostname configuration.

# nmcli con mod con_name ipv4.dns nameserver_1,nameserver_2...nameserver_n ↵

where nameserver_1 to nameserver_n are the available DNS name servers

To optionally specify one or more DNS search domains, enter the following for each interface:

# nmcli con mod con_name ipv4.dns-search search_domains ↵

where search_domains is a comma-separated list of DNS search domains

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

/etc/sysctl.conf

Locate the following line:

vm.max_map_count=value

Edit the line to read as follows; if the line is not present, add the line to the end of the file:

vm.max_map_count=262144

Save and close the file.

If you are installing in a KVM environment, enter the following:

# mkdir /opt/nsp ↵

It is essential that the disk I/O on each VM in the NSP cluster meets the NSP specifications.

On each NSP cluster VM, perform the tests described in “Disk performance tests” in the NSP Troubleshooting Guide.

If any test fails, contact technical support for assistance.

Enter the following to reboot the NSP cluster VM:

# systemctl reboot ↵

Close the console session by pressing Ctrl+] (right bracket).

Deploy Kubernetes environment

Enter the following on the NSP deployer host

# cd /opt/nsp/nsp-k8s-deployer-release-ID/config ↵

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

k8s-deployer.yml

Configure the following parameters for each NSP cluster VM; see the descriptive text at the head of the file for parameter information, and Hostname configuration requirements for general configuration information.

- nodeName: noden

  nodeIp: private_IP_asdress

  accessIp: public_IP_asdress

Note: The nodeName value:

• can include only ASCII alphanumeric and hyphen characters

• cannot include an upper-case character

• cannot begin or end with a hyphen

• cannot begin with a number

• cannot include an underscore

• must end with a number

Configure the following parameter, which specifies whether dual-stack NE management is enabled:

Note: Dual-stack NE management can function only when the network environment is appropriately configured, for example:

• Only valid, non-link-local static or DHCPv6-assigned addresses are used.

• A physical or virtual IPv6 subnet is configured for IPv6 communication with the NEs.

  enable_dual_stack_networks: value

where value must be set to true if the cluster VMs support both IPv4 and IPv6 addressing

Configure the following parameter in the cluster section:

  hosts: "path"

where path is the location of the hosts file for deploying the NSP cluster

If you have disabled remote root access to the NSP cluster VMs, configure the following parameters in the cluster section, sshAccess subsection:

  sshAccess:

    userName: "user"

    privateKey: "path"

where

user is the designated root-equivalent user

path is the SSH key path, for example, /home/user/.ssh/id_rsa

Save and close the k8s-deployer.yml file.

Create a backup copy of the updated k8s-deployer.yml file, and transfer the backup copy to a station that is separate from the NSP system, and preferably in a remote facility.

Note: The backup file is crucial in the event of an NSP deployer host failure, and must be copied to a separate station.

Enter the following:

# cd /opt/nsp/nsp-k8s-deployer-release-ID/bin ↵

Enter the following to create the cluster configuration:

# ./nspk8sctl config -c ↵

The following is displayed when the creation is complete:

✔ Cluster hosts configuration is created at: /opt/nsp/nsp-k8s-deployer-release-ID/config/hosts.yml

Enter the following to import the Kubernetes container images to the registry:

# ./nspk8sctl import ↵

Messages like the following are displayed as the import proceeds:

✔ Pushing artifacts to registry (it takes a while) ...

date time Load container image from [/opt/nsp/nsp-k8s-deployer-release-ID/artifact/nsp-k8s-R.r.0-rel.tar.gz] ...

date time Push image [image_name] to registry.nsp.nokia.local/library ...

date time Push image [image_name] to registry.nsp.nokia.local/library ...

.

.

.

date time Push image [image_name] to registry.nsp.nokia.local/library ...

If remote root access is disabled, switch to the designated root-equivalent user.

You must generate an SSH key for password-free NSP deployer host access to each NSP cluster VM.

Enter the following:

# ssh-keygen -N "" -f ~/.ssh/id_rsa -t rsa ↵

Enter the following for each NSP cluster VM to distribute the SSH key to the VM.

# ssh-copy-id -i ~/.ssh/id_rsa.pub address ↵

where address is the NSP cluster VM IP address

If remote root access is disabled, switch back to the root user.

Enter the following:

.# ./nspk8sctl install ↵

The NSP Kubernetes environment is deployed.

The NSP cluster member named node1 is designated the NSP cluster host for future configuration activities; record the NSP cluster host IP address for future reference.

Check NSP cluster status

Open a console window on the NSP cluster host.

Enter the following periodically to display the status of the Kubernetes system pods:

Note: You must not proceed to the next step until each pod STATUS reads Running or Completed.

# kubectl get pods -A ↵

The pods are listed.

Enter the following periodically to display the status of the NSP cluster nodes:

Note: You must not proceed to the next step until each node STATUS reads Ready.

# kubectl get nodes -o wide ↵

The NSP cluster nodes are listed, as shown in the following three-node cluster example:

NAME    STATUS   ROLES    AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   

node1   Ready    master   nd    version   int_IP        ext_IP

node2   Ready    master   nd    version   int_IP        ext_IP

node3   Ready    <none>   nd    version   int_IP        ext_IP

Configure NSP software

Open a console window on the NSP deployer host.

Enter the following:

# cd /opt/nsp ↵

Enter the following:

# tar xvf NSP_DEPLOYER_R_r.tar.gz ↵

where R_r is the NSP release ID, in the form Major_minor

The bundle file is expanded, and the following directory is created:

/opt/nsp/NSP-CN-DEP-release-ID/NSP-CN-release-ID

Enter the following:

# rm -f NSP_DEPLOYER_R_r.tar.gz ↵

The bundle file is deleted.

Open the following file using a plain-text editor such as vi to specify the system parameters and enable the required installation options:

/opt/nsp/NSP-CN-DEP-release-ID/NSP-CN-release-ID/config/nsp-config.yml

Note: See nsp-config.yml file format for configuration information.

Note: You must preserve the leading spaces in each line.

Note: The following REST-session parameters in the nsp section of the nsp-config.yml file apply only to an NSP system that uses CAS authentication, and are not to be configured otherwise:

• ttlInMins

• maxNumber

Configure the cluster addressing parameters in the platform section as shown below; you must specify the client_address value, which is used as the default for any optional address parameter that you do not configure:

Note: If the client network uses IPv6, you must specify the NSP cluster hostname as the client_address value.

  advertisedAddress: "client_address"

  mediationAdvertisedAddress: "IPv4_mediation_address"

  mediationAdvertisedAddressIpv6: "IPv6_mediation_address"

  internalAdvertisedAddress: "internal_cluster_address"

  clusterHost: "cluster_host_address"

where

client_address is the public IPv4 address or hostname that is advertised to clients

IPv4_mediation_address is the optional address for IPv4 NE management traffic

IPv6_mediation_address is the optional address for IPv6 NE management traffic

internal_cluster_address is the optional IPv4 or IPv6 address for internal NSP communication

cluster_host_address is the address of NSP cluster member node1, which is subsequently used for cluster management operations

Configure the remaining parameters in the platform section as shown below:

platform section, docker subsection:

    repo: "registry.nsp.nokia.local/nsp/images"

    pullPolicy: "IfNotPresent"

platform section, helm subsection:

    repo: "oci://registry.nsp.nokia.local/nsp/charts"

    timeout: "300"

If you are creating a multi-node cluster, perform the following steps.

1. Configure the following parameters in the platform section, elb subsection as shown below:

   elb:

     deploy: true

     virtualIpAddress: "client_VIP"

      mediationVirtualIpAddress: "IPv4_mediation_VIP"

      mediationVirtualIpAddressIpv6: "IPv6_mediation_VIP"

      internalVirtualIpAddress: "internal_VIP"

   where

   client_VIP is the virtual cluster address for client access

   IPv4_mediation_VIP is the virtual cluster address for IPv4 network mediation

   IPv6_mediation_VIP is the virtual cluster address for IPv6 network mediation

   internal_VIP is the virtual cluster address for internal communication

2. For each NSP cluster VM, add the following group of lines to the elb subsection under hosts:

        - hostAddress: "client_IP"

          mediationHostAddress: "IPv4_mediation_IP"

          mediationHostAddressIpv6: "IPv6_mediation_IP"

          internalHostAddress: "internal_address"

where

client_IP is the address of the VM interface to the client network

IPv4_mediation_IP is the address of the VM interface to the IPv4 mediation network

IPv6_mediation_IP is the address of the VM interface to the IPv6 mediation network

internal_IP is the address of the VM interface to the internal network

Note: The deployer host requires access to the client network.

Configure the type parameter in the deployment section as shown below:

deployment:

    type: "deployment_type"

where deployment_type is one of the parameter options listed in the section

Configure the tls parameters in the deployment section as shown below:

Note: The customKey, customCert, and customCaCert parameters are required only if you are using custom TLS certificates.

See To generate custom TLS certificate files for the NSP for information about configuring custom TLS certificates.

   tls:                     

     truststorePass: "truststore_password"

     keystorePass: "keystore_password"

     customKey: private_server_key_location

     customCert: public_server_key_location

     customCaCert: public_CA_key_location

If the NSP system is a DR deployment, configure the parameters in the dr section as shown below:

dr:

   dcName: "data_center"

   mode: "deployment_mode"

   peer: "peer_address"

   internalPeer: "peer_internal_address"

   peerDCName: "peer_data_center"

where

data_center is the unique alphanumeric name to assign to the cluster

deployment_mode is the case-sensitive deployment type, dr or standalone

peer_address is the address at which the peer data center is reachable over the client network

peer_internal_address is the address at which the peer data center is reachable over the internal network

peer_data_center is the unique alphanumeric name of the peer cluster

If you are integrating one or more existing systems or components with the NSP, configure the required parameters in the integrations section.

For example:

To integrate a standalone NFM-P system, you must configure the nfmp parameters in the section as shown below:

Note: When the section includes an NFM-P IP address, the NSP UI is accessible only when the NFM-P is operational.

Note: In the client section of samconfig on the NFM-P main servers, if the address for client access is set using the hostname parameter, the primaryIp and standbyIp values in the nfmp section of the NSP configuration file, nsp-config.yml, must be set to hostnames.

Likewise, if the public-ip parameter in the client section is configured on the main server, the primaryIp and standbyIp values in the nsp-config.yml file must be set to IP addresses.

 integrations:

   nfmp:

     primaryIp: "main_server_address"

     standbyIp: 

     tlsEnabled: true | false

If all of the following are true, configure the following parameters in the integrations section:

• You are integrating an NFM-P system with the NSP.

• You want the NFM-P to forward system metrics to the NSP cluster.

• The NFM-P main server and main database are on separate stations:

    nfmpDB:

      primaryIp: ""

      standbyIp: ""

If both of the following are true, configure the following parameters in the integrations section:

• You are integrating an NFM-P system with the NSP.

• You want the NFM-P to forward system metrics to the NSP cluster.

• The NFM-P system includes one or more auxiliary servers:

    auxServer:

      primaryIpList: ""

      standbyIpList: ""

If the NSP deployment includes one or more Release 22 analytics servers that are to remain at the earlier release, you must enable NSP and analytics compatibility; otherwise, you can skip this step.

Set the legacyPortEnabled parameter in the analyticsServer subsection of the integrations section to true as shown below:

  analyticsServer:

    legacyPortEnabled: true

If the NSP deployment includes an auxiliary database, configure the required parameters.

Note: If the NSP deployment is to be integrated with a Release 22 or 23 NFM-P system, the auxiliary database release must match the NFM-P release.

Note: If the deployment is geo-redundant and is to include the NFM-P, you must record the following values for addition to the local NFM-P main server configuration:

• ipList addresses, which must you must set as the cluster_1 addresses in the local main server configuration

• standbyIpList addresses, which you must set as the cluster_2 addresses local main server configuration

1. Locate the following section:

       auxDb:

         secure: "true"

         ipList: ""

         standbyIpList: ""

2. Edit the section to read as follows:

   Note: If the auxiliary database is at the same Release as the NSP, the secure parameter must be set to true.

       auxDb:

         secure: "true"

         ipList: "cluster_1_IP1,cluster_1_IP2...cluster_1_IPn"

         standbyIpList: "cluster_2_IP1,cluster_2_IP2...cluster_2_IPn"

   where

   cluster_1_IP1, cluster_1_IP2...cluster_1_IPn are the external IP addresses of the stations in the local cluster

   cluster_2_IP1, cluster_2_IP2...cluster_2_IPn are the external IP addresses of the stations in the peer cluster; required only for geo-redundant deployment

If you are including VMs to host MDM instances in addition to a standard or enhanced NSP cluster deployment, configure the following mdm parameters in the modules section:

 modules:

   mdm:

     clusterSize: members

     backupServers: n

where

members is the total number of VMs to host MDM instances

n is the total number of VMs to allocate as backup instances

Configure the user authentication parameters in the sso section; see NSP SSO configuration parameters for configuration information.

Save and close the nsp-config.yml file.

Ensure that the location of your license.zip file, as indicated in the nsp-config.yml file, is in the correct location on the NSP deployer host.

If you are integrating an existing NFM-P system with the NSP, and the NFM-P TLS certificate is self-signed or root-CA-signed, you must use the NFM-P TLS artifacts in the NSP system.

Transfer the following TLS files from the NFM-P to the /opt/nsp/NSP-CN-DEP-release-ID/NSP-CN-release-ID/tls/ca directory:

• ca.pem

• ca.key

• ca_internal.pem

• ca_internal.key

If you are configuring the standby NSP cluster in a DR deployment, obtain the TLS and telemetry artifacts from the NSP deployer host in the primary data center.

1. If remote root access is disabled, switch to the root-equivalent user specified in Step 54.

2. Enter the following:

   # scp -r address:/opt/nsp/NSP-CN-DEP-release-ID/NSP-CN-release-ID/tls/ca/* /opt/nsp/NSP-CN-DEP-release-ID/NSP-CN-release-ID/tls/ca/ ↵

   where address is the address of the NSP deployer host in the primary cluster

3. Enter the following:

   # scp address:/opt/nsp/NSP-CN-DEP-release-ID/NSP-CN-release-ID/tls/telemetry/* /opt/nsp/NSP-CN-DEP-release-ID/NSP-CN-release-ID/tls/telemetry/ ↵

4. Enter the following:

   # mkdir -p /opt/nsp/nsp-configurator/generated ↵

5. Enter the following:

   # scp address:/opt/nsp/nsp-configurator/generated/nsp-keycloak-*-secret /opt/nsp/nsp-configurator/generated/ ↵

6. If remote root access is disabled, switch back to the root user.

If you are not including any dedicated MDM nodes in addition to the number of member nodes in a standard or enhanced NSP cluster, go to Step 100.

Log in as the root user on the NSP cluster host.

Open a console window.

If remote root access is disabled, switch to the root-equivalent user specified in Step 54.

Perform the following steps for each additional MDM node.

1. Enter the following to open an SSH session on the MDM node.

   Note: The root password for a VM created using the Nokia qcow2 image is available from technical support.

   # ssh MDM_node ↵

   where MDM_node is the node IP address

2. Enter the following:

   # mkdir -p /opt/nsp/volumes/mdm-server ↵

3. Enter the following:

   # chown -R 1000:1000 /opt/nsp/volumes ↵

4. Enter the following:

   # exit ↵

If remote root access is disabled, switch back to the root user.

Enter the following:

# kubectl get nodes -o wide ↵

A list of nodes like the following is displayed.

NAME    STATUS   ROLES    AGE   VERSION   INTERNAL-IP       EXTERNAL-IP   

node1   Ready    master   nd   version   int_IP   ext_IP

node2   Ready    master   nd   version   int_IP   ext_IP

node3   Ready    <none>   nd   version   int_IP   ext_IP

Record the NAME value of each node whose INTERNAL-IP value is the IP address of a node that has been added to host an additional MDM instance.

For each node, enter the following sequence of commands:

# kubectl label node node mdm=true ↵

# kubectl cordon node ↵

where node is the recorded NAME value of the cordoned MDM node

Label NSP cluster nodes

Log in as the root user on the NSP deployer host.

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

/opt/nsp/NSP-CN-DEP-release-ID/config/nsp-deployer.yml

Configure the following parameters:

  hosts: "hosts_file"

  labelProfile: "../ansible/roles/apps/nspos-labels/vars/labels_file"

where

hosts_file is the absolute path of the hosts.yml file created in Step 58, typically /opt/nsp/nsp-k8s-deployer-release-ID/config/hosts.yml

labels_file is the file name below that corresponds to the cluster deployment type specified in Step 77:

• node-labels-basic-1node.yml

• node-labels-basic-sdn-2nodes.yml

• node-labels-enhanced-6nodes.yml

• node-labels-enhanced-sdn-9nodes.yml

• node-labels-standard-3nodes.yml

• node-labels-standard-4nodes.yml

• node-labels-standard-sdn-4nodes.yml

• node-labels-standard-sdn-5nodes.yml

If you have disabled remote root access to the NSP cluster VMs, configure the following parameters in the cluster section, sshAccess subsection:

  sshAccess:

    userName: "user"

    privateKey: "path"

where

user is the designated root-equivalent user

path is the SSH key path, for example, /home/user/.ssh/id_rsa

Save and close the nsp-deployer.yml file.

Open a console window.

Enter the following:

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

Enter the following to apply the node labels to the NSP cluster:

# ./nspdeployerctl config ↵

Enter the following to import the NSP images and Helm charts to the NSP Kubernetes registry

# ./nspdeployerctl import ↵

Deploy NSP software, monitor initialization

Enter the following to deploy the NSP software in the NSP cluster:

# ./nspdeployerctl install --config --deploy ↵

The specified NSP functions are installed and initialized.

Monitor and validate the NSP cluster initialization.

Note: You must not proceed to the next step until each NSP pod is operational.

1. On the NSP cluster host, enter the following every few minutes:

   # kubectl get pods -A ↵

   The status of each NSP cluster pod is displayed; the NSP cluster is operational when the status of each pod is Running or Completed, with the following exception.

   • If you are including any MDM VMs in addition to a standard or enhanced NSP cluster deployment, the status of each mdm-server pod is shown as Pending, rather than Running or Completed.

2. If the Network Operations Analytics - Baseline Analytics installation option is enabled, ensure that the following pods are listed; otherwise, see the NSP Troubleshooting Guide for information about troubleshooting an errored pod:

   Note: The output for a non-HA deployment is shown below; an HA cluster has three sets of three baseline pods, three rta-ignite pods, and two spark-operator pods.

   • analytics-rtanalytics-tomcat

   • baseline-anomaly-detector-n-exec-1

   • baseline-trainer-n-exec-1

   • baseline-window-evaluator-n-exec-1

   • rta-anomaly-detector-app-driver

   • rta-ignite-0

   • rta-trainer-app-driver

   • rta-windower-app-driver

   • spark-operator-m-n

3. If any pod fails to enter the Running or Completed state, see the NSP Troubleshooting Guide for information about troubleshooting an errored pod.

If you are including any MDM VMs in addition to a standard or enhanced NSP cluster deployment, perform the following steps to uncordon the nodes cordoned in Step 99.

1. Enter the following:

   # kubectl get pods -A | grep Pending ↵

   The pods in the Pending state are listed; an mdm-server pod name has the format mdm-server-ID.

   Note: Some mdm-server pods may be in the Pending state because the manually labeled MDM nodes are cordoned in Step 99. You must not proceed to the next step if any pods other than the mdm-server pods are listed as Pending. If any other pod is shown, re-enter the command periodically until no pods, or only mdm-server pods, are listed.

2. Enter the following for each manually labeled and cordoned node:

   # kubectl uncordon node ↵

   where node is an MDM node name recorded in Step 99

   The MDM pods are deployed.

   Note: The deployment of all MDM pods may take a few minutes.

3. Enter the following periodically to display the MDM pod status:

   # kubectl get pods -A | grep mdm-server ↵

4. Ensure that the number of mdm-server-ID instances is the same as the mdm clusterSize value in nsp-config.yml, and that each pod is in the Running state. Otherwise, contact technical support for assistance.

Close the open console windows.

End of steps