Facebook如何构建满足规模需求的精确时间服务？

小提示：您能找到这篇{Facebook如何构建满足规模需求的精确时间服务？}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的Facebook如何构建满足规模需求的精确时间服务？内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

< ">互联网上的设备要保持正常运行需要内置时钟运行精准，像Facebook这种规模体量的互联网公司对设备时钟的精准度要求会更高。本文介绍了Facebook在搭建自己的精确时间服务方面的探索实践，最终给我们提供了测量系统时间误差的方法以及对chrony的应用实践。

< ">数十亿连接到互联网的设备几乎都有内置时钟，为了保证设备的正常运行，这些时钟必须保持精确。因为许多时钟的内部振荡器并不精准，所以可能会导致每天数秒的误差，这就需要定期校正。因为不准确的时间会导致一些问题，比如错过重要的提醒时间，甚至导致宇宙飞船发射失败。全世界的设备都依赖网络时间协议(NTP)，通过包交换、可变延迟的数据网络来保持与更精确时钟的同步。

< ">随着Facebook基础设施的增长，系统中的时间精度变得越来越重要。我们需要知道数据中心中两个随机服务器之间的准确时间差，以便数据存储写入数据时不会打乱事务顺序。我们需要以亚毫秒级的精度同步多个数据中心的所有服务器。为此，我们测试了chrony，这是一个功能丰富的现代NTP服务器实现。在测试期间，我们发现与以前使用的服务ntpd相比，chrony具有更高的精确性和可伸缩性，这就让我们很安心的用chrony替换了基础设施中的ntpd。Chrony也是Facebook公共NTP服务time.facebook.com的基础。在这篇文章中，我们将分享将时间精度从10毫秒提高到100微秒所做的工作，以及我们如何在计时实验室验证这些结果的。

闰秒

< ">在深入了解NTP服务细节之前，我们需要了解一种称为闰秒的现象。由于地球不规律的自转，我们有时需要增加或减少一秒，或一闰秒。对于人类来说，增加或减少一秒在看钟表的时候几乎察觉不到。然而，这种事情发生在服务器上，就可能导致大量事务或事件丢失，甚至发生严重的软件故障。解决这一问题最通常的做法是“抹去”闰秒，也就是说每过几个小时稍微修改一下时间。

规模建设NTP服务

< ">Facebook的NTP服务分为四个层次:

< ">第0层是一层拥有极其精确原子钟的卫星，这些原子钟来自全球导航卫星系统(GNSS)，如GPS、GLONASS和Galileo。

< ">第1层是Facebook的原子钟，与GNSS同步。

< ">第2层是一个与层1设备同步的NTP服务器池。在这一层，闰秒开始出现。

< ">第3层是更大规模配置的服务器层。他们接收被处理过的时间，这一层就感知不到闰秒了。

< ">在某些系统中，可能有多达16个层来分配工作，对层数的需求取决于系统规模和精福州宣传片制作度要求。

< ">当我们开始构建NTP服务时，我们测试了以下后台程序使用的时间：

< ">1.Ntpd：一个通用的后台程序，Ntpd过去常常应用在大多数类Unix操作系统中。多年来，它一直是稳定的解决方案，现在的大多数计算机上依旧运行着Ntpd。

< ">2.Chrony：一个比较新的后台程序，它具有丰富的特性，并且可以为NTP提供精确的时间同步。Chrony还提供了可扩展控制协议，理论上可以将精度降低到纳秒。从资源消耗的角度来看，我们发现ntpd和chrony非常相似，chrony消耗的内存甚至稍微少一些(大约有1 MiB的差异)。

评估后台程序

< ">无论系统是使用ntpd还是chrony，每个系统都提供了一些评估的度量方法。通过使用这些后台程序的命令行工具可以进行评估。这些评估是基于一定的假设为前提的，例如：

< ">客户机和服务器之间的网络路径要有对称性。

< ">当时间戳被添加到NTP包并调用send()时，操作系统会立即发送它。

< ">振荡器的温度和输入电压是恒定的。

< ">Ntpd包含ntpq命令行工具，可以显示时间没有同步的状态：

[user@client ~]# ntpq -p

remote           refid      st t when poll reach   delay   offset  jitter

=========================================================================

+server1          .FB.       2 u  406 1024  377    0.029    0.149   0.035

+server2          .FB.       2 u  548 1024  377    0.078    0.035   0.083

*server3          .FB.       2 u  460 1024  377    0.049   -0.185   0.114

< ">然而，这些数据可信么？如果ntpd报告时间差了0.185 ms，是否准确？答案是否定的。服务器根据包中的多个时间戳估计偏移量，而实际值应该在一个10倍大的窗口内。换句话说，差0.185毫秒的结果意味着偏差可能在+/-2毫秒内(总共4毫秒)。我们的测试表明，ntpd的准确性一般在10毫秒以内。

< ">我们有更高精度的技术要求。例如，多主数据库将微秒甚至纳秒的精度直接转换为理论吞吐量。另一个需要中等精度的示例是日志记录，为了在分布式系统的节点之间匹配日志，通常需要毫秒级的精度。

< ">下面让我们看看如果用chrony替换ntpd，效果会怎样：

[user@client ~]# chronyc sources -v

210 Number of sources = 19

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.

 / .- Source state '*' = current synced, '+' = combined , '-' = not combined,

| /   '?' = unreachable, 'x' = time may be in error, '~' = time too variable.

||                                                 .- xxxx [ yyyy ] +/- zzzz

||      Reachability register (octal) -.           |  xxxx = adjusted offset,

||      Log2(Polling interval) --.      |          |  yyyy = measured offset,

||                                     |          |  zzzz = estimated error.

||                                 |    |           

MS Name/IP address       Stratum Poll Reach LastRx Last sample

===============================================================================

^+ server1                     2   6   377     2    +10us[  +10us] +/-  481us

^- server2                     2   6   377     0  -4804us[-4804us] +/-   77ms

^* server3                     2   6   377    59    -42us[  -46us] +/-  312us

^+ server4                     3   6   377    60    +11ns[-3913ns] +/-  193us

< ">注意最后三个数字。在最后，从右向左看:

< ">最后一个数字是估计误差。它的前缀是+/-。它表示chrony的最大误差范围。有时是10毫秒，有时是100微秒(100倍的差异)。这是因为当chrony与另一个chrony同步时，使用扩展的NTP协议，这极大地提高了精度。效果还不错。

< ">下一个是方括号中的数字。它显示了测量的偏移量。除了server4(我们稍后将讨论这个)，其它的我们看到也大约有100倍的差异。

< ">方括号左边的数字显示的是最初的测量值，经过调整后，允许自第一次测量以来的任何slews应用于本地时钟。同样，我们可以看到ntpd和chrony之间的差异也是100倍。

< ">请看下图：

< ">蓝色竖线表示ntpd被chrony替换的时间点。对于ntpd，其范围是+/-1.5 ms。用了chrony后，变动范围在微秒内。更重要的是，估计误差(窗口)下降到了100微秒的范围，这些是可以通过实验室测量来确认的(下面会有更多的介绍)。但是，这些值是用后台程序估算的。实际上，实际时间可能完全不同。我们如何验证这些数字的准确性呢?

每秒脉冲数(1PPS)

< ">我们可以从原子钟中提取模拟信号(实际上是来自层1设备的内部计时电路)。这个信号叫做1PPS，意思是每秒1个脉冲；它在每一秒的开始都会在同轴电缆上产生一个脉冲。这是一种主流的、精确的同步方法。我们可以在NTP服务器上生成相同的脉冲，然后比较各个阶段的差异。这里有个困难点就是，并非所有服务器都支持1PPS，因此需要专门的网络扩展卡。

< ">我们第一次测试是手动完成的，使用了一台显示相移的示波器。

< ">通过10分钟的测量，我们估算出ntpd的偏移约为3.5毫秒，有时会跳到10毫秒。

< ">这个测试在Facebook大规模服务器上实现起来是极其困难并且也不切实际。更好的测试方法是将测试服务器的1PPS输出连接到层1设备本身的1PPS输入，并监控其差异。

< ">这种方法可以实现上一个测试方法中所有优点，同时也不需要在数据中心使用示波器。如果使用该方法，我们能够在任何时间点进行测量并验证真实的NTP偏移量。

< ">通过这两个测量结果，我们对实际的NTP偏移有了很好的了解，使用1PPS误差估计在纳秒内，这主要是由电缆长度导致的。

< ">这些方法的不足之处是：

< ">电缆铺设：做这样的测试需要同轴电缆。在不同的数据中心进行测试需要更改数据中心的布局设计，这是比较困难的。

< ">定制硬件：不是所有网卡都有1PPS输出。这样的测试需要特殊的网卡和服务器。

