几种磁盘读写性能相关的服务器磁盘使用策略与压测方法

1、关于磁盘RAID
在以往工作中因为各种缘由，也使用过多种的磁盘高可用配置策略。谈磁盘高可用，大多数时候就是在谈数据冗余保护配置RAID。但当和实际业务结合起来时，保障业务应用的读写性能需求才是第一位重要的，有时不得不要略牺牲一些磁盘高可用设计。
众所周知的，常用RAID级别有0，1，5，6 。
RAID0，只做条带化，直接把数据切分成多段，然后分别写入到多个磁盘中去。因此RAID0具有所有RAID级别中最高的存储性能，写惩罚为1，即只需一次写操作. 同时也不提供任何数据保护能力，一块盘损坏了等于全部磁盘中的数据丢失。
RAID1，磁盘镜像，写惩罚为2，也就是说每一个写操作，都要同时向两块磁盘写入成功后才能结束。虽然如此，但RAID1仍然是兼顾性能与高可用的一个解决方案。
RAID5，交叉地存取数据及奇偶校验信息于所有磁盘上，至少需要3块或以上数量的磁盘且会损失一块磁盘大小的存储容量，较适合小数据块的随机读写。RAID5的写惩罚是4，即每一次写操作,将产生四个实际的读/写操作, 其中两次读旧的数据及奇偶信息, 两次写新的数据及奇偶信息。
RAID6，与RAID 5相比,增加了第二个独立的奇偶校验信息块，需要读取两次校验位和写入两次校验位。两个独立的奇偶系统使用不同的算法, 数据的可靠性非常高。 即使两块磁盘同时失效,也不会影响数据的使用。RAID6的写惩罚是6 。

实际使用中，如果数据很重要，往往还要再额外设置一块“热备盘”。当然这个热备盘对RAID0是不适用的。

大家看到RAID6的写惩罚实在是太高了，可能会认为毫无用处，但在特定的使用场景中确实也有RAID6的身影出没。我接触的一款NetApp nas设备，厂商着力推荐的就是使用RAID6，必竟是可以通过各种手段提高存储设备的写能力，但在数据保护级别上，其它RAID级别最多只能提供同时损坏一块磁盘的能力。

而对于RAID0，毫无数据保护可言，却也有它的用武之地，比如用作CDN加速业务的主机，主机上的数据实际上是可以“丢失”的，因为只是一份缓存加速数据。同一时间，除了源站，还有众多的CDN加速节点上也有同样的数据。

2、关于物理主机的磁盘分区策略与RAID配置策略
无外乎是两种策略，一是使用独立的磁盘作为主机系统盘专用；二是不区分系统盘、数据盘，系统分区和数据分区混用。
这两种策略，其实是无关谁优谁劣的，因为对于各种实际业务使用场景，只有最适用的，没有最佳的解决办法。

（1）对于企业级服务器设备来说，不可能只配置一块磁盘。配置多块磁盘时，除极个别使用场景之外，如运行hadoop，都需要配置磁盘RAID保护。
（2）凡是对磁盘读写性能敏感的业务应用，建议采用RAID1或RAID10；
（3）在有条件的情况下，建议系统盘和数据盘分离，比如另有数据存储阵列、NAS或是分布式存储系统，为系统盘直接使用两块中高性能的磁盘配置为RAID1使用；
（4）即便是运行hadoop这种分布式系统的datanode节点，也不要让系统盘直接使用一块磁盘去跑，虽然挂掉一台datanode节点主机不会影响hadoop平台继续正常运转，但下线、修复、重新配置上线并加入集群平台太浪费时间了；
（5）在磁盘资源条件比较紧张时，可以直接采取不区分系统盘、数据盘的策略，所有磁盘配置为一个RAID10，有时一台主机上的应用程序和数据需要全部基于本地磁盘进行读写且读写很频繁，这种情况下再单独为系统盘划出两块磁盘跑系统显得过于奢侈了，必竟保证为业务应用提供足够的磁盘IO能力才是第一位重要的；
（6）磁盘容量越大，这里指的主要是传统的机械磁盘，意味着磁盘的IOPS能力越低，比如一块300GB 10K转速的磁盘的IOPS能力大约要比一块600GB 10K转速的磁盘高出1/3 ，所以在磁盘性能和容量的选择上需要预先做好技术分析，避免容量够了，性能又不达标了，尤其是对于要在本地运行mysql数据库的情况来说，会对磁盘IO性能更加敏感；
（7）为swap分区设置合理的空间，尤其是在物理内存紧张的情况下，至少可以避免因内存溢出引发的当机；
（8）在同一个RAID磁盘分组中的物理磁盘数量越多，意味着RAID后得到的逻辑磁盘所具有的IOPS能力越大，这是因为数据是被切分成多块后分别分布存储到一组磁盘中的；
（9）是否设置热备盘要看团队的运维能力而定，如果已经做到每天自动检查物理磁盘是否发生故障，且在一块磁盘出现坏块后能够在较短时间内更换受损磁盘，那么就没有必要使用热备盘。对于一个只能挂载8块或12块磁盘的主机或小型存储阵列而言，如果设置一块盘作为热备盘，对于数据库业务应用来说就只能基于6块或10块磁盘配置RAID10，这不但降低了存储容量，也同时降低了总的IOPS能力。

