Red Hat Training

A Red Hat training course is available for Red Hat Ceph Storage

第 5 章 OSD 故障排除

本章包含关于如何修复与 Ceph OSD 相关的最常见错误的信息。

开始前

5.1. 与 OSD 相关的大多数通用错误消息

下表列出了 ceph health detail 命令返回或 Ceph 日志中最常包含的错误消息。这些表中提供了相应的部分的链接，这些部分解释了错误并指向修复问题的特定程序。

表 5.2. 与 OSD 相关的 Ceph 日志中的常见错误消息

错误消息日志文件请查看

heartbeat_check: no reply from osd.X

主集群日志

第 5.1.4 节 “Flapping OSD”

wrongly marked me down

主集群日志

第 5.1.4 节 “Flapping OSD”

osds have slow requests

主集群日志

第 5.1.5 节 “请求速度较慢，请求被阻塞”

FAILED assert(!m_filestore_fail_eio)

OSD 日志

第 5.1.3 节 “个或更多 OSD 发生故障”

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

OSD 日志

第 5.1.3 节 “个或更多 OSD 发生故障”

5.1.1. 完整 OSD

ceph health detail 命令返回类似如下的错误消息： 

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%，您可以：

另请参阅

5.1.2. nearfull OSD

ceph health detail 命令返回类似如下的错误消息： 

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 计数是否足够，并在需要时增加。详情请查看 第 7.5 节 “增加 PG 数量”。
  2. 验证您是否使用最优于集群版本的 CRUSH 可调项，如果不是，请进行调整。详情请查看红帽 Ceph 存储 3 存储 3 存储策略 指南中的 CRUSH 可调项小节 ，以及如何测试对红帽客户门户上红帽 Ceph 存储中 OSD 的 PG 分布的影响 CRUSH map 可调项。
  3. 根据利用率更改 OSD 的权重。请参阅红帽 Ceph 存储 3 的存储策略指南中的设置 OSD Weight by Utilization 部分。

  4. 确定 OSD 使用的磁盘上保留多少空间。

    1. 查看 OSD 一般使用的空间量： 

      # ceph osd df

    2. 查看 OSD 在特定节点上使用的空间：从包含 nearful OSD 的节点运行以下命令： 

      $ df
    3. 如果需要，添加新 OSD 节点。请参阅《红帽 Ceph 存储 3 管理指南 》中的 添加和删除 OSD 节点 章节。
另请参阅

5.1.3. 个或更多 OSD 发生故障

ceph health 命令返回类似如下的错误： 

HEALTH_WARN 1/3 in osds are down
此 Means 是什么

其中一个 ceph-osd 进程因为可能的服务故障或与其他 OSD 通信时出现问题而不可用。因此，存活的 ceph-osd 守护进程会向 monitor 报告这个失败。

如果 ceph-osd 守护进程没有运行，底层 OSD 驱动器或文件系统会损坏，或者某些其他错误（如缺少密钥环）会阻止守护进程启动。

在大多数情况下，网络问题会导致 ceph-osd 守护进程正在运行，但仍标记为 down。

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

  1. 确定哪个 OSD 为 down: 

    # 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 守护进程： 

    systemctl restart ceph-osd@<OSD-number>

    使用 down 的 OSD 的 ID 替换 <OSD-number>，例如： 

    # systemctl restart ceph-osd@0
    1. 如果您无法启动 ceph-osd，请按照 ceph-osd 守护进程中的步骤启动。
    2. 如果您能够启动 ceph-osd 守护进程，但标记为 down，请按照 ceph-osd 守护进程正在运行但仍标记为 down 的步骤操作。
ceph-osd 守护进程无法启动
  1. 如果您有一个包含多个 OSD 的节点（通常比 12 多个 OSD），请验证默认最多线程数（PID 数）是否足够。详情请查看 第 5.5 节 “增加 PID 数量”。

  2. 验证 OSD 数据和日志分区是否已正确挂载： 

    # ceph-disk list
...
/dev/vdb :
 /dev/vdb1 ceph data, prepared
 /dev/vdb2 ceph journal
/dev/vdc :
 /dev/vdc1 ceph data, active, cluster ceph, osd.1, journal /dev/vdc2
 /dev/vdc2 ceph journal, for /dev/vdc1
/dev/sdd1 :
 /dev/sdd1 ceph data, unprepared
 /dev/sdd2 ceph journal

    如果 ceph-disk 将分区标记为 active，则会挂载分区。如果分区是 prepared，挂载它。详情请查看 第 5.3 节 “挂载 OSD 数据分区”。如果分区是 unprepared，则必须在挂载前首先准备它。请参阅《红帽 Ceph 存储 3 管理指南 》中的准备 OSD 数据和日志驱动器一节。

  3. 如果您收到 ERROR: missing keyring, cannot use cephx for authentication 错误消息，则 OSD 缺少密钥环。请参阅《红帽 Ceph 存储 3 管理指南》 中的 密钥环管理部分。

  4. 如果您收到 ERROR: unable to open OSD superblock on /var/lib/ceph/osd/ceph-1 错误消息，ceph-osd 守护进程将无法读取底层文件系统。有关如何排除故障并修复此错误的说明，请参阅以下步骤。

    注意

    如果在 OSD 主机引导期间返回此错误消息，请打开支持票据，因为这可能表示 在红帽 Bugzilla 1439210 中跟踪了一个已知问题。详情请查看 第 9 章 联系红帽支持服务。

  5. 检查对应的日志文件，以确定故障的原因。默认情况下，Ceph 将日志文件存储在 /var/log/ceph/ 目录中。

    1. 类似于以下内容的 EIO 错误消息表示底层磁盘失败： 

      FAILED assert(!m_filestore_fail_eio || r != -5)

      为修复此问题，请替换底层 OSD 磁盘。详情请查看 第 5.4 节 “替换 OSD 驱动器”。

    2. 如果日志包含任何其他 FAILED assert 错误，如以下错误，请打开支持票据。详情请查看 第 9 章 联系红帽支持服务。 

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

  6. 检查 dmesg 输出是否有底层文件系统或磁盘的错误： 

    $ dmesg

    1. error -5 错误消息类似如下，表示底层 XFS 文件系统崩溃。有关如何解决这个问题的详情，请查看红帽客户门户网站中的 "xfs_log_force: error -5 返回"? 解决方案的含义。 

      xfs_log_force: error -5 returned
    2. 如果 dmesg 输出包含任何 SCSI error 错误消息，请参阅红帽客户门户网站中的 SCSI Error Codes Solution Finder 解决方案，以确定解决问题的最佳方法。
    3. 或者，如果您无法修复底层文件系统，请替换 OSD 驱动器。详情请查看 第 5.4 节 “替换 OSD 驱动器”。

  7. 如果 OSD 因分段错误而出现故障，如以下 OSD，请收集必要的信息并打开支持票据。详情请查看 第 9 章 联系红帽支持服务。 

    Caught signal (Segmentation fault)
ceph-osd 正在运行，但仍标记为 down

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

    1. 如果日志包含类似以下的错误消息，请参阅 第 5.1.4 节 “Flapping OSD”。 

      wrongly marked me down
heartbeat_check: no reply from osd.2 since back
    2. 如果您看到任何其他错误，请打开支持票据。详情请查看 第 9 章 联系红帽支持服务。
另请参阅

5.1.4. Flapping OSD

ceph -w | grep osds 命令会在短时间内重复显示 OSD 为 down，然后再次显示 up ： 

# ceph -w | grep osds
2017-04-05 06:27:20.810535 mon.0 [INF] osdmap e609: 9 osds: 8 up, 9 in
2017-04-05 06:27:24.120611 mon.0 [INF] osdmap e611: 9 osds: 7 up, 9 in
2017-04-05 06:27:25.975622 mon.0 [INF] HEALTH_WARN; 118 pgs stale; 2/9 in osds are down
2017-04-05 06:27:27.489790 mon.0 [INF] osdmap e614: 9 osds: 6 up, 9 in
2017-04-05 06:27:36.540000 mon.0 [INF] osdmap e616: 9 osds: 7 up, 9 in
2017-04-05 06:27:39.681913 mon.0 [INF] osdmap e618: 9 osds: 8 up, 9 in
2017-04-05 06:27:43.269401 mon.0 [INF] osdmap e620: 9 osds: 9 up, 9 in
2017-04-05 06:27:54.884426 mon.0 [INF] osdmap e622: 9 osds: 8 up, 9 in
2017-04-05 06:27:57.398706 mon.0 [INF] osdmap e624: 9 osds: 7 up, 9 in
2017-04-05 06:27:59.669841 mon.0 [INF] osdmap e625: 9 osds: 6 up, 9 in
2017-04-05 06:28:07.043677 mon.0 [INF] osdmap e628: 9 osds: 7 up, 9 in
2017-04-05 06:28:10.512331 mon.0 [INF] osdmap e630: 9 osds: 8 up, 9 in
2017-04-05 06:28:12.670923 mon.0 [INF] osdmap e631: 9 osds: 9 up, 9 in

此外，Ceph 日志包含类似于以下的错误消息： 

2016-07-25 03:44:06.510583 osd.50 127.0.0.1:6801/149046 18992 : cluster [WRN] map e600547 wrongly marked me down
2016-07-25 19:00:08.906864 7fa2a0033700 -1 osd.254 609110 heartbeat_check: no reply from osd.2 since back 2016-07-25 19:00:07.444113 front 2016-07-25 18:59:48.311935 (cutoff 2016-07-25 18:59:48.906862)
此 Means 是什么

引发 OSD 的主要原因是：

  • 某些集群操作（如清理或恢复）通常需要花费大量时间。例如，如果您对具有大型索引或大型放置组的对象执行这些操作。通常，在完成这些操作后，flapping OSD 问题会得到解决。
  • 与底层物理硬件相关的问题.在这种情况下，ceph health detail 命令也会返回 slow requests 错误消息。详情请查看 第 5.1.5 节 “请求速度较慢，请求被阻塞”。
  • 网络相关问题.

当集群（后端）网络出现故障或开发显著延迟时，OSD 无法很好地处理这种情形，而公共（前端）网络运行最佳。

OSD 使用集群网络来互相发送 heartbeat 数据包，以注明它们是 up 和 in。如果集群网络无法正常工作，OSD 无法发送和接收 heartbeat 数据包。因此，它们相互报告为 down 到 monitor，同时将自身标记为 up。

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

参数描述默认值

osd_heartbeat_grace

OSD 在将 OSD 报告为 down 向 monitor 报告之前等待心跳数据包返回的时长。

20 秒

mon_osd_min_down_reporters

监控将 OSD 标记为 down 前有多少 OSD 必须报告另一个 OSD 为 down

2

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

注意

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

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

  1. 再次检查 ceph health detail 命令的输出。如果包含 slow requests 错误消息，请参阅 第 5.1.5 节 “请求速度较慢，请求被阻塞” 了解如何排除此问题的详情。 

    # 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 的节点上，对任何网络问题进行故障排除并修复。详情请查看 第 3 章 网络问题故障排除。

  4. 或者，您可以通过设置 noup 和 nodown 标志来临时强制监控器停止将 OSD 标记为 down 和 up ： 

    # ceph osd set noup
# ceph osd set nodown
    重要

    使用 noup 和 nodown 标志不会修复造成问题的根本原因，而是只防止 OSD 崩溃。如果无法自行修复并对错误进行故障排除，请打开支持票据。详情请查看 第 9 章 联系红帽支持服务。

  5. 此外，可以通过在 Ceph 配置文件中设置 osd heartbeat min size = 100，然后重新启动 OSD，来修复 flapping OSD。这会导致因为 MTU 错误配置解决了网络问题。
其它资源
  • 针对 Red Hat Enterprise Linux 的红帽 Ceph 存储 3 安装指南 或 Ubuntu安装指南中的 验证红帽 Ceph 存储网络配置 一节
  • 红帽 Ceph 存储 3 架构指南 中的 Heartbeating 部分

5.1.5. 请求速度较慢，请求被阻塞

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 日志包含类似于以下的错误消息： 

2015-08-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
2016-07-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，它们无法在 osd_op_complaint_time 参数定义的时间内为队列中的每秒 I/O 操作(IOPS)提供服务。默认情况下，此参数设置为 30 秒。

造成 OSD 缓慢请求的主要原因是：

  • 与底层硬件相关的问题，如磁盘驱动器、主机、机架或网络交换机
  • 网络相关问题.这些问题通常与闪烁的 OSD 连接。详情请查看 第 5.1.4 节 “Flapping OSD”。
  • 系统负载

下表显示了慢速请求的类型。使用 dump_historic_ops 管理 socket 命令来确定慢速请求的类型。有关管理套接字的详细信息，请参阅《红帽 Ceph 存储 3 管理指南》 中的使用管理 套接字 小节。

请求类型慢描述

waiting for rw locks

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

waiting for subops

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

no flag points reached

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

waiting for degraded object

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

要排除这个问题，请执行以下操作
  1. 确定请求缓慢或块请求的 OSD 是否共享共同的硬件部分，如磁盘驱动器、主机、机架或网络交换机。

  2. 如果 OSD 共享磁盘：

    1. 使用 smartmontools 工具检查磁盘或日志的健康状况，以确定磁盘中的任何错误。

      注意

      smartmontools 工具包括在 smartmontools 软件包中。

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

      注意

      iostat 工具包括在 sysstat 软件包中。

  3. 如果 OSD 共享主机：

    1. 检查 RAM 和 CPU 使用率
    2. 使用 netstat 实用程序查看网络接口控制器(NIC)上的网络统计信息，并对任何网络问题进行故障排除。如需更多信息，请参阅 第 3 章 网络问题故障排除。
  4. 如果 OSD 共享机架，请检查机架的网络交换机。例如，如果您使用巨型帧，请验证路径中的 NIC 是否已设置了巨型帧。
  5. 如果您无法确定请求速度较慢的 OSD 共享的硬件部分，或者无法对硬件和网络问题进行故障排除和修复，请打开支持票据。详情请查看 第 9 章 联系红帽支持服务。
另请参阅
  • 《红帽 Ceph 存储 3 管理指南 》中的使用管理 套接字 一节