注意你的Ceph集群！没有注意这一点你的集群可能会挂！

睡梦中刚好醒来,瞅了一眼群,发现群里已经炸开了锅,各个重要系统报来宕机的噩耗。 这一晚的大雪，挺有意思。。。

Q了下运维老朋友,说是遇到了个大坑,某几台机器时间走的飞快，基本是每十秒会多出1s的速度。

可不要小看这小小的时间加速,造成的影响是Ceph的集群某几个osd节点down掉,然后早就了开头那一幕。

原因就是因为时间不同步,Ceph节点健康检测应该是失败了(推测)

他的临时办法,只能强制30s 调用一次crontab ntpupdate ,ceph恢复。

这番描述感觉挺有意思，印象中一般配置了 ntp同步，基本不需要再去频繁的配置，麻利的穿好衣服，开始搜索与linux时间相关的 page.

搜索一番感觉除了一个闰秒之坑之外，没有别的地方可以入手,系统时间速度快肯定是时钟频率快了，但是什么导致的就不得而知了。

于是要了下有问题的机器和环境配置: RHEL 7 , 然后crontab 写了临时解决方法 是10s自动 调用ntpupdate 从B机器同步时间，

使用watch -n 1 date命令观察 date变化,发现时间明显要快速与别的正常机器。

此外 我们发现 B机器时间要慢于实际现实世界的时间大概10分钟左右

没有更多的信息了。

抱着试试看的态度，google 了 rhel linux time 相关文章：

https://access.redhat.com/articles/15145

看完这篇文章貌似并没有什么太大相关性: 它讲述了 RHEL 是怎么处理闰秒(可自行百度 谷歌该关键词)

对应于环境 当前RHEL 7版本， 我们除了发现闰秒，还发现官网似乎介绍了一个有别于 ntp服务的东西 叫 chrony

这个chrony干啥的， 百度谷歌发现 它其实是ntp的另一种实现，最重要的我们发现 rhel7/centos7 开始 内置了这玩意。

于是迅速检查了下该机器是否运行该服务:

service chronyd status

其配置文件默认位于 /etc/chrony.conf

内容如下:

这一看基本感觉跟 ntp 配置文件类似, 开头4个地址，查看文档我们发现，chrony有个客户端 chronyc，还有守护进程chronyd

通过　chronyc sources -v得到如下状态:

发现chrony貌似是在跟这3个地址在同步时间,but 这三个地址，我们并没有在配置文件中配置，

那么从哪里来的? 其实配置里比如配置的

这里面包含一个pool基本可以想到这是一个类似LB的地址，实际真正的地址就是上图里的这些，可以理解，chrony 会满世界的找离我们比较近的ntp服务器进行时间同步。

这台rhel7是可以联网的,所以时间是可以同步的。

我们注意到chrony的配置有一项叫 makestep:

通过注释和查阅文档我们知道:

通常，chronyd将根据需求通过减慢或加速时钟，使得系统逐步纠正所有时间偏差。在某些特定情况下，系统时钟可能会漂移过快，导致该调整过程消耗很长的时间来纠正系统时钟。该指令强制chronyd在调整期大于某个阀值时步进调整系统时钟，但只有在因为chronyd启动时间超过指定限制（可使用负值来禁用限制），没有更多时钟更新时才生效

这， 就比较接近事情的真相了

原来chrony真的去干了！ 真的去干了自动调节时钟频率来使本机时间与 配置的几个server差距最小。

然后注意到我们所说的一个情况就是，我们内网的 ntpserver 要比实际现实时间 慢10分钟；

所有的这一切几乎可以解释的通了， 本机时间慢,chrony 觉得你慢了， 得加快点，于是你的时间跑的飞快:

通过chronyc tracking命令得到如下:

经过分析:

ppm：是一个相对变化量，1ppm指百万分之一，也就是相对标称频率的变化量，这个值越小越好，标准是在25ppm以内，都认为是正常现象

chrony 通过比对 和配置的ntpserver，计算出差距，然后动态控制本机系统时钟频率，根据 makestep的参数来调节(加速/减缓);最终让时间趋于 上述的server

有了这样一个东西在内网，而我们的又配置了和内网ntp 同步，内网的时间又慢了10分钟，这就是冲突所在，考虑chrony是 rhel7内置 ，我们不考虑禁用它(即使你禁用它未必管用，因为它配置的时钟频率已经生效了,所以我们该考虑怎么使用chrony,拥抱rhel7的这一变化)

其实很简单喽， 既然是ntp另一种实现,那么把配置的server 换成内网 ntpserver不就哦了？

注释掉外网ntpserver配上内网ntp，重启 chronydservice chronyd restart

再去使用chronyc相关命令，我们发现天下太平了,时间再也不那么快了。

chrony到底如何，设置系统始终频率? 我花了点时间想查看当前 sys clock frequency发现还是不特别好获得, chrony 通过计算会把当前和server的频率误差记录在 driffile文件里,上述默认配置在/var/lib/chrony/drift

然后根据代码https://github.com/mlichvar/chrony/:

嗯,所有一切都解释的通了。。 集群什么的都恢复和平的模样了。注意这是 RHEL7 ,centos7可能也存在该问题

相关文档:

https://access.redhat.com/articles/15145

http://www.techug.com/post/leap-second-cause-linux-down.html

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/sect-using_chrony