Cloud 如何在云中跨多个节点（AWS、heroku等）建立时钟同步？

我想在云中运行一个大型节点集群（AWS、Heroku，或者可能是自管理的VM），其时钟必须与预先定义的容差同步。我正在寻找一个大概200毫秒的公差。这意味着如果我有250个节点，那么250个节点之间的最大时钟差永远不会超过200毫秒。我并不真正关心世界的实际日期/时间。解决方案必须是容错的，并且不需要依赖任何一个系统的时钟精度——事实上，很可能没有一个时钟会非常精确

如果出于任何原因，任何特定节点的时钟同步被确定为不可靠，那么我希望由于时钟失步而从集群中删除一个节点——因此，对于任何可疑的故障，我希望能够对该节点执行某种类型的受控关机

我很想使用NTP之类的东西，但根据NTP：

NTP不是为在虚拟机内运行而设计的。 它需要一个高分辨率的系统时钟，以及对时钟中断的响应时间 以高精度进行维修。不存在已知的虚拟机 能够满足这些要求

尽管同一个twiki接着描述了解决这种情况的各种方法（比如在主机操作系统上运行ntp），但我认为我没有能力使用AWS或horoku对环境进行足够的修改，以满足解决方法的要求

即使我没有在虚拟机中运行，一位有多年运行ntp经验的可信运营经理告诉我，ntp会偶尔因为糟糕的本地时钟漂移而停止同步（或者干脆把时间弄错）。这种情况并不经常发生，但确实发生了，随着机器的增加，这种情况发生的几率也随之增加。顺便说一句，检测距离您有多远需要停止ntpd，运行查询模式命令，然后重新启动它，并且可能需要很长时间才能得到回复

总之，我需要一个时钟同步，其主要目标如下：

• 在操作控制受限的VM中运行良好（即：“云服务提供商”）
• 集群中所有参与者之间的时间容差约为200ms
• 能够检测坏节点并以主动方式对此作出反应
• 容错（无单点故障）
• 可伸缩性（当您添加更多节点时，这件事不会失败——一定要避免n^2）
• 可以支持数百个节点
• 任何节点都不应被视为具有优于任何其他节点的时间概念
• 整个集群漂移（在合理范围内）是可以的——只要它同步漂移

从描述来看，在这里似乎是正确的选择，但是它已经实现了吗

很高兴拥有：

• 最小配置（节点自动注册以参与）--对于启动新节点非常重要
• HTML仪表板或（REST？）API，用于报告参与时钟同步的节点以及相对时间偏移量
• 漂亮的图形

由于明确说明了NTP时间同步在虚拟机下无法“正确”工作的原因，这可能是一个无法克服的问题

大多数机器都有一个RTC（实时时钟），在PC机上，它是如何存储时间的，这样，如果ntp不可用，您就可以“粗略”猜测时间，一旦系统加载，就会有一个更高分辨率的“滴答”时钟-这就是ntp设置的

该滴答声时钟受虚拟机漂移的影响，因为滴答声可能以正确的间隔发生，也可能不以正确的间隔发生-您尝试使用的任何时间机制都将受该漂移的影响

尝试在虚拟机上实施ntp同步可能是次优设计，如果机器A和B的增量为200ms，而机器B和C的增量为200ms，那么C可能距离A 400ms。这是无法控制的

您最好使用像zeromq这样的集中式消息传递系统来保持每个人都与作业队列同步，这样会增加开销，但依赖系统计时充其量是一件不可靠的事情。有许多集群解决方案考虑到集群参与，它们使用各种可靠的机制来确保每个人都是同步的，看看corosync或spread——它们已经解决了这一问题，例如两阶段提交

顺便说一句，当漂移太大时，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.

---

在虚拟机上与NTP抗争了这么多个月之后，我们改用chrony。我发现它在很多方面（配置、控制、文档、处理虚拟机时钟经常剧烈漂移的问题）都远远优于ntpd

---

使用chrony，不要回头看：）

我希望我不需要粗略的时钟同步，但在这种情况下，我想我需要。设想一个处理大量事件类型工作的系统。其中大部分是通过外部职位进入系统的。但想象一下，这些事件中有许多会导致需要定时的未来事件。因此，事件X希望从现在开始安排事件Y，n秒，我们希望事件Y能够在云中的任何节点上处理。因此，如果你能在没有时间集中概念的情况下解决这个问题，我会很高兴听到这个消息。我强烈建议你看看zeromq如果你想要一个低级别的解决方案，它的LGPL，有很好的文档和多平台，支持uni和多播。如果你能进入一个李