ceph pg 状态监测#yyds干货盘点#

Posted 2021-12-31 坚韧的石头

1、pg 状态监测（简单 描述）

检查 集群 健康状态时（ceph health、ceph -s、ceph -w 等命令），你需要 关注 集群的健康状态（HEALTH OK -- 健康），如果 集群 处于 异常状态，某些 情况下 需要 监测 pg 状态，本文 就是 简单的描述一下，掌握 检查 集群 健康状态时 所需的基本 概念/知识，以便 后期的 排除异常

1.1 pg 健康状态

只有 pg 处于 "activate + clean" 状态，才能 代表 该 pg 处于 正常状态，其余 状态 均属于 异常

## 检查 pg 健康状态 # ceph pg stat

1.1.1 查询 所有 pg

## pg 的格式 : <pool_num>.<pg_id> # ceph pg dump ## 以 json 格式 显示 pg dump，并 保存 至 某一文件中 # ceph pg dump -o <file_name> --format=json

1.1.2 查看 某一 pg

## 查看 某一 pg 详细 信息 # ceph pg <pool_num>.<pg_id> query

1.2 pg creating 状态

新的 pg 创建时（例如创建数据池，指定 pg数），pg（pg 处于 creating） 会在 一个 osd（该 osd 标志为 acting） 上 生成，然后 经过 peering ，最终 pg 达到 activate + clean 状态

1.3 pg peering 状态

暂时 不写，过程 比较 复杂，后期 单独描述

1.4 pg activate 状态

一旦 pg 完成了 peering 过程，pg 也许 就会变成 activate（正常 情况下）；主 osd 或者 副本 osd 上 处于 activate 状态的pg 可以 正常 供客户端 进行 读写 操作

1.5 pg clean 状态

一旦 pg 处于 clean 状态，表示 pg 分布 根据 crush 保持一致（acting 与 up 保持一致）

1.6 obj degraded 状态

当 客户端 写入 一个 obj 到 主osd，主osd 又得 向副osd 写入数据，直至 向副osd 成功写入 obj 并返回给 主osd的 这一过程，obj 一直处于 degraded 状态

1.6.1 osd down 导致 obj degraded

一个 osd 异常（例如，I/O error），则 该 osd 就会被 设置为 down（标志为 down 时，此时 就会 出现 obj degraded） 并且 out 出 集群；一般情况下（集群 没有 设置 nodown、noout），osd 出现异常 无法 读写之后，ceph 集群 会自动 把 osd 标志为 down 并且 out 出集群；

1.6.2 osd down -> out 时间 间隔

ceph 集群 会自动 把 osd 标志为 down 并且 out 出集群 这个 时间 间隔 一般为 300s，可以 通过参数 "mon_osd_down_out_interval" 调整控制

1.7 pg recovering 状态（资源预约）

当 某一个 osd out、in 或者 调整 负载值之后，pg 对应的 osd 更新 当前的 pg 状态 信息，这一过程中 的 pg 处于 recovering 状态；pg recovering 完成之后，obj 也随之 开始 迁移，obj 迁移的过程 可以称为 数据回填 --backfill（可以 通过 参数设置 来 控制 obj 迁移速度 -- 简单 知道 下，毕竟 还没有 经过 测试）

1.7.1 recover 相关参数（简单介绍，未经测试）

• osd_recovery_delay_start : allows an OSD to restart, re-peer and even process some replay requests before starting the recovery process.
• osd_recovery_threads : limits the number of threads for the recovery process, by default one thread.
• osd_recovery_thread_timeout : set a thread timeout, because multiple OSDs may fail, restart and re-peer at staggered rates.
• osd_recovery_max_active : limits the number of recovery requests an OSD will entertain simultaneously to prevent the OSD from failing to serve
• osd_recovery_max_chunk : limits the size of the recovered data chunks to prevent network congestion

1.8 pg backfilling 状态

某些 情况下（新增、删除 osd、pg均衡调整 等），已经 分配 完成 的 pg 根据 crush 算法 重新 分配 到 新的 osd 上（或者 删除的osd 上的pg 分配到 别的 osd 上），这个 过程 叫做 backfill（数据回填）

1.8.1 pg backfill 相关 状态

• backfill_wait : a backfill operation is pending, but isn’t underway yet
• backfill : a backfill operation is underway
• backfill_too_full : a backfill operation was requested, but couldn’t be completed due to insufficient storage capacity(可以 通过 调整 osd_backfill_full_ratio 来 解决此问题)
• incomplete : a placement group cannot be backfilled

1.8.2 pg backfill 相关参数

• osd_max_backfills : the maximum number of concurrent backfills to or from an OSD to 10
• osd_backfill_full_ratio : enables an OSD to refuse a backfill request if the OSD is approaching its full ratio, by default 85%
• osd_backfill_retry_interval : If an OSD refuses a backfill request, the osd backfill retry interval enables an OSD to retry the request, by default after 10 seconds

1.9 pg remapped 状态

当 pg 需要 重新 归置时（例如，重新 调整 pg 负载），一些 pg 会 迁移到 新的 osd 上，而 迁移过程 需要 一定的时间，这个 时间段 仍有 旧的 osd 对外 提供服务，直至 迁移完成，这个 过程中 的 pg 处于 remapped 状态

1.10 pg stale 状态

如果 主osd 因某些原因 down了；如果 pg 临时主osd 或者 其他副osd 向mon 汇报 主osd down 了， 那么 mon 将pg 标志为 stale状态（故障域 小于 副本数 时，也会 出现此状态）

1.11 pg misplaced 状态

pg 副本数 处于 错误的位置（一般 不会 发生 此错误 状态，暂未遇到）

1.12 pg incomplete 状态

代表 有 pg 无法 从异常状态中恢复，此时 需要 查找原因，解决问题

2、pg 定位/查找

2.1 stuck pg

一般 情况下，pg 不处于 activate + clean 状态 不一定就代表 该pg 不能供 客户端 访问，因为 ceph 存储 具备 自我修复的功能；但也不是 pg 修复 一定 就能 成功，当 一些 pg 处于 "stuck"(人为定义的) 状态时，就可能 无法 修复，stuck 一般包括 "unclean、inactivate、stale、inconsistent"

• unclean
• inactivate
• stale
• inconsistent

2.2 定位/查找 stuck pg

## 查找 stuck pg # ceph pg dump_stuck [unclean|inactive|stale|undersized|degraded]