技术解析

大家是如何解决 Linux 下的时间问题的?
0
2021-07-16 18:13:29
idczone
Linux下面有二个时间,一个系统时间,一个Bios时间
随着系统运行的时间越长,系统时间与"真实"时间相差越来越大
由于业务的原因,不能进行同步等操作,大家有没有遇到这样的问题?
请教大家是如何解决这样的呢?
[[email protected] ~]# date
Fri Jul 25 10:12:14 CST 2014
[[email protected] ~]# clock
Fri 25 Jul 2014 10:17:52 AM CST -0.031876 seconds
使用ntpdate us.pool.ntp.org同步时间
将ntpdated加入开机启动chkconfig
RHEL系列。

因为你有业务,不能修正系统时间,那么把定时把系统时间同步到rtc里去。
`hwclock -w`
但是不知道哪个时间是对的,建议还是使用ntp同步,大家都好


兄台,业务原因不能使用时间同步

哦哦,那你希望以哪个时间为主呢?是不是想修改BIOS时间呢?

服务器使用的话,我推荐 ntpd。
ntpdate 每次运行是直接把时间与上游时间服务器同步的,假如相差太多的话,一次性更改太大,可能会影响一些对时间敏感的程序的运行,或者至少在各种日志里面会出现比较奇怪的时间。
ntpd 作为守护进程运行,会与上游时间服务器保持通讯,默认行为是尽量平滑地同步时间,感觉效果更好。
Linux 下面最著名的 ntpd 实现就是 http://www.ntp.org 自家的了,各发行版的软件库里面应该都有自带。
我现在用的是 http://www.openntpd.org 的 OpenNTPD(Debian 8 里面官方软件库里还没有,我装的是 Debian unstable 里的);不用 ntpd 的原因主要是 ntpd 默认会监听一个端口,关不掉,只能在软件配置里面设置了禁止外来的查询,看着烦……

同样遇到这个问题,不能联网的机器在机房若干年后时间就差很远了




不是想修改Bios时间.
程序都是读的系统时间吧?初次安装的机器可以同步时间再加入到业务中去
加入之后再同步的话就会导致崩溃,业务非常依赖时间.
刚才查了下资料,貌似还没有好的解决方法
http://tldp.org/HOWTO/Clock-2.html

ntpd必须的啊
然后相关服务程序全部用UTC时间,这样就什么问题都没有了

ntpdate 是直接跳到当前时间, 可能对业务造成影响, 不推荐.
而 ntpd 可以在误差小于 600s 时是极小粒度的调整(默认约 0.5ms/s), 所以一般不会有什么问题. 更多信息可以看 man ntpd.

系统启动时从rtc读取系统时间,然后os自己维护系统时间,和rtc就没关系了,你说业务不能同步时间,是指不能修改时间吧,但同步到rtc里去应该没影响阿。
只不过这个时间是以你的系统时间为基准,所以和实际时间不一定准了。

可以内网同步的, 只要一台机器或者路由和外面同步就行了.

如果能连内网的话 用htpdate获取内网开了http服务的机器的时间,很好用


抱歉,可能是我没有表达清楚...
客户的业务依赖于系统的时间,如果系统时间不准的话,用户会经常反映
但是架构上又不能修改时间,修改时间的话会导致集群崩溃

但是架构上又不能修改时间,修改时间的话会导致集群崩溃
哪有这样的架构设计,这不是自己给自己添堵么?只要SVR超过一台,那就必须有一个ntp server,自建或者用通用的服务都ok,其他机器从时间服务器得到时间,保证所有ip时间一致。没其他更好的办法了

这样就只有ntpd一个办法了, 可以内网同步, 提高polling的频率, 每次只是修改很小的偏差, 应用里是看不出差别的, 还可以保证内网的所有机器时间同步


所以就用 ntpd 啊,它是在后台极小粒度慢慢调整时间的,比如你的时钟慢了 10 s,它可能会花上几个小时的时间,每次调零点几毫秒,来把时间调成同步的(具体策略应该可以设置)。正常的服务器集群时间同步都是用这个的吧,再精细的需求估计就要给每台机器配个独立的原子钟了 :)

集群时间也要同步的吧?

难道 ntp 不是服务器标配?

debian+ntpd啊. 这个应该是标配吧

无补偿的晶振,误差在几十到几百ppm。计算机的钟不够准,我都不敢不开ntp服务。这项服务,在Debian和Ubuntu发行版里默认处于开启状态。默认不安装ntp的发行版,都是极其不靠谱的发行版。
内网时间同步,用ptp协议。与全世界同步,用ntp协议。
另外就是好多人校正时间采用ntpdate(8)的方式,不知道是从哪里看到这么用的。难道是RH的培训材料?
刚启动服务时,ntpd也会产生一次时钟跳变。启动后,不会出现高至10s的偏差,除非晶振坏了。






感谢各位,现在还无法判断用ntpd是否可行,只有新建集群的时候测试了

还有从架构上无法同步时间的集群???这么牛逼。。。


是的,集群中有控制器,依赖于时间
刚才测试修改时间,直接导致控制器认为主机脱离集群


求科普...


翻了一下man
貌似只有一个同步的时间超过1000S的告警
不知道说的小粒度是如何实现的

所以说你整个集群的时间都是错的?!Orz给跪了。。。集群中居然不放时间同步服务器。。。

小粒度更新是 ntpd 的默认行为啊。


感谢
-x Normally, the time is slewed if the offset is less than the step threshold, which is 128 ms by default, and stepped if above the threshold. This option sets the threshold to 600 s, which is well
within the accuracy window to set the clock manually. Note: Since the slew rate of typical Unix kernels is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s.
Thus, an adjustment as much as 600 s will take almost 14 days to complete. This option can be used with the -g and -q options. See the tinker command for other options. Note: The kernel time disci-
pline is disabled with this option.

ntpd,关键是平滑的。

上时间同步设备,暂停集群,同步。和运营确定好方案先。

推荐阅读:
RTC 与 NTP - delphij's Chaos : https://blog.delphij.net/2010/08/rtc-ntp.html
AsiaBSDCon上说OpenBSD的sensor framework的时候的一个观点 [为什么不用ntpdate,而要用ntpd] - delphij's Chaos : https://blog.delphij.net/2007/03/asiabsdconopenb.html

是不是编译内核的时候 rtc 没选啊~~~一般不会相差特别大吧~~~

数据地带为您的网站提供全球顶级IDC资源
在线咨询
专属客服