3、关于IOPS测试数据
下面是一个很笼统的估算公式：
物理磁盘总的IOPS = 物理磁盘的IOPS × 磁盘数目
可用的IOPS = （物理磁盘总的IOPS × 写百分比 ÷ RAID写惩罚） + （物理磁盘总的IOPS × 读百分比）

对于公司线上生产环境中主机或存储设备的磁盘高可用配置策略的调整，需要特别谨慎，需要有直接的、准确的iops测试数据作为支持，才能调整或改变一直沿用的存储管理策略。

我们一般使用fio来测试磁盘的IOPS能力。如果是运行mysql数据库应用，建议另外使用tpcc测试数据库的处理能力。
在一个主机或系统上线前，应该测试和收集它的磁盘IOPS读写能力数据；在准备使用一个新的磁盘配置管理策略时，也需要先测试其IOPS数据作为依据。

下面是几组测试方法和参数
fio测试磁盘/dev/sdb1随机读：
fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=randread -ioengine=psync -bs=16k -size=200G -numjobs=10 -runtime=300 -group_reporting -name=mytest

fio测试磁盘/dev/sdb1 随机写：
fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=16k -size=200G -numjobs=30 -runtime=300 -group_reporting -name=mytest

测试参数说明：

filename=/dev/sdb1       测试文件名称，通常选择需要测试的盘的data目录。

direct=1                     测试过程绕过机器自带的buffer。使测试结果更真实。
rw=randwrite             测试随机写的I/O
rw=randread             测试随机读的I/O
bs=16k                      单次io的块文件大小为16k
bsrange=512-2048         同上，提定数据块的大小范围
size=200g    本次的测试文件大小为200g，以每次16k的io进行测试。
numjobs=10               本次的测试线程为10.
runtime=300             测试时间为300秒。
ioengine=psync           io引擎使用pync方式
group_reporting          关于显示结果的，汇总每个进程的信息。

测试报告解析说明：

io= 执行了多少M的IO

bw= 平均IO带宽

iops=   IOPS

runt= 线程运行时间

slat 提交延迟

clat 完成延迟

e5b5

lat响应时间

bw 带宽

cpu利用率

IO depths=io队列

IO submit=单个IO提交要提交的IO数

IO complete= Like the above submit number, but for completions instead.

IO issued= The number of read/write requests issued, and how many

of them were short.

IO latencies=IO完延迟的分布

4、关于TPCC测试
tpcc测试方法和工具请自行在网上检索即可。该工具的使用也比较简单。
对于运行mysql数据库应用的系统，建议在上线前先对该数据库执行几次TPCC测试，收集和存放好测试结果数据。用于日后的维护、优化工作，作为参考。尤其是在对运行数据库应用的主机、存储或数据库软件版本做出调整后，建议都重新做一下TPCC压测。以证实该次调优是否达到了设计意图。

对于系统管理员或数据库DBA来说，了解自己的系统性能上限是多少是很重要的。

以下给出一组测试数据，供大家参考。
一套mysql 数据库的DRBD双机高可用系统。
双物理主机的配置相同，均为：cpu E5-2620 v4 @ 2.10GHz ， 内存64GB，磁盘8*600 RAID10 。
双机上各划1.2TB磁盘分区配置为DRBD网络共享磁盘。双机间使用千兆网络连接。

