ceph运维大宝剑第一期，后续还会针对运维问题更新，本次是网友的环境问题

写在前面

松鼠哥的ceph专业课程上线啦！
面向新手同学，从0实战，全面入门ceph安装部署与运维，有需要的同学赶紧扫码订购吧：

近日有网友反映，他们公司生产环境ceph集群出现full的osd，导致集群不可访问，在加一个盘后数据未进行迁移，对full的osd做了reweight也不进行数据迁移，业务一度中断，情况比较紧急，笔者以非常有限的水平帮忙处理了一下，在征得本人同意的情况下，写下处理过程，希望可以帮到其他人

环境

tv连上环境后，初步确认了一下环境

• 1、ceph 12.2.5
• 2、两副本，19个osd
• 3、只使用了对象存储
• 4、有一个osd为full状态

等等，环境好像有什么不对！？？

• 1、两副本，四个节点，故障域为host，crushmap没有定制
• 2、12.2.5版本，原本默认是bluestore，一看环境日志，居然是filestore
• 3、所有存储池没有划分开，全部放在所有的osd上
• 4、一个ssd都没有，全机械盘，而且有些盘性能堪忧
• 5、居然有4个mon，4个mgr

额，说实话这个环境真的复杂，不是真的拿到手，不敢相信。集群现在是osd full状态导致集群不可读写

开始处理

osd full的情况，一般的思路有两步，首先通过rewegiht的方式，削减full状态osd的pg，使得部分数据迁出，该osd可以暂时不达到full状态，然后加盘，扩大集群容量，分担其他osd的数据

首先是设置集群标记

1
2
3

ceph osd set noout
ceph osd set noscrub
ceph osd set nodeep-scrub

避免恢复过程中其他任务引发其他问题

并通过网上盛传的tell的方式设置osd的full相关参数

1

ceph tell osd.4 injectargs '--mon_osd_full_ratio 0.95 --mon_osd_nearfull_ratio 0.95 --mon_osd_backfillfull_ratio 0.95'

然后，查看osd的参数情况，确认tell的参数没问题

但是，full状态的osd依旧full，集群没有任何改观，于是给mon也配置一下这个参数，在ceph.conf文件的global字段直接设置上面的三个参数，并逐个重启mon(实际上干掉了一个mon,集群工作mon变成三个)，使用ceph daemon xxx config show确认参数配置成功后，集群依旧没有明显的变化，依然是一个osd full，集群仅有少量的recovery，在新加盘之后，数据应该会进行迁移的，没有发生迁移，是什么地方卡住了吗？

通过查看ceph health detail发现，有不少pg处于toofull状态，先想办法让这部分pg活过来

为了避免pg开始迁移后造成较大的压力导致osd挂掉，先在配置文件global中写入如下配置

1
2
3
4

osd_op_thread_suicide_timeout = 900
osd_op_thread_timeout = 900
osd_recovery_thread_suicide_timeout = 900
osd_heartbeat_grace = 900

然后，重启了osd.10，重启完成后，并没有太大的变化，于是重启了osd.4，集群开始比较明显的recovery，应该是部分osd.4的pg卡住了

于是，调节了下列参数，让recovery更快一些

1
2
3
4

osd_recovery_max_single_start 32
osd_recovery_sleep_hdd 0 
osd_recovery_max_active 32
osd_max_backfills 32

此时开始，集群飞快地进行recovery

小总结

在笔者的环境，前期设计、调优、测试都做过很长时间的试验，线上环境在设计初期就进行了充分的考虑，所以说实话没有太多处理full的经验，在帮助网友的同时也学到了不少东西，在此表示感谢

首先，full ratio不生效的问题，虽然在osd和mon上都检查配置成功了，但是ceph osd dump的时候发现三个参数并没有修改成功

ceph -s发现集群还是full，原因是在之前的版本中有命令ceph pg set_full_ratio xx进行配置，在12.x版本以后，命令变成了ceph osd set-full-ratio xx，即从此前的pg配置改为现在的osd配置(如果因为pg的toofull引发数据问题，命令用原来的很容易理解，不知道为何要修改为osd级别的配置)，配置下去后直接生效无需重启任何进程，集群状态可以按照新的配置生效，不再显示为full

