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