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

知识的领域是无限的,我们的学习也是无限期的。这篇文章主要讲述ceph pg 状态监测#yyds干货盘点#相关的知识，希望能为你提供帮助。
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 entertainsimultaneously 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"