如何跨多個節點在雲（AWS，heroku等）中建立時鍾同步？

Question

我想在雲中運行一個龐大的節點集群（AWS，Heroku，或者可能是自我管理的VMS），其時鍾必須與預定義的容差同步。 我正在尋找可能200毫秒的容差。 這意味着如果我有250個節點，250個節點中任何一個節點之間的最大時鍾差異不應超過200毫秒。 我真的不關心世界的實際日期/時間。 解決方案必須具有容錯能力，並且不需要依賴任何一個系統的時鍾精度 - 實際上，很可能沒有一個時鍾會非常精確。

要求足夠強大，如果由於任何原因確定時鍾同步對於任何特定節點不可靠，我寧願由於時鍾失步而從群集中刪除節點 - 所以在任何可疑的故障時，我都會喜歡能夠執行該節點的某種類型的受控關閉。

我喜歡使用類似NTP的東西，但根據NTP 已知問題twiki ：

NTP不是為在虛擬機內部運行而設計的。 它需要一個高分辨率的系統時鍾，響應時間到時鍾中斷，並以高精度提供服務。 沒有已知的虛擬機能夠滿足這些要求。

雖然然后同樣的twiki描述了解決這種情況的各種方法（例如在主機操作系統上運行ntp），但我不相信我能夠使用AWS或者horoku來修改環境以符合解決方法。

即使我沒有在VM中運行，一位擁有多年運行ntp經驗的值得信賴的運營經理告訴我，ntp可以並且會因為每隔一段時間本地時鍾漂移不良而導致同步失敗（或者說時間錯誤）。 它不會經常發生，但確實會發生，並且隨着您增加機器，您會增加發生這種情況的機會。 AFAIK，檢測你的距離需要停止ntpd，運行查詢模式命令，然后重新啟動它，並且可能需要很長時間才能得到答案。

總結一下 - 我需要一個時鍾同步，其主要目標如下：

• 在運營控制有限的VM中運行良好（即：“雲服務提供商”）
• 所有參與者之間的集群中的時間容差約為200ms
• 能夠檢測壞節點並以主動方式對其作出反應
• 容錯（無單點故障）
• 可擴展（當你添加更多節點時，這個東西不能倒下 - 絕對避免n ^ 2）
• 可以支持數百個節點
• 任何節點都不應被視為具有優於任何其他節點的時間概念
• 整個集群可以漂移（在合理范圍內） - 只要它一致漂移即可

從描述來看，似乎伯克利算法可能是正確的選擇，但是它已經實現了嗎？

很高興有：

• 最小配置（節點自動注冊參與） - 對於啟動新節點很重要
• HTML儀表板或（REST？）API，用於報告參與時鍾同步的節點以及相對時間偏移量
• 漂亮的圖表？

Answer 1

由於NTP的常見問題解答明確說明了為什么NTP時間同步在虛擬機下無法正常工作，這可能是一個不可逾越的問題。

大多數機器都有一個RTC（實時時鍾），在PC上你可以如何存儲時間，以便你對ntp不可用的時間有一個“粗略”的猜測，一旦系統加載就有了'刻度更高的分辨率 - 這就是NTP設置的內容。

該滴答時鍾受虛擬機漂移的影響，因為滴答可能會或可能不會以正確的間隔發生 - 您嘗試使用的任何時間機制都將受到這種漂移的影響。

嘗試在虛擬機上強制執行ntp同步可能是次優設計，如果機器A和B的增量為200ms，機器B和C的增量為200ms，C可能距離A有400ms。您無法控制它。

你最好使用像zeromq這樣的集中式消息傳遞系統讓每個人都與作業隊列保持同步，這將是更多的開銷，但依靠系統滴答時間充其量只是一件狡猾的事情。 有許多聚類解決方案可以解決群集參與問題，使用各種可靠的機制來確保每個人都同步，看看corosync或傳播 - 他們已經解決了這個問題，例如兩階段提交。

順便說一下，當漂移過高時，ntp'放棄'可以通過指示它“把”時間“甩”到新值而不是“回轉”來規避。 默認情況下，ntp將逐步更新系統時間，以說明其從“實時”漂移。 我忘記了如何在ntpd中配置它，但如果使用ntpdate，則標志為-B

-B      Force the time to always be slewed using the adjtime(2) system call, even if the measured 
offset is greater than +-128 ms.  The default is to step the time using settimeofday(2) if the offset 
is greater than +-128 ms.  Note that, if the offset is much greater than +-128 ms in this case, it
can take a long time (hours) to slew the clock to the correct value.  During this time, the host 
should not be used to synchronize clients.

Answer 2

在與VM上的NTP斗爭了這么多個月之后，我們已經使用了chrony https://chrony.tuxfamily.org進行了切換。 我發現它在很多方面遠遠優於ntpd（配置，控制，文檔，處理問題，其中vm時鍾經常漂移和大幅度）。

使用chrony，不要回頭:)