550
技術社區[雲棲]
複盤京東金融 2017 年元旦閏秒處置方案
丙申年，庚子月，戊子日。
西元二〇一七年元日，帝都霾，不禁殺。
從立秋到冬至，乃決大辟罪之季。
柴市牌樓前，人頭湧動，聽說今日要處決一重犯，大家都拿著瓜子端著茶壺出來看熱鬧。
十字路口上，麵向南方跪著一位蓬頭垢麵的犯人，身披三械，背後斜插著一支亡命牌。身邊一名劊子手，袒胸露乳，一身腱子肉閃著黝黑的光亮，雙手端著一把鬼頭刀，寒光淩厲。在重犯身後五丈遠的地方，放置著一具長案，案上台布一片腥紅，桌上還放著一筒火簽，旁邊有一個香爐，裏頭插著一根三寸長的檀香。桌後四仰八叉慵懶閑散躺著一位監斬官，不停用嘴吹著檀香，好快點燃完。
太陽像一張沒有烙熟的雞蛋煎餅，無力地透過厚厚的霧層，耷拉在圭表上。石柱的影子虛弱地投在坑坑窪窪的石板上，實在難以辨認現在是幾時幾刻。
檀香還剩一寸的時候，監斬官已經失去耐心，勐地翻起身來，從簽筒裏胡亂抽出一支火簽令，扔到桌前麵的地上：『吉時已到，行刑』。
劊子手雙手舉刀過頭，口中碎碎念叨，全身肌肉繃得緊緊地，擰腰沉肘，一道青霜。
突然犯人仰頭長笑幾聲：『哈哈哈哈』，驚得牌樓上循著血腥味來覓食的幾隻烏鴉撲棱棱飛起。劊子手也愣了一下，沒料到他會在這生死關頭突然發笑，手中的刀自然也就沒有再落下來。
監斬官眯著眼睛道：『你不知死到臨頭，為甚做這鬼叫聲！』
犯人若有所思道：『看來專家說得沒錯，每天笑一笑，可以延長壽命五秒鍾。』
監斬官道：『弱爆了，專家的話你也信！你難道不知，你今日已經多活了一秒！』
犯人蒙逼道：『此話怎講？』
監斬官鄙夷道：『閏秒！』
曆史和閏秒問題的提出
最初，秒是依據地球繞著軸自轉和繞太陽的公轉，以平均太陽日的 1/86400 來定義（太陽時）。到了 20 世紀中葉，很明顯的，地球自轉沒有提供足夠一致的標準，於是在 1956 年改以繞太陽軌道公轉一年的時間重新定義秒。在 1967 年，秒又被以物理學的屬性再一次重新定義：以銫 133 的振蕩頻率來定義秒，並可以用原子鍾來測量。地球自轉變慢的主要因素由於潮汐加速，其他因素主要是地球質量的分布不均勻變化，包括冰河反彈，2004 年的印度洋地震使其縮短 2.68 毫秒等。
圖 1 展示了國際地球自轉和參考係服務（IERS）觀測到的地球自轉數據。
圖 1A 地球自轉數據（3D）
圖 1B 地球自轉數據（2D）
閏秒Leap Second是在協調世界時（UTC）中增加或減少一秒，從而使之與平太陽時貼近所做的調整。
閏秒由國際地球自轉和參考係服務發布，圖 2 是本次閏秒的公告：
圖 2 本次閏秒的公告
在 2016 年 12 月 31 日，https://www.time.gov 展現了這次閏秒（圖 3）：
圖 3 https://www.time.gov 展現了這次閏秒
而 2015 年 6 月 30 日的閏秒事件，影響了紐約股票交易所、多種互聯網路由器、Twitter、Instagram、Netflix、Amazon、Altea 航空訂票係統等。
閏秒事件的同步實現方式和限製
閏秒在 Linux 係統上的實現方式
目前在 Linux 上多使用 NTP 協議同步時間，在 NTP 的數據包中包含閏秒標誌位。在 NTP 時間同步部署正確的情況下，閏秒標誌位被傳遞至最終的客戶端，並設置在內核中，閏秒發生時，在係統中將出現23:59:60 這樣的時間，並且由內核控製時間將進行跳躍 1 秒，此時時間將不連續（圖 4）。在 CentOS 中由於曆史原因和係統的複雜性，閏秒問題變得更為複雜，並且在特定的係統版本中會引起係統掛起、高係統負載等內核 BUG 等現象。
圖 4 內核控製時間跳躍 1 秒，此時時間將不連續
ntpd 提供了 Slew 模式（-x 參數），但是在存在閏秒標誌位的情況下，僅對足夠新的 ntpd 版本才有效果。在 Slew 模式正常工作的情況下，係統時間的變化仍然不均勻，並可能引起多節點的不一致（圖 5）。
圖 5 係統時間的變化仍然不均勻，並可能引起多節點的不一致
業界公司對閏秒的處理
為了使這 1 秒的同步連續且均勻，Google 和 Amazon 對閏秒問題提供了不同的解決方案。
Google 的解決方法是修改內部的 Stratum 2 時間服務器軟件以進行“閏秒融合”，在閏秒事件發生後均勻的增加（或減少）時間：
其中 ω 為這次融合需要經曆的時間。
Amazon 的解決方法是均勻的時間調整。在閏秒事件發生前 12 小時，以每秒 1/86400 秒的步調，最終比 UTC 時間快 0.5 秒；閏秒後比 UTC 時間慢 0.5 秒，在閏秒後 12 個小時再以每秒 1/86400 秒的步調追趕 UTC 時間。 這兩種方法都可以使時間連續變化，並且使客戶端不會因時間同步服務的突然變化而丟失同步，或者選擇其他的時間源，而使集群時間不一致。
我們的問題
在 2015 年的閏秒事件中，我們經曆了由閏秒帶來的各種係統和軟件問題。 在我們的生產環境中，管理著超過 30K 個節點，位於不同地理位置的 IDC，它們使用內部的 Stratum 2 時間源同步。這些節點配置有 ntpd 作為時間同步客戶端。使用的操縱係統版本包括 CentOS 6.2 - 6.5 版本。大部分 ntpd 客戶端版本為 ntp-4.2.6p5-1.el6， minpoll 和 maxpoll 參數使用默認的配置，即時間穩定後 1024 秒同步一次，時間變化頻率不超過 500PPM。 由於操作係統環境的多樣性，閏秒標誌位若下發則不可避免的觸發操作係統和軟件的 BUG；節點數量巨大，因此對大批量節點的操作會有不可測的風險；同時考慮到運行服務的性質，因為是在跨年時間調整，提前調整時間可能會對業務邏輯產生影響。我們決定不下發閏秒標誌位，在閏秒事件發生後，采用事件發生後緩慢調整的方式進行。
時間融合集群架構和實現
架構和硬件
我們的 Stratum 2 時間同步服務器分布在 3 個 IDC，有 8 台獨立的物理機，他們使用互聯網上的 4 個相互獨立的 Stratum 1 時間源和內部的兩台銣原子鍾授時時間服務器作為時間同步標準。 位於多個 IDC 的環境，外部獨立的時間源，內部低延遲的時間源，使 Stratum 2 時間服務器可以穩定運行。
軟件
目前在 CentOS 係列操作係統上可以選擇的時間同步軟件有 ntpd、chronyd、PTP4L、PHC2SYS。PTP4L、PHC2SYS 需要特定的硬件結構進行同步，而 ntpd 在 slew 模式下無法均勻同步時間。chronyd 作為 CentOS 7 中替換 ntpd 的方案，在 CentOS 7.2 和 6.8 中的 chrony 2.1 版本提供了時間平滑變化的方法。 chronyd 的時間平滑算法分為3個階段。第一階段頻率（frequency）以固定比率（wander）變化至最大值（max_freq）；第二階段頻率維持在最大變化頻率（max_freq）足夠的時間；第三階段頻率由再以固定比率（wander）變化至 0。假設這個變化從時刻 0 開始，時刻 a 完成第一階段變化，時刻 b 完成第二階段變化，時刻 b+a 完成第三階段變化：
以此方式變化，則時間偏移為：
由於我們的客戶端使用 NTP 同步，它的最大允許頻率變化為 500PPM（PPM = Part Per Million，10-6 秒），而 500PPM 的變化反映在 1 天的區間，將會達到 43 秒。因此在時間調整過程中，我們不會達到像 500PPM 這樣的數量級。因此，以上公式變為：
測試
測試集群包括 1 個節點作為時間調整源（Stratum 1，時間手動調整），3 台時間融合節點（Stratum 2，chronyd），連接至時間融合節點的 Stratum 3 節點（ntpd）和連接到以上節點的 Stratum 4 節點（ntpd）。
以下驗證了參數 wander 對時間同步效果的影響
Wander=0.001ppm（圖 6，圖 7）：
圖 6
圖 7
wander=0.002ppm（圖 8、圖 9）：
圖 8
圖 9
wander=0.004ppm（圖 10、圖 11）
圖 10
圖 11
總結測試數據如下
|
參數(wander, ppm) |
完成同步所需時間 (小時) |
客戶節點時間偏移幅度 |
4 級時間是否連續 |
|
0.001 |
17.57 |
<100ms |
是 |
|
0.002 |
12.42 |
<100ms |
是 |
|
0.004 |
8.78 |
>100ms |
否 |
因為閏秒事件於北京時間早晨 8 點開始，並且需要當天 0 點之前完成同步，因此我們選擇使用參數 wander=0.002ppm 進行時間融合。而 max_freq=400ppm。
實施
時間融合節點的選用
時間融合節為改造過的 Stratum 2 節點，使用 x86 服務器。X86 服務器電子振蕩器（石英晶振）作為授時元件，它們受外界環境因素影響，主要是溫度。而我們的 Stratum 2 時間服務器的授時質量也並不一致。圖 12 展示了一周的時間周期內 Stratum 2 時間服務器 Frequency error 的變化。
圖 12 Frequency error 的變化
圖 12 我們選擇其中 4 個變化幅度較小的節點作為時間融合節點，如此 NTP 客戶端可以選擇其中 3 個節點進行時間同步計算，並且有 1 個節點作為冗餘。
實施過程和時間點
|
時間點 |
操作 |
結果 |
|
閏秒發生前1周 |
切斷外部時間源，使用內部銣鍾守時。掃描內部節點，清除閏秒標誌位。 |
使內部節點不受閏秒標誌所引起的各種bug影響。 |
|
閏秒發生前48小時 |
時間融合集群上線，使用內部銣鍾同步。 |
使時間融合集群通過銣鍾校正穩定。 |
|
閏秒發生前8個小時 |
切斷時間同步節點，完全使用時間融合集群守時和同步。 |
使時間來源一致。 |
|
2017年1月1日08:00 UTC+8 閏秒發生 |
無 |
銣鍾按照預設算法從GPS獲得時間修正並躍遷1秒，時間融合集群開始修正時間。 閏秒發生後12.41小時 無 時間融合結束，時間融合集群重新和內部銣鍾同步，客戶端時間隨之由時間修正轉變為穩定性修正。 |
|
閏秒發生後24小時 |
Stratum 2時間同步節點修正時間後上線，並與銣鍾和外部時間源同步。 |
Stratum 2時間同步節點開始同步，在他們穩定之前客戶端仍然和時間融合集群同步。 |
|
閏秒發生後36小時 |
無 |
Stratum 2時間同步節點與時間源同步，被客戶端選擇參與時間同步運算。 |
|
閏秒發生後48小時 |
添加外部時間源至時間融合集群節點，時間融合集群作為Stratum 2時間同步節點運作。 |
閏秒相關變更完成。 |
時間融合期間的觀測數據
時間融合期間，我們在位於 3 個 IDC 與時間融合集群同步的服務器上觀測了銣原子鍾、時間融合集群、客戶端相對與銣原子鍾的偏移（圖 13、圖 14）。觀測點同步與銣原子鍾。還有時間融合集群 3 個節點間的差距（圖 15）。
圖 13 相對與銣原子鍾的偏移
圖 14 相對與銣原子鍾的偏移
圖 15 時間融合集群 3 個節點間的差距
性能分析
在 12.41 小時的時間融合之後，仍需 1.39 小時使集群與原子鍾重新同步，而連接時間融合集群的客戶端需要更長的時間進行同步，時間融合集群各節點間差距小於 2ms，生產服務器依照時間融合集群步調融合時間，生產服務器集群和時間融合集群、以及生產服務器之間的時間差距不超過 100ms。
監控和測量方法
監控使用 Collectd 收集數據，Graphite 作為數據存儲，Grafana 作為數據展示，數據收集的精度為每 10 秒一次。監測機同步至內部的銣原子鍾以獲得穩定的參考基線。
結論和後續工作
CentOS 6.8 和 7.2 版本中加入的 Chrony 版本 2.1 提供了一種對時間變化控製的方法，而不需再定製 Stratum 2 節點軟件。
通過建立時間融合集群，同步複雜部署環境下超過 30k 個節點的時間變化，將其步調一致的變慢 1 秒。避免了時間變化的不連續和由於閏秒機製帶來的潛在 BUG。
在實施過程中也發現了若幹問題，在時間融合期間，時間融合服務器的時間變化性能受服務器個體、外界環境溫度等因素影響；時間同步受傳輸過程中經過的長路徑設施、防火牆等網絡設備時，傳輸延遲擺動帶來的時間不均勻變化也不容忽視。
後續考慮在 Stratum 2 和時間融合節點引入更精確的時間參考標準，比如 PTP、PPS 信號等方式，使時間變化過程控製更加均勻，時間融合節點間的誤差更低；在傳輸設備上部署 PTP，以抵長距離和跨 IDC 網絡傳輸對時間同步帶來的影響。
原文發布時間為：2017-01-20
本文來自雲棲社區合作夥伴“Linux中國”
最後更新：2017-05-27 10:02:43