検索
連載

最終回 NTP時刻同期サービスのトラブルシューティングWindowsネットワーク時刻同期の基礎とノウハウ(改訂版)(1/3 ページ)

Windows環境で時刻同期機能を提供するWindows Timeサービスのトラブルシューティングを行うには、デバッグ・ログやイベント・ログを調査するとよい。読み取り専用ドメイン・コントローラにおける時刻同期処理の挙動と設定方法も解説する。

PC用表示 関連情報
Share
Tweet
LINE
Hatena
Windowsネットワーク時刻同期の基礎とノウハウ(改訂版)
Windows Server Insider


「Windowsネットワーク時刻同期の基礎とノウハウ(改訂版)」のインデックス

連載目次

本連載では、主にWindows Vista/Windows 7/Windows Server 2008/Windows Server 2008 R2を対象としています。Windows XPやWindows 2000 Server/Windows Server 2003については、以下の旧記事を参照してください。


 前回から時間が空いてしまったが、最終回となる今回は、Windows OSのNTP時刻同期にまつわるトラブルシューティングの情報を解説しよう。

 NTP時刻同期は、NTPクライアントが正常な設定であり、NTPサーバが適切な状態(有効な時刻を保持している状態)であれば、最適化されたタイミングで自動的に同期を繰り返すので、システム管理者は特に注意を払う必要はない。しかし、NTPクライアント(Windows Time)の設定が誤っていたり、参照先NTPサーバが適切な状態でない場合(有効な時刻を保持していない場合)、時刻同期は失敗する。トラブルシュートを行う場合、ネットワークの問題なのか、NTPサーバあるいはクライアントの問題なのか、切り分けを行わなければならない。

 まずは、「Time-Service」サービスのイベント・ログによるトラブルシューティングを見ていく。

イベントID 37/イベントID 35

 Windows Timeサービスによる時刻同期の状況は、イベント・ビューアの「システム ログ」に、「Time-Service」イベントとして記録される。Windows Timeサービスが起動し、時刻同期を試行した結果は、成功した場合も失敗した場合も、Time-Serviceイベントに記録される。時刻同期に成功した場合、イベントID 37およびイベントID 35が記録される。イベントID 37は「参照先NTPサーバから時刻情報(時刻サンプル)を受け取った」ことを意味し、イベントID 35は「(受け取った)時刻サンプルを使って実際にシステム時刻を変更した」ことを意味する。

イベントID 37のログの例
イベントID 37のログの例
これは、参照先NTPサーバから時刻情報(時刻サンプル)を受け取ったことを表すイベント。

イベントID 35のログの例
イベントID 35のログの例
これは、(受け取った)時刻サンプルを使って実際にシステム時刻を変更したことを表すイベント。

 注意してほしいのは、イベントID 37が記録されただけでは「時刻同期が行われた」ということにならない点である。イベントID 37が記録されているのに、イベントID 35が記録されていない場合、受け取った時刻サンプルが有効でない、といった理由でWindows Timeサービスが同期を行わなかったことが考えられる。同期に失敗した場合はID 35とは異なるIDのイベントが記録されるため、実際にはこのイベントの内容で判断することになる。

イベントID 47

 イベントID 47は、「NTP問い合わせに対する応答がなかった」といった際に記録される。具体的な理由として、存在しないコンピュータのIPアドレスやNTPサーバでないコンピュータにアクセスしようとした場合が対象となる。またWindows Server 2008 R2がNTPサーバの場合、「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer\Enable」レジストリ値(NTPサーバの有効化)が設定されていなかったり、WindowsファイアウォールでUDPのポート123番(入力/出力方向とも)が解放されていない、という理由が考えられる。

イベントID 47のログの例
イベントID 47のログの例
これは、NTP問い合わせに対する応答がなかったことを表すイベント。

