summaryrefslogtreecommitdiffstats
path: root/docs/testing/user/userguide/opnfv_yardstick_tc073.rst
blob: ad452640537d874b8a934b343859bac2e6404bb8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
.. This work is licensed under a Creative Commons Attribution 4.0 International
.. License.
.. http://creativecommons.org/licenses/by/4.0
.. (c) OPNFV, Huawei Technologies Co.,Ltd and others.

*************************************
Yardstick Test Case Description TC073
*************************************

.. _netperf: http://www.netperf.org/netperf/training/Netperf.html

+-----------------------------------------------------------------------------+
|Throughput per NFVI node test                                                |
|                                                                             |
+--------------+--------------------------------------------------------------+
|test case id  | OPNFV_YARDSTICK_TC073_Network latency and throughput between |
|              | nodes                                                        |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|metric        | Network latency and throughput                               |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|test purpose  | To evaluate the IaaS network performance with regards to     |
|              | flows and throughput, such as if and how different amounts   |
|              | of packet sizes and flows matter for the throughput between  |
|              | nodes in one pod.                                            |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|configuration | file: opnfv_yardstick_tc073.yaml                             |
|              |                                                              |
|              | Packet size: default 1024 bytes.                             |
|              |                                                              |
|              | Test length: default 20 seconds.                             |
|              |                                                              |
|              | The client and server are distributed on different nodes.    |
|              |                                                              |
|              | For SLA max_mean_latency is set to 100.                      |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|test tool     | netperf_                                                     |
|              | Netperf is a software application that provides network      |
|              | bandwidth testing between two hosts on a network. It         |
|              | supports Unix domain sockets, TCP, SCTP, DLPI and UDP via    |
|              | BSD Sockets. Netperf provides a number of predefined tests   |
|              | e.g. to measure bulk (unidirectional) data transfer or       |
|              | request response performance.                                |
|              | (netperf is not always part of a Linux distribution, hence   |
|              | it needs to be installed.)                                   |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|references    | netperf Man pages                                            |
|              | ETSI-NFV-TST001                                              |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|applicability | Test can be configured with different packet sizes and       |
|              | test duration. Default values exist.                         |
|              |                                                              |
|              | SLA (optional): max_mean_latency                             |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|pre-test      | The POD can be reached by external ip and logged on via ssh  |
|conditions    |                                                              |
+--------------+--------------------------------------------------------------+
|test sequence | description and expected result                              |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|step 1        | Install netperf tool on each specified node, one is as the   |
|              | server, and the other as the client.                         |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|step 2        | Log on to the client node and use the netperf command to     |
|              | execute the network performance test                         |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|step 3        | The throughput results stored.                               |
|              |                                                              |
+--------------+--------------------------------------------------------------+
|test verdict  | Fails only if SLA is not passed, or if there is a test case  |
|              | execution problem.                                           |
|              |                                                              |
+--------------+--------------------------------------------------------------+
itors show as follows, there are four | | | instance of the "openstack-cmd" monitor, in order to check | | | the database connection of different OpenStack components. | | | | | | monitor1: | | | -monitor_type: "openstack-cmd" | | | -api_name: "openstack image list" | | | monitor2: | | | -monitor_type: "openstack-cmd" | | | -api_name: "openstack router list" | | | monitor3: | | | -monitor_type: "openstack-cmd" | | | -api_name: "openstack stack list" | | | monitor4: | | | -monitor_type: "openstack-cmd" | | | -api_name: "openstack volume list" | | | monitor5: | | | -monitor_type: "process" | | | -process_name: "mysql" | | | -host: node1 | | | | +--------------+--------------------------------------------------------------+ |metrics | In this test case, there are two metrics: | | | 1)service_outage_time: which indicates the maximum outage | | | time (seconds) of the specified OpenStack command request. | | | 2)process_recover_time: which indicates the maximum time | | | (seconds) from the process being killed to recovered | | | | +--------------+--------------------------------------------------------------+ |test tool | Developed by the project. Please see folder: | | | "yardstick/benchmark/scenarios/availability/ha_tools" | | | | +--------------+--------------------------------------------------------------+ |references | ETSI NFV REL001 | | | | +--------------+--------------------------------------------------------------+ |configuration | This test case needs two configuration files: | | | 1) test case file: opnfv_yardstick_tc090.yaml | | | -Attackers: see above "attackers" description | | | -waiting_time: which is the time (seconds) from the process | | | being killed to stopping monitors the monitors | | | -Monitors: see above "monitors" description | | | -SLA: see above "metrics" description | | | | | | 2)POD file: pod.yaml | | | The POD configuration should record on pod.yaml first. | | | the "host" item in this test case will use the node name in | | | the pod.yaml. | | | | +--------------+--------------------------------------------------------------+ |test sequence | description and expected result | | | | +--------------+--------------------------------------------------------------+ |step 1 | start monitors: | | | each monitor will run with independently process | | | | | | Result: The monitor info will be collected. | | | | +--------------+--------------------------------------------------------------+ |step 2 | do attacker: connect the host through SSH, and then execute | | | the kill process script with param value specified by | | | "process_name" | | | | | | Result: Process will be killed. | | | | +--------------+--------------------------------------------------------------+ |step 3 | stop monitors after a period of time specified by | | | "waiting_time" | | | | | | Result: The monitor info will be aggregated. | | | | +--------------+--------------------------------------------------------------+ |step 4 | verify the SLA | | | | | | Result: The test case is passed or not. | | | | +--------------+--------------------------------------------------------------+ |post-action | It is the action when the test cases exist. It will check the| | | status of the specified process on the host, and restart the | | | process if it is not running for next test cases | | | | +--------------+--------------------------------------------------------------+ |test verdict | Fails only if SLA is not passed, or if there is a test case | | | execution problem. | | | | +--------------+--------------------------------------------------------------+