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
  88 Availability zone
  89 ^^^^^^^^^^^^^^^^^
  90
  91 The configuration of the availability zone is requred in cases where location
  92 of exact compute host/group of compute hosts needs to be specified for SampleVNF
  93 or traffic generator in the heat test case. If this is the case, please follow
  94 the instructions below.
  95
  96 .. _`Create a host aggregate`:
  97
  98 1. Create a host aggregate in the OpenStack and add the available compute hosts
  99    into the aggregate group.
 100
 101    .. note:: Change the ``<AZ_NAME>`` (availability zone name), ``<AGG_NAME>``
 102      (host aggregate name) and ``<HOST>`` (host name of one of the compute) in the
 103      commands below.
 104
 105    .. code-block:: bash
 106
 107      # create host aggregate
 108      openstack aggregate create --zone <AZ_NAME> --property availability_zone=<AZ_NAME> <AGG_NAME>
 109      # show available hosts
 110      openstack compute service list --service nova-compute
 111      # add selected host into the host aggregate
 112      openstack aggregate add host <AGG_NAME> <HOST>
 113
 114 2. To specify the OpenStack location (the exact compute host or group of the hosts)
 115    of SampleVNF or traffic generator in the heat test case, the ``availability_zone`` server
 116    configuration option should be used. For example:
 117
 118    .. note:: The ``<AZ_NAME>`` (availability zone name) should be changed according
 119      to the name used during the host aggregate creation steps above.
 120
 121    .. code-block:: yaml
 122
 123      context:
 124        name: yardstick
 125        image: yardstick-samplevnfs
 126        ...
 127        servers:
 128          vnf__0:
 129            ...
 130            availability_zone: <AZ_NAME>
 131            ...
 132          tg__0:
 133            ...
 134            availability_zone: <AZ_NAME>
 135            ...
 136        networks:
 137          ...
 138
 139 There are two example of SampleVNF scale out test case which use the availability zone
 140 feature to specify the exact location of scaled VNFs and traffic generators.
 141
 142 Those are:
 143
 144 .. code-block:: console
 145
 146   <repo>/samples/vnf_samples/nsut/prox/tc_prox_heat_context_l2fwd_multiflow-2-scale-out.yaml
 147   <repo>/samples/vnf_samples/nsut/vfw/tc_heat_rfc2544_ipv4_1rule_1flow_64B_trex_scale_out.yaml
 148
 149 .. note:: This section describes the PROX scale-out testcase, but the same
 150   procedure is used for the vFW test case.
 151
 152 1. Before running the scale-out test case, make sure the host aggregates are
 153    configured in the OpenStack environment. To check this, run the following
 154    command:
 155
 156    .. code-block:: console
 157
 158      # show configured host aggregates (example)
 159      openstack aggregate list
 160      +----+------+-------------------+
 161      | ID | Name | Availability Zone |
 162      +----+------+-------------------+
 163      |  4 | agg0 | AZ_NAME_0         |
 164      |  5 | agg1 | AZ_NAME_1         |
 165      +----+------+-------------------+
 166
 167 2. If no host aggregates are configured, please use `steps above`__ to
 168    configure them.
 169
 170 __ `Create a host aggregate`_
 171
 172
 173 3. Run the SampleVNF PROX scale-out test case, specifying the availability
 174    zone of each VNF and traffic generator as a task arguments.
 175
 176    .. note:: The ``az_0`` and ``az_1`` should be changed according to the host
 177      aggregates created in the OpenStack.
 178
 179    .. code-block:: console
 180
 181      yardstick -d task start\
 182      <repo>/samples/vnf_samples/nsut/prox/tc_prox_heat_context_l2fwd_multiflow-2-scale-out.yaml\
 183        --task-args='{
 184          "num_vnfs": 4, "availability_zone": {
 185            "vnf_0": "az_0", "tg_0": "az_1",
 186            "vnf_1": "az_0", "tg_1": "az_1",
 187            "vnf_2": "az_0", "tg_2": "az_1",
 188            "vnf_3": "az_0", "tg_3": "az_1"
 189          }
 190        }'
 191
 192    ``num_vnfs`` specifies how many VNFs are going to be deployed in the
 193    ``heat`` contexts. ``vnf_X`` and ``tg_X`` arguments configure the
 194    availability zone where the VNF and traffic generator is going to be deployed.
 195
 196
 197 Collectd KPIs
 198 -------------
 199
 200 NSB can collect KPIs from collected.  We have support for various plugins
 201 enabled by the Barometer project.
 202
 203 The default yardstick-samplevnf has collectd installed. This allows for
 204 collecting KPIs from the VNF.
 205
 206 Collecting KPIs from the NFVi is more complicated and requires manual setup.
 207 We assume that collectd is not installed on the compute nodes.
 208
 209 To collectd KPIs from the NFVi compute nodes:
 210
 211
 212     * install_collectd on the compute nodes
 213     * create pod.yaml for the compute nodes
 214     * enable specific plugins depending on the vswitch and DPDK
 215
 216     example pod.yaml section for Compute node running collectd.
 217
 218 .. code-block:: yaml
 219
 220     -
 221       name: "compute-1"
 222       role: Compute
 223       ip: "10.1.2.3"
 224       user: "root"
 225       ssh_port: "22"
 226       password: ""
 227       collectd:
 228         interval: 5
 229         plugins:
 230           # for libvirtd stats
 231           virt: {}
 232           intel_pmu: {}
 233           ovs_stats:
 234             # path to OVS socket
 235             ovs_socket_path: /var/run/openvswitch/db.sock
 236           intel_rdt: {}
 237
 238
 239
 240 Scale-Up
 241 --------
 242
 243 VNFs performance data with scale-up
 244
 245   * Helps to figure out optimal number of cores specification in the Virtual
 246     Machine template creation or VNF
 247   * Helps in comparison between different VNF vendor offerings
 248   * Better the scale-up index, indicates the performance scalability of a
 249     particular solution
 250
 251 Heat
 252 ^^^^
 253 For VNF scale-up tests we increase the number for VNF worker threads.  In the
 254 case of VNFs we also need to increase the number of VCPUs and memory allocated
 255 to the VNF.
 256
 257 An example scale-up Heat testcase is:
 258
 259 .. literalinclude:: /submodules/yardstick/samples/vnf_samples/nsut/vfw/tc_heat_rfc2544_ipv4_1rule_1flow_64B_trex_scale-up.yaml
 260    :language: yaml
 261
 262 This testcase template requires specifying the number of VCPUs, Memory and Ports.
 263 We set the VCPUs and memory using the ``--task-args`` options
 264
 265 .. code-block:: console
 266
 267   yardstick task start --task-args='{"mem": 10480, "vcpus": 4, "vports": 2}' \
 268   samples/vnf_samples/nsut/vfw/tc_heat_rfc2544_ipv4_1rule_1flow_64B_trex_scale-up.yaml
 269
 270 In order to support ports scale-up, traffic and topology templates need to be used in testcase.
 271
 272 A example topology template is:
 273
 274 .. literalinclude:: /submodules/yardstick/samples/vnf_samples/nsut/vfw/vfw-tg-topology-scale-up.yaml
 275    :language: yaml
 276
 277 This template has ``vports`` as an argument. To pass this argument it needs to
 278 be configured in ``extra_args`` scenario definition. Please note that more
 279 argument can be defined in that section. All of them will be passed to topology
 280 and traffic profile templates
 281
 282 For example:
 283
 284 .. code-block:: yaml
 285
 286    schema: yardstick:task:0.1
 287    scenarios:
 288    - type: NSPerf
 289      traffic_profile: ../../traffic_profiles/ipv4_throughput-scale-up.yaml
 290      extra_args:
 291        vports: {{ vports }}
 292      topology: vfw-tg-topology-scale-up.yaml
 293
 294 A example traffic profile template is:
 295
 296 .. literalinclude:: /submodules/yardstick/samples/vnf_samples/traffic_profiles/ipv4_throughput-scale-up.yaml
 297    :language: yaml
 298
 299 There is an option to provide predefined config for SampleVNFs. Path to config
 300 file may by specified in ``vnf_config`` scenario section.
 301
 302 .. code-block:: yaml
 303
 304    vnf__0:
 305       rules: acl_1rule.yaml
 306       vnf_config: {lb_config: 'SW', file: vfw_vnf_pipeline_cores_4_ports_2_lb_1_sw.conf }
 307
 308
 309 Baremetal
 310 ^^^^^^^^^
 311   1. Follow above traffic generator section to setup.
 312   2. Edit num of threads in
 313      ``<repo>/samples/vnf_samples/nsut/vfw/tc_baremetal_rfc2544_ipv4_1rule_1flow_64B_trex_scale_up.yaml``
 314      e.g, 6 Threads for given VNF
 315
 316 .. code-block:: yaml
 317
 318
 319      schema: yardstick:task:0.1
 320      scenarios:
 321      {% for worker_thread in [1, 2 ,3 , 4, 5, 6] %}
 322      - type: NSPerf
 323        traffic_profile: ../../traffic_profiles/ipv4_throughput.yaml
 324        topology: vfw-tg-topology.yaml
 325        nodes:
 326          tg__0: trafficgen_1.yardstick
 327          vnf__0: vnf.yardstick
 328        options:
 329          framesize:
 330            uplink: {64B: 100}
 331            downlink: {64B: 100}
 332          flow:
 333            src_ip: [{'tg__0': 'xe0'}]
 334            dst_ip: [{'tg__0': 'xe1'}]
 335            count: 1
 336          traffic_type: 4
 337          rfc2544:
 338            allowed_drop_rate: 0.0001 - 0.0001
 339          vnf__0:
 340            rules: acl_1rule.yaml
 341            vnf_config: {lb_config: 'HW', lb_count: 1, worker_config: '1C/1T', worker_threads: {{worker_thread}}}
 342            nfvi_enable: True
 343        runner:
 344          type: Iteration
 345          iterations: 10
 346          interval: 35
 347      {% endfor %}
 348      context:
 349        type: Node
 350        name: yardstick
 351        nfvi_type: baremetal
 352        file: /etc/yardstick/nodes/pod.yaml
 353
 354 Scale-Out
 355 ---------
 356
 357 VNFs performance data with scale-out helps
 358
 359   * in capacity planning to meet the given network node requirements
 360   * in comparison between different VNF vendor offerings
 361   * better the scale-out index, provides the flexibility in meeting future
 362     capacity requirements
 363
 364
 365 Standalone
 366 ^^^^^^^^^^
 367
 368 Scale-out not supported on Baremetal.
 369
 370 1. Follow above traffic generator section to setup.
 371 2. Generate testcase for standalone virtualization using ansible scripts
 372
 373   .. code-block:: console
 374
 375     cd <repo>/ansible
 376     trex: standalone_ovs_scale_out_trex_test.yaml or standalone_sriov_scale_out_trex_test.yaml
 377     ixia: standalone_ovs_scale_out_ixia_test.yaml or standalone_sriov_scale_out_ixia_test.yaml
 378     ixia_correlated: standalone_ovs_scale_out_ixia_correlated_test.yaml or standalone_sriov_scale_out_ixia_correlated_test.yaml
 379
 380   update the ovs_dpdk or sriov above Ansible scripts reflect the setup
 381
 382 3. run the test
 383
 384   .. code-block:: console
 385
 386     <repo>/samples/vnf_samples/nsut/tc_sriov_vfw_udp_ixia_correlated_scale_out-1.yaml
 387     <repo>/samples/vnf_samples/nsut/tc_sriov_vfw_udp_ixia_correlated_scale_out-2.yaml
 388
 389 Heat
 390 ^^^^
 391
 392 There are sample scale-out all-VM Heat tests. These tests only use VMs and
 393 don't use external traffic.
 394
 395 The tests use UDP_Replay and correlated traffic.
 396
 397 .. code-block:: console
 398
 399   <repo>/samples/vnf_samples/nsut/cgnapt/tc_heat_rfc2544_ipv4_1flow_64B_trex_correlated_scale_4.yaml
 400
 401 To run the test you need to increase OpenStack CPU, Memory and Port quotas.
 402
 403
 404 Traffic Generator tuning
 405 ------------------------
 406
 407 The TRex traffic generator can be setup to use multiple threads per core, this
 408 is for multiqueue testing.
 409
 410 TRex does not automatically enable multiple threads because we currently cannot
 411 detect the number of queues on a device.
 412
 413 To enable multiple queue set the ``queues_per_port`` value in the TG VNF
 414 options section.
 415
 416 .. code-block:: yaml
 417
 418   scenarios:
 419     - type: NSPerf
 420       nodes:
 421         tg__0: tg_0.yardstick
 422
 423       options:
 424         tg_0:
 425           queues_per_port: 2
 426
 427
 428 Standalone configuration
 429 ------------------------
 430
 431 NSB supports certain Standalone deployment configurations.
 432 Standalone supports provisioning a VM in a standalone visualised environment using kvm/qemu.
 433 There two types of Standalone contexts available: OVS-DPDK and SRIOV.
 434 OVS-DPDK uses OVS network with DPDK drivers.
 435 SRIOV enables network traffic to bypass the software switch layer of the Hyper-V stack.
 436
 437 Standalone with OVS-DPDK
 438 ^^^^^^^^^^^^^^^^^^^^^^^^
 439
 440 SampleVNF image is spawned in a VM on a baremetal server.
 441 OVS with DPDK is installed on the baremetal server.
 442
 443 .. note:: Ubuntu 17.10 requires DPDK v.17.05 and higher, DPDK v.17.05 requires OVS v.2.8.0.
 444
 445 Default values for OVS-DPDK:
 446
 447   * queues: 4
 448   * lcore_mask: ""
 449   * pmd_cpu_mask: "0x6"
 450
 451 Sample test case file
 452 ^^^^^^^^^^^^^^^^^^^^^
 453
 454   1. Prepare SampleVNF image and copy it to ``flavor/images``.
 455   2. Prepare context files for TREX and SampleVNF under ``contexts/file``.
 456   3. Add bridge named ``br-int`` to the baremetal where SampleVNF image is deployed.
 457   4. Modify ``networks/phy_port`` accordingly to the baremetal setup.
 458   5. Run test from:
 459
 460 .. literalinclude:: /submodules/yardstick/samples/vnf_samples/nsut/acl/tc_ovs_rfc2544_ipv4_1rule_1flow_64B_trex.yaml
 461    :language: yaml