分布式系统中要部署几台 NTP 服务器才够用?

简介:

陈硕 (giantchen_AT_gmail)

Blog.csdn.net/Solstice  t.sina.com.cn/giantchen


本作品采用“Creative Commons 署名-非商业性使用-禁止演绎 3.0 Unported 许可协议(cc by-nc-nd)”进行许可。
http://creativecommons.org/licenses/by-nc-nd/3.0/

分布式系统中各节点的时钟同步是必备的,虽然做不到完全同步(毕竟不是一个时钟域),但是借助 NTP 服务可以把同一个数据中心(同一个 LAN 上)内的机器的时钟同步到相互误差 1 毫秒上下,这通常已经够用了。(这里的机器指的是运行 Linux 或 FreeBSD 的机器,Windows 的时钟精度要差得多,不堪一用。)

那么要部署多少台 NTP 服务器才能达到比较高的可用性(availability)呢?

1 台肯定不够,因为是 single point of failure,它一旦坏了各台机器的时钟就会漂移。

2 台呢?似乎可以满足高可用的需求,坏一台也没关系。但是,一个人戴一块手表的时候知道时间,当他戴两块手表的时候就不知道哪个是准的了。如果数据中心里有两台 NTP 服务器,stratum 数又是一样(它们之间不相互同步,因此有时间差),在两台都正常工作的情况下,各台机器怎么知道应该跟哪台 NTP 服务器同步时钟呢?更糟糕的是,万一有一半的机器跟 NTP1 同步,另外一半跟 NTP2 同步,分属两个时钟阵营,岂不是比不同步好不了多少?(NTP 的算法规定只能和一台服务器同步时钟,不能取两台服务器的平均数来同步。)

3 台呢?似乎能打破僵局 (break the tie),有了三个候选者,但愿机器们能从中选出一台来与之同步时钟。但是,即便有 3 台服务器,仍然不能满足高可用的需求,只要有任何一台坏掉,就会退回到第 2 种情况,机器们又戴上了两个表。

4 台?根据以上分析,似乎要 4 台 NTP 服务器才能满足高可用的需求,您同意吗?在平时,有四个候选时钟,机器们可以自己选一个来同步,如果坏掉一个,仍然有三个以供选择,不会出现平局。在部署 4 台 NTP 的时候,可以考虑放两台在本数据中心,另外两台放在临近的数据中心,两个数据中心的机器可以共享这 4 台 NTP 服务器,以进一步提高可靠性。

更多?根据以上分析,如果容忍坏两台 NTP 服务器,那么要部署 5 台才够用,以此类推。

其实,在部署多台 stratum 相同的 NTP 服务器的情况下,似乎没有什么办法能让所有的机器都跟其中一台 NTP 服务器同步时间,各台机器有自己的选择,会造成 systematical 的时钟误差,在设计分布式系统的时候必须要充分考虑机器之间的时钟误差(以及可能的时钟跳变)。

NTP 服务器不同于一般的服务器,它有独特的部署要求,见:Brad Knowles 写的 Building scalable NTP server infrastructuresIt's about time ...

数据中心应该有自己的 stratum 1 NTP 服务器

Stratum 1 是最高等级的 NTP 服务器,它直接连到参考时钟(refclock),能够独立报时。

受益于 GPS 模块的普及(淘宝上一百块以内),stratum 1 NTP 服务器可以低成本 DIY,只要设法把 GPS 模块的 pulse per second 信号接到 ntpd 就行。传统做法是通过串口的 DCD 信号(不过可能抖动 jitter 比较大),如果主板上有 GPIO ,可以有更精确的手段,见 A home-built NTP appliance。我准备在家装个 stratum 1 NTP 来玩。

另外,为了提高精度与稳定度,可以用 GPS 驯服钟(简单的可以用恒温晶振+锁相环 DIY),这比直接使用廉价 GPS 模块更好(当然,在其他各项条件足够好的情况下才能看出区别)。

数据中心部署 stratum 1 NTP 的难点恐怕不在 NTP 服务器本身,而是找能看见足够的天空的地方装 GPS 天线,再专门为之布线,让 GPS 模块能正常工作。在家玩就简单得多,把 GPS 模块的天线贴到窗台上就行。

思考:如何监控 stratum 1 NTP 服务器是否工作正常呢?看一个表准不准,得用比它更准的时钟源,那么如何判断 stratum 1 的 NTP 服务器的时钟是否精确呢?有没有比它更准的时钟?在数据中心放原子钟吗?其实民用原子钟也不贵,几千块钱(二手 FE-5680A 铷钟在淘宝卖 100 块左右),体积跟移动硬盘差不多大。


   本文转自 陈硕  博客园博客,原文链接:http://www.cnblogs.com/Solstice/archive/2011/05/31/2063870.html,如需转载请自行联系原作者




