新闻

NEWS

VC君讲技术03 | 常见两种pg状态问题的处理方法

发布时间:2020-06-03 发布者:瑞驰信息技术

《VC君讲技术》

技术分享第3期

作者:带鱼、乐枫

 

前言:

关于集群异常恢复过程中,经常遇到pg状态问题,导致集群恢复阻塞,无法正常读写操作。

常见的两种pg问题,incomplete和inconsistent我们应该如何进行处理呢? 

首先了解这两种pg状态具体的含义:

incomplete:不完整状态。peering过程中,由于以下两种情况导致peering无法正常完成 

(1)无法选取出权威日志 

(2)通过choose_acting选取的Acting Set后续不足以完成数据修复 

inconsistent:不一致状态。集群清理和深度清理后检测到PG中的对象在副本存在不一 致,例如对象的文件大小不一致或Recovery结束后一个对象的副本丢失。


下面我们根据实际的问题来分析和处理上述两种异常问题


incomplete问题

ceph v0.94,两副本冗余集群;

出现一个osd磁盘故障导致无法启动,在此种情况下,节点又发生宕机,过程中客户端持续写入;重启恢复后集群状态阻塞,无法恢复。

第一步,首先观察下,目前的pg处于一个什么样的状态,对于集群的故障有个初步的判断


可以明显看到,集群已经没有提示进行recovery,未进行迁移恢复。我们来看看pg阻塞的详细情况:ceph health detail命令可以查看(输出日志信息过长,我们截取部分)


观察到pg有两个主要问题:

(1)18个pg处于remapped+degraded+recovery_wait+undersized,pg卡在remapped,导致recovery_wait恢复等待。

( 2 )16个pg处于incomplete状态

此次我们主要针对incomplete和inconsistent问题,对于remapped卡住的问题,我们后续再进行分析。对于incomlete的pg处理,我们列出这些pg $ ceph heath detail | grep incopmlete


随便选取一个pg 1.16e分析,查看其query信息:ceph pg 1.16e query | less


可以看出由于osd down导致无法探测全部副本,而剩余副本无法选取权威日志或恢复数据。

在损坏的磁盘pg数据还可以导出的情况下

我们可以对比osd.3上面的对象和现存副本的对象数据,如果osd.3上面有较完整的数据,可以导出数据再导入主本osd。

例如,我们简单查看osd.3上面该pg的数据情况

然后查看现存主osd.4上该pg数据量,以及其他probe探测过的osd副本

可以看出osd.4基本是空的pg,然后我们可以将osd.3上pg数据导出,再导入到osd.4

导入pg重启osd后,pg状态一般就可以正常了。

如果pg数据导入重启仍不能消除incomplete,就需要使用ceph-objectstore-tool工具强制标记pg状态complete。

修复原理:将所有导致pg的past_intervals全部清空重新写入pg info持久化到硬盘(就是这些past_intervals中包含故障磁盘的osd,导致pg无法通过peering的GetLog阶段)。

在损坏的磁盘pg数据无法导出的情况下

我们应该尽可能的恢复数据。例如下面已经无法导出pg数据的情况。另外一个集群环境,出现坏盘情况且pg数据无法导出。


尝试查看其他osd上是否存在数据,14/16/17都没有对应pg数据,查看副本osd.23发现存在数据,且和osd.3上数据大致一致,数据量相当。

根据阻塞op的osd,以及查看的down+incomplete pg所在osd主本,设置该osd参数osd_find_best_info_ignore_history_les = true,重启osd触发peering,重新选取权威日志,选择best,忽略history.last_epoch,选择最优的。

修复完成后,恢复参数为false。


inconsistent问题


对于pg出现的inconsistent问题,主要原因是因为底层进行对象scrub或者deep scrub时, 出现主副本的数据对象不一致情况。

集群状态error

尝试repair修复inconsistent:

执行repair后没有修复, 执行repair时,开启ceph -w,查看数据错误的对象

可以找到数据不一致的数据对象为下面两个:

repair0.44  0/45043444/rbd_data.195a70238e1f29.000000000000a4bb/65  is  an unexpected clone

repair0.44  0/a7b6e444/rbd_data.195a70238e1f29.0000000000012173/65  is  an unexpected clone

查看两个对象主副本的数据轻量

发现主副本的对应克隆对象md5值计算完全一致。rsync同步副本对象到主本,repair后仍然没有恢复。

一般碰到的主副本数据不一致问题,进行对象数据同步后repair就可以修复了。 针对于这个pg出现的对象意外克隆问题,需要根据提示"is an unexpected clone",我们需要进一步处理了。 

首先,remove-clone-metadata

提示clone 41不存在,这个地方的id应该是16机制0x65=101,重新删除clond-metadata仍然提示no present;repair修复不能消除,备份数据后,考虑删除对象 

根据image的指纹查看对应的image信息:

匹配到对应的image名称vm-132-disk-4,修复incomplete问题后,虚拟机可以正常访问,备份该虚拟机的300G数据盘数据。 

删除对应的快照

删除后repair对应的pg,不能修复;ceph-objectstore-tool工具查看对象信息:看到之前删除的快照,仍存在一个快照对象

删除主副本对象的快照对象

删除快照对象需要注意对象信息格式要是json格式,且需要用 " 单引号包含 ,删除后启动osd,执行repair仍然没有修复。怀疑工具删除了对象,实际物理数据是否被完全删除?

再检查主副本osd中对应的快照对象数据是否删除,发现副本存在遗留对象数据未删除,主本存在空对象数据问题,并删除相关对象。

最后结论,scrub只针对底层的数据块进行校验,最终必须保证主副本中相关数据块一致,处理不了的情况,考虑删除主副本中对应的数据。

总结

解决incomplete问题:

主要思想是从其他完整副本osd上面导出pg或者从损坏磁盘osd上面导出,然后重新导入集群;如果没有完整副本,或者pg query详细提示blocke卡住在peering_blocked_by_history_les_bound,设置参数peering_blocked_by_history_les_bound=true,然后重启osd进行peering

解决inconsistent问题:

主要通过数据同步使主副本对象数据完全一致,碰到异常情况,比如数据显示一致的情况下仍报错,可尝试清理对象数据后repair修复。