Hardware platform and resource requirements using virtualization

Overview

Virtualization is supported using VMware vSphere ESXi, RHEL KVM, and OpenStack. All other forms of virtualization or virtualization products are not supported.

For installations of the NFM-P server, NFM-P database, NFM-P auxiliary database, NSP Flow Collector, NSP Flow Collector Controller, and NFM-P auxiliary collector on a Guest Operating System of a virtualized installation, the Guest Operating System must be an NFM-P supported version of RHEL 8 server x86-64. For installations of the NFM-P client and NFM-P client delegate server on a Guest Operating System of a virtualized installation, the Guest Operating System can be either an NFM-P supported version of RHEL 8 Server or Windows.

Defined CPU and Memory resources must be reserved and dedicated to the individual Guest OSs and cannot be shared or oversubscribed. As a best practice, VMs should be configured with a single virtual socket with all vCPUs assigned to it, if possible. Additional hardware resources should be reserved for use by the host hypervisor installation to ensure that the resources assigned to the Guest OSs is not impacted. Disk and Network resources should be managed appropriately to ensure that other Guest OSs on the same physical server do not negatively impact the operation of NFM-P.

Virtualized installations of NFM-P are server vendor agnostic but must meet specific hardware criteria and performance targets to be used with NFM-P. Server class hardware must be used, not desktops. Processor support is limited to specific Intel Xeon based x86-64 and AMD Epyc based x86-64 CPUs with a minimum CPU core speed as outlined in the proceeding tables. The Intel CPUs must be from the Haswell microarchitecture, or newer, where the CPU microarchitecture determines the minimum supported CPU speed. The AMD CPUs must from the Zen 3 microarchitecture, or newer.

For best performance, storage should be either internal disks (10K or 15K RPM SAS), Fiber Channel attached storage (array or SAN) with dedicated Fiber Channel connections between hosts and Storage Arrays, or 10Gb iSCSI using non-shared infrastructure. All storage must meet the performance metrics provided with NFM-P platform sizing responses. Performance must meet the documented requirements for both throughput and latency.

You must provide information about the provisioned VM 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 NFM-P support.

VMware virtualization

NFM-P 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. If using the NSP RHEL OS image, only VMware vSphere ESXi 6.5, 6.7, and 7.0 are supported. See the VMware Hardware Compatibility List (HCL) to determine specific hardware support. Not all features offered by ESXi are supported when using NFM-P. For example, Memory Compression, or Storage vMotion are not supported. Nokia should be contacted to determine if a specific ESXi feature is supported with an NFM-P installation.

Defined CPU and Memory resources must be reserved for the individual Guest OSs and cannot be shared or oversubscribed. This includes individual vCPUs which must be reserved for the VM.

For new installations, it is recommended to use the latest Virtual Machine Hardware version supported by all of the ESXi hosts in the cluster, from the supported versions. For existing installations, VMware’s best practices should be followed regarding Virtual Machine Hardware version changes. Virtual Machine versions 13, and 19 have been tested with NFM-P where the minimum supported Virtual Machine Hardware version is 10 and the latest supported version is 19.

See the following table for additional VM setting requirements.

Note: 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.

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.

Table 2-10: VMware VM settings

Resource Type

Parameter

Setting

CPU

Shares

Set to High

Reservation

Must be set to 1/2 the number of vCPUs * the CPU frequency. For example, on a 2.4GHz 8 vCPU configuration, the reservation must be set to (0.5*8*2400) 9600MHz

Limit

Unlimited

Memory

Shares

set to High

Reservation

Reserve all guest memory

Limit

Unlimited

Disk

Shares (moved to Storage Policies in 8.0)

set to High

Limit - IOPs

set to Unlimited

Type

Thick Provision Eager Zeroed

Sharing

No Sharing

Disk Mode

Dependent

SCSI Controller

Type

VMware Paravirtual

Network Adapter

Type

VMXNET 3

VMware features

The following VMware features have been tested with NFM-P. To ensure NFM-P stability and compatibility, the following recommendations should be noted for each feature:

vMotion

High Availability

Snapshots

Distributed Resource Scheduler (DRS)

KVM virtualization

NFM-P supports using RHEL 6, RHEL 7, and RHEL 8 based KVM on x86 based servers natively supported by KVM. The Host Environment Compatibility Reference for NSP and CLM should be consulted for up-to-date KVM compatibility along with requirements and restrictions. See the RHEL Hardware Compatibility List (HCL) to determine specific hardware support. Not all features offered by KVM are supported when using NFM-P. For example, Live Migration, Snapshots, or High Availability are not supported. Nokia should be contacted to determine if a specific KVM feature is supported with an NFM-P installation.

Defined CPU and Memory resources must be reserved for the individual Guest OSs and cannot be shared or oversubscribed. This includes individual vCPUs which must be reserved for the VM.

The Disk Controller type must be set to “virtio”, the storage format must be configured as “raw”, cache mode set to “none”, and the I/O mode set to “native”. The NIC device model must be “virtio”. The hypervisor type must be set to “kvm”.

OpenStack

NFM-P tests on open source OpenStack and will support the application running on any OpenStack distribution that is based on the tested versions. Any product issues deemed to be related to the specific OpenStack distribution will need to be pursued by the customer with their OpenStack vendor. Supported OpenStack versions include Newton, Queens, and Train.

To ensure NFM-P stability and compatibility with OpenStack, the following recommendations should be noted:

Hypervisor

CPU and Memory resources

Simultaneous Multi-threading (SMT)

CPU Pinning

Availability zones / affinity / placement:

Migration

Networking

Storage

VM Storage

Flavors

Firewalls