From 3248682fcc789f95ff8246a8d1f208a6a3abd46d Mon Sep 17 00:00:00 2001 From: Emma Foley Date: Wed, 7 Mar 2018 18:40:28 +0000 Subject: [docs] Move user guide chapters to make room for new chapter. * Increment the numbering on chapters * Fix some of the changes flagged by doc8 Change-Id: Ie03d165297671dfd50b9de339612cdc8bf00b988 Signed-off-by: Emma Foley --- docs/testing/user/userguide/13-nsb_operation.rst | 306 ----------------------- 1 file changed, 306 deletions(-) delete mode 100644 docs/testing/user/userguide/13-nsb_operation.rst (limited to 'docs/testing/user/userguide/13-nsb_operation.rst') diff --git a/docs/testing/user/userguide/13-nsb_operation.rst b/docs/testing/user/userguide/13-nsb_operation.rst deleted file mode 100644 index e791b048d..000000000 --- a/docs/testing/user/userguide/13-nsb_operation.rst +++ /dev/null @@ -1,306 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International -.. License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) OPNFV, 2016-2017 Intel Corporation. - -Yardstick - NSB Testing - Operation -=================================== - -Abstract --------- - -NSB test configuration and OpenStack setup requirements - - -OpenStack Network Configuration -------------------------------- - -NSB requires certain OpenStack deployment configurations. -For optimal VNF characterization using external traffic generators NSB requires -provider/external networks. - - -Provider networks -^^^^^^^^^^^^^^^^^ - -The VNFs require a clear L2 connect to the external network in order to generate -realistic traffic from multiple address ranges and port - -In order to prevent Neutron from filtering traffic we have to disable Neutron Port Security. -We also disable DHCP on the data ports because we are binding the ports to DPDK and do not need -DHCP addresses. We also disable gateways because multiple default gateways can prevent SSH access -to the VNF from the floating IP. We only want a gateway on the mgmt network - -.. code-block:: yaml - - uplink_0: - cidr: '10.1.0.0/24' - gateway_ip: 'null' - port_security_enabled: False - enable_dhcp: 'false' - -Heat Topologies -^^^^^^^^^^^^^^^ - -By default Heat will attach every node to every Neutron network that is created. -For scale-out tests we do not want to attach every node to every network. - -For each node you can specify which ports are on which network using the -network_ports dictionary. - -In this example we have ``TRex xe0 <-> xe0 VNF xe1 <-> xe0 UDP_Replay`` - -.. code-block:: yaml - - vnf_0: - floating_ip: true - placement: "pgrp1" - network_ports: - mgmt: - - mgmt - uplink_0: - - xe0 - downlink_0: - - xe1 - tg_0: - floating_ip: true - placement: "pgrp1" - network_ports: - mgmt: - - mgmt - uplink_0: - - xe0 - # Trex always needs two ports - uplink_1: - - xe1 - tg_1: - floating_ip: true - placement: "pgrp1" - network_ports: - mgmt: - - mgmt - downlink_0: - - xe0 - -Collectd KPIs -------------- - -NSB can collect KPIs from collected. We have support for various plugins enabled by the -Barometer project. - -The default yardstick-samplevnf has collectd installed. This allows for collecting KPIs -from the VNF. - -Collecting KPIs from the NFVi is more complicated and requires manual setup. -We assume that collectd is not installed on the compute nodes. - -To collectd KPIs from the NFVi compute nodes: - - - * install_collectd on the compute nodes - * create pod.yaml for the compute nodes - * enable specific plugins depending on the vswitch and DPDK - - example pod.yaml section for Compute node running collectd. - -.. code-block:: yaml - - - - name: "compute-1" - role: Compute - ip: "10.1.2.3" - user: "root" - ssh_port: "22" - password: "" - collectd: - interval: 5 - plugins: - # for libvirtd stats - virt: {} - intel_pmu: {} - ovs_stats: - # path to OVS socket - ovs_socket_path: /var/run/openvswitch/db.sock - intel_rdt: {} - - - -Scale-Up --------- - -VNFs performance data with scale-up - - * Helps to figure out optimal number of cores specification in the Virtual Machine template creation or VNF - * Helps in comparison between different VNF vendor offerings - * Better the scale-up index, indicates the performance scalability of a particular solution - -Heat -^^^^ - -For VNF scale-up tests we increase the number for VNF worker threads and ports. In the case of VNFs -we also need to increase the number of VCPUs and memory allocated to the VNF. - -An example scale-up Heat testcase is: - -.. literalinclude:: /submodules/yardstick/samples/vnf_samples/nsut/vfw/tc_heat_rfc2544_ipv4_1rule_1flow_64B_trex_scale-up.yaml - :language: yaml - -This testcase template requires specifying the number of VCPUs, Memory and Ports. -We set the VCPUs and memory using the ``--task-args`` options - -.. code-block:: console - - yardstick task start --task-args='{"mem": 10480, "vcpus": 4, "ports": 2}' \ - samples/vnf_samples/nsut/vfw/tc_heat_rfc2544_ipv4_1rule_1flow_64B_trex_scale-up.yaml - -In order to support ports scale-up, traffic and topology templates need to be used in testcase. - -A example topology template is: - -.. literalinclude:: /submodules/yardstick/samples/vnf_samples/nsut/vfw/vfw-tg-topology-scale-up.yaml - :language: yaml - -This template has ``vports`` as an argument. To pass this argument it needs to -be configured in ``extra_args`` scenario definition. Please note that more -argument can be defined in that section. All of them will be passed to topology -and traffic profile templates - -For example: - -.. code-block:: yaml - - schema: yardstick:task:0.1 - scenarios: - - type: NSPerf - traffic_profile: ../../traffic_profiles/ipv4_throughput-scale-up.yaml - extra_args: - vports: {{ vports }} - topology: vfw-tg-topology-scale-up.yaml - -A example traffic profile template is: - -.. literalinclude:: /submodules/yardstick/samples/vnf_samples/traffic_profiles/ipv4_throughput-scale-up.yaml - :language: yaml - -There is an option to provide predefined config for SampleVNFs. Path to config -file may by specified in ``vnf_config`` scenario section. - -.. code-block:: yaml - - vnf__0: - rules: acl_1rule.yaml - vnf_config: {lb_config: 'SW', file: vfw_vnf_pipeline_cores_4_ports_2_lb_1_sw.conf } - - -Baremetal -^^^^^^^^^ - 1. Follow above traffic generator section to setup. - 2. edit num of threads in ``/samples/vnf_samples/nsut/vfw/tc_baremetal_rfc2544_ipv4_1rule_1flow_64B_trex_scale_up.yaml`` - - e.g, 6 Threads for given VNF - -.. code-block:: yaml - - - schema: yardstick:task:0.1 - scenarios: - {% for worker_thread in [1, 2 ,3 , 4, 5, 6] %} - - type: NSPerf - traffic_profile: ../../traffic_profiles/ipv4_throughput.yaml - topology: vfw-tg-topology.yaml - nodes: - tg__0: trafficgen_1.yardstick - vnf__0: vnf.yardstick - options: - framesize: - uplink: {64B: 100} - downlink: {64B: 100} - flow: - src_ip: [{'tg__0': 'xe0'}] - dst_ip: [{'tg__0': 'xe1'}] - count: 1 - traffic_type: 4 - rfc2544: - allowed_drop_rate: 0.0001 - 0.0001 - vnf__0: - rules: acl_1rule.yaml - vnf_config: {lb_config: 'HW', lb_count: 1, worker_config: '1C/1T', worker_threads: {{worker_thread}}} - nfvi_enable: True - runner: - type: Iteration - iterations: 10 - interval: 35 - {% endfor %} - context: - type: Node - name: yardstick - nfvi_type: baremetal - file: /etc/yardstick/nodes/pod.yaml - -Scale-Out --------------------- - -VNFs performance data with scale-out - - * Helps in capacity planning to meet the given network node requirements - * Helps in comparison between different VNF vendor offerings - * Better the scale-out index, provides the flexibility in meeting future capacity requirements - - -Standalone -^^^^^^^^^^ - -Scale-out not supported on Baremetal. - -1. Follow above traffic generator section to setup. -2. Generate testcase for standalone virtualization using ansible scripts - - .. code-block:: console - - cd /ansible - trex: standalone_ovs_scale_out_trex_test.yaml or standalone_sriov_scale_out_trex_test.yaml - ixia: standalone_ovs_scale_out_ixia_test.yaml or standalone_sriov_scale_out_ixia_test.yaml - ixia_correlated: standalone_ovs_scale_out_ixia_correlated_test.yaml or standalone_sriov_scale_out_ixia_correlated_test.yaml - - update the ovs_dpdk or sriov above Ansible scripts reflect the setup - -3. run the test - - .. code-block:: console - - /samples/vnf_samples/nsut/tc_sriov_vfw_udp_ixia_correlated_scale_out-1.yaml - /samples/vnf_samples/nsut/tc_sriov_vfw_udp_ixia_correlated_scale_out-2.yaml - -Heat -^^^^ - -There are sample scale-out all-VM Heat tests. These tests only use VMs and don't use external traffic. - -The tests use UDP_Replay and correlated traffic. - -.. code-block:: console - - /samples/vnf_samples/nsut/cgnapt/tc_heat_rfc2544_ipv4_1flow_64B_trex_correlated_scale_4.yaml - -To run the test you need to increase OpenStack CPU, Memory and Port quotas. - - -Traffic Generator tuning ------------------------- - -The TRex traffic generator can be setup to use multiple threads per core, this is for multiqueue testing. - -TRex does not automatically enable multiple threads because we currently cannot detect the number of queues on a device. - -To enable multiple queue set the queues_per_port value in the TG VNF options section. - -.. code-block:: yaml - - scenarios: - - type: NSPerf - nodes: - tg__0: tg_0.yardstick - - options: - tg_0: - queues_per_port: 2 -- cgit 1.2.3-korg