5.2. 大多数常见 Ceph OSD 错误


下表列出了 ceph 运行状况详细信息 命令返回或包含在 Ceph 日志中的最常见错误消息:这些表中提供了相应部分的链接,这些部分解释了错误并指向修复问题的特定程序。

5.2.1. 先决条件

  • 对 Ceph OSD 节点的根级别访问权限.

5.2.2. Ceph OSD 错误消息

常见 Ceph OSD 错误消息和可能的修复表。

错误消息查看

HEALTH_ERR

full osds

完整 OSD

HEALTH_WARN

backfillfull osds

backfillfull OSDS

nearfull osds

nearfull OSD

OSD 已停机

降级 OSD

flapping OSD

requests are blocked

请求或请求速度较慢

slow requests

请求或请求速度较慢

5.2.3. Ceph 日志中的常见 Ceph OSD 错误消息

Ceph 日志中常见 Ceph OSD 错误消息的列表,以及可能的修复链接。

错误消息日志文件查看

heartbeat_check:没有来自 osd.X 的回复

主集群日志

flapping OSD

错误地标记我被关闭

主集群日志

flapping OSD

OSD 的请求速度较慢

主集群日志

请求或请求速度较慢

FAILED assert(0 == "hit suicide timeout")

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 VALUE

    VALUE 的范围是 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 的后端存储几乎已满。

排除此问题,请执行以下操作:

  1. 验证 PG 计数是否足够,并在需要时增加。
  2. 验证您是否使用最优于集群版本的 CRUSH 可调项,如果不是,请进行调整。
  3. 根据利用率更改 OSD 的权重。
  4. 确定 OSD 使用的磁盘上保留多少空间。

    1. 要查看特定节点上 OSD 使用的空间量,请使用以下命令:

      [ceph: root@host01 /]# ceph osd df tree
    2. 在检查大多数使用哪些 OSD (full/nearfull)后,查看将哪个磁盘用作 OSD 的底层磁盘。登录到包含 nearfull OSD 的节点,并运行以下命令:

      [ceph: root@host01 /]# cephadm shell
      [ceph: root@host01 /]# ceph-volume lvm list
    3. 查看集群中存在的池列表:

      [ceph: root@host01 /]# ceph df
    4. 如果需要,添加新 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 时的情况。

要排除这个问题,请执行以下操作

  1. 确定哪个 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
  2. 尝试重新启动 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

    1. 如果您无法启动 ceph-osd,请按照 ceph-osd 守护进程中的步骤启动
    2. 如果您能够启动 ceph-osd 守护进程但已标记为 down,请按照 ceph-osd 守护进程中的步骤运行,但仍标记为"down"。

ceph-osd 守护进程无法启动

  1. 如果您的节点包含多个 OSD(通常超过 12 倍),请验证默认最多线程数(PID 数)是否足够。有关 详细信息,请参阅增加 PID 数
  2. 验证 OSD 数据和日志分区是否已正确挂载。您可以使用 ceph-volume lvm list 命令列出 与 Ceph 存储群集关联的所有设备和卷,然后手动检查它们是否已正确挂载。详情请查看 mount(8) 手册页。
  3. 如果您收到错误 的密钥环:缺少密钥环,无法使用 cephx 进行身份验证 错误消息,OSD 缺少密钥环。
  4. 如果您遇到 ERROR: unable to open OSD superblock on /var/lib/ceph/osd/ceph-1 错误信息,ceph-osd 守护进程不能读底层的文件系统。有关如何排除故障并修复此错误的说明,请参阅以下步骤。

    1. 检查对应的日志文件,以确定故障的原因。默认情况下,Ceph 在启用了日志记录到文件后,Ceph 将日志文件存储在 /var/log/ceph/CLUSTER_FSID/ 目录中。
    2. EIO 错误消息表示底层磁盘失败。为修复此问题,请替换底层 OSD 磁盘。详情请参阅 替换 OSD 驱动器
    3. 如果日志包含任何其他 FAILED assert 错误,如以下错误,请打开支持票据。有关 详细信息,请参阅联系红帽支持团队

      FAILED assert(0 == "hit suicide timeout")
  5. 检查 dmesg 输出是否有底层文件系统或磁盘的错误:

    dmesg
    1. 如果 dmesg 输出包含任何 SCSI error 错误信息,请参阅红帽客户门户网站中的 SCSI Error Codes Solution Finder 解决方案,以确定解决问题的最佳方法。
    2. 或者,如果您无法修复底层文件系统,请替换 OSD 驱动器。详情请参阅 替换 OSD 驱动器
  6. 如果 OSD 因分段错误而出现故障,如以下 OSD,请收集必要的信息并创建一个支持问题单。有关 详细信息,请参阅联系红帽支持团队

    Caught signal (Segmentation fault)

ceph-osd 正在运行,但仍标记为 down

  1. 检查对应的日志文件,以确定故障的原因。默认情况下,Ceph 在启用了日志记录到文件后,Ceph 将日志文件存储在 /var/log/ceph/CLUSTER_FSID/ 目录中。

    1. 如果日志中包含类似于下文的错误消息,请参阅 Flapping OSD

      wrongly marked me down
      heartbeat_check: no reply from osd.2 since back
    2. 如果您看到任何其他错误,请打开支持票据。有关 详细信息,请参阅联系红帽支持团队

其它资源

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 使用专用网络在彼此间发送心跳数据包,以代表它们处于 upin 状态。如果私有存储集群网络无法正常工作,OSD 无法发送和接收心跳数据包。因此,它们互相报告为 停机到 Ceph 监控器,同时将自身标记为 up

Ceph 配置文件中的以下参数会影响此行为:

参数描述默认值

osd_heartbeat_grace_time

OSD 等待 heartbeat 数据包返回多长时间,然后将 OSD 报告为 down 到 Ceph 监控器。

20 秒

mon_osd_min_down_reporters

在 Ceph 监控将该 OSD 标记为 down 之前,需要多少 OSD 报告了另一个 OSD 为 down

2

下表显示了在默认配置中,Ceph 监控器在只有一个 OSD 三次报告了第一个 OSD 为 down 时,才会将 OSD 标记为 down。在某些情况下,如果单个主机遇到网络问题,整个群集可能会遇到 OSD 出现问题。这是因为主机上的 OSD 将报告集群中的其他 OSD 为 down

注意

Flanping OSD 方案不包括 OSD 进程启动时,然后立即终止的情况。

要排除这个问题,请执行以下操作

  1. 再次检查 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
  2. 确定哪些 OSD 标记为 down 以及它们所在的节点上:

    ceph osd tree | grep down
  3. 在包含 flapping OSD 的节点上,对任何网络问题进行故障排除并修复。详情请参阅对 网络问题进行故障排除
  4. 或者,您可以通过设置 noupnodown 标记,临时强制 monitor 停止将 OSD 标记为 downup

    ceph osd set noup
    ceph osd set nodown
    重要

    使用 noupnodown 标志不会修复问题的根本原因,而是仅防止 OSD 崩溃。要创建支持问题单,请参阅联系红帽支持团队部分。

重要

Ceph OSD 节点上、网络交换机级别上的 MTU 错误配置或两者可能会引起 Fpping OSD。要解决这个问题,请在所有存储集群节点上将 MTU 设置为统一大小,包括在核心上和通过计划停机访问网络交换机。不要调优 osd heartbeat min 大小,因为更改此设置可能会隐藏网络中的问题,也不会解决实际的网络不一致。

其它资源

  • 有关详细信息,请参见《 红帽 Ceph 存储架构指南》中的 Ceph 心跳 章节。
  • 请参阅《 红帽 Ceph 存储故障排除指南 》中的流 请求或请求 部分

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 管理套接字一节。

请求类型慢描述

等待 rw 锁定

OSD 正在等待在 PG 上获取操作的锁定。

waiting for subops

OSD 正在等待副本 OSD 将操作应用到日志。

no flag points reached

OSD 未达到任何主要操作里程碑。

等待降级对象

OSD 尚未复制指定次数的对象。

要排除这个问题,请执行以下操作

  1. 确定具有缓慢或块请求的 OSD 是否共享一个通用的硬件,如磁盘驱动器、主机、机架或网络交换机。
  2. 如果 OSD 共享磁盘:

    1. 使用 smartmontools 实用程序检查磁盘或日志的健康状况,以确定磁盘上的任何错误。

      注意

      smartmontools 程序包含在 smartmontools 软件包中。

    2. 使用 iostat 实用程序获取 OSD 磁盘上的 I/O 等待报告(%iowai),以确定磁盘是否负载过重。

      注意

      The iostat 实用程序包含在 sysstat 软件包中。

  3. 如果 OSD 与另一个服务共享节点:

    1. 检查 RAM 和 CPU 使用率
    2. 使用 netstat 实用程序查看网络接口控制器(NIC)上的网络统计信息,并对任何网络问题进行故障排除。如需更多信息,请参阅对 网络问题进行故障排除
  4. 如果 OSD 共享机架,请检查机架的网络交换机。例如,如果您使用巨型帧,请验证路径中的 NIC 是否已设置了巨型帧。
  5. 如果您无法确定请求速度较慢的 OSD 共享的硬件部分,或者无法对硬件和网络问题进行故障排除和修复,请创建一个支持问题单。有关 详细信息,请参阅联系红帽支持团队

其它资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.