NTPと同期してくれないときのトラブルシューティング
ラボ環境や検証環境だと、用意したNTPサーバーとESXi/VCSAが同期してくれないことがしばしばあると思います。
多くの場合はちょっとした設定の追加で解決できることが多いので、今回はその方法についてご説明します。
NTPサーバとの疎通確認
何はともあれ、まずはNTP側との疎通と動作確認が必要です。
以下のコマンドを実行してください。
※ESXiにはntpdateコマンドはないのでスキップしてください。
上のコマンドはNTPサーバと同期するコマンドです。NTPデーモンは時間がずれすぎている同期してくれないので、まずはこのコマンドで強制的に時間を合わせます。
下のコマンドはntpサーバの正常動作を確認するコマンドです。
このコマンドが失敗するようでは疎通やNTPサーバ側の問題ですのでそちらをご確認ください。
NTPサーバとの同期に時間がかかっている可能性
NTPサーバとの同期は一時間くらいかかることもあります。
その場合はiburstというオプションを付与することで初期同期までの時間を短縮できます。
/etc/ntp.conf内の外部NTPサーバのIPアドレスの後ろにiburstを追加することで設定可能です。
以下のような感じです。
##
48 server <ntp server ip> iburst
49 trustedkey
##
下のコマンドはntpサーバの正常動作を確認するコマンドです。
このコマンドが失敗するようでは疎通やNTPサーバ側の問題ですのでそちらをご確認ください。
NTPサーバとの同期に時間がかかっている可能性
NTPサーバとの同期は一時間くらいかかることもあります。
その場合はiburstというオプションを付与することで初期同期までの時間を短縮できます。
/etc/ntp.conf内の外部NTPサーバのIPアドレスの後ろにiburstを追加することで設定可能です。
以下のような感じです。
##
48 server <ntp server ip> iburst
49 trustedkey
##
上記の設定があることで何十分も同期を待たずに済みます。
実施後は/etc/init.d/ntpd restart でサービスを再起動してください。
なお、NTPサーバとしてインターネット上の公開NTPサーバを指定している場合はiburstは利用しないか、利用可能かどうかをサーバの管理者にお尋ねください。
社内のNTPサーバの場合はほぼほぼ問題ないとは思いますが、確認しておいた方が無難です。
NTPサーバからの時刻が信頼されていない可能性
iburst設定後や、十分な時間が経過した後でも同期しない場合は、NTPサーバからの情報をNTP Clientが信頼していない場合があります。
VCSAの場合
vcsa の場合は ntpdc コマンドで確認します。
# /usr/sbin/ntpdc -c 'showpeer <ntp ip address>'
remote <ntp ip address>, local <ntp ip address>
hmode client, pmode unspec, stratum 2, precision -6
leap 00, refid [xxx.xxx.xxx.xxx], rootdistance 0.03125, rootdispersion 8.30737
ppoll 6, hpoll 6, keyid 0, version 4, association 57089
reach 001, unreach 1, flash 0x0400, boffset 0.00400, ttl/mode 0
timer 0s, flags config, bclient
reference time: dc0bbd00.3f21a2e7 Tue, Dec 27 2016 1:00:00.246
originate timestamp: dc0c6b35.c3fed202 Tue, Dec 27 2016 13:23:17.765
receive timestamp: dc0c6b35.c3d4dc75 Tue, Dec 27 2016 13:23:17.764
transmit timestamp: dc0c6b35.c3bfd0d1 Tue, Dec 27 2016 13:23:17.764
filter delay: 0.00032 0.00032 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
filter offset: 0.000801 0.000480 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
filter order: 0 1 2 3
4 5 6 7
offset 0.000801, delay 0.00032, error bound 1.98726, filter error 0.01791
remote <ntp ip address>, local <ntp ip address>
hmode client, pmode unspec, stratum 2, precision -6
leap 00, refid [xxx.xxx.xxx.xxx], rootdistance 0.03125, rootdispersion 8.30737
ppoll 6, hpoll 6, keyid 0, version 4, association 57089
reach 001, unreach 1, flash 0x0400, boffset 0.00400, ttl/mode 0
timer 0s, flags config, bclient
reference time: dc0bbd00.3f21a2e7 Tue, Dec 27 2016 1:00:00.246
originate timestamp: dc0c6b35.c3fed202 Tue, Dec 27 2016 13:23:17.765
receive timestamp: dc0c6b35.c3d4dc75 Tue, Dec 27 2016 13:23:17.764
transmit timestamp: dc0c6b35.c3bfd0d1 Tue, Dec 27 2016 13:23:17.764
filter delay: 0.00032 0.00032 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
filter offset: 0.000801 0.000480 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
filter order: 0 1 2 3
4 5 6 7
offset 0.000801, delay 0.00032, error bound 1.98726, filter error 0.01791
!!! 注意 !!!
最近の NTP サーバでは ntpdc コマンドが利用する mode 7 がデフォルトで無効になっているため、コマンドが ”timed out, nothing received” となって失敗することがあるそうです。
その場合は、ESXi と同じく ntpq -classoc コマンドと、ntpq -c "rv xxxx" にてご確認ください。
ESXiの場合
ESXi には ntpdc コマンドは無いので ntpq コマンドで確認します。※ntpq コマンドを利用するためには ntp サービスが稼働している必要があります。
# /usr/sbin/ntpq -classoc
ind assid status conf reach auth condition last_event cnt
===========================================================
1 63674 961a yes yes none sys.peer sys_peer 1
# /usr/sbin/ntpq -classoc
ind assid status conf reach auth condition last_event cnt
===========================================================
1 63674 961a yes yes none sys.peer sys_peer 1
# /usr/sbin/ntpq -c "rv 63674" <<<< rv xxxx のIDは↑のコマンドのassidで確認
associd=63674 status=961a conf, reach, sel_sys.peer, 1 event, sys_peer,
srcadr=ntp-sv1.cpsd.local, srcport=123, dstadr=xxx.xxx.xxx.xxx, dstport=123,
leap=00, stratum=4, precision=-25, rootdelay=350.113, rootdisp=94.040,
refid=10.30.48.37,
reftime=e2b64f76.e5a956e2 Mon, Jul 13 2020 3:11:50.897,
rec=e2b650cc.9a6cec7e Mon, Jul 13 2020 3:17:32.603, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=10, ppoll=10, headway=0, flash=00 ok,
keyid=0, offset=3.212, delay=0.700, dispersion=19.482, jitter=0.630,
xleave=0.039,
filtdelay= 0.74 0.70 0.74 0.68 0.69 0.73 0.76 0.79,
filtoffset= 3.37 3.21 2.94 2.99 2.91 2.83 2.40 1.89,
filtdisp= 0.00 16.02 32.31 48.08 64.13 79.52 95.43 111.65
このコマンド出力中で注目すべきところは太字で強調したflash のところです。
flashの値は簡単にいえばエラーコードみたいなものです。
上の例ではVCSAは0x400 となっており、ESXiでは00 (0x0000)となっています。
flashの値の意味についてはntpのソースコードのヘッダファイルに説明があります。
#### ヘッダファイル引用
+++++ include/ntp.h
/*
* Define flasher bits (tests 1 through 11 in packet procedure)
* These reveal the state at the last grumble from the peer and are
* most handy for diagnosing problems, even if not strictly a state
* variable in the spec. These are recorded in the peer structure.
*
* Packet errors
*/
#define TEST1 0X0001 /* duplicate packet */
#define TEST2 0x0002 /* bogus packet */
#define TEST3 0x0004 /* protocol unsynchronized */
#define TEST4 0x0008 /* access denied */
#define TEST5 0x0010 /* authentication error */
#define TEST6 0x0020 /* bad synch or stratum */
#define TEST7 0x0040 /* bad header data */
#define TEST8 0x0080 /* autokey error */
#define TEST9 0x0100 /* crypto error */
#define PKT_TEST_MASK (TEST1 | TEST2 | TEST3 | TEST4 | TEST5 |\
TEST6 | TEST7 | TEST8 | TEST9)
/*
* Peer errors
*/
#define TEST10 0x0200 /* peer bad synch or stratum */
#define TEST11 0x0400 /* peer distance exceeded */
#define TEST12 0x0800 /* peer synchronization loop */
#define TEST13 0x1000 /* peer unreacable */
#define PEER_TEST_MASK (TEST10 | TEST11 | TEST12 | TEST13)
####
上記のように定められています。
今回の場合は flash 0x400なので、
TEST11のpeer distance exceededに該当することが分かります。
(多くの場合はこれが原因と思います・・・)
これは要するに同期先のNTPサーバまでの距離が遠いということです。
(距離が遠いと信頼性が下がりますからね。違ったら御免なさい)
デフォルトで許容されるホップ数がいくつなのかは不明ですが、
とりあえず増やしてあげれば解決する理屈です。
なのでホップ数を30まで増やすためにtosコマンドを/etc/ntp.confに追記しましょう。
まとめるとこんな感じです。
!!注意!!
ESXi 7.0U3 以降ではntp.confを直接編集できません。(したとしてもntp起動時に消える)
ESXi 7.0U3 以降でのワークアラウンドは後述します。
## /etc/ntp.conf
48 server <ntp ip address > iburst <<<< iburst 追記
49 trustedkey
50
51 tos maxdist 30 <<<< 追記
##
ntp.conf の設定が完了したら、ntp service を再起動しましょう。
この設定をすれば、少なくともflash 0x400の問題は解消できるはずです。
ntp service の再起動方法は以下です。
# VCSA 6.0
service ntp restart
# VCSA 6.5 or later
systemctl restart ntpd
# ESXi
/etc/init.d/ntpd restart
0x400以外の問題については別の対応が必要になると思います。
また、flash codeが正常 (0x00)なのに同期してくれない場合は、messagesログなどにntp デーモンのエラーが吐かれているかもしれませんので確認されることをお勧めします。
(補足)ESXi 7.0U3 以降の場合のワークアラウンド
ESXi 7.0U3 以降ではntp.confファイルを直接編集することができなくなっています。
参照: vSphere ESXi 7.0 U3 and later versions NTP configuration steps loading a text file containing NTP configuration commands (broadcom.com)
参照: vSphere ESXi 7.0 U3 and later versions NTP configuration steps loading a text file containing NTP configuration commands (broadcom.com)
その為、NTPの設定はGUIから入力するしかありませんが、その場合はiburst や tos maxdist 30 などのオプション設定を加えることができません。
そのため、上記KBに記載のある通り、構成ファイルを作成してCLIで読み込ませることでオプション設定も含めて反映させることができるようになります。
そのため、上記KBに記載のある通り、構成ファイルを作成してCLIで読み込ませることでオプション設定も含めて反映させることができるようになります。
手順:
# vi /scratch/ntpconfig.txt // ファイル名は何でもよい。デフォルトでは存在しない。
# cat /scratch/ntpconfig.txt // 以下の出力になるように編集する
server <ntp server ip or fqdn> iburst
tos maxdist 30
# esxcli system ntp set -f /scratch/ntpconfig.txt // CLIで設定を読み込ませる
# esxcli system ntp set -e 1 // ntpサービスを有効化する
# cat /etc/ntp.conf // iburst と tos maxdist 30 が反映されていることを確認
上記のようにファイルから設定を読ませれば、その後にGUIからNTP IP を変更や追加をしてもtos maxdist の設定は維持されます。しかしGUIからNTP設定を削除してしまうと、tos maxdist 30 の設定は消えてしまうので、もう一度ファイルから読ませる必要があります。
(補足)NTPサーバがWindwos OSの場合
WindowsサーバをNTPサーバとして構築している場合、デフォルトの設定では同期可能なNTPサーバとしてみなされない場合があります。
おそらく多くの場合はLocalClockDispersion の設定によるものと思われますので、この値が0になっているかを確認されることをお勧めいたします。
レジストリパス
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\
ntpq で以下のような出力になるとき、reachの列は以下のような意味にがある
(補足)ntpq -p のReachの意味について
ntpq で以下のような出力になるとき、reachの列は以下のような意味にがある
$ ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
+aaa.bbb.ccc.8 .XXXX. 1 u 94 1024 0 0 0 0
-aaa.bbb.ccc.0 .XXXX. 1 u 1020 1024 357 16.164 2.833 0.520
+aaa.bbb.ccc.12 .XXXX. 1 u 985 1024 1 185.135 -0.739 3.292
*aaa.bbb.ccc.4 .XXXX. 1 u 243 1024 377 34.682 0.590 0.944
reach列は最大377(8bit)の8進数表記であり、以下のように読み取る。
0 (8進数) = 00000000 (2進数)であり、NTPサーバとの過去8回の疎通ですべて失敗していることを意味する。
1 (8進数) = 00000001 (2進数)であり、NTPサーバとの過去8回の疎通のうち、最後の一回のみ成功していることを意味する
357 (8進数) = 11101111(2進数)であり、NTPサーバとの過去8回の疎通のうち、5回前の疎通のみ失敗したことがわかる
377 (8進数) = 11111111(2進数)であり、NTPサーバとの過去8回の疎通すべてで成功していることを意味する
関連ドキュメント
Dell EMC KB
VxRail: How to troubleshoot NTP issue in VxRail cluster | Dell US
VMware by Broadcom KB
vSphere ESXi 7.0 U3 and later versions NTP configuration steps loading a text file containing NTP configuration commands (broadcom.com)
NTPの仕組み
【図解】NTPプロトコルの概要と仕組み~誤差補正の計算,仕様,シーケンス~ | SEの道標 (nesuke.com)
NTPDのパラメタ
Miscellaneous Commands and Options
NTPの仕組み
【図解】NTPプロトコルの概要と仕組み~誤差補正の計算,仕様,シーケンス~ | SEの道標 (nesuke.com)
NTPDのパラメタ
Miscellaneous Commands and Options
NTPのメッセージ、flash code の詳細
コメント
コメントを投稿