分类 Ceph 下的文章

今天ceph db出现溢出情况,记录一下解决方式。

[root@ceph-node-1 ceph-admin-node]#  ceph health detail
 HEALTH_WARN 6 OSD(s) experiencing BlueFS spillover
[WRN] BLUEFS_SPILLOVER: 6 OSD(s) experiencing BlueFS spillover
     osd.4 spilled over 17 MiB metadata from 'db' device (3.6 GiB used of 35 GiB) to slow device
     osd.5 spilled over 47 MiB metadata from 'db' device (3.2 GiB used of 35 GiB) to slow device
     osd.6 spilled over 125 MiB metadata from 'db' device (3.1 GiB used of 35 GiB) to slow device
     osd.12 spilled over 4.1 MiB metadata from 'db' device (3.9 GiB used of 35 GiB) to slow device
     osd.13 spilled over 21 MiB metadata from 'db' device (3.8 GiB used of 35 GiB) to slow device
     osd.14 spilled over 22 MiB metadata from 'db' device (3.8 GiB used of 35 GiB) to slow device

- 阅读剩余部分 -

查看新插入的HDD Slot Number编号:

/opt/MegaRAID/MegaCli/MegaCli64 -PDList -aALL -NoLog|egrep "Enclosure Device ID|Slot Number|Device Id|Firmware state"

确认是3以后创建RAID0:

/opt/MegaRAID/MegaCli/MegaCli64 -CfgLdAdd -r0[32:3] WB Direct -a0

- 阅读剩余部分 -

刚把ceph osd重建,为osd WAL/DB分配ssd专门的分区,同时也应用了bcache。想测试下不同bcache缓存模式下对性能的影响情况。

4个节点,节点配置:E5-2650/ 32GB内存 / 4*4TB ST4000NM0035 128MB缓存 + 三星zet983 480GB + 三星pro 500GB系统盘;zet983为每个hdd分配35GB DB分区、4GB WAL分区、50GB BCACHE分区。

- 阅读剩余部分 -

一般情况下可以操作以下3个参数实现速度控制,但是要留意,速度越快对集群性能的影响越大;可以动态的调整参数值,观察集群性能情况,找到合适自己的值,即不会对client请求造成过大影响的同时保障最优的recovery速度。

osd max backfills:这是允许进出 OSD 的最大回填操作数。数字越大,恢复越快,这可能会影响整个集群性能,直到恢复完成。
osd recovery max active:这是活动恢复请求的最大数量。数字越大,恢复越快,这可能会影响整个集群性能,直到恢复完成。
osd recovery op priority:这是为恢复操作设置的优先级。数字越小,恢复优先级越高。较高的恢复优先级可能会导致性能下降,直到恢复完成。



- 阅读剩余部分 -

我原来CEPH集群的OSD是默认方式创建的,即“ceph-deploy osd create ceph-node-1 --data /dev/bcache0”,因为性能遇到瓶颈,为了充分榨干nvme aic ssd,决定重建osd把WAL/DB分区放到nvme aic ssd上。目前社区和官方说只有重建方式,ceph允许同时存在2种不同的osd,所以可以平滑的过度。

我有4个节点,所以我每次重建4个osd,重建osd数量应保持在总数20%左右,不应一次性操作太多。

- 阅读剩余部分 -

为了提高CEPH HDD的性能,我买了Samsung 983ZET用来做Bcache缓存盘。

4个CEPH节点,每个节点OSD配置:4x4TB HDD,Samsung 983ZET一拖四用作Bcache缓存盘。1500个左右VM,平时负荷差不多23MiB/s wr | 1.5k op/s上下wr,rbd上的VM 60以上线程并发写入时经常有500ms以上的io延迟,偶尔延迟达到1000ms以上,如果更高并发写入时有时候甚至超过10000ms延迟,使用影响很大,但是并发读的却非常低的延迟一般保持在0ms,偶尔上个几十ms。

- 阅读剩余部分 -

首先停止故障osd运行:

# ceph osd out osd.4
# systemctl stop ceph-osd@4.service

解除bcache绑定(停用前端缓存),假设故障osd是建立在bcache1上,缓存盘的cset-uuid为805bc5f1-36e9-4685-a86a-3ea8c03f1172,我osd只是偶尔出现错误即将故障,而不是不能识盘,所以正常解除绑定清理脏数据:

# echo 805bc5f1-36e9-4685-a86a-3ea8c03f1172  > /sys/block/bcache1/bcache/detach

- 阅读剩余部分 -

下午收到故障警报,有个ceph节点osd故障。故障osd建立在节点bcache2分区上,但是这分区不见了,bcache2是一个RAID0的前端缓存分区。

通过MegaRAID检查RAID硬盘状态,发现有个RAID0下的硬盘变成外来设备了:

/opt/MegaRAID/MegaCli/MegaCli64 -PDList -aALL -NoLog|grep "Firmware state"

Firmware state: Unconfigured(good), Spun Up

也就是没有RAID信息列阵不识别这个盘了,也许是高负荷下掉盘又恢复后无法识别了?但起码盘还能识到,也就是说可能盘还没坏,可以尝试RAID导入一下外来配置:

- 阅读剩余部分 -

错误类似:26 slow ops, oldest one blocked for 48 sec, daemons [osd.15,osd.17,osd.18,osd.5,osd.6,osd.7] have slow ops.

如果只是集群中极少部分的OSD出现该问题,可以通过:

systemctl status ceph-osd@{num}

查看OSD日志找到问题并处理,常见的有磁盘故障等,根据错误网络搜索很多解决方案。


如果是集群中所有osd,或者过半数的osd出现这个问题呢?检查了磁盘、网络、mon都正常。其实还有一种可能,想一下是否近期升级过ceph,有升级不完整osd版本问题造成。

- 阅读剩余部分 -

自Nautilus版本开始Ceph支持自动调整PG merging,减少了每次加osd时候自己计算、修改的麻烦。

但其实自己计算也是很简单的,一个原则就是每个OSD大约能够分配到100pg就是合理的范围,计算公式:

(OSD数量100)/副本数量,如果有多个pool,还需要再除以pool数量,结果取接近计算值的2次幂。比如16个OSD / 3副本/ 1个pool,(16100)/3 / 1= 533.33,近2次幂的就是512了。

- 阅读剩余部分 -