第 5 章 Ceph OSD 故障排除
本章介绍了如何修复与 Ceph OSD 相关的最常见的错误。
先决条件
- 验证您的网络连接。详情请参阅对网络问题进行故障排除。
-
使用
ceph health
命令验证 monitor 具有仲裁。如果命令返回健康状态(HEALTH_OK
、HEALTH_WARN
或HEALTH_ERR
),则 monitor 能够形成仲裁。如果没有,请首先解决任何 monitor 问题。详情请参阅 Ceph Monitor 故障排除。如需有关ceph health
的详细信息,请参阅了解 Ceph 健康状况。 - (可选)停止重新平衡过程,以节省时间和资源。详情请参阅停止和启动重新平衡。
5.1. 最常见的 Ceph OSD 错误
下表列出了 ceph health detail
命令返回的最常见错误消息,或者包含在 Ceph 日志中。这些表中提供了相应部分的链接,这些部分解释了错误并指向修复问题的特定程序。
先决条件
- 对 Ceph OSD 节点的 root 级别访问权限。
5.1.1. Ceph OSD 错误消息
常见 Ceph OSD 错误消息表,以及潜在的修复。
错误消息 | 查看 |
---|---|
| |
| |
| |
| |
| |
| |
| |
|
5.1.2. Ceph 日志中常见的 Ceph OSD 错误消息
Ceph 日志中找到的常见 Ceph OSD 错误消息表,以及到潜在修复的链接。
错误消息 | 日志文件 | 查看 |
---|---|---|
| 主集群日志 | |
| 主集群日志 | |
| 主集群日志 | |
| OSD 日志 |
5.1.3. OSD 已满
ceph health detail
命令返回类似如下的错误消息:
HEALTH_ERR 1 full osds osd.3 is full at 95%
这意味着
Ceph 可防止客户端对完整 OSD 节点执行 I/O 操作,以避免丢失数据。当集群达到由 mon_osd_full_ratio
参数设定的容量时,它会返回 HEALTH_ERR full osds
消息。默认情况下,此参数被设置为 0.95
,即 集群容量的 95%。
要排除此问题,请执行以下操作
确定使用了多少原始存储(%RAW USED
):
ceph df
如果 %RAW USED
超过 70-75%,您可以:
- 删除不必要的数据.这是一个短期解决方案,可以避免生产停机时间。
- 通过添加新 OSD 节点来扩展集群。这是红帽推荐的长期解决方案。
其它资源
- Red Hat Ceph Storage 故障排除指南中的 Nearfull OSDs。
- 详情请参阅从完整存储集群中删除数据。
5.1.4. backfillfull OSDs
ceph health detail
命令返回类似如下的错误消息:
health: HEALTH_WARN 3 backfillfull osd(s) Low space hindering backfill (add storage if this doesn't resolve itself): 32 pgs backfill_toofull
这意味着
当一个或多个 OSD 超过 backfillfull 阈值时,Ceph 会阻止数据重新平衡到这个设备。这是一个早期警告,重新平衡可能无法完成,且集群已接近满。默认的 backfullfull 阈值为 90%。
要排除此问题
检查池的利用率:
ceph df
如果 %RAW USED
超过 70-75%,您可以执行以下操作之一:
- 删除不必要的数据.这是一个短期解决方案,可以避免生产停机时间。
- 通过添加新 OSD 节点来扩展集群。这是红帽推荐的长期解决方案。
为包含 PG 处于
backfull_toofull
的 OSD 增加backfillfull
比率,以允许恢复过程继续。尽快向集群添加新存储,或移除数据以防止填满 OSD。语法
ceph osd set-backfillfull-ratio VALUE
VALUE 的范围为 0.0 到 1.0。
示例
[ceph: root@host01/]# ceph osd set-backfillfull-ratio 0.92
其它资源
- Red Hat Ceph Storage 故障排除指南中的 Nearfull OSDS。
- 详情请参阅从完整存储集群中删除数据。
5.1.5. nearfull OSDs
ceph health detail
命令返回类似如下的错误消息:
HEALTH_WARN 1 nearfull osds osd.2 is near full at 85%
这意味着
当集群达到由 mon osd nearfull ratio defaults
指定的容量时,Ceph 会返回 nearfull osds
信息。默认情况下,此参数设置为 0.85
,这意味着集群容量的 85%。
Ceph 以最佳方式基于 CRUSH 层次结构分发数据,但它不能保证相等的分布。数据分布和 nearfull osds
信息的主要原因包括:
- OSD 在集群中的 OSD 节点之间没有平衡。也就是说,一些 OSD 节点托管的 OSD 比其他 OSD 高得多,或者 CRUSH map 中部分 OSD 的权重不足以满足其容量要求。
- PG 计数与 OSD 数量、用例、每个 OSD 目标 PG 和 OSD 利用率不同。
- 集群使用不正确的 CRUSH 可调项。
- OSD 的后端存储几乎已满。
排除此问题,请执行以下操作:
- 验证 PG 数是否足够,并在需要时增加。
- 验证您使用对集群版本的最佳 CRUSH 可调项,如果不是,则调整它们。
- 根据利用率更改 OSD 的权重。
确定 OSD 使用的磁盘上保留多少空间。
查看 OSD 一般使用的空间量:
[ceph: root@host01 /]# ceph osd df
查看 OSD 在特定节点上使用的空间量。从包含
nearfull
OSD 的节点使用以下命令:df
- 如果需要,添加新 OSD 节点。
其它资源
- OSD 已满
- 请参阅 Red Hat Ceph Storage 7 的存储策略指南中的 Set a OSD 的 Weight by Utilization 部分。
- 详情请参阅 Red Hat Ceph Storage 7 的存储策略指南中的 CRUSH Tunables 部分,以及如何 测试 CRUSH map 可调整的影响 CRUSH map 可跨 OSD 在 Red Hat Ceph Storage 的 Red Hat Ceph Storage? 解决方案上进行 PG 分发 部分。
- 详情请参阅 增加放置组。
5.1.6. OSD 下线
ceph health detail
命令返回类似如下的错误:
HEALTH_WARN 1/3 in osds are down
这意味着
由于服务故障或与其他 OSD 通信存在问题,其中一个 ceph-osd
进程不可用。因此,存活 ceph-osd
守护进程会向 monitor 报告这个失败。
如果 ceph-osd
守护进程未在运行,则代表底层 OSD 驱动器或文件系统已损坏,或者存在一些其他错误(如缺少密钥环)阻止守护进程启动。
在大多数情况下,网络问题会导致在 ceph-osd
守护进程运行时,仍标记为 down
的情况。
要排除此问题,请执行以下操作
确定哪个 OSD 为
down
:[ceph: root@host01 /]# ceph health detail HEALTH_WARN 1/3 in osds are down osd.0 is down since epoch 23, last address 192.168.106.220:6800/11080
尝试重启
ceph-osd
守护进程。将 OSD_ID 替换为 down 的 OSD 的 ID:语法
systemctl restart ceph-FSID@osd.OSD_ID
示例
[root@host01 ~]# systemctl restart ceph-b404c440-9e4c-11ec-a28a-001a4a0001df@osd.0.service
-
如果您无法启动
ceph-osd
,请按照ceph-osd
守护进程中的步骤启动。 -
如果您能够启动
ceph-osd
守护进程,但它标记为down
,请按照ceph-osd
守护进程运行 中的步骤,但仍然标记为"down "。
-
如果您无法启动
ceph-osd
守护进程无法启动
- 如果您的节点包含多个 OSD(通常超过 12 倍),请验证默认最多线程数(PID 数)是否足够。详情请参阅 增加 PID 计数。
-
验证 OSD 数据和日志分区是否已正确挂载。您可以使用
ceph-volume lvm list
命令列出与 Ceph Storage 集群关联的所有设备和卷,然后手动检查是否正确挂载它们。详情请查看mount (8)
手册页。 -
如果您遇到
ERROR: missing keyring,则无法将 cephx 用于身份验证
错误消息,则 OSD 是缺少的密钥环。 如果您遇到
ERROR: unable to open OSD superblock on /var/lib/ceph/osd/ceph-1
错误信息,ceph-osd
守护进程不能读底层的文件系统。有关如何排除故障并修复此错误的说明,请参阅以下步骤。-
检查对应的日志文件,以确定故障的原因。默认情况下,Ceph 在启用了日志记录到文件后将日志文件存储在
/var/log/ceph/CLUSTER_FSID/
目录中。 -
EIO
错误消息表示底层磁盘失败。若要修复此问题,可替换底层 OSD 磁盘。详情请参阅 替换 OSD 驱动器。 如果日志包含任何其他
FAILED assert
错误,如以下错误,请创建一个支持问题单。详情请参阅联系红帽支持以获取服务。FAILED assert(0 == "hit suicide timeout")
-
检查对应的日志文件,以确定故障的原因。默认情况下,Ceph 在启用了日志记录到文件后将日志文件存储在
检查
dmesg
输出是否有底层文件系统或磁盘的错误:dmesg
类似于以下内容的错误 -5
错误消息表示底层 XFS 文件系统崩溃。如需解决这个问题的信息,请参阅红帽客户门户网站中的 What is the meaning of "xfs_log_force: error -5 returned"?。xfs_log_force: error -5 returned
-
如果
dmesg
输出包含任何SCSI error
错误信息,请参阅红帽客户门户网站中的 SCSI Error Codes Solution Finder 解决方案,以确定解决问题的最佳方法。 - 或者,如果您无法修复底层文件系统,请替换 OSD 驱动器。详情请参阅 替换 OSD 驱动器。
如果 OSD 因分段错误而出现故障,如以下 OSD,请收集必要的信息并创建一个支持问题单。详情请参阅联系红帽支持以获取服务。
Caught signal (Segmentation fault)
ceph-osd
正在运行,但仍标记为 down
检查对应的日志文件,以确定故障的原因。默认情况下,Ceph 在启用了日志记录到文件后将日志文件存储在
/var/log/ceph/CLUSTER_FSID/
目录中。如果日志包含与以下类似的错误消息,请参阅 Flapping OSD。
wrongly marked me down heartbeat_check: no reply from osd.2 since back
- 如果您看到任何其他错误,请创建一个支持问题单。详情请参阅联系红帽支持以获取服务。
其它资源
- Fflapping OSD
- Stale 放置组
- 请参阅 Ceph 守护进程日志,以启用日志记录到文件。
5.1.7. Fflapping OSD
ceph -w | grep osds
命令重复显示 OSD 为 down
,然后在短时间内再次显示为 up
:
ceph -w | grep osds 2022-05-05 06:27:20.810535 mon.0 [INF] osdmap e609: 9 osds: 8 up, 9 in 2022-05-05 06:27:24.120611 mon.0 [INF] osdmap e611: 9 osds: 7 up, 9 in 2022-05-05 06:27:25.975622 mon.0 [INF] HEALTH_WARN; 118 pgs stale; 2/9 in osds are down 2022-05-05 06:27:27.489790 mon.0 [INF] osdmap e614: 9 osds: 6 up, 9 in 2022-05-05 06:27:36.540000 mon.0 [INF] osdmap e616: 9 osds: 7 up, 9 in 2022-05-05 06:27:39.681913 mon.0 [INF] osdmap e618: 9 osds: 8 up, 9 in 2022-05-05 06:27:43.269401 mon.0 [INF] osdmap e620: 9 osds: 9 up, 9 in 2022-05-05 06:27:54.884426 mon.0 [INF] osdmap e622: 9 osds: 8 up, 9 in 2022-05-05 06:27:57.398706 mon.0 [INF] osdmap e624: 9 osds: 7 up, 9 in 2022-05-05 06:27:59.669841 mon.0 [INF] osdmap e625: 9 osds: 6 up, 9 in 2022-05-05 06:28:07.043677 mon.0 [INF] osdmap e628: 9 osds: 7 up, 9 in 2022-05-05 06:28:10.512331 mon.0 [INF] osdmap e630: 9 osds: 8 up, 9 in 2022-05-05 06:28:12.670923 mon.0 [INF] osdmap e631: 9 osds: 9 up, 9 in
此外,Ceph 日志包含类似以下的错误消息:
2022-05-25 03:44:06.510583 osd.50 127.0.0.1:6801/149046 18992 : cluster [WRN] map e600547 wrongly marked me down
2022-05-25 19:00:08.906864 7fa2a0033700 -1 osd.254 609110 heartbeat_check: no reply from osd.2 since back 2021-07-25 19:00:07.444113 front 2021-07-25 18:59:48.311935 (cutoff 2021-07-25 18:59:48.906862)
这意味着
flapping OSD 的主要原因包括:
- 某些存储集群操作(如清理或恢复)在具有大型索引或大型放置组的对象上执行这些操作时(例如,需要一定时间)。通常,这些操作完成后,flapping OSD 问题会解决。
-
底层物理硬件的问题。在本例中,
ceph health detail
命令也会返回slow requests
错误信息。 - 与网络相关的问题。
Ceph OSD 无法管理存储集群的专用网络出现故障的情况,或者显著延迟位于面向公共客户端的网络上。
Ceph OSD 使用专用网络在彼此间发送心跳数据包,以代表它们处于 up
和 in
状态。如果私有存储集群网络无法正常工作,OSD 无法发送和接收 heartbeat 数据包。因此,它们会将彼此报告为 down
到 Ceph 监控器,同时将自身标记为 up
。
Ceph 配置文件中的以下参数会影响此行为:
参数 | 描述 | 默认值 |
---|---|---|
|
在将 OSD 报告为 | 20 秒 |
|
在 Ceph 监控将该 OSD 标记为 | 2 |
下表显示了在默认配置中,Ceph 监控器在只有一个 OSD 三次报告了第一个 OSD 为 down
时,才会将 OSD 标记为 down
。在某些情况下,如果一个主机遇到网络问题,整个集群可能会遇到流化 OSD。这是因为主机上的 OSD 将报告集群中的其他 OSD 为 down
。
flapping OSD 方案不包括在 OSD 进程启动时的情况,然后立即终止。
要排除此问题,请执行以下操作
再次检查
ceph health detail
命令的输出。如果其中包含slow requests
错误信息,请参阅如何排除此问题。ceph health detail HEALTH_WARN 30 requests are blocked > 32 sec; 3 osds have slow requests 30 ops are blocked > 268435 sec 1 ops are blocked > 268435 sec on osd.11 1 ops are blocked > 268435 sec on osd.18 28 ops are blocked > 268435 sec on osd.39 3 osds have slow requests
确定哪些 OSD 标记为
down
,以及它们所在的节点上:ceph osd tree | grep down
- 在包含 flapping OSD 的节点上,对任何网络问题进行故障排除并修复。
或者,您可以通过设置
noup
和nodown
标记,临时强制 monitor 停止将 OSD 标记为down
和up
:ceph osd set noup ceph osd set nodown
重要使用
noup
和nodown
标志不会修复问题的根本原因,而是只防止 OSD 出现问题。要创建一个支持问题单,请参阅联系红帽支持部分。
扁平化 OSD 可能是由 Ceph OSD 节点上的 MTU 错误配置、网络交换机级别或两者导致的。要解决这个问题,请在所有存储集群节点上将 MTU 设置为统一大小,包括在核心上和通过计划停机访问网络交换机。不要调整 osd heartbeat min size
,因为更改此设置可能会隐藏网络中的问题,且无法解决实际网络不一致的问题。
其它资源
- 请参阅 Red Hat Ceph Storage Architecture Guide 中的 Ceph heartbeat 部分。
- 请参阅 Red Hat Ceph Storage 故障排除指南中的 请求较慢或请求被阻塞部分。
5.1.8. 请求慢或请求被阻塞
ceph-osd
守护进程响应请求的速度非常慢,ceph health detail
命令返回类似如下的错误消息:
HEALTH_WARN 30 requests are blocked > 32 sec; 3 osds have slow requests 30 ops are blocked > 268435 sec 1 ops are blocked > 268435 sec on osd.11 1 ops are blocked > 268435 sec on osd.18 28 ops are blocked > 268435 sec on osd.39 3 osds have slow requests
此外,Ceph 日志包含类似于以下的错误消息:
2022-05-24 13:18:10.024659 osd.1 127.0.0.1:6812/3032 9 : cluster [WRN] 6 slow requests, 6 included below; oldest blocked for > 61.758455 secs
2022-05-25 03:44:06.510583 osd.50 [WRN] slow request 30.005692 seconds old, received at {date-time}: osd_op(client.4240.0:8 benchmark_data_ceph-1_39426_object7 [write 0~4194304] 0.69848840) v4 currently waiting for subops from [610]
这意味着
请求速度较慢的 OSD 是每个无法在 osd_op_complaint_time
参数定义的时间内队列中每秒 I/O 操作(IOPS)服务的 OSD。默认情况下,此参数被设置为 30 秒。
造成 OSD 请求缓慢的主要原因包括:
- 底层硬件的问题,如磁盘驱动器、主机、机架或网络交换机
- 与网络相关的问题。这些问题通常与 flapping OSD 相关。详情请参阅 Flapping OSD。
- 系统负载
下表显示了较慢请求的类型。使用 dump_historic_ops
管理套接字命令确定较慢请求的类型。有关管理套接字的详细信息,请参阅 Red Hat Ceph Storage 7 管理指南中的使用 Ceph 管理套接字一节。
慢速请求类型 | 描述 |
---|---|
| OSD 正在等待在 PG 上获取操作的锁定。 |
| OSD 正在等待副本 OSD 将操作应用到日志。 |
| OSD 无法到达任何主要的操作里程碑。 |
| OSD 尚未复制一个对象的指定次数。 |
要排除此问题,请执行以下操作
- 确定具有缓慢或块请求的 OSD 是否共享一个通用的硬件,如磁盘驱动器、主机、机架或网络交换机。
如果 OSD 共享一个磁盘:
使用
smartmontools
工具检查磁盘的健康状态或日志来确定磁盘上的任何错误。注意smartmontools
工具包含在smartmontools
软件包中。使用
iostat
实用程序获取 OSD 磁盘上的 I/O 等待报告 (%iowai
),以确定磁盘是否负载过重。注意iostat
实用程序包含在sysstat
软件包中。
如果 OSD 与另一个服务共享节点:
- 检查 RAM 和 CPU 使用率
-
使用
netstat
工具查看网络接口控制器(NIC) 上的网络统计信息,并对任何网络问题进行故障排除。
- 如果 OSD 共享一个机架,请检查机架的网络交换机。例如,如果您使用巨型帧,请验证路径中的 NIC 是否已设置了巨型帧。
- 如果您无法确定请求速度较慢的 OSD 共享的硬件部分,或者无法对硬件和网络问题进行故障排除和修复,请创建一个支持问题单。详情请参阅联系红帽支持以获取服务。
其它资源
- 详情请参阅 Red Hat Ceph Storage Administration Guide 中的 Using the Ceph Administration Socket 部分。