< ">层1设备需要1PPS输入。

< ">服务器上需要安装1PPS软件：为了运行测试，我们必须在我们的测试服务器上安装ntpd。这个后台程序可能会导致意外错误，因为它在用户空间中工作，并会被Linux调度。

专用测试设备

< ">市场上有一些设备可以进行准确性测试。它们包含GNSS接收器，一个原子钟，多个1PPS和网络接口，还可以充当NTP客户端。这就让我们可以直接使用NTP协议执行相同的测试。接收到的NTP包由原子钟或GNSS接收器以非常精确的时间戳记录。

< ">以下就是常见的装备：

< ">上面的照片是我们最初临时用的测试设备。使用该设备进行测量有以下几个优点：

< ">它不需要额外的1PPS电缆。我们虽然仍然需要约束原子钟，但这可以通过使用GNSS或层1设备本身和一根短电缆来实现。

< ">它使用原子钟的数据来标记传输和接收的网络数据包。这使得操作系统的影响可以忽略不计，误差率只有几纳秒。

< ">它同时支持NTP和PTP(精确时间协议)。

< ">该设备是便携式的，我们可以在不同地点之间移动它来执行测试。

< ">设备使用自己的数据点集格式，但它可以将数据导出到CSV，也就是说我们可以按我们的数据标准导出数据。

NTPD测量

< ">结果与我们在后台程序评估和1PPS测量中看到的非常相似。首先，我们发现有一个10毫秒的下降，然后慢慢地修正为+/-1毫秒。有趣的是，这个10毫秒的下降是相当稳定的，并且在每次重启后都会出现。

Chrony测量

< ">这看起来与chrony后台程序的估算非常相似，它比ntpd好10到100倍。

Chrony的硬件时间戳

< ">Chrony极大地改善了偏移量，这可以从1PPS的估算结果和实验室设备值中看出。不过Chrony还支持硬件时间戳。根据文档，Chrony声称可以将精度提高到几百纳秒以内。

< ">让我们来看看网络上NTP客户机-服务器通信中的NTP包结构。初始客户端的NTP包包含传输时间戳字段。

< ">服务器填充其余的字段(例如，接收时间戳)，将客户机的传输时间戳保存为原始时间戳，并将其发送回客户机。

< ">可以使用tcpdump验证此行为:

08:37:31.489921 IP6 (hlim 127, next-header UDP (17) payload length: 56) client.36915 > time1.facebook.com.ntp: [bad udp cksum 0xf5d2 -> 0x595e!] NTPv4, length 48

    Client, Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 3 (8s), precision -6

    Root Delay: 1.000000, Root dispersion: 1.000000, Reference-ID: (unspec)

      Reference Timestamp:  0.000000000

      Originator Timestamp: 0.000000000

      Receive Timestamp:    0.000000000

      Transmit Timestamp:   3783170251.489887309 (2019/11/19 08:37:31)

        Originator - Receive Timestamp:  0.000000000

        Originator - Transmit Timestamp: 3783170251.489887309 (2019/11/19 08:37:31)

...

08:37:31.490923 IP6 (hlim 52, next-header UDP (17) payload length: 56) time1.facebook.com.ntp > server.36915: [udp sum ok] NTPv4, length 48

    Server, Leap indicator:  (0), Stratum 1 (primary reference), poll 3 (8s), precision -32

    Root Delay: 0.000000, Root dispersion: 0.000152, Reference-ID: FB

      Reference Timestamp:  3783169800.000000000 (2019/11/19 08:30:00)

      Originator Timestamp: 3783170251.489887309 (2019/11/19 08:37:31)

      Receive Timestamp:    3783170251.490613035 (2019/11/19 08:37:31)

      Transmit Timestamp:   3783170251.490631213 (2019/11/19 08:37:31)

        Originator - Receive Timestamp:  +0.000725725

        Originator - Transmit Timestamp: +0.000743903

...

< ">客户端会获得数据包，附加另一个接收时间戳，并使用下面这个NTP RFC#958中的公式计算偏移量:

c=(t2-t1+t3-t4)/2

< ">然而，Linux不是一个实时操作系统，它要运行的进程不止一个。因此，当传输时间戳被填满并调用Write()时，并不能保证立即通过网络发送数据：

