第 7 章 PG 故障排除

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

开始前

验证您的网络连接。详情请查看第 3 章 网络问题故障排除。
确保 monitor 能够形成仲裁。有关排除与 monitor 相关的大多数常见错误的详情，请查看第 4 章 监控器故障排除。
确保所有健康的 OSD 都是 up 和 in，并且回填和恢复过程已完成。有关对 OSD 的最常见错误进行故障排除的详细信息，请参阅第 5 章 OSD 故障排除。

7.1. 与放置组相关的大多数通用错误信息
复制链接

下表列出了 ceph health detail 命令返回的最常见错误信息。下表提供了解释错误并指向解决问题的具体步骤的对应部分的链接。

另外，您可以列出处于非最佳状态的放置组。详情请查看第 7.2 节 “列出 stale、inactive 或 unclean 状态中的 PG”。

Expand

表 7.1. 与 PG 相关的错误消息
错误消息	请查看
`HEALTH_ERR`
`pgs down`	第 7.1.5 节 “放置组 Are `down`”
`pgs inconsistent`	第 7.1.2 节 “放置组不一致”
`scrub errors`	第 7.1.2 节 “放置组不一致”
`HEALTH_WARN`
`pgs stale`	第 7.1.1 节 “过时的 PG”
`unfound`	第 7.1.6 节 “未找到的对象”

7.1.1. 过时的 PG
复制链接

ceph health 命令列出了一些 PG(PG)作为 stale:

HEALTH_WARN 24 pgs stale; 3/300 in osds are down

HEALTH_WARN 24 pgs stale; 3/300 in osds are down

Copy to Clipboard

Toggle word wrap

此 Means 是什么

当 PG 没有从 PG 操作集的 Primary OSD 收到任何状态更新时，或其它 OSD 报告Primary OSD 为 down 时，monitor 会将其标记为 stale。

通常，PG 在启动存储集群后进入 stale 状态，直到对等过程完成为止。但是，当 PG 保留 stale 的时间超过预期时，可能会指出这些 PG 的 Primary OSD 为 down，或不向 monitor 报告 PG 统计信息。当存储 stale PG 的 Primary OSD 返回 up 时，Ceph 会开始恢复 PG。

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

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

确定哪些 PG 是 stale，以及它们存储在哪些 OSD 上。错误消息将包含类似以下示例的信息：

ceph health detail

# 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

对标记为 down 的 OSD 的所有问题进行故障排除。详情请查看第 5.1.3 节 “个或更多 OSD 发生故障”。

另请参阅

红帽 Ceph 存储 3 管理指南 中的 {administration-guide}#identify_troubled_placement_groups[监控放置组状态]部分

7.1.2. 放置组不一致
复制链接

有些放置组被标记为 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

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

此 Means 是什么

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

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

在大多数情况下，清理过程中的错误会导致 PG 中不一致。

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

确定处于 inconsistent 状态的 PG:

ceph health detail

# 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

确定放置组为 inconsistent 的原因。
1. 在 PG 中启动深度清理过程：
  ceph pg deep-scrub <id>
  Copy to Clipboard Toggle word wrap
  使用 inconsistent 放置组的 ID 替换 <id>，例如：
  # 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 放置组的 ID 替换 <id>，例如：
  # ceph -w | grep 0.6 2015-02-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. 2015-02-26 01:35:36.788334 osd.106 [ERR] 0.6 deep-scrub 1 errors
  Copy to Clipboard Toggle word wrap

如果输出包含类似以下的错误消息，您可以修复 inconsistent 放置组。详情请查看第 7.4 节 “修复事件 PG”。

<pg.id> shard <osd>: soid <object> missing attr _, missing attr <attr 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>

<pg.id> shard <osd>: soid <object> missing attr _, missing attr <attr 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

如果输出包含类似以下的错误消息，则无法安全地修复 inconsistent 放置组，因为您可以丢失数据。在这种情况下创建一个支持问题单。详情请查看第 9 章 联系红帽支持服务。

<pg.id> shard <osd>: soid <object> digest <digest> != known digest <digest>
<pg.id> shard <osd>: soid <object> omap_digest <digest> != known omap_digest <digest>

<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.4 节 “修复事件 PG”
第 7.3 节 “列出清单”
红帽 Ceph 存储 3 架构指南 中的 确保数据完整性一节
Red Hat Ceph Storage 3 配置指南中 的清理部分

7.1.3. unclean Placement Groups
复制链接

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

HEALTH_WARN 197 pgs stuck unclean

HEALTH_WARN 197 pgs stuck unclean

Copy to Clipboard

Toggle word wrap

此 Means 是什么

如果 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。

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

确定哪些 OSD 为 down:
```
ceph osd tree
```
```
# ceph osd tree
```
Copy to Clipboard Toggle word wrap
对 OSD 进行故障排除和修复任何问题。详情请查看第 5.1.3 节 “个或更多 OSD 发生故障”。

另请参阅

第 7.2 节 “列出 stale、inactive 或 unclean 状态中的 PG”

7.1.4. 不活跃的 PG
复制链接

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

HEALTH_WARN 197 pgs stuck inactive

HEALTH_WARN 197 pgs stuck inactive

Copy to Clipboard

Toggle word wrap

此 Means 是什么

如果 PG 未在 Ceph 配置文件中的 mon_pg_stuck_threshold 参数中指定的秒数内指定，Ceph 会将其标记为 inactive。mon_pg_stuck_threshold 的默认值是 300 秒。

通常，inactive 放置组表示某些 OSD 可能为 down。

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

确定哪些 OSD 为 down:
```
ceph osd tree
```
```
# ceph osd tree
```
Copy to Clipboard Toggle word wrap
对 OSD 进行故障排除和修复任何问题。详情请查看第 5.1.3 节 “个或更多 OSD 发生故障”。

另请参阅

第 7.2 节 “列出 stale、inactive 或 unclean 状态中的 PG”

7.1.5. 放置组 Are down
复制链接

ceph health detail 命令报告一些放置组为 down ：

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

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

此 Means 是什么

在某些情况下，peering 进程会被阻止，这会阻止放置组变得活跃且可用。通常，OSD 故障会导致对等故障。

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

确定什么块对等进程：

ceph pg <id> query

ceph pg <id> query

Copy to Clipboard

Toggle word wrap

使用 down 的 PG ID 替换 <id>，例如：

ceph pg 0.5 query

# ceph pg 0.5 query

{ "state": "down+peering",
  ...
  "recovery_state": [
       { "name": "Started\/Primary\/Peering\/GetInfo",
         "enter_time": "2012-03-06 14:40:16.169679",
         "requested_info_from": []},
       { "name": "Started\/Primary\/Peering",
         "enter_time": "2012-03-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": "2012-03-06 14:40:16.169513"}
   ]
}

Copy to Clipboard

Toggle word wrap

recovery_state 部分包含对等进程被阻止的信息。

如果输出中包含 peering is blocked due to down osds 错误消息，请参阅第 5.1.3 节 “个或更多 OSD 发生故障”。
如果您看到任何其他错误消息，请打开支持票据。详情请查看第 9 章 联系红帽支持服务。

另请参阅

Red Hat Ceph Storage 3 管理指南 中的 Peering 部分

7.1.6. 未找到的对象
复制链接

ceph health 命令返回类似以下示例的错误消息，包含 unfound 关键字：

HEALTH_WARN 1 pgs degraded; 78/3778 unfound (2.065%)

HEALTH_WARN 1 pgs degraded; 78/3778 unfound (2.065%)

Copy to Clipboard

Toggle word wrap

此 Means 是什么

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

Situation 示例

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

osd.1 进入 down。
osd.2 处理一些写入操作。
osd.1 发送至 up。
osd.1 和 osd.2 之间的对等进程启动，osd.1 中缺少的对象排队以进行恢复。
在 Ceph 复制新对象之前，osd.2 转到 down。

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

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

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

确定哪个 PG 包含 unfound 对象：

ceph health detail

# 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

列出有关 PG 的更多信息：

ceph pg <id> query

# ceph pg <id> query

Copy to Clipboard

Toggle word wrap

使用包含 unfound 对象的 PG 的 ID 替换 <id>，例如：

ceph pg 3.8a5 query

# 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": "2015-01-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": "2015-01-28 19:30:11.044020"}],

Copy to Clipboard

Toggle word wrap

might_have_unfound 部分包含 Ceph 尝试查找 unfound 对象的 OSD：

already probed 状态表示 Ceph 无法找到该 OSD 中的 unfound 对象。
osd is down 状态表示 Ceph 无法联系该 OSD。

对标记为 down 的 OSD 进行故障排除。详情请查看第 5.1.3 节 “个或更多 OSD 发生故障”。
如果您无法修复导致 OSD 成为 down 的问题，请打开支持票据。详情请查看第 9 章 联系红帽支持服务。

第 7 章 PG 故障排除

开始前

7.1. 与放置组相关的大多数通用错误信息
复制链接

7.1.1. 过时的 PG
复制链接

此 Means 是什么

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

另请参阅

7.1.2. 放置组不一致
复制链接

此 Means 是什么

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

另请参阅

7.1.3. unclean Placement Groups
复制链接

此 Means 是什么

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

另请参阅

7.1.4. 不活跃的 PG
复制链接

此 Means 是什么

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

另请参阅

7.1.5. 放置组 Are down
复制链接

此 Means 是什么

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

另请参阅

7.1.6. 未找到的对象
复制链接

此 Means 是什么

Situation 示例

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

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

第 7 章 PG 故障排除

开始前

7.1. 与放置组相关的大多数通用错误信息复制链接链接已复制到粘贴板!

7.1.1. 过时的 PG复制链接链接已复制到粘贴板!

此 Means 是什么

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

另请参阅

7.1.2. 放置组不一致复制链接链接已复制到粘贴板!

此 Means 是什么

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

另请参阅

7.1.3. unclean Placement Groups复制链接链接已复制到粘贴板!

此 Means 是什么

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

另请参阅

7.1.4. 不活跃的 PG复制链接链接已复制到粘贴板!

此 Means 是什么

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

另请参阅

7.1.5. 放置组 Are down复制链接链接已复制到粘贴板!

此 Means 是什么

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

另请参阅

7.1.6. 未找到的对象复制链接链接已复制到粘贴板!

此 Means 是什么

Situation 示例

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

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

7.1. 与放置组相关的大多数通用错误信息
复制链接

7.1.1. 过时的 PG
复制链接

7.1.2. 放置组不一致
复制链接

7.1.3. unclean Placement Groups
复制链接

7.1.4. 不活跃的 PG
复制链接

7.1.5. 放置组 Are down
复制链接

7.1.6. 未找到的对象
复制链接