chrony 与 systemd-timesyncd – 作为 NTP 客户端有什么区别和用例?

chrony 与 systemd-timesyncd – 作为 NTP 客户端有什么区别和用例?

不知怎的,但不是完全建立在旧问题的基础上“ntpd 与 systemd-timesyncd - 如何实现可靠的 NTP 同步?”,我想问一下 chrony 和 systemd-timesyncd 在 NTP 方面的区别客户

我知道 systemd-timesyncd 或多或少是一个最小的 ntp 客户端实现,而 chrony 是一个完整的 NTP 守护进程解决方案,恰好包含 NTP 客户端。

乌班图仿生海狸发行说明陈述以下内容:

对于简单的时间同步需求,基本系统已经附带了 systemd-timesyncd。 Chrony 仅需要充当时间服务器,或者如果您希望实现更准确、更高效的同步。

我喜欢使用最小的预安装工具来完成这项工作,并且我很确定 systemd-timesyncd 会为我的用例完成这项工作,但我仍然很好奇:

  • 两者在准确性方面的现实差异是什么?
  • 效率上有何差异?
  • 什么是“非简单”时间同步需求,即 chrony 作为 NTP 客户端的用例?

答案1

systemd NEWS 文件中关于 systemd-timesyncd 的公告很好地解释了该工具与 Chrony 和类似工具相比的差异。 (强调我的):

一个新的“systemd-时间同步”添加了守护进程来同步网络上的系统时钟。它实现了一个SNTP客户端。与 NTP 实现相反,例如慢性的或 NTP 参考服务器,这仅实现客户端,并且不关心完整的 NTP 复杂性,只关注从一台远程服务器查询时间并将本地时钟与其同步。除非您打算向联网客户端提供 NTP 服务或想要连接到本地硬件时钟,否则这个简单的 NTP 客户端应该更适合大多数安装。 [...]

此设置是服务器群中大多数主机的常见用例。它们通常会从本地 NTP 服务器进行同步,而本地 NTP 服务器本身会从多个源(可能包括硬件)进行同步。 systemd-timesyncd 尝试为该常见用例提供易于使用的解决方案。


尝试解决您的具体问题:

两者在准确性方面的现实差异是什么?

我相信您可以通过从多个源获取同步数据来获得更高的准确性,这特别不受 systemd-timesyncd 支持的用例。但是,当您使用它从连接到可靠的内部网络的中央 NTP 服务器获取同步数据时,使用多个源实际上并不那么相关,并且您可以从单个源获得很好的准确性。

如果您要从本地网络和同一数据中心中的受信任服务器同步您的服务器,NTP 和 SNTP 之间的精度差异几乎不存在。 NTP 可以考虑 RTT 并进行时间涂抹,但当 RTT 非常小时(即快速本地网络和附近机器的情况),这并没有多大好处。如果您可以信任您正在使用的来源,那么您也不需要多个来源。

效率上有何差异?

从单个源获取同步比从多个源获取同步要简单得多,因为您不必决定哪些源比其他源更好,也不必组合来自多个源的信息。算法要简单得多,对于简单的情况需要更少的 CPU 负载。

什么是“非简单”时间同步需求,即 chrony 作为 NTP 客户端的用例?

上面的引用中已经解决了这个问题,但无论如何,这些都是 systemd-timesyncd 未涵盖的 Chrony 用例:

  • 运行 NTP 服务器(以便其他主机可以使用该主机作为同步源);
  • 从多个源获取 NTP 同步信息(这对于从 Internet 上的公共服务器获取该信息的主机很重要);和
  • 从本地时钟获取同步信息,这通常涉及专用硬件,例如 GPS 设备,可以从卫星获取准确的时间信息。

这些用例需要 Chrony 或 ntpd 或类似的。

答案2

正如另一个答案正确指出的那样,chrony实现 NTP 和systemd-timesyncdSNTP。

从授时客户端的角度来看:

SNTP 是一种更容易实现的协议;
NTP 允许按时间逐步增量/修正。 NTP 的一大优点是它还考虑了答案的 RTT 以获得更准确的时间。

https://www.meinbergglobal.com/english/faq/faq_37.htm

虽然全功能的 NTP 服务器或客户端通过使用不同的数学和统计方法以及平滑的时钟速度调整来达到非常高的精度并尽可能避免突然的时间步长,但 SNTP 只能推荐用于简单的应用,其中要求准确性和可靠性要求不太高。通过忽略漂移值并使用简化的系统时钟调整方法(通常是简单的时间步进),与完整的 NTP 实现相比,SNTP 只能实现低质量的时间同步。

SNTP 采用更简单的方法。 NTP 算法的许多复杂性都被消除了。许多 SNTP 客户端不是倾斜时间,而是步进时间。这对于许多需要简单时间戳的应用程序来说是很好的。此外,SNTP 缺乏监视和过滤多个 NTP 服务器的能力。通常使用简单的循环方法,如果一台服务器发生故障,则使用列表中的下一台服务器

https://www.masterclock.com/company/masterclock-inc-blog/ntp-vs-sntp

NTP 比 SNTP 更加准确和精确,这使其成为大多数企业应用程序中事实上的赢家。另一方面,SNTP 的简单性使其更适合 IP 摄像机、DVR 和某些网络交换机等设备。这些类型的硬件缺乏处理资源来处理更复杂的协议,但随着连接的设备变得越来越强大,这种情况可能会改变。

SNTP 的一个主要弱点是您无法像网络时间协议默认情况下那样通过从多个源检索时间来使其更加准确。

另一个要点是,当虚拟机管理程序和 NTP 守护进程都试图更改虚拟机时间时,我发现 SNTP 实现比 NTP 带来更多问题。特别是当他们在时间上不一致并且某些配置错误导致他们都处于活动状态时,可能会导致大问题。 (虽然有能力的系统管理员只会保持一种与时间同步的方法处于活动状态,但可能会由于配置错误而使它们同时处于活动状态)。

systemd-timesyncd不使用时,不建议使用PS作为替代方案systemd

答案3

chrony不是分叉形式,ntpd而是从头开始实现的。它同时实现了客户服务器完整 NTPv4 协议的模式(RFC5905)。在企业级用户中,我们看到一种从传统ntpd转向chronyRed Hat(RHEL 7 及以上)和 SuSE(SLES 15 起)等的趋势。

systemd-timesyncd只实现SNTP协议(RFC4330客户模式。因此,复杂的用例不属于systemd-timesyncd.例如,SNTP 无法像 NTP 默认那样通过从多个源检索时间来使其更加准确。因此systemd-timesyncd无法提供像 一样高精度的时间chrony

相关内容