Ceph分布式存储 - 常见OSD故障排除

1.常见的OSD故障排除
在排除OSD故障之前，请检查显示器和网络。如果ceph health或ceph -s返回健康状态，则表示监视器形成了法定人数。如果监视器未达到仲裁或监视器状态不正确，请首先解决监视器问题。验证您的网络并确保其正常工作，因为网络对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守护进程osd.0的帮助
或者，您可以指定{socket-file}（例如/var/run/ceph下的文件）：
Ceph守护进程{socket-file}帮助
与其他方法相比，管理套接字允许您：
在运行时列出配置
列出历史操作
列出操作的优先级队列状态
列出正在进行的操作
列出性能计数器
显示自由空间
可能导致文件系统问题。使用df命令显示文件系统的可用空间。Df -h
有关其他用法，请参阅df --help。
I/O统计信息
使用iostat工具查找与I/O相关的问题。
Iostat -x
诊断信息
要查看诊断信息，请使用带有less，more，grep或tail的dmesg，例如：
Dmesg | grep scsi
1.2停止数据重新平衡
您必须定期维护群集的子集或解决故障域（例如机架）的问题。如果您不希望CRUSH在关闭OSD时自动重新平衡，请首先设置群集的noout标志：
Ceph osd没有设置
一旦设置了noout，您就可以在维护失败域中关闭OSD。
停止ceph-osd id={num}
注意：在故障域中查找问题时，停止的OSD中的PG状态将降低。
维护结束后，重新启动OSD。
启动ceph-osd id={num}
最后，删除noout标志。
Ceph osd没有注意到
1.3 OSD未运行
通常，只需重新启动ceph-osd进程就会将其返回到集群并进行恢复。
OSD无法起床
如果重新启动群集，但其中一个OSD未出现，请按顺序检查：
配置文件：如果新安装的OSD未启动，请检查配置文件以确保其符合（例如主机而不是主机名等）。
检查路径：检查配置文件的路径，以及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邮件列表并提供配置文件，监视器输出和日志文件内容。
OSD失败
当ceph-osd挂起时，监视器可以通过live ceph-osd了解这一点并通过ceph health命令报告：
Ceph健康
HEALTH_WARN 1/3 in osds正在下降
特别是，当ceph-osd进程标记为in和down时，您将收到警告。您可以使用以下命令来了解挂起的ceph-osd进程：
Ceph健康细节
HEALTH_WARN 1/3 in osds正在下降
Osd.0从纪元23开始下降，最后地址为192.168.106.220: 6800/11080
如果硬盘故障或其他错误导致ceph-osd无法运行或重新启动，则会在日志文件/var/log/ceph /中输出错误消息。
如果守护程序因心跳故障而停止或基础核心文件系统无响应，请检查dmesg是否存在硬盘或内核错误。
如果是软件错误（断言失败或其他意外错误），则应将其报告给ceph-devel邮件列表。
硬盘上没有剩余空间
Ceph不允许您将数据写入完整的OSD以避免丢失数据。在正在运行的集群中，您应该能够收到集群空间已满的警告。 Mon osd full ratio默认为0.95，否则会阻止客户端在达到95％的空间使用时写入数据。 mon osd nearfull ratio默认为0.85，这意味着当它达到容量的85％时会产生健康警告。
在测试小型Ceph集群上的小型OS故障时，通常会出现满载集群问题。当节点具有高使用率时，群集可以快速屏蔽全速率和全速率。如果您正在测试小集群上的Ceph如何响应OSD故障，您应该留下足够的可用磁盘空间并尝试暂时降低mon osd full ratio和mon osd nearfull ratio值。Ceph health将报告完整的ceph-osds：
Ceph健康
HEALTH_WARN 1近乎完整的osds
Osd.2接近满85％
要么：
Ceph健康
HEALTH_ERR 1近乎完整的osds，1个完整的osds
Osd.2接近满85％
Osd.3满97％
处理这种情况的最佳方法是在发生接近完全警报时立即添加新的ceph-osd，这允许集群将数据重新分配到新的OSD中。
如果由于满载而无法启动OSD，您可以尝试删除该OSD上的某些数据。但是，有一个问题。当OSD使用率达到95％时，群集将不接受任何从Ceph客户端读取和写入数据的请求。此时rbd rm delete命令不会得到响应。
首先要做的是读取和写入集群。最容易考虑的是增加mon osd full ratio和mon osd nearfull ratio值，但是对于生产环境，一旦调整了这个全局比例，整个集群的数据将被移动，从而导致更多的数据迁移。另一个折衷方案是分别调整完整OSD的近满和全比率；您还可以使用降低OSD压缩权重的方法来移植完整OSD上的部分数据。
＃调整单个osd的比例
Ceph告诉osd.id injectargs'--mon-osd-full-ratio .98'
Ceph告诉osd.id injectargs'--mon-osd-full-ratio 0.98'
＃调整osd的压碎重量值
Ceph osd crush reweight osd.id {a-little-lower-weight-value}
1.4 OSD乌龟速度或无响应
一个反复出现的问题是OSD缓慢或无响应。在深入了解性能问题之前，您应该确保没有其他故障。例如，确保您的网络运行正常并且OSD正在运行，并检查OSD是否被恢复流量拖拽。提示：较新版本的Ceph可以更好地处理恢复，防止恢复过程耗尽系统资源，导致OSD无法使用或响应缓慢。
网络问题
Ceph是一个分布式存储系统，因此它依靠网络来互连OSD，复制对象，从错误中恢复以及检查心跳。网络问题可能导致OSD延迟和振荡（反复上下重复，有关详细信息，请参阅下面的相关部分）。
确保Ceph进程和Ceph依赖进程已建立连接和/或正在侦听。
Netstat -a | grep ceph
Netstat -l | grep ceph
Sudo netstat -p | grep ceph
检查网络统计信息
Netstat -s
驱动配置
存储驱动器只能用于一个OSD。如果其他进程共享驱动器，则顺序读取和写入吞吐量可能成为瓶颈，包括日志，操作系统，监视器，其他OSD和非ceph进程。
在记录完成之前，Ceph不会确认写入，因此在使用ext4或XFS文件系统时，高速SSD对减少响应延迟很有吸引力。相反，btrfs文件系统可以同时读写日志和数据分区。
注意：对驱动器进行分区不会更改总吞吐量或顺序读写限制。将日志分成单独的分区可能会有所帮助，但最好有另一个硬盘的分区。
扇区损坏/碎片硬盘
检查硬盘是否有坏扇区和碎片。这可能导致总吞吐量急剧下降。
MON和OSD共存
监视器通常是轻量级进程，但它们经常调用fsync（），这会干扰其他工作负载，尤其是当Mon和OSD共享驱动器时。此外，如果您同时在OSD主机上运行Mon，则遇到的性能问题可能与以下因素有关：
运行较旧的内核（低于3.0）
Argonaut版本运行在旧的glibc之上
正在运行的内核不支持syncfs（2）系统调用
在这些情况下，同一主机上的多个OSD将相互拖动。他们经常导致爆炸性的写作。