An NSP cluster must be sized according to the requirements defined by the Nokia NSP Platform Sizing Tool, which calculates the minimum platform requirements based on the specified installation options. These platform requirements support the network dimensions described in Chapter 5, Scaling and performance.

Note: The NSP deployer is a crucial element of an NSP system that holds the required container images and Helm repositories for deployment to each NSP cluster VM. If the deployer host is unavailable, NSP cluster recovery in the event of a failure may be compromised. Ensure that the NSP deployer host remains operational and reachable by the NSP cluster after the cluster deployment.

The platform requirements for NSP cluster VMs and VMs that host additional components depend on, but are not limited to, the following factors:

• number of managed LSPs and services

• number of managed NEs

• number of MDM learned services

• number of simultaneous operator and API sessions

• expected numbers of:

  • flows

  • monitored NEs

  • AS

  • ports with real-time statistics collection

NSP deployments are server- and vendor-agnostic, but must meet all NSP component hardware criteria and performance targets. Server-class hardware is required; desktop hardware is inadequate. Processor support is limited to specific Intel Xeon-based x86-64 and AMD Epyc x86-64 CPUs that have the required minimum CPU core speed listed in Table 2-6, VM processor requirements.

Table 2-6: VM processor requirements

Note: CPU oversubscription is only supported on Skylake and newer processor microarchitectures.

Provisioned CPU resources are based upon threaded CPUs. The NSP Platform Requirements will specify a minimum number of vCPUs to be assigned to the VM. VMs are recommended to be configured with all vCPUs on one virtual socket.

A host system requires CPU, memory and disk resources after resources for NSP cluster VMs have been allocated. Contact the hypervisor provider for requirements and best practices related to the hosting environment.

You must provide information about the provisioned VMs to Nokia support. You can provide the information through read-only hypervisor access, or make the information available upon request. Failure to provide the information may adversely affect NSP support.

Note: A virtual machine running a VSR-NRC instance requires CPU pinning and isolation from other virtual machines running on the host system. For platform requirements of the VSR-NRC, refer to the VSR Installation and Setup Guide.

The storage layer of an NSP cluster requires a minimum read/write IOPS based on deployment type, network size and storage type. NSP cluster deployments with customer provided storage also have storage capacity requirements for database backups. See the tables below for IOPS and storage capacity requirements.

Note: IOPS performance can vary in a cloud environment and may degrade over time. Degraded IOPS performance may affect NSP performance. Customers are advised to monitor IOPS performance over time.

Table 2-7: Minimum NSP cluster IOPS requirements - local storage

Table 2-8: Minimum NSP cluster IOPS requirements - customer provided storage

Table 2-9: Customer provided storage capacity requirements for database backup storage

Refer to the NSP Installation and Upgrade Guide for file system requirements and disk partitioning recommendations.

Note: The disk layout and partitioning of each VM in a multi-node NSP cluster, including DR deployments, must be identical.

In environments where multiple physical hosts are used to run NSP Cluster VMs, an option to ensure further resiliency of the deployment would be deploy certain VMs on different physical hosts. This would allow for a physical host to fail completely without necessarily triggering a site switchover.

Note: This VM distribution recommendation only applies for HA deployment types.

Note: In the case of a physical host failure, multiple VMs will be affected – as NSP only guarantees a single VM failure without affecting any service, if multiple VMs fail, it is quite likely that the data center will be running in a degraded state, with some non-essential services being completely unavailable.

While three physical hosts will allow for this additional resiliency, it is recommended to have four physical hosts to minimize the number of affected VMs should a physical host fail.

Table 2-10: Three physical host layout

Table 2-11: Four physical host layout

In both cases, any additional nodes can be placed on any physical host.

If more than four physical hosts are required, please contact your Nokia representative.

The virtual memory configuration of each NSP cluster VM requires a parameter change to support Centralized Logging.

The following command entered as the root user displays the current setting:

sysctl -a | grep “vm.max_map_count”

If the setting is not at least 26 2144, you must enter the following command before you deploy the NSP:

sysctl -w vm.max_map_count=262144

The system clocks of the NSP components must always be closely synchronized. The RHEL chronyd service is required as the time-synchronization mechanism to engage on each NSP component during deployment.

Caution: Some components - members of an etcd cluster, for example - will not trust the integrity of data if a time difference is detected. As such, failure to closely synchronize system clocks can complicate debugging and cause outages or other unexpected behavior.

Note: Only one time-synchronization mechanism can be active in an NSP system. Before you enable a service such as chronyd on an NSP component, you must ensure that no other time-synchronization mechanism, for example, the VMware Tools synchronization utility, is enabled.

The NSP cluster VMs require sufficient available user IDs to create system users for NSP applications.

NSP deployer and worker nodes require a system user account named nsp that must have uid 1000. If a user other than nsp is already assigned to uid 1000, then that user needs to be deleted or modified before the NSP cluster can be installed.

NSP deployments can use hostnames or FQDNs rather than IP addresses, but the hostname resolution must be through DNS.

Note: Using multiple nameservers in /etc/resolv.conf is only intended for redundant nameservers and not for resolving different domains.

The hostname of an NSP component station must meet the following criteria:

• include only alphanumeric ASCII characters and hyphens

• not begin or end with a hyphen

• if an FQDN, FQDN components are delimited using periods

• hostname FQDN does not exceed 63 characters