diff options
Diffstat (limited to 'docs/testing/user/userguide')
| -rw-r--r-- | docs/testing/user/userguide/13-nsb-installation.rst | 100 | ||||
| -rw-r--r-- | docs/testing/user/userguide/opnfv_yardstick_tc074.rst | 72 |
2 files changed, 138 insertions, 34 deletions
diff --git a/docs/testing/user/userguide/13-nsb-installation.rst b/docs/testing/user/userguide/13-nsb-installation.rst index 3e0ed0bfb..fb68fbf21 100644 --- a/docs/testing/user/userguide/13-nsb-installation.rst +++ b/docs/testing/user/userguide/13-nsb-installation.rst @@ -118,7 +118,7 @@ Ansible: .. code-block:: ini - cat ./ansible/yardstick-install-inventory.ini + cat ./ansible/install-inventory.ini [jumphost] localhost ansible_connection=local @@ -138,7 +138,7 @@ Ansible: .. note:: SSH access without password needs to be configured for all your nodes defined in - ``yardstick-install-inventory.ini`` file. + ``install-inventory.ini`` file. If you want to use password authentication you need to install sshpass .. code-block:: console @@ -352,18 +352,53 @@ SR-IOV SR-IOV Pre-requisites ^^^^^^^^^^^^^^^^^^^^^ -On Host: - a) Create a bridge for VM to connect to external network +On Host, where VM is created: + a) Create and configure a bridge named ``br-int`` for VM to connect to external network. + Currently this can be done using VXLAN tunnel. + + Execute the following on host, where VM is created: .. code-block:: console + ip link add type vxlan remote <Jumphost IP> local <DUT IP> id <ID: 10> dstport 4789 brctl addbr br-int - brctl addif br-int <interface_name> #This interface is connected to internet + brctl addif br-int vxlan0 + ip link set dev vxlan0 up + ip addr add <IP#1, like: 172.20.2.1/24> dev br-int + ip link set dev br-int up + + .. note:: May be needed to add extra rules to iptable to forward traffic. + + .. code-block:: console + + iptables -A FORWARD -i br-int -s <network ip address>/<netmask> -j ACCEPT + iptables -A FORWARD -o br-int -d <network ip address>/<netmask> -j ACCEPT + + Execute the following on a jump host: + + .. code-block:: console + + ip link add type vxlan remote <DUT IP> local <Jumphost IP> id <ID: 10> dstport 4789 + ip addr add <IP#2, like: 172.20.2.2/24> dev vxlan0 + ip link set dev vxlan0 up + + .. note:: Host and jump host are different baremetal servers. + + b) Modify test case management CIDR. + IP addresses IP#1, IP#2 and CIDR must be in the same network. + + .. code-block:: YAML + + servers: + vnf: + network_ports: + mgmt: + cidr: '1.1.1.7/24' - b) Build guest image for VNF to run. + c) Build guest image for VNF to run. Most of the sample test cases in Yardstick are using a guest image called - ``yardstick-image`` which deviates from an Ubuntu Cloud Server image - Yardstick has a tool for building this custom image with samplevnf. + ``yardstick-nsb-image`` which deviates from an Ubuntu Cloud Server image + Yardstick has a tool for building this custom image with SampleVNF. It is necessary to have ``sudo`` rights to use this tool. Also you may need to install several additional packages to use this tool, by @@ -548,18 +583,53 @@ OVS-DPDK OVS-DPDK Pre-requisites ^^^^^^^^^^^^^^^^^^^^^^^ -On Host: - a) Create a bridge for VM to connect to external network +On Host, where VM is created: + a) Create and configure a bridge named ``br-int`` for VM to connect to external network. + Currently this can be done using VXLAN tunnel. + + Execute the following on host, where VM is created: .. code-block:: console + ip link add type vxlan remote <Jumphost IP> local <DUT IP> id <ID: 10> dstport 4789 brctl addbr br-int - brctl addif br-int <interface_name> #This interface is connected to internet + brctl addif br-int vxlan0 + ip link set dev vxlan0 up + ip addr add <IP#1, like: 172.20.2.1/24> dev br-int + ip link set dev br-int up + + .. note:: May be needed to add extra rules to iptable to forward traffic. + + .. code-block:: console + + iptables -A FORWARD -i br-int -s <network ip address>/<netmask> -j ACCEPT + iptables -A FORWARD -o br-int -d <network ip address>/<netmask> -j ACCEPT + + Execute the following on a jump host: + + .. code-block:: console + + ip link add type vxlan remote <DUT IP> local <Jumphost IP> id <ID: 10> dstport 4789 + ip addr add <IP#2, like: 172.20.2.2/24> dev vxlan0 + ip link set dev vxlan0 up + + .. note:: Host and jump host are different baremetal servers. + + b) Modify test case management CIDR. + IP addresses IP#1, IP#2 and CIDR must be in the same network. + + .. code-block:: YAML + + servers: + vnf: + network_ports: + mgmt: + cidr: '1.1.1.7/24' - b) Build guest image for VNF to run. + c) Build guest image for VNF to run. Most of the sample test cases in Yardstick are using a guest image called - ``yardstick-image`` which deviates from an Ubuntu Cloud Server image - Yardstick has a tool for building this custom image with samplevnf. + ``yardstick-nsb-image`` which deviates from an Ubuntu Cloud Server image + Yardstick has a tool for building this custom image with SampleVNF. It is necessary to have ``sudo`` rights to use this tool. Also you may need to install several additional packages to use this tool, by @@ -880,7 +950,7 @@ Install dependencies needed for the DevStack Setup SR-IOV ports on the host: -.. note:: The ``enp24s0f0``, ``enp24s0f0`` are physical function (PF) interfaces +.. note:: The ``enp24s0f0``, ``enp24s0f1`` are physical function (PF) interfaces on a host and ``enp24s0f3`` is a public interface used in OpenStack, so the interface names should be changed according to the HW environment used for testing. diff --git a/docs/testing/user/userguide/opnfv_yardstick_tc074.rst b/docs/testing/user/userguide/opnfv_yardstick_tc074.rst index 92cd51439..261a8bd95 100644 --- a/docs/testing/user/userguide/opnfv_yardstick_tc074.rst +++ b/docs/testing/user/userguide/opnfv_yardstick_tc074.rst @@ -19,16 +19,27 @@ Yardstick Test Case Description TC074 |metric | Storage performance | | | | +--------------+--------------------------------------------------------------+ -|test purpose | Storperf integration with yardstick. The purpose of StorPerf | -| | is to provide a tool to measure block and object storage | -| | performance in an NFVI. When complemented with a | -| | characterization of typical VF storage performance | -| | requirements, it can provide pass/fail thresholds for test, | -| | staging, and production NFVI environments. | -| | | -| | The benchmarks developed for block and object storage will | -| | be sufficiently varied to provide a good preview of expected | -| | storage performance behavior for any type of VNF workload. | +|test purpose | To evaluate and report on the Cinder volume performance. | +| | | +| | This testcase integrates with OPNFV StorPerf to measure | +| | block performance of the underlying Cinder drivers. Many | +| | options are supported, and even the root disk (Glance | +| | ephemeral storage can be profiled. | +| | | +| | The fundamental concept of the test case is to first fill | +| | the volumes with random data to ensure reported metrics | +| | are indicative of continued usage and not skewed by | +| | transitional performance while the underlying storage | +| | driver allocates blocks. | +| | The metrics for filling the volumes with random data | +| | are not reported in the final results. The test also | +| | ensures the volumes are performing at a consistent level | +| | of performance by measuring metrics every minute, and | +| | comparing the trend of the metrics over the run. By | +| | evaluating the min and max values, as well as the slope of | +| | the trend, it can make the determination that the metrics | +| | are stable, and not fluctuating beyond industry standard | +| | norms. | | | | +--------------+--------------------------------------------------------------+ |configuration | file: opnfv_yardstick_tc074.yaml | @@ -38,7 +49,8 @@ Yardstick Test Case Description TC074 | | * public_network: "ext-net" - name of public network | | | * volume_size: 2 - cinder volume size | | | * block_sizes: "4096" - data block size | -| | * queue_depths: "4" | +| | * queue_depths: "4" - the number of simultaneous I/Os | +| | to perform at all times | | | * StorPerf_ip: "192.168.200.2" | | | * query_interval: 10 - state query interval | | | * timeout: 600 - maximum allowed job time | @@ -50,7 +62,11 @@ Yardstick Test Case Description TC074 | | performance in an NFVI. | | | | | | StorPerf is delivered as a Docker container from | -| | https://hub.docker.com/r/opnfv/storperf/tags/. | +| | https://hub.docker.com/r/opnfv/storperf-master/tags/. | +| | | +| | The underlying tool used is FIO, and StorPerf supports | +| | any FIO option in order to tailor the test to the exact | +| | workload needed. | | | | +--------------+--------------------------------------------------------------+ |references | Storperf_ | @@ -80,9 +96,17 @@ Yardstick Test Case Description TC074 | | - rr: 100% Read, random access | | | - wr: 100% Write, random access | | | - rw: 70% Read / 30% write, random access | -| | * nossd: Do not perform SSD style preconditioning. | -| | * nowarm: Do not perform a warmup prior to | | | measurements. | +| | * workloads={json maps} | +| | This parameter supercedes the workload and calls the V2.0 | +| | API in StorPerf. It allows for greater control of the | +| | parameters to be passed to FIO. For example, running a | +| | random read/write with a mix of 90% read and 10% write | +| | would be expressed as follows: | +| | {"9010randrw": {"rw":"randrw","rwmixread": "90"}} | +| | Note: This must be passed in as a string, so don't forget | +| | to escape or otherwise properly deal with the quotes. | +| | | | | * report= [job_id] | | | Query the status of the supplied job_id and report on | | | metrics. If a workload is supplied, will report on only | @@ -92,8 +116,7 @@ Yardstick Test Case Description TC074 | | | +--------------+--------------------------------------------------------------+ |pre-test | If you do not have an Ubuntu 14.04 image in Glance, you will | -|conditions | need to add one. A key pair for launching agents is also | -| | required. | +|conditions | need to add one. | | | | | | Storperf is required to be installed in the environment. | | | There are two possible methods for Storperf installation: | @@ -126,10 +149,21 @@ Yardstick Test Case Description TC074 |test sequence | description and expected result | | | | +--------------+--------------------------------------------------------------+ -|step 1 | The Storperf is installed and Ubuntu 14.04 image is stored | -| | in glance. TC is invoked and logs are produced and stored. | +|step 1 | Yardstick calls StorPerf to create the heat stack with the | +| | number of VMs and size of Cinder volumes specified. The | +| | VMs will be on their own private subnet, and take floating | +| | IP addresses from the specified public network. | +| | | ++--------------+--------------------------------------------------------------+ +|step 2 | Yardstick calls StorPerf to fill all the volumes with | +| | random data. | +| | | ++--------------+--------------------------------------------------------------+ +|step 3 | Yardstick calls StorPerf to perform the series of tests | +| | specified by the workload, queue depths and block sizes. | | | | -| | Result: Logs are stored. | ++--------------+--------------------------------------------------------------+ +|step 4 | Yardstick calls StorPerf to delete the stack it created. | | | | +--------------+--------------------------------------------------------------+ |test verdict | None. Storage performance results are fetched and stored. | |