共计 3615 个字符，预计需要花费 10 分钟才能阅读完成。
这篇文章主要为大家展示了“Ceph 中的 Placement Group 状态有哪些”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让丸趣 TV 小编带领大家一起研究并学习一下“Ceph 中的 Placement Group 状态有哪些”这篇文章吧。
Placement Group（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 unpauseBackfill-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，查看 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 服务起来。
以上是“Ceph 中的 Placement Group 状态有哪些”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注丸趣 TV 行业资讯频道！
