一、 常见的 pg 状态：
| 状态 | 说明 |
|---|---|
creating |
创建中 |
down |
PG处于失效状态，PG处于离线状态 |
repair |
PG正在被检查，被发现的任何不一致都将尽可能的被修复 |
peering |
当 ceph peering pg, ceph 将会把 pg 副本协定导入 osd, 当 ceph 完成 peering, 意味着 osd 同意当前 PG 状态, 并允许写入 PG处于 peering 过程中, peering 由主 osd 发起的使存放 PG 副本的所有 OSD 就 PG 的所有对象和元素数据的状态达成一致的过程, peering 过程完成后, 主 OSD 就可以接受客户端写请求. |
active |
当 ceph 完成 peering 过程, pg 将会变成 active, active 状态意味着 pg 中的数据变得可用, 主 pg 将可执行读写操作 PG 是活动的, 意味着 PG 中的数据可以被读写, 对该 PG 的操作请求都讲会被处理. |
clean |
干净态。PG当前不存在待修复的对象， Acting Set和Up Set内容一致，并且大小等于存储池的副本数 |
replay |
某OSD崩溃后，PG正在等待客户端重新发起操作。 |
degraded |
当客户端写对象到主 osd, 主 OSD 会把数据写复制到对应复制 OSD, 在主 OSD 把对象写入存储后, PG 会显示为 degraded 状态, 直到主 osd 从复制 OSD 中接收到创建副本对象完成信息 PG 处于 active+degraded 原因是因为 OSD 是处于活跃, 但并没有完成所有的对象副本写入, 假如 OSD DOWN, CEPH 标记每个 PG 分配到这个相关 OSD 的状态为 degraded, 当 OSD 重新上线, OSD 将会重新恢复 假如 OSD DOWN 并且 degraded 状态持续, CEPH 会标记 DOWN OSD, 并会对集群迁移相关 OSD 的数据, 对应时间由 mon osd down out interval 参数决定 PG 可以被北极为 degraded, 因为 ceph 在对应 PG 中无法找到一个或者多个相关的对象, 你不可以读写 unfound 对象, 你仍然可以访问标记为 degraded PG 的其他数据 PG 中部分对象的副本数量未达到规定的数量 |
inconsistent |
PG副本出现不一致, 对象大小不正确或者恢复借宿后某个副本出现对象丢失现象 |
recoverying |
ceph 设备故障容忍在一定范围的软件与硬件问题, 当 OSD 变 DOWN, 那么包含该 OSD 的 PG 副本都会有问题, 当 OSD 恢复, OSD 对应的 PG 将会更新并反映出当前状态, 在一段时间周期后, OSD 将会恢复 recoverying 状态 recovery 并非永远都有效, 因为硬件故障可能会导致多个 OSD 故障, 例如, 网络交换机故障, 可以导致集群中的多个主机及主机包含的 OSD 故障当网络恢复之后, 每个 OSD 都必须执行恢复 |
back filling |
当新 OSD 加入集群, CRUSH 将会为集群新添加的 OSD 重新分配 PG, 强制新的 OSD 接受重新分配的 PG 并把一定数量的负载转移到新 OSD 中,back filling OSD 会在后台处理, 当 backfilling 完成, 新的 OSD 完成后, 将开始对请求进行服务在 backfill 操作期间, 你可以看到多种状态backfill_wait 表示 backfill 操作挂起, 但 backfill 操作还没有开始 ( PG 正在等待开始回填操作 )backfill 表示 backfill 操作正在执行backfill_too_full 表示在请求 backfill 操作, 由于存储能力问题, 但不可以完成 |
remapped |
当 pg 改变, 数据从旧的 osd 迁移到新的 osd, 新的主 osd 应该请求将会花费一段时间, 在这段时间内, 将会继续向旧主 osd 请求服务, 直到PG 迁移完成, 当数据迁移完成, mapping 将会使用新的 OSD 响应主 OSD 服务 当 PG 的 action set 变化后, 数据将会从旧 acting set 迁移到新 action set, 新主 OSD 需要过一段时间后才能提供服务, 因此它会让老的主 OSD 继续提供服务, 知道 PG 迁移完成, 数据迁移完成后, PG map 将会使用新 acting set 中的主 OSD |
scrubbing |
PG 在做不一至性校验 |
deep |
表示这是一个深度检查。深度检查比普通检查更彻底，它会检查所有对象的元数据和数据内容，以确保没有任何问题。深度检查可能会消耗更多的资源和时间。 |
二、 每个 pool 中 pg 数量的计算方法
官方：
Total PGs = (Total_number_of_OSD * 100) / max_replication_count
每个池中 pg 数量最好接近或等于2的次方
：
最大可容忍的总 PG 副本数 = 200 × osd数
示例：
有100 个 osd，2 副本，5 个 pool
Total PGs = 100 * 100 / 2 = 5000
每个 pool 的PG = 5000 /5 = 1000，那么创建 pool 的时候就指定 pg 为 1024
ceph osd pool create images 1024
最大可容忍的总 PG 副本数200 * 100 = 20000
ceph osd pool create images 1024
当前 images 池的pg = 1024 * 副本数；
如果有多个池要注意他们的
总pg = 池数 * 池pg * 副本小于 最大可容忍的总 PG 副本数
三、ceph pg 命令
1. ceph pg dump
打印所有 PG 的详细信息，包括 PG ID、状态、主副本位置、数据量等
# ceph pg dump
dumped all
version 33420
stamp 2024-08-16T09:56:59.472500+0800
last_osdmap_epoch 0
last_pg_scan 0
PG_STAT OBJECTS MISSING_ON_PRIMARY DEGRADED MISPLACED UNFOUND BYTES OMAP_BYTES* OMAP_KEYS* LOG DISK_LOG STATE STATE_STAMP VERSION REPORTED UP UP_PRIMARY ACTING ACTING_PRIMARY LAST_SCRUB SCRUB_STAMP LAST_DEEP_SCRUB DEEP_SCRUB_STAMP SNAPTRIMQ_LEN
7.b 1 0 0 0 0 0 0 0 6 6 active+clean 2024-08-15T15:23:44.357364+0800 1925'7 1935:777 [1,2] 1 [1,2] 1 0'0 2024-08-15T09:48:01.803090+0800 0'0 2024-08-15T09:48:01.803090+0800 0
打印内容说明
| 字段 | 说明 | 示例 |
|---|---|---|
PG_STAT |
PG 的 ID（标识符），由池编号和 PG 编号组成。 | 7.b 表示池 7 中的 PG 编号 b。 |
OBJECTS |
PG 中当前存储的对象数量。 | 1 表示该 PG 中存储了 1 个对象。 |
MISSING_ON_PRIMARY |
在主 OSD 上缺失的对象数量。这表明主副本中某些对象未能完全复制到副本 OSD。 | 0 表示没有对象在主 OSD 上缺失。 |
DEGRADED |
PG 中处于降级状态的对象数量。降级的对象是指没有满足完整复制要求的对象。 | 0 表示没有降级对象。 |
MISPLACED |
PG 中被错误放置的对象数量。这些对象没有位于正确的 OSD 上，可能是由于数据迁移或恢复过程中发生。 | 0 表示没有错误放置的对象。 |
UNFOUND |
未找到的对象数量。这些对象是 Ceph 试图恢复或检查时未能定位到的。 | 0 表示没有未找到的对象。 |
BYTES |
PG 中存储的数据总字节数。 | 0 表示该 PG 当前没有存储任何数据。 |
OMAP_BYTES |
PG 中存储的 OMAP 数据的总字节数。OMAP 用于存储对象元数据（key-value 对）。 | 0 表示没有 OMAP 数据。 |
OMAP_KEYS |
PG 中存储的 OMAP 键的数量。 | 0 表示没有 OMAP 键。 |
LOG |
PG 的日志条目数量。每个 PG 有一个独立的日志，记录了该 PG 的所有写操作。 | 6 表示有 6 条日志条目。 |
DISK_LOG |
PG 在磁盘上记录的日志条目数量。与 LOG 字段类似，但表示已持久化到磁盘的条目数。 | 6 表示有 6 条日志条目已持久化。 |
STATE |
PG 的当前状态。常见状态包括 active+clean（正常）、degraded（降级）、recovering（恢复中）等。 | active+clean 表示该 PG 正常并且所有副本都是一致的。 |
STATE_STAMP |
PG 状态的最后更新时间戳。 | 2024-08-15T15:23:44.357364+0800 表示该 PG 状态在这个时间最后一次更新。 |
VERSION |
PG 的当前版本号，由 epoch 和 log entry 组成。表示自 PG 创建以来的修改次数。 | 1925'7 表示版本号是 1925 期的第 7 条日志。 |
REPORTED |
报告该 PG 状态的 OSD 编号和日志条目。通常表示最后一个已知的 PG 状态信息。 | 1935:777 表示 OSD 1935 报告的第 777 条日志。 |
UP |
当前分配给此 PG 的 OSD 编号列表。这些 OSD 负责处理该 PG 的 I/O 请求。 | [1,2] 表示 PG 被分配给了 OSD 1 和 OSD 2。 |
UP_PRIMARY |
当前分配给此 PG 的主 OSD 编号。主 OSD 处理该 PG 的大部分写请求。 | 1 表示 OSD 1 是该 PG 的主 OSD。 |
ACTING |
当前活跃的 OSD 编号列表，这些 OSD 实际上正在处理该 PG 的请求。 | [1,2] 表示 OSD 1 和 OSD 2 当前处理该 PG 的请求。 |
ACTING_PRIMARY |
当前活跃的主 OSD 编号。 | 1 表示 OSD 1 是当前活跃的主 OSD。 |
LAST_SCRUB |
PG 最后一次 scrub 操作的日志条目版本号。scrub 是 Ceph 用于检测和修复数据不一致的操作。 | 0'0 表示该 PG 尚未进行 scrub 操作。 |
SCRUB_STAMP |
PG 最后一次 scrub 操作的时间戳。 | 2024-08-15T09:48:01.803090+0800 表示该 PG 在这个时间进行了最后一次 scrub 操作。 |
LAST_DEEP_SCRUB |
PG 最后一次 deep-scrub 操作的日志条目版本号。deep-scrub 是更深入的数据一致性检查。 | 0'0 表示该 PG 尚未进行 deep-scrub 操作。 |
DEEP_SCRUB_STAMP |
PG 最后一次 deep-scrub 操作的时间戳。 | 2024-08-15T09:48:01.803090+0800 表示该 PG 在这个时间进行了最后一次 deep-scrub 操作。 |
SNAPTRIMQ_LEN |
PG 的快照修剪队列长度。表示该 PG 中等待修剪的快照数量。 | 0 表示没有等待修剪的快照。 |
2. ceph pg map <pgid>
显示指定 PG 的映射信息，包括 PG 的主 OSD 和副本所在的 OSD。
# ceph pg map 7.b
osdmap e1937 pg 7.b (7.b) -> up [1,2] acting [1,2]
打印内容说明
| 字段 | 说明 | 示例 |
|---|---|---|
osdmap e1937 |
这是当前 OSD Map 的 epoch 编号 1937。每次 OSD Map 发生变化（例如，OSD 的加入、退出或状态变化），epoch 号都会递增。 |
e1937 表示这是第 1937 期的 OSD Map。 |
pg 7.b (7.b) |
pg 7.b 这是 PG 的标识符，由池编号 7 和 PG 编号 b 组成。 |
(7.b) 再次重复了 PG 的标识符，通常用于确认或显示 PG 的一致性信息。 |
-> up [1,2] |
up 表示当前参与该 PG 的 OSD 列表。这里的 OSD 处于 "up" 状态，也就是说它们当前是在线且可用的。 |
[1,2]: 表示 OSD 编号 1 和 2 当前负责此 PG 的存储和处理工作。这个列表中的 OSD 是被指定为存储 PG 数据的 OSD 集合。 |
acting [1,2] |
acting 表示实际处理此 PG 数据的 OSD 列表。通常情况下，acting 集合与 up 集合是一致的。 |
[1,2] 表示 OSD 编号 1 和 2 当前实际处理此 PG 的 I/O 操作和请求。 |
3. ceph pg ls
列出所有 PG 的基本信息。比 pg dump 输出更简洁
4. ceph pg stat
显示集群中 PG 的整体状态，包括活跃、清洁、未恢复等统计信息。
# ceph pg stat
177 pgs: 177 active+clean; 6.7 GiB data, 246 GiB used, 5.9 TiB / 6.1 TiB avail
打印内容说明
| 字段 | 说明 | 示例 |
|---|---|---|
177 pgs: 177 active+clean |
Ceph 集群中有 177 个 PG，其中所有的 177 个 PG 都处于 active+clean 状态。 |
PG: Placement Group 是 Ceph 中用于数据分布的基本单位。active+clean: 表示这些 PG 当前是活跃且干净的，意味着数据在所有副本之间是完全一致的，没有需要恢复或修复的对象。 |
6.7 GiB data |
Ceph 集群中目前存储了 6.7 GiB（吉比字节）的实际用户数据。 |
data: 这是用户实际存储在 Ceph 中的数据总量，不包括副本或编码数据。 |
246 GiB used |
Ceph 集群中总共使用了 246 GiB 的物理存储空间。 |
used: 这是 Ceph 使用的总存储空间，包含了所有的数据副本、元数据、以及 Ceph 本身的管理开销。因此，used 空间通常会比实际存储的数据量大，因为 Ceph 会根据数据冗余配置（如复制或 EC 编码）存储多个副本或冗余数据。 |
5.9 TiB / 6.1 TiB avail |
Ceph 集群总共有 6.1 TiB（泰比字节）的可用物理存储空间，其中还剩余 5.9 TiB 可用。 |
avail: 这是 Ceph 集群中剩余的可用存储空间，可以用于存储更多数据。6.1 TiB: 表示整个 Ceph 集群中所有 OSD 的总存储容量。5.9 TiB avail: 表示在总容量中，剩余 5.9 TiB 的空间可以用于新数据的存储。 |
5. ceph pg scrub <pgid>
对指定 PG 执行 scrub 操作，检查 PG 的数据一致性
# ceph pg scrub 7.b
instructing pg 7.b on osd.1 to scrub
打印内容说明
| 字段 | 说明 | 示例 |
|---|---|---|
instructing pg 7.b |
Ceph 正在指示 PG 7.b 进行 scrub 操作。 |
7.b: 这是一个 PG 的标识符，表示池 7 中的 PG 编号 b。 |
on osd.1 |
表示 PG 7.b 的主副本（primary OSD）当前位于 osd.1 上，因此 scrub 操作将在 osd.1 上发起。 |
osd.1: 这是负责处理 PG 7.b 的主 OSD（Primary OSD）。在 Ceph 中，scrub 操作通常由主 OSD 发起，并在所有相关的副本 OSD 上执行。 |
to scrub |
表示对 PG 7.b 的 scrub 操作已经指示并开始执行。 scrub 操作用于检查 PG 中的数据一致性，确保所有副本的一致性，并修复可能存在的错误。 |
6. ceph pg deep-scrub <pgid>
对指定 PG 执行深度 scrub，检查 PG 的数据一致性，比普通 scrub 更为彻底
7. ceph pg repair <pgid>
修复指定 PG 中发现的不一致或损坏的数据
：修复操作可能会影响集群性能，且存在数据修复的风险，建议在有备份或清楚问题来源时使用。
8. ceph pg force-create-pg <pgid>
强制创建指定 PG，通常用于手动干预 PG 创建或恢复过程
9. ceph pg ls-by-osd 40 | wc -l
osd 中 pg 数量
四、实际使用中的注意事项
1. PG 状态
Ceph 中 PG 的状态对集群的健康非常关键。常见的 PG 状态包括 active+clean（表示正常）、degraded（表示有副本丢失）、stuck（表示状态停滞），管理员应及时监控并处理异常状态。
2. Scrub 和 Deep Scrub
这些命令用于检查 PG 的数据一致性，但它们会消耗一定的系统资源，并可能影响正常的 I/O 操作。因此建议在性能需求较低的时间段执行这些操作。
3. 数据修复
repair 命令用于修复数据不一致的 PG。但在执行之前，应尽可能了解问题来源，因为不正确的修复可能会导致数据丢失。
4. 监控与报警
通过ceph pg stat 和 ceph pg dump 等命令定期监控 PG 的状态，可以提前发现并处理潜在问题，确保集群的稳定运行。
