ceph bluestore的db分区应该预留多大的空间

前言

关于bluestore的db应该预留多少空间，网上有很多资料

如果采用默认的

write_buffer_size=268435456

大小的话

那么几个rocksdb的数据等级是

L0: in memory
L1: 256MB
L2: 2.56 GB
L3: 25.6 GB
L4: 256 GB

设置L4那么大的ssd可以给一个osd使用有点不划算，那么空间一般计算就是L1+L2+L3将近30GB

这个可以参考下面的文章

https://blog.csdn.net/NewTyun/article/details/103379694

关于block.db大小调整,只需为所有Bluestore OSD保留30 GB

那么这个大小对不对，如果你直接参考30GB这个，并且按照常规的去分区来说，就会带来问题了，我们看下具体什么问题

实际测试验证

parted -s /dev/sdb mkpart primaru 1 31G

上面的命令已经放大了1GB了，但是实际上还是不行

[root@lab102 ~]# ceph daemon osd.0 perf dump|grep bluefs -A 10
    "bluefs": {
        "gift_bytes": 0,
        "reclaim_bytes": 0,
        "db_total_bytes": 30999044096,
        "db_used_bytes": 3258966016,
        "wal_total_bytes": 1999630336,
        "wal_used_bytes": 501215232,
        "slow_total_bytes": 160000114688,
        "slow_used_bytes": 7837319168,
        "num_files": 194,
        "log_bytes": 10485760,

上面是我测试环境记录的值，db只使用了3.2G实际上已经开始使用slow 了,所以这个大小实际上不满足的我的预设的，这个跟parted命令分区的GB转换也存在的一定的关系

看下parted的问题

[root@lab102 ~]# parted -s  /dev/sdf mkpart primary 1 1GB
[root@lab102 ~]# parted -s  /dev/sdf print
Model: Intel RMS25CB080 (scsi)
Disk /dev/sdf: 4000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 
Number  Start   End     Size   File system  Name     Flags
 1      1049kB  1000MB  999MB               primary

可以看到上面创建1GB的时候实际上只创建了999MB，加上我指定的从1MB开始，实际上这个地方设置是按1000进制处理容量的，而对容量的需求的是真正的1024的去算的，这个地方就存在误差了

那么我们简单点处理，就是直接放大到35GB即可

parted -s  /dev/sdf mkpart primary 1 35GB

按这个容量设置的，能够保证上面的L3没有先满的时候不会提前溢出了

红帽的官方的建议是留1T 40GB左右，而suse是建议db大小为64GB

https://documentation.suse.com/zh-tw/ses/6/single-html/ses-deployment/index.html#:~:text=如需BlueStore 的詳細,使用單獨的分割區。

https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/4/html/administration_guide/osd-bluestore

如果没有调整write_buffer_size的情况下，建议是35GB，40GB或者64GB，这个都存在一些放大设置，如果磁盘空间足够的情况下，多分一点也没什么关系的，尽量避免转换不正确带来的未知的降速

WAL大小，suse建议是4GB的

测试模型构建

准备一个4TB的sata盘，准备一个db分区，准备一个wal分区(测试环境为2GB)

db分区设置为你需要的大小，上面的环境当中，我测试了db 30GB和35GB两组大小的情况

设置35GB写入600万文件的时候osd的db情况如下：

ceph daemon osd.0 perf dump|grep bluefs -A 10
    "bluefs": {
        "gift_bytes": 0,
        "reclaim_bytes": 0,
        "db_total_bytes": 34999361536,
        "db_used_bytes": 10392428544,
        "wal_total_bytes": 1999630336,
        "wal_used_bytes": 492826624,
        "slow_total_bytes": 160000114688,
        "slow_used_bytes": 0,
        "num_files": 177,
        "log_bytes": 3944448,

创建osd的命令

ceph-deploy osd create --data /dev/sdc1 --block-db /dev/sdb1  --block-wal /dev/sdb2 lab102

创建一个rgw网关

然后用cosbench往网关打数据

200个worker，64KB的文件，写入600万文件

测试一轮的时间大概为2小时就可以复现上面的情况，测试过程还带出了另外的一个问题

rgw_dynamic_resharding = true

这个动态分片过程中会有一定的概率阻塞住请求的，通过cosbench里面的压测图形也可以看到分片后的性能比没分片是好很多的，所以如果抢时间的话

最好是关闭动态分片，设置好需要的分片数目

测试完需要改db的时候，直接删存储池，然后重新创建即可，推掉的操作也很快的

总结

网上的文章都是用来参考的，实际是一定需要去复测验证的，一般分享的文章也不会细化到一个parted的命令也记录，只会从原理上面出发去分析，并且环境调整了什么参数，都是不同的结果的，比如上面的

write_buffer_size如果调整到512MB，那么预留的空间差不多需要翻一倍的

所以参数的调整，一定要实测