第 7 章 Ceph 放置组故障排除
本节介绍修复与 Ceph 放置组(PG)相关的最常见错误。
先决条件
- 验证您的网络连接。
- 确保 monitor 能够形成仲裁。
-
确保所有健康的 OSD 为
up和in，回填和恢复过程已完成。
7.1. 最常见的 Ceph 放置组错误
下表列出了 ceph health detail 命令返回的最常见的错误消息。这些表中提供了相应部分的链接，这些部分解释了错误并指向修复问题的特定程序。
另外，您可以列出处于不最佳状态的放置组。详情请查看 第 7.2 节 “列出放置组处于 stale、active 或 unclean 状态”。
先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 正在运行的 Ceph 对象网关.
7.1.1. 放置组错误消息
常见放置组错误消息和潜在的修复表。
| 错误消息 | 查看 |
|---|---|
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
7.1.2. Stale 放置组
ceph health 命令将一些放置组 (PG) 列为 stale ：
HEALTH_WARN 24 pgs stale; 3/300 in osds are down
这意味着
当 PG 没有从 PG 活跃集合的 Primary OSD 接收任何状态更新时，monitor 会将放置组标记为 stale，或者当其他 OSD 报告 Primary OSD 为 down 时。
通常，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 8 管理指南中的 监控放置组设置 部分
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 中启动深度清理过程：
语法
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 Troubleshooting Guide 中的 列出放置组不一致 的内容。
- 请参阅 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 秒。
如果 PG 为 unclean，它包含没有复制 osd_pool_default_size 参数中指定的时间的对象。osd_pool_default_size 的默认值为 3，这意味着 Ceph 会创建三个副本。
通常，unclean 放置组代表某些 OSD 可能处于 down。
要排除此问题，请执行以下操作
确定哪些 OSD 为
down：[ceph: root@host01 /]# ceph osd tree
- 对 OSD 进行故障排除并修复任何问题。详情请参阅 关闭 OSD。
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 进行故障排除并修复任何问题。
其它资源
7.1.6. 放置组已停机
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
使用 停机 的 PG 的 ID 替换 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 进程被阻止的信息。
-
如果输出包含
因为 osds 错误消息而被阻止的 peering，请参阅 故障 OSD。 - 如果您看到任何其他错误消息，请创建一个支持问题单。详情请参阅联系红帽支持服务。
其它资源
- 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 正在等待故障节点再次访问，未找到 的对象会阻止恢复过程。
要排除此问题，请执行以下操作
登录到 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对象的 PG 的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 试图找到未找到对象的 OSD：-
已探测的状态表示 Ceph 无法在该 OSD 中找到unfound对象。 -
osd is down状态表示 Ceph 无法联系该 OSD。
-
-
对标记为
down的 OSD 进行故障排除。详情请参阅 关闭 OSD。 -
如果您无法修复导致 OSD
停机的问题，请创建一个支持问题单。详情请参阅联系红帽支持以获取服务。
