1.常见 OSD 故障处理

进行 OSD 排障前，先检查一下 monitors 和网络。如果 ceph health 或 ceph -s 返回的是健康状态，这意味着 monitors 形成了法定人数。如果 monitor 还没达到法定人数、或者 monitor 状态错误，要先解决 monitor 的问题。核实下你的网络，确保它在正常运行，因为网络对 OSD 的运行和性能有显著影响。

1.1 收集 OSD 数据

开始 OSD 排障的第一步最好先收集信息，另外还有监控 OSD 时收集的，如 ceph osd tree 。

Ceph 日志

如果你没改默认路径，可以在 /var/log/ceph 下找到 Ceph 的日志：

ls /var/log/ceph

如果看到的日志还不够详细，可以增大日志级别。请参考[1.12 日志和调试]，查阅如何保证看到大量日志又不影响集群运行。

管理套接字

用管理套接字工具检索运行时信息。列出节点上所有 Ceph 套接字：

ls /var/run/ceph

然后，执行下例命令显示可用选项，把 {daemon-name} 换成实际的守护进程（如 osd.0 ）：

ceph daemon osd.0 help

或者，你也可以指定一个 {socket-file} （如 /var/run/ceph 下的文件）：

ceph daemon {socket-file} help

和其它手段相比，管理套接字允许你：

• 在运行时列出配置

• 列出历史操作

• 列出操作的优先队列状态

• 列出在进行的操作

• 列出性能计数器

显示可用空间

可能会引起文件系统问题。用 df 命令显示文件系统的可用空间。

df -h

其它用法见 df --help 。

I/O 统计信息

用 iostat 工具定位 I/O 相关问题。

iostat -x

诊断信息

要查看诊断信息，配合 less 、 more 、 grep 或 tail 使用 dmesg ，例如：

dmesg | grep scsi

1.2 停止数据向外重平衡

你得周期性地对集群的子集进行维护，或解决某个故障域的问题（如某个机架）。如果你不想在停机维护 OSD 时让 CRUSH 自动重均衡，首先设置集群的 noout 标志：

ceph osd set noout

设置了 noout 后，你就可以停机维护失败域内的 OSD 了。

stop ceph-osd id={num}

注意：在定位某故障域内的问题时，停机的 OSD 内的 PG 状态会变为 degraded 。

维护结束后，重启 OSD 。

start ceph-osd id={num}

最后，解除 noout 标志。

ceph osd unset noout

1.3 OSD 没运行

通常情况下，简单地重启 ceph-osd 进程就可以让它重回集群并恢复。

OSD 起不来

如果你重启了集群，但其中一个 OSD 起不来，依次检查：

• 配置文件： 如果你新装的 OSD 不能启动，检查下配置文件，确保它符合规定（比如 host 而非 hostname ，等等）。

• 检查路径： 检查配置文件的路径，以及 OSD 的数据和日志分区路径。如果你分离了 OSD 的数据和日志分区、而配置文件和实际挂载点存在出入，启动 OSD 时就可能失败。如果你想把日志存储于一个块设备，应该为日志硬盘分区并为各 OSD 分别指定一个分区。

• 检查最大线程数： 如果你的节点有很多 OSD ，也许就会触碰到默认的最大线程数限制（如通常是 32k 个），尤其是在恢复期间。你可以用 sysctl 增大线程数，把最大线程数更改为支持的最大值（即 4194303 ），看看是否有用。例如：

  sysctl -w kernel.pid_max=4194303

如果增大最大线程数解决了这个问题，你可以把此配置 kernel.pid_max 写入配置文件 /etc/sysctl.conf，使之永久生效，例如：

kernel.pid_max = 4194303

• 内核版本： 确认你使用的内核版本和发布版本。 Ceph 默认依赖一些第三方工具，这些工具可能有缺陷或者与特定发布版和/或内核版本冲突（如 Google perftools ）。检查下操作系统推荐表，确保你已经解决了内核相关的问题。

• 段错误： 如果有了段错误，提高日志级别（如果还没提高），再试试。如果重现了，联系 ceph-devel 邮件列表并提供你的配置文件、monitor 输出和日志文件内容。

OSD 失败

当 ceph-osd 挂掉时，monitor 可通过活着的 ceph-osd 了解到此情况，并通过 ceph health 命令报告：