web-dev-qa-db-ja.com

単一のNTP分離ネットワーク上のサーバー

分離されたネットワーク上に2台のLinuxマシン（AとB）があります。それらは時間同期されている必要があります。マシンAは断続的に電力が供給されており、信頼できるタイムソース（GPS）に接続されているため、時間を提供する必要があります。マシンBは、マシンAに電力が供給されている場合にのみ給電されますが、組み込みLinuxデバイスであり、その電力状態は頻繁に変化します。どちらのマシンも他のシステムにアクセスできません。それは閉じたネットワークです。

NTPは通常、複数のサーバーとの接続を想定しているので、これはNTPにとって非常に長い順序であることを理解しています。これをマシンBで適切に機能させるのに問題があります。マシンAはGPSは問題なく、マシンBはマシンAに到達でき、時間クエリも実行できますが、マシンAは信頼されていません（おそらくそれ自体で？）。マシンAが1時間稼働した後、これは突然変更され、マシンBは機能しました。 、マシンA（したがってマシンB）がダウンしたとき、マシンBは再び適切な時刻同期を見つけることができません。

ここにいくつかのntpdate情報があります。マシンAの階層が1の場合でも、最後に同じ出力で操作が失敗することに注意してください。

 10.10.10.1：サーバーが削除されました：階層が高すぎます
サーバー10.10.10.1、ポート123 
階層16、精度-19、飛躍11、信頼000 
 refid [10.10.10.1]、遅延0.02614、分散0.00000 
送信4、フィルター4 
参照時間：00000000.00000000 Thu、2月7日2036 6：28：16.000 
元のタイムスタンプ：d3a9bdc4 .27ebb350 2012年7月12日木曜日21：19：00.155 
タイムスタンプの送信：bc17c803.b42dfffe 2000年1月1日土曜日0：25：39.703 
フィルター遅延：0.02625 0.02614 0.02618 0.02625 
 0.00000 0.00000 0.00000 0.00000 
フィルターオフセット：39544160 39544160 39544160 39544160 
 0.000000 0.000000 0.000000 0.000000 
遅延0.02614、分散0.00000 
オフセット395441600.451568 
 
 1 Jan 00:25:39 ntpdate [677]：同期に適したサーバーが見つかりません

私の推測では、マシンAは時間を提供すること自体を信頼していません。 51分の稼働時間（以前に起こった可能性がありますが、私にはわかりません）とそのクロックがGPSに同期された後、マシンAが時間を正しく提供し始め、マシンBがそれを取得しました。私はこれが早く起こる必要があります。同様に、可能であれば数秒以内に。

以下の設定（および多くの待機）を使用すると、最終的には成功します。

マシンAntp.conf：

サーバー127.127.28.0は真のminpoll4を優先maxpoll4 
ファッジ127.127.28.0層1回10.420 refid GPS 

マシンBntp.conf：

サーバー10.10.10.1はtrue minpoll 4 maxpoll 4を優先します

マシンBでntpq -cピアが適切な時間の修正なしでピアリングされています

     ポーリングが遅延オフセットジッターに到達したときのリモートrefidst t 
 =================================== =========================================== 
 10.10。 10.1.STEP。 16 u 9 16 0 0.000 0.000 0.000

マシンB上のntp1-cピアで、適切な時間修正が行われました。

     ポーリングが遅延オフセットジッターに到達したときのリモートrefidst t 
 =================================== =========================================== 
 * 10.10 .10.1 SHM（0）2 u 7 16 17 0.669 2.597 1.808

それで、今問題は次のようになります：どうすればマシンAをすぐに自分自身に信頼させることができますか？

マシンBの前後のマシンAからの一部のデバッグ出力は、マシンAが使用するのに十分であると判断します。

前..

〜＃ntpq -c rv 
 associd = 0 status = c418 leap_alarm、sync_uhf_radio、1 event、no_sys_peer、
 version = "ntpd [email protected] Fri Feb 24 15:01:45 UTC 2012 （1） "、
 processor =" armv7l "、system =" Linux/2.6.35.14 "、leap = 11、stratum = 2、
 precision = -19、rootdelay = 0.000、rootdisp = 44.537、refid = SHM（0）、
 reftime = d3ab0053.43b44780金、2012年7月13日20：15：15.264、
 clock = d3ab0062.e7e03154金、2012年7月13日20：15：30.905 、peer = 34819、tc = 4、
 mintc = 3、offset = 0.000、frequency = 0.000、sys_jitter = 3.853、
 clk_jitter = 36.492、clk_wander = 0.000

