Ceph 中的 PG 状态详解

Creating

Peering

Activating

Active

Backfilling

Backfill-toofull

Backfill-wait

Incomplete

Inconsistent

Peered

Recovering

Recovering-wait

Remapped

Scrubbing

Unactive

Unclean

Stale

Undersized

Down

 

 

Creating

含义：PG正在建立

引发缘由：建立pool的时候，根据指定的pg数量进行建立pg时出现的状态，正常状态

后果：无

解决方案：无需解决，正常状态之一

 

 

Peering

含义：PG之间进行互联，就其中的对象和元数据状态达成一致

引发缘由：当pg被creating以后，会进行互联，存储归置组副本的 OSD 之间就其中的对象和元数据状态达成一致。

后果：无

解决方案：无需解决，正常状态之一

 

 

Activating

含义：pg在完成peering过程后，会对以前的结果进行固化，等待全部pg同步，尝试进入active状态

引发缘由：pg进入active前的准备状态

后果：若是长期卡在该状态，会影响该PG没法读写，进而影响整个pool可用性

解决方案：

停掉PG所在全部OSD

用ceph-object-tool进行pg数据备份

用ceph-object-tool在主PG上删除空的pg（不要手动删除）

再次使用ceph-object-tool导入数据

手动给该pg目录赋ceph权限

最后重启osd

 

 

Active

含义：pg是活跃态，能够进行读写操做

引发缘由：正常状态

后果：无

解决方案：无需解决，正常状态之一

 

 

Backfilling

含义：回填状态

引发缘由：这种状况通常是因为osd的离线（超过5分钟没有心跳回应），ceph找寻新的osd来替换所进行的全量数据拷贝。

后果：出现这个状态通常都是肯定有osd挂掉或者离线了

解决方案：多数状况下ceph会自动完成数据回填，若是没法完成回填，就会进入backfill-toofull状态

 

 

Backfill-toofull

含义：backfilling挂起状态

引发缘由：一般是由于osd容量不足以回填丢失的osd引发

后果：形成pool没法写入，读写卡死。

解决方案：

须要检查osd容量，是否有严重不平衡现象，将超量osd数据手动疏散（reweight），若是是集群nearful现象，应该尽快物理扩容

紧急扩容方式（治标不治本，最好的方法仍是扩展osd数量和容量）

暂停osd读写：

ceph osd pause

通知mon和osd修改full阈值

ceph tell mon.* injectargs "--mon-osd-full-ratio 0.96"

ceph tell osd.* injectargs "--mon-osd-full-ratio 0.96"

通知PG修改full阈值：

ceph pg set_full_ratio 0.96

解除osd禁止读写：

ceph osd unpause

 

 

Backfill-wait

含义：PG正在等待开始回填操做。

引发缘由：OSD离线形成（未亲自捕获该状态，多是太快了没看到）

后果：接下来理论来说pg会进入backfilling状态进行数据回填

解决方案：正常的回填必经状态，无需特殊关注

 

 

Incomplete

含义：peering过程当中发现没法就数据状态达成一致

引发缘由：pg在选择权威日志的时候，权威日志无法完成，或者权威日志完成后和本地日志对比逻辑不正常

后果：一般会致使pg没法建立，卡在creating+incomplete状态，进而致使pool没法使用

解决方案：

首先确认osd_allow_recovery_below_min_size为true，还有副本数量是否合理，crushmap配置的选取osd数量是否与pool一致，若是都正常，尝试执行如下恢复流程

停掉全部incomplete的PG对应的每个osd

使用ceph-object-tool对osd进行mark complete

而后重启osd

 

 

Inconsistent

含义：其实就是副本数据不一致的意思

引发缘由：某个副本数据未知缘由丢失

后果：副本数据不一致致使安全性降低

解决方案：

使用ceph pg repair工具进行数据修复，通常状况下均可以恢复正常，若是没法恢复

把三副本的osd的osd_max_scrubs都先调大,再次使用使用ceph pg repair工具进行数据修复，最后再将osd_max_scrubs调回1

 

 

