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

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/itest_2016/article/details/79197939

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


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 这三个地址,我们并没有在配置文件中配置,

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

server 0.rhel.pool.ntp.org iburst


这里面包含一个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,重启 chronyd service 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


展开阅读全文

没有更多推荐了,返回首页