这也显示了ceph默认的0.85和0.90的合理之处，有机会让我们进行手动调整，拯救集群

其次，着手处理这个full问题时，应该立即tell那4个timeout的参数并将配置写入到ceph.conf，时间可长度可以设置得更长，尤其是磁盘性能比较差的集群，随便一个compaction就要几分钟，osd分分钟会挂，引发二次伤害

最后，二副本坑到爆，三副本稳如狗，谁用谁知道

第二天

是的，过了一晚，小伙子反馈，集群还是有问题，最突出的问题是，osd老是挂，并且有一个osd居然达到了0.95，集群再次不可用，我去。。。

看起来，又是有osd的pg toofull，看了下，是另外一个osd达到了full，又立即将该osd的reweight调整，并将backfill full和recovery full再调高一点

这次是osd.6，嗯，调整后，集群数据开始快速恢复，但是期间发生多次osd.2挂掉的情况，这个osd并没有用得很满，timeout也调整得比较高，怎么老是挂呢，检查一下

差点吓被到，读写都很低的情况下磁盘写入的await高达8170ms，持续观察一段时间，发现这个盘读写的await都非常高，这样看来这个盘就算没有坏道，也是一个性能非常差的盘， 所以它拖累了整个集群！

在征求小伙子本人同意后，笔者先使用ceph osd reweight 2 0的方式将该osd的reweight降为0，此osd立即out出集群，然后将该osd停止，触发了集群的数据迁移，其实该osd被踢出后，集群恢复速度飙升，并且没有再发生osd挂掉的情况，全部数据迁移完成后，集群恢复正常

后续措施

对于已经上线并存储了大量数据的集群，未在开始就进行pg均衡的话，此时进行了初步的故障处理后，建议的后续处理手段是，在业务低峰期，手动将存放数据pg较少的osd reweight为较低的值(如果此时是1的话)，例如为0.8，因为如果不降低reweight的话，就没法提高了，默认为1，然后手动将比较满的osd手动降低reweight值，再根据实际情况调整其他reweight值，总之，目标就是为了让所有osd存放的数据都差不多

这种做法会频繁触发数据迁移，并且还有卡住pg的风险，所以一定要小心地在线上环境上操作，新手同学不建议玩

当然，这也只是亡羊补牢，只能让集群再撑一阵，根本来说，还是要在集群一开始就调整好

总结

纸上得来终觉浅，绝知此事要躬行，接手的这个环境算是比较复杂的一个，问题也层出不穷，学习到了很多的东西，入行ceph这么久以来，笔者坚定地相信一个道理：大部分的ceph问题都能在集群设计之初就杜绝掉，如果在设计之初不考虑周全，后续出的问题会千奇百怪，所以基于本次故障处理，总结一下对象存储集群设计避坑思路，希望可以帮助到各位读者

• 1、非要用二副本的话，一定要定制crushmap，自己设计数据的分布
• 2、如果不是全新的HDD，一定要测试过所有机械磁盘，性能合格才上线，ceph容易受到木桶效应的影响
• 3、不必要太多的mgr，一般两个就够了，分布在不同的故障域节点即可，奇数个mon，别问为啥，也别强行执行领导要求的高可用，这个东西真的不是部署越多越高可用
• 4、12.x及更新版本还是用bluestore吧，filestore真的没那么好用
• 5、集群上线前做好性能评估，有条件要做全面的优化，不然苦的还是自己
• 6、存储池划分，data存储池放在HDD，其他，尤其是index强烈推荐放在ssd osd上
• 7、存储池在集群建好的时候，强烈推荐首先进行pg的均衡，否则会出现某些osd full，某些osd才用了0.60，此时集群总共才用了60%，领导不会同意加盘的-.-(买盘不用钱啊，集群不是才用了一半吗？)
• 8、wal和db真的要放ssd，宁愿少两个HDD也要加ssd
• 9、实在不会设计、调优，可以阅读本博客其他文章，也欢迎来邮件或者QQ相互讨论、学习

赏

谢谢你请我吃糖果

支付宝

微信