基于PVE Ceph集群搭建（二）：Ceph存储池搭建与基本性能测试

MatthewLXJ

博客最新更新
基于PVE Ceph集群搭建（一）：集群40GbEx2聚合测试
基于PVE Ceph集群搭建（二）：Ceph存储池搭建与基本性能测试

接前篇“基于PVE Ceph集群搭建（一）：集群40GbEx2聚合测试”，搭建Ceph存储池以及性能基本的测试

Ceph集群搭建

集群包括七个节点，其中三个为纯存储节点，四个存储计算一体节点，均处于同一内网，根据“基于PVE Ceph集群搭建（一）：集群40GbEx2聚合测试”

中的测试节点间40GbEx2聚合后可实现50GbE互联。

软件部分

1. 软件版本
   
2. proxmox-ve: 7.3-1 (running kernel: 5.15.74-1-pve)
   
3. ceph：17.2.5-pve1 quincy (stable)
   
4. iperf：2.0.14a (2 October 2020) pthreads
   
5. fio：3.25

复制代码

节点配置


OSD分布与配置


测试系统Ceph共36个OSD

创建Ceph存储池
1.RBD

1. ceph osd pool create testbench 100 100   (创建测试池testbench)
   
2. ceph osd pool application enable testbench rbd   （分配application）
   
3. rbd create testbench/disk1 --size 1024000
   
4. rbd map testbench/disk1
   
5. mkfs.xfs /dev/rbd0
   
6. mount /dev/rbd0 /mnt/rbd
   
7. /mnt/rbd用于fio对rbd进行测试

复制代码

2.Cephfs

1. ceph fs new cephfs cephfs_data cephfs.metadata
   
2. mount -t ceph :/ /mnt/pve/cephfs -o name=admin,secret=
   
3. /mnt/pve/cephfs用于fio对cephfs进行测试

复制代码

3.NFS
Ceph推荐使用NFS-ganesha来提供NFS服务，基于PVE集群搭建的ceph不能直接提供NFS配置，因此暂时未进行测试，后续补上。
Ceph性能测试
本次性能测试从以下几项展开：
1. Ceph的rados bench测试write、read和seq；
2. fio测试runtime、bs、iodepth、numjobs和iodepth*numjobs的影响；
3. 针对Ceph，分别测试CephFS、RBD、NFS的性能；

1.Ceph的rados工具测试

1. rados bench -p testbench 30 write -b 4M -t 16 --no-cleanup | tee rados_write.log
   
2. rados bench -p testbench 30 rand -t 16 | tee rados_rand.log
   
3. rados bench -p testbench 30 seq -t 16 | tee rados_seq.log

复制代码

Ceph自带的rados工具针对4M进行测试。
2.fio测试
(I) rbd
fio_rbd.conf

1. [global]
   
2. ioengine=libaio      
   
3. direct=1            
   
4. size=5g              
   
5. lockmem=1G           
   
6. runtime=30           
   
7. group_reporting      
   
8. directory=/mnt/rbd   
   
9. numjobs=1
   
10. iodepth=1
    
11. [4k_randwrite]
    
12. stonewall
    
13. rw=randwrite
    
14. bs=4k
    
15. [4k_randread]
    
16. stonewall
    
17. rw=randread
    
18. bs=4k
    
19. [64k_write]
    
20. stonewall
    
21. rw=write
    
22. bs=64k
    
23. [64k_read]
    
24. stonewall
    
25. rw=read
    
26. bs=64k
    
27. [1M_write]
    
28. stonewall
    
29. rw=write
    
30. bs=1M
    
31. [1M_read]
    
32. stonewall
    
33. rw=read
    
34. bs=1M

复制代码

fio_rbd.sh

1. for iodepth in 1 2 4 8 16 32; do
   
2.     sed -i "/^iodepth/c iodepth=${iodepth}" fio_rbd.conf && fio fio_rbd.conf | tee rbd_i$(printf "%02d" ${iodepth}).log && sleep 20s
   
3. done

复制代码

(II) cephfs
fio_cephfs.conf

1. [global]
   
2. ioengine=libaio      
   
3. direct=1            
   
4. size=5g              
   
5. lockmem=1G           
   
6. runtime=30           
   
7. group_reporting      
   
8. directory=/mnt/pve/cephfs
   
9. numjobs=1
   
10. iodepth=1
    
11. [4k_randwrite]
    
12. stonewall
    
13. rw=randwrite
    
14. bs=4k
    
15. [4k_randread]
    
16. stonewall
    
17. rw=randread
    
18. bs=4k
    
19. [64k_write]
    
20. stonewall
    
21. rw=write
    
22. bs=64k
    
23. [64k_read]
    
24. stonewall
    
25. rw=read
    
26. bs=64k
    
27. [1M_write]
    
28. stonewall
    
29. rw=write
    
30. bs=1M
    
31. [1M_read]
    
32. stonewall
    
33. rw=read
    
34. bs=1M

复制代码

fio_cephfs.sh

1. for iodepth in 1 2 4 8 16 32; do
   
2.     sed -i "/^iodepth/c iodepth=${iodepth}" fio_cephfs.conf && fio fio_cephfs.conf | tee cephfs_i$(printf "%02d" ${iodepth}).log && sleep 20s
   
3. done

复制代码

测试结果
number job=1

number job=16

测试结论

• RBD、Cephfs总体性能是随iodepth、线程数（number job）提升的。
• 延迟（clat）随着number job与iodepth的乘积的增加而增加的，相对来说，number job对延迟的影响更大，更多的并行IO任务会显著提高IO延迟。
• Cephfs相对RBD来说4K随机写性能有显著提升。
  

参数配置建议
针对我当前Ceph的配置，36 OSD + 1% NVME共200T存储空间的情况下，结合测试结果，为了得到更好的性能，参数设置：

