The main advantages of implementing NFV are as follows:

Red Hat OpenStack Platform 10 supports NFV deployments with the inclusion of automated OVS-DPDK and SR-IOV configuration. Furthermore, customers looking for a Hyper-converged Infrastructure (HCI) solution can now co-locate the Compute sub-system with the Red Hat Ceph Storage nodes. This hyper-converged model delivers lower cost of entry, smaller initial deployment footprints, maximized capacity utilization, and more efficient management in NFV use cases.

With the previous releases of Red Hat OpenStack Platform director, overcloud consists of predefined nodes, namely, Controller, Compute, Storage and so on. Each node consisted of a set of services defined in the core heat template collection on the director node. With the Red Hat OpenStack Platform 10, you can create custom deployment roles, using the composable roles feature, adding or removing services from each role. With Red Hat OpenStack Platform 10 release, the director offers many configuration options to deploy the latest OpenStack and Ceph versions. It also supports, with limitations, the deployment of Technology Preview services such as OpenDaylight, Containerized Compute node or the Real-Time KVM hypervisor. For more information on the support scope for features marked as technology previews, see Technology Preview.

For more information on the Composable Roles, see Composable Roles and Services.

The European Telecommunications Standards Institute (ETSI) is an independent standardization group that develops standards for information and communications technologies (ICT) in Europe.

Network functions virtualization (NFV) focuses on addressing problems involved in using proprietary hardware devices. With NFV, the necessity to install network-specific equipment is reduced, depending upon the use case requirements and economic benefits. The ETSI Industry Specification Group for Network Functions Virtualization (ETSI ISG NFV) sets the requirements, reference architecture, and the infrastructure specifications necessary to ensure virtualized functions are supported.

Red Hat is offering an open-source based cloud-optimized solution to help the Communication Service Providers (CSP) to achieve IT and network convergence, by adding the NFV features like SR-IOV, DPDK-OVS to existing open source projects like OpenStack.

To install Red Hat OpenStack Platform, you must register all systems in the OpenStack environment either through the Red Hat Content Delivery Network, or through Red Hat Satellite 6. If using a Red Hat Satellite Server, synchronize the required repositories to your Red Hat OpenStack Platform environment. Subscribing to the right channels allows you access to certain repositories and each repository allows you to download the necessary packages required for installing and configuring Red Hat OpenStack Platform. The following is a list of CDN channels that you need to subscribe for installing Red Hat OpenStack Platform 10 with NFV components:

Table: Red Hat OpenStack Platform Repositories

For more information on the steps to subscribe to the channels, see Subscription Basics.

In general, NFV platform has the following components:

Red Hat’s solution for NFV includes a range of products that can act as the different components of the NFV framework in the ETSI model. The following products from the Red Hat portfolio will have NFV features:

The Red Hat OpenStack Platform director is a toolset for installing and managing a complete OpenStack environment. It is based primarily on the upstream OpenStack project TripleO, which is an abbreviation for "OpenStack-On-OpenStack". This project takes advantage of the OpenStack components to install a fully operational OpenStack environment; this includes a minimal OpenStack node called the undercloud that provisions and controls the bare metal systems to be use as the production OpenStack nodes, called the overcloud. This provides a simple method for installing a complete Red Hat OpenStack Platform environment that is both lean and robust.

For more information on installing the undercloud and overcloud, see Red Hat OpenStack Platform Director Installation and Usage.

To install the NFV features, you need to configure the following additional steps:

For detailed information on the configuration procedure steps, see Network Function Virtualization Configuration Guide.

Previously, all memory on x86 systems was equally accessible to all CPUs in the system. This resulted in memory access times that were the same regardless of which CPU in the system was performing the operation and was referred to as Uniform Memory Access (UMA).

In Non-Uniform Memory Access (NUMA), system memory is divided into zones called nodes, which are allocated to particular CPUs or sockets. Access to memory that is local to a CPU is faster than memory connected to remote CPUs on that system. Normally, each socket on a NUMA system has a local memory node whose contents can be accessed faster than the memory in the node local to another CPU or the memory on a bus shared by all CPUs.

Similarly, physical NICs are placed in PCI slots on the Compute node hardware. These slots connect to specific CPU sockets which are associated to a particular NUMA node. For optimum performance, connect your datapath NICs to the same NUMA nodes in your configuration (SR-IOV or OVS-DPDK).

The performance impact of NUMA misses are significant, generally starting at a 10% performance hit or higher. Each CPU socket can have multiple CPU cores which are treated as individual CPUs for virtualization purposes.

OpenStack Compute makes smart scheduling and placement decisions when launching instances. Administrators who want to take advantage of these features can create customized performance flavors to target specialized workloads including NFV and High Performance Computing (HPC).

5.1.1. NUMA Node Example

The following diagram provides an example of a two-node NUMA system and the way the CPU cores and memory pages are made available:

Note

Remote memory available via Interconnect is accessed only if VM1 from NUMA node 0 has a CPU core in NUMA node 1. In this case, the memory of NUMA node 1 will act as local for the third CPU core of VM1 (for example, if VM1 is allocated with CPU 4 in the diagram above), but at the same time, it will act as remote memory for the other CPU cores of the same VM.

Warning

At present, it is impossible to migrate an instance which has been configured to use CPU pinning. For more information about this issue, see the following solution: Instance migration fails when using cpu-pinning from a numa-cell and flavor-property "hw:cpu_policy=dedicated".

CPU pinning is the ability to run a specific virtual machine’s virtual CPU on a specific physical CPU, in a given host. vCPU pinning provides similar advantages to task pinning on bare-metal systems. Since virtual machines run as user space tasks on the host operating system, pinning increases cache efficiency.

Physical memory is segmented into contiguous regions called pages. For efficiency, the system retrieves memory by accessing entire pages instead of individual bytes of memory. To perform this translation, the system looks in the Translation Lookaside Buffers (TLB) which contain the physical to virtual address mappings for the most recently or frequently used pages. When a mapping being searched for is not in the TLB, the processor must iterate through all the page tables to determine the address mappings. This causes a performance penalty. It is therefore preferable to optimise the TLB so as to ensure the target process can avoid the TLB misses as much as possible.

The typical page size in an x86 system is 4KB, with other larger page sizes available. Larger page sizes mean that there are fewer pages overall, and therefore increases the amount of system memory that can have its virtual to physical address translation stored in the TLB, and as a result lowers the potential for TLB misses, which increases performance. With larger page sizes, there is an increased potential for memory to be wasted as processes must allocate in pages, but not all of the memory is likely required. As a result, choosing a page size is a trade off between providing faster access times by using larger pages and ensuring maximum memory utilization by using smaller pages.

Port security is an anti-spoofing measure. It blocks egress traffic that does not match the source IP and source MAC address of the originating network port. You cannot view or modify this behavior using security group rules.

By default, the port_security_enabled parameter is set to enabled on newly created Neutron networks in OpenStack. Newly created ports copy the value of the port_security_enabled parameter from the network they are created on.

For some NFV use cases, such as building a firewall or router, you will need to disable port security.

To disable port security on a single port, run the following command:

openstack port set --disable-port-security <port-id>

To prevent port security from being enabled on any newly created port on a network, set the port_security_enabled parameter on the network to disabled.

openstack network set --disable-port-security <network-id>