所以,我最近意识到,由于我的网络中有 3 个 GPS 时钟,从技术上讲,我可以回馈一点,为世界其他地方提供时间。到目前为止,我还没有看到这个想法有任何缺点,但我有以下问题;
我可以虚拟化这个吗?我不会为此花费金钱和时间来建立硬件,因此虚拟化是必须的。由于服务器将可以访问三个第 1 层源,如果 ntpd 配置正确,我看不出这会是什么问题
公共 NTP 服务器(pool.ntp.org 的一部分)通常会看到什么样的流量?我需要多大的虚拟机?据我所知,ntpd 不应该占用太多资源,但我宁愿事先知道。
这有哪些安全方面?我正在考虑只在 DMZ 中的两个 VM 上安装 ntpd,只允许 ntp 通过 FW 进入,并且只允许 ntp 从 DMZ 输出到内部 ntp 服务器。似乎也有一些根据 NTP 池页面推荐的 ntp 设置,但它们是否足够?https://www.ntppool.org/join/configuration.html
他们建议不要配置本地时钟驱动程序,这是否等同于从配置文件中删除本地时间源配置?
还有什么要考虑的吗?
首先,对你有好处;这是一件乐于助人且具有公益精神的事情。话虽如此,并且您澄清说您计划创建一个或多个 DMZ 虚拟机,这些虚拟机将同步到您的三个支持 Meinberg GPS 的 Stratum-1(内部)服务器并公开提供时间:
编辑:虚拟化不时出现在池列表中进行讨论;最近的一个是在 2015 年 7 月,可以从这封邮件开始关注。问 Bjørn Hansen,项目负责人,确实在线程中发帖,并没有公开反对虚拟化。显然,许多池服务器运营商现在正在虚拟化,所以我认为没有人会为它开枪,正如一张海报所表明的那样,如果你的服务器不可靠,池监控系统只会将它们从水池。KVM 似乎是首选的虚拟化技术;我没有发现任何人专门使用 VMWare,因此无法评论虚拟化有多“诚实”。 也许关于这个主题的最好的总结说
这是过去一年我在我的池服务器(位于英国、欧洲和全球区域)上看到的每秒不同客户端的日平均数:
这几乎没有可检测到的系统负载(
ntpd
大多数时候似乎使用了 1% 到 2% 的 CPU)。请注意,在一年中的某个时间点,负载曾短暂达到每秒近 1000 个客户端的峰值(最大值:849.27);我确实监控过负载,但警报并没有全部响起,所以我只能注意到即使是那个级别的负载也没有引起问题,尽管是短暂的。项目推荐的配置是最佳实践,对我有用。我还
iptables
习惯在一个滚动的 10 秒窗口中将客户端速率限制为两个入站数据包(令人惊讶的是那里有多少粗鲁的客户端,他们认为他们应该可以自由爆发以便快速设置自己的时钟)。或者删除任何引用以 . 开头的服务器地址的行
127.127
。最佳实践指南还建议使用三个以上的时钟,因此除了三个第一层服务器之外,您可能还需要选择几个其他公共服务器或特定池服务器。
我还要注意,如果您打算将这两个虚拟机放在同一个主机硬件上,您可能应该只运行一个,但将声明给池的带宽增加一倍(即,接受两倍于其他方式的查询)。
首先,恭喜您提出了一个非面谈材料的 NTP 问题。:-) 我在这篇文章的底部添加了一些图表,让您对事物有所了解。有问题的 VM 在池控制面板中设置为 100 Mbps,并且位于英国、欧洲和全球池中。
我认为 MadHatter 很好地涵盖了这一点——虚拟化应该没问题。就像你说的那样,如果它们是从你的 GPS 连接的地层 1 中获取的,它们应该是相当坚固的。根据我的经验,在频率方面,VM 往往比裸机更跳跃(见下图),但这正是您所期望的 - 它们正在处理时钟仿真层(希望非常有效)并且可能有噪音邻居。如果您不想看到这种跳跃,可以使用较旧的服务器或未使用的桌面作为您的 DMZ 层 2。
这个虚拟机是 1 个核心,2 GB RAM,运行 Ubuntu 16.04 LTS,在 OpenStack(KVM 管理程序)中虚拟化。如您所见,RAM 有点过头了。
推荐的设置——包括不配置本地驱动程序——是 Ubuntu 16.04 中的默认设置。除了同行列表之外,我的运行非常接近库存配置。
(看上面)
我可能会在低端开始带宽,并在您监控一段时间后提高带宽。如果您的虚拟机彼此靠近并且在网络延迟方面靠近您的第 1 层,我可能会让所有虚拟机与所有第 1 层通信,并且可能彼此对等并打开孤立模式。
这是图表——它们都涵盖了大约 3 周的同一时期,除了网络之一,由于备份而出现了几个峰值。当出现网络高峰时,我什至看不到正常的 NTP 流量,所以我放大一点以显示通常的背景。
CPU 内存 网络 频率 系统偏移
NTP 需要考虑的一些事项
这里已经有很好的答案了。为了完整起见,我只是根据自己的经验添加一些想法。
我建议在裸机与 VM 上启用 NTP 日志记录和图形时钟偏差和更正,因为如果这是一个问题,它与该讨论有关。我不相信这可以很容易地概括,因为硬件和配置因实现而异。最好在那个上获得你自己的号码。
我一直建议人们选择具有相当恒定的 CPU 时间并且不是无滴答内核或启用了省电模式的服务器或网络设备的系统角色。尤其要避免守护进程在 NTP 服务器上使用 cpuspeed 或速度调节器或高级节能,即使它们只是您场中的第 2 层。永远不要超过 C-State 1 可以获得一些稳定性,但您的功耗会增加。
我还尝试确保人们选择离网络边缘不到 40 毫秒的少数第 1 层服务器,然后将它们分配到边缘 NTP 服务器上,并确保网络中同一 SNAT 后面的 2 台服务器没有在通话到相同的第 1 层服务器。与 相同
burst
,在同一个 SNAT 后面使用相同的上游服务器让多个服务器是不明智的,因为在他们看来,即使您没有启用突发,您也已启用。您应该始终尊重
kod
来自上游服务器的数据包,并使用监控工具检查上游服务器的时间偏移和可达性。您可能需要考虑在一些数据中心中拥有自己的准确时间源,以便在军方启用 GPS SA 的不太可能的情况下与之对等或依赖。有专门为此而设计的具有成本效益的设备。即使您处于“笼式”环境中并且没有自己的数据中心,一些托管设施也可以适应这种情况。
请参阅http://www.vmware.com/pdf/vmware_timekeeping.pdf上的 vmware 计时文档
在 VM 中运行 NTP 守护程序可能不是一个好主意,尤其是在您需要可靠时间的情况下。
这是来自 VMware 的一个很好的 KB,其中包含不同 Linux 发行版的实际配置参数
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427