Ceph性能测试总结

Ceph性能测试总结

测试目的：

通过对ceph集群块接口常见性能指标进行简单测试，达到以下几个目的：

1. 了解当前集群配置方案对硬件性能的利用情况；
2. 验证集群性能计算公式的正确性；
3. 识别集群性能瓶颈点；
4. 为后续性能优化提供部分参考；

测试指标：

块接口IOPS，带宽，时延

硬盘性能一般使用以下几个指标对其性能进行描述：

• IOPS：每秒读/写次数，单位为次（计数）。存储设备的底层驱动类型决定了不同的 IOPS。
• 带宽：每秒的读写数据量，单位为MB/s。
• 时延：IO操作的发送时间到接收确认所经过的时间，单位为秒。

ceph提供的3种接口：块，文件和对象接口都是基于rados层进行的包装，通过测试块接口能够将集群的整体性能充分挖掘出来。

测试原则：

1. 理论上网络带宽是可以远大于磁盘带宽的，但目前OSD节点磁盘密度过高，所需带宽无法满足，这种条件下网络带宽会成为瓶颈，导致集群最大带宽没有参考价值；
2. 所有的测试结果都建立在同一个条件下：网络带宽未被osd占满，所有磁盘带宽被osd几乎全部占满(100%使用率)；
3. 本次测试是针对ceph有bcache时的性能情况；
4. 测试结果数据统计方法：多个客户端同时并发时，统计读写带宽和IOPS时计算所有客户端求和结果，读写时延取平均值；
5. 查看节点上磁盘带宽使用命令iostat -dmx 3，查看节点上网络带宽使用命令sar -n DEV 3

环境信息：

名称	说明	数量/单位
mon节点	mon + mds + mgr + rgw	3
osd节点	Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz 128GB memory 16 * 2.4TB SAS 4 * 480GB SSD 2个10GE网卡组成一个bond口(public network 和 cluster network共用) Bonding Mode: IEEE 802.3ad Dynamic link aggregation Transmit Hash Policy: layer3+4 (1)	5
OS	CentOS Linux release 7.5.1804 kernel: 4.17.6-1.el7.elrepo.x86_64
bcache	ssd与sas按照1比4进行聚合 cache_mode: writeback
ceph	luminous v12.2.7 + blustore + 3副本
fio	3.1

集群性能计算公式：

首先需要测试出OSD所使用单盘的各项性能指标，然后按照下面公式推算集群总体性能

