帮一位读者朋友解决集群问题的过程

写在前面

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

最近好几位读者朋友私信催更，啊，最近半年的更新速度确实是肉眼可见的减慢了。后续争取加大更新力度

本次要分享的问题，是一位读者朋友环境问题的解决，其中涉及到一些新手用户的常见问题，征得其本人同意后，将过程发出来，供大家参考

开始

刚开始，目标集群进行了扩容，原本只有3个osd，两副本模式，扩容后变成了5个，数据正常恢复，但是，osd上的pg数量相差比较大，所以读者朋友调整了weight来实现pg的重分布

建议1

• 扩容的时候，可以先将osd全部建好后(使用ceph-volume来创建，这样就不会自动加入到某个root)，一次性加入到集群的crush中的某个bucket，而不是逐个加入，逐个加入的问题是，每加入一次，就会引发一次震荡
• 不要修改weight或reweight来进行pg的均衡，而是使用balancer，weight通常用来表示osd的存储能力，它的数值1对应磁盘的1T空间，这个数值是多少其实并不是很重要，重要的是是否相同，rewegiht和weight都是crush算法的输入，不适合人为修改

接下来，这个集群出问题了，理论上，加入osd后，即使修改weight值，也不会有什么问题，但是注意，上图显示，osd.1的weight被改得非常小，这么大的weight差距使得pg的分布再次变得更加不均衡，更要命的是，集群进行了如下操作

1
2
3
4

在上一次还没完全恢复的时候， 又新增osd 且修改pg num
然后 osd 反复down up
又把那个osd 移除了
就这样了

这。。。。。。新手朋友们常常会犯的一个错误，就是集群发生变化时，频繁地去操作，这样会让集群的情况变得更糟糕

调大恢复速度并等待一段时间后(期间不操作，就等)，集群最终变成了这样

看起来，还不算糟糕，比较难搞的是stale+down和incomplete状态的pg

针对incomplete状态的pg，读者朋友使用了ceph-objectstore-tool来进行pg的强制complete，em….这并不是很好的操作但也不能算错误，毕竟确实能处理这个问题，pg本身卡在了incomplete，说明某个pg副本确实是还有问题的

针对stale+down的pg，这个pg显示它的last acting是osd.8，但是osd.8已经在刚才被删掉了，这就难了，现在集群完全没有这个pg的信息了，可是，使用ceph pg map这个pg，显示这个pg应该在osd.5和osd.1上面

也就是说，目前的状态是，stale+down的pg，原本在osd.8上，osd.8被删除后，数据没有及时迁移到新的osd.1和osd.5上，这导致这个pg数据丢失

幸亏删除osd的时候，没有进行lvm的删除或者格式化等破坏性的操作，而仅仅是osd从集群rm掉，针对这种情况，我当时给出的建议是

1
2

现在思路有两个，一个是按照刚才那个链接，把osd.8重新加回去，但是不一定有用，因为osd.8上的其他数据已经完成了均衡，重新加回去不知道会有什么问题，我没有试过
另外一个思路是，将pg 9.6从osd.8里导出，然后导入osd.5和osd.1，起来后，集群理论上会根据新的pgmap让集群恢复正常

于是，读者朋友采取了导出再导入的方式

1

ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-8/ --type bluestore --pgid 9.6 --op export --file 9.6data

然后，将这个导出的pg数据再导入到osd.1和osd.5

1

ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-5/ --type bluestore --pgid 9.6 --op import --file 9.6data

至此，集群恢复正常的HEALTH_OK状态

建议2

• 如果osd磁盘不是损坏的话，不建议将其移出集群，更不建议对其进行删除lvm或者格式化之类的破坏性操作，留一条数据恢复的后路
• 不要因为集群状态变化而频繁操作，尤其是进行pg级别的操作，除非非常清楚它的原理

后续

集群正常后，后续的建议是，将weight改回原本的值，然后使用balancer进行pg均衡，因为集群本身osd数量太少，会出现osd的up/down震荡，可能需要进行set noout之类的操作，并在集群完全恢复后进行扩容

对于此前提出的第一个思路，osd被踢出集群后，集群数据完成均衡，然后再将这个osd加回去，注意，这个osd加回去并不是重建回去，而是直接手工的将osd id创建出来，然后手工添加key，再将osd起起来，关于这个操作，我特意在测试集群试了一下，没有问题，osd起来后，会根据最新的osdmap和pgmap进行映射，原本在这个osd上的pg实际上会进行一次扫描校验，最终会按照最新的分布来，没有出现奇怪的现象

总结

这还是个生产集群我的天。。。

总的来说，这次的集群恢复不算复杂，就是需要对pg了解较深入，另外，建议集群状态变化不要着急操作，要淡定，想好对策再下手，尤其是破坏性操作，应慎之又慎

赏

谢谢你请我吃糖果

支付宝

微信