从传统运维到云运维演进历程之软件定义存储

Posted 2020-08-15

前面系列已经讲完了硬件选型、部署、调优，在上线之前呢需要进行性能存储测试，本章主要讲述下测试Ceph的几种常用工具，以及测试方法。

 

关卡四：性能测试关卡

难度：四颗星

说起存储性能永远是第一重要的问题。关于性能有以下几个指标：带宽（Bandwidth）、IOPS、顺序（Sequential）读写、随机（Random）读写、延迟（latency）、持续吞吐（Sustained Throughput）、突发处理能力（Burst I/O）等等。

1、iops&latency   

这是两个衡量存储性能最基本的概念。IOPS (Input/Output Per Second)即每秒的输入输出量(或读写次数)，是衡量存储性能的主要指标之一。IOPS是指单位时间内系统能处理的I/O请求数量，一般以每秒处理的I/O请求数量为单位，I/O请求通常为读或写数据操作请求。另一个重要的性能指标是延迟（等待时间），延迟度量系统运行状况及系统资源可用性，延迟取决于队列。存储系统类似于杂货店收银台排队，每个组件都有确定的性能最大值，系统趋近最大性能会增加延迟。延迟小于10毫秒的目标并非偶然，很多应用系统甚至对延迟更敏感。

2、影响性能的因素

传统存储的封闭特性带来的优势是从存储操作系统软件到专用硬件的深度优化，而软件定义存储、Server SAN的目的是软件和硬件的解耦合，它们带来了灵活性，免除了硬件厂商锁定，但很多时候却不能充分发挥硬件的潜力，给客户造成投资浪费。在分布式Server SAN的环境下，用户不能直接的把部件的性能做简单的加法，就得到整个存储的性能，其原因来自于集群和网络带来的复杂性，也来自于通用操作系统内核（如Linux）对NVMe SSD和万兆以上网络的处理机制不够优化，导致超强的硬件部件性能无法“吐出去”，或者“吐出去”对CPU等核心部件的资源消耗太大，要求过高。同时，由于网络交互在分布式存储中的引入，给存储的整体“时延（latency）”特性带来了挑战，很多分布式存储系统因没有恒定的低时延无法满足高实时性数据库等应用的需求。

利用FIO测试Ceph

硬盘的性能是可以估算出来的，但是怎么才能让应用获得这些性能呢？对于测试工具来说，就是如何得到IOPS、吞吐量和延迟。

FIO简介：

fio 是一个 I/O 工具用来对硬件进行压力测试和验证，支持13种不同的I/O引擎，包括：sync, mmap, libaio, posixaio, SG v3, splice, null, network, syslet, guasi, solarisaio 等等, I/O priorities (for newer Linux kernels), rate I/O, forked or threaded jobs, 等等。它可以对块设备以及文件系统进行性能测试，通过接收一份简单的文本文件来理解工作描述来，结果会显示各种I/O性能信息。该工具在很多地方广泛使用，用来测试性能基准，稳定性验证。它支持Linux，FreeBSD，NetBSD，OS X，OpenSolaris，AIX和Windows。

FIO安装：

1、确保libaio引擎已安装，yum install libaio-devel

2、https://pkgs.org/download/fio  下载fio工具RPM包

3、安装 rpm -ivh fio-2.2.8-2.el7.x86_64.rpm

常用参数说明：

filename: 指定文件(设备)的名称。可以通过冒号分割同时指定多个文件，如filename=/dev/sda:/dev/sdb。

directory: 设置filename的路径前缀。在后面的基准测试中，采用这种方式来指定设备。

name: 指定job的名字，在命令行中表示新启动一个job。

direct: bool类型，如果设置成true (1)，表示不使用io buffer。

ioengine: I/O引擎，现在fio支持19种ioengine。默认值是sync同步阻塞I/O，libaio是Linux的native异步I/O。关于同步异步，阻塞和非阻塞模型。可以参考文章“使用异步 I/O大大提高应用程序的性能”。http://www.ibm.com/developerworks/cn/linux/l-async/

iodepth: 如果ioengine采用异步方式，该参数表示一批提交保持的io单元数。该参数可参考文章“Fio压测工具和io队列深度理解和误区”。http://blog.yufeng.info/archives/2104

rw: I/O模式，随机读写，顺序读写等等。

bs: I/O block大小，默认是4k。

size: 指定job处理的文件的大小。

numjobs: 指定job的克隆数(线程)。

time_based: 如果在runtime指定的时间还没到时文件就被读写完成，将继续重复知道runtime时间结束。

runtime: 指定在多少秒后停止进程。如果未指定该参数，fio将执行至指定的文件读写完全完成。

group_reporting: 当同时指定了numjobs了时，输出结果按组显示。

 

测试方式：

有两种测试方式1.配置文件、2.命令行，这里是讲述下命令行操作。

# fio -filename=/dev/sdx -iodepth=1 -numjobs=1 -thread -rw=randwrite -bs=4k -ioengine=libaio -group_reporting -name=mytest -randrepeat=0 -time_based -runtime=300 -direct=1

上面这种是基于挂载块设备进行测试的，下面讲述下如何使用fio直接测试RBD块。

# fio -direct=1 -iodepth=12 -rw=rw – ioengine=rbd -bs=4k -group_reporting -name=test -numjobs=4 -runtime=600 -clientname=admin -pool=pool-f61ba147fd61441ab272ae96b09e4ee0 -rbdname=volume-fd8f04986a33465d9908f3f97500961b

注意：

其中ioengine更换为rbdI/O引擎，需要在pool参数中指定卷设备所在的存储池ID，rbdname参数需要指定rbd设备的ID

 

以上命令均为举例，现实测试中可以根据实际情况调整iodepth、numjobs、bs大小参数来增加I/O压力，以获得更加性能。

测试指标：

顺序读写（吞吐量，常用单位为MB/s）：文件在硬盘上存储位置是连续的。

适用场景：大文件拷贝（比如视频音乐）。速度即使很高，对数据库性能也没有参考价值。

4K随机读写（IOPS，常用单位为次）：在硬盘上随机位置读写数据，每次4KB。

适用场景：操作系统运行、软件运行、数据库。

 

测试结果关注点：

对于一些新手来说不知道FIO测试出来之后应该关注哪些结果是有价值的，最基本的关注是带宽（bw)和iops，其次关注响应时间（clat）和磁盘利用率（util）。详细介绍可参考荣泽的博客。http://way4ever.com/?p=465

 

利用Cosbench来测试Ceph

Cosbench是Intel的开源云存储性能测试软件，Cosbench目前已经广泛使用与云存储测试，并作为云存储的基准测试工具使用，Cosbench可在windows和linux两种系统中运行，而为了更好的发挥硬件和系统的能力，建议在使用Cosbench进行测试时，选择linux系统。

Cosbench是一个分布式的基准测试工具，测试云对象存储系统，目前为止它支持一些云对象存储系统的测试，Cosbench也允许用户创建额外的存储系统适配器。

1.cosbench安装：

安装Java SDK

# yum install  java-1.7.0-openjdk

# yum install -y nc java-1.7.0-openjdk

安装curl软件

# yum install curl

#yum install nmap-ncat

安装COSBench软件

从https://github.com/intel-cloud/cosbench/releases下载安装文件

# cd 0.4.2.c3

给予权限执行权限

# chmod a+x *.sh

启动COSbench

# ./start-all.sh

出现如下证明安装成功

Successfully started cosbench controller!

Listening on port 0.0.0.0/0.0.0.0:19089 …

Persistence bundle starting…

Persistence bundle started.

———————————————-

!!! Service will listen on web port: 19088 !!!

———————————————-

2.使用Cosbench进行测试

注意：该测试说明基于ceph对象存储测试

 

编辑wokload 文件

可以参照0.4.2.c3/conf目录下的s3-config-sample.xml配置文件，在这里注意将之前在CEPH中分配的RGW用户的AK，SK，已经RGW启用的cvitweb域名端口设置正确：<storage type=”s3″ config=”accesskey=HX1XZCKWT6RDC8GA96AI;secretkey=j0RR17r0yx5jsszstHCTl8bY1usJ4fs1mUJNw8BC;proxyhost=;proxyport=;endpoint=http://192.168.182.128:80” />提交workload执行测试

 

通过以下链接访问COSBench – Controller Web Console

http://:19088/controller/index.html

界面显示

1. 点击submit new workloads 提交workloads文件；

2. 选择文件后，点击提交；

3. 提交成功后，点击view details ,查看详细信息。

workloads xml文件示例：2个节点的3个网关write.xml

说明：

1、该文件中可以更改<work>：
name：名字  不能重复，重复会产生重复数据
works：进程
totalOps：对象总个数
cprefix：桶名的前缀
oprefix：对象名前缀
containers：桶的个数
objects：每个work写入的对象个数
sizes：写入对象的大小
endpoint：存储网关

2、若read，则需要改operation里的type为read，即可；

3、多个work，size大小同时写的话，压力会大。

注意：1. xml配置文件中网关地址格式为http://<网关IP>:<端口号>
2. 小于64K的文件会往索引池中写
3. 在Cosbench 上换算是按照1000算的。例如：若你写4096KB就是4096X1000=4096000，这个就算小文件。正常4M=4194304B

至此Ceph的硬件选型、部署、调优、性能测试等关卡已经讲述完毕，希望本关卡能够给予Ceph新手参考。想要知道葡萄酸不酸，最好的办法就是亲自尝一尝，俗话说：适合自己的才是最好的。对于存储也一样，只有在用户需要的配置方式下，在实际的生产应用系统中，实实在在的运行之后，用户才能真正清楚的感知存储设备的真实性能表现。请读者见仁见智，预知后事如何，请期待《 架构灾备设计》。

本文出自 “态度决定一切” 博客，请务必保留此出处http://sangh.blog.51cto.com/6892345/1863344