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.27.10 |
|
calico |
v3.25.2 |
|
cni |
v1.3.0 |
|
containerd |
v1.7.13 |
|
etcd |
v3.5.10 |
|
Helm |
v3.12.3 |
|
coredns |
v1.10.1 |
|
kubespray |
2.23.3 |
|
k9s |
v0.27.4 |
|
harbor |
v3.8.2 |
|
nerdctl |
v1.4.0 |
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.