docs/testing/user/userguide/13-nsb_operation.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International
   2 .. License.
   3 .. http://creativecommons.org/licenses/by/4.0
   4 .. (c) OPNFV, 2016-2017 Intel Corporation.
   5
   6 Yardstick - NSB Testing - Operation
   7 ===================================
   8
   9 Abstract
  10 --------
  11
  12 NSB test configuration and OpenStack setup requirements
  13
  14
  15 OpenStack Network Configuration
  16 -------------------------------
  17
  18 NSB requires certain OpenStack deployment configurations.
  19 For optimal VNF characterization using external traffic generators NSB requires
  20 provider/external networks.
  21
  22
  23 Provider networks
  24 ^^^^^^^^^^^^^^^^^
  25
  26 The VNFs require a clear L2 connect to the external network in order to generate
  27 realistic traffic from multiple address ranges and port
  28
  29 In order to prevent Neutron from filtering traffic we have to disable Neutron Port Security.
  30 We also disable DHCP on the data ports because we are binding the ports to DPDK and do not need
  31 DHCP addresses.  We also disable gateways because multiple default gateways can prevent SSH access
  32 to the VNF from the floating IP.  We only want a gateway on the mgmt network
  33
  34 .. code-block:: yaml
  35
  36     uplink_0:
  37       cidr: '10.1.0.0/24'
  38       gateway_ip: 'null'
  39       port_security_enabled: False
  40       enable_dhcp: 'false'
  41
  42 Heat Topologies
  43 ^^^^^^^^^^^^^^^
  44
  45 By default Heat will attach every node to every Neutron network that is created.
  46 For scale-out tests we do not want to attach every node to every network.
  47
  48 For each node you can specify which ports are on which network using the
  49 network_ports dictionary.
  50
  51 In this example we have ``TRex xe0 <-> xe0 VNF xe1 <-> xe0 UDP_Replay``
  52
  53 .. code-block:: yaml
  54
  55       vnf_0:
  56         floating_ip: true
  57         placement: "pgrp1"
  58         network_ports:
  59           mgmt:
  60             - mgmt
  61           uplink_0:
  62             - xe0
  63           downlink_0:
  64             - xe1
  65       tg_0:
  66         floating_ip: true
  67         placement: "pgrp1"
  68         network_ports:
  69           mgmt:
  70             - mgmt
  71           uplink_0:
  72             - xe0
  73           # Trex always needs two ports
  74           uplink_1:
  75             - xe1
  76       tg_1:
  77         floating_ip: true
  78         placement: "pgrp1"
  79         network_ports:
  80           mgmt:
  81            - mgmt
  82           downlink_0:
  83            - xe0
  84
  85 Collectd KPIs
  86 -------------
  87
  88 NSB can collect KPIs from collected.  We have support for various plugins enabled by the
  89 Barometer project.
  90
  91 The default yardstick-samplevnf has collectd installed.   This allows for collecting KPIs
  92 from the VNF.
  93
  94 Collecting KPIs from the NFVi is more complicated and requires manual setup.
  95 We assume that collectd is not installed on the compute nodes.
  96
  97 To collectd KPIs from the NFVi compute nodes:
  98
  99
 100     * install_collectd on the compute nodes
 101     * create pod.yaml for the compute nodes
 102     * enable specific plugins depending on the vswitch and DPDK
 103
 104     example pod.yaml section for Compute node running collectd.
 105
 106 .. code-block:: yaml
 107
 108     -
 109       name: "compute-1"
 110       role: Compute
 111       ip: "10.1.2.3"
 112       user: "root"
 113       ssh_port: "22"
 114       password: ""
 115       collectd:
 116         interval: 5
 117         plugins:
 118           # for libvirtd stats
 119           virt: {}
 120           intel_pmu: {}
 121           ovs_stats:
 122             # path to OVS socket
 123             ovs_socket_path: /var/run/openvswitch/db.sock
 124           intel_rdt: {}
 125
 126
 127
 128 Scale-Up
 129 --------
 130
 131 VNFs performance data with scale-up
 132
 133   * Helps to figure out optimal number of cores specification in the Virtual Machine template creation or VNF
 134   * Helps in comparison between different VNF vendor offerings
 135   * Better the scale-up index, indicates the performance scalability of a particular solution
 136
 137 Heat
 138 ^^^^
 139
 140 For VNF scale-up tests we increase the number for VNF worker threads and ports.  In the case of VNFs
 141 we also need to increase the number of VCPUs and memory allocated to the VNF.
 142
 143 An example scale-up Heat testcase is:
 144
 145 .. literalinclude:: /submodules/yardstick/samples/vnf_samples/nsut/vfw/tc_heat_rfc2544_ipv4_1rule_1flow_64B_trex_scale-up.yaml
 146    :language: yaml
 147
 148 This testcase template requires specifying the number of VCPUs, Memory and Ports.
 149 We set the VCPUs and memory using the ``--task-args`` options
 150
 151 .. code-block:: console
 152
 153   yardstick task start --task-args='{"mem": 10480, "vcpus": 4, "ports": 2}' \
 154   samples/vnf_samples/nsut/vfw/tc_heat_rfc2544_ipv4_1rule_1flow_64B_trex_scale-up.yaml
 155
 156 In order to support ports scale-up, traffic and topology templates need to be used in testcase.
 157
 158 A example topology template is:
 159
 160 .. literalinclude:: /submodules/yardstick/samples/vnf_samples/nsut/vfw/vfw-tg-topology-scale-up.yaml
 161    :language: yaml
 162
 163 This template has ``vports`` as an argument. To pass this argument it needs to
 164 be configured in ``extra_args`` scenario definition. Please note that more
 165 argument can be defined in that section. All of them will be passed to topology
 166 and traffic profile templates
 167
 168 For example:
 169
 170 .. code-block:: yaml
 171
 172    schema: yardstick:task:0.1
 173    scenarios:
 174    - type: NSPerf
 175      traffic_profile: ../../traffic_profiles/ipv4_throughput-scale-up.yaml
 176      extra_args:
 177        vports: {{ vports }}
 178      topology: vfw-tg-topology-scale-up.yaml
 179
 180 A example traffic profile template is:
 181
 182 .. literalinclude:: /submodules/yardstick/samples/vnf_samples/traffic_profiles/ipv4_throughput-scale-up.yaml
 183    :language: yaml
 184
 185 There is an option to provide predefined config for SampleVNFs. Path to config
 186 file may by specified in ``vnf_config`` scenario section.
 187
 188 .. code-block:: yaml
 189
 190    vnf__0:
 191       rules: acl_1rule.yaml
 192       vnf_config: {lb_config: 'SW', file: vfw_vnf_pipeline_cores_4_ports_2_lb_1_sw.conf }
 193
 194
 195 Baremetal
 196 ^^^^^^^^^
 197   1. Follow above traffic generator section to setup.
 198   2. edit num of threads in ``<repo>/samples/vnf_samples/nsut/vfw/tc_baremetal_rfc2544_ipv4_1rule_1flow_64B_trex_scale_up.yaml``
 199
 200   e.g, 6 Threads  for given VNF
 201
 202 .. code-block:: yaml
 203
 204
 205      schema: yardstick:task:0.1
 206      scenarios:
 207      {% for worker_thread in [1, 2 ,3 , 4, 5, 6] %}
 208      - type: NSPerf
 209        traffic_profile: ../../traffic_profiles/ipv4_throughput.yaml
 210        topology: vfw-tg-topology.yaml
 211        nodes:
 212          tg__0: trafficgen_1.yardstick
 213          vnf__0: vnf.yardstick
 214        options:
 215          framesize:
 216            uplink: {64B: 100}
 217            downlink: {64B: 100}
 218          flow:
 219            src_ip: [{'tg__0': 'xe0'}]
 220            dst_ip: [{'tg__0': 'xe1'}]
 221            count: 1
 222          traffic_type: 4
 223          rfc2544:
 224            allowed_drop_rate: 0.0001 - 0.0001
 225          vnf__0:
 226            rules: acl_1rule.yaml
 227            vnf_config: {lb_config: 'HW', lb_count: 1, worker_config: '1C/1T', worker_threads: {{worker_thread}}}
 228            nfvi_enable: True
 229        runner:
 230          type: Iteration
 231          iterations: 10
 232          interval: 35
 233      {% endfor %}
 234      context:
 235        type: Node
 236        name: yardstick
 237        nfvi_type: baremetal
 238        file: /etc/yardstick/nodes/pod.yaml
 239
 240 Scale-Out
 241 --------------------
 242
 243 VNFs performance data with scale-out
 244
 245   * Helps in capacity planning to meet the given network node requirements
 246   * Helps in comparison between different VNF vendor offerings
 247   * Better the scale-out index, provides the flexibility in meeting future capacity requirements
 248
 249
 250 Standalone
 251 ^^^^^^^^^^
 252
 253 Scale-out not supported on Baremetal.
 254
 255 1. Follow above traffic generator section to setup.
 256 2. Generate testcase for standalone virtualization using ansible scripts
 257
 258   .. code-block:: console
 259
 260     cd <repo>/ansible
 261     trex: standalone_ovs_scale_out_trex_test.yaml or standalone_sriov_scale_out_trex_test.yaml
 262     ixia: standalone_ovs_scale_out_ixia_test.yaml or standalone_sriov_scale_out_ixia_test.yaml
 263     ixia_correlated: standalone_ovs_scale_out_ixia_correlated_test.yaml or standalone_sriov_scale_out_ixia_correlated_test.yaml
 264
 265   update the ovs_dpdk or sriov above Ansible scripts reflect the setup
 266
 267 3. run the test
 268
 269   .. code-block:: console
 270
 271     <repo>/samples/vnf_samples/nsut/tc_sriov_vfw_udp_ixia_correlated_scale_out-1.yaml
 272     <repo>/samples/vnf_samples/nsut/tc_sriov_vfw_udp_ixia_correlated_scale_out-2.yaml
 273
 274 Heat
 275 ^^^^
 276
 277 There are sample scale-out all-VM Heat tests.  These tests only use VMs and don't use external traffic.
 278
 279 The tests use UDP_Replay and correlated traffic.
 280
 281 .. code-block:: console
 282
 283   <repo>/samples/vnf_samples/nsut/cgnapt/tc_heat_rfc2544_ipv4_1flow_64B_trex_correlated_scale_4.yaml
 284
 285 To run the test you need to increase OpenStack CPU, Memory and Port quotas.
 286
 287
 288 Traffic Generator tuning
 289 ------------------------
 290
 291 The TRex traffic generator can be setup to use multiple threads per core, this is for multiqueue testing.
 292
 293 TRex does not automatically enable multiple threads because we currently cannot detect the number of queues on a device.
 294
 295 To enable multiple queue set the queues_per_port value in the TG VNF options section.
 296
 297 .. code-block:: yaml
 298
 299   scenarios:
 300     - type: NSPerf
 301       nodes:
 302         tg__0: tg_0.yardstick
 303
 304       options:
 305         tg_0:
 306           queues_per_port: 2