5.2. 大多数常见 Ceph OSD 错误
下表列出了 ceph 运行状况详细信息 命令返回或包含在 Ceph 日志中的最常见错误消息:这些表中提供了相应部分的链接,这些部分解释了错误并指向修复问题的特定程序。
5.2.1. 先决条件 复制链接链接已复制到粘贴板!
- 对 Ceph OSD 节点的根级别访问权限.
5.2.2. Ceph OSD 错误消息 复制链接链接已复制到粘贴板!
常见 Ceph OSD 错误消息和可能的修复表。
| 错误消息 | 查看 |
|---|---|
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
5.2.3. Ceph 日志中的常见 Ceph OSD 错误消息 复制链接链接已复制到粘贴板!
Ceph 日志中常见 Ceph OSD 错误消息的列表,以及可能的修复链接。
| 错误消息 | 日志文件 | 查看 |
|---|---|---|
|
| 主集群日志 | |
|
| 主集群日志 | |
|
| 主集群日志 | |
|
| OSD 日志 |
5.2.4. OSD 已满 复制链接链接已复制到粘贴板!
ceph 运行状况详情 命令返回类似如下的错误消息:
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,即集群容量的 95%。
要排除这个问题,请执行以下操作
确定使用原始存储的百分比(%RAW USED):
ceph df
如果 %RAW USED 超过 70-75%,您可以:
- 删除不必要的数据.这是避免生产停机时间的短期解决方案。
- 通过添加新 OSD 节点来扩展集群。这是红帽推荐的长期解决方案。
5.2.5. backfillfull OSD 复制链接链接已复制到粘贴板!
ceph 运行状况详情 命令返回类似如下的错误消息:
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 节点来扩展集群。这是红帽推荐的长期解决方案。
增加在
backfull_toofull中包含 PG 的 OSD 的backfillfull比率,以允许恢复过程继续。尽快向集群添加新存储,或删除数据以防止填充更多 OSD。语法
ceph osd set-backfillfull-ratio VALUEVALUE 的范围是 0.0 到 1.0。
示例
[ceph: root@host01/]# ceph osd set-backfillfull-ratio 0.92
5.2.6. nearfull OSD 复制链接链接已复制到粘贴板!
ceph 运行状况详情 命令返回类似如下的错误消息:
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 tree在检查大多数使用哪些 OSD (full/nearfull)后,查看将哪个磁盘用作 OSD 的底层磁盘。登录到包含 nearfull OSD 的节点,并运行以下命令:
[ceph: root@host01 /]# cephadm shell [ceph: root@host01 /]# ceph-volume lvm list查看集群中存在的池列表:
[ceph: root@host01 /]# ceph df- 如果需要,添加新 OSD 节点。
5.2.7. OSD 下线 复制链接链接已复制到粘贴板!
ceph 健康状况详情 命令返回类似如下的错误:
HEALTH_WARN 1/3 in osds are down
此 Means 是什么
由于服务故障或与其他 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 存储群集关联的所有设备和卷,然后手动检查它们是否已正确挂载。详情请查看mount(8)手册页。 -
如果您收到错误
的密钥环:缺少密钥环,无法使用 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 assert错误,如以下错误,请打开支持票据。有关 详细信息,请参阅联系红帽支持团队。FAILED assert(0 == "hit suicide timeout")
-
检查对应的日志文件,以确定故障的原因。默认情况下,Ceph 在启用了日志记录到文件后,Ceph 将日志文件存储在
检查
dmesg输出是否有底层文件系统或磁盘的错误:dmesg-
如果
dmesg输出包含任何SCSI error错误信息,请参阅红帽客户门户网站中的 SCSI Error Codes Solution Finder 解决方案,以确定解决问题的最佳方法。 - 或者,如果您无法修复底层文件系统,请替换 OSD 驱动器。详情请参阅 替换 OSD 驱动器。
-
如果
如果 OSD 因分段错误而出现故障,如以下 OSD,请收集必要的信息并创建一个支持问题单。有关 详细信息,请参阅联系红帽支持团队。
Caught signal (Segmentation fault)
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- 如果您看到任何其他错误,请打开支持票据。有关 详细信息,请参阅联系红帽支持团队。
5.2.8. Flapping OSD 复制链接链接已复制到粘贴板!
ceph -w | grep osds 命令显示 OSD 重复为 down,然后在短时间内 再次运行 :
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)
此 Means 是什么
引发 OSD 的主要原因是:
- 某些存储集群操作(如清理或恢复)需要大量时间,例如,如果您在具有大型索引或大型放置组的对象上执行这些操作。通常,在完成这些操作后,flapping OSD 问题会得到解决。
-
与底层物理硬件相关的问题.在本例中,
ceph health detail命令也会返回slow requests错误信息。 - 与网络相关的问题。
Ceph OSD 无法管理存储集群的专用网络出现故障的情况,或者显著延迟位于面向公共客户端的网络上。
Ceph OSD 使用专用网络在彼此间发送心跳数据包,以代表它们处于 up 和 in 状态。如果私有存储集群网络无法正常工作,OSD 无法发送和接收心跳数据包。因此,它们互相报告为 停机到 Ceph 监控器,同时将自身标记为 up。
Ceph 配置文件中的以下参数会影响此行为:
| 参数 | 描述 | 默认值 |
|---|---|---|
|
|
OSD 等待 heartbeat 数据包返回多长时间,然后将 OSD 报告为 | 20 秒 |
|
|
在 Ceph 监控将该 OSD 标记为 | 2 |
下表显示了在默认配置中,Ceph 监控器在只有一个 OSD 三次报告了第一个 OSD 为 down 时,才会将 OSD 标记为 down。在某些情况下,如果单个主机遇到网络问题,整个群集可能会遇到 OSD 出现问题。这是因为主机上的 OSD 将报告集群中的其他 OSD 为 down。
Flanping OSD 方案不包括 OSD 进程启动时,然后立即终止的情况。
要排除这个问题,请执行以下操作
再次检查
ceph 运行状况详细信息命令的输出。如果其中包含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 崩溃。要创建支持问题单,请参阅联系红帽支持团队部分。
Ceph OSD 节点上、网络交换机级别上的 MTU 错误配置或两者可能会引起 Fpping OSD。要解决这个问题,请在所有存储集群节点上将 MTU 设置为统一大小,包括在核心上和通过计划停机访问网络交换机。不要调优 osd heartbeat min 大小,因为更改此设置可能会隐藏网络中的问题,也不会解决实际的网络不一致。
5.2.9. 请求慢或请求被阻塞 复制链接链接已复制到粘贴板!
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]
此 Means 是什么
请求速度较慢的 OSD 是每个无法在 osd_op_complaint_time 参数定义的时间内队列中每秒 I/O 操作(IOPS)服务的 OSD。默认情况下,此参数被设置为 30 秒。
造成 OSD 请求缓慢的主要原因包括:
- 与底层硬件相关的问题,如磁盘驱动器、主机、机架或网络交换机
- 与网络相关的问题。这些问题通常与闪烁的 OSD 连接。详情请参阅 Flapping OSD。
- 系统负载
下表显示了慢速请求的类型。使用 dump_historic_ops 管理 socket 命令来确定慢速请求的类型。有关管理套接字的详细信息,请参见 Red Hat Ceph Storage 5 管理指南中的使用 Ceph 管理套接字一节。
| 请求类型慢 | 描述 |
|---|---|
|
| OSD 正在等待在 PG 上获取操作的锁定。 |
|
| OSD 正在等待副本 OSD 将操作应用到日志。 |
|
| OSD 未达到任何主要操作里程碑。 |
|
| OSD 尚未复制指定次数的对象。 |
要排除这个问题,请执行以下操作
- 确定具有缓慢或块请求的 OSD 是否共享一个通用的硬件,如磁盘驱动器、主机、机架或网络交换机。
如果 OSD 共享磁盘:
使用
smartmontools实用程序检查磁盘或日志的健康状况,以确定磁盘上的任何错误。注意smartmontools程序包含在smartmontools软件包中。使用
iostat实用程序获取 OSD 磁盘上的 I/O 等待报告(%iowai),以确定磁盘是否负载过重。注意The
iostat实用程序包含在sysstat软件包中。
如果 OSD 与另一个服务共享节点:
- 检查 RAM 和 CPU 使用率
-
使用
netstat实用程序查看网络接口控制器(NIC)上的网络统计信息,并对任何网络问题进行故障排除。如需更多信息,请参阅对 网络问题进行故障排除。
- 如果 OSD 共享机架,请检查机架的网络交换机。例如,如果您使用巨型帧,请验证路径中的 NIC 是否已设置了巨型帧。
- 如果您无法确定请求速度较慢的 OSD 共享的硬件部分,或者无法对硬件和网络问题进行故障排除和修复,请创建一个支持问题单。有关 详细信息,请参阅联系红帽支持团队。