处理ceph incompelete的经验


fix.png-40kB

前言

最近已经见到几个环境出现过incompelete了,这个在很久以前Jewel正在合入mark-complete工具的时候就有做过类似的处理,但是随着处理的环境越来越多,这个地方还是有些需要注意的,本篇是写一些需要注意的点

一般来说是环境有多个机器同时坏盘或者掉电,或者掉主机引起的

处理流程

拿到环境第一时间是对环境标记noout,这个操作是为了防止集群的环境反复震荡,标记noout没有osd标记为out的情况下,只是pg状态变化,实际数据并不进行迁移

把能够启动的osd都启动起来,直到没有能启动的osd了,如果有能力处理的话,尽量把osd拉起来,如果是硬盘损坏掉了,确定无法修复了,那么就当这个osd无法救回来了,这个步骤里面是要尽最大努力把osd拉起来

这里面还有一部分情况是osd启动不起来,但是数据目录是可以访问的,这个地方就把这种盘先保留好,一定不要推掉了,很多运维上去看盘坏了就重新创建osd,这种推掉osd的操作建议只在active+clean的时候才做,否则的话,pg状态不对,又把osd推掉了,数据有比较大的概率丢失

在以上操作做完以后,开始处理异常的pg,处理的时候,首先把异常的pg的info全部倒好备份一下,还把pg分布保存下

ceph pg 1.4 query > 1.4query
ceph pg dump|grep incom > pgincom.info

全部保留一份,通过这个信息能够分析出数据的完整性和数据在哪里,这个一定要保留好原始版本,这个是有可能在后面做一些操作后就变更了,造成你不知道去哪里找数据

一部分情况下,根据query的信息提示,会告诉你 lost掉某个盘,可能让它恢复,这个操作的时候也是需要检查下,这个pg的数据是不是在当前环境下面有地方有完整的数据,确定有的话再根据提示进行lost的操作,如果还不放心,或者更稳妥的话,这个时候就需要备份pg数据了,这里就有个问题了,在做系统规划的时候,系统盘要尽量大点,这个时候就可以用来保存pg导出的数据了,如果是filestore,容量不够还可以拿osd的目录做临时存储,如果是bluestore,就只能拿本地盘做临时存储了

做完上面的标记和备份的操作后,有一部分的pg可能恢复正常了,然后还有一部分恢复不了正常,这个时候就需要根据上面保存好的query的信息里面拿到pg的数据在哪个osd上面,注意这个时候当前的query是可能查不到数据在哪里的,这个时候会出现提示数据在osd.1,osd.2,osd.3实际数据在osd.8的情况,并且可能完全没地方知道是在osd.8的,这个信息是存储在最开始版本的query里面的,所以在处理前,一定备份好信息,备份好数据

这个时候就开始把pg的数据导入到主osd,导入以后就可以标记mark-complete了,然后拉起osd,然后看下处理的这个pg的状态

总结

在处理故障过程中,首先要保证能把能够拉起来的osd尽量全部拉起来,这个操作做好了可以省掉很多工作,pg是交叉映射的,有的时候正好交叉的osd全down了,所以能拉起来一个,这个pg也是可以状态恢复的

在所有操作前都是要进行数据备份的,这样即使出了问题,数据在都可以导入,导出的数据是需要检查下对象数目的,这个在导出前可以用ceph-object-tool做list操作检查pg对象的个数是否跟pg dump里面的一致的,通过大小也可以大致判断,这个在L版本的ceph做rm pg操作的时候,是有一个export-remove的命令的,这个把rm变成了mv操作,安全性比以前要好很多,防止手抖删错了,可以再导入

总之在数据处理过程中要小心,操作前备份好,操作过程每一步进行命令反馈确认,也就是你执行了命令应该是什么结果,这个要提前有分析,一旦产生偏差的时候,就要去分析了

本篇是操作上的建议,并没有具体命令,这个需要自己在实际操作过程中体会了,当然生产环境没那么多练手的机会,那么就尝试下对测试环境多进行破坏后进行恢复了,尽量不要直接推掉测试环境,每一次的问题处理都是为生产的处理做好储备工作

变更记录

Why Who When
创建 武汉-运维-磨渣 2018-12-19