NSP container environment requirements

Supported NSP cluster environments

A NSP cluster must be deployed in a Nokia provided container environment.

Nokia supports and recommends installing NSP components on VMs using VMware ESXi or RHEL KVM, including OpenStack. The guest OS must be a supported RHEL version.

Supported container software versions

The NSP is validated against a container environment that uses the following software versions:

Table 2-1: Supported container software versions

Containerization element

Supported version

Kubernetes core

v1.28.6

calico

v3.26.4

cni

v1.3.0

containerd

v1.7.13

etcd

v3.5.10

Helm

v3.13.1

coredns

v1.10.1

kubespray

2.24.1

k9s

v0.32.4

metallb

v0.13.9

harbor app

v2.10.2

nerdctl

v1.7.1

KVM virtualization

The NSP supports using RHEL 6, RHEL 7, and RHEL 8 based KVM on x86 based servers natively supported by KVM. See the Host Environment Compatibility Reference for NSP and CLM for the current KVM compatibility level, requirements, and restrictions. See the RHEL Hardware Compatibility List (HCL) for information about specific hardware support.

Not all features offered by KVM are supported when using the NSP. For example Snapshots, Live Migration and HA are not supported. Contact Nokia to determine if a specific KVM feature is supported with an installation of NSP.

KVM CPU and Memory

The required memory resources must be reserved and dedicated to each guest OS, and cannot be shared or oversubscribed. You must set the ram_allocation_ratio parameter to 1.0 in the OpenStack Nova configuration on the control NE, or on each individual compute node that may host an NSP VM. CPU resources may be oversubscribed using the guidelines in the following table.

Table 2-2: KVM CPU oversubscription guidelines

NSP deployment type

KVM

cpu_allocation_ratio

enhanced

2.0

standard

1.5

medium

1.25

Note: CPU oversubscription is only supported on NSP clusters with three or more nodes. Smaller NSP deployments must have reserved and dedicated CPU resources for each node.

KVM configuration

When you configure the KVM, set the parameters listed in the following table to the required values.

Table 2-3: KVM configuration parameters

Parameter

Value

Disk Controller type

virtio

Storage format

raw

Cache mode

none

I/O mode

native

NIC device model

virtio

Hypervisor type

kvm

CPU pinning may be used for NSP virtual machines (deployer and cluster nodes) but may restrict other KVM functions. Please consult KVM documentation for more information.

OpenStack virtualization

The NSP is tested in an open-source OpenStack environment. Nokia supports NSP deployment on VMs provided in any OpenStack distribution that is based on the tested version. Any product issues deemed related to a specific distribution must be pursued by the customer and OpenStack vendor. The supported OpenStack versions include Newton, Queens and Train.

To ensure NSP compatibility with an OpenStack environment, you must follow the requirements in the following topics.

Hypervisor

KVM is the only supported hypervisor for an OpenStack environment. For information about the supported KVM hypervisor versions, see KVM virtualization.

CPU and memory resources

The required memory resources must be reserved and dedicated to each guest OS, and cannot be shared or oversubscribed. You must set the ram_allocation_ratio parameter to 1.0 in the OpenStack Nova configuration on the control NE, or on each individual compute node that may host an NSP VM. CPU resources may be oversubscribed using the guidelines for KVM CPU oversubscription in table 2-2 above.

Simultaneous Multi-threading (SMT)

The usage of CPUs with enabled SMT must be consistent across all compute nodes. If the CPUs do not support SMT, you must disable SMT at the hardware level on each compute node that may host an NSP VM.

CPU pinning

CPU pinning is supported, but may restrict some OpenStack functions such as migration.

Availability zones/affinity/placement

Nokia does not provide recommendations for configuring VM placement in OpenStack.

Migration

The OpenStack environment supports only regular migration; live migration is not supported.

Networking

Basic Neutron functions using Open vSwitch with the ML2 plugin are supported in an NSP deployment, as is the use of OpenStack floating IP addresses.

Storage

All storage must meet the throughput and latency performance criteria in the response to your NSP Platform Sizing Request.

VM storage

The VM storage must be persistent block (Cinder) storage, and not ephemeral. In order to deploy each VM, you must create a bootable Cinder volume. The volume size is indicated in the response to your NSP Platform Sizing Request.

Flavors

Flavors must be created for each Station Type described in the response to your NSP Platform Sizing Request.

Firewalls

You can enable firewalls using OpenStack Security Groups, or on the VMs using the firewalld service, except as noted. If firewalld is enabled, an OpenStack Security Group that allows all incoming and outgoing traffic must be used.

VMware virtualization

The NSP supports using VMware vSphere ESXi 6.5, 6.7, 7.0 and 8.0 only, on x86 based servers natively supported by ESXi. See the Host Environment Compatibility Reference for NSP and CLM for the current VMware compatibility level, requirements, and restrictions. See the VMware Hardware Compatibility List (HCL) to determine specific hardware support.

Not all features offered by ESXi are supported when using the NSP. For example, Fault Tolerant, High Availability (HA), Memory Compression, Distributed Resource Scheduler (DRS), and vMotion features are not supported. VM snapshots are not supported when using NSP. Contact Nokia to determine if a specific ESXi feature is supported with an NSP installation.

CPU pinning is supported on NSP virtual machines (deployer and cluster nodes) but may restrict some VMware functions. Please consult VMware documentation for more information.

Note: The system clocks of the NSP components must always be closely synchronized. The RHEL chronyd service is strongly recommended 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.

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.

Virtual Machine Version 11 or above must be used.

See the following table for additional Virtual Machine setting requirements:

Table 2-4: Additional Virtual Machine setting requirements

Resource type

Parameter

Setting

CPU

Shares

Set to High

Reservation

See VMWare CPU Reservation below

Limit

Check box checked for unlimited

Memory

Shares

Set to High

Reservation

Reserve all guest memory

Limit

Check box checked for unlimited

Disk

Shares

Set to High

Limit - IOPs

set to Unlimited

Type

Thick Provision Eager Zeroed

SCSI controller

Type

VMware Paravirtual

Network Adapter

Type

VMXNET 3

VMWare CPU Reservation

CPU resources may be oversubscribed when NSP is deployed on VMWare. In the following table, the CPU Reservation is determined by: factor X * the number of CPUs * the CPU frequency. For example, with a factor of 0.5 on a 2.4 GHz 8 vCPU configuration, the reservation must be set to (0.5 * 8 * 2400) = 9600 MHz.

NSP deployment type

VMWare factor X

enhanced

0.25

standard

0.33

medium

0.4

Note: CPU oversubscription is only supported on NSP clusters with three or more nodes. Smaller NSP deployments must have reserved and dedicated CPU resources for each node.