bcache+drbd性能测试
1、测试环境
架构示意：
1、bcache
2、bcache+drbd
硬件：
172.17.105.223
[0:2:0:0] disk DELL PERC H730 Adp 4.26 /dev/sda 1.19TB
[0:2:1:0] disk DELL PERC H730 Adp 4.26 /dev/sdb 1.19TB
[0:2:4:0] disk DELL PERC H730 Adp 4.26 /dev/sde 799GB
172.17.105.224
[0:2:0:0] disk DELL PERC H730 Adp 4.26 /dev/sda 1.19TB
[0:2:1:0] disk DELL PERC H730 Adp 4.26 /dev/sdb 1.19TB
[0:2:4:0] disk DELL PERC H730 Adp 4.26 /dev/sde 799GB
软件：
bcache（安装配置参见：https://blog.csdn.net/MC_dull_lj/article/details/82761591）、drbd、fio
2、测试过程
（1）单节点配置bcache 性能4k随机写（hdd+ssd分区100G）
1、指令：fio -direct=1 -iodepth 64 -thread -rw=randwrite -ioengine=libaio -bs=4k -size=100G -runtime=300 -ramp_time=5 -group_reporting -name=randwrite -filename=/dev/bcache80
结果：
①创建完成查询显示state为clean，dirty_data=0后，
第1次run：iops=63799。dirty_data上升，hdd无io时，iops可达10w（dirty_data达到write_back_percent之前），见下附图1；之后dirty_data增加，hdd有大量写入，hdd w/s 从3k增长到1w+，ssd w/s 6w，见下附图2。
第2、3次run：iops=733。dirty_data稳定在64G，不再增长，hdd w/s 减去ssd r/s 、ssd w/s与fio iops相近，新写入数据直接从ssd到hdd。iostats见下附图3
②等待数据变为clean，dirty_data=0，并手动触发gc。
第1次run：iops=61338
第2次run：iops=748
缓存被写满
③在dirty_data=30g时，减少压测时间，设置runtime=120，使得每次run不写满缓存，得到稳态数值
第一次run：iops=59148，平均延时1.081ms
第一次run：iops=61591，平均延时1.038ms
测试结论：
1、压测裸ssd4k随机写iops为4w。压测bcache，数据未向hdd提交时iops为10w，向hdd提交时为6w。推测bacahe对随机io有合并。缓存未满，压测时，底层ssd有6w iops，hdd有1w+ iops，性能较优。
2、当上层的大量随机写IO充满缓存空间后，须等待脏数据全部刷完才能继续为写IO提供缓存
3、自动gc间隔时间较长，需要手动触发gc回收ssd空间，否则state为clean之后，写IO仍然无法缓存，iops为700+。
4、GC线程运行时会造成业务IO的波动，iops有为0的时刻。
（2）两节点分别配置一个bcache并做一组drbd
两节点bcache都为clean状态并触发gc，开始测试。
结果：
第1次run：iops=14646
第2次run：iops=9582。iostat见下附图1，hdd w/s 4k，ssd w/s 2k。
第3次run：iops=9808，延时=6.5ms
第4次run：iops=9610，延时=6.6ms
第5次run：iops=9707，延时=6.6ms
测试结论：
1、默认writeback_percent=10，ssd大小为100g，dirty_data下10g后开始往下刷。所以第一次运行iops略高于之后的运行。可配置writeback_percent=0更快获得稳定结果，也可调高该值优化性能。
2、该场景下，运行5次，dirty_data仍维持在十几g，缓存未满，且不容易满。稳定iops为9k+。对比场景（1）（2）可知，在bcache上做drbd性能从6w降低到约1w，性能损耗较大。
对比延时，深度为1时，场景（1）iops=8885，平均延时为0.110ms；场景（2）iops=367，平均延时为2.716ms。
（3）两节点分别配置2个bcache并做2组drbd
两节点bcache都为clean状态并触发gc，开始测试。
结果：
第1次run：iops=18177+19558=37735，延时3.88ms 3.2ms
第2次run：iops=12477+14162=26639。延时5.1ms 4.5ms
第3次run：iops=12409+14364=26773。延时5.1ms 4.4ms
第4次run：iops=13235+14780=28015。延时4.8ms 4.3ms
4次运行后，dirty_data为10+g，缓存未满。
（4）两节点分别配置4个bcache并做4组drbd
配置所有bcache writeback_percent=0
| 第N次run |
fio1 |
fio2 |
fio3 |
fio4 |
总iops |
平均延时 |
|---|---|---|---|---|---|---|
| 1 | 14745 | 15735 | 16808 | 17137 | 64425 | 4-5ms |
| 2 | 9881 | 10668 | 12178 | 12607 | 45334 | 5-6ms |
| 3 | 10071 | 10622 | 11707 | 12096 | 44496 | 5-6ms |
| 4 | 9609 | 10271 | 12029 | 12143 | 44056 | 5-6ms |
| 5 | 11579 | 12383 | 14379 | 15044 | 53385 | 4-5ms |
| 6 | 10688 | 11306 | 13197 | 13680 | 48871 | 4-5ms |
iostat如下：
6次运行后，dirty_data为10+g，缓存未满。
测试结论：
1、由测试场景（2）（3）（4）可知，增加drbd（bcache）数，性能呈线性增长。每组drbd（bcache）仍分别能获得约1w的稳定性能。ssd未达到瓶颈。
（5）加入tgt测试
服务端、客户端配置 展开源码
4k随机写性能对比
①裸压ssd，iops=41302；裸ssd通过tgt挂载，iops=41240。（io深度为64， --bsoflags=direct）
结论：裸ssd通过tgt挂载，几乎没有性能损耗。
②将两节点bcache做drbd，压测drbd，稳定iops=9808；将drbd再通过tgt挂载，稳定iops=4780。（io深度为64， --bsoflags=direct）
结论：将drbd通过tgt挂载，性能损耗将近一半。推测为tgt默认线程为16导致。
③不同io深度下，压测drbd(bcache)和压测drbd(bcache)+tgt的性能对比。（ --bsoflags=direct）
IOPS对比：
| drbd(bcache) | drbd(bcache)+tgt | |||
|---|---|---|---|---|
| 深度 | iops | 延时 | iops | 延时 |
| 1 | 707 | 1.409 | 525 | 1.896 |
| 2 |
512 | 3.894 | 669 | 2.983 |
| 4 | 1565 | 2.551 | 1318 | 3.029 |
| 8 | 2342 | 3.412 | 2266 | 3.527 |
| 16 | 3888 | 4.113 | 3658 | 4.370 |
| 32 | 6743 | 4.744 | 3937 | 8.123 |
| 64 | 9911 | 6.456 | 4634 | 13.81 |
结论：深度为1-16时，有没有tgt相差不大；深度为32时，延时加倍，iops减半。
④将--bstype配置为aio（tgtadm --lld iscsi -m logicalunit --op new --tid 1 --lun 1 --backing-store /dev/drbd1 --bstype=aio）
测试drbd(bcache)+tgt场景，
深度32，iops=6150，平均延时5.2ms
深度64，iops=6560，平均延时9.753ms
结论：配置aio后，当io深度为32时，drbd(bcache)+tgt与drbd(bcache)性能相近。
⑤将tgt线程改为128（tgtd -t 128），direct模式下
测试drbd(bcache)+tgt场景，
深度32，iops=7807，平均延时4.098ms
深度64，iops=7823，平均延时8.174ms
结论：对比③④⑤，io深度为64时，drbd(bcache) iops=9k+，drbd(bcache)+tgt（aio） iops=6k+，drbd(bcache)+tgt（direct，tgt -t 128） iops=7k+。
⑥将bache直接挂给tgt，bcache+tgt，direct模式，tgtd线程128
深度64，iops=30825，平均延时2.093
（6）两节点分别将ssd和hdd盘做drbd0、drbd1，再将drbd0和1做bcache，对bcache进行压测
结果：iops非常不稳定，在几百到几万之间波动，平均iops 1w。该架构不可取。
（7）不同io深度下性能测试数据
测试结论：
1、对比①②，bcache性能与io深度有关，深度越大性能越好。io深度为8时，可以发挥出ssd的性能。
2、对比①②③④⑤，ssd做drbd对性能影响不大，bcache做drbd延时上升了一个数量级。
3、对比④⑥⑦，多组bcache对drbd同时压测，单客户端性能优于单bcache做drbd的性能。压力越大，bcache性能越好。bcache适合一块ssd给多块hdd做缓存这种场景。
4、对比⑧⑨⑩(13)，lio默认配置下32线程性能达到最佳。bcache通过lio挂载后，在32深度以下，性能低于ssd通过lio挂载，在深度达到32时，性能相差不大。
bcache通过lio挂载后，在深度达到32时的性能达到最佳，该值和直接压测bcache性能深度为8相近。bcache通过lio挂载性能优于通过tgt（aio）方式挂载。
5、一组drbd（bcache）通过lio和tgt挂载，在深度为1、32，性能相近。
（8）多组drbd（bcache）通过target挂载后的性能对比
测试结论：
1、对比①②⑥⑦，2组drbd（bcache）通过target挂载后性能比1组drbd（bcache）通过target挂载后性能的两倍大的多。符合（7）-3测试结论。
2、对比①②③④，tgt aio模式下，2组drbd（bcache）通过target挂载后性能和3组、4组drbd（bcache）通过target挂载后性能相近，增加drbd（bcache）组数，性能不再增加，推测tgt的线程数为瓶颈。
3、参照⑧⑨，将两个节点的四组bcache配置为四个drbd资源，每个节点两个主，并通过lio或tgt direct模式挂载。客户端同时对四个lun压测可以得到6w+的性能。