5.2. 大多数常见 Ceph OSD 错误

排除此问题，请执行以下操作：

1. 验证 PG 计数是否足够，并在需要时增加。
2. 验证您是否使用最优于集群版本的 CRUSH 可调项，如果不是，请进行调整。
3. 根据利用率更改 OSD 的权重。

4. 启用 Ceph 管理器均衡器模块，优化 OSD 之间的 PG 放置，从而实现均衡分布

   示例

   [root@mon ~]# ceph mgr module enable balancer

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

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

      [root@mon ~]# ceph osd df

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

      $ df

   3. 如果需要，添加新 OSD 节点。

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

1. 确定哪个 OSD 处于 down 状态 ：

   [root@mon ~]# 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 守护进程：

   [root@mon ~]# systemctl restart ceph-osd@OSD_NUMBER

   将 OSD_NUMBER 替换为 down 的 OSD ID，例如：

   [root@mon ~]# systemctl restart ceph-osd@0

   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. 如果您收到错误 ROR：无法对 /var/lib/ceph/osd/ceph-1 错误消息打开 OSD 超级块，ceph -osd 守护进程无法读取底层文件系统。有关如何排除故障并修复此错误的说明，请参阅以下步骤。

   注意

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

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

   注意

   对于基于容器的部署，Ceph 会生成日志到 journald。您可以通过在 Ceph 配置文件中 [global] 下将 log_to_file 参数设置为 true，以启用记录到 /var/log/ceph 中的文件。如需了解更多详细信息 ，请参阅了解 ceph 日志。

   1. EIO 错误消息类似如下，表示底层磁盘失败：

      为修复此问题，请替换底层 OSD 磁盘。详情请参阅 替换 OSD 驱动器。

   2. 如果日志包含任何其他 FAILED assert 错误，如以下错误，请打开支持票据。有关 详细信息，请参阅联系红帽支持团队。

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

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

   $ dmesg

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

7. 如果 OSD 因分段错误而出现故障，如以下 OSD，请收集必要的信息并打开支持票据。有关 详细信息，请参阅联系红帽支持团队。

   Caught signal (Segmentation fault)

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

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

   注意

   对于基于容器的部署，Ceph 会生成日志到 journald。您可以通过在 Ceph 配置文件中 [global] 下将 log_to_file 参数设置为 true，以启用记录到 /var/log/ceph 中的文件。如需了解更多详细信息 ，请参阅了解 ceph 日志。

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

      wrongly marked me down
      heartbeat_check: no reply from osd.2 since back

   2. 如果您看到任何其他错误，请打开支持票据。有关 详细信息，请参阅联系红帽支持团队。

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

1. 再次检查 ceph 运行状况详细信息 命令的输出。如果其中包含 较慢的请求 错误消息，请参阅 如何排除此问题。

   # 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. 或者，您可以通过设置 noup 和 no down 标记来临时强制监控器停止将 OSD 标记为 down 和 up ：

   # ceph osd set noup
   # ceph osd set nodown

   重要

   使用 noup 和 nodown 标志不会修复问题的根本原因，而是仅防止 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 共享的硬件部分，或者无法对硬件和网络问题进行故障排除和修复，请打开支持票据。有关 详细信息，请参阅联系红帽支持团队。