Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

第 7 章 Ceph 放置组故障排除

本节介绍修复与 Ceph 放置组(PG)相关的最常见错误。

先决条件

  • 验证您的网络连接。
  • 确保 monitor 能够形成仲裁。
  • 确保所有健康的 OSD 为 up 和 in，回填和恢复过程已完成。

7.1. 最常见的 Ceph 放置组错误
复制链接

下表列出了 ceph health detail 命令返回的最常见的错误消息。这些表中提供了相应部分的链接，这些部分解释了错误并指向修复问题的特定程序。

另外，您可以列出处于非最佳状态的放置组。详情请查看 第 7.2 节 “列出放置组处于 过时、不活动 或未 清除 状态”。

先决条件

  • 一个正在运行的 Red Hat Ceph Storage 集群。
  • 正在运行的 Ceph 对象网关.

7.1.1. 放置组错误消息
复制链接

常见放置组错误消息表以及潜在的修复。

Expand
错误消息查看

HEALTH_ERR

PG 停机

放置组处于 down状态

pgs inconsistent

Inconsistent placement groups

scrub errors

Inconsistent placement groups

HEALTH_WARN

pgs stale

Stale placement groups

unfound

Unfound objects

7.1.2. Stale 放置组
复制链接

ceph health 命令将一些放置组 (PG) 列为 stale ： 

HEALTH_WARN 24 pgs stale; 3/300 in osds are down
Copy to Clipboard Toggle word wrap

这意味着

当放置组没有从 PG 的操作集合的 Primary OSD 接收任何状态更新，或者当其他 OSD 报告 Primary OSD 为 down 时，Monitor 会将该放置组标记为 stale。

通常，PG 在启动存储集群后进入 stale 状态，直到对等过程完成为止。但是，如果 PG 处于 stale 状态的时间超过预期，这可能表示这些 PG 的 Primary OSD 为 down 或未向 monitor 报告 PG 统计信息。当存储 过时 PG 的 Primary OSD 备份 时，Ceph 会开始恢复 PG。

mon_osd_report_timeout 设置决定了 OSD 向 monitor 报告 PG 统计的频率。默认情况下，此参数设置为 0.5，这意味着 OSD 每半年报告统计数据。

要排除此问题，请执行以下操作

  1. 识别哪些 PG 处于 stale 状态，以及它们存储在哪些 OSD 上。错误消息包括类似以下示例的信息：

    示例

    [ceph: root@host01 /]# ceph health detail
HEALTH_WARN 24 pgs stale; 3/300 in osds are down
...
pg 2.5 is stuck stale+active+remapped, last acting [2,0]
...
osd.10 is down since epoch 23, last address 192.168.106.220:6800/11080
osd.11 is down since epoch 13, last address 192.168.106.220:6803/11539
osd.12 is down since epoch 24, last address 192.168.106.220:6806/11861
    Copy to Clipboard Toggle word wrap

  2. 对标记为 down 的 OSD 的任何问题进行故障排除。详情请参阅 关闭 OSD。

7.1.3. Inconsistent placement groups
复制链接

有些放置组被标记为 active + clean + inconsistent，ceph health detail 会返回类似如下的错误消息： 

HEALTH_ERR 1 pgs inconsistent; 2 scrub errors
pg 0.6 is active+clean+inconsistent, acting [0,1,2]
2 scrub errors
Copy to Clipboard Toggle word wrap

这意味着

当 Ceph 检测到 PG 中一个或多个对象副本中的不一致时，它会将该 PG 标记为 inconsistent。最常见的不一致是：

  • 对象的大小不正确。
  • 恢复完成后，一个副本中的对象会丢失。

在大多数情况下，清理过程中的错误会在放置组内造成不一致。

要排除此问题，请执行以下操作

  1. 登录到 Cephadm shell：

    示例

    [root@host01 ~]# cephadm shell
    Copy to Clipboard Toggle word wrap

  2. 确定哪个放置组 处于不一致的状态 ： 

    [ceph: root@host01 /]# ceph health detail
HEALTH_ERR 1 pgs inconsistent; 2 scrub errors
pg 0.6 is active+clean+inconsistent, acting [0,1,2]
2 scrub errors
    Copy to Clipboard Toggle word wrap

  3. 确定 PG 不一致 的原因。

    1. 在 PG 中启动深度清理过程：

      语法

      ceph pg deep-scrub ID
      Copy to Clipboard Toggle word wrap

      使用 inconsistent 的 PG 的 ID 替换 ID，例如： 

      [ceph: root@host01 /]# ceph pg deep-scrub 0.6
instructing pg 0.6 on osd.0 to deep-scrub
      Copy to Clipboard Toggle word wrap

    2. 搜索 ceph -w 的输出，以查找与该放置组相关的任何消息：

      语法

      ceph -w | grep ID
      Copy to Clipboard Toggle word wrap

      使用 inconsistent 的 PG 的 ID 替换 ID，例如： 

      [ceph: root@host01 /]# ceph -w | grep 0.6
2022-05-26 01:35:36.778215 osd.106 [ERR] 0.6 deep-scrub stat mismatch, got 636/635 objects, 0/0 clones, 0/0 dirty, 0/0 omap, 0/0 hit_set_archive, 0/0 whiteouts, 1855455/1854371 bytes.
2022-05-26 01:35:36.788334 osd.106 [ERR] 0.6 deep-scrub 1 errors
      Copy to Clipboard Toggle word wrap

  4. 如果输出包含与以下类似的错误消息，您可以修复 不一致的 放置组。详情请参阅 修复不一致的放置组。

    语法

    PG.ID shard OSD: soid OBJECT missing attr , missing attr _ATTRIBUTE_TYPE
PG.ID shard OSD: soid OBJECT digest 0 != known digest DIGEST, size 0 != known size SIZE
PG.ID shard OSD: soid OBJECT size 0 != known size SIZE
PG.ID deep-scrub stat mismatch, got MISMATCH
PG.ID shard OSD: soid OBJECT candidate had a read error, digest 0 != known digest DIGEST
    Copy to Clipboard Toggle word wrap

  5. 如果输出包含与以下类似的错误消息，则无法安全地修复不一致的 PG，因为您可以丢失数据。在这种情况下，创建一个支持问题单。详情请参阅联系红帽支持。 

    PG.ID shard OSD: soid OBJECT digest DIGEST != known digest DIGEST
PG.ID shard OSD: soid OBJECT omap_digest DIGEST != known omap_digest DIGEST
    Copy to Clipboard Toggle word wrap

7.1.4. unclean PG
复制链接

ceph health 命令返回类似如下的错误消息： 

HEALTH_WARN 197 pgs stuck unclean
Copy to Clipboard Toggle word wrap

这意味着

如果 PG 未在 Ceph 配置文件中的 mon_pg_stuck_threshold 参数中指定的秒数达到 active+clean 状态，则 Ceph 会将其标记为 unclean。mon_pg_stuck_threshold 的默认值为 300 秒。

如果放置组为 unclean，它包含没有复制 osd_pool_default_size 参数中指定的次数的对象。osd_pool_default_size 的默认值为 3，这意味着 Ceph 创建三个副本。

通常，unclean 放置组代表某些 OSD 可能处于 down。

要排除此问题，请执行以下操作

  1. 确定哪些 OSD 为 down ： 

    [ceph: root@host01 /]# ceph osd tree
    Copy to Clipboard Toggle word wrap
  2. 故障排除和修复与 OSD 相关的问题。详情请参阅关闭 OSD。

7.1.5. 不活跃的放置组
复制链接

ceph health 命令返回类似如下的错误消息： 

HEALTH_WARN 197 pgs stuck inactive
Copy to Clipboard Toggle word wrap

这意味着

如果 PG 在 Ceph 配置文件中的 mon_pg_stuck_threshold 参数中指定的秒数中未激活，Ceph 会将它标记为不活动。mon_pg_stuck_threshold 的默认值为 300 秒。

通常，inactive 放置组代表某些 OSD 可能处于 down。

要排除此问题，请执行以下操作

  1. 确定哪些 OSD 为 down ： 

    # ceph osd tree
    Copy to Clipboard Toggle word wrap
  2. 故障排除和修复与 OSD 相关的问题。

其它资源

7.1.6. 放置组处于 down 状态
复制链接

ceph health detail 命令报告某些放置组 已停机 ： 

HEALTH_ERR 7 pgs degraded; 12 pgs down; 12 pgs peering; 1 pgs recovering; 6 pgs stuck unclean; 114/3300 degraded (3.455%); 1/3 in osds are down
...
pg 0.5 is down+peering
pg 1.4 is down+peering
...
osd.1 is down since epoch 69, last address 192.168.106.220:6801/8651
Copy to Clipboard Toggle word wrap

这意味着

在某些情况下，对等过程可能会被阻断，这会阻止放置组处于活跃状态并可用。通常，OSD 故障会导致对等失败。

要排除此问题，请执行以下操作

确定什么阻塞了对等进程：

语法

ceph pg ID query
Copy to Clipboard Toggle word wrap

将 ID 替换为 down 的 PG 的 ID：

示例

[ceph: root@host01 /]#  ceph pg 0.5 query

{ "state": "down+peering",
  ...
  "recovery_state": [
       { "name": "Started\/Primary\/Peering\/GetInfo",
         "enter_time": "2021-08-06 14:40:16.169679",
         "requested_info_from": []},
       { "name": "Started\/Primary\/Peering",
         "enter_time": "2021-08-06 14:40:16.169659",
         "probing_osds": [
               0,
               1],
         "blocked": "peering is blocked due to down osds",
         "down_osds_we_would_probe": [
               1],
         "peering_blocked_by": [
               { "osd": 1,
                 "current_lost_at": 0,
                 "comment": "starting or marking this osd lost may let us proceed"}]},
       { "name": "Started",
         "enter_time": "2021-08-06 14:40:16.169513"}
   ]
}
Copy to Clipboard Toggle word wrap

recovery_state 部分包含有关为什么对等进程被阻止的信息。

7.1.7. Unfound objects
复制链接

ceph health 命令返回一个类似于以下的错误消息，其中包含 unfound 关键字： 

HEALTH_WARN 1 pgs degraded; 78/3778 unfound (2.065%)
Copy to Clipboard Toggle word wrap

这意味着

当知道这些对象或它们的较新副本存在但无法找到它们时，Ceph 会将其标记为 unfound。因此，Ceph 无法恢复这样的对象并继续恢复过程。

Situation 示例

放置组在 osd.1 和 osd.2 上存储数据。

  1. OSD.1 停机。
  2. osd.2 处理一些写入操作。
  3. OSD.1 启动。
  4. osd.1 和 osd.2 启动之间的对等进程，并且 osd.1 上缺少的对象被排队以进行恢复。
  5. 在 Ceph 复制新对象之前，osd.2 会 停机。

因此，osd.1 知道这些对象存在，但没有 OSD 具有对象的副本。

在这种情况下，Ceph 正在等待故障节点再次访问，而 unfound 对象会阻止恢复过程。

要排除此问题，请执行以下操作

  1. 登录到 Cephadm shell：

    示例

    [root@host01 ~]# cephadm shell
    Copy to Clipboard Toggle word wrap

  2. 确定哪个放置组包含 unfound 对象： 

    [ceph: root@host01 /]# ceph health detail
HEALTH_WARN 1 pgs recovering; 1 pgs stuck unclean; recovery 5/937611 objects degraded (0.001%); 1/312537 unfound (0.000%)
pg 3.8a5 is stuck unclean for 803946.712780, current state active+recovering, last acting [320,248,0]
pg 3.8a5 is active+recovering, acting [320,248,0], 1 unfound
recovery 5/937611 objects degraded (0.001%); **1/312537 unfound (0.000%)**
    Copy to Clipboard Toggle word wrap

  3. 列出放置组的更多信息：

    语法

    ceph pg ID query
    Copy to Clipboard Toggle word wrap

    使用包含 unfound 对象的放置组 ID 替换 ID：

    示例

    [ceph: root@host01 /]# ceph pg 3.8a5 query
{ "state": "active+recovering",
  "epoch": 10741,
  "up": [
        320,
        248,
        0],
  "acting": [
        320,
        248,
        0],
<snip>
  "recovery_state": [
        { "name": "Started\/Primary\/Active",
          "enter_time": "2021-08-28 19:30:12.058136",
          "might_have_unfound": [
                { "osd": "0",
                  "status": "already probed"},
                { "osd": "248",
                  "status": "already probed"},
                { "osd": "301",
                  "status": "already probed"},
                { "osd": "362",
                  "status": "already probed"},
                { "osd": "395",
                  "status": "already probed"},
                { "osd": "429",
                  "status": "osd is down"}],
          "recovery_progress": { "backfill_targets": [],
              "waiting_on_backfill": [],
              "last_backfill_started": "0\/\/0\/\/-1",
              "backfill_info": { "begin": "0\/\/0\/\/-1",
                  "end": "0\/\/0\/\/-1",
                  "objects": []},
              "peer_backfill_info": [],
              "backfills_in_flight": [],
              "recovering": [],
              "pg_backend": { "pull_from_peer": [],
                  "pushing": []}},
          "scrub": { "scrubber.epoch_start": "0",
              "scrubber.active": 0,
              "scrubber.block_writes": 0,
              "scrubber.finalizing": 0,
              "scrubber.waiting_on": 0,
              "scrubber.waiting_on_whom": []}},
        { "name": "Started",
          "enter_time": "2021-08-28 19:30:11.044020"}],
    Copy to Clipboard Toggle word wrap

    may _have_unfound 部分包括 Ceph 试图定位 unfound 对象的 OSD：

    • 已探测的 状态表示 Ceph 无法找到该 OSD 中的 unfound 对象。
    • osd 为 down 状态表示 Ceph 无法与该 OSD 联系。
  4. 对标记为 down 的 OSD 进行故障排除。详情请参阅关闭 OSD。
  5. 如果您无法修复导致 OSD 停机 的问题，请创建一个支持问题单。详情请参阅联系红帽支持以获取服务。
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat