NTP:如何为NTP服务器build立冗余解决scheme?

在我公司的基础设施中,远程位置有5个数据中心。

在每个远程位置,都有一对服务器用于存放DNS和NTP服务,并在该位置的每台服务器上进行configuration,以便从这两台服务器获得DNS和NTP呼叫。

所有的服务器都是CentOS 6.x机器。

在DNS和NTP方面,在这两个服务器之间创build冗余是一个动机。

DNS部分被覆盖,我只有NTP的问题。

什么是正确的方法,以确保当一个NTP服务器发生故障时,第二/其余的服务器将继续为客户端服务,就像什么都没有发生?

我已经Google了解它,发现一个RedHat解决scheme ,将其中一个服务器设置为主服务器(通过在客户端configuration为“真”),但在“真正”(主服务器)服务器失败…然后它失败了,客户端不会从它那里得到NTP更新,所以它不是一个纯粹的冗余解决scheme。

我想知道有没有人configuration这样的解决scheme的经验?

编辑#1:

为了testingMadHatter的答案,我做了以下工作:

  1. 我已经停止在每个NTP客户端上configuration为“首选”的服务器上的NTPd。
  2. 我正在等待NTP客户端停止对这个服务器的工作,并开始对付它的合作伙伴NTPd服务器。
  3. 我正在客户端上运行ntpq -p来查看更改。 这是ntpq -p的输出:
 [root@ams2proxy10 ~]# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== 10.XX38 .INIT. 16 u - 128 0 0.000 0.000 0.000 *10.XX39 131.211.8.244 2 u 2 64 377 0.123 0.104 0.220 

什么是“在ntpq”? 请问我该跑哪个命令?

编辑#2:输出为:

 [root@ams2proxy10 ~]# ntpq ntpq> as ind assid status conf reach auth condition last_event cnt =========================================================== 1 64638 8011 yes no none reject mobilize 1 2 64639 963a yes yes none sys.peer sys_peer 3 ntpq> 

pe的输出:

 ntpq> pe remote refid st t when poll reach delay offset jitter ============================================================================== 10.XX38 .INIT. 16 u - 512 0 0.000 0.000 0.000 *10.XX39 131.211.8.244 2 u 36 64 377 0.147 0.031 18874.7 ntpq> 

我怀疑这是一个没有问题的问题:NTP已经很有弹性了。

您没有“主要”NTP服务器和一些次级服务器:您有一组configuration的服务器。 NTPd将决定哪一个是可靠的,哪个最有可能提供一个好的时间信号,并且会不断地重新评估它的决定。

这是我的NTP池服务器在过去一个月左右的一组绑定:

munin NTP状态图

正如你所看到的,大部分时间状态6(系统对等)被绿线占用, ntp0.jonatkins.com ,这是我与权限绑定的层1服务器(我所有的其他服务器是层2,所以如果没有其他因素适用,NTPd更喜欢更高层的服务器)。

但是你可以在第44周早些时候看到这一行的下降,图像下面的数字确认在图表的这段时间内, ntp0.jonatkins.com下降到第4状态(outlyer),而linnaeus.inf.ed linnaeus.inf.ed.ac.uk ,大部分时间花在状态5(候选人)上,尽pipe如此,他仍然在6(系统同行) linnaeus.inf.ed.ac.uk 。 (线路不能一路下降到4/6,因为这些是5分钟原始数据的2小时平均值,大概不pipe发生的时间明显less于2小时,因此已经被平滑掉了。)

这表明,在没有任何投入的情况下,NTPd在某些时候决定,其通常的同行是不够可靠的,在“停电”期间select了最好的替代来源。 只要其首选对等设备再次通过了内部质量保证testing,就会恢复到对等状态。

四个或更多的NTP对等体提供Falseticker检测和n + 1冗余。 这也是红帽的build议 (尽pipe现在看来只是用户的内容)。

select4个或更多Internet源或使用NTP池项目。 如果有的话,添加GPS时钟等非互联网资源。 将所有NTP服务器configuration为所有这些源。

validation您的NTP服务器分布在整个基础设施中,尽可能less地使用单点故障。 使用不同的机架,配电,networking和互联网连接,数据中心等

configuration所有“客户端”主机以使用所有的NTP服务器。 每个客户端至lessconfiguration4个。

这种configuration非常有弹性。 你可能会失去任何单一的NTP对等点,并且仍然可以检测到错误的语句,并抛出一个疯狂的时钟。