8.2. 大多数常见的 Ceph 放置组错误
下表列出了 ceph 健康详情 命令返回的最常见错误消息。这些表中提供了相应部分的链接，这些部分解释了错误并指向修复问题的特定程序。
另外，您可以列出处于非最佳状态的放置组。详情请查看 第 8.3 节 “列出 PG 停留在 stale、inactive 或 unclean 状态”。
8.2.1. 先决条件
- 一个正在运行的 Red Hat Ceph Storage 集群。
- 正在运行的 Ceph 对象网关.
8.2.2. 放置组错误消息
常见放置组错误消息和可能的修复表。
| 错误消息 | 查看 |
|---|---|
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
8.2.3. Stale 放置组
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 处于 stale 状态的时间超过预期，这可能表示这些 PG 的 Primary OSD 为 down 或未向 monitor 报告 PG 统计信息。当存储 过时 PG 的 Primary OSD 备份 后，Ceph 会开始恢复 PG。
mon_osd_report_timeout 设置确定 OSD 将 PG 统计数据报告到 monitor 的频率。默认情况下，此参数设置为 0.5，这表示 OSD 每隔半一次报告统计信息。
要排除这个问题，请执行以下操作
确定哪些 PG 是
过时的，以及它们存储在哪些 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 5 的 管理指南中的 Monitoring Placement Group 设置 小节
8.2.4. Inconsistent placement groups
有些放置组被标记为 active + 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 标记为 inconsistent。最常见的不一致是：
- 对象的大小不正确。
- 恢复完成后，一个副本中的对象会丢失。
在大多数情况下，清理过程中的错误会导致 PG 中不一致。
要排除这个问题，请执行以下操作
登录 Cephadm shell：
示例
[root@host01 ~]# cephadm shell
确定哪个 PG 处于
不一致状态：[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。详情请参阅 修复不一致的 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
其它资源
- 请参阅 Red Hat Ceph Storage 故障排除指南中的 列出放置组不一致。
- 请参阅 Red Hat Ceph Storage Architecture Guide 中的 Ceph data integrity 部分。
- 请参阅 Red Hat Ceph Storage Configuration Guide 中的 Scrubbing the OSD 部分。
8.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 创建三个副本。
通常，unclean 放置组代表某些 OSD 可能处于 down。
要排除这个问题，请执行以下操作
确定哪些 OSD 已
停机：[ceph: root@host01 /]# ceph osd tree
- 对 OSD 进行故障排除和修复任何问题。详情请参阅关闭 OSD。
8.2.6. 不活跃的放置组
ceph health 命令返回类似如下的错误消息：
HEALTH_WARN 197 pgs stuck inactive
此 Means 是什么
如果 PG 在 Ceph 配置文件中的 mon_pg_stuck_threshold 参数中指定的秒数中未激活，Ceph 会将它标记为不活动。mon_pg_stuck_threshold 的默认值为 300 秒。
通常，inactive 放置组代表某些 OSD 可能处于 down。
要排除这个问题，请执行以下操作
确定哪些 OSD 已
停机：# ceph osd tree
- 对 OSD 进行故障排除和修复任何问题。
其它资源
8.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 故障会导致对等故障。
要排除这个问题，请执行以下操作
确定什么阻塞了对等进程：
语法
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 部分包括了为什么对等进程被阻断的信息。
其它资源
- Red Hat Ceph Storage Administration Guide 中的 Ceph OSD peering 部分。
8.2.8. Unfound objects
ceph health 命令返回类似如下的错误消息，其中包含 unfound 关键字：
HEALTH_WARN 1 pgs degraded; 78/3778 unfound (2.065%)
此 Means 是什么
当知道这些对象或它们的较新副本存在但无法找到它们时，Ceph 会将其标记为 unfound。因此，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 正在等待故障节点再次访问，而 未找到的对象 则阻止恢复过程。
要排除这个问题，请执行以下操作
登录 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%)**
列出有关 PG 的更多信息：
语法
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 中的未找到对象。 -
osd is down状态表示 Ceph 无法联系该 OSD。
-
-
对标记为
down的 OSD 进行故障排除。详情请参阅关闭 OSD。 -
如果您无法修复导致 OSD
停机的问题，请打开支持票据。有关 详细信息，请参阅联系红帽支持团队。
