遇到的问题解决及几点建议

By | 2021年8月26日
目录
[隐藏]

写在前面

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

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

开始

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

osdqingkuang

建议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 移除了
就这样了

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

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

看起来,还不算糟糕,比较难搞的是stale+downincomplete状态的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了解较深入,另外,建议集群状态变化不要着急操作,要淡定,想好对策再下手,尤其是破坏性操作,应慎之又慎

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注