第 5 章 Ceph OSD 故障排除
本章包含有关如何修复与 Ceph OSD 相关的最常见的错误的信息。
先决条件
- 验证您的网络连接。详情请参阅对网络问题进行故障排除。
-
使用
ceph health
命令验证 monitor 具有仲裁。如果命令返回健康状态(HEALTH_OK
、HEALTH_WARN
或HEALTH_ERR
),则 monitor 能够组成仲裁。如果没有,请首先解决任何 monitor 问题。详情请参阅 Ceph 监控器故障排除。有关ceph 健康
的详细信息,请参阅了解 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%
HEALTH_ERR 1 full osds
osd.3 is full at 95%
这个 Means
Ceph 可防止客户端对完整 OSD 节点执行 I/O 操作,以避免丢失数据。当集群达到 mon_osd_full_ratio
参数设置的容量时,它会返回 HEALTH_ERR full osds
消息。默认情况下,此参数设为 0.95
,这意味着 cluster 容量的 95%。
排除此问题,请执行以下操作
确定使用了多少原始存储(%RAW USED
):
ceph df
ceph df
如果 %RAW USED
高于 70-75%,您可以:
- 删除不必要的数据.这是一个短期解决方案,可避免生产停机时间。
- 通过添加新 OSD 节点来扩展集群。这是红帽推荐的长期解决方案。
5.1.4. backfillfull OSD 复制链接链接已复制到粘贴板!
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
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
ceph df
如果 %RAW USED
高于 70-75%,您可以执行以下操作之一:
- 删除不必要的数据.这是一个短期解决方案,可避免生产停机时间。
- 通过添加新 OSD 节点来扩展集群。这是红帽推荐的长期解决方案。
增加在
backfull_toofull
中包含 PG 的 OSD 的backfillfull
比率,以允许恢复过程继续。尽快向集群添加新存储,或删除数据以防止填充更多 OSD。语法
ceph osd set-backfillfull-ratio VALUE
ceph osd set-backfillfull-ratio VALUE
Copy to Clipboard Copied! Toggle word wrap Toggle overflow VALUE 的范围是 0.0 到 1.0。
示例
[ceph: root@host01/]# ceph osd set-backfillfull-ratio 0.92
[ceph: root@host01/]# ceph osd set-backfillfull-ratio 0.92
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.1.5. nearfull OSD 复制链接链接已复制到粘贴板!
ceph health detail
命令返回类似如下的错误消息:
HEALTH_WARN 1 nearfull osds osd.2 is near full at 85%
HEALTH_WARN 1 nearfull osds
osd.2 is near full at 85%
这个 Means
当集群达到 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
[ceph: root@host01 /]# ceph osd df
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 查看 OSD 在特定节点上使用了多少空间。从包含
nearfull
OSD 的节点使用以下命令:df
df
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 如果需要,添加新的 OSD 节点。
5.1.6. OSD 下线 复制链接链接已复制到粘贴板!
ceph health detail
命令返回类似如下的错误:
HEALTH_WARN 1/3 in osds are down
HEALTH_WARN 1/3 in osds are down
这个 Means
ceph-osd
进程中的一个因为可能的服务故障或与其他 OSD 通信而出现问题。因此,surviving 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: 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
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 尝试重新启动
ceph-osd
守护进程。将 OSD_ID 替换为 down 的 OSD 的 ID:语法
systemctl restart ceph-FSID@osd.OSD_ID
systemctl restart ceph-FSID@osd.OSD_ID
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 示例
systemctl restart ceph-b404c440-9e4c-11ec-a28a-001a4a0001df@osd.0.service
[root@host01 ~]# systemctl restart ceph-b404c440-9e4c-11ec-a28a-001a4a0001df@osd.0.service
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
如果您无法启动
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 密钥环,则无法使用 cephx 进行身份验证
错误消息,则 OSD 缺失的密钥环。 如果您遇到
ERROR: unable to open OSD superblock on /var/lib/ceph/osd/ceph-1
错误信息,ceph-osd
守护进程不能读底层的文件系统。有关如何排除故障并修复此错误的说明,请参阅以下步骤。-
检查对应的日志文件,以确定故障的原因。默认情况下,Ceph 在启用了日志记录到文件后,Ceph 将日志文件存储在
/var/log/ceph/CLUSTER_FSID/
目录中。 -
EIO
错误消息表示底层磁盘失败。若要修复此问题,请替换底层 OSD 磁盘。详情请参阅 替换 OSD 驱动器。 如果日志包含任何其他
FAILED 作为s
ert 错误,如以下错误,请打开一个支持问题单。详情请参阅联系红帽支持团队。FAILED assert(0 == "hit suicide timeout")
FAILED assert(0 == "hit suicide timeout")
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
检查对应的日志文件,以确定故障的原因。默认情况下,Ceph 在启用了日志记录到文件后,Ceph 将日志文件存储在
检查
dmesg
输出是否有底层文件系统或磁盘的错误:dmesg
dmesg
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 类似于以下内容的
错误 -5
错误消息表示底层 XFS 文件系统损坏。如需解决这个问题的信息,请参阅红帽客户门户网站中的 What is the meaning of "xfs_log_force: error -5 returned"?。xfs_log_force: error -5 returned
xfs_log_force: error -5 returned
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
如果
dmesg
输出包含任何SCSI error
错误信息,请参阅红帽客户门户网站中的 SCSI Error Codes Solution Finder 解决方案,以确定解决问题的最佳方法。 - 或者,如果您无法修复底层文件系统,请替换 OSD 驱动器。详情请参阅 替换 OSD 驱动器。
如果 OSD 因分段错误而出现故障,如以下 OSD,请收集必要的信息并创建一个支持问题单。详情请参阅联系红帽支持团队。
Caught signal (Segmentation fault)
Caught signal (Segmentation fault)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ceph-osd
正在运行,但仍标记为 down
检查对应的日志文件,以确定故障的原因。默认情况下,Ceph 在启用了日志记录到文件后,Ceph 将日志文件存储在
/var/log/ceph/CLUSTER_FSID/
目录中。如果日志包含类似于以下的错误消息,请参阅 Flapping OSD。
wrongly marked me down heartbeat_check: no reply from osd.2 since back
wrongly marked me down heartbeat_check: no reply from osd.2 since back
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 如果您看到任何其他错误,请创建一个支持问题单。详情请参阅联系红帽支持团队。
5.1.7. 波动 OSD 复制链接链接已复制到粘贴板!
ceph -w | grep osds
命令重复显示 OSD 为 down
,然后在短时间内再次显示为 up
:
此外,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 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)
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)
这个 Means
大量 OSD 的主要原因包括:
- 某些存储集群操作(如清理或恢复)在具有大型索引或大型放置组的对象上执行这些操作(如清理或恢复)。通常,这些操作完成后,会解决 OSD 问题。
-
与底层物理硬件相关的问题。在这种情况下,
ceph health detail
命令也会返回较慢的请求
错误消息。 - 与网络相关的问题。
Ceph OSD 无法管理存储集群的专用网络出现故障的情况,或者显著延迟位于面向公共客户端的网络上。
Ceph OSD 使用专用网络来互相发送心跳数据包,表示它们为 up
和 in
。如果私有存储集群网络无法正常工作,OSD 无法发送和接收心跳数据包。因此,它们会报告相互 停机
到 Ceph 监控器,同时将自身标记为 up
。
Ceph 配置文件中的以下参数会影响此行为:
参数 | 描述 | 默认值 |
---|---|---|
|
在报告 OSD 为 | 20 秒 |
|
在 Ceph 监控将该 OSD 标记为 | 2 |
下表显示了在默认配置中,Ceph 监控器在只有一个 OSD 三次报告了第一个 OSD 为 down
时,才会将 OSD 标记为 down
。在某些情况下,如果一个主机遇到网络问题,整个集群可能会遇到大量 OSD。这是因为位于主机上的 OSD 会将集群中的其他 OSD 报告为 down
。
波动 OSD 方案不包括 OSD 进程启动时的状态,然后立即终止。
排除此问题,请执行以下操作
再次检查
ceph health detail
命令的输出。如果其中包含slow requests
错误信息,请参阅如何排除此问题。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 确定哪些 OSD 标记为
down
,以及它们所在的节点上:ceph osd tree | grep down
ceph osd tree | grep down
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 在包含流动 OSD 的节点上,对任何网络问题进行故障排除并修复。
或者,您可以通过设置
noup
和nodown
标志来临时强制 Monitor 停止将 OSD 标记为down
和up
:ceph osd set noup ceph osd set nodown
ceph osd set noup ceph osd set nodown
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要使用
noup
和nodown
标志不会修复问题的根本原因,但只会防止 OSD 波动。要创建一个支持问题单,请参阅联系红帽支持部分。
浮动 OSD 可能是 Ceph OSD 节点上的 MTU 错误配置、网络交换机级别或两者导致的。要解决这个问题,请在所有存储集群节点上将 MTU 设置为统一大小,包括在核心上和通过计划停机访问网络交换机。不要调优 osd heartbeat min size
,因为更改此设置可以隐藏网络中的问题,且无法解决实际的网络不一致的问题。
5.1.8. 请求慢或请求被阻塞 复制链接链接已复制到粘贴板!
ceph-osd
守护进程响应请求的速度非常慢,ceph health detail
命令返回类似如下的错误消息:
此外,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-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]
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 6 管理指南中的使用 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 共享的硬件部分,或者无法对硬件和网络问题进行故障排除和修复,请创建一个支持问题单。详情请参阅联系红帽支持以获取服务。