One of the critical elements for successful migration to the cloud is the ability to ensure high performance for real-time media packet processing in virtual, cloud environments. The OpenStack and OPNFV (Open Platform for Network Functions Virtualization) communities have made great strides in driving communication service provider (CSP) requirements regarding performance, scalability and reliability. Yet, challenges remain when moving real-time communications from purpose-built hardware to virtual, cloud-based deployment models.
Virtual network functions (VNFs) for real-time media packet processing need to meet CSP demands for high throughput, high availability and low latency. The key to overcoming this unfortunate reality is to understand which OpenStack configurations can be modified to deliver against CSP expectations by accelerating network traffic handling and ensuring deterministic behavior of media processing with no packet loss.
Below are five best practices CSPs should look for in a solution for cloud-based handling of real-time media packets, including recommended OpenStack configurations for establishing deterministic network behavior:
Leverage solutions with multi-queue vhost-user support.
In theory, accelerating the handling of real-time media packets should simply involve getting a packet off a network into a virtual machine (VM) and out on the network again as quickly as possible. However, using the default Open vSwitch (OVS) technique to get packets from network interface cards (NIC) and pass them on the VMs through the Linux tap devices only works well for applications with low-throughput traffic rates. For applications with a high-throughput of media packets, solutions like single root input/output virtualization or data plane development kit (DPDK) accelerated Open vSwitch with multi-queue vhost-user support need to be used.
Update overcommit settings, non-uniform memory access placement and vCPU technology.
To ensure a 1:1 ratio for CPU and RAM, it’s best to override OpenStack’s default overcommit settings. Also, when accessing remote RAM, it is possible to prevent performance degradation or wasted resources by placing guests so they’re entirely confined within a single, non-uniform memory access (NUMA) node. If the host topology is also configured in the guest, it is possible to spawn instances with input/output (IO) device locality awareness and reduce your hypervisor overhead.
Take advantage of CPU pinning.
While a NUMA configuration means that memory access from the processor will usually be local, it’s possible for a hypervisor to then place the next scheduled clock tick on a different processor, resulting in less memory locality and potential cache misses. To combat this problem, pin the guest vCPUs to the host CPUs so other VMs on the same host can’t use them. Compute resources should host either only pinned VMs or unpinned VMS, but not a mix of the two. In order to have all the pinned CPU dedicated for the guest vCPU and no interferences with the host level processes, it’s best to isolate the CPUs to be used by the VMs.
Specify the use of large pages.
When possible, use the Linux kernel feature “transparent huge pages” (THP) to explicitly allocate huge pages to application RAM allocations. Doing so can reduce the requirement of page allocation at runtime dependent on the memory usage. It can also minimize your hypervisor overhead and boost VM performance through optimized RAM allocation.
Turn off non-usage of settings.
There are several OpenStack settings that can be turned off (or not used) to drive real-time media packet processing performance. For instance, improve memory access and ensure low latency in memory access by not using Swap memory on the compute host. Also, turning off kernel shared memory (KSM) can help keep applications running quickly and reduce costs by lowering CPU usage.
Thankfully, further work is being done to advance existing processing solutions and new tools are continually being introduced to provide performance at scale for media packet handling in virtual, cloud networks. In the meantime, however, CSPs can immediately begin improving their real-time media packet handling by adjusting their existing OpenStack configurations to establish deterministic behavior and eliminate packet loss or latency.
