Linux 基于chrony进行时钟同步方案验证

chrony是一个Linux系统中用于时钟同步的工具。它使用NTP（网络时间协议）来与远程时间服务器进行通信，从而使系统的时钟保持准确。
chrony具有一些特性，使其成为时钟同步工具的首选：

• 精准度：chrony能够以亚毫秒级的精度同步系统时钟，确保时钟的准确性。
• 动态时钟频率调整：chrony具有自适应的时钟频率调整机制，可以根据网络延迟和计算机负载等因素动态地调整时钟频率，以保持时钟的稳定性和准确性。
• 持久追踪：chrony能够在计算机重启后快速同步时钟，不需要等待很长的时间。
• 多服务器支持：chrony可以同时与多个时间服务器通信，并根据服务器的可用性和准确性进行选择。
• 使用chrony进行时钟同步的步骤如下：
• 安装chrony：在Linux系统上使用适当的包管理工具安装chrony。
• 配置chrony：编辑chrony配置文件，指定要使用的时间服务器和其他参数。
• 启动chrony：启动chrony服务，使其开始同步系统时钟。
• 验证同步状态：使用chronyc命令检查系统时钟与时间服务器的同步状态。

通过使用chrony进行时钟同步，您可以确保您的系统时钟与全球标准时间保持一致，以确保系统操作的准确性和一致性。

1. 背景介绍

生产环境中，经常出现部分节点时钟跟时钟源不一致的现象，需要平滑的同步时钟，因此本主要探讨chrony模式下的平滑同步时钟的相关方案和测试验证过程。

10.30.15.189 10.30.15.159 时间同步，但是比时钟源慢20秒左右。测试的目标是，希望10.30.11.159 完成时钟同步，并不产生时钟跳变。

ntp clent ntp server 同步正常，无时间误差

ntpserver 同ntp上游相差20秒左右

2. 验证过程

2.1 追踪配置

1. ntpserver部署chrony

yum -y install chrony

2. 修改chrony配置(/etc/chrony.conf)
   该配置大概30分钟追1秒。

###此处不复制，这个配置大概30分钟追1秒
server gps_1 iburst
server gps_2 iburst
stratumweight 0
driftfile /var/lib/chrony/drift
rtcsync
makestep 9999999999 1
maxchange 9999999999 1 1
bindcmdaddress 127.0.0.1
bindcmdaddress ::1
keyfile /etc/chrony.keys
commandkey 1
generatecommandkey
noclientlog
logchange 0.5
logdir /var/log/chrony
maxupdateskew 500
maxslewrate 500

参数说明

• stratumweight是一个配置选项，用于确定本地时钟和远程服务器时钟之间的权重比例。该选项影响系统时钟同步的行为。具体来说stratumweight用于计算本地时钟和远程时钟的加权平均值，以确保在使用多个时间源时，更可靠的时钟源所提供的时间更为重要。通过调整stratumweight，可以调节不同时间源对系统时钟同步的影响程度。

• driftfile是一个配置选项，用于指定一个文件来存储本地系统时钟漂移的估计值。时钟漂移是时钟偏离准确时间的速率，它是由于时钟的不准确性而导致的。当Chrony服务运行时，它会持续地监测本地时钟的漂移，并将漂移的估计结果写入driftfile中。这样做有助于Chrony在重新启动时更快地调整本地时钟，提高时钟同步的准确性。

• rtcsync是一个配置选项，用于指定是否应该尝试使用硬件时钟（Real Time Clock，RTC）来改善系统时钟的准确性。启用rtcsync可以让Chrony尝试使用RTC来纠正本地时钟的漂移，从而提高时钟同步的准确性。这对于那些没有持续连接到网络的系统尤其有用，因为它们可以依赖RTC来帮助保持时钟的准确性。

• keyfile是一个配置选项，用于指定包含身份验证密钥的文件的路径。这些密钥可用于对NTP客户端和服务器之间的通信进行加密和身份验证。通过keyfile，用户可以定义用于安全通信的密钥，以确保通信的保密性和完整性。

• bindcmdaddress是一个配置选项，用于指定Chrony守护进程监听命令的网络地址。通过设置bindcmdaddress，用户可以指定Chrony监听命令的网络接口和端口。这使得用户可以通过网络发送命令以控制Chrony守护进程，例如查询状态、手动触发时钟校准等操作。

• commandkey: 用于指定用于对chronyc命令进行身份验证的密钥。

• generatecommandkey: 用于生成新的commandkey密钥。

• noclientlog: 禁用客户端的日志记录。

• logchange: 记录系统时钟状态的变化。

• logdir: 指定Chrony日志文件的目录路径。

跟追时钟相关的参数如下

• makestep是一个配置选项，用于指定是否允许时钟调整时可以进行"大步调整"。当makestep选项被启用时，Chrony可以在需要时一次性调整系统时钟，而不是逐渐地调整，以便更快地将系统时钟与参考时钟同步。这在某些情况下可能是有用的，但需要谨慎使用，因为大幅度的时钟调整可能会对系统和应用程序产生影响。配合maxchange、maxslewrate、maxupdateskew使用，能够规避时钟突然跳变

• maxchange是一个配置选项，用于指定系统时钟每秒允许的最大变化量。当系统时钟与参考时钟之间的偏差超出此限制时，Chrony会限制时钟调整的速度，以避免系统时钟的突然大幅度调整。这有助于稳定地调整系统时钟并减少对系统和应用程序的潜在影响。配合makestep、maxslewrate、maxupdateskew使用，能够规避时钟突然跳变

• maxslewrate 500
  当设置"chrony maxslewrate 500"时，这表示系统时钟的最大调整速率为500 PPM（parts per million）。这意味着系统时钟每秒最多可以调整500微秒。

• maxupdateskew 500
  当设置 maxupdateskew 设置为 500，这意味着系统时钟可以在 500 毫秒内进行连续更新

3. 编辑chrony服务配置文件/usr/lib/systemd/system/chronyd.service, 注释掉这行

   #Conflicts=ntpd.service systemd-timesyncd.service
   

4. 重载systemd配置

   systemctl daemon-reload
   

5. 启动chronyd

    systemctl start chronyd
   

6. 检查ntpd和chrony 状态是否正常

   systemctl status chronyd  ntpd
   

7. 这样chrony负责向ntp源同步时间回来，逐步修正ntpserver时间准确性，ntpd负责向下游ntp client 同步时间，下游的时间也会间件追平

8. 再次检查ntpsever 和ntp上游时间差
   

9. 确认chrony 开始工作

   # 查看同步频率情况
   chronyc tracking -v
   
   # 查看同步情况
   chronyc -n sources -v
   

   

2.2 追平记录

1. 开始同步以后误差23.84s
   

2. 同步3小时左右
   

3. ntp client 同ntpserver 相差达到1秒，避免ntp客户端出现跳变（调整chrony追平速度 maxslewrate 200 ）
   

4. 修改配置重启了chrony以后，大概又过了4个小时左右
   

5. ntp client 已经追平ntp server
   

6. 又同步大概21个小时，已经只有很小的误差了
   
   客户端无异常
   

7. 重新等待了36小时以后，误差已经是正常水平了
   

8. ntp client 也无异常
   

9. 查看ntp客户端跳变历史
   

可以看到在chrony参数较大的时候客户端也发生过较大时间的跳变（超过1秒）
在修正chrony参数为200的时候客户端也发送过几次跳变，但是时间都比较小了

结论：

• 如果时间误差较小，可以将参数设置较小，同步时间会比较长，不易发生跳变，或者发生跳变误差也很小
• 如果时间误差较大，也可以将时间参数设置较大，缩短同步时间，但是跳变的时间会略大

2.2 追平时间换算

简单计算追踪1s的时间
$$追踪1s的时间=1s/maxslewrate(微秒)$$

设置200 大概1个多小时多走1秒
设置500，大概就是半个小时多走1秒

通过检查同步日志验证

• 当前时间比时钟源落后
  

• 当前时间比时钟源提前
  
  28min追0.8908579999999802s，跟计算整体一致。

3. 疑问和思考

3.1 如何统计追踪1s需要花费多长时间？

简单计算追踪1s的时间
$$追踪1s的时间=1s/maxslewrate(微秒)$$

常规的配置如下

• 设置200 大概1个多小时多走1秒
• 设置500，大概就是半个小时多走1秒

4. 参考文档

暂无