Avamar：故障診斷 Avamar「asktime」和相關 NTP 問題

此解決方案旨在提供有關 Avamar 網格所使用的網路時間通訊協定 （NTP） 的使用和設定的其他資訊。

它還針對使用 NTP 配置期間出現的問題提供了更多詳細資訊和故障排除步驟，使用 asktime 效用。

其中涵蓋了為新增節點或額外伺服器 （例如網路資料管理通訊協定 （NDMP） 加速器） 設定 NTP 所需的步驟。

Avamar 使用 NTP 在外部時間來源和所有 Avamar Data Store （ADS） 節點上維持時間同步。

ADS 軟體套裝包含公用程式詢問時間，用於設定 NTP。這可以是設置過程的一部分，如果需要，也可以手動執行。 

本文的目的是提供有關故障診斷的其他資訊和提示 asktime 以及NTP相關問題。

部分 #1 - 基本 NTP 功能：

• 所有節點 （公用程式和儲存裝置） 應輪詢一或多個使用者或公用 NTP 伺服器。
• 所有儲存 （資料） 節點均應輪詢相同的使用者伺服器。此外，存儲節點輪詢工具節點 （0.s） 和第一個存儲節點 （0.0）。
• 工具節點以本地時間運行。所有儲存節點均以 UTC 執行。

2.這裡的目的是所有節點都可以獨立維護時間。（在外部 NTP 伺服器無法使用時，節點繼續能夠使用 0.s 和 0.0 保持同步。

部分 #2 - 用於檢查 NTP 功能的其他 UNIX 實用程式：

• service ntpd status/stop/start - 驗證網路時間協定守護程式 （NTPD） 是否正在運行/停止並根據需要啟動。
• date - 顯示目前的系統日期和時間。
• ntpdate - 用於輪詢遠端 NTP 伺服器，並在需要時設置本地系統時鐘。
• ntpq - 用於查看目前的 NTP 連線能力。  

部分 #3 - 用於檢查 NTP 功能的其他 Avamar 公用程式：

使用 "check.dpn --preinstall --checktime」 的指令檔，以在所有或指定的節點上自動執行 NTPD，以驗證節點是否正確執行 NTPD，且已選取時間伺服器。
安裝程式和 GSAN 在啟動時，因此它是NTPD是否按要求工作的關鍵指標。

這些命令，尤其是在與 mapall 命令應足以調試大多數與 NTP 相關的錯誤。

第 #4 節 - 針對 NTP 問題進行故障診斷：

1.NTP 問題通常會在執行新安裝時立即發生，原因是 timeserver 客戶提供的位址，或因防火牆或路由問題而提供的地址。  

2.當 （正常運作一段時間後） 對客戶網路進行變更、移除 NTP 伺服器等時，也會出現 NTP 問題。隨著時間的推移，這開始影響 Avamar 網格。  

3.若要將安裝期間發生問題的風險降至最低，請使用 ntpdate 具有除錯選項 （-d） 以驗證一個或多個分配的時間伺服器是否可用並提供服務請求。

有關完整的示例輸出，請參閱附錄 A 。

在下面的範例中，可以看到 Avamar 節點和時間伺服器之間的握手。在這種情況下，時間伺服器報告 0.000006 秒的小偏移：  

ntpdate -d 168.xxx.xx.x

offset 0.000006
29 Dec 15:47:15 ntpdate[10500]: adjust time server 168.xxx.xx.x offset 0.000006 sec 

將此與 timeserver 這是不可用的。

ntpdate -d 168.xxx.xx.x

offset 0.000000
29 Dec 15:49:13 ntpdate[10699]: no server suitable for synchronization found 

在此範例中，很明顯時間伺服器不可用，並且如果 asktime 將對此進行操作 timeserver 它永遠不會被視為同步。 

在此情況下，請與客戶合作，確認指派的位址正確無誤，以及 NTP 連接埠 （UDP 123） 未被防火牆阻止。

4.不要依賴簡單的 ping 測試來驗證 timeserver) 在 NTP 解除封鎖的情況下，防火牆可能會封鎖 ping，反之亦然。 Ntpdate 在使用 NTP 時有效地取代 ping，以驗證連線能力。

5.所有節點都必須能夠與外部時間伺服器通訊，這可以使用 Avamar 進行驗證 mapall 命令：
（假設 Avamar 已安裝，且 probe.xml 檔案已正確設定。）

mapall --all --user=root ntpdate -d 168.xxx.xx.x

6.根據上述範例，檢閱輸出結果，並確認所有節點都可以與時間伺服器通訊。

如果所有節點都根據需要進行通信，則運行 ntpdate 沒有”-d」旗標以實際更新系統時間 （假設 NTPD 尚未執行）：

mapall --all --user=root ntpdate 168.xxx.xx.x

Using /usr/local/avamar/var/probe.xml
(0.s) ssh  -x  root@10.x.xxx.xxx 'ntpdate 168.xxx.xx.x'
29 Dec 17:40:41 ntpdate[23552]: adjust time server 168.xxx.xx.x offset 0.014792 sec
(0.0) ssh  -x  root@10.x.xxx.xxx 'ntpdate 168.xxx.xx.x'
30 Dec 01:40:42 ntpdate[18131]: adjust time server 168.xxx.xx.x offset 0.029407 sec
(0.1) ssh  -x  root@10.x.xxx.xxx 'ntpdate 168.xxx.xx.x'
30 Dec 01:40:43 ntpdate[16250]: adjust time server 168.xxx.xx.x offset 0.000689 sec

注意：重新啟動 NTPD 服務 （服務 NTPD 重新開機） 呼叫 ntpdate 以執行類似的步驟。但是，當服務從內部重新啟動時 asktime 沒有立即的指標表明 ntpdate 命令成功或失敗。理想情況下 asktime 應單獨運行以驗證連接是否良好。

部分 #5 - NTP 伺服器選擇：

客戶網站上的 NTP 服務可能由網路團隊管理，而備份 （Avamar） 則更可能由伺服器團隊管理。 

伺服器團隊可能不知道 NTP 伺服器，也不知道允許連線所需的任何防火牆變更，或變更要求等。

因此，請在安裝前進行規劃，並確保客戶事先知道需要什麼。

• 許多路由器配置為運行NTP，因此請嘗試使用預設閘道IP。如果有回應，請確認時間是否正確！
• Windows Active Directory （AD） 伺服器預設會執行 NTP。但是，這些可以在通常不可靠的虛擬機上運行。如果 ntpdate 回報良好的連線，但 NTPD 無法與目標建立良好的同步，請與客戶合作尋找良好的本機時間來源。
• 如果可以找到時間來源，請務必先與客戶確認該來源是否合適，再設定 Avamar 以使用它。
• 如果可能，請盡可能將NTP伺服器定位在本地園區內，以最大程度地減少由緩慢或高延遲連接引起的問題。
• 盡可能嘗試使用多個 NTP 伺服器。可用的伺服器越多，NTP 就越能比較各種伺服器並建立最準確的時間。

注意：Avamar 無法使用任何時間伺服器：資料節點會與 Avamar Utility Node 同步，但整個網格最終會在一段時間內發生漂移。

注意： check.dpn （因此安裝和 GSAN 啟動） 在選擇的服務時間少於三次時發出警告。這隻是一個警告而不是錯誤，但請嘗試在可能的情況下配置多個伺服器。

第 #6 節 - 進一步疑難解答：

偶爾，儘管 ntpdate 最初顯示良好 timeserver 握手，NTPD 始終無法使用 timeserver 作為權威時間源。這可以通過以下輸出來驗證： ntpq （詳情如下）：

• 正在重新執行 "ntpdate -d <timeserver>" 顯示波動的偏移值，指示提供的時間不一致（請參閱前面有關在虛擬機 （VM） 上運行的 NTP 的評論），或者高網路延遲導致問題。
• 執行中 ntpdate 針對幾個不同的 NTP 伺服器，始終顯示它們報告的時間不同;這可能只有幾秒鐘，但足以讓 NTPD 拒絕兩個伺服器作為有效的候選伺服器。
• 識別良好的本地 timeservers.如果在生成期間發生這種情況並影響計劃，請考慮在沒有任何時間伺服器的情況下生成（系統將恢復為工具節點作為時間源），並在以後使用重新配置時間伺服器 asktime 一旦可以正確驗證它們。     

部分 #7 - 使用 ntpq 若要檢查目前的 NTPD 狀態：

注意： 完整的解釋 ntpq 輸出數據超出了本文的範圍，但可以在此處引用： http://doc.ntp.org （外部連結）

可使用 ntpq 公用程式可用於檢視目前的 NTPD 組態和時鐘選擇一次 asktime 已手動運行或作為構建過程的一部分運行。  

典型輸出如下：  

ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+d-host.company.com 168.xxx.xx.xx    3 u   59   64  377   78.917   -6.205   8.690
+e-host.company.com 168.xxx.xx.xx    3 u   54   64  377   77.521   -4.340   8.744
+f-host.company.com 168.xxx.xx.xx    3 u   58   64  377   78.063   -1.381  10.317
+g-host.company.com 168.xxx.xx.xx    3 u   49   64  377   77.723   -6.972   8.570
*h-host.company.com 128.xx.xx.xx     2 u   49   64  377   77.003   -7.736   8.511
+i-host.company.com 130.xxx.xxx.xxx  2 u   42   64  377   78.341   -1.701   9.984
 j-host.company.com .INIT.          16 u    -  256    0    0.000    0.000 4000.00
 LOCAL(0)        LOCAL(0)         8 l   51   64  377    0.000    0.000   0.001

如果 ntpq 最初回應緩慢，這可能是因為它嘗試根據配置不正確的域名系統 （DNS） 配置解析時間伺服器的名稱。 

如果是這樣，請執行 ntpq 與 -n 標誌以跳過名稱查找。但是，請嘗試確定 DNS 無法解析名稱的原因並相應地進行修復：  

ntpq -pn

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+128.xxx.xx.xx   168.xxx.xx.xx    3 u   63   64  377   78.917   -6.205   8.690
+128.xxx.xx.xx   168.xxx.xx.xx    3 u   58   64  377   77.521   -4.340   8.744
+10.xxx.xxx.xx   168.xxx.xx.x     3 u   62   64  377   78.063   -1.381  10.317
+10.xxx.xxx.xx   168.xxx.xx.xx    3 u   53   64  377   77.723   -6.972   8.570
*168.xxx.xx.x    128.xx.xx.xx     2 u   53   64  377   77.003   -7.736   8.511
+168.xxx.xx.xx   130.xxx.xxx.xxx  2 u   46   64  377   78.341   -1.701   9.984
 168.xxx.xx.x    .INIT.          16 u    -  256    0    0.000    0.000 4000.00
 127.xxx.x.x     LOCAL(0)         8 l   55   64  377    0.000    0.000   0.001

對 ntpq 但是，輸出超出了本文檔的範圍 ntpq，其他 NTP 程式在 http://doc.ntp.org（外部連結）中有很好的記錄。 

Avamar 運作的關鍵是選擇正常時間伺服器，最左側欄中的星號會指出這一點。這是 i-host.company.com 或以上範例中的 168.xxx.xx.x。

前面的示例適用於工具節點。下列範例顯示一個儲存節點，該節點也在嘗試使用工具節點 （0.s） 和第一個儲存節點 （0.0） 作為時間來源：  

ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+d-host.company.com 168.xxx.xx.xx    3 u   36  128  377   78.403   15.627  26.941
+e-host.company.com 168.xxx.xx.xx    3 u   82  128  377   77.740   10.448  23.707
+f-host.company.com 168.xxx.xx.x     3 u   89  128  377   77.982  -16.786  18.895
+g-host.company.com 168.xxx.xx.xx    3 u   40  128  377   78.565    3.230  16.925
+h-host.company.com 10.xxx.x.xx      2 u   96  128  377   78.082    0.369  17.982
*i-host.company.com 128.xx.xx.xx     2 u   35  128  377   77.954   16.410  26.429
 j-host.company.com .INIT.          16 u    -  256    0    0.000    0.000 4000.00
+utility.company.com 168.xxx.xx.x    3 u   34  128  377    0.226   -1.589  15.290
+sn1.company.com  168.xxx.xx.xx    3 u   97  128  377    0.214   -6.072  31.263

• • • 無法在此設定中預先確定選取哪個時間伺服器作為授權時間來源 （如 ntpq -p 左欄中的輸出）。主要目標是確保正確選擇所有定義的時間伺服器並使其可用。ntpd 服務負責決定使用哪個時間伺服器。
    • j-host.company.com 不處理時間請求。左列中沒有字元，其他各種狀態處於啟動預設值，這很明顯;從未建立連接以啟動時間調整過程。這是測試時遇到的問題 ntpdate 有助於事先確定。
    • 在工具節點的輸出中 （utility.company.com） 和儲存節點 0.0 （sn.company.com） 也存在於如前所述的有效伺服器清單中。  

注意： 公用程式 （0.s） 和第一個儲存裝置 （0.0） 節點在完全穩定之前不會提供時間要求，因此這些伺服器可能會標示為 INIT 在初始配置后的一段時間內，因為它們不會回應請求，直到它們自己正確同步。

部分 #8 - 在其他節點上配置時間：

節點新增： 

過程產生器「容量升級過程」部分詳細記錄了在要添加到網格的其他存儲節點上配置時間服務。 

 其他節點 （加速器等）：

必須在加速器等其他節點上正確配置時間，以便正確記錄備份時間戳。這是一個手動過程：

一個。以根身分複製 /etc/ntp.conf 從現有儲存節點 （0.0 以外的） 到加速器。 

這會提供外部 節點的詳細資料 timeservers 和鍵（0.0 和 0.s）網格 timeservers.

b.以根身分編輯 /etc/ntp.conf 在工具節點 （0.S） 和第一個儲存節點 （0.0） 上。
（該 ntp.conf 檔案定義 NTP 的執行階段參數。）  

必須將新節點 IP 添加到節點 0.s 和 0.0 上的存取控制清單中，以允許它們回應來自加速器的請求：   

# - - - - -
# Inpidual DPN node restrictions - they can listen, but they can't
# change us, except as above.
#
restrict 10.x.xxx.xxx    nomodify
restrict 10.x.xxx.xxx    nomodify
restrict 10.x.xxx.xxx    nomodify
restrict <Accelerator server IP>    nomodify 

c. 新增加速器節點後，請在工具節點 （0.s） 和節點 0.0 上重新啟動 ntpd 服務，以便重新讀取設定檔：  

mapall --nodes=0.0,0.s --user=root service ntpd restart 

d. 在新節點上，以 root 身份將服務配置更改為在啟動時自動運行 ntpd：  

chkconfig --level 35 ntpd on 

e.在新節點上啟動 ntpd：

service ntpd start

ntpd: Synchronizing with time server:           [  OK  ]
Starting ntpd:                                  [  OK  ] 

f.加速器節點以本地時間報告。時區由檔案控制 /etc/localtime) 這是修改的內容 asktime 設置時區時。最簡單的設定方法是直接從工具節點複製它：

scp /etc/localtime root@accelerator:/etc/localtime

g.在新加速器節點上使用 date 命令驗證是否報告了正確的時間和時區。

部分 #9 - 正常操作期間的時間同步問題：

NTP 非常可靠，除非網路配置發生更改、修改時間伺服器 IP 等。 

當 Avamar 將其節點同步到公用程式和第一個儲存節點 （0.0 和 0.s） 時，可以進行變更，但暫時不會成為問題。

如果節點配置錯誤，它們可能無法與工具節點或第一個存儲節點同步，最終將與其他數據節點不同步。

網格 （GSAN） 檢查在每個維護活動啟動期間時間同步是否適當。如果任何節點上的時間差異超過兩秒，則活動將失敗。在一或多個節點上的 err.log 檔案中會看到類似以下內容的訊息：  

2010/12/30-02:23:10.57646 {0.3} [cpman:3411]  WARN: <0980> samconn::dpntimecheck retrying dpn time check mytime=1293675790
2010/12/30-02:23:10.57712 {0.3} [cpman:3411]  WARN: <0980> samconn::dpntimecheck retrying dpn time check mytime=1293675790
2010/12/30-02:23:10.57782 {0.3} [cpman:3411]  ERROR: <0001> samconn::dpntimecheck time mismatch: synchronize clocks and retry

或者這個來自 status.dpn：

Checkpoint failed with result MSG_ERR_BADTIMESYNC : cp.20101229150030 started Wed Dec 29 07:00:30

若要解決此問題，請參閱 ntpq 如上所述的輸出，以確定哪些節點無法同步以及原因。與客戶合作，查看是否因為最近的網路變更造成此問題。

造成這種情況的一個常見原因是 asktime 運行不正確，因為只選擇了新節點進行修改; asktime 正確設定這些節點，但不更新 ntp.conf 存取控制清單 0.s 和 0.0，以新增新節點的 IP。此外，它不會在這些需要重新讀取 ntp.conf 檔案中所定義。反過來，這意味著新節點永遠不會與網格同步時間。 

如果指定了外部時間伺服器，則它們應與該伺服器同步時間（網格也應該如此），以便網格和新節點看起來都具有權威時間伺服器。但是，額外的節點無法同步到 0.0 和 0.s，因此如果外部時間伺服器不可用，它們最終將不同步並失敗。

附錄 A： 

的範例輸出 ntpdate 顯示良好回應的命令：

ntpdate -d 168.xxx.xx.x

29 Dec 15:47:14 ntpdate[10500]: ntpdate 4.2.0a@1.1190-r Thu Oct  5 04:11:33 EDT 2006 (1)
Looking for host 168.xxx.xx.x and service ntp
host found : h-host.company.com
transmit(168.xxx.xx.x)
receive(168.xxx.xx.x)
transmit(168.xxx.xx.x)
receive(168.xxx.xx.x)
transmit(168.xxx.xx.x)
receive(168.xxx.xx.x)
transmit(168.xxx.xx.x)
receive(168.xxx.xx.x)
transmit(168.xxx.xx.x)
server 168.xxx.xx.x, port 123
stratum 2, precision -17, leap 00, trust 000
refid [168.xxx.xx.x], delay 0.10268, dispersion 0.00024
transmitted 4, in filter 4
reference time:    d0c646c4.f9ac7000  Wed, Dec 29 2010 15:46:12.975
originate timestamp: d0c64702.fb7f0000  Wed, Dec 29 2010 15:47:14.982
transmit timestamp:  d0c64702.f192b7fe  Wed, Dec 29 2010 15:47:14.943
filter delay:  0.10661  0.10268  0.10274  0.10298
         0.00000  0.00000  0.00000  0.00000
filter offset: -0.00184 0.000006 0.000053 -0.00000
         0.000000 0.000000 0.000000 0.000000
delay 0.10268, dispersion 0.00024
offset 0.000006
29 Dec 15:47:15 ntpdate[10500]: adjust time server 168.xxx.xx.x offset 0.000006 sec 

的範例輸出 ntpdate 顯示不良 回應的命令：

ntpdate -d 168.xxx.xx.x

29 Dec 15:49:09 ntpdate[10699]: ntpdate 4.2.0a@1.1190-r Thu Oct  5 04:11:33 EDT 2006 (1)
Looking for host 168.xxx.xx.x and service ntp
host found : j-host.company.com
transmit(168.xxx.xx.x)
transmit(168.xxx.xx.x)
transmit(168.xxx.xx.x)
transmit(168.xxx.xx.x)
transmit(168.xxx.xx.x)
168.xxx.xx.x: Server dropped: no data
server 168.xxx.xx.x, port 123
stratum 0, precision 0, leap 00, trust 000
refid [168.xxx.xx.x], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Wed, Feb  6 2036 22:28:16.000
originate timestamp: 00000000.00000000  Wed, Feb  6 2036 22:28:16.000
transmit timestamp:  d0c64778.b4da6e75  Wed, Dec 29 2010 15:49:12.706
filter delay:  0.00000  0.00000  0.00000  0.00000
         0.00000  0.00000  0.00000  0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
         0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000
29 Dec 15:49:13 ntpdate[10699]: no server suitable for synchronization found