ceph-s & ceph_osd_tree_ceph缩容恢复_集群状态.md

一、集群状态与容量分布 (ceph -s & ceph osd df tree)

1. 集群概览 (ceph -s)

1cluster:
2  id:     xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
3  health: HEALTH_ERR
4          2 pgs stuck inactive
5          1 pgs inconsistent
6          57 requests are blocked > 32 sec
7
8  services:
9    mon: 3 daemons, quorum a,b,c
10    mgr: x(active)
11    osd: 8 osds: 7 up, 8 in; 1 osd down (osd.7)
12
13  data:
14    pools:   5 pools, 352 pgs
15    objects: 1.69k objects, 5.5 GiB
16    usage:   25 GiB used, 55 GiB / 80 GiB avail
17    pgs:     291 active+clean
18             2  incomplete
19             1  stale+active+clean
20             37 active+recovery_wait+degraded
21             16 active+recovery_wait+undersized+degraded+remapped
22             2  active+recovering+degraded
23             1  active+remapped+backfill_wait
24
25  progress:
26    Rebalancing after osd.7 marked in (stuck for 2h)

核心判断：

• HEALTH_ERR + requests are blocked：业务已受影响，需要立即处理

• incomplete + stale：数据有丢失风险，需要人工介入修复

• osd.7 down：新盘激活失败，需要检查硬件和日志

• progress stuck：后台任务卡住，需要排查阻塞原因

• cluster 27d39faa-...：集群的唯一标识符（FSID）。

• health HEALTH_WARN：集群当前的健康状态。

  • HEALTH_WARN：表示集群处于"警告"状态，数据虽然可用（集群未挂），但存在潜在风险（如降级、回填、恢复等）。

• 579 pgs backfill：有 579 个 Placement Groups (PG) 正在进行 Backfill（回填） 操作。这是数据在 OSD 之间移动的一种状态，通常发生在 OSD 故障恢复或扩容时。

• 25 pgs backfilling：正在处于回填过程中的 PG 数量。

• 5 pgs degraded：有 5 个 PG 处于 Degraded（降级） 状态。这意味着这些 PG 的数据副本数不足（例如，副本数为 3，但目前只有 2 个副本在线），如果再有一个 OSD 故障，这些 PG 对应的数据可能会丢失。

• 4 pgs recovery_wait：处于等待恢复队列中的 PG 数量。

• 1 pgs stuck degraded：有 1 个 PG 卡在降级状态，无法自动恢复，通常需要人工干预。

• 605 pgs stuck unclean：有 605 个 PG 无法达到干净状态（Clean），通常是由于数据不一致或恢复失败导致。

• recovery 1300458/4538988 objects misplaced (28.651%)：这是一个关键指标。表示有约 28.65% 的对象被 Misplaced（错位） 了。这意味着这些对象当前存储在了错误的 OSD 上（因为集群拓扑发生了变化，如 OSD 被标记为 out），集群正在努力将它们移动到正确的位置。

• pgmap v300311259: 2400 pgs, 1 pools, ...：

  • 2400 pgs：集群总共有 2400 个 PG。
  • 1 pools：有 1 个存储池（Pool）。
  • 13580 GB data：用户存储的数据总量约为 13.5 TB。
  • 43192 GB used：集群已使用的物理空间约为 43.1 TB（因为有副本，所以 used > data）。
  • 98639 GB avail：集群剩余可用空间约为 98.6 TB。

• recovery io 2193 MB/s：当前的恢复 IO 速率，约为 2.1 GB/s，说明集群正在高负荷地进行数据迁移。

2. health 字段：最顶层的"红灯"

这是第一眼要看的，一旦出现 HEALTH_ERR 或 HEALTH_WARN，就说明集群不正常了。

• **HEALTH_ERR**：最严重，意味着数据不可用或丢失。
  • 举例 ：health: HEALTH_ERR 1 pgs inconsistent; 2 pgs stuck inactive; 57 requests are blocked > 32 sec
  • 解读 ：有PG数据不一致（inconsistent），有PG卡死（stuck inactive），客户端读写请求被阻塞超过32秒，业务已中断。
• **HEALTH_WARN**：常见，表示集群降级运行，但数据通常还可读。
  • 举例 ：health: HEALTH_WARN Degraded data redundancy: 904/5061 objects degraded (17.862%); 17 pgs undersized; 7 slow ops
  • 解读 ：数据冗余度降低（部分副本丢失），有PG副本数不足（undersized），部分操作变慢。

3. pgs 字段：恢复过程的"晴雨表"

PG状态是判断恢复是否顺利的核心。异常状态主要有以下几类：

表格

异常状态	含义	严重程度	典型原因
incomplete	PG无法完成数据恢复，缺少关键信息	极高	换盘后新盘数据损坏或无法读取，导致PG无法确定权威副本
stale	PG长时间没有更新，主OSD可能失联	高	新盘激活失败，或网络问题导致OSD心跳超时
peering	PG正在协商主从关系，长时间卡住	中	换盘后OSD之间无法就PG状态达成一致，常见于盘符变化或版本不匹配
undersized	PG的副本数低于设定值	中	新盘刚加入，数据还没开始复制
degraded	PG的部分副本不可用或数据损坏	中	旧盘已移除，新盘数据还在恢复中
inconsistent	PG的多个副本数据不一致	高	换盘过程中数据写入异常，或旧盘有静默数据损坏
backfill_toofull	回填目标OSD空间不足	中	新盘容量小于集群平均值，或集群整体空间紧张

