第 7 章 Ceph 放置组故障排除

PDF

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

先决条件

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

7.1. 最常见的 Ceph 放置组错误

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

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

先决条件

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

7.1.1. 放置组错误消息

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

错误消息	查看
`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

这意味着

当放置组没有从 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 每半年报告统计数据。

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

识别哪些 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

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

其它资源

Red Hat Ceph Storage 7 管理指南中的 监控放置组设置 部分

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

这意味着

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

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

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

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

登录到 Cephadm shell：
示例
```
[root@host01 ~]# cephadm shell
```

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

[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

确定 PG 不一致 的原因。

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

语法

ceph pg deep-scrub ID

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

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

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

语法

ceph -w | grep ID

使用 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

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

语法

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

如果输出包含与以下类似的错误消息，则无法安全地修复不一致的 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
```

其它资源

请参阅 Red Hat Ceph Storage 故障排除指南中的 列出放置组不一致的情况。
请参阅 Red Hat Ceph Storage Architecture Guide 中的 Ceph data integrity 部分。
详情请参阅 Red Hat Ceph Storage 配置指南中的清理 OSD 部分。

7.1.4. unclean PG

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

HEALTH_WARN 197 pgs stuck unclean

这意味着

如果 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: root@host01 /]# ceph osd tree
```
故障排除和修复与 OSD 相关的问题。详情请参阅关闭 OSD。

其它资源

列出放置组处于 stale inactive 或 unclean 状态。

7.1.5. 不活跃的放置组

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

HEALTH_WARN 197 pgs stuck inactive

这意味着

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

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

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

确定哪些 OSD 为 down ：
```
# ceph osd tree
```
故障排除和修复与 OSD 相关的问题。

其它资源

列出放置组处于 stale inactive 或 unclean 状态
详情请参阅关闭 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

这意味着

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

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

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

语法

ceph pg ID query

将 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"}
   ]
}

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

如果输出包含 peering is blocked due due due dueing osds 错误消息，请参阅 Down OSDs。
如果您看到任何其他错误消息，请创建一个支持问题单。详情请参阅联系红帽支持服务。

其它资源

Red Hat Ceph Storage Administration Guide 中的 Ceph OSD peering 部分。

7.1.7. Unfound objects

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

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

这意味着

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

Situation 示例

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

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

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

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

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

登录到 Cephadm shell：
示例
```
[root@host01 ~]# cephadm shell
```

确定哪个放置组包含 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%)**

列出放置组的更多信息：

语法

ceph pg ID query

使用包含 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"}],

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

已探测的 状态表示 Ceph 无法找到该 OSD 中的 unfound 对象。
osd 为 down 状态表示 Ceph 无法与该 OSD 联系。

对标记为 down 的 OSD 进行故障排除。详情请参阅关闭 OSD。
如果您无法修复导致 OSD 停机 的问题，请创建一个支持问题单。详情请参阅联系红帽支持以获取服务。

第 7 章 Ceph 放置组故障排除

7.1. 最常见的 Ceph 放置组错误

7.1.1. 放置组错误消息

7.1.2. Stale 放置组

7.1.3. Inconsistent placement groups

7.1.4. unclean PG

7.1.5. 不活跃的放置组

7.1.6. 放置组处于 down 状态

7.1.7. Unfound objects

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links