1. 每块SAS磁盘作为一个OSD，有一块SSD磁盘专门跑RocksDB。数据会被直接写入到data分区(裸盘）中，而对象元数据会被写到RocksDB和RocksDB的WAL中，也就是单OSD的写放大系数就变成1；
2. 假设OSD个数为N；
3. 假设副本数是M，数据直到写入M个OSD之后才响应，因此对于多副本存储池，写放大系数是M；
4. 因为ceph软件会损耗CPU资源，也会损耗一些性能，损耗系数定为0.7；
5. 假设单块SSD的4K随机读IOPS是R，4K随机写IOPS是W，1M顺序写带宽是B。
   在不考虑网络瓶颈和CPU瓶颈的情况下，ceph存储池的性能估算公式是：

• 4K随机读IOPS = R*N *0.7
• 4K随机写IOPS = W*N *0.7/(M)
• 1M顺序写带宽 = B*N *0.7/(M)

测试方法及脚本

• 创建60个测试卷

for i in {1..60};do rbd create fio_test$i --size 10G; done

• 对卷进行填充，由于ceph使用了cow机制，如果不填充后面在写数据的时候需要进行空间分配，会影响性能结果

for i in {1..60}; do fio -ioengine=rbd -pool=rbd -rbdname=fio_test$i -clientname=admin -direct=1 -iodepth 256 -thread -rw=write -bs=1m -size=10G -numjobs=1  -runtime=300 -name=mytest; done

• 准备一个脚本用于在screen内执行一条命令 myscreen.sh
  格式：myscreen.sh <screen_name>

#!/bin/bash
set -x
screen_name=$1
cmd=$2
screen -dmS $screen_name
screen -x -S $screen_name -p 0 -X stuff "$cmd"
screen -x -S $screen_name -p 0 -X stuff $'\n'

• 通过myscreen.sh同时执行多条fio命令
  示例：同时开启5个fio client，跑4k随机写，卷名字以fio_test开头加客户端序号

for i in {1..5}; do ./myscreen.sh s$i "fio -ioengine=rbd -pool=rbd -rbdname=fio_test$i -clientname=admin -direct=1 -iodepth 256 -thread -rw=randwrite -bs=4k -size=10G -numjobs=1  -runtime=300 -name=mytest"; done

性能测试结果

单盘性能

测试项	IOPS		BW(MB/s)		AVG_LAT(ms)
	4K随机读	4K随机写	64K/1M顺序读	64K/1M顺序写	4K随机读	4K随机写
SSD盘+xfs	67.9k	22.2k	495	409	0.118	0.091
SAS裸盘	1129	749	256	246	4.1	1.3
bcache聚合设备裸盘	72.6k	56.2k	256	243	0.071	0.067

集群性能

测试项	IOPS		BW(MB/s)		AVG_LAT(ms)
	4K随机读	4K随机写	64K/1M顺序读	64K/1M顺序写	4K随机读	4K随机写
集群总性能	116k	88k	4500	1800	0.965	2.541

小结

集群1M顺序读带宽测试：
1M顺序读带宽按照公式应该为 240MB/s * 80 * 0.7 = 13440MB/s
实际测试结果为 4500MB/s，大约为总性能的33%

原因分析：
9个clients同时并发大块读时osd节点资源占用情况如下：
磁盘%util大约40%，
osd节点占用网卡带宽大约900MB/s，通过iperf工具测试bond口带宽为1GB/s，
此时带宽为性能瓶颈，读性能接近网卡带宽的总和900MB/s * 5 = 4500MB/s，符合实际测试结果值。

集群1M顺序写带宽测试：
1M顺序写带宽按照公式应该为 240MB/s * 80 * 0.7 / 3 = 4500MB/s
实际测试结果为 1800MB/s，大约为总性能的40%

原因分析：
3个clients同时并发大块写时osd节点资源占用情况如下：
磁盘%util大约40%，
osd节点占用网卡带宽大约900MB/s，通过iperf工具测试bond口带宽为1GB/s，
此时带宽为性能瓶颈，写性能接近网卡带宽的总和900MB/s * 5 / 3 = 1500MB/s，和实际测试结果值相差不大。

集群4K随机写IOPS测试：
4K随机写IOPS按照公式应该为： 56.2k * 4 * 5 * 0.7 / 3 = 262k

注：4K随机写数据基本能够全部落盘到SSD cache中，
且当cache写满后存在回刷的性能损耗，因此集群4K随机写IOPS的理论计算公式是按照SSD盘的数量20来计算得到

实际测试结果为88k，大约为总性能的33%

原因分析：
8台服务器，每个上面5个clients，同时并发测试4k随机写时osd节点资源占用情况如下：
磁盘%util大约60%
单个client IOPS：2200，集群总IOPS为 2200 * 5 * 8≈88k
fio跑时单节点cpu最大IOPS大约为10k，此时cpu成为瓶颈，如果要将集群IOPS跑满还需要增加client来提高压力

集群4k随机读IOPS测试：
4K随机写IOPS按照公式应该为： 72.6k * 4 * 5 * 0.7 = 1016.4k
实际测试结果为116k，大约为总性能的11%

原因分析：
和4k随机写性能结果类似，cpu为性能瓶颈

综上，当前环境部署方案能够满足常见的性能指标，文件和对象接口由于只部署了1个进程或主备部署，无法将所有磁盘性能发挥到最大，因此对于mds和rgw要考虑在多主的场景下做性能测试，目前社区版本的多mds及多rgw还不够稳定需要持续进行优化；
后续如果业务要求带宽不满足可以通过增加osd节点网络带宽来提升性能；
如果业务要求IOPS不满足可以通过增加节点或提高节点上cpu性能来提升性能；