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
-
NFM-P performance can be degraded by as much as 30% when a snapshot exists and therefore NFM-P performance and stability is not guaranteed
-
Snapshots should be kept for the least amount of time possible
-
Snapshot deletion can take many hours and will pause the VM several times
-
NFM-P database failover will occur when VMs are reverted to snapshots, requiring a re-instantiation of the standby database
-
Supported on all components except for the NFM-P auxiliary database
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
-
KVM is the only hypervisor supported within an OpenStack environment. See the preceding section for supported versions.
CPU and Memory resources
-
Defined CPU and Memory resources must be reserved and dedicated to the individual Guest OSs and cannot be shared or oversubscribed. The OpenStack Nova configuration for cpu_allocation_ratio and ram_allocation_ratio must both be set to 1.0 on either the control node or each individual compute node where a VM hosting NFM-P could reside.
Simultaneous Multi-threading (SMT)
-
SMT CPU usage must be consistent across all compute nodes. If there are CPUs that do not support SMT, SMT must be disabled on all compute nodes, at the hardware level, where NFM-P components could be deployed.
CPU Pinning
-
CPU pinning is supported but not recommended as it restricts the use of OpenStack migration. See the 7701 CPAA Installation Guide for vCPAA CPU Pinning requirements
Availability zones / affinity / placement:
Migration
Networking
-
Basic Neutron functionality using Open vSwitch with the ML2 plugin can be used in an NFM-P deployment. OpenStack floating IP address functionality can be used on specific interfaces used by NFM-P that support the use of NAT. This would require a Neutron router using the neutron L3 agent.
Storage
-
All storage must meet the performance metrics provided with NFM-P Platform Responses. Performance must meet the documented requirements for both throughput and latency.
VM Storage
-
VM storage must be persistent block (Cinder) storage and not ephemeral. For each VM to be deployed, a bootable Cinder volume must be created. The size of the volume is indicated in the NFM-P Platform sizing response.
Flavors
Firewalls