前言
随着时间的流逝，ceph集群中的数据越来越多，OSD的使用率会越来也高。我在维护客户集群时遇到过一些危急的case。比如集群中某个OSD写满了。 如何处理这种情况。
分析
mon会监控ceph集群中OSD空间使用情况，首先时有两个参数
"mon_osd_full_ratio": "0.95",
"mon_osd_nearfull_ratio": "0.85",
默认情况下，当OSD空间使用超过85%，ceph health就会有⚠️，说该OSD near full，这种情况下只是一个提醒，如果集群中很多OSD都near full，那么最合理的措施当然时添加OSD或者添加存储节点，即我们通常说的扩容。
有一个笑话时，悬崖边上有个warning指示牌，只有程序员掉下去了，就是说有些人总是忽视这些⚠️，OSD满了85%也并不处理，下一个关隘就到了OSD full。
当OSD full了，集群就真的出问题了。因为数据写入到那个OSD，这个是由crushmap决定了，而OSD 满了，又不能写，其实集群就是出于不能工作的状态。这种情况怎么办？
处理方法1
前辈在这片博文Ceph集群磁盘没有剩余空间的解决方法提到了步骤，简单地讲，就是修改/etc/ceph/ceph.conf
[global]
mon osd full ratio = .98
mon osd nearfull ratio = .80
这种方法我试过，但是这种方法有个缺点，就是不及时。你重启OSD（我忘记我当时是否重启mon了），不停刷新ceph health，full的告警一致都在。 我想补充的方法是，即刻生效的方法。表面看，这没啥，当客户集群写不了数据，你的电话被各路神仙打爆的时候，就知道这种方法的可贵之处了。
ceph pg set_full_ratio 0.98
ceph pg set_nearfull_ratio 0.80
处理方法2
上面这种方法能解燃眉之急，解了燃眉之急之后，就可以看下还有什么能做的。毫无疑问，扩容是必须的，但是扩容本质不仅仅是个技术问题，牵扯商务一大堆的事，很可能来不及。作为技术人员，不能只有眼前路，没有身后身。
很有可能OSD空间使用率并不均衡，这并不是不可能，我就曾经见过很多集群，OSD空间使用率差距很大，比如有的已经97%，而有的只有50%多，这种情况下，就可以调整weight。
将OSD full的weight调低，同时将空间使用率最低的OSD的weight调高。但是这种方法也有个坑需要注意。当存在OSD full的时候，想必其他OSD磁盘使用率低于80%的可能性也不大（如果发生，说明前期工作没有做好），很可能PG迁移的目的地，即backfill的目标OSD也比较满，导致进入backfill_toofull状态。这种情况很有意思，有点地方保护注意的色彩，就是说OSD A因为十万火急了，调整weight之后，需要向OSD B迁移PG，即迁移很多数据到B上，但是B也很惨，比如B也已经使用了85%了，OSD B就不乐意了，说我的空间使用率也太高了，我拒不接受往我这里迁移数据。
这个拒绝接受backfill的权重是：
"osd_backfill_full_ratio": "0.85",
一般来讲，这个参数是需要调整的，如果不调整，很可能数据迁移工作就不能顺利进行：
ceph tell osd.\* injectargs "--osd_backfill_full_ratio 0.92"
注意，表面看发起了reweight，PG开始搬迁就万事大吉，其实不然。注意，数据从full的OSD往比较清闲的OSD搬移，这是一个过程，而且并不是搬移一个object， full的OSD就删除一个object，并非如此，搬移工作是需要完成之后，full OSD对应PG的内容才会删除。
我曾经遇到过一个PG有800G的数据，按照搬移速度（不能任意调整搬移速度，否则可能影响线上业务），可能需要20天才能搬完，full的OSD该PG对应的空间才能释放，但是，线上业务仍然不断往OSD里面写，统计显示8天之后，OSD就会被彻底写满，这种情况怎么处理。
这种情况是不是更加危急？加快搬迁速度，就可能影响线上业务，客户可能会抱怨，投诉，如果不加快搬迁，OSD彻底满了，搬迁也没做完，PG的空间也不会释放，是不是急死人。
处理方法太复杂，今天就到此为止了。
其他
当然了，未雨绸缪，胜过无数tricky的小伎俩，我们应该及时扩容，不应该将自己陷入如此绝境。