Centos6

NTP:如何為 NTP 伺服器建立冗餘解決方案?

  • November 15, 2015

在我公司的基礎設施中,有 5 個位於偏遠地區的數據中心。

在每個遠端位置,有一對伺服器持有 DNS 和 NTP 服務,並在該位置的每台伺服器上進行配置,以從這兩個伺服器獲取 DNS 和 NTP 呼叫。

所有伺服器都是 CentOS 6.x 機器。

就 DNS 和 NTP 而言,在這兩個伺服器之間創建冗餘是有動機的。

DNS部分被覆蓋,我只有NTP問題。

什麼是正確的方法來確保當一個 NTP 伺服器出現故障時,第二個/其餘伺服器將繼續為客戶端服務,就像什麼都沒發生一樣?

我已經用Google搜尋了它並找到了一個RedHat 解決方案,將其中一個伺服器設置為主伺服器(通過在客戶端中將其配置為“true”),但萬一“true”(主)伺服器出現故障……然後它失敗了,客戶端不會從中獲取 NTP 更新,所以它不是一個純粹的冗餘解決方案。

我想知道是否有人有配置此類解決方案的經驗?

編輯#1:

為了測試 MadHatter 的答案,我做了以下事情:

  1. 我已經在每個 NTP 客戶端上配置為“首選”的伺服器上停止了 NTPd。
  2. 我正在等待 NTP 客戶端停止針對此伺服器工作並開始針對它的合作夥伴 NTPd 伺服器工作。
  3. 我正在ntpq -p客戶端上執行以查看更改。這是的輸出ntpq -p
[root@ams2proxy10 ~]# ntpq -p
    remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
10.X.X.38      .INIT.          16 u    -  128    0    0.000    0.000   0.000
*10.X.X.39      131.211.8.244    2 u    2   64  377    0.123    0.104   0.220

什麼是“在 ntpq 中”?請問我應該執行哪個命令?

編輯#2: as 的輸出:

[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.X.X.38      .INIT.          16 u    -  512    0    0.000    0.000   0.000
*10.X.X.39      131.211.8.244    2 u   36   64  377    0.147    0.031 18874.7
ntpq>

我懷疑這不是問題:NTP 已經對此具有彈性。

您沒有“主要”NTP 伺服器和一些輔助伺服器:您有一組已配置的伺服器。NTPd 將決定哪個是可靠的,哪個最有可能提供良好的時間信號,並且它將不斷重新評估其決定。

這是過去一個月左右來自我的 NTP 池伺服器的一組綁定:

munin NTP 狀態圖

如您所見,大部分時間狀態 6(系統對等體)被綠線佔用ntp0.jonatkins.com,這是我通過權限綁定到的第 1 層伺服器(我所有其他伺服器都是第 2 層,因此 NTPd 更喜歡更高的層伺服器(如果沒有其他因素適用)。

但是您可以在第 44 周初看到該線的下降,並且圖像下方的數值證實,在圖表期間,ntp0.jonatkins.com下降到狀態 4(離群值),而linnaeus.inf.ed.ac.uk,其大部分時間都處於狀態 5(候選人),但最高為 6(系統對等)。(這些線不會一直下降到 4 / 最多 6,因為這些是 5 分鐘原始數據的 2 小時平均值;可能發生的任何事情都持續了不到 2 小時,因此已經被平滑了。)

這表明,在我沒有任何意見的情況下,NTPd 在某個時候決定其通常的對等點不夠可靠,並在“中斷”期間選擇了最佳替代源。一旦其首選對等方再次通過其內部 QA 測試,它就會恢復為對等方狀態。

引用自:https://serverfault.com/questions/736488