イベントID 134

 イベントID 134は、「DNS名前解決が原因でアクセス先が指定できない」といった際に記録される。具体的な理由としては、Windows Server 2008 R2で「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NTPServer」レジストリ値(NTPサーバ名の指定)の値が適切でなかったり、ネットワーク接続のTCP/IPプロパティにある「優先DNSサーバ」のIPアドレスが誤っている、などでDNS名前解決が失敗しているといったことが考えられる。

イベントID 134のログの例
イベントID 134のログの例
これは、DNS名前解決が原因でアクセス先が指定できなかったことを表すイベント。

イベントID 36

 イベント ID 36は、「長時間時刻同期を行うことができずに時刻が不正確な状態になっている」といった際に記録される。RFC 1305では、有効(正確)な状態の時刻サンプルは「86,400秒(=1日)」の間に同期を行っていなければならず、それを超えた場合長時間同期を行っていないものとして、不正確なサンプルとみなされる。

 Windowsの時刻同期は、ワークグループ環境の場合、「604,800秒(=7日)」ごとにtime.windows.comというNTPサーバに同期を行うよう設定されている。おそらくは「必要以上にネットワークを利用しない」と「ある程度正確な時刻に合わせる」を両立しようとした実装であると思われ、NTPクライアントとしての実用上に大きな問題はない。

イベントID 36のログの例
イベントID 36のログの例
これは、長時間時刻同期を行うことができずに時刻が不正確な状態になっていることを表すイベント。

 しかし、比較的正確な時刻情報(例えば0.5秒以内の誤差)を必要とする場合や、NTPサーバとしてWindowsを利用したい場合、86400秒以内に同期を行うよう、設定を変更しなければならない。それにはNTPサーバの動作モードを適切に選択する必要がある。

NTPサーバの動作モードの選択について

 NTPサーバの動作モードを選択するには、「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NTPServer」の値の「第 2パラメータ」を、次の(1)か(2)のいずれかに設定する。どちらを選択してもNTPサーバとして動作はするが、前者であれば時刻同期の間隔を明示的に制御できるメリットがあり、後者であればRFC 1305に準拠した業界標準の時刻同期の動作が行われるメリットがある。Linuxなどの非Windowsマシンの時刻同期を考慮する場合は、後者を選択したほうがいいだろう。また、非Windowsマシンの外部NTPサーバと時刻同期する場合、Clientモードを選択したほうがよい。Symmetric Activeモードで同期を行った場合、同期先NTPサーバから(peerモードに沿った)相互同期を行う要求を拒否され、時刻同期が失敗することがあるためである。

(1)一定間隔での時刻同期が必要な場合、0x9(Clientモード)または0x1(Symmetric Activeモード)を選択する。
(2)RFC 1305に準拠した時刻同期が必要な場合は、0x8(Clientモード)もしくは、0x4かパラメータなし(Symmetric Activeモード)を選択する。

NTPサーバの動作モードの設定(1)
NTPサーバの動作モードの設定(1)
一定間隔での時刻同期が必要な場合の設定。
  (1)NtpServerの第1パラメータにはNTPサーバのIPアドレス、第2パラメータには、0x09(Clientモード)か0x1(Symmetric Activeモード)を設定する。

NTPサーバの動作モードの設定(2)
NTPサーバの動作モードの設定(2)
RFC 1305に準拠した業界標準の時刻同期が必要な場合の設定。
  (1)NtpServerの第1パラメータにはNTPサーバのIPアドレス、第2パラメータには0x8(Clientモード)もしくは、0x4かパラメータなし(Symmetric Activeモード)を設定する。

●時刻同期の間隔をレジストリ値で調整する

 前項の(1)を選択した場合と(2)を選択した場合で確認するレジストリ値が異なるので注意する。

 時刻同期の間隔については、16秒以上の間隔(一般的なNTPソフトウェアの最短同期間隔)で、自分の時刻の同期精度と相手先NTPサーバへの負荷を考えながら決定する必要がある。例えばNICTではNTPサーバへの負荷を考慮して「1時間に20回(3分に1回)」を目途にしているが(NICTの公開NTPサーバに関するFAQ「ポーリング間隔に制限はありますか?」参照)、一定間隔で3分ごとに同期するより、最初は1分間隔で同期して、時刻が安定してきたら同期間隔を(自動的に)延ばす方法が、正確な時刻の取得と負荷の軽減を両立できる(RFC1305の同期間隔の挙動はこのような背景で定められていると思われる)。一般的なNTPソフトウェア(デーモン・タイプのもの)では、64〜1024秒の可変間隔で同期間隔が設定されたものが多いので、筆者もこの設定を個人的にはお勧めする。

(1)一定間隔での時刻同期が必要な場合、「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient\SpecialPollInterval」レジストリ値を「秒数」で設定
(2)RFC 1305に準拠した時刻同期が必要な場合、「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\MinPollInterval」および「MaxPollInterval」レジストリ値を「2を基底とした対数」で設定。例えば6を設定すると2の6乗=64秒、10を設定すると2の10乗=1024秒を表すことになる。

一定間隔での時刻同期が必要な場合のレジストリ設定
一定間隔での時刻同期が必要な場合のレジストリ設定
一定間隔での時刻同期が必要な場合は、SpecialPollIntervalのレジストリ値を設定する。
  (1)時刻同期間隔(秒数)。

RFC 1305に準拠した時刻同期が必要な場合のレジストリ設定
RFC 1305に準拠した時刻同期が必要な場合のレジストリ設定
RFC 1305に準拠した時刻同期が必要な場合は、MinPollIntervalとMaxPollIntervalのレジストリ値を設定する。
  (1)最小ポーリング間隔。「2を基底とした対数」で(秒数)を指定する。ここでは0x0a=10(10進数)なので2の10乗=1024秒が設定されている。
  (2)最大ポーリング間隔。「2を基底とした対数」で(秒数)を指定する。ここでは0x06=6(10進数)なので2の6乗=64秒が設定されている。

●Windowsファイアウォールの設定

 NTPサーバとして利用する場合は、まず「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer\Enable」レジストリ値を1に設定する。

NTPサーバの有効化のためレジストリ設定
NTPサーバの有効化のためレジストリ設定
NTPサーバを有効にするには、Enableのレジストリ値を1に設定する。
  (1)これを1に設定する。

 次に[セキュリティが強化されたWindowsファイアウォール]管理ツールで、「受信の規則」に「プロトコルの種類=UDP」「ローカル ポート=123」「リモート ポート=123」を許可した新しい規則を作成して、接続可能な状態にする。

NTPサーバの有効化のためWindowsファイアウォール設定
NTPサーバの有効化のためWindowsファイアウォール設定
WindowsファイアウォールでNTPサーバに対する新しい受信規則を作成し、クライアントからの接続を許可しておく。許可する規則の内容は、プロトコルの種類=UDP、ポート番号=123とする。
  (1)UDPポートを選択する。
  (2)「123」を設定する。
  (3)「123」を設定する

イベントID 50

 イベント ID 50は、「一定間隔(900秒)の間にNTPサーバとの時刻ずれが縮まらない」という場合に記録される。この状況は、原則的には参照先NTPサーバ側でslewモード(時間のずれを少しずつ減らしながら同期させるモード)が発生し、時刻ずれが続いた場合に起こることがある。UNIXやLinuxのntpdといった一般的なNTPソフトウェアでは、NTPクライアントが同期のたびに時刻ずれを感知しないように、ごく小さい範囲でslewモードの補正をしているため(1秒あたり0.5ミリ秒の補正)、こういったことは生じにくい。一方Windows ServerがNTPサーバだった場合、1秒あたりの補正値はオフセットに依存するため(大きく時刻がずれているうちは補正値を大きくとり、正しい時刻に近づくと補正値が小さくなる)、このような問題が起こることがある。

イベントID 50のログの例
イベントID 50のログの例
これは、一定間隔(900秒)の間にNTPサーバとの時刻ずれが縮まらないということを表すイベント。

 Windows Timeサービスにおける、この補正値の仕様は非公開であるため、上記が原因の場合は、「最初から正しい時刻に手動で合わせてから、Windows Timeサービスを動作させる」以外の解決策はない。ただVMwareやHyper-Vといった仮想環境のゲスト・マシンで発生した場合、仮想環境特有の理由による場合が少なくない。

 ハイパーバイザ型のゲスト・マシンでは、Clock Tickと呼ばれるOS内部の時刻カウンタがソフトウェアでエミュレートされているが、高負荷がかかるとこれが正常に(時間通りに)カウントされず、結果的に時刻が遅れていく傾向がある*1。これを補正するため、ゲスト仮想マシンで対応ドライバ・ソフトウェア(Hyper-Vの場合は「Hyper-V統合サービス」)をインストールすると時刻に関する修正が1分ごとに行われるようになる。

*1Active Directoryドメイン・コントローラの仮想化はNG?」の「そもそも、仮想化するとなぜ時間がずれてしまうのか?」参照。


 この機能を無効にした場合、発生した時刻ずれがイベントID 50の条件に一致すると、Windows Timeは時刻ずれの原因が自分自身なのか、参照先NTPサーバなのかを判定できないため、このイベントが記録されることがある。

 仮想環境のゲスト・マシンでこの状況が発生した場合、根本的に原因を解消する方法はないので、時刻同期の条件を最適化するといった対処が必要になる。具体的には次のどちらかを選択することになるだろう。

(A)自分自身しか存在しない、または1台のホスト・マシンでホストされた仮想環境のみであれば、「統合サービス」などの時刻同期サービスを有効にする。単純な環境であれば、この方法が最も簡単で、手間や時間がかからない。

(B)ほかの物理マシンや、複数台のホスト・マシンでホストされた仮想環境であれば、「統合サービス」の時刻同期サービスは無効に設定したうえ、各ゲスト・マシンのWinodws Timeサービスが時刻同期の階層を構成するよう設定する。複数の物理マシン間で時刻同期させるとそれぞれが影響しあって動作を邪魔する可能性があるため、統合サービスの同期性は1台のホスト・マシン上でのみ有効にするのがよい。

 あわせて、各ゲスト・マシンの時刻同期間隔は通常より短く設定し、特に時刻同期の最上位となるゲスト・マシンについては、物理マシンとなるNTPサーバにさらに短い間隔で時刻同期を行うよう設定する。Clock Tickの遅れを補正するためには、短い間隔で時刻同期を行う以外に方法はないこと、ゲスト・マシン間での時刻同期は不正確さが伴うため、少なくとも最上位のゲスト・マシンは、正確な時刻を担保できる物理マシンから同期を行う必要がある。

 仮想環境の状況に依存するが、1分以内の時刻同期間隔を保つ必要があるケースもあり、(NICTなどの)公共の外部NTPサーバから直接同期するのではなく、自社内に物理マシンによる基準NTPサーバを用意して、これをゲスト・マシンの時刻同期に利用した方がよいだろう。

イベントID 12

 イベント ID 12は、「PDCエミュレータ役割のドメイン・コントローラが外部から時刻同期を行うよう設定されていない」といった際に記録される。PDCエミュレータ役割のドメイン・コントローラは、時刻同期の最上位のNTPサーバとして、外部のNTPサーバと同期するか、自分自身をStratum 1のNTPサーバとして設定しないと、ほかのサーバやクライアントが適切に時刻同期できない。

イベントID 12のログの例
イベントID 12のログの例
これは、PDCエミュレータ役割のドメイン・コントローラが外部から時刻同期を行うように設定されていない場合に記録されるイベント。

 ドメイン・コントローラの時刻同期設定については、第2回の「Active Directoryおよびワークグループ環境での時刻同期 - 2.Active Directory環境で、PDCエミュレータを権威ある時刻サーバに設定する」を参照されたい。


Copyright© Digital Advantage Corp. All Rights Reserved.

       | 次のページへ
ページトップに戻る