後...

〜＃ntpq -c rv 
 associd = 0 status = 0415 leap_none、sync_uhf_radio、1 event、clock_sync、
 version = "ntpd [email protected] Fri Feb 24 15:01:45 UTC 2012 （1） "、
 processor =" armv7l "、system =" Linux/2.6.35.14 "、leap = 00、stratum = 2、
 precision = -19、rootdelay = 0.000、rootdisp = 41.278、refid = SHM（0）、
 reftime = d3ab0063.43b37856 2012年7月13日金曜日20：15：31.264、
 clock = d3ab006d.9ee53ec2 2012年7月13日金曜日20：15：41.620 、peer = 34819、tc = 4、
 mintc = 3、offset = 0.000、frequency = 43.896、sys_jitter = 0.762、
 clk_jitter = 36.953、clk_wander = 0.000
linuxtimentp
8
San Jacinto

NTPは正常に動作するはずです。起動時の高速同期のオプションのいくつかを見てください。システムBのburstおよびiburstオプションを確認します。GPSクロックソースのtrueオプションを確認します。

両方のシステムでバックアップタイムソースとしてハードウェアクロックを使用することを検討してください。より高い階層システムBを設定します。次のようなものが機能するはずです。

server  127.127.1.0
fudge   127.127.1.0 stratum 8

ntpq -c peersの出力を見て、信頼できるクロックソースがいつ得られるかを確認してください。通常、ntpは、信頼する前に、信頼できるタイムソースからの多数の応答を要求します。これは、各行の最初の文字で示されます。

NTPはより多くのソースを好みますが、1つの階層レベル内の奇数のタイムソースはうまく機能します。2つのサーバーとGPSクロックしかないので、ソースの優先度（階層）はGPS、サーバーAのクロック、サーバーBのクロック。それぞれの間の階層を3または4レベル増やすと、優先順位が尊重されます。

編集：サーバーAにbusybox NTP=サーバーがある場合、完全なntpサーバーパッケージをインストールすることは価値があるかもしれません。サーバーAで何が起こっているかを理解することは問題を解決するための長い道のりを行くはずです。サーバーBが信頼する前に、少なくとも1つの信頼できるタイムソースが必要です。ntpq -c peersが機能しない場合は、ntpdc peersを試すことができます。これらのコマンドはどちらも、他のホストにクエリを実行できます。Apeerstatslogも役立つ可能性があります。

サーバーBでは、文書化されているようにntpclientを使用して busybox ntp howto で何が起こっているかをログに記録します

サーバーが長時間ダウンしていない場合、クロックは正しい時刻にかなり近いはずです。 2つのシステムを同期する必要がある場合は、それで十分です。 GPSは、時間を実際の世界と同期させます。

'ntpd -q'は迅速に同期しますが、終了します（ntpdateの動作）。継続的に同期するには、終了オプションなしでntpdコマンドを続ける必要があります。

EDIT2：サーバーをチェックしたところ、サーバーの1つが1秒ずれていることがわかりました。これを修正しながら、私は設定で遊んだ。 iburstは非常に迅速にサーバーを信頼します。 trueは、他に複数の信頼できるソースがない場合に、クロックドライバーが信頼できることを確認しました。時計は、ローカルで信頼され、リモートで信頼できるようになるまでに1分強かかりました。

テストするときは、同期されたらntpdプロセスを再開し、設定の動作速度をテストできるはずです。上記の場合、サーバーBの同期速度をテストするために、サーバーBを再起動する必要がある場合があります。 ntpdの変更を監視するとき、次のような行を使用します。

while ntpq -c peers localhost; do sleep 10; done

ホスト名とスリープ時間は必要に応じて調整されます。場合によっては、ループ内で2つ以上のntpqコマンドラインをチェーンします。そうするときは、echoやdateコマンドを使用して、データのセットがどこで変更されたかを示します。

8
BillThor