COSBench Reviews

COSBench test is a distributed object storage system cloud benchmarking tool, and Driver Controller has two key components, herein briefly by using COSBench RGW Ceph S3 of the test interface.

First, the test environment

ceph cluster operating system version: centos 7.4, the kernel 3.10.0
ceph cluster version: Luminous version (Version: 12.2.10)
cluster size: 3 servers
Number of copies: 3
Creating test tasks in six test client, where 10.11. 16.47 as controller, 10.11.16.48-52 as read-only performance driver, the test cluster.

Second, the download tool

1. Download and unzip tool COSBench
   

wget https://github.com/intel-cloud/cosbench/releases/download/v0.4.2.c4/0.4.2.c4.zip
unzip 0.4.2.c2.zip
复制代码

2. Install java and curl
   

yun install java curl
复制代码

3. 0.4.2.c4 into the directory, giving .sh file execute permissions
   

cd 0.4.2.c4
chmod +x *.sh
复制代码

4. Close http service to prevent conflict
   

unset http_proxy
复制代码

5. Modify conf / controller.conf Configuration
   

[root@conf]# cat controller.conf 
[controller]
drivers = 5
log_level = INFO
log_file = log/system.log
archive_dir = archive

[driver1]
name = driver1
url = http://10.11.16.48:18088/driver

[driver2]
name = driver2
url = http://10.11.16.49:18088/driver

[driver3]
name = driver3
url = http://10.11.16.50:18088/driver

[driver4]
name = driver4
url = http://10.11.16.51:18088/driver

[driver5]
name = driver5
url = http://10.11.16.52:18088/driver
复制代码

6. Each node configuration modification Driver
   

[driver]
name=driver1
url=http://10.11.16.49:18088/driver
复制代码

7. Start COSbench the Driver and Controller
   

sh start-all sh  //Controller节点执行
sh start-driver.sh  //每个Driver节点执行
复制代码

8. Verify
   By default, COSBench the Driver listening port 18088, COSBench the Controller listening port 19088. Log HTTP: // 10.11.16.47 : 19088 / the Controller /

Third, the use

Here the main brief article corresponding configuration file, configuration parameters for each specific need to see COSBench of PDF, can be found in COSBench the official GitHub. New test.conf file in the conf directory, configuration file format is as follows:

<?xml version="1.0" encoding="UTF-8" ?>
<workload name="test_read_only" description="this is a test">
  <storage type="s3" config="accesskey=******;secretkey=******;endpoint=域名:端口号;path_style_access=true" />
  <workflow>
    <workstage name="init">
      <work type="init" workers="1" config="cprefix=zmtest;containers=r(1,10)" />
    </workstage>
    <workstage name="prepare">
      <work type="prepare" workers="1" config="cprefix=zmtest;containers=r(1,10);objects=r(1,100);sizes=c(64)KB" />
    </workstage>
    <workstage name="main">
      <work name="main" workers="30" runtime="300">
        <operation type="read" ratio="0" config="cprefix=zmtest;containers=u(1,10);objects=u(1,100)" />
        <operation type="write" ratio="100" config="cprefix=zmtest;containers=u(1,10);objects=u(101,200);sizes=c(100)KB" />
      </work>
    </workstage>
    <workstage name="cleanup">
      <work type="cleanup" workers="1" config="cprefix=zmtest;containers=r(1,10);objects=r(1,200)" />
    </workstage>
    <workstage name="dispose">
      <work type="dispose" workers="1" config="cprefix=zmtest;containers=r(1,10)" />
    </workstage>
  </workflow>
</workload>
复制代码

Is divided into five stages, init phase is responsible for the order to create an empty bucket 10, bucket prefix zmtest;
PREPARE stage is responsible for writing to each bucket 100 objects, each object size is 64KB, r (1,10) represents from 1-10 increments;
main stage is responsible for reading and writing test, workers represent the number of concurrent, runtime shows that the runtime, type indicates the type, ratio represents the ratio of read and write. Since the test read-only properties described herein, the ratio is read 100, write zero. u (1,10) represents a random 1-10.
cleanup stage cleanup Object;
the Dispose stage clean-up bucket.
If we need to repeatedly test the same batch of data, leaving only the main stage in the total follow-up tests, the rest can be deleted.

Fourth, start the test

Test There are two ways, one is to write the configuration file can be submitted through the web link submit new workloads, and the other is to perform sh script, here briefly sh script execution process.

Performed on the Controller nodes:

[[email protected]]# pwd
/root/0.4.2.c4
[[email protected]]# sh cli.sh submit conf/test.conf
Accepted with ID: w1
复制代码

Fifth, the results of analysis

The figure is not the same parameters and before, just to explain the situation. Parameters as follows:
Op-type - the type of operation
Op-Count - Total operating
Byte-Count - generated by the operation Byte
Avg. ResTime-- the average time generated by the operation
Avg-ProceTime - the average time operation
Throughput - Throughput, mainly reflecting the degree of concurrent operations
Bandwidth - Bandwidth
Succ-ratio - success rate