1 .. This work is licensed under a Creative Commons Attribution 4.0 International
3 .. http://creativecommons.org/licenses/by/4.0
4 .. (c) OPNFV, Huawei Technologies Co.,Ltd and others.
6 *************************************
7 Yardstick Test Case Description TC074
8 *************************************
10 .. _Storperf: https://wiki.opnfv.org/display/storperf/Storperf
12 +-----------------------------------------------------------------------------+
15 +--------------+--------------------------------------------------------------+
16 |test case id | OPNFV_YARDSTICK_TC074_Storperf |
18 +--------------+--------------------------------------------------------------+
19 |metric | Storage performance |
21 +--------------+--------------------------------------------------------------+
22 |test purpose | To evaluate and report on the Cinder volume performance. |
24 | | This testcase integrates with OPNFV StorPerf to measure |
25 | | block performance of the underlying Cinder drivers. Many |
26 | | options are supported, and even the root disk (Glance |
27 | | ephemeral storage can be profiled. |
29 | | The fundamental concept of the test case is to first fill |
30 | | the volumes with random data to ensure reported metrics |
31 | | are indicative of continued usage and not skewed by |
32 | | transitional performance while the underlying storage |
33 | | driver allocates blocks. |
34 | | The metrics for filling the volumes with random data |
35 | | are not reported in the final results. The test also |
36 | | ensures the volumes are performing at a consistent level |
37 | | of performance by measuring metrics every minute, and |
38 | | comparing the trend of the metrics over the run. By |
39 | | evaluating the min and max values, as well as the slope of |
40 | | the trend, it can make the determination that the metrics |
41 | | are stable, and not fluctuating beyond industry standard |
44 +--------------+--------------------------------------------------------------+
45 |configuration | file: opnfv_yardstick_tc074.yaml |
47 | | * agent_count: 1 - the number of VMs to be created |
48 | | * agent_image: "Ubuntu-14.04" - image used for creating VMs |
49 | | * public_network: "ext-net" - name of public network |
50 | | * volume_size: 2 - cinder volume size |
51 | | * block_sizes: "4096" - data block size |
52 | | * queue_depths: "4" - the number of simultaneous I/Os |
53 | | to perform at all times |
54 | | * StorPerf_ip: "192.168.200.2" |
55 | | * query_interval: 10 - state query interval |
56 | | * timeout: 600 - maximum allowed job time |
58 +--------------+--------------------------------------------------------------+
59 |test tool | Storperf_ |
61 | | StorPerf is a tool to measure block and object storage |
62 | | performance in an NFVI. |
64 | | StorPerf is delivered as a Docker container from |
65 | | https://hub.docker.com/r/opnfv/storperf-master/tags/. |
67 | | The underlying tool used is FIO, and StorPerf supports |
68 | | any FIO option in order to tailor the test to the exact |
69 | | workload needed. |
71 +--------------+--------------------------------------------------------------+
72 |references | Storperf_ |
76 +--------------+--------------------------------------------------------------+
77 |applicability | Test can be configured with different: |
83 | | * query_interval |
85 | | * target=[device or path] |
86 | | The path to either an attached storage device |
87 | | (/dev/vdb, etc) or a directory path (/opt/storperf) that |
88 | | will be used to execute the performance test. In the case |
89 | | of a device, the entire device will be used. If not |
90 | | specified, the current directory will be used. |
91 | | * workload=[workload module] |
92 | | If not specified, the default is to run all workloads. The |
93 | | workload types are: |
95 | | - rs: 100% Read, sequential data |
96 | | - ws: 100% Write, sequential data |
97 | | - rr: 100% Read, random access |
98 | | - wr: 100% Write, random access |
99 | | - rw: 70% Read / 30% write, random access |
103 | | * workloads={json maps} |
104 | | This parameter supercedes the workload and calls the V2.0 |
105 | | API in StorPerf. It allows for greater control of the |
106 | | parameters to be passed to FIO. For example, running a |
107 | | random read/write with a mix of 90% read and 10% write |
108 | | would be expressed as follows: |
109 | | {"9010randrw": {"rw":"randrw","rwmixread": "90"}} |
110 | | Note: This must be passed in as a string, so don't forget |
111 | | to escape or otherwise properly deal with the quotes. |
113 | | * report= [job_id] |
114 | | Query the status of the supplied job_id and report on |
115 | | metrics. If a workload is supplied, will report on only |
117 | | * availability_zone: Specify the availability zone which |
118 | | the stack will use to create instances. |
120 | | Cinder volumes can have different types, for example |
121 | | encrypted vs. not encrypted. |
122 | | To be able to profile the difference between the two. |
123 | | * subnet_CIDR: Specify subnet CIDR of private network |
124 | | * stack_name: Specify the name of the stack that will be |
125 | | created, the default: "StorperfAgentGroup" |
126 | | * volume_count: Specify the number of volumes per |
127 | | virtual machines |
129 | | There are default values for each above-mentioned option. |
131 +--------------+--------------------------------------------------------------+
132 |pre-test | If you do not have an Ubuntu 14.04 image in Glance, you will |
133 |conditions | need to add one. |
135 | | Storperf is required to be installed in the environment. |
136 | | There are two possible methods for Storperf installation: |
138 | | - Run container on Jump Host |
139 | | - Run container in a VM |
141 | | Running StorPerf on Jump Host |
144 | | - Docker must be installed |
145 | | - Jump Host must have access to the OpenStack Controller |
147 | | - Jump Host must have internet connectivity for |
148 | | downloading docker image |
149 | | - Enough floating IPs must be available to match your |
152 | | Running StorPerf in a VM |
155 | | - VM has docker installed |
156 | | - VM has OpenStack Controller credentials and can |
157 | | communicate with the Controller API |
158 | | - VM has internet connectivity for downloading the |
160 | | - Enough floating IPs must be available to match your |
163 | | No POD specific requirements have been identified. |
165 +--------------+--------------------------------------------------------------+
166 |test sequence | description and expected result |
168 +--------------+--------------------------------------------------------------+
169 |step 1 | Yardstick calls StorPerf to create the heat stack with the |
170 | | number of VMs and size of Cinder volumes specified. The |
171 | | VMs will be on their own private subnet, and take floating |
172 | | IP addresses from the specified public network. |
174 +--------------+--------------------------------------------------------------+
175 |step 2 | Yardstick calls StorPerf to fill all the volumes with |
178 +--------------+--------------------------------------------------------------+
179 |step 3 | Yardstick calls StorPerf to perform the series of tests |
180 | | specified by the workload, queue depths and block sizes. |
182 +--------------+--------------------------------------------------------------+
183 |step 4 | Yardstick calls StorPerf to delete the stack it created. |
185 +--------------+--------------------------------------------------------------+
186 |test verdict | None. Storage performance results are fetched and stored. |
188 +--------------+--------------------------------------------------------------+
Code Review / yardstick.git / blob