< ">另外，如果机器没有足够的流量，在发送NTP包之前可能需要一个ARP请求，ARP请求是不可靠的，这会导致估算错误。但chrony支持硬件时间戳，使用这些方法，另一端的chrony可以高精度地确定数据包何时被网络接口处理。虽然从网卡戳记数据包到它实际离开数据包之间仍然有一个延迟，但小于10ns。

< ">还记得之前这个chronyc sources的输出形式吗?

^+server4 2 6 377 60+11ns[-3913ns]+/-193us

< ">Chrony报告偏移量为11 ns。这是因为启用了硬件时间戳的结果。然而，估计误差在几百微秒的范围内。虽然不是所有的网卡都支持硬件时间戳，但是随着它越来越受欢迎，网卡会慢慢支持这个特性。要验证对硬件时间戳的支持，只需运行ethtool检查，然后就可以看到硬件传输和硬件接收功能。

ethtool-T eth0

Time stamping parameters for eth0:

Capabilities:

hardware-transmit(SOF_TIMESTAMPING_TX_HARDWARE)

hardware-receive(SOF_TIMESTAMPING_RX_HARDWARE)

hardware-raw-clock(SOF_TIMESTAMPING_RAW_HARDWARE)

< ">通过使用实验室设备测试相同的硬件，我们就可以得到不同的结果了，ntpd误差显示在-10毫秒和3毫秒之间(13毫秒的差异)，chrony误差显示在-200微秒和200微秒之间，而且启用硬件时间戳后，在大多数情况下chrony误差都显示在-100微秒和100微秒之间。这也证实了之前后台程序的估算可能是不准确的。

公共服务

< ">现在，所有测量都在我们内部控制的数据中心网络中进行。下面，我们看看当我们在公共NTP服务或者其他一些著名的公共NTP服务提供商上测试时，情况是什么样的：

< ">测量的结果好坏在很大程度上取决于网络路径以及网络连接的速度和质量。这些测量并没有受到Facebook网络的影响，针对的是来自不同地点、不同Wi-Fi和LAN网络的服务进行的多次测试。我们可以看到，我们的公共NTP服务不仅与其他主流的供应相比有竞争优势，而且在某些情况下，它的性能也更优。

< ">公共NTP设计方案

< ">在我们成功地将内部精度提升到亚毫秒级别之后，我们就启动了一个公共NTP服务，它可以通过设置time.facebook.com作为NTP服务器来使用。我们在我们的网络入网点（PoP）上运行这个公共NTP服务。为保障私隐，我们不会按IP地址为设备设定指纹。为了在即使请求网络路径失败的情况下也能提供更好的服务，我们在五个不同的地理位置都设置了端点。我们的五个端点如下：

< ">time1.facebook.com

< ">time2.facebook.com

< ">time3.facebook.com

< ">time4.facebook.com

< ">time5.facebook.com

< ">每个端点都在不同的地理位置上，这对可靠性和时间精度都有积极的影响。

< ">time2.facebook.com的网络路径如下:

< ">time3.facebook.com的网络路径如下:

抹掉闰秒

< ">Ntpd一直使用一种预发布的闰秒列表文件。有了这个文件，Ntpd就可以提前进行时间修正，当闰秒实际发生时，也能保证时间是正确的。

< ">Chrony依赖于GNSS提前几小时发布的闰秒指示器。当闰秒事件在UTC 00:00实际发生时，在指定的时间段内它就会被抹去。有了Facebook公共NTP服务，我们决定采用更精确的方法，在事件结束后的大约18个小时内抹去闰秒。

< ">因为涂抹操作要在层2的许多服务器上同时进行，所以保持操作尽可能的相似是很重要的。按照平滑的正弦曲线规则进行操作对应用程序来说是安全的选择。

经验总结

< ">测量时间是非常具有挑战性的。ntpd和chrony提供的估算方法在一定程度上都是正确的。一般来说，如果您想要监控真实的偏移量，我们建议使用1PPS或带有GNSS接收器和原子钟的外部设备。

< ">在比较ntpd和chrony时，我们的测量结果表明chrony要精确得多，这就是我们将基础设施迁移到chrony并启动公共NTP服务的原因。结果证明，将精度从几十毫秒提高到几百微秒是值得的。

< ">使用硬件时间戳可以进一步将精度提高两个数量级。怎样危机公共关系尽管NTP已经有所改善，但它也有自己的局限性，因此对PTP的研究使用才有可能将您的精度提升到下一个级别。

英文原文：

https://engineering.fb.com/production日常公关 危机公关-engineering/ntp-service/