第 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%
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
ceph df
					如果 %RAW USED 超过 70-75%,您可以:
				
- 删除不必要的数据.这是一个短期解决方案,可以避免生产停机时间。
- 通过添加新 OSD 节点来扩展集群。这是红帽推荐的长期解决方案。
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
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 节点来扩展集群。这是红帽推荐的长期解决方案。
- 为包含 PG 处于 - backfull_toofull的 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 OSDs
					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%这意味着
						当集群达到由 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 在特定节点上使用的空间量。从包含 - nearfullOSD 的节点使用以下命令:- 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这意味着
						由于服务故障或与其他 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: 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 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") - FAILED assert(0 == "hit suicide timeout")- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
- 
									检查对应的日志文件,以确定故障的原因。默认情况下,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 在启用了日志记录到文件后将日志文件存储在 - /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. Fflapping 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 down2022-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)这意味着
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错误信息,请参阅如何排除此问题。- 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 
- 在包含 flapping 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 secs2022-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 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 共享的硬件部分,或者无法对硬件和网络问题进行故障排除和修复,请创建一个支持问题单。详情请参阅联系红帽支持以获取服务。