• 4K随机读写: iodepth设置为16或32及以上，并采用Cephfs的方式来存储；
• 1M顺序读写：iodepth设置为1，多线程能够尽可能发挥读写极限。
  

3. Cache Tier测试

Ceph官方文档对Cache Tier的解释:Cache Tier为Ceph客户端提供了更好的I/O性能，用于存储在支持存储层的数据子集。缓存分层包括创建一个相对快速的存储设备池（例如，固态驱动器）配置为缓存层，以及一个由擦除编码或相对较慢/便宜的设备组成的备份池，配置为经济的存储层。Ceph objecter处理放置对象的位置，分层代理决定何时将对象从缓存中冲到备份存储层。所以缓存层和后备存储层对Ceph客户端是完全透明的。
Ceph官方文档提到,值得注意的是：

• 缓存分层将降低大多数工作负载的性能。用户在使用这个功能之前应该非常谨慎。
  取决于工作负载。缓存是否能提高性能在很大程度上取决于工作负载。因为将对象移入或移出缓存是有成本的，所以只有当数据集的访问模式有很大的偏差，比如大部分的请求只触及少量的对象时，它才会有效。缓存池应该足够大，以便为你的工作负载捕获工作集，从而避免惊扰。
• 难以进行基准测试。大多数用户用来衡量性能的基准测试都会显示出高速缓存分层的糟糕性能，部分原因是其中很少有请求偏向于一小部分对象，高速缓存需要很长的时间来 "预热"，而且预热成本也很高。
• 通常情况下，速度较慢。对于不适合缓存分层的工作负载，性能通常比没有启用缓存分层的普通RADOS池要慢。
• librados对象枚举。librados级别的对象枚举API并不意味着在存在的情况下是连贯的。如果你的应用程序直接使用librados并依赖于对象枚举，缓存分层可能不会像预期的那样工作。(这对RGW、RBD或CephFS来说不是一个问题）。
• 复杂性。启用缓存分层意味着在RADOS集群中使用了很多额外的机器和复杂性。这增加了你在系统中遇到其他用户尚未遇到的错误的概率，并将你的部署置于更高的风险水平。
  

由于NVME基本被OSD的DB/WAL设备占用，后续继续增加SSD/NVME设备后对Cache Tier进行测试。
后续性能优化方向

• 当前测试系统下OSD节点与mon、mgr、mds均重叠，可能会影响性能，后续分离优化；
• 部分节点NVME盘体积与数量均太少，后续增加NVME，按照10% NVME配置DB/WAL将带来较大性能提升，同时一块NVME不能给过多OSD缓存；
• 当前测试下OSD临时数量为36，最终集群Ceph总OSD数量为87，裸机HDD总容量624T，NVME总数量20，裸机NVME容量63T。
  

下一篇将会更新“基于PVE CEPH集群搭建（三）：Cephfs、RBD、NFS存储池性能调优”

MatthewLXJ

Mufasa 发表于 2023-1-12 13:02
PVE安装ceph，直接跳过了前面那些工作，就到建立rbd或者cephfs这一步了？

或者说前面那些鼠标一按就搞定？ ...

pve安装ceph就是一键式的

MatthewLXJ

蓝色星芒 发表于 2023-1-12 14:19
50G的带宽，这要什么样的访问才可以，至少是大型4K 8K媒体工作室的访问带宽，但是看你的测试结果，在加速情 ...

网络带宽是完全没有占用多少的，不过后续会加更多的NVME来测试，跑30G左右应该没问题

MatthewLXJ

蓝色星芒 发表于 2023-1-12 14:44
全部换nvme的话，加上分布式的加成，7台设备，还真差不多可以。

pve的可玩性比esxi高。适合家用，esxi是 ...

我从6.x版本用起来的，一般情况下pve更新还是没什么问题的，而且7.x版本以后能明显感觉bug变少很多

MatthewLXJ

awpak78 发表于 2023-1-12 14:07
这个速度，太失望了……

确实太菜了，后面把OSD全加上去看看怎么样，每年再把NVME按照10%加上去应该能好不少

MatthewLXJ

QSG 发表于 2023-1-12 16:09
epyc拿来跑集中存储也差不多能跑到30G，分布式有啥好处呢

分布式保证的是高可用性

MatthewLXJ

nsc117 发表于 2023-1-12 16:39
同感，相同的硬件组ZFS，性能可起飞。
Ceph的优势在于分布式，但对硬件的要求，说是不高，实际上可是太高 ...

是的，就100 HDD+NVME缓存上ZFS估计能拉满，所以看下来ceph对高速硬盘容量要求很高

MatthewLXJ

IPP 发表于 2023-1-13 14:12
7节点这个性能 有点… 我司产品是基于gluster的，，ceph用来塞S3兼容存储

确实哈哈哈哈哈，距离我预期差太多了，不然之前我也不会一直折腾把网络提到40x2和100G，第三篇优化还有很多的路要走，不过没有部署到实际应用所以调整起来也很方便，年前年后再慢慢测试提升

MatthewLXJ

robt233 发表于 2023-1-14 22:55
而且像您这个结构可以考虑存储计算分离，集中式存储可能可以获得更高效率，而且闪存可以考虑集中存在一个服 ...

最近也在测试分离后效果，OSD都在全部重新分布测试性能，期待下，基本顺序读写接近5G，4K随机能有100K以上我就不折腾了

MatthewLXJ

zvcs 发表于 2025-2-19 16:06
看来下一篇“基于PVE CEPH集群搭建（三）：Cephfs、RBD、NFS存储池性能调优” 已经鸽了。。。 ...

已经寄了，趁早放弃，这东西没规模性能很烂，所以我放弃了