举例（换盘后半小时，恢复不顺利）：编辑

1pgs: 291 active+clean
2     2  incomplete
3     1  stale+active+clean
4     37 active+recovery_wait+degraded
5     16 active+recovery_wait+undersized+degraded+remapped
6     2  active+recovering+degraded
7     1  active+remapped+backfill_wait
8     1  active+remapped+backfill_toofull

关键判断：

• incomplete 和 stale 是红色警报，需要立即介入
• backfill_toofull 说明空间规划有问题，需要扩容或清理
• 其他 degraded、undersized 等状态，只要数量在减少，就是正常恢复过程

1. active+remapped+wait_backfill** (579 pgs)**

• 含义 ：
  • active：PG 是可用的，可以正常读写。
  • remapped：该 PG 的主 OSD 或副本 OSD 已经发生变化（比如某个 OSD 被标记为 out），数据需要移动到新的 OSD 上。
  • wait_backfill：等待执行回填操作。也就是说，系统已经知道要移动哪些数据，但还没开始实际拷贝。
• 通俗解释：这 579 个 PG "知道"自己该搬家了，但还在排队等工人（IO 资源、网络带宽）来搬。这是大规模数据重分布前的"待命"状态。

2. active+remapped+backfilling** (24 pgs)**

• 含义 ：
  • backfilling：正在进行实际的回填操作 ------ 即把数据从旧 OSD 拷贝到新 OSD。
• 通俗解释：这 24 个 PG 正在"搬家途中"，数据正在物理复制中。这个过程会消耗网络和磁盘 IO。

3. active+recovery_wait+degraded** (3 pgs)**

• 含义 ：
  • recovery_wait：等待恢复操作（通常是因为有 OSD 故障后重新上线，需要同步缺失的数据）。
  • degraded：当前副本数不足（例如 3 副本只剩 2 个）。
• 通俗解释：这 3 个 PG 因为之前有 OSD 挂了导致数据不完整，现在那个 OSD 可能回来了，但它们还在排队等"补全数据"。在此期间，它们仍然是危险的（再挂一个就丢数据）。

4. active+recovery_wait+degraded+remapped** (1 pg)**

• 含义 ：
  • 同时具备 recovery_wait, degraded, 和 remapped。
• 通俗解释：这个 PG 最复杂------它既缺副本（degraded），又需要恢复数据（recovery_wait），而且目标位置还变了（remapped）。相当于"既要修房子，又要换地基，还得等施工队排期"。

5. active+degraded+remapped+backfilling** (1 pg)**

• 含义 ：
  • 正在一边"降级运行"，一边进行"回填"操作。
• 通俗解释：这个 PG 虽然目前副本不全（危险状态），但系统已经开始把它往新位置迁移数据了。这是一种"边跑边修"的状态，风险较高，需尽快完成。

状态组合	风险等级	是否影响业务	建议动作
wait_backfill	低	否	监控即可，等待自动处理
backfilling	中	可能轻微延迟	观察 IO 压力，必要时限速
recovery_wait + degraded	高	是（潜在丢数据）	检查故障 OSD 是否恢复，手动触发恢复
stuck degraded / unclean	极高	是（数据不可用或丢失风险）	必须人工干预：ceph pg repair, ceph osd rm, 或联系支持

4. progress 字段：后台任务的"进度条"

这个字段会显示当前正在执行的后台任务，异常情况通常表现为任务长时间不推进。

• 正常 ：progress: Rebalancing after osd.7 marked in
• 异常 ：progress: Rebalancing after osd.7 marked in (stuck for 2h)
  • 解读：重平衡任务卡住超过2小时，可能是磁盘性能瓶颈、网络问题或PG卡死。

二、OSD 容量分布 (ceph osd df tree | sort -unr -k7 | head -20)

这部分显示了每个 OSD 的存储使用情况，经过了排序（按使用率降序）。

• 第一列 (ID)：OSD 的编号（如 192, 2, 91 等）。
• 第二列 ：REWEIGHT 值。这是管理员手动设置的权重，用于控制 OSD 接收数据的比例。1.00000 表示正常权重。
• 第三列 (SIZE)：OSD 的总容量（如 432G）。
• 第四列 (USED)：已使用的容量。
• 第五列 (AVAIL)：剩余可用容量。
• 第六列 (USE%)：已使用空间的百分比。
• 第七列 (VAR) ：该 OSD 的使用率与集群平均使用率的偏差系数。1.0 是平均值。如果某个 OSD 的 VAR 远大于 1（比如 1.54），说明它比其他 OSD 满得多，存在数据分布不均的问题。
• 第八列 (OSD NAME)：OSD 的名称。