Trying out OPNFV Yardstick NSB with Aarna Networks ONAP Distribution (ANOD)
February 3, 2019
Sriram Rupanagunta is a co-founder & SVP Engineering at Aarna Networks, Inc, and heads their engineering team. Prior to Aarna, Sriram was the Head of India Engineering at Data Center Business of Western Digital Corp. Prior to Western Digital, Sriram was with the SSD based startup Virident Systems (which was acquired by Western Digital). Earlier to that, Sriram was also the co-founder of start up Aarohi Communications which was acquired by Emulex Corporation, and was the Vice President, Technology at Emulex. He lives in Bangalore, India with his wife and a daughter.
This technical blog explains how to run NSB (Network Services Benchmarking) using Yardstick, in a virtual environment, using the Aarna Networks ONAP Distribution (ANOD) on GCP. You can get free access ANOD for GCP here.
We believe that Yardstick NSB will complement ONAP very well by helping validate and certify the performance of VNFs before they are onboarded. See my August blog that talks about this more. See also my YouTube video titled "OPNFV Yardstick NSB Demo".
Deploy OPNFV on CentOS 7.x server or a GCE instance, with vcpus as 16, and memory as 32GB.
The IP address of Openstack Horizon interface can be found in Openstack credentials file on the Undercloud instance of Openstack (log in using the command “opnfv-util undercloud” , and refer to the file overcloudrc.v3).
Log into Horizon dashboard to examine Openstack parameters such as number of resources for Hypervisors and so on (after setting up SOCKS proxy tunnel).
Create a KVM instance of Ubuntu 16.04, with the following resources. You can refer to Aarna’s Lab ONAP300 (which sets up Ubuntu 16 VM on GCE instance). If you are running this on a local server, you need to create this VM using a standard Ubuntu 16.04 cloud image. Instead of using this image for deploying ONAP, you can use the same VM to run NSB/Yardstick. This VM requires the following resources:
(Note: NSB scripts do not work on CentOS distributions, so it cannot be run from the base Jump host)
Login to Ubuntu instance as user “aarna”, and copy openstack credentials file to this (in directory /opnfv-yardstick). Edit this file, and remove comments and shell commands, and retain only environment variables (openstack.creds.sh).
Once this command completes successfully, you can see yardstick container created on this VM. Run the bash shell on this container. There is no need to explicitly start the container (nsb_setup does it).
docker ps -a # You should see yardstick container
docker exec -it yardstick /bin/bash # execute shell in the container
The nsb_setup script also prepares the cloud image (yardstick-samplevnfs) for Openstack, and adds it to Glance on the Openstack. This image contains all the needed utilities for running all the NSB sample VNF’s.
# Edit this file, and add file as the destination (in addition to http). It can also
# be set to influxdb for viewing the results in Grafana
For the purpose of this blog, we will use the sample application l2fwd, which does L2 forwarding functions. Edit the l2fwd test case from prox VNF (yardstick/samples/vnf_samples/nsut/prox/tc_prox_heat_context_l2fwd-2.yaml), and reduce the resource requirements in the context section of the file.
vcpus to 8
memory to 10G
Edit the following file and make few changes. These changes are not needed in a hardware based deployment, but since the VM deployment takes more time to boot up the VMs on Openstack, these changes are required.
This takes few minutes to complete. While this is running, you can examine Horizon dashboard, and look at the Stack created (which includes all the resources needed to run the tests), and the VM instances (2 of them) which are created. At the end of the test, the stack will be undeployed.
The results of the test will be in /tmp/yardstick.out, which you can examine.
Influxdb/Grafana can be configured to view the results graphically (NOTE: This is not included in the recorded session).
The L2 forwarding service consists of 2 VNF’s - TG (Traffic Generator) and L2FWD (L2 Forwarding function). Both these functions are implemented using the open source tool called prox (Packet PROcessing eXecution engine). Prox can be configured to run in various modes, and for the purpose of this network service, we will be running prox on both the VNF’s, in different modes. On the TG VNF, prox will be run as a traffic generator, by passing the appropriate configuration file (gen-l2fwd-2.cfg). On the L2FWD VNF, prox will be run as a L2 forwarding function, by passing the configuration file (handle-l2fwd-2.cfg).
The prox application is built using the open source library DPDK.
The network configuration of the service is as shown below:
Curios to learn more about ONAP? Consider signing up for one of our upcoming trainings.