Peered

含义：搜索中，指的是PG找不到足够的副原本进行读写操做（连min_size都没法知足的状况下）

引发缘由：多个osd挂掉，形成当前活跃osd副本数<min_size，读写功能锁死

后果：pg没法使用，甚至pool没法进行常规io

解决方案：

集群健康状态下，osd挂掉超过5分钟会自动remapped修复该状态，想要快速修复该状态方法有二：

1 尝试启动副本osd，从新加入集群，peered会自动消失

2 主动out掉失联的osd，ceph会自动进入修复状态

 

 

Recovering

含义：恢复中

引发缘由：当某 OSD 挂了（ down ）时，其内的归置组会落后于别的归置组副本；此 OSD 重生（ up ）时，归置组内容必须更新到当前状态；

后果：恢复并不是老是这些小事，由于一次硬件失败可能牵连多个 OSD 。好比一个机柜或房间的网络交换机失败了，这会致使多个主机上的 OSD 落后于集群的当前状态，故障恢复后每个 OSD 都必须恢复。

解决方案：集群出现这个状态，说明PG正在自动恢复，等它恢复完成就行了。

 

 

Recovering-wait

含义：等待 Recovery 资源预留

引发缘由：PG正在等待恢复。

后果：理论来说pg会进入recovering状态进行数据恢复

解决方案：正常的恢复状态。

 

 

Remapped

含义：从新映射态

引发缘由：当Acting集合里面的PG组合发生变化时，数据从旧的集合迁移到新的集合中。这段时间可能比较久，新集合的主OSD在迁移完以前不能响应请求。因此新主OSD会要求旧主OSD继续服务指导PG迁移完成。一旦数据迁移完成，新主OSD就会生效接受请求。

后果：若是没法从新映射，数据就没法进行迁移，会形成数据的丢失。

解决方案：

在 OSD 挂掉或者在扩容的时候PG 上的OSD会按照Crush算法从新分配PG 所属的osd编号。而且会把 PG Remap到别的OSD上去。

Remapped状态时，PG当前Acting Set与Up Set不一致。

客户端IO能够正常读写。

 

 

Scrubbing

含义：清理中

引发缘由：pg正在作不一致性校验。

后果：会形成IO性能降低

解决方案：能够根据实际环境需求，关闭该功能或者下降自检频率。

 

 

Unactive

含义：非活跃态,PG 不能处理读写请求

引发缘由：PG 很长时间没有显示为 acitve 状态, (不可执行读写请求), PG 不能够执行读写,

后果：PG 不能够执行读写

解决方案：等待 OSD 更新数据到最新的备份状态

 

 

Unclean

含义：非干净态,PG 不能从上一个失败中恢复

引发缘由：归置组里有些对象的副本数未达到指望次数，它们应该在恢复中；

后果：数据安全性降低

解决方案：一般都要执行恢复操做

 

 

Stale

含义：为刷新态，pg没有被任何osd更新

引发缘由：极可能是osd挂掉引发的，通常状况下跟随peering状态一块儿出现

模拟：手动停掉一个osd，systemctl stop ceph-osd@0，查看ceph -s 会发如今短期内（peering以前），pg会进入stale+clean+active的特殊状态

后果：警告标志，每每表明着osd出现异常，或者某节点断网。

解决方案：通常状况下只须要等待peering完成便可。

 

 

Undersized

含义：副本数太小

引发缘由：该PG的副本数量小于存储池所配置的副本数量。一般是因为一个osd服务down了，出现此状态。

后果：下降数据可用性

解决方案：调整PG所在池的副本数 osd pool default min size =1 ，不建议调整。等osd服务起来就行了

 

 

Down

含义：失效

引发缘由：归置组的权威副本OSD宕机，必须等待其开机，或者被标记为lost才能继续

后果：这个时候该 PG 不能提供客户端 IO 读写， IO 会挂起夯住

解决方案：将OSD服务起来。