web-dev-qa-db-ja.com

NTP分散とは何ですか?どのように制御しますか?

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

私の質問は:

  1. 分散とは何で、その値を変更できるものは何ですか?
  2. NTPサーバーから詳細を取得するためにどのようなコマンドを実行できますか?
  3. 不適切なntp.confを使用して、Ubuntuサーバー側に障害があるのでしょうか?本当に特別なことは何もありません。
  4. この場合、chronyに切り替えると何かが変わりますか?
21
Jeff

ここでの回答には混乱が生じています。まず、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または時間を提供するものは何でも。

24
hobbs

「分散とは」の部分的な答えは次のとおりです。

典型的なNTP往復:

client |        | server
    t1 |------->| t2
    t3 |<-------| t4

これにより、次の式を使用して、オフセット(クライアントとサーバー間の時間差)と遅延(基本的にはネットワーク移動時間)の2つの値が得られます。

offset= ((t4 - t3) + (t1 - t2)) / 2
delay = (t4 - t1) - (t3 - t2)

クライアントは、受信した最後の8つのパケットから現在のオフセットを選択し、遅延が最も小さいパケットを選択します。

同じ8パケットを使用して分散を計算するために、最後のステップで選択したオフセットに対してこれらの8つのオフセットの差の加重平均を実行します。ここで、遅延は重み係数として使用され、小さい遅延への重み。これは値の「広がり」の尺度であり、特に複数から選択できる場合は、タイムサーバーの品質を計算するために使用されます。

12
Sven

分散とスキューは非常に大きく、ローカルクロックからそのピアへの非常に大きなオフセットがあります。オフセットをローカルdateと比較し、クロックを手動で設定する必要があります。

Ntpdを実行し、すべてのピアを使用してホストからntpq -pを表示します。それはより良いものを選択します。

7
John Mahowald

このシスコのドキュメント によると、秒単位で報告されるdispersionは、これまでに観測された最大クロック時間差です。ローカルクロックとサーバークロック」。完全に壊れていないntpサーバーでは、高い分散が発生することはありません。唯一の実行可能なシナリオは、クライアントがntpを初期化し、これまでのところ、ローカルクロックしか使用できない場合です。そして、それでも、あなたが報告するのと同じくらい高い分散は、2週間以上ずれている時計に対応します。

BIOSでクロックを調整するか、日付を調整することによって、またはntpdateクライアントでntpdを開始する前に1回。

5