预装载500个仓库的压测数据。

压测30分钟：
./tpcc_start -h192.168.110.48 -uroot -p123456 -d tpcc -w 500 -c 256 -r 300 -l 1800 -f ./tpcc_mysql_256_20170226.log

压测通过，结果如下：
<Raw Results>
  [0] sc:293979  lt:2672  rt:0  fl:0
  [1] sc:296648  lt:47  rt:0  fl:0
  [2] sc:29656  lt:7  rt:0  fl:0
  [3] sc:29633  lt:0  rt:0  fl:0
  [4] sc:29683  lt:0  rt:0  fl:0
 in 1800 sec.

<Raw Results2(sum ver.)>
  [0] sc:293982  lt:2672  rt:0  fl:0
  [1] sc:296660  lt:47  rt:0  fl:0
  [2] sc:29656  lt:7  rt:0  fl:0
  [3] sc:29634  lt:0  rt:0  fl:0
  [4] sc:29683  lt:0  rt:0  fl:0

<Constraint Check> (all must be [OK])
 [transaction percentage]
        Payment: 43.48% (>=43.0%) [OK]
   Order-Status: 4.35% (>= 4.0%) [OK]
       Delivery: 4.34% (>= 4.0%) [OK]
    Stock-Level: 4.35% (>= 4.0%) [OK]
 [response time (at least 90% passed)]
      New-Order: 99.10%  [OK]
        Payment: 99.98%  [OK]
   Order-Status: 99.98%  [OK]
       Delivery: 100.00%  [OK]
    Stock-Level: 100.00%  [OK]

<TpmC>
                 9888.366 TpmC

压测过程输出解读见下：
-- 以逗号分隔，共6列
-- 第一列，第N次10秒
-- 第二列，总成功执行压测的次数(总推迟执行压测的次数):90%事务的响应时间|本轮测试最大响应时间
-- 第三列，新订单业务成功执行次数(推迟执行次数):90%事务的响应时间|本轮测试最大响应时间
-- 第四列，支付业务的结果，后面几个的意义同上
-- 第五列，发货业务的结果，后面几个的意义同上
-- 第六列，库存业务的结果，后面几个的意义同上

-- 第一次粗略结果统计

[0] sc:100589 lt:0 rt:0 fl:0 -- New-Order，新订单业务成功(success,简写sc)次数，延迟(late,简写lt)次数，重试(retry,简写rt)次数，失败(failure,简写fl)次数
[1] sc:100552 lt:0 rt:0 fl:0 -- Payment，支付业务统计，其他同上
[2] sc:10059 lt:0 rt:0 fl:0 -- Order-Status，订单状态业务统计，其他同上
[3] sc:10057 lt:0 rt:0 fl:0 -- Delivery，发货业务统计，其他同上
[4] sc:10058 lt:0 rt:0 fl:0 -- Stock-Level，库存业务统计，其他同上

测试结果统计分析
(all must be [OK]) -- 下面所有业务逻辑结果都必须为 OK 才行
[transaction percentage]
Payment: 43.47% (>=43.0%) [OK] -- 支付成功次数(上述统计结果中 sc + lt)必须大于43.0%，否则结果为NG，而不是OK
Order-Status: 4.35% (>= 4.0%) [OK] -- 订单状态，其他同上
Delivery: 4.35% (>= 4.0%) [OK] -- 发货，其他同上
Stock-Level: 4.35% (>= 4.0%) [OK] -- 库存，其他同上
[response time (at least 90% passed)] -- 响应耗时指标必须超过90%通过才行
New-Order: 100.00% [OK] -- 下面几个响应耗时指标全部 100% 通过
Payment: 100.00% [OK]
Order-Status: 100.00% [OK]
Delivery: 100.00% [OK]
Stock-Level: 100.00% [OK]

以及最终的tpcc测试结果

9888.366  TpmC -- TpmC结果值，即每分钟的事务数

测试后，再次压测前需要做的清理工作：
# sync  -- 将脏数据刷新到磁盘
# echo 3 > /proc/sys/vm/drop_caches  -- 清除OS Cache
# swapoff -a && swapon -a

或者重启整个OS。