平安云存储修真之路

导读

症状

在云存储上线前期，测试验证我们的存储集群性能杠杠，但在系统使用了大约2周时间之后，性能监控发现磁盘写入性能下降了约60%。使用磁盘验证工具对磁盘性能验证，证实磁盘的性能确实下降很多，且每台主机都有一个磁盘利用率持续在90%以上。

诊断

进一步查看磁盘使用进程时，我们发现，除集群自己的程序在使用磁盘外，还有一个系统的Mlocate进程在持续访问磁盘。

Mlocate进程是linux系统用来扫描目录并更新索引，用于快速查询文件用的一个定时job。正常情况下mlocate进程会在很短的时间内扫描完目录并退出，但由于云存储系统的使用特性是会存储大量小于100KB的小文件，同时也会产生大量深度为7的文件目录，造成mlocate job扫描速度越来越慢，最终每天都无法退出job，导致了云存储单盘的利用率持续飚高。

解决方案

鉴于存储服务器本身很少会使用文件查询的功能，我们将所有存储服务器的Mlocate任务禁用。

总结

本例只是所有可能引起集群性能下降的原因之一，但却不失为ceph集群环境的一个重要注意项。除此之外ceph集群搭建涉及的磁盘类型、文件系统格式、内存搭配等环境因素都有可能影响到集群的稳定运行。

症状

集群的监控系统经常告警，提示存储服务器（osd）宕机，但登陆检查发现osd已启动。

诊断

• 查看对应osd的日志，发现日志中记录osd被检测服务器（mon）强制标记为宕机

• 检查mon的日志，查找到对应osd被标记为宕机的原因是该osd的签到检查失败

• 仔细梳理ceph的osd健康检查机制之后发现，osd向mon发送签到信息的时机和mon定期检查osd签到状态的时机把握不当确实可能造成mon错误地认为osd已经宕机

• 检查集群配置，发现当前配置的osd发送签到信息的时间间隔为300s，而mon检查osd是否签到的时间间隔也是300s，存在mon检查不到正常签到信息的可能。

解决方案

将osd提交签到信息的时间间隔调整为120s，保证在一个mon的检查间隔内能有两次osd的签到，避免因网络延迟或其他原因造成mon的误判。

总结

ceph的官网有一个推荐的配置列表，通常缺省配置都是经过社区人员反复验证的，大家没有充分理由不要随意去修改ceph的缺省配置。比如osd签到的时间间隔缺省配置就是120s，但在产品上线初期我们自以为扩大签到的间隔可以减少osd的压力，但实际上两个间隔时间对osd压力的影响可以直接忽略，修改后反而引起了上述问题。

症状

用户反映在创建某些bucket的时候会持续创建失败，创建失败率为5%左右。

诊断

• 通过命令查看集群的健康状态，发现所有服务器运行正常

• 核对最近的变更，在问题发生前一天，我们刚好对ceph软件版本进行了升级，对所有服务都进行了重启。但版本问题不可能造成某一些bucket创建失败，打开了rgw的debug日志也无法取得有用的信息。

• 在没有头绪的前提下，我们开始逐个对osd的日志进行分析，在查看到一个osd的日志时，发现该osd从前一天开始就没有再写日志了，但该osd的进程还在，所以怀疑是前一天升级引起该osd异常

• 执行ceph版本查看命令，确认ceph版本没有问题。在咨询了ceph社区专家之后，利用运行态的命令查看了当前集群的所有模块的ceph版本，发现该问题osd的对应ceph版本居然还是老版本。

解决方案

手动关闭进程并重启osd后，再验证，问题解决。判断是因为当时执行ceph的批量重启命令后ceph进程没有关闭成功，所以新版本的进程一直没有启动。

总结

ceph目前没有一个各模块版本一致性的检查机制，所以在升级版本后一定要手动确认一下各运行态的进程版本是否一致。具体命令为：ceph tell osd.* version

症状

由于有大量的数据需要在短时间内从其它存储系统迁移到云存储中，为了提高数据的写入效率，我们将目标集群的磁盘写缓存都打开了。从性能测试来看，当然是喜大普奔，于是我们开始了迁移。

这时候问题出现了：当磁盘平均写入到20%左右后，集群的写入流量曲线呈现出了连续过山车的趋势，峰值和最低值的差距可以达到5-10倍，磁盘利用率持续增高。

诊断

每个机械盘自带的缓存大约为5-10MB,磁盘会将缓存中的数据连续地写入到磁盘中，在磁盘为空的时候，要寻找到5MB-10MB的连续空间很容易，不过假象过后的真相是当磁盘已经写入很多零散数据之后再去寻找大片连续的空闲空间就会变慢，这个时候还不如让各个文件单独写入。

解决方案

关闭磁盘的写缓存

总结

磁盘本身的写缓存是没有数据保护功能的，而且ceph 本身有journal缓存的机制，所以在搭建存储服务器的时候完全没有必要开启磁盘本身的写缓存。