Ceph性能测试总结

发布时间 2023-04-25 10:41:57作者: XU-NING

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性能来提升性能;