作者 | Zoe Talamantes, Oleg Obleukhov 譯者 | 大小非 策劃 | 钰瑩 網際網路上的裝置要保持正常運作需要内置時鐘運作精準，像 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 服務時，我們測試了以下背景程式使用的時間：
- Ntpd： 一個通用的背景程式，Ntpd 過去常常應用在大多數類 Unix 作業系統中。多年來，它一直是穩定的解決方案，現在的大多數計算機上依舊運作着 Ntpd。
- Chrony：一個比較新的背景程式，它具有豐富的特性，并且可以為 NTP 提供精确的時間同步。Chrony 還提供了可擴充控制協定，理論上可以将精度降低到納秒。從資源消耗的角度來看，我們發現 ntpd 和 chrony 非常相似，chrony 消耗的記憶體甚至稍微少一些 (大約有 1 MiB 的差異)。
評估背景程式
無論系統是使用 ntpd 還是 chrony，每個系統都提供了一些評估的度量方法。通過使用這些背景程式的指令行工具可以進行評估。這些評估是基于一定的假設為前提的，例如：
- 客戶機和伺服器之間的網絡路徑要有對稱性。
- 當時間戳被添加到 NTP 包并調用 send() 時，作業系統會立即發送它。
- 振蕩器的溫度和輸入電壓是恒定的。
Ntpd 包含 ntpq 指令行工具，可以顯示時間沒有同步的狀态：
然而，這些資料可信麼？如果 ntpd 報告時間差了 0.185 ms，是否準确？答案是否定的。伺服器根據包中的多個時間戳估計偏移量，而實際值應該在一個 10 倍大的視窗内。換句話說，差 0.185 毫秒的結果意味着偏差可能在 +/-2 毫秒内 (總共 4 毫秒)。我們的測試表明，ntpd 的準确性一般在 10 毫秒以内。
我們有更高精度的技術要求。例如，多主資料庫将微秒甚至納秒的精度直接轉換為理論吞吐量。另一個需要中等精度的示例是日志記錄，為了在分布式系統的節點之間比對日志，通常需要毫秒級的精度。
下面讓我們看看如果用 chrony 替換 ntpd，效果會怎樣：
注意最後三個數字。在最後，從右向左看:
- 最後一個數字是估計誤差。它的字首是 +/-。它表示 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 驗證此行為:
用戶端會獲得資料包，附加另一個接收時間戳，并使用下面這個 NTP RFC #958 中的公式計算偏移量:
然而，Linux 不是一個實時作業系統，它要運作的程序不止一個。是以，當傳輸時間戳被填滿并調用 Write() 時，并不能保證立即通過網絡發送資料：
另外，如果機器沒有足夠的流量，在發送 NTP 包之前可能需要一個 ARP 請求，ARP 請求是不可靠的，這會導緻估算錯誤。但 chrony 支援硬體時間戳，使用這些方法，另一端的 chrony 可以高精度地确定資料包何時被網絡接口處理。雖然從網卡戳記資料包到它實際離開資料包之間仍然有一個延遲，但小于 10ns。
還記得之前這個 chronyc sources 的輸出形式嗎?
Chrony 報告偏移量為 11 ns。這是因為啟用了硬體時間戳的結果。然而，估計誤差在幾百微秒的範圍内。雖然不是所有的網卡都支援硬體時間戳，但是随着它越來越受歡迎，網卡會慢慢支援這個特性。要驗證對硬體時間戳的支援，隻需運作 ethtool 檢查，然後就可以看到硬體傳輸和硬體接收功能。
通過使用實驗室裝置測試相同的硬體，我們就可以得到不同的結果了，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/
你也「在看」嗎？?