云硬盘测试

我们通过两方面来提高云硬盘的性能的：
降低延迟(使用 SSD，使用万兆网络，优化代码，减少瓶颈)
提高并行度(数据分片，同时使用整个集群的所有 SSD)
在 Linux 下测试云硬盘
在 Linux 下，你可以使用 FIO 来测试
操作系统：Ubuntu 14.04
CPU： 2
Memory: 2GB
云硬盘大小： 1TB(SLA: 6000 IOPS, 170MB/s 吞吐率 )
安装 fio：
#sudo apt-get install fio
再次介绍一下 FIO 的测试参数：
ioengine: 负载引擎，我们一般使用 libaio，发起异步 IO 请求。
bs: IO 大小
direct: 直写，绕过操作系统 Cache。因为我们测试的是硬盘，而不是操作系统的 Cache，所
以设置为 1。
rw: 读写模式，有顺序写 write、顺序读 read、随机写 randwrite、随机读 randread 等。
size: 寻址空间，IO 会落在 [0, size)这个区间的硬盘空间上。这是一个可以影响 IOPS 的参数。
一般设置为硬盘的大小。
filename: 测试对象
iodepth: 队列深度，只有使用 libaio 时才有意义。这是一个可以影响 IOPS 的参数。
runtime: 测试时长
4K 随机写测试
我们首先进行 4K 随机写测试，测试参数和测试结果如下所示：
#fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randwrite -size=100G -filename=/dev/vdb
-name="EBS 4KB randwrite test" -iodepth=32 -runtime=60
蓝色方框表示 IOPS 是 5900，在正常的误差范围内。绿色方框表示 IO 请求的平均响应时间
为 5.42ms， ***方框表示 95%的 IO 请求的响应时间是小于等于 6.24 ms 的。
4K 随机读测试
我们再来进行 4K 随机读测试，测试参数和测试结果如下所示：
#fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randread -size=100G -filename=/dev/vdb
-name="EBS 4KB randread test" -iodepth=8 -runtime=60
512KB 顺序写测试
最后我们来测试 512KB 顺序写，看看云硬盘的最大 MBPS(吞吐率)是多少，测试参数和测
试结果如下所示：
#fio -ioengine=libaio -bs=512k -direct=1 -thread -rw=write -size=100G -filename=/dev/vdb
-name="EBS 512KB seqwrite test" -iodepth=64 -runtime=60
蓝色方框表示 MBPS 为 174226KB/s，约为 170MB/s。
使用 dd 测试吞吐率
其实使用 dd 命令也可以测试出 170MB/s 的吞吐率，不过需要设置一下内核参数，详细介绍
在 128MB/s VS 170MB/s 章节中。
在 Windows 下测试云硬盘
在 Windows 下，我们一般使用 IOMeter 测试磁盘的性能，IOMeter 不仅功能强大，而且很
专业，是测试磁盘性能的首选工具。
IOMeter 是图形化界面(浓浓的 MFC 框架的味道)，非常方便操作，下面我将使用 IOMeter
测试我们 UOS 上 1TB 的云硬盘。
操作系统：Window Server 2012 R2 64
CPU： 4
Memory: 8GB
云硬盘大小： 1TB
当你把云硬盘挂载到 Windows 主机之后，你还需要在 windows 操作系统里面设置硬盘为联
机状态。
4K 随机写测试
打 开 IOMeter( 你 需 要 先 下 载 ) ， 你 会 看 到 IOMeter 的 主 界 面 。 在 右 边 ， 你 回 发 现 4 个
worker(数量和 CPU 个数相同)，因为我们现在只需要 1 个 worker，所以你需要把其他 3 个
worker 移除掉。
现在让我们来测试硬盘的 4K 随机写，我们选择好硬盘(Red Hat VirtIO 0001)，设置寻址空
间 (Maximum Disk Size) 为 50GB( 每 个 硬 盘 扇 区 大 小 是 512B ， 所 以 一 共 是
50*1024*1024*1024/512 = 104857600)，设置队列深度(Outstanding I/Os)为 64。

然后在测试集中选择”4KiB ALIGNED; 0% Read; 100% random(4KB 对齐，100%随机写操

作)” 测试
然后设置测试时间，我们设置测试时长为 60 秒，测试之前的预热时间为 10 秒(IOMeter 会
发起负载，但是不统计这段时间的结果)。

在最后测试之前，你可以设置查看实时结果，设置实时结果的更新频率是 5 秒钟。最后点击
绿色旗子开始测试。
在测试过程中，我们可以看到实时的测试结果，当前的 IOPS 是 6042，平均 IO 请求响应时
间是 10.56ms，这个测试还需要跑 38 秒，这个测试轮回只有这个测试。

我们可以看到 IOMeter 自动化程度很高，极大解放测试人员的劳动力，而且可以导出 CSV

格式的测试结果。
顺序读写测试
我们再按照上面的步骤，进行了顺序读/写测试。下面是测试结果：
IO 大小 读写模式 队列深度 MBPS
顺序写吞吐测试 512KB 顺序写 64 164.07 MB/s

顺序读吞吐测试 256KB 顺序读 64 179.32 MB/s

云硬盘的响应时间
当前云硬盘写操作的主要延迟是
网络传输
多副本，写三份(数据强一致性)
三份数据都落盘(数据持久化)之后，才返回
IO 处理逻辑
我们当前主要是优化 IO 处理逻辑，并没有去优化 2 和 3，这是因为我们是把用户数据的安
全性放在第一位。
128MB/s VS 170MB/s
回到最开始的问题 “为什么使用 dd 命令测试云硬盘只有 128MB/s”， 这是因为目前云硬盘
在处理超大 IO 请求时的延迟比 SSD 高(我们会不断进行优化)，现在我们有两种方法来获得
更高的 MBPS：
设置 max_sectors_kb 为 256 (系统默认为 512)，降低延迟
使用 fio 来测试，加大队列深度
通过设置 max_sectors_kb 这个参数，使用 dd 也可以测出 170MB/s 的吞吐量
root@ustack:~# cat /sys/block/vdb/queue/max_sectors_kb
512
root@ustack:~# echo "256" > /sys/block/vdb/queue/max_sectors_kb
root@ustack:~#
root@ustack:~# dd if=/dev/zero of=/dev/vdb bs=32M count=40 oflag=direct
40+0 records in
40+0 records out
1342177280 bytes (1.3 GB) copied, 7.51685 s, 179 MB/s
root@ustack:~#
同时查看 IO 请求的延迟：
root@ustack:~# iostat -x vdb 5 100
...
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vdb 0.00 0.00 0.00 688.00 0.00 176128.00 512.00 54.59 93.47 0.00 93.47 1.40 96.56
下面是使用 fio 工具的测试结果，也可以得到 170MB/s 的吞吐率。
不可测试的指标
IOPS 和 MBPS 是用户可以使用工具测试的指标，云硬盘还有一些用户不可测量的指标
数据一致性
数据持久性
数据可用性
这些指标我们只能通过根据系统架构和约束条件计算得到，然后转告给用户。这些指标衡
量着公有云厂商的良心，有机会会专门进行介绍。

总结
上面介绍了一下测试工具和一些观点，希望对你有所帮助。
测试需要定性和定量
了解存储模型可以帮助你更好的进行测试
增加队列深度可以有效测试出 IOPS 和 MBPS 的峰值