1. 时间不同步出问题的往往是你最想不到的地方先说一个我压箱底的排查经历。前几年维护一套内部业务系统每到凌晨两点左右就会出现短暂的服务不可用日志里全是证书校验失败和 token 过期报错。查了几天找不到规律后来无意中发现服务器系统时间比真实时间快了将近三分钟而且偏差还在逐日增大。后来才意识到问题根源不是业务代码也不是中间件配置而是这台机器根本没做过 NTP 时间同步。这类事在实际运维里特别常见而且越隐蔽越致命。时间偏差对系统的影响往往是延迟显现的TLS 证书校验对时间敏感差几分钟直接握手失败数据库主从复制依赖时间戳排序偏差可能导致冲突日志采集和告警分析系统里时间错乱会让排障链路完全断裂更不用说定时任务、消息队列、分布式锁这些对时间一致性有强依赖的组件。很多团队在搭建环境时把精力全部放在业务部署上唯独忽略了基础的时间同步结果埋下一颗随时会爆的雷。这篇文章围绕 Linux 系统下的 NTP 时间同步把原理、部署、配置、验证和排障一次讲透。无论你用的是 CentOS、Ubuntu 还是国产化系统只要底层是 Linux这套思路和命令基本通用。我会把重点放在实际操作上包括我踩过的坑和现在仍然在用的检查习惯希望能帮你在自己环境里少走弯路。2. NTP 不是简单对个表理解分层机制才能排对错2.1 NTP 到底在同步什么很多人以为 NTP 就是把服务器时间改成标准时间其实没那么简单。NTPNetwork Time Protocol真正做的是持续校正系统时钟的走时速率而不是一次性把时间设对。这里有个关键概念叫走时漂移。每台服务器的硬件晶振都有制造误差和环境温度影响导致它每秒走的量和真实时间不完全一致。有的机器一天慢几十毫秒有的机器一天快几百毫秒长期积累就成了几分钟的偏差。NTP 客户端会周期性地从时间服务器获取参考时间计算出本机时钟的偏移量和漂移率然后平滑调整而不是粗暴地跳变。这也是为什么 NTP 同步完成后你很少看到秒针猛跳一下而是系统时间在不知不觉中被校准。2.2 分层结构决定了时间怎么一级级传下来NTP 使用分层的树状结构来组织时间来源层级用 stratum 表示。层级含义常见来源Stratum 0原子钟、GPS 时钟等硬件时间源铯原子钟、GPS/北斗授时模块Stratum 1直接连接 Stratum 0 的时间服务器国家授时中心的服务器、各大云厂商的 NTP 节点Stratum 2从 Stratum 1 同步时间的服务器企业内部 NTP 服务器、普通公共服务节点Stratum 3 及以下从上一层同步的客户端普通业务服务器、办公电脑层级越低离权威时间源越近精度越高。但同时要注意层级越低也意味着一旦上游故障受影响的范围越大。所以在企业环境里通常的做法是内网搭一台或两台 NTP 服务器Stratum 2统一从公网权威源同步然后内网所有机器都指向这台服务器。这样做的好处一是节省公网出口带宽二是内网机器的时间源一致彼此之间的时间偏差小到可以忽略。2.3 一个让很多人困惑的点NTP 和时区NTP 同步的是 UTC 时间协调世界时不负责时区换算。系统显示的本地时间 UTC 时间 时区偏移。所以你在配置 NTP 之前应该先确认系统的时区设置是否正确。我见过不少案例NTP 同步明明正常date命令打印的时间却不对最后发现是时区设成了 UTC 而不是 Asia/Shanghai。检查时区用这个命令timedatectl status如果发现时区不对修改方式以设置为中国标准时间为例timedatectl set-timezone Asia/Shanghai并且建议开启时间自动同步能力timedatectl set-ntp truetimedatectl set-ntp true在较新的系统上会自动激活 systemd-timesyncd 或 chrony具体取决于发行版和配置这一点后面会细说。从同步原理上可以提炼一条结论NTP 解决的是时间准不准的问题时区设置解决的是时间显示对不对的问题两者职责不同缺一不可。3. 用 chrony 还是 ntpd先想清楚再动手3.1 ntpd 和 chrony 的定位差异传统 Linux 服务器上最经典的时间同步方案是 ntpd这是 NTP 项目官方提供的守护进程历史悠久、生态成熟。而 chrony 是后起之秀现在已经是 RHEL/CentOS 8、Ubuntu 18.04 之后各主流发行版的默认方案。很多从 CentOS 6/7 时代过来的运维习惯性安装 ntpd这个选择本身没错但如果你在新的发行版上同时启动 systemd-timesyncd、chronyd 和 ntpd 三个服务就会发现端口互相抢占日志里全是冲突报错。所以我建议先理清自己的场景再选择。对比项ntpdchrony同步精度高但收敛较慢高而且收敛极快网络波动适应能力一般频繁断网场景表现不佳专门针对不稳定网络做了优化虚拟机和云主机支持较差时钟跳变时容易异常目前对频繁挂起/恢复的虚拟机支持良好配置文件位置/etc/ntp.conf/etc/chrony.conf状态查询命令ntpq -pchronyc sources -v系统资源占用略高更低如果你是维护老系统或者有历史脚本依赖 ntpq 的输出用 ntpd 没毛病。如果是新部署环境特别是云服务器和虚拟化环境直接上 chrony这是当前损耗最小、体验最平滑的路线。3.2 为什么云服务器和虚拟机强烈建议 chrony云服务器有一个天然痛点CPU 会被宿主机调度随时可能被暂停。llvm 一暂停虚拟机的 clock 就会发生跳变ntpd 对这种快速跳变的处理方式往往是缓慢调整甚至误判为异常而 chrony 在检测到大幅跳变后能更快地修正。另外如果你的服务器是双机热备或集群架构各个节点的时间偏差越小越好chrony 的快速收敛能力在这种场景下非常有价值。我在实际项目里处理过一台物理服务器和两台虚拟机的组合物理机用 ntpd虚拟机用 chrony三台机器互相做业务交互。运行半年下来虚拟机的偏差基本都在毫秒级反而物理机在换过主板电池后出现了一次较大的时间回退。所以说选型不是越老越稳而是要适配运行环境。3.3 chrony 配置文件的常用写法以主流的 RHEL 系和 Debian 系系统为例安装完成后主要配置都集中在/etc/chrony.conf。下面是一个适合内网环境使用的典型配置# 上游时间服务器可选择国内公共 NTP 节点 server ntp.aliyun.com iburst server ntp1.aliyun.com iburst server time.windows.com iburst # 允许本机作为内网时间源时哪些网段的客户端可以来同步 allow 192.168.1.0/24 # 记录时钟漂移率的文件 driftfile /var/lib/chrony/drift # 如果服务器端时间偏差过大加快校准速度 makestep 1 3 # 开启 RTC 实时时钟同步支持 rtcsync逐行说说重点server后面的iburst参数很关键。不加这个参数chrony 在启动时只会发送一个请求包如果网络慢要等很久才能完成首次同步加了之后启动时会在短时间内连续发送多个请求快速拿到结果实测下来首次同步时间可以从几十秒缩短到几秒。allow字段只在你打算让这台服务器作为内网时间源时才有意义。如果所有机器都直接连公网 NTP这个字段可以不加。makestep 1 3表示当系统时间与参考时间偏差超过 1 秒时以步进方式直接调整时间而不是慢慢微调并且这个规则在启动后的前 3 次同步中生效。这是为了避免刚启动时系统时间偏差过大、需要等很久才能微调到位的问题。rtcsync让系统定期把内核时间写回硬件时钟防止重启后时间又跳回错误值。修改完配置文件后重启服务并设为开机自启systemctl restart chronyd systemctl enable chronyd3.4 ntpd 的配置要点如果确定要用 ntpd配置文件在/etc/ntp.conf核心部分大同小异server ntp.aliyun.com iburst server ntp1.aliyun.com iburst restrict default nomodify notrap nopeer noquery restrict 127.0.0.1 restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap driftfile /var/lib/ntp/driftrestrict段用来做访问控制默认规则建议保持严格。nomodify表示客户端不能修改本机配置notrap禁止 trap 远程事件日志nopeer阻止建立对等关系noquery禁止远程查询状态。生产环境的 NTP 服务器上这些限制尽量都加上避免被内网其他机器利用。启动方式同样是用 systemctlsystemctl restart ntpd systemctl enable ntpd提示在同一台机器上chronyd 和 ntpd 不要同时启用。两者都监听 UDP 123 端口同时开启会互相冲突日志里报错一堆时间反而无法正常同步。4. 从零部署一台内网 NTP 时间服务器的完整流程4.1 架构设计企业内网该用哪种方案小型企业或实验室环境最简单的方式是所有服务器直接指向公网 NTP 节点。这样做配置简单、不用额外维护但如果内网机器数量很多请求频繁公网流量和上游服务压力都会增加而且一旦公网链路抖动内网所有机器都会受影响。更稳妥的做法是分层架设。这里以最常见的三层结构为例公网 NTP 源如 ntp.aliyun.com ↓ 内网主 NTP 服务器Stratum 2 ↓ 业务服务器 A / B / C ...主 NTP 服务器从公网同步时间内网其他服务器指向它。这样业务服务器不需要访问公网既能提高同步稳定性也能方便内部审计和管理。下面我按这个架构给出完整实操步骤。4.2 实例CentOS/RHEL 系搭建内网 NTP 服务器第一步检查操作系统默认自带的时间同步服务是否已启动。如果你的系统默认启用了 chrony而你又想用 ntpd先把 chrony 停掉再装 ntpd顺序反了会出问题systemctl stop chronyd systemctl disable chronyd第二步安装并配置 ntpdyum install -y ntp编辑/etc/ntp.conf重点配置如下server ntp.aliyun.com iburst server ntp1.aliyun.com iburst server cn.pool.ntp.org iburst restrict default nomodify notrap nopeer noquery restrict 127.0.0.1 restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap启动服务并设置为开机自启systemctl start ntpd systemctl enable ntpd第三步在防火墙放行 NTP 端口 UDP 123。这一步最容易遗漏不少机器上客户端报同步失败查到最后都是防火墙拦了firewall-cmd --permanent --add-servicentp firewall-cmd --reload第四步在业务服务器上配置 NTP 客户端指向这台内网服务器。同样以 CentOS 为例yum install -y ntp编辑/etc/ntp.conf把上游地址改成内网 NTP 服务器的 IPserver 192.168.1.10 iburst启动并验证systemctl start ntpd systemctl enable ntpd ntpdate -q 192.168.1.10ntpdate -q可以快速查询目标服务器的时间而不实际修改本机时间用来判断网络连通性和时间差很方便。如果查询结果里没有报错说明内网服务器可达且服务正常。4.3 实例Ubuntu/Debian 系搭建内网 NTP 服务器Ubuntu 的步骤大同小异只是软件包管理命令不同。以 Ubuntu 22.04 为例apt update apt install -y ntp配置文件同样是/etc/ntp.conf写入内容参考上面 CentOS 的部分把server指到公网源restrict段加上内网网段允许规则。启动验证命令systemctl restart ntp systemctl enable ntpUbuntu 默认是通过 systemd-timesyncd 做时间同步的安装 ntp 包会弹出提示询问是否禁用 systemd-timesyncd选择禁用即可否则会有服务抢占冲突。注意Ubuntu 18.04 之后的系统如果安装了 ntpsec 包服务名是ntpsec配置文件在/etc/ntpsec/ntp.conf别和传统 ntp 的路径混淆了。我用apt install ntp时遇到过一次装成了 ntpsec导致按旧文档找不到配置路径花了几分钟才反应过来。4.4 配置完怎么确认内网各个机器时间一致部署完成后不要只看一台机器的时间偏差要批量检查所有机器。最简单的办法是写个脚本循环 ssh 到各台机器执行date但更轻量的方式是直接在各机器上跑chronyc tracking或ntpq -p看远端状态字段是否正常。我自己的习惯是把关键节点的时间检查做成每月一次的巡检项脚本大致长这样for host in server1 server2 server3; do echo $host ssh $host date %Y-%m-%d %H:%M:%S; chronyc tracking | grep -E System time|Last offset || ntpq -p done脚本输出里重点看两项一是当前系统时间二是偏移量offset。正常情况下偏移量应该在毫秒级如果出现秒级甚至更大的偏差就需要进一步排查了。5. chrony 客户端配置与状态查询看这一节就够了5.1 客户端安装与环境清理现在服务器端和客户端都使用 chrony 是最省心的方案。客户端安装命令在 RHEL 系是yum install -y chronyDebian 系是apt install -y chrony。装之前先确认系统里没有残留的 ntpd 服务systemctl status ntpd systemctl status chronyd如果发现 ntpd 还在运行先停掉再禁用systemctl stop ntpd systemctl disable ntpd5.2 最小化客户端配置客户端只需要指定上游服务器即可。推荐至少配置两个上游地址避免单点故障。下面是/etc/chrony.conf的简化版本server 192.168.1.10 iburst server ntp.aliyun.com iburst driftfile /var/lib/chrony/drift makestep 1 3 rtcsync配置完成后systemctl restart chronyd systemctl enable chronyd5.3 chronyc 常用查询命令解读配置生效后验证同步状态的命令要熟练掌握。chronyc tracking用来查看当前系统时间的追踪状态输出里最重要两个字段是System time系统时间与参考源的时间偏差正数表示本地时间比源快负数表示慢。Last offset最近一次同步计算出的偏移量如果这个值一直在跳且为负数说明本机时钟在走慢。chronyc sources -v用来查看当前时间源的状态^*表示该源当前被选为同步源。^表示该源可用且被列为候选源。^-表示该源被排除通常是因为距离或同步质量差。^?表示该源状态未知可能是网络不通。chronyc sourcestats -v可以看到每个源的详细统计信息包括延迟、抖动等用于判断上游源质量。我经常用的一组快速检查命令chronyc tracking | grep -E System time|Last offset chronyc sources -v date三条命令配合能在一分钟内判断出系统时间是否准确、同步源是否健康。5.4 立即校正一次时间手动步进操作正常情况下 chrony 会自动平滑调整时间但如果本机时间偏差实在太大比如超过几十秒了自动调整可能需要很长时间。这时候可以手动执行一次步进让时间快速回到正确值chronyc makestep这个命令会让 chrony 立即执行一次时间校正。如果时间偏差在 1 秒以内一般不会有什么感觉如果偏差很大系统时间会发生跳变依赖时间递增的业务比如数据库可能会受影响所以尽量在维护窗口执行。经验执行完chronyc makestep后建议再等几秒执行一次chronyc tracking确认System time字段已经回到毫秒级才算真正同步完成。6. 哪些情况会导致同步失败我的排查经验都在这里6.1 防火墙拦住了 UDP 123最典型、也最容易被忽略的问题就是防火墙。NTP 使用 UDP 123 端口很多安全策略默认只放行 TCP 常见端口UDP 123 经常被漏掉。排查方法# 在内网 NTP 服务器上查看端口监听 ss -ulnp | grep 123 # 在客户端上用 nc 测试 UDP 连通性需要安装 nmap-ncat 或 netcat-openbsd nc -u -z -w2 192.168.1.10 123我还有一招很好用直接在客户端用chronyc sources -v如果上游源状态长期停留在^?大概率就是网络路径上有防火墙拦截。6.2 上游时间服务器不可达或响应慢公网 NTP 节点偶尔也会出问题。特别是某些境外节点在特定网络环境下时延高、丢包多导致同步质量极差。碰上这种情况优先换成国内公共 NTP 节点比如阿里云、腾讯、国家授时中心提供的服务。6.3 chrony 和 ntpd 冲突前面反复提过chronyd 和 ntpd 不能共存。但实际上我排查过几次时间无法同步的问题最后都是发现系统里残留了 ntpd 的启动脚本开机时两个进程抢端口日志里满是chronyd[xxx]: Cant bind UDP socket : Address already in use解决方法是彻底禁用 ntpdsystemctl stop ntpd systemctl disable ntpd pkill ntpd然后再重启 chronyd。6.4 时间跳变过大导致数据库或认证异常这个场景在实际运维中最头疼。假如系统时间被 NTP 强制步进了几分钟数据库主从复制可能因为时间断层出现丢数据或复制中断Java 应用里基于时间戳的缓存也可能瞬间失效。针对这类问题的建议是在业务敏感的设备上尽量避免使用makestep手动跳变而是让 chrony 通过makestep配置只在启动阶段允许大步进运行期间保持微调。makestep 1 3这个1代表超过 1 秒的偏差才步进3代表仅前 3 次同步允许步进。业务运行起来后再大的偏差也只会通过连续的微调逐步修正不会产生让业务惊掉下巴的大跳变。6.5 虚拟化环境下时钟漂移严重如果你用的是 VMware、KVM 或云平台虚拟机有时会发现 NTP 明明是正常的时间却还是时不时跳一下。这多半是虚拟化平台对客户机时钟的处理机制导致的。ESXi 系统里如果 VM 配置了主机时钟同步而客户机里又启用了 NTP经常会出现两个时间源打架的现象。处理思路虚拟化平台里建议关闭虚拟机自行向宿主机同步时钟的选项统一让客户机通过 NTP 从时间服务器同步如果宿主机本身部署了 NTP 服务也要确保宿主机的硬件时钟是准确的否则会把错误时间传染给所有虚拟机。6.6 时区设置错误造成的时间偏差假象有些机器执行date看到本地时间不对就误以为是同步失败但其实 UTC 时间是准的只是时区没设置好。用timedatectl status一看时区写的是 UTC 或者 Etc/GMT自然显示的本地时间就差了八个小时。处理办法timedatectl set-timezone Asia/Shanghai另外要注意某些嵌入式 Linux 系统或精简发行版可能不自带timedatectl这种情况下要手动改/etc/localtime或/etc/timezone并用/usr/share/zoneinfo/Asia/Shanghai覆盖本地区时区文件。7. 让时间持续保持准确的日常运维习惯7.1 把时间同步状态检查纳入巡检脚本时间同步这种事配好之后如果不管说不定哪天就会以意料之外的方式给你添乱。我的习惯是把时间状态检查固定到日常巡检脚本里每天定时跑一次只输出异常内容有异常才告警。巡检脚本的关键检查项包括检查 chronyd 或 ntpd 进程是否在运行。检查系统时间偏移量是否超过阈值。检查上游时间源是否处于^*状态。检查系统时区是否为目标时区。一个精简版本的脚本逻辑#!/bin/bash # 检查 NTP 同步是否正常 if systemctl is-active --quiet chronyd; then offset$(chronyc tracking | grep System time | awk {print $4}) echo chronyd running, offset: $offset elif systemctl is-active --quiet ntpd; then ntpq -p else echo NTP service is not running fi把脚本放到 cron 里每天早上执行一次异常时输出内容并退出非零状态配合监控系统就能做到第一时间发现问题。7.2 关键业务机器的时间偏差阈值设置不同场景对时间偏差的容忍度不同。普通日志服务器偏差个几百毫秒可能问题不大但交易类、认证类系统对时间一致性要求很高。实践上可以参考这个经验值场景建议最大偏差处理方式日志采集、普通应用500ms自动微调数据库主从、消息队列100ms自动微调 异常告警金融交易、证书签发50ms多渠道时间源 频繁校验分布式一致性场景10ms 或更低建议使用 PTP 或硬件时钟源如果现有环境对同步精度要求已经到微秒级NTP 就不再适用了需要评估 PTPPrecision Time Protocol方案那是另一个方向的课题这里暂不展开。7.3 硬件时钟与内核时钟的联动Linux 系统里存在两套时钟硬件时钟RTC即主板电池供电的实时时钟和系统时钟内核维护的软件时钟。NTP 同步的是系统时钟但系统重启时内核会从硬件时钟读取初始时间。如果你配好了 NTP 却没有配好rtcsync系统每次重启后可能会读取到一个旧的硬件时间再等 NTP 慢慢校准期间产生的日志时间戳就会错乱。所以配置里rtcsync一定要保留它负责让内核定期把校准后的系统时间写回硬件时钟。手动查看和同步硬件时钟可以用hwclock --show hwclock --systohchwclock --systohc的意思是把当前系统时间写入硬件时钟。在日常使用中让 NTP 服务自己维护这个动作就好不需要频繁手动干预。7.4 断电重启后的时间异常还有一类情况值得专门提一下机房断电后重新上电。如果服务器没有配置硬件时钟同步或者主板电池没电了重启后系统时间会回到一个很早的默认值。此时即使 NTP 服务正常启动也需要一定时间才能把时间校准回来而且如果时间偏差太大某些应用可能在启动阶段就报证书错误或数据写入异常。针对这种场景我的建议是确保 NTP 服务开机自启且配置了makestep规则让服务启动时能快速修正大偏差。如果机房经常断电考虑在 BIOS 层面检查硬件时钟电池状态。业务侧的启动脚本里避免在系统时间校正前就启动强依赖时间戳的服务。8. 关于 NTP 上下游协同我最后想多说几句在我这些年维护 Linux 服务器的经历里NTP 时间同步是一种典型的平时没存在感出事就是大事的基础设施。很多新人在搭建环境时习惯性地把 NTP 配置放在最后甚至配完一次就不再关注。但真正进入生产环境后会发现时间不同步引发的连锁故障排查起来极其痛苦因为症状会分散到证书校验、数据库复制、日志排序等各个层面没有人第一时间联想到是时间出了问题。反过来看一套配置合理的时间同步方案收益是长期且稳定的。内网架设一台 NTP 服务器作为统一时间源所有机器指向它再配合巡检脚本和合理的偏差阈值基本可以在很长一段时间内做到无感运行。如果你现在的环境还没有做任何 NTP 配置建议先执行一下timedatectl status和date查看当前状态然后在测试机上按这篇文章的步骤装好 chrony指定一个国内公共时间源跑几天看看效果。等你习惯了chronyc sources -v输出里^*带来的那种踏实感再回头看那些时间错乱导致的故障多半会觉得当初应该早一点把这件事安排上。
Linux NTP时间同步全解析：chrony与ntpd部署、配置和排障
1. 时间不同步出问题的往往是你最想不到的地方先说一个我压箱底的排查经历。前几年维护一套内部业务系统每到凌晨两点左右就会出现短暂的服务不可用日志里全是证书校验失败和 token 过期报错。查了几天找不到规律后来无意中发现服务器系统时间比真实时间快了将近三分钟而且偏差还在逐日增大。后来才意识到问题根源不是业务代码也不是中间件配置而是这台机器根本没做过 NTP 时间同步。这类事在实际运维里特别常见而且越隐蔽越致命。时间偏差对系统的影响往往是延迟显现的TLS 证书校验对时间敏感差几分钟直接握手失败数据库主从复制依赖时间戳排序偏差可能导致冲突日志采集和告警分析系统里时间错乱会让排障链路完全断裂更不用说定时任务、消息队列、分布式锁这些对时间一致性有强依赖的组件。很多团队在搭建环境时把精力全部放在业务部署上唯独忽略了基础的时间同步结果埋下一颗随时会爆的雷。这篇文章围绕 Linux 系统下的 NTP 时间同步把原理、部署、配置、验证和排障一次讲透。无论你用的是 CentOS、Ubuntu 还是国产化系统只要底层是 Linux这套思路和命令基本通用。我会把重点放在实际操作上包括我踩过的坑和现在仍然在用的检查习惯希望能帮你在自己环境里少走弯路。2. NTP 不是简单对个表理解分层机制才能排对错2.1 NTP 到底在同步什么很多人以为 NTP 就是把服务器时间改成标准时间其实没那么简单。NTPNetwork Time Protocol真正做的是持续校正系统时钟的走时速率而不是一次性把时间设对。这里有个关键概念叫走时漂移。每台服务器的硬件晶振都有制造误差和环境温度影响导致它每秒走的量和真实时间不完全一致。有的机器一天慢几十毫秒有的机器一天快几百毫秒长期积累就成了几分钟的偏差。NTP 客户端会周期性地从时间服务器获取参考时间计算出本机时钟的偏移量和漂移率然后平滑调整而不是粗暴地跳变。这也是为什么 NTP 同步完成后你很少看到秒针猛跳一下而是系统时间在不知不觉中被校准。2.2 分层结构决定了时间怎么一级级传下来NTP 使用分层的树状结构来组织时间来源层级用 stratum 表示。层级含义常见来源Stratum 0原子钟、GPS 时钟等硬件时间源铯原子钟、GPS/北斗授时模块Stratum 1直接连接 Stratum 0 的时间服务器国家授时中心的服务器、各大云厂商的 NTP 节点Stratum 2从 Stratum 1 同步时间的服务器企业内部 NTP 服务器、普通公共服务节点Stratum 3 及以下从上一层同步的客户端普通业务服务器、办公电脑层级越低离权威时间源越近精度越高。但同时要注意层级越低也意味着一旦上游故障受影响的范围越大。所以在企业环境里通常的做法是内网搭一台或两台 NTP 服务器Stratum 2统一从公网权威源同步然后内网所有机器都指向这台服务器。这样做的好处一是节省公网出口带宽二是内网机器的时间源一致彼此之间的时间偏差小到可以忽略。2.3 一个让很多人困惑的点NTP 和时区NTP 同步的是 UTC 时间协调世界时不负责时区换算。系统显示的本地时间 UTC 时间 时区偏移。所以你在配置 NTP 之前应该先确认系统的时区设置是否正确。我见过不少案例NTP 同步明明正常date命令打印的时间却不对最后发现是时区设成了 UTC 而不是 Asia/Shanghai。检查时区用这个命令timedatectl status如果发现时区不对修改方式以设置为中国标准时间为例timedatectl set-timezone Asia/Shanghai并且建议开启时间自动同步能力timedatectl set-ntp truetimedatectl set-ntp true在较新的系统上会自动激活 systemd-timesyncd 或 chrony具体取决于发行版和配置这一点后面会细说。从同步原理上可以提炼一条结论NTP 解决的是时间准不准的问题时区设置解决的是时间显示对不对的问题两者职责不同缺一不可。3. 用 chrony 还是 ntpd先想清楚再动手3.1 ntpd 和 chrony 的定位差异传统 Linux 服务器上最经典的时间同步方案是 ntpd这是 NTP 项目官方提供的守护进程历史悠久、生态成熟。而 chrony 是后起之秀现在已经是 RHEL/CentOS 8、Ubuntu 18.04 之后各主流发行版的默认方案。很多从 CentOS 6/7 时代过来的运维习惯性安装 ntpd这个选择本身没错但如果你在新的发行版上同时启动 systemd-timesyncd、chronyd 和 ntpd 三个服务就会发现端口互相抢占日志里全是冲突报错。所以我建议先理清自己的场景再选择。对比项ntpdchrony同步精度高但收敛较慢高而且收敛极快网络波动适应能力一般频繁断网场景表现不佳专门针对不稳定网络做了优化虚拟机和云主机支持较差时钟跳变时容易异常目前对频繁挂起/恢复的虚拟机支持良好配置文件位置/etc/ntp.conf/etc/chrony.conf状态查询命令ntpq -pchronyc sources -v系统资源占用略高更低如果你是维护老系统或者有历史脚本依赖 ntpq 的输出用 ntpd 没毛病。如果是新部署环境特别是云服务器和虚拟化环境直接上 chrony这是当前损耗最小、体验最平滑的路线。3.2 为什么云服务器和虚拟机强烈建议 chrony云服务器有一个天然痛点CPU 会被宿主机调度随时可能被暂停。llvm 一暂停虚拟机的 clock 就会发生跳变ntpd 对这种快速跳变的处理方式往往是缓慢调整甚至误判为异常而 chrony 在检测到大幅跳变后能更快地修正。另外如果你的服务器是双机热备或集群架构各个节点的时间偏差越小越好chrony 的快速收敛能力在这种场景下非常有价值。我在实际项目里处理过一台物理服务器和两台虚拟机的组合物理机用 ntpd虚拟机用 chrony三台机器互相做业务交互。运行半年下来虚拟机的偏差基本都在毫秒级反而物理机在换过主板电池后出现了一次较大的时间回退。所以说选型不是越老越稳而是要适配运行环境。3.3 chrony 配置文件的常用写法以主流的 RHEL 系和 Debian 系系统为例安装完成后主要配置都集中在/etc/chrony.conf。下面是一个适合内网环境使用的典型配置# 上游时间服务器可选择国内公共 NTP 节点 server ntp.aliyun.com iburst server ntp1.aliyun.com iburst server time.windows.com iburst # 允许本机作为内网时间源时哪些网段的客户端可以来同步 allow 192.168.1.0/24 # 记录时钟漂移率的文件 driftfile /var/lib/chrony/drift # 如果服务器端时间偏差过大加快校准速度 makestep 1 3 # 开启 RTC 实时时钟同步支持 rtcsync逐行说说重点server后面的iburst参数很关键。不加这个参数chrony 在启动时只会发送一个请求包如果网络慢要等很久才能完成首次同步加了之后启动时会在短时间内连续发送多个请求快速拿到结果实测下来首次同步时间可以从几十秒缩短到几秒。allow字段只在你打算让这台服务器作为内网时间源时才有意义。如果所有机器都直接连公网 NTP这个字段可以不加。makestep 1 3表示当系统时间与参考时间偏差超过 1 秒时以步进方式直接调整时间而不是慢慢微调并且这个规则在启动后的前 3 次同步中生效。这是为了避免刚启动时系统时间偏差过大、需要等很久才能微调到位的问题。rtcsync让系统定期把内核时间写回硬件时钟防止重启后时间又跳回错误值。修改完配置文件后重启服务并设为开机自启systemctl restart chronyd systemctl enable chronyd3.4 ntpd 的配置要点如果确定要用 ntpd配置文件在/etc/ntp.conf核心部分大同小异server ntp.aliyun.com iburst server ntp1.aliyun.com iburst restrict default nomodify notrap nopeer noquery restrict 127.0.0.1 restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap driftfile /var/lib/ntp/driftrestrict段用来做访问控制默认规则建议保持严格。nomodify表示客户端不能修改本机配置notrap禁止 trap 远程事件日志nopeer阻止建立对等关系noquery禁止远程查询状态。生产环境的 NTP 服务器上这些限制尽量都加上避免被内网其他机器利用。启动方式同样是用 systemctlsystemctl restart ntpd systemctl enable ntpd提示在同一台机器上chronyd 和 ntpd 不要同时启用。两者都监听 UDP 123 端口同时开启会互相冲突日志里报错一堆时间反而无法正常同步。4. 从零部署一台内网 NTP 时间服务器的完整流程4.1 架构设计企业内网该用哪种方案小型企业或实验室环境最简单的方式是所有服务器直接指向公网 NTP 节点。这样做配置简单、不用额外维护但如果内网机器数量很多请求频繁公网流量和上游服务压力都会增加而且一旦公网链路抖动内网所有机器都会受影响。更稳妥的做法是分层架设。这里以最常见的三层结构为例公网 NTP 源如 ntp.aliyun.com ↓ 内网主 NTP 服务器Stratum 2 ↓ 业务服务器 A / B / C ...主 NTP 服务器从公网同步时间内网其他服务器指向它。这样业务服务器不需要访问公网既能提高同步稳定性也能方便内部审计和管理。下面我按这个架构给出完整实操步骤。4.2 实例CentOS/RHEL 系搭建内网 NTP 服务器第一步检查操作系统默认自带的时间同步服务是否已启动。如果你的系统默认启用了 chrony而你又想用 ntpd先把 chrony 停掉再装 ntpd顺序反了会出问题systemctl stop chronyd systemctl disable chronyd第二步安装并配置 ntpdyum install -y ntp编辑/etc/ntp.conf重点配置如下server ntp.aliyun.com iburst server ntp1.aliyun.com iburst server cn.pool.ntp.org iburst restrict default nomodify notrap nopeer noquery restrict 127.0.0.1 restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap启动服务并设置为开机自启systemctl start ntpd systemctl enable ntpd第三步在防火墙放行 NTP 端口 UDP 123。这一步最容易遗漏不少机器上客户端报同步失败查到最后都是防火墙拦了firewall-cmd --permanent --add-servicentp firewall-cmd --reload第四步在业务服务器上配置 NTP 客户端指向这台内网服务器。同样以 CentOS 为例yum install -y ntp编辑/etc/ntp.conf把上游地址改成内网 NTP 服务器的 IPserver 192.168.1.10 iburst启动并验证systemctl start ntpd systemctl enable ntpd ntpdate -q 192.168.1.10ntpdate -q可以快速查询目标服务器的时间而不实际修改本机时间用来判断网络连通性和时间差很方便。如果查询结果里没有报错说明内网服务器可达且服务正常。4.3 实例Ubuntu/Debian 系搭建内网 NTP 服务器Ubuntu 的步骤大同小异只是软件包管理命令不同。以 Ubuntu 22.04 为例apt update apt install -y ntp配置文件同样是/etc/ntp.conf写入内容参考上面 CentOS 的部分把server指到公网源restrict段加上内网网段允许规则。启动验证命令systemctl restart ntp systemctl enable ntpUbuntu 默认是通过 systemd-timesyncd 做时间同步的安装 ntp 包会弹出提示询问是否禁用 systemd-timesyncd选择禁用即可否则会有服务抢占冲突。注意Ubuntu 18.04 之后的系统如果安装了 ntpsec 包服务名是ntpsec配置文件在/etc/ntpsec/ntp.conf别和传统 ntp 的路径混淆了。我用apt install ntp时遇到过一次装成了 ntpsec导致按旧文档找不到配置路径花了几分钟才反应过来。4.4 配置完怎么确认内网各个机器时间一致部署完成后不要只看一台机器的时间偏差要批量检查所有机器。最简单的办法是写个脚本循环 ssh 到各台机器执行date但更轻量的方式是直接在各机器上跑chronyc tracking或ntpq -p看远端状态字段是否正常。我自己的习惯是把关键节点的时间检查做成每月一次的巡检项脚本大致长这样for host in server1 server2 server3; do echo $host ssh $host date %Y-%m-%d %H:%M:%S; chronyc tracking | grep -E System time|Last offset || ntpq -p done脚本输出里重点看两项一是当前系统时间二是偏移量offset。正常情况下偏移量应该在毫秒级如果出现秒级甚至更大的偏差就需要进一步排查了。5. chrony 客户端配置与状态查询看这一节就够了5.1 客户端安装与环境清理现在服务器端和客户端都使用 chrony 是最省心的方案。客户端安装命令在 RHEL 系是yum install -y chronyDebian 系是apt install -y chrony。装之前先确认系统里没有残留的 ntpd 服务systemctl status ntpd systemctl status chronyd如果发现 ntpd 还在运行先停掉再禁用systemctl stop ntpd systemctl disable ntpd5.2 最小化客户端配置客户端只需要指定上游服务器即可。推荐至少配置两个上游地址避免单点故障。下面是/etc/chrony.conf的简化版本server 192.168.1.10 iburst server ntp.aliyun.com iburst driftfile /var/lib/chrony/drift makestep 1 3 rtcsync配置完成后systemctl restart chronyd systemctl enable chronyd5.3 chronyc 常用查询命令解读配置生效后验证同步状态的命令要熟练掌握。chronyc tracking用来查看当前系统时间的追踪状态输出里最重要两个字段是System time系统时间与参考源的时间偏差正数表示本地时间比源快负数表示慢。Last offset最近一次同步计算出的偏移量如果这个值一直在跳且为负数说明本机时钟在走慢。chronyc sources -v用来查看当前时间源的状态^*表示该源当前被选为同步源。^表示该源可用且被列为候选源。^-表示该源被排除通常是因为距离或同步质量差。^?表示该源状态未知可能是网络不通。chronyc sourcestats -v可以看到每个源的详细统计信息包括延迟、抖动等用于判断上游源质量。我经常用的一组快速检查命令chronyc tracking | grep -E System time|Last offset chronyc sources -v date三条命令配合能在一分钟内判断出系统时间是否准确、同步源是否健康。5.4 立即校正一次时间手动步进操作正常情况下 chrony 会自动平滑调整时间但如果本机时间偏差实在太大比如超过几十秒了自动调整可能需要很长时间。这时候可以手动执行一次步进让时间快速回到正确值chronyc makestep这个命令会让 chrony 立即执行一次时间校正。如果时间偏差在 1 秒以内一般不会有什么感觉如果偏差很大系统时间会发生跳变依赖时间递增的业务比如数据库可能会受影响所以尽量在维护窗口执行。经验执行完chronyc makestep后建议再等几秒执行一次chronyc tracking确认System time字段已经回到毫秒级才算真正同步完成。6. 哪些情况会导致同步失败我的排查经验都在这里6.1 防火墙拦住了 UDP 123最典型、也最容易被忽略的问题就是防火墙。NTP 使用 UDP 123 端口很多安全策略默认只放行 TCP 常见端口UDP 123 经常被漏掉。排查方法# 在内网 NTP 服务器上查看端口监听 ss -ulnp | grep 123 # 在客户端上用 nc 测试 UDP 连通性需要安装 nmap-ncat 或 netcat-openbsd nc -u -z -w2 192.168.1.10 123我还有一招很好用直接在客户端用chronyc sources -v如果上游源状态长期停留在^?大概率就是网络路径上有防火墙拦截。6.2 上游时间服务器不可达或响应慢公网 NTP 节点偶尔也会出问题。特别是某些境外节点在特定网络环境下时延高、丢包多导致同步质量极差。碰上这种情况优先换成国内公共 NTP 节点比如阿里云、腾讯、国家授时中心提供的服务。6.3 chrony 和 ntpd 冲突前面反复提过chronyd 和 ntpd 不能共存。但实际上我排查过几次时间无法同步的问题最后都是发现系统里残留了 ntpd 的启动脚本开机时两个进程抢端口日志里满是chronyd[xxx]: Cant bind UDP socket : Address already in use解决方法是彻底禁用 ntpdsystemctl stop ntpd systemctl disable ntpd pkill ntpd然后再重启 chronyd。6.4 时间跳变过大导致数据库或认证异常这个场景在实际运维中最头疼。假如系统时间被 NTP 强制步进了几分钟数据库主从复制可能因为时间断层出现丢数据或复制中断Java 应用里基于时间戳的缓存也可能瞬间失效。针对这类问题的建议是在业务敏感的设备上尽量避免使用makestep手动跳变而是让 chrony 通过makestep配置只在启动阶段允许大步进运行期间保持微调。makestep 1 3这个1代表超过 1 秒的偏差才步进3代表仅前 3 次同步允许步进。业务运行起来后再大的偏差也只会通过连续的微调逐步修正不会产生让业务惊掉下巴的大跳变。6.5 虚拟化环境下时钟漂移严重如果你用的是 VMware、KVM 或云平台虚拟机有时会发现 NTP 明明是正常的时间却还是时不时跳一下。这多半是虚拟化平台对客户机时钟的处理机制导致的。ESXi 系统里如果 VM 配置了主机时钟同步而客户机里又启用了 NTP经常会出现两个时间源打架的现象。处理思路虚拟化平台里建议关闭虚拟机自行向宿主机同步时钟的选项统一让客户机通过 NTP 从时间服务器同步如果宿主机本身部署了 NTP 服务也要确保宿主机的硬件时钟是准确的否则会把错误时间传染给所有虚拟机。6.6 时区设置错误造成的时间偏差假象有些机器执行date看到本地时间不对就误以为是同步失败但其实 UTC 时间是准的只是时区没设置好。用timedatectl status一看时区写的是 UTC 或者 Etc/GMT自然显示的本地时间就差了八个小时。处理办法timedatectl set-timezone Asia/Shanghai另外要注意某些嵌入式 Linux 系统或精简发行版可能不自带timedatectl这种情况下要手动改/etc/localtime或/etc/timezone并用/usr/share/zoneinfo/Asia/Shanghai覆盖本地区时区文件。7. 让时间持续保持准确的日常运维习惯7.1 把时间同步状态检查纳入巡检脚本时间同步这种事配好之后如果不管说不定哪天就会以意料之外的方式给你添乱。我的习惯是把时间状态检查固定到日常巡检脚本里每天定时跑一次只输出异常内容有异常才告警。巡检脚本的关键检查项包括检查 chronyd 或 ntpd 进程是否在运行。检查系统时间偏移量是否超过阈值。检查上游时间源是否处于^*状态。检查系统时区是否为目标时区。一个精简版本的脚本逻辑#!/bin/bash # 检查 NTP 同步是否正常 if systemctl is-active --quiet chronyd; then offset$(chronyc tracking | grep System time | awk {print $4}) echo chronyd running, offset: $offset elif systemctl is-active --quiet ntpd; then ntpq -p else echo NTP service is not running fi把脚本放到 cron 里每天早上执行一次异常时输出内容并退出非零状态配合监控系统就能做到第一时间发现问题。7.2 关键业务机器的时间偏差阈值设置不同场景对时间偏差的容忍度不同。普通日志服务器偏差个几百毫秒可能问题不大但交易类、认证类系统对时间一致性要求很高。实践上可以参考这个经验值场景建议最大偏差处理方式日志采集、普通应用500ms自动微调数据库主从、消息队列100ms自动微调 异常告警金融交易、证书签发50ms多渠道时间源 频繁校验分布式一致性场景10ms 或更低建议使用 PTP 或硬件时钟源如果现有环境对同步精度要求已经到微秒级NTP 就不再适用了需要评估 PTPPrecision Time Protocol方案那是另一个方向的课题这里暂不展开。7.3 硬件时钟与内核时钟的联动Linux 系统里存在两套时钟硬件时钟RTC即主板电池供电的实时时钟和系统时钟内核维护的软件时钟。NTP 同步的是系统时钟但系统重启时内核会从硬件时钟读取初始时间。如果你配好了 NTP 却没有配好rtcsync系统每次重启后可能会读取到一个旧的硬件时间再等 NTP 慢慢校准期间产生的日志时间戳就会错乱。所以配置里rtcsync一定要保留它负责让内核定期把校准后的系统时间写回硬件时钟。手动查看和同步硬件时钟可以用hwclock --show hwclock --systohchwclock --systohc的意思是把当前系统时间写入硬件时钟。在日常使用中让 NTP 服务自己维护这个动作就好不需要频繁手动干预。7.4 断电重启后的时间异常还有一类情况值得专门提一下机房断电后重新上电。如果服务器没有配置硬件时钟同步或者主板电池没电了重启后系统时间会回到一个很早的默认值。此时即使 NTP 服务正常启动也需要一定时间才能把时间校准回来而且如果时间偏差太大某些应用可能在启动阶段就报证书错误或数据写入异常。针对这种场景我的建议是确保 NTP 服务开机自启且配置了makestep规则让服务启动时能快速修正大偏差。如果机房经常断电考虑在 BIOS 层面检查硬件时钟电池状态。业务侧的启动脚本里避免在系统时间校正前就启动强依赖时间戳的服务。8. 关于 NTP 上下游协同我最后想多说几句在我这些年维护 Linux 服务器的经历里NTP 时间同步是一种典型的平时没存在感出事就是大事的基础设施。很多新人在搭建环境时习惯性地把 NTP 配置放在最后甚至配完一次就不再关注。但真正进入生产环境后会发现时间不同步引发的连锁故障排查起来极其痛苦因为症状会分散到证书校验、数据库复制、日志排序等各个层面没有人第一时间联想到是时间出了问题。反过来看一套配置合理的时间同步方案收益是长期且稳定的。内网架设一台 NTP 服务器作为统一时间源所有机器指向它再配合巡检脚本和合理的偏差阈值基本可以在很长一段时间内做到无感运行。如果你现在的环境还没有做任何 NTP 配置建议先执行一下timedatectl status和date查看当前状态然后在测试机上按这篇文章的步骤装好 chrony指定一个国内公共时间源跑几天看看效果。等你习惯了chronyc sources -v输出里^*带来的那种踏实感再回头看那些时间错乱导致的故障多半会觉得当初应该早一点把这件事安排上。
