Ntpd 4.2.6p5を実行し、顧客から提供された複数のNTPサーバーを使用するように構成された(pool.ntp.orgへのアクセスなし))分離ネットワーク上にUbuntu 14.04サーバーを展開します。ダムターミナルクライアントデバイスは、古いバージョンのBusyBox(1.00-rc2)と ntpclient 201 をLarry Doolittleから実行します。
このセットアップは何年もの間うまく機能してきましたが、最近、私たちは新しい顧客の障害にぶつかりました。 Linuxサーバーでntpdate-debian
が関係している限り、社内で5つの社内アドレスNTPサーバーアドレスが適切に機能しているように見えます。ただし、BusyBox側ではntpclient
は「分散が高すぎます」と文句を言います。デバッグ出力から、ntpclient
はNTPサーバーから "1217163.1"を取得しますが、サポートする最大値は絶対値です(65536)。
$ /usr/sbin/ntpclient -s -i 15 -h 10.17.162.250 -d
Configuration:
-c probe_count 1
-d (debug) 1
-g goodness 0
-h hostname 10.17.162.250
-i interval 15
-l live 0
-p local_port 0
-q min_delay 800.000000
-s set_clock 1
-x cross_check 1
Listening...
Sending ...
recvfrom
packet of length 48 received
Source: INET Port 123 Host 10.17.162.250
LI=0 VN=3 Mode=4 Stratum=4 Poll=4 Precision=-20
Delay=60745.2 Dispersion=1346801.8 Refid=10.31.10.21
Reference 3668859928.942079
(sent) 3668859928.708371
Originate 3668859928.708371
Receive 3668859928.963271
Transmit 3668859928.963369
Our recv 3668859928.708371
Total elapsed: 0.00
Server stall: 93.09
Slop: -93.09
Skew: 255443.94
Frequency: 0
day second elapsed stall skew dispersion freq
42463 56728.708 rejected packet: abs(DISP)>65536
これらはすべて同じLAN上のデバイスなので、率直に言って私は戸惑いを覚えます。驚いても。
これは、Ubuntu 14.04サーバーからのntpq -pn
出力です。
user@Host:~$ ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.1.0 .LOCL. 10 l 1025 64 0 0.000 0.000 0.000
10.17.162.249 10.17.6.10 5 u 23 1024 37 0.865 1381.07 697.260
10.31.10.22 .LOCL. 1 u 1044 1024 17 29.586 -838.06 397.342
10.17.6.10 10.31.10.21 4 u 1065 1024 17 0.366 105.245 402.999
*10.31.10.21 132.246.11.238 3 u 5 1024 37 29.418 794.292 616.796
10.17.6.11 10.31.10.21 4 u 1038 1024 17 0.408 120.030 381.058
私の質問は:
ntp.conf
を使用して、Ubuntuサーバー側に障害があるのでしょうか?本当に特別なことは何もありません。ここでの回答には混乱が生じています。まず、ntpclient
は、少なくとも-s
モードでは、完全なNTPクライアントとして機能していません。送信と受信のみを行っています 1パケットなので、「最後に受信した8パケット」はありません。実際にはそれ自体のばらつきを推定しているわけではありません。
代わりに、出力する値は、サーバーから返されたパケットの "ルート分散"(rootdisp)と呼ばれる値です。これは、そのサーバーと正しい時間の間のエラー/分散の総量の推定値です。これを計算する方法は非常に簡単です。すべてのNTPサーバーは、外部クロック(たとえば、ラジオまたはGPSレシーバー)または別のNTPサーバーから時刻を取得します。サーバーが外部クロックから時刻を取得する場合、そのルート分散はそのクロックの推定最大誤差です。別のNTPサーバーから時間を取得する場合、そのルート分散は、サーバーのルート分散plusであり、ネットワークリンクによって分散が追加されますそれらの間の。
ここでの混乱の1つのポイントは、ntpqとchronyは分散とルート分散を秒単位で表示しますが、これは人々が慣れていることですが、ntpclientはそれをmicroseconds。とにかく、1217163の値はまだかなり高いです。適切なNTPサーバーは、数ミリ秒以内の時間を認識しています。数十ミリ秒または数百ミリ秒以内に悪いもの。あなたは、その時間は+/- 1.2秒以内にしか信頼できないと言っています。
実際にntpclientをこのサーバーに同期させるには、-x 0
または-t
オプション(ntpclientのバージョンによって異なります)を渡して、NTPの正常性チェックを無効にします。おおよそ正確な時間(数秒以内)のみが必要な場合は、それで十分です。ただし、ntpclientは、このような不良サーバーとの同期を拒否することについてはかなり合理的です。 ubuntuマシンのntpq
出力は、サーバーの遅延が小さいにもかかわらず、すべてのサーバーで数百ミリ秒のジッターを示しています。これは、非常に信頼性の低いネットワークか、陰謀allサーバーの不規則な時間、またはサーバー自体の基本的な計時の問題を提供します。
また、サーバー10.31.10.22がLOCL
(規律のないローカルクロック)のrefidをアドバタイズしているが、ストラタムが1であることも関係しています。通常、ローカルクロックは10のストラタムにファッジされ、次のようにのみ使用されます。群れがバラバラにならないようにする最後の手段である同期ソース。 10.31.10.22が正しく構成されておらず、ネットワークの残りの部分に悪い時間を提供している、またはNTPの制御外のプログラムによって適切な時間に規律されている。この場合、誤った構成は、単にLOCL
refidをアドバタイズしているということです。 ;たとえば、次のようにオーバーライドする必要があります。 GPS
または時間を提供するものは何でも。
「分散とは」の部分的な答えは次のとおりです。
典型的なNTP往復:
client | | server
t1 |------->| t2
t3 |<-------| t4
これにより、次の式を使用して、オフセット(クライアントとサーバー間の時間差)と遅延(基本的にはネットワーク移動時間)の2つの値が得られます。
offset= ((t4 - t3) + (t1 - t2)) / 2
delay = (t4 - t1) - (t3 - t2)
クライアントは、受信した最後の8つのパケットから現在のオフセットを選択し、遅延が最も小さいパケットを選択します。
同じ8パケットを使用して分散を計算するために、最後のステップで選択したオフセットに対してこれらの8つのオフセットの差の加重平均を実行します。ここで、遅延は重み係数として使用され、小さい遅延への重み。これは値の「広がり」の尺度であり、特に複数から選択できる場合は、タイムサーバーの品質を計算するために使用されます。
分散とスキューは非常に大きく、ローカルクロックからそのピアへの非常に大きなオフセットがあります。オフセットをローカルdate
と比較し、クロックを手動で設定する必要があります。
Ntpdを実行し、すべてのピアを使用してホストからntpq -p
を表示します。それはより良いものを選択します。
このシスコのドキュメント によると、秒単位で報告されるdispersionは、これまでに観測された最大クロック時間差です。ローカルクロックとサーバークロック」。完全に壊れていないntpサーバーでは、高い分散が発生することはありません。唯一の実行可能なシナリオは、クライアントがntpを初期化し、これまでのところ、ローカルクロックしか使用できない場合です。そして、それでも、あなたが報告するのと同じくらい高い分散は、2週間以上ずれている時計に対応します。
BIOSでクロックを調整するか、日付を調整することによって、またはntpdate
クライアントでntpd
を開始する前に1回。