目录
打赏
0
0
0
0
348
分享
相关文章
DeepSeek服务器繁忙解决方法:使用阿里云一键部署DeepSeek个人网站!
通过阿里云一键部署DeepSeek个人网站,解决服务器繁忙问题。学生用户可领取300元代金券实现0成本部署,普通用户则可用99元/年的服务器。教程涵盖从选择套餐、设置密码到获取百炼API-KEY的全流程,助您快速搭建专属大模型主页,体验DeepSeek、Qwen-max、Llama等多款模型,无需代码,最快5分钟完成部署。支持绑定个人域名,共享亲友使用,日均成本仅约1元。
158 10
YashanDB分布式可视化部署
本文介绍YashanDB的分布式部署流程,涵盖服务端安装、数据库基本信息与服务器配置、节点信息设置、建库参数调整、环境变量配置及安装结果检查等步骤。通过可视化Web界面操作,详细说明了各环节配置方法和注意事项,确保用户顺利完成数据库集群的搭建与初始化设置。适用于需要分布式数据库部署的场景,提供全面的操作指导。
YashanDB分布式可视化部署
Vue项目部署:如何打包并上传至服务器进行部署?
以上就是Vue项目打包及部署的方法,希望对你有所帮助。描述中可能会有一些小疏漏,但基本流程应该没有问题。记住要根据你的实际情况调整对应的目录路径和服务器IP地址等信息。此外,实际操作时可能会遇到各种问题,解决问题的能力是每一位开发者必备的技能。祝你部署顺利!
239 17
Koupleless 助力「人力家」实现分布式研发集中式部署,又快又省!
本文由仁励家网络科技(杭州)有限公司架构师赵云兴、葛志刚撰写,探讨了公司在优化HR SaaS解决方案时遇到的系统资源浪费和运维成本高的问题。通过引入Koupleless框架,成功将模块体积从500M缩减至5M以下,部署时间从6分钟缩短至3分钟,并大幅节省服务器资源。文章详细介绍了Koupleless的部署方案及优化措施,感谢Koupleless团队的专业支持,使人力家实现了多应用合并部署,降低了运维成本。
Koupleless 助力「人力家」实现分布式研发集中式部署,又快又省!
Koupleless 助力「人力家」实现分布式研发集中式部署,又快又省!
通过引入Koupleless框架,解决了多应用部署中资源浪费和运维成本高的问题,实现了模块瘦身、快速部署及流量控制优化,大幅降低了服务器资源占用和发布耗时,提升了系统稳定性和运维效率。最终,人力家成功实现了多应用的轻量集中部署,显著减少了运维成本。
 Koupleless 助力「人力家」实现分布式研发集中式部署,又快又省!
Docker——阿里云服务器使用Docker部署python项目全程小记
本文记录了我在阿里云服务器上使用Docker部署python项目(flask为例)的全过程,在这里记录和分享一下,希望可以给大家提供一些参考。
188 1
【已解决】Matomo本地SMTP配置可以发邮件,但部署到阿里云ECS就发不了邮件
在阿里云ECS上使用Matomo和PHPMailer发送邮件时遇到问题,邮件无法发出且接口调用Pending。经过排查,发现是ECS安全组未开放25/465端口,导致SMTP请求无法正常通信。解决方法为在安全组中配置并开放25/465端口,从而恢复邮件发送功能。
Linux服务器部署docker windows
在当今软件开发中,Docker成为流行的虚拟化技术,支持在Linux服务器上运行Windows容器。流程包括:1) 安装Docker;2) 配置支持Windows容器;3) 获取Windows镜像;4) 运行Windows容器;5) 验证容器状态。通过这些步骤,你可以在Linux环境中顺利部署和管理Windows应用,提高开发和运维效率。
197 1
大道至简-基于ACK的Deepseek满血版分布式推理部署实战
大道至简-基于ACK的Deepseek满血版分布式推理部署实战
132 5
基于ECS部署DeepSeek个人专属AI网站
本方案介绍了如何基于云服务器ECS集成百炼API和Open WebUI服务,一键部署体验DeepSeek个人专属AI网站。用户不仅可以以极低的成本,拥有个人专属的AI网站,进行稳定的AI对话,还能够切换DeepSeek-V3、DeepSeek-R1、Qwen-max等模型进行体验。同时Open WebUI还具备开源能力,支持定制工具的开发。您还可以创建其他子账号,将您的专属AI网站分享给他人使用。

热门文章

最新文章