Create CLM deployer host VM

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

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

Note: This step applies only when using a CLM OEM disk image.

• NSP_CLM_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 CLM deployer host and CLM cluster VMs:

  • NSP_K8S_PLATFORM_RHEL8_yy_mm.qcow2

  • NSP_K8S_PLATFORM_RHEL8_yy_mm.ova

• NSP_CLM_DEPLOYER_R_r.tar.gz—bundle for installing the CLM application software

where

R_r is the CLM 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 CLM 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 to host the CLM deployer host VM.

Open a console window.

If the downloaded NSP_CLM_DEPLOYER_R_r.tar.gz file has multiple parts, enter the following to create one NSP_CLM_DEPLOYER_R_r.tar.gz file from the partial image files:

# cat filename.part* >filename.tar.gz ↵

where filename is the image file name

A filename.tar.gz file is created in the current directory.

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

Note: The CLM 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 a 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 RHEL OS installation for CLM and Chapter 4, CLM disk setup and partitioning.

Configure CLM deployer host networking

Enter the following to open a console session on the CLM 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 10

MAC_address is the MAC address recorded in Step 10

Enter the following:

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

where

con_name is the connection name assigned in Step 11

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 a CLM deployment must be resolved by a DNS server.

Note: A CLM 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 CLM Kubernetes registry

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

Enter the following:

# mkdir /opt/nsp ↵

Copy the downloaded NSP_CLM_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_CLM_K8S_DEPLOYER_R_r.tar.gz ↵

where R_r is the CLM 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_CLM_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 CLM cluster VMs

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

Note: Each CLM 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 a 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 RHEL OS installation for CLM and Chapter 4, CLM disk setup and partitioning.

Record the MAC address of each interface on each VM.

Perform Step 32 to Step 50 for each CLM cluster VM to configure the required interfaces.

Configure CLM 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 CLM 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 35

MAC_address is the MAC address recorded in Step 35

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 36

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 a CLM deployment must be resolved by a DNS server.

Note: A CLM 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 CLM cluster meets the CLM specifications.

On each CLM cluster VM, perform the tests described in “To verify disk performance for NSP” in the NSP Troubleshooting Guide.

If any test fails, contact technical support for assistance.

Enter the following to reboot the CLM cluster VM:

# systemctl reboot ↵

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

Deploy Kubernetes environment

Enter the following on the CLM 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 the CLM cluster VM.

- nodeName: noden

  nodeIp: private_IP_address

  accessIp: public_IP_address

  isIngress: value

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

In the following section, specify the virtual IP addresses for the CLM to use as the internal load-balancer endpoints.

Note: A single-node CLM cluster requires at least the client_IP address.

The addresses are the virtualIP values for CLM client, internal, and mediation access that you intend to specify in Step 75 in the nsp-config.yml file.

loadBalancerExternalIps:

    - client_IP

    - internal_IP

The following addresses are not used in CLM and must be left empty.

    - trapV4_mediation_IP

    - trapV6_mediation_IP

    - flowV4_mediation_IP

    - flowV6_mediation_IP

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 CLM cluster

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

  sshAccess:

    userName: "user"

    privateKey: "path"

where

user is the designated CLM ansible 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 CLM system, and preferably in a remote facility.

Note: The backup file is crucial in the event of a CLM 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 ...

For password-free CLM deployer host access to the CLM cluster VMs, you require an SSH key.

To generate and distribute the SSH key, perform the following steps.

1. Enter the following:

   # ssh-keygen -N "" -f path -t rsa ↵

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

   An SSH key is generated.

2. Enter the following for each CLM cluster VM to distribute the key to the VM.

   # ssh-copy-id -i key_file user@address ↵

   where

   user is the designated CLM ansible user configured in Step 57 , if root-user access is restricted; otherwise, user@ is not required

   key_file is the SSH key file, for example, /home/user/.ssh/id_rsa.pub

   address is the CLM cluster VM IP address

Enter the following:

Note: If the CLM cluster VMs do not have the required SSH key, you must include the --ask-pass argument in the following command, and are subsequently prompted for the root password of each cluster member:

nspk8sctl --ask-pass install

.# ./nspk8sctl install ↵

The CLM Kubernetes environment is deployed.

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

Check CLM cluster status

Open a console window on the CLM 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 CLM cluster nodes:

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

# kubectl get nodes -o wide ↵

The CLM cluster nodes are listed, as shown in the following example:

NAME    STATUS   ROLES    AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   

node1   Ready    master   nd    version   int_IP        ext_IP

Configure CLM software

Open a console window on the CLM deployer host.

Enter the following:

# cd /opt/nsp ↵

Enter the following:

# tar xvf NSP_CLM_DEPLOYER_R_r.tar.gz ↵

where R_r is the CLM 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_CLM_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.

Configure the following parameter in the platform section as shown below:

  clusterHost: "cluster_host_address"

where

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

Configure the following CLM cluster address parameters in the platform section, ingressApplications subsection as shown below.

Each address is an address from the ingressApplications section of the k8s-deployer.yml file described in Step 54.

Note: The client_IP value is mandatory; the address is used for interfaces that remain unconfigured, such as in a single-interface deployment.

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

Note: The trapForwarder addresses are not required.

  ingressApplications:

    ingressController:

      clientAddresses:

        virtualIp: "client_IP"

        advertised: "client_public_address"

      internalAddresses:

        virtualIp: "internal_IP"

        advertised: "internal_public_address"

where

client_IP is the address for external client access

internal_IP is the address for internal communication

each public_address value is an optional address to advertise instead of the associated _IP value, for example, in a NAT environment

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"

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

If you are using a custom server certificate, configure the following tls parameter in the deployment section:

   tls:                     

     customCaCert: certificate_path

where certificate_path is the file path of the custom root CA certificate file

If the CLM 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

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

Save and close the nsp-config.yml file.

Ensure that your license.zip file is on the CLM deployer host in the location specified in the nsp-config.yml file.

Configure hosts file

Log in as the root or CLM admin user on the CLM 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 61, 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

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

  sshAccess:

    userName: "user"

    privateKey: "path"

where

user is the designated CLM ansible user

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

Save and close the nsp-deployer.yml file.

Install Kubernetes secrets

If you are configuring the standby cluster in a DR deployment, go to Step 97.

Open a console window on the standalone or primary CLM deployer host.

Enter the following:

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

Enter the following:

# ./nspdeployerctl secret install ↵

The following prompt is displayed:

Would you like to use your own CA key pair for the NSP Internal Issuer? [yes,no]

Perform one of the following.

1. Enter no ↵.

   The CLM generates the internal key and certificate files.

2. Provide your own certificate to secure the internal network.

   1. Enter yes ↵.

      The following messages and prompt are displayed:

   2. Building secret 'ca-key-pair-internal-nspdeployer'

      The CA key pair used to sign certificates generated by the NSP Internal Issuer.

      Please enter the internal CA private key:

   3. Enter the full path of the internal private key.

      The following prompt is displayed:

      Please enter the internal CA certificate:

   4. Enter the full path of the internal certificate:

      The following messages are displayed for each Kubernetes namespace:

      Adding secret ca-key-pair-internal-nspdeployer to namespace namespace...

      secret/ca-key-pair-internal-nspdeployer created

The following prompt is displayed:

Would you like to use your own CA key pair for the NSP External Issuer? [yes,no]

Perform one of the following.

1. Enter no ↵.

   The CLM generates the external key and certificate files.

2. Provide your own certificate to secure the external network.

   1. Enter yes ↵.

      The following messages and prompt are displayed:

      Building secret 'ca-key-pair-external-nspdeployer'

      The CA key pair used to sign certificates generated by the NSP External Issuer.

      Please enter the external CA private key:

   2. Enter the full path of the external private key.

      The following prompt is displayed:

      Please enter the external CA certificate:

   3. Enter the full path of the external certificate:

      The following messages are displayed for each Kubernetes namespace:

      Adding secret ca-key-pair-external-nspdeployer to namespace namespace...

      secret/ca-key-pair-external-nspdeployer created

Would you like to provide a custom private key and certificate for use by NSP endpoints when securing TLS connections over the client network? [yes,no]

Perform one of the following.

1. Enter no ↵.

   The CLM generates the client key and certificate files.

2. Provide your own certificate for the client network.

   1. Enter yes ↵

      The following messages and prompt are displayed:

      Building secret 'nginx-nb-tls-nsp'

      TLS certificate for securing the ingress gateway.

      Please enter the ingress gateway private key:

   2. Enter the full path of the private key file for client access. The private key file is the customKey file from To generate custom TLS certificate files for the CLM.

      The following prompt is displayed:

      Please enter the ingress gateway public certificate:

   3. Enter the full path of the public certificate file for client access. The public certificate file is the customCert file from To generate custom TLS certificate files for the CLM.

      The following prompt is displayed:

      Please enter the ingress gateway public trusted CA certificate bundle:

   4. Enter the full path of the public trusted CA certificate bundle file. The public trusted CA certificate bundle file is the customCaCert file from To generate custom TLS certificate files for the CLM.

      The following message is displayed:

        Adding secret nginx-nb-tls-nsp to namespace namespace...

Your deployment does not include MDM. The following prompt is displayed:

Would you like to provide mTLS certificates for the NSP mediation interface for two-way TLS authentication? [yes,no]

Perform one of the following.

1. Enter no ↵

Back up the Kubernetes secrets.

1. Enter the following:

   # ./nspdeployerctl secret -o backup_file backup ↵

   where backup_file is the absolute path and name of the backup file to create

   As the secrets are backed up, messages like the following are displayed for each Kubernetes namespace:

   Backing up secrets to /opt/backupfile...

     Including secret namespace:ca-key-pair-external

     Including secret namespace:ca-key-pair-internal

     Including secret namespace:nsp-tls-store-pass

   When the backup is complete, the following prompt is displayed:

   Please provide an encryption password for backup_file

   enter aes-256-ctr encryption password:

2. Enter a password.

   The following prompt is displayed:

   Verifying - enter aes-256-ctr encryption password:

3. Re-enter the password.

   The backup file is encrypted using the password.

4. Record the password for use when restoring the backup.

5. Record the name of the data center associated with the backup.

6. Transfer the backup file to a secure location in a separate facility for safekeeping.

Restore secrets on standby cluster, DR deployment

If you are configuring the standby cluster in a DR deployment, obtain and restore the CLM secrets backup file from the CLM cluster in the primary data center.

1. Enter the following on the standby CLM deployer host:

   # scp address:path/backup_file /tmp/ ↵

   where

   address is the address of the CLM deployer host in the primary cluster

   path is the absolute file path of the backup file created in Step 96

   backup_file is the secrets backup file name

   The backup file is transferred to the local /tmp directory.

2. Enter the following:

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

3. Enter the following:

   ./nspdeployerctl secret -i /tmp/backup_file restore ↵

   The following prompt is displayed:

   Please provide the encryption password for /opt/backupfile

   enter aes-256-ctr decryption password:

4. Enter the password recorded in Step 96.

   As the secrets are restored, messages like the following are displayed for each Kubernetes namespace:

   Restoring secrets from backup_file...

   secret/ca-key-pair-external created

     Restored secret namespace:ca-key-pair-external

   secret/ca-key-pair-internal created

     Restored secret namespace:ca-key-pair-internal

   secret/nsp-tls-store-pass created

     Restored secret namespace:nsp-tls-store-pass

5. If you answer yes to the Step 94 prompt for client access during the primary CLM cluster configuration, you must update the standby server secret for client access using the custom certificate and key files that are specific to the standby cluster.

   Enter the following:

   # ./nspdeployerctl secret -s nginx-nb-tls-nsp -n psaRestricted -f tls.key=customKey -f tls.crt=customCert -f ca.crt=customCaCert update ↵

   where

   customKey is the full path of the private server key

   customCert is the full path of the server public certificate

   customCaCert is the full path of the CA public certificate

   Custom certificate and key files are created by performing To generate custom TLS certificate files for the CLM.

   Messages like the following are displayed as the server secret is updated:

   secret/nginx-nb-tls-nsp patched

   The following files may contain sensitive information. They are no longer required by NSP and may be removed.

     customKey

     customCert

     customCaCert

Deploy CLM software, monitor initialization

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

# ./nspdeployerctl config ↵

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

# ./nspdeployerctl import ↵

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

Note: If the CLM cluster VMs do not have the required SSH key, you must include the --ask-pass argument in the command, as shown in the following example, and are subsequently prompted for the root password of each cluster member:

nspdeployerctl --ask-pass install --config --deploy

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

The specified CLM functions are installed and initialized.

Monitor and validate the CLM cluster initialization.

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

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

   # kubectl get pods -A ↵

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

2. Check PVCs are bound to PVs and PVs are created with STORAGECLASS as shown below

   # kubectl get pvc -A

   NAMESPACE            NAME                       STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS    AGE

   nsp-psa-privileged   data-volume-mdm-server-0   Bound    pvc-ID  5Gi        RWO            storage_class  age

   nsp-psa-restricted   data-nspos-kafka-0         Bound    pvc-ID  10Gi       RWO            storage_class   age

   nsp-psa-restricted   data-nspos-zookeeper-0     Bound    pvc-ID  2Gi        RWO            storage_class  age

   ...

   # kubectl get pv

   NAME                      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM

   nspos-fluentd-logs-data   50Mi       ROX            Retain           Bound    nsp-psa-restricted/nspos-fluentd-logs-data

   pvc-ID                   10Gi       RWO            Retain           Bound    nsp-psa-restricted/data-nspos-kafka-0 

   pvc-ID                   2Gi        RWO            Retain           Bound    nsp-psa-restricted/data-nspos-zookeeper-0

   ...

3. Verify that all pods are in the Running state.

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

Close the open console windows.

End of steps