none
時刻同期について RRS feed

 > 

  • 質問

  • Question
    サインインして投票
    0
    サインインして投票

    お世話になります。

    ご相談したい事があり、色々調べてみたのですが

    解決しなかった為こちらで質問させてもらいました。

    時刻同期に関してなのですが

    A,BというNTPサーバに対して、D,E,F,Gというクライアントから

    一日に一度同期を行うように設定しています。

    設定 SpecialPollInterval=86400

    しかしクライアントE,Gだけが毎日数秒づつ時刻が遅れており

    現在8分程度遅れた状態になってしまいました。

    クライアントD,Fに関しては、正確な時刻の状態なのですが

    原因が全くわかりません。(D,Fが正確な日時で同期を行っている為NTPサーバが悪いとも思えません)

    ちなみに、E,Gのイベントを見た感じですと、Kernel General 1の表記も

    イベント上に存在し、毎日時刻同期のタイミングで同期を行い

    システムクロックを更新している様に見えます。

    またクライアントEにて、status,peerを取得したのですが

    statusとpeerで最終正常同期時刻に差異があります。

    statusとpeerの最終同期時刻とはそれぞれどこを参照しているのでしょうか。

    取得したログより何点かピックアップして記載させていただきます。

    w32tm /query /status /verbose

    Leap Indicator: 3

    Stratum: 5

    Precision: -6

    Root Delay: 0.126144s

    Root Dispersion: 8.2988158s

    Last Successfull Sync Time: 6/9/2014 9:43:24 PM

    Poll Interval: 10

    Phase Offset: 0.0309885s

    ClockRate: 0.0156000s

    State Machine: 2( Sync )

    Time Source Flags : 0

    Server Role: 0

    Last Sync Error : 2

    Time since last Good Sync Time :67233.2180000

    w32tm /query /peers /verbose

    Peer  :XXXXXXXX(NTP1,2共に内容は等しいのでまとめます)

    State: Active

    Time Remaining: 21980.9219999s

    Mode: 3

    Stratum: 4

    PeerPoll Interval : 10

    HostPoll Intervall: 10

    Last Successful Sync Time: 6/9/2014 9:50:15

    Last SyncError: 0x00000000(Succeeded)

    LastSyncErrorMsgID: 0x00000000(Succeeded)

    Resolve Attempts: 0

    ValidDataCounter: 8

    Reachability: 255

    なんらかのアドバイスを頂ければと考えております。



    • 編集済み OgaSei 2014年6月12日 1:26
    2014年6月12日 0:07
    |

回答

  • Question
    サインインして投票
    0
    サインインして投票

    チャブーンです。

    以下のコマンド結果から、ある程度の状況はわかるかもしれません。

    w32tm /query /status /verbose
    Leap Indicator: 3
    Stratum: 5
    Precision: -6
    Root Delay: 0.126144s
    Root Dispersion: 8.2988158s

    Leap Indicatorが0ではないので、実質上同期エラーが発生しています。で、理由ですがRoot Dispersionの数値が大きすぎ、サーバの時刻精度が不正確とみなされているためですが、状況から、クライアント側の挙動が不正確なため問題が起こっているのだと思います。平たくいうと、クライアント側の時刻が内部的にずれてしまっている、ということになります。

    まず、次の点を確認されるといいと思います。

    • クライアントE,Gは仮想マシン(ゲストマシン)ですか？そうであれば、時刻がずれるのは仕様上仕方がない部分があります。
    • クライアントE,G上のボタン電池は消耗していませんか？
    • クライアントE,G上で他の時刻同期クライアントツールが動作している、ということはありませんか？
    • クライアントE,G上のCPU利用率が恒常的に高い、ということはありませんか？

    どれも当てはまらない、ということでしたら、実際の挙動を「デバッグ」するしかありません。w32timeのデバッグログを採り、解析します。デバッグログの取り方については、したのページを参考になさってください。

    http://support.microsoft.com/kb/816043/ja

    • 回答の候補に設定 佐伯玲 2014年6月30日 2:04
    • 回答としてマーク OgaSei 2014年7月1日 2:13
    2014年6月27日 2:34
    |
    モデレータ

すべての返信

  • Question
    サインインして投票
    0
    サインインして投票

    OgaSei さま

    >statusとpeerの最終同期時刻とはそれぞれどこを参照しているのでしょうか。
    　⇒statusは、NTPクライアント側(ローカル側)の同期状態、peersは参照先NTPサーバーの同期状態となります。

    E,Gだけが徐々に遅延していくということですが、D,Fとのw32tmサービスのスタートアップ設定に差異はみられないでしょうか。
    (イベントログで同期が確認できているようなのであてはまらないかもしれませんが。。)

    http://social.technet.microsoft.com/Forums/ja-JP/2b6acffb-5321-498a-a75e-7c7f9a4ce775/windows7?forum=w7itprogeneralja

    よろしくお願いいたします。

    • 回答の候補に設定 佐伯玲 2014年6月30日 2:04
    2014年6月27日 1:58
    |
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーンです。

    以下のコマンド結果から、ある程度の状況はわかるかもしれません。

    w32tm /query /status /verbose
    Leap Indicator: 3
    Stratum: 5
    Precision: -6
    Root Delay: 0.126144s
    Root Dispersion: 8.2988158s

    Leap Indicatorが0ではないので、実質上同期エラーが発生しています。で、理由ですがRoot Dispersionの数値が大きすぎ、サーバの時刻精度が不正確とみなされているためですが、状況から、クライアント側の挙動が不正確なため問題が起こっているのだと思います。平たくいうと、クライアント側の時刻が内部的にずれてしまっている、ということになります。

    まず、次の点を確認されるといいと思います。

    • クライアントE,Gは仮想マシン(ゲストマシン)ですか？そうであれば、時刻がずれるのは仕様上仕方がない部分があります。
    • クライアントE,G上のボタン電池は消耗していませんか？
    • クライアントE,G上で他の時刻同期クライアントツールが動作している、ということはありませんか？
    • クライアントE,G上のCPU利用率が恒常的に高い、ということはありませんか？

    どれも当てはまらない、ということでしたら、実際の挙動を「デバッグ」するしかありません。w32timeのデバッグログを採り、解析します。デバッグログの取り方については、したのページを参考になさってください。

    http://support.microsoft.com/kb/816043/ja

    • 回答の候補に設定 佐伯玲 2014年6月30日 2:04
    • 回答としてマーク OgaSei 2014年7月1日 2:13
    2014年6月27日 2:34
    |
    モデレータ
  • Question
    サインインして投票
    0
    サインインして投票

    FUGUKUJIRA様

    返答ありがとうございます。

    w32tmサービスのスタートアップの設定に関しては、

    起動時にあるトリガーにかかりサービスが起動しない件がある為全て自動（遅延）に設定しています。

    今該当のE,Gだけ再起動して様子見しています。


    • 編集済み OgaSei 2014年6月30日 4:12
    2014年6月30日 2:13
    |
  • Question
    サインインして投票
    0
    サインインして投票

    チャーブン様

    返答ありがとうございます。

    最終正常同期時刻や、Windows のイベント上にも時刻同期の旨があるのに

    実際には同期できていないなんて事がありえるんですね。勉強になります。

    ちなみにご指摘いただいた点の確認を行いました。

    • クライアントE,Gは仮想マシン(ゲストマシン)ですか？そうであれば、時刻がずれるのは仕様上仕方がない部分があります。

    　　　＞仮想マシンではありません。全て実サーバです。

    • クライアントE,G上のボタン電池は消耗していませんか？

    　　　＞電池消耗かはわかりませが、HW上問題があるようなイベントはございません。

    　　　　なんらかの調査方法があるかもしれませんので確認します。

    • クライアントE,G上で他の時刻同期クライアントツールが動作している、ということはありませんか？

    　　　＞時刻同期のクライアントツールは動作しておりません。

    • クライアントE,G上のCPU利用率が恒常的に高い、ということはありませんか？

    　　　＞CPU使用率は恒常的に高いということはございませんが、クライアントE,Gは

    　　　データベースサーバとして使用している為、恒常的にメモリ使用率は高い状態です。（常に90%前後維持）

    上記回答にも記載しましたが、現在クライアントE,Gに関しましては機会があったため

    OSを再起動し、BIOSで時刻調整した上で運用しております。

    現在一週間ほどたっており、また誤差がでないか様子見しております。

    2014年6月30日 4:11
    |
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーン様

    OgaSeiです。

    再起動の作業を実施した事で、クライアントE,GのうちのEに関しては

    Leap indicatorの値も0となり一週間たった今も時刻に誤差なく動いている様に見えます。

    しかし、Gに関しましては改善が見られませんでした。

    日々、同期を行わず徐々に時刻が遅れている状態です。

    レジストリ値を他の正常なサーバとも比較したのですが、おかしい箇所はなかったため

    要員は別にあり、ログレベルをデバッグにして様子を見るしかないと判断しました。

    今後タイミングをみて、デバッグログを出力するようにしたいと考えております。

    参考までにお伺いしたのですが。leap indicatorが３になる場合に

    改善させる有効な手段などご存じではないでしょうか？

    何度がOS再起動orW32time再起動で改善する可能性もあると思っております。

    （根本的な解決にはなりませんが）

    2014年7月2日 2:39
    |