Openstack Shaker for VyOS VNF (Blog — 2)
This is in continuation to the Blog — 1 series where we extended openstack shaker to test Ubuntu VM performance on openstack setup. Please refer to Blog — 1 for openstack setup details, installation and configuration of Shaker.
In this blog we will test the same scenario as in previous blog except for now we will replace the Ubuntu VM with VyOS VNF. We will not be performing any complex configurations on the VyOS VNF here, we just use it to show shaker can be extended for any VNF or VM to test its performance. So basically we would be testing how VyOS VNF performs as a router when launched in a openstack setup. We will measure the response time and throughput of the traffice passing through the VNF.
Here is the basic topology of the test case
Prerequisite
To test the current VyOS VNF performance on the openstack using shaker it is expected that the below requirements are met.
- Openstack devstack victoria setup — single node would suffice, but the below test is performed on a multi node setup having 1 controller+compute and 1 compute
- Shaker setup — shaker binary installed, shaker image uploaded to glance, shaker flavor created
- VyOS image uploaded to glance — iso image for VyOS can be found here — https://s3.amazonaws.com/s3-us.vyos.io/vyos-1.1.8-amd64.iso
It is also required that the network, router and port configuration required for the testcase also be created prior. As noticed from the topology we would require 3 networks
Network configuration steps:
- Mangement network — for cloud-init configurations
- East and West networks in different subnets used for l3 testing
To create the networks we can either use the dashboard or openstack cli.
Management network creation
# openstack network create mgmt
# openstack subnet create mgmt_subnet --network mgmt --subnet-range 20.0.0.0/24
East network creation
# openstack network create east
# openstack subnet create east_subnet --network east --subnet-range 30.0.0.0/24
West network creation
# openstack network create west
# openstack subnet create west_subnet --network west --subnet-range 40.0.0.0/24
Once created here is how the network details are listed in the dashboard
We can now create a router and attach the management network, this step is necessary to facilitate cloud-init configuration on the VMs
# openstack router create router
# neutron router-gateway-set router public
# openstack router add subnet router mgmt_subnet
Here is the topology view in openstack after network configuration.
Once the networks are created, it is necessary that the network ports for VyOS VM are created prior as well, as we need to allow address pairs on the ports.
east_routerport — connecting VyOS VNF and primary VM from shakerwest_routerport — connecting VyOS VNF with minion VM from shaker
To create ports use the below commands
# openstack port create east_router --fixed-ip ip-address=30.0.0.10 --network east --allowed-address ip-address=0.0.0.0/0
# openstack port create west_router --fixed-ip ip-address=40.0.0.10 --network west --allowed-address ip-address=0.0.0.0/0
For more information on the network, router and port configurations refer Blog — 1
VyOS VNF Deployment and Configuration
The next step now is to use the ports and networks created above to launch a VyOS VNF which would work as a router for our testcase. Here after the VM is boot up we will configure the interfaces. We will launch the VM using openstack cli
# openstack server create --image vyos --flavor m1.medium --nic net-id=<mgmt_net_id> --nic port-id=<east_router_port_id> --nic port-id=<west_router_port_id> vyos_router
The arguments passed here are:
- east_router_port_id — port id of the
east_routerport created above - west_router_port_id — port id of the
west_routerport created above - image VyOS — VyOS image name or id already uploaded to glance
Please note that we are not passing any user data here and the configuration would be performed manually. And also even in this use case we will launch all the three VMs on the single compute node(harrypotter).
We would now connect to the VM through the horizon console and configure the interfaces. The default username and password to connect to the VM is vyos/vyos. Once connected we execute the below commands.
$ configure
# set interfaces ethernet eth0 address dhcp
# set interfaces ethernet eth1 address dhcp
# set interfaces ethernet eth2 address dhcp
# commit;save;exit
Once we have the configuration in place, now we can proceed with the testcase execution using shaker.
Shaker Testcase Execution
As seen from Blog — 1, we would use the same HOT template and shaker yaml file with testcase execution parameters. Here is the copy of the same files
# VyOS testcase HOT template
# vyos_test.hotheat_template_version: 2013-05-23description:
Primary instances and minion instances are connected into different networks. The cloud-init configuration helps connects these instances to VyOS VM.parameters:
net_id:
type: string
description: Network Id of management server
default: "e12265ed-68a0-45c8-8652-fd41b2594f57"
image:
type: string
description: Name of image to use for servers
flavor:
type: string
description: Flavor to use for servers
external_net:
type: string
description: ID or name of external network for which floating IP addresses will be allocated
server_endpoint:
type: string
description: Server endpoint address
dns_nameservers:
type: comma_delimited_list
description: DNS nameservers for the subnets
east_private_net:
type: string
description: NetId of east network
default: "4bdc7b4e-e1d9-4a36-9dc6-0dc3260b2313"
east_private_subnet:
type: string
description: SubnetId of east network
default: "cfa98799-f769-4965-861e-0eec405bc849"
east_ip_address:
type: string
description: Ipaddress for east network
default: "30.0.0.25"
west_private_net:
type: string
description: NetId of west network
default: "7f5f0429-7453-49b7-86cf-4f013fddbae4"
west_private_subnet:
type: string
description: SubnetId of west network
default: "33736de5-ccd9-4903-b6f0-0b272e66eda3"
west_ip_address:
type: string
description: Ipaddress for west network
default: "40.0.0.25"resources:
server_security_group:
type: OS::Neutron::SecurityGroup
properties:
rules: [
{remote_ip_prefix: 0.0.0.0/0,
protocol: tcp,
port_range_min: 1,
port_range_max: 65535},
{remote_ip_prefix: 0.0.0.0/0,
protocol: udp,
port_range_min: 1,
port_range_max: 65535},
{remote_ip_prefix: 0.0.0.0/0,
protocol: icmp}]east_agent_port:
type: OS::Neutron::Port
properties:
network_id: { get_param: east_private_net }
fixed_ips:
- subnet_id: { get_param: east_private_subnet }
ip_address: { get_param: east_ip_address }
security_groups: [{ get_resource: server_security_group }]
west_agent_port:
type: OS::Neutron::Port
properties:
network_id: { get_param: west_private_net }
fixed_ips:
- subnet_id: { get_param: west_private_subnet }
ip_address: { get_param: west_ip_address }
security_groups: [{ get_resource: server_security_group }]test_primary_0:
type: OS::Nova::Server
properties:
name: test_primary_0
image: { get_param: image }
flavor: { get_param: flavor }
key_name: test
networks:
- network: { get_param: net_id }
- port: { get_resource: east_agent_port }
user_data_format: RAW
user_data:
str_replace:
template: |
#!/bin/sh
sudo dhclient ens4
sudo ip r d default via 30.0.0.1
sudo ip r a 40.0.0.0/24 via 30.0.0.10 dev ens4
screen -dmS shaker-agent-screen shaker-agent --server-endpoint=$SERVER_ENDPOINT --agent-id=$AGENT_ID --agent-socket-recv-timeout 10 --agent-socket-send-timeout 10
params:
"$SERVER_ENDPOINT": { get_param: server_endpoint }
"$AGENT_ID": "test_primary_0"test_minion_0:
type: OS::Nova::Server
properties:
name: test_minion_0
image: { get_param: image }
flavor: { get_param: flavor }
key_name: test
networks:
- network: { get_param: net_id }
- port: { get_resource: west_agent_port }
user_data_format: RAW
user_data:
str_replace:
template: |
#!/bin/sh
sudo dhclient ens4
sudo ip r d default via 40.0.0.1
sudo ip r a 30.0.0.0/24 via 40.0.0.10 dev ens4
screen -dmS shaker-agent-screen shaker-agent --server-endpoint=$SERVER_ENDPOINT --agent-id=$AGENT_ID --agent-socket-recv-timeout 10 --agent-socket-send-timeout 10
params:
"$SERVER_ENDPOINT": { get_param: server_endpoint }
"$AGENT_ID": "test_minion_0"outputs:
test_primary_0:
value: { get_attr: [ test_primary_0, instance_name ] }
test_minion_0:
value: { get_attr: [ test_minion_0, instance_name ] }
test_primary_0_ip:
value: { get_attr: [ test_primary_0, networks, east, 0 ] }
test_minion_0_ip:
value: { get_attr: [ test_minion_0, networks, west, 0 ] }
Update the mgmt_net_id along with east and west network and subnet ids in the above HOT template before execution
The below file defines the shaker testcase execution parameters
# VyOS testcase execution yaml
# vyos_test.yamltitle: OpenStack VNF testdescription:
In this scenario Shaker launches pairs of instances. Instances are
connected to one of 2 tenant networks, which plugged into the router VNF.
The traffic goes from one network to the other (L3 east-west).deployment:
template: vyos_test.hot
accommodation: [pair, best_effort]execution:
progression: quadratic
tests:
-
title: Download
class: flent
method: tcp_download
-
title: Upload
class: flent
method: tcp_upload
-
title: Bi-directional
class: flent
method: tcp_bidirectional
Once we have the files in place with the updated details, now we will start with the shaker testcase execution with the below command.
# shaker --server-endpoint <host_ip:prt> --scenario vyos_test.yaml --report vyos_test.html --stack-name test
Replace <host_ip:port> with the host_ip and port of your host.
When we execute the above command, it creates the heat stack from the above vyos_test.hot and then runs the flent traffic as defined in vyos_test.yaml and finally deletes the stack once completed storing the test results in vyos_test.html.
Below is the screen shots of how the topology looks when shaker testcase are executing. The execution might take 15–20mins
As seen from above all the instances are launched on the same compute node(harrypotter)
Once the execution is complete, below are the test results observed. A copy of the same is available here.
We observed around 1.3ms ping output along with 5GB/s and 4.4GB/s download and upload speed respectively.
Conclusion
We have learnt how to use shaker to test the nic/interface performance of a VNF. This helps greatly in current telco-cloud world. It gives the operator better handle to learn about the VNF performance and its behavior in a cloud environment.
Next we will see how the performance of the VNF effects when we change its placement from one compute node to another compute node.
