第 7 章 Ceph 放置组故障排除
本节介绍修复与 Ceph 放置组(PG)相关的最常见错误。
先决条件
- 验证您的网络连接。
- 确保 monitor 能够形成仲裁。
-
确保所有健康的 OSD 为
up
和in
,回填和恢复过程已完成。
7.1. 最常见的 Ceph 放置组错误
下表列出了 ceph health detail
命令返回的最常见的错误消息。这些表中提供了相应部分的链接,这些部分解释了错误并指向修复问题的特定程序。
另外,您可以列出处于非最佳状态的放置组。详情请查看 第 7.2 节 “列出放置组处于 过时
、不活动
或未 清除
状态”。
先决条件
- 一个正在运行的 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 的操作集合的 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。
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. 放置组处于 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
停机
的问题,请创建一个支持问题单。详情请参阅联系红帽支持以获取服务。