Create NSP cluster in DC B

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

Open a console window.

Perform the following sections of procedure To install the NSP in DC B.

Note: The number of VMs in each NSP cluster must match.

1. Create NSP deployer host VM ( Step 1 to Step 6)—creates the NSP deployer host VM in DC B

   Note: The DC B VM specifications, such as disk layout and capacity, must be identical to the DC A VM specifications.

2. Configure NSP deployer host networking ( Step 7 to Step 17)—sets the NSP deployer host communication parameters

3. Install NSP Kubernetes registry ( Step 18 to Step 28)—configures and deploys the Kubernetes registry

4. Create NSP cluster VMs ( Step 29 to Step 50)—creates the new NSP cluster VMs

   Note: The DC B VM specifications, such as disk layout and capacity, must be identical to the DC A VM specifications.

5. Deploy Kubernetes environment ( Step 51 to Step 112)—deploys the NSP cluster in DC B

Reconfigure NSP cluster in DC A

Log in as the root or NSP admin user on the NSP deployer host in DC A.

Open a console window.

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

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

Edit the following line in the platform section, kubernetes subsection to read as shown below:

  deleteOnUndeploy:false

Save and close the file.

Enter the following:

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

Enter the following to stop the NSP cluster in DC A:

Note: If the NSP 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 uninstall --undeploy

# ./nspdeployerctl uninstall --undeploy ↵

The NSP cluster stops.

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

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

Configure the parameters in the dr section as shown below:

Note: The peer_address value that you specify must match the advertisedAddress value in the configuration of the cluster in DC B and have the same format; if one value is a hostname, the other must also be a hostname.

dr:

   dcName: "data_center"

   mode: "dr"

   peer: "peer_address"

   internalPeer: "peer_internal_address"

   peerDCName: "peer_data_center"

where

data_center is the unique alphanumeric name to assign to the DC A cluster

peer_address is the address at which the DC B cluster is reachable over the client network

peer_internal_address is the address at which the DC B cluster is reachable over the internal network

peer_data_center is the unique alphanumeric name to assign to the DC B cluster

Save and close the nsp-config.yml file.

Enter the following:

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

Enter the following to start the NSP in DC A:

Note: If the NSP 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 DC A NSP initializes in DR mode.

Transfer the /opt/nsp/NSP-CN-DEP-release-ID/NSP-CN-release-ID/config/nsp-config.yml file to the /tmp directory on the NSP deployer host in DC B.

Close the open console windows in DC A.

Configure NSP cluster in DC B

Log in as the root or NSP admin user on the NSP deployer host in DC B.

Open a console window.

Open the following file copied from DC A using a plain-text editor such as vi:

/tmp/nsp-config.yml

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

Configure the following NSP cluster address parameters in the platform section, ingressApplications subsection as shown below:

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 NSP cluster hostname as the client_IP value.

  ingressApplications:

    ingressController:

      clientAddresses:

        virtualIp: "client_IP"

        advertised: "client_public_address"

      internalAddresses:

        virtualIp: "internal_IP"

        advertised: "internal_public_address"

    trapForwarder:

      mediationAddresses:

        virtualIpV4: "trapV4_mediation_IP"

        advertisedV4: "trapV4_mediation_public_address"

        virtualIpV6: "trapV6_mediation_IP"

        advertisedV6: "trapV6_mediation_public_address"

where

client_IP is the address for external client access

internal_IP is the address for internal communication

trapV4_mediation_IP is the address for IPv4 network mediation

trapV6_mediation_IP is the address for IPv6 network mediation

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

If flow collection is enabled, configure the following parameters in the platform section, ingressApplications subsection as shown below:

    flowForwarder:

      mediationAddresses:

        virtualIpV4: "flowV4_mediation_IP"

        advertisedV4: "flowV4_mediation_public_address"

        virtualIpV6: "flowV6_mediation_IP"

        advertisedV6: "flowV6_mediation_public_address"

where

flowV4_mediation_IP is the address for IPv4 flow collection

flowV6_mediation_IP is the address for IPv6 flow collection

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

Configure the parameters in the dr section as shown below:

Note: The peer_address value that you specify must match the advertisedAddress value in the configuration of the cluster in DC A and have the same format; if one value is a hostname, the other must also be a hostname.

dr:

   dcName: "data_center"

   mode: "dr"

   peer: "peer_address"

   internalPeer: "peer_internal_address"

   peerDCName: "peer_data_center"

where

data_center is the unique alphanumeric name of the DC B cluster

peer_address is the address at which the DC A cluster is reachable over the client network

peer_internal_address is the address at which the DC A cluster is reachable over the internal network

peer_data_center is the unique alphanumeric name of the DC A cluster

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

   tls:                     

     customCaCert: CA_key_file

where CA_key_file is the CA.pem file generated in Step 7 of To generate custom TLS certificate files for the NSP

Save and close the file.

Replace the original NSP configuration file with the edited file.

1. Enter the following to create a local backup of the original file:

   # mv /opt/nsp/NSP-CN-DEP-release-ID/NSP-CN-release-ID/config/nsp-config.yml nsp-config.orig ↵

2. Enter the following:

   # cp /tmp/nsp-config.yml /opt/nsp/NSP-CN-DEP-release-ID/NSP-CN-release-ID/config ↵

Restore NSP Kubernetes secrets

Obtain and restore the NSP Kubernetes secrets from DC A.

1. Enter the following:

   # scp address:path/backup_file /tmp/ ↵

   where

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

   path is the absolute file path of the secrets backup file

   backup_file is the secret backup file name

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

2. Enter the following on the NSP deployer host:

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

3. Enter the following:

   ./nspdeployerctl secret -i backup_file restore ↵

   where backup_file is the absolute path and filename of the secrets backup file to 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 during the backup creation.

   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

WARNING Deployment failure

The install script will advise you to delete customCaCert, stating that the file is no longer required by NSP. This message is not correct for installations that use custom certificates.

Do not delete this file if you are using custom certificates, as the deployment will fail.

If the NSP uses a custom server certificate for client access, 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 NSP.

Messages like the following are displayed as the server secret is updated. Do not delete customCaCert if you are using custom certificates, as the deployment will fail.

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 NSP software in DC B

Enter the following on the NSP deployer host in DC B:

Note: If the NSP 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 NSP cluster initializes as the standby cluster in the new DR deployment.

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

Enter the following every few minutes to monitor the NSP cluster initialization:

# 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. If any pod fails to enter the Running or Completed state, see the NSP Troubleshooting Guide for information about troubleshooting an errored pod.

Note: Some pods may remain in the Pending state; for example, MDM pods in addition to the default for a deployment.

Start NFM-P

Perform the following steps on each NFM-P main server station to start the server.

Note: If the NFM-P system is redundant, you must perform the steps on the primary main server first.

1. Enter the following:

   bash$ cd /opt/nsp/nfmp/server/nms/bin ↵

2. Enter the following:

   bash$ ./nmsserver.bash start ↵

3. Enter the following:

   bash$ ./nmsserver.bash appserver_status ↵

   The server status is displayed; the server is fully initialized if the status is the following:

   Application Server process is running.  See nms_status for more detail.

   If the server is not fully initialized, wait five minutes and then repeat this step. Do not perform the next step until the server is fully initialized.

End of steps