9.2. 大多数常见的 Ceph 放置组错误

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

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

9.2.1. 先决条件

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

9.2.2. 放置组错误消息

常见放置组错误消息和可能的修复表。

错误消息	请查看
`HEALTH_ERR`
`pgs down`	放置组 `停机`
`pgs inconsistent`	不一致的 PG
`清理错误`	不一致的 PG
`HEALTH_WARN`
`pgs stale`	过时 PG
`未找到`	未找到的对象

9.2.3. 过时 PG

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

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

此 Means 是什么

当 PG 的 Primary OSD 未收到 PG 执行集的 Primary OSD 或其他 OSD 报告Primary OSD 已 停机 时，monitor 会将其标记为 stale。

通常，PG 在启动存储集群后，并在 peering 进程完成前进入 过时的 状态。不过，如果 PG 保留 过时的 时间超过预期，这可能表示这些 PG 的 Primary OSD 已 停机 或未向 monitor 报告 PG 统计信息。当存储 过时 PG 的 Primary OSD 备份 后，Ceph 会开始恢复 PG。

mon_osd_report_timeout 设置确定 OSD 将 PG 统计数据报告到 monitor 的频率。默认情况下，此参数设为 0.5，这表示 OSD 每半秒报告一次统计信息。

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

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

示例

# 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。

其它资源

红帽 Ceph 存储 4 管理指南中 的监控放置组章节

9.2.4. 不一致的 PG

有些放置组被标记为 活跃 + clean + 不一致，ceph 运行状况详细信息 返回类似如下的错误消息：

HEALTH_ERR 1 pgs inconsistent; 2 scrub errors
pg 0.6 is active+clean+inconsistent, acting [0,1,2]
2 scrub errors

此 Means 是什么

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

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

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

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

确定哪个 PG 处于 不一致 状态：

# 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 中启动深度清理过程：

[root@mon ~]# ceph pg deep-scrub ID

使用 不一致的 PG 的 ID 替换 ID，例如：

[root@mon ~]# ceph pg deep-scrub 0.6
instructing pg 0.6 on osd.0 to deep-scrub

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

ceph -w | grep ID

使用 不一致的 PG 的 ID 替换 ID，例如：

[root@mon ~]# 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

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

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
```

其它资源

9.2.5. unclean PG

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

HEALTH_WARN 197 pgs stuck unclean

此 Means 是什么

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

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

通常，未 清理 PG 表示某些 OSD 可能已 停机。

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

确定哪些 OSD 已 停机 ：
```
# ceph osd tree
```
对 OSD 进行故障排除和修复任何问题。详情请参阅 关闭 OSD。

其它资源

列出 PG 停留在 stale notactive 或 unclean 状态。

9.2.6. 不活跃的放置组

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

HEALTH_WARN 197 pgs stuck inactive

此 Means 是什么

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

通常，不活跃的 PG 表示一些 OSD 可能已 停机。

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

确定哪些 OSD 已 停机 ：
```
# ceph osd tree
```
对 OSD 进行故障排除和修复任何问题。

其它资源

列出 PG 处于 stale inactive 或 unclean 状态
详情请参阅 关闭 OSD。

9.2.7. 放置组停机

ceph 运行状况详细信息 命令报告某些 PG 已 停机 ：

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

此 Means 是什么

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

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

确定什么块对等进程：

[root@mon ~]# ceph pg ID query

使用下 线 PG 的 ID 替换 ID，例如：

[root@mon ~]# 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"}
   ]
}

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

如果输出中包含 peering，因为 down osds 错误消息而被阻断，请参见 Down OSD。
如果您看到任何其他错误消息，请打开支持票据。有关详细信息，请参阅 联系红帽支持服务。

其它资源

《 红帽 Ceph 存储管理指南》中的 CephOSD 对等 章节。

9.2.8. 未找到的对象

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

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

此 Means 是什么

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

Situation 示例

PG 将数据存储在 osd.1 和 osd.2 上。

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

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

在这种情景中，Ceph 正在等待故障节点再次访问，而 未找到的对象 则阻止恢复过程。

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

确定哪个 PG 包含 未找到 的对象：

[root@mon ~]# 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%)**

列出有关 PG 的更多信息：

[root@mon ~]# ceph pg ID query

使用包含未找到 对象的 PG 的 ID 替换 ID，例如：

[root@mon ~]# 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"}],

may _have_unfound 部分包括 Ceph 尝试定位 未找到对象的 OSD：

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

对标记为 down 的 OSD 进行故障排除。详情请参阅 关闭 OSD。
如果您无法修复导致 OSD 停机 的问题，请打开支持票据。有关 详细信息，请参阅联系红帽支持团队。

9.2. 大多数常见的 Ceph 放置组错误

9.2.1. 先决条件

9.2.2. 放置组错误消息

9.2.3. 过时 PG

9.2.4. 不一致的 PG

9.2.5. unclean PG

9.2.6. 不活跃的放置组

9.2.7. 放置组停机

9.2.8. 未找到的对象

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links