本文主要是介绍OSD故障排除，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
OSD故障排除
在调试你的OSD之前，先检查监视器和网络。当你执行ceph health或ceph -s命令后，正常情况下Ceph会返回一个健康状态，表明监视器具有一个Quoram。如果返回错误信息，首先应排除监视器自身问题。确保网络正常运行，因为网络对OSD操作和性能有显著影响。
获得OSD数据
在调试OSD时，除监视OSD得到的反馈信息外，还应尽可能获得更多的信息。(比如, ceph osd tree).
Ceph日志
如果未修改默认路径，你可在/var/log/ceph目录中找到Ceph日志文件：
ls /var/log/ceph
如果日志未提供足够多的细节，你可以更改日志级别。请参看“日志和调试”章节内容，确保Ceph在记录大日志文件时，仍能保持足够的性能。
管理套接字
管理套接字工具可用于收集实时运行信息。如下命令可显示Ceph进程可用套接字：
ls /var/run/ceph
然后，将命令中的{socket-name}替换为真实的套接字名称，执行该命令将列出可用选项:
ceph --admin-daemon /var/run/ceph/{socket-name} help
在这些套接字中，管理套接字可实现
列出运行时配置
存储历史操作
存储操作操优先队列状态
存储传输中的操作
存储perfcounters值
显示空闲空间
文件系统故障发生时，可先使用df命令查看系统可用空间
df -h
执行df --help可显示其它用法
I/O统计
可使用iostat命令识别I/O相关问题.
iostat -x
诊断信息
将dmesg与less、more、grep或tail联合使用，有助于更有效的获取有价值诊断信息。
dmesg | grep scsi
关闭重平衡
你可能需要定期对集群中某个子网进行例行维护，或者要解决某个域内的问题。当你停止OSD时，默认情况下CRUSH机制会对集群自动重平衡，可将集群设为noout关态将之关闭：
ceph osd set noout
当集群设为noout状态后，再开始关闭域中需维护的OSD。
ceph osd stop osd.{num}
注意：当你对失败域中OSD维护时，其中的PG将会变为degraded状态。
结束运维后，记得重启OSD。
ceph osd start osd.{num}
最后，务必取消集群的noout状态。
ceph osd unset noout
OSD无法运行
在正常环境中，简单的重启ceph-osd服务即可让它重新加入集群并恢复。
OSD无法启动
当集群启动时，如果有OSD未启动，请检查如下信息：
配置文件：新安装的OSD无法启动，先检查配置文件，确保已正确配置(如主机，主机名等)。
检查路径：检查配置文件中的路径是否与实际相符。在将OSD数据和日志分开存储时，如果配置文件或挂载点存在故障，启动OSD时都将面临困难。如果你想在块设备上存储日志，请先对块设备分区格式化，并为每个OSD指定一个分区。
内核版本：识别出你正在用的内核版本和发行版。Ceph默认使用的一些第三方工具可能与特定发行版或内核版本冲突。
段错误：收到段错误提示时，如果未打开日志，请先打开。然后重新执行，问题依旧的话。请联系ceph-devel邮件列表，并附上你的Ceph配置文件，监视器输出和日志文件。
如果你无法解决问题同时邮件列表也无法提供帮助时，你可联系Inktank寻求支持。
一个OSD失败
当ceph-osd进程意外终止时，监视器可以从ceph-osd服务的残留进程中获取失败信息，并通过ceph health命令提交。
ceph health
HEALTH_WARN 1/3 in osds are down
值得说明的是，任意一个ceph-osd进程被标记为启动或关闭时，你都会收到一条警告信息。可通过如下命令识别关闭的ceph-osd进程:
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
当存在磁盘错误或其它严重问题影响ceph-osd正常工作或重启时，一条错误信息将被提交到/var/log/ceph日志文件中。
如果心跳检测失败引起进程终止，存放内核的文件系统可能会无法响应。检查dmesg输出排除磁盘或其它内核错误。
如果问题是软件错误（如failed assertion等未预料错误），可将之报告给ceph-devel邮件列表。
无空闲空间
ceph会阻止往已满的OSD中写入数据，以可避免数据覆盖丢失。在生产集群中，当集群接近写满前，你将会收到警告信息。OSD全满比例默认为0.95，此后它将阻止客户端继续写入数据。OSD将满比例默认为0.85，随后它将生成一条健康警报。
在小型集群中测试Ceph如何处理OSD失效时，常会发生集群写满故障。如果某个节点数据存储百分比过高，集群可将之快速分流转移至其它空闲节点，使其存储比率迅速回落。因此在测试时，应预留足够大的富余磁盘空间，并将OSD全满和将满比率临时下调。
ceph health可显示全满的ceph-osd
ceph health
HEALTH_WARN 1 nearfull osds
osd.2 is near full at 85%
或：
ceph health
HEALTH_ERR 1 nearfull osds, 1 full osds
osd.2 is near full at 85%
osd.3 is full at 97%
全满集群的最佳解决方案是增加新的ceph-osd，使得集群可将数据重分发到新的可用存储上。
如果因为集群写满而无法启动OSD，你可通过删除全满OSD中的部分PG路径以实现数据的删除。
重要：当你删除一个全满OSD中的某个PG时，不要在另一个全满OSD中也将这个PG删除，否则你将丢失数据。你必须至少在一个OSD中保留该PG备份。
可参看“监视配置引用”查看更多细节。
OSD过慢或无响应
另一类常见问题可能涉及过慢或无响应的OSD。在解决OSD性能问题之前，先确保其它问题已排除完毕。例如，确保网络和OSD都正常运行。另外检查OSD是否正节流恢复流量。
建议：新版本的Ceph提供一个更佳的恢复机制，可避免从正在运行的OSD复制资源，因此不会对当前运行的OSD造成影响。
网络故障
Ceph是一个分布式存储系统，它依赖于底层网络进行OSD配对、对象复制、故障恢复和心跳检测。网络故障可导致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文件系统则可以将数据和日志同时写入。
注意：对磁盘分区将不会改变它的总吞吐量或读写序列限制。将日志放在独立分区上将有助于提高性能，但前提是这个分区处于独立磁盘上。
磁盘坏道
检查你的磁盘是否有损坏磁头或磁道，这可能会导致吞吐量的突然下降。
共存监视器/OSD
监视器通常是轻量级进程，但是它们使用了很多fsync()调用，以便和其它工作负载通信，特别是当你在同一个磁盘上运行OSD和监视器时。此外，如果你在同一台主机上运行监视器和OSD，你可能会因下述问题面临性能问题：
运行老旧内核(3.0之前)
运行老旧glibc
运行不支持syncfs系统调用的内核
在这些情况中，同台主机上的多个OSD进程会由于过多的提交，而相互拉低性能。这通常会导致大量的突发写入。
共存进程
在相同硬件上运行OSD进程及其它共存进程，如云应用、虚拟机等，当同时进行写操作时，OSD可能会面临极大的延迟。通常，我们建议为不同应用部署单独的主机，这有助于提升性能和简化排错。
日志级别
如果你在排错时临时提高了日志级别，但事后忘了复原，OSD将会向磁盘写入大量的日志文件，这就显著降低OSD性能。如果你确实希望保持高的日志级别，可考虑将日认默认路径指向单独的磁盘上(如var/log/ceph/$cluster-$name.log等)。
恢复节流
根据配置文件不同，Ceph可能会降低恢复速率以保持性能，如果OSD利用率过低，Ceph同样也可能会提高恢复速率。检查OSD是否属于恢复状态。
内核版本
检查正在使用的内核版本。老旧的内核可能不会收到新的更新补丁，这也能会影响Ceph性能。
内核syncfs故障
在每个主机上仅运行一个OSD，观察性能是否有所提升。老旧内核可能不支持较高的glibc版本，以致于无法启用支持syncfs(2)。
文件系统故障
当前，我们建议在集群中使用XFS或ext4文件系统。Btrfs文件系统具有很多极具吸引力的特性，但它还处于开发状态，过多的bug极可能导致性能问题。
内存不足
我们建议为每个OSD服务分配1G内存。你可能注意到在日常操作中，OSD可能仅使用了部分分配内存(如100～200MB)。OSD会将未使用内存作为预留内存，以供后台各种应用使用，如VM等。但是当OSD进入恢复模式后，内存将很快耗尽。一旦无可用内存，OSD性能将显著降低。
请求过期或过慢
如果OSD服务对某个请求响应过慢，它将会生成关于此请求的详细日志。默认警告阀值为30秒，可通过osd op complaint time命令进行修改。当此类问题再次发生时，集群日志将会收到警告信息。
旧版本Ceph关于“过期请求”日志:
osd.0 192.168.106.220:6800/18813 312 : [WRN] old request osd_op(client.5099.0:790 fatty_26485_object789 [write 0~4096] 2.5e54f643) v4 received at 2012-03-06 15:42:56.054801 currently waiting for sub ops
新版本Ceph关于“慢速请求”日志:
{date} {osd.num} [WRN] 1 slow requests, 1 included below; oldest blocked for > 30.005692 secs
{date} {osd.num} [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]
可能原因包括：
磁盘损坏(检查dmesg输出)
内核文件系统漏洞(检查dmesg输出)
集群过载(检查系统负载，I/O状态等)
ceph-osd服务漏洞
可用的解决方法
从ceph主机上移除VM云方案
升级内核
升级Ceph
重启OSD
OSD翻转
我们建议同时使用公网(前端)和集群私网(后端)，以更好的符合对象复制时的性能要求。另一个优势是在集群私网中，将不会受到来自互联网上的拒绝服务攻击(译者注：即常说的DoS和DDoS攻击)。当OSD配对或检查心跳时，它都会优先选择集群私网，除非集群私网不可用。可查看"监控OSD联系”章节了解更多细节。
但是，当集群私网断线或延迟过高而公网正常工作时，OSD会无法很好的适应这种情况。ISD将在监视器上将自身标记为“关闭”，但下一刻又将自身标记为“启动”。我们将这种情景称之为翻转。
当OSD陷入翻转状态时(重复标记为关闭和启动)，你可通过如下方法强制监视器停止翻转：
ceph osd set noup # prevent osds from getting marked up
ceph osd set nodown # prevent osds from getting marked down
这些标志符将会记录在osdmap中:
ceph osd dump | grep flags
flags no-up,no-down
你可通过如下方法清除标志符:
ceph osd unset noup
ceph osd unset nodown
Ceph还支持另外2个标志符，noin和noout，前者阻止启动的OSD被标记为in，后者阻止标记为out的ceph-osd进程关闭()。
注意：noup、noout和nodown都是临时性的，一旦标志符为清除，它们所阻止的操作将随之执行。而noin则是另一种情况，在标志符设定后启动的任何进程都将得到保留。
这篇关于OSD故障排除的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
