一个关于Ceph的slow request问题

        刚进公司的第三天，接到一个关于ceph稳定性的攻关任务。公司内部集群采用k8s的部署模式，用ceph来做存储模块。ceph是5node、3monitor的集群。

         同事描述了几个现象，1、mysql访问偶现夯住，服务端直接报错，由于涉及线上业务已切换至虚拟机部署的mysql，问题消失  2、部署在k8s的efk集群也是采用ceph的rbd块作为后端存储，基于rbd的IOPS会突降为0，efk不可用，过几分钟服务恢复 3、ceph-mds.log偶尔会报slow request的日志

          由于之前没有使用ceph，当时的我一脸懵逼，但是问题排查思路还是通用的，我决定一边查看ceph的文档一边复现问题。slow request由于出现频率较低，也没有复现方案，暂时搁置。先复现mysql和efk的问题。

           Mysql这边，由于只有pod集群的监控，没有rbd的监控，在查看了grafana发现，出现mysql不稳定的时候，mysql和mysqlexporter(mysql的promethues采集器)的流量均变成0，前后的负载均没有大的波动。参照这个现象，我决定用mysqlslap先对数据库做单独的压测，尝试复现问题，但是在压了两天之后没有复现，于是拉开发进行服务端的压测，同时接入rbd的监控，很遗憾的是问题还是没有复现。

           正当一筹莫展的时候，efk集群的IOPS问题倒是每天都出现，不妨换个思路先定位这个问题。这边问题是每天出现，但是日志太少了, 只有mds的日志里有偶尔的slow request日志，和问题出现并不是强相关。所以第一步想办法打印更多的日志。参照官方文档 http://docs.ceph.org.cn/rados/troubleshooting/log-and-debug/ 把debug_osd的日志等级打印到了5/5，并把所有的ceph收集到了efk集群方便查看。当问题再次出现的时候，我查看的5台机器的负载和io，都是比较低的水平，由于出现问题的时候没法使用efk，osd的日志又很分散没法查看，所以只能查看主机上有没有异常，我又查看了主机的dmesg信息和系统日志，果然在/var/log/messages下面有所发现，我发有两台机器在疯狂的打以下日志:

Nov 10 03:53:13 db-16-2-hzxs ceph-osd: 2019-11-10 03:53:13.599 7f49b2c9f700 -1 osd.35 4443 get_health_metrics reporting 1 slow ops, oldest is osd_op(client.67215.0:60910421 7.c 7:306feb75:::rbd_data.fea92572485c.000000000001db2a:head [zero 0~40960] snapc 149=[149,138,128,118,108,f8,e9,da,cb,bc,ad,9e,8f,80,71,62,53] ondisk+write+known_if_redirected e4443)

我翻阅了之前出现问题的时间段，都有类似的日志，只是osd编号和最后的e4443会有所变化，等efk恢复查询之后，我在efk查询了get_health_metrics关键，果然在两个节点发现大量的相同日志，那rbd的不可用很可能是这两个节点导致的，但是为什么就这两个节点报错呢。我问了部署ceph集群的同学节点之间有什么差异，果然这两个节点的内核版本和ceph版本和其他三个节点都不一样，这是一个重大的信息点。接下来就能用排除法去解决问题了。首先升级了一个正常节点的ceph至14.2.4，和异常节点的ceph保持一致，但是问题再次出现依然是原来的两个节点报错。然后我们降级了一个异常节点的内核版本，从3.10.0-957.27.2.el7降到了3.10.0-957.12.1.el7，和正常节点保持一致，重启机器，问题消失。

           降级内核后到发稿时efk尚未出现问题，mysql也没有出现问题，至于为什么还有一个节点没有升级但是依然不报错，我猜可能是OSD写入的时候需要2个osd同时写入失败才会失败，后面等ceph功力再深一层次再去探究。整个排查过程差不多持续了一周，主要查阅的文档是官方文档 http://docs.ceph.org.cn/start/intro/ 和这篇博文 https://lihaijing.gitbooks.io/ceph-handbook/content/Troubleshooting/troubleshooting_osd.html 。当然这可能还不是最后的结论，我也把日志发送给了社区，希望他们给我答疑 ，但是从接触问题到升级内核解决的过程还是想记录和分享给大家 : )   最后大家部署开源软件的时候还是建议部署在官方推荐的硬件和软件版本上，以免踩不必要的坑。