Windows Server 2016 の時間精度の向上

  • [アーティクル]

Windows Server 2016 では、協定世界時 (UTC) と同期させるために時刻の修正とローカル クロックの補正に使用されるアルゴリズムが強化されました。 Network Time Protocol (NTP) では、クライアントの要求および応答とサーバーの要求および応答のタイムスタンプに基づく 4 つの値を使用して、時刻補正が計算されます。 しかし、ネットワークにはノイズがあるため、ネットワークの輻輳やネットワーク待機時間に影響するその他の要因が原因で、NTP からのデータが急増する可能性があります。 Windows Server 2016 のアルゴリズムでは、さまざまな手法を使用してこのノイズが平均化されます。これにより、安定した正確な時計が実現されます。 正確な時刻を得るために使用されるソースも、強化された API を参照するため、より良いソリューションが得られます。 これらの機能強化により、ドメイン全体で UTC を基準に 1 ミリ秒の精度を実現することが可能です。

Hyper-V

Windows Server 2016 では、Hyper-V TimeSync サービスが強化されました。 この改善には、VM の開始時や 仮想マシン (VM) の復元時の初期時刻の精度の向上と割り込み待ち時間の修正が含まれ、Windows Time サービス (W32time) に与えられるサンプルに利用されます。 この機能強化により、75% の負荷のあるマシンでも、ホストに対して 50 マイクロ秒の二乗平均平方根 (分散を示します) で 10 マイクロ秒以内の精度を維持できます。 詳細については、Hyper-V のアーキテクチャに関するページをご覧ください。

Note

負荷は、prime95 のベンチマークを使用し、均衡プロファイルを使用して作成されました。

さらに、ホストからゲストに報告される Stratum レベルがより透過的になっています。 以前は、ホストからは、その精度に関係なく Stratum 2 が固定で提示されていました。 Windows Server 2016 に追加された変更によって、ホストからはそのホストの Stratum よりも 1 大きい Stratum が報告されるようになるため、仮想ゲストでより正確な時刻を実現できます。 ホスト Stratum は、W32Time によって、そのソース タイムに基づく通常の方法で決定されます。 ドメインに参加している Windows Server 2016 のゲストは、ホストを既定値とするのではなく、最も正確な時刻を利用できます。 この理由により、Windows Server 2012 R2 以前のドメインに参加しているマシンに対して [Hyper-V タイム プロバイダー] 設定を手動で無効にすることが推奨されていました。

監視

パフォーマンス モニター カウンターが追加されました。 これらのカウンターを使用して、時刻の精度のベースライニング、監視、およびトラブルシューティングを行うことができます。 次の表に、カウンターの一覧を示します。

カウンタ 説明
計算されたタイム オフセット システム クロックと選択したタイム ソースの間の時刻補正の絶対値。W32Time サービスによってマイクロ秒単位で計算されます。 新しい有効なサンプルが利用可能な場合は、そのサンプルによって示されるタイム オフセットを使用して計算された時刻が更新されます。 この時間は、ローカル クロックの実際の時刻補正です。 W32Time では、このオフセットを使用して時刻の修正が開始されます。また、ローカル クロックに適用する必要がある残りの時刻補正を使用して、サンプルの間で計算された時間が更新されます。 時刻精度を追跡するには、短いポーリング間隔 (256 秒以内など) でこのパフォーマンス カウンターを使用し、カウンター値が必要な時刻精度の上限よりも小さくなるようにします。
クロック周波数の調整 W32Time によって行われる、ローカル システム クロックのクロック周波数の調整の絶対値 (10 億分の 1 単位) です。 このカウンターは、W32Time によって実行されているアクションを視覚化するのに役立ちます。
NTP ラウンドトリップ遅延 NTP クライアントがサーバーからの応答を受信する際に発生した、最新のラウンドトリップ遅延です (マイクロ秒単位)。 この遅延は、NTP クライアント上で、NTP サーバーに要求を送信してから、サーバーから有効な応答を受信するまでに経過した時間です。 このカウンターは、NTP クライアントで発生する遅延の特性を示すのに役立ちます。 ラウンドトリップの増加や変化は、NTP による時刻の計算にノイズを混入させ、さらに NTP を使用した時刻の同期の精度に影響を与える可能性があります。
NTP クライアントのソースの数 NTP クライアントによって使用されているアクティブな NTP タイム ソースの数です。 この数値は、このクライアントの要求に応答している、アクティブなタイム サーバーの個別の IP アドレスの数です。 この数は、ピア名の DNS 解決と現在の到達可能性によっては、構成されたピア数よりも大きい数または小さい数になる可能性があります。
NTP サーバーの受信要求 NTP サーバーが受信した要求の数です (要求数/秒)。
NTP サーバーの送信応答 NTP サーバーが応答した要求の数です (応答数/秒)。

最初の 3 つのカウンターは、精度の問題をトラブルシューティングするためのシナリオを対象としています。 詳細については、この記事で後述する「時刻精度と NTP のトラブルシューティング」を参照してください。 最後の 3 つのカウンターは、NTP サーバーに関するシナリオに対応しており、負荷を特定し、現在のパフォーマンスをベースライニングする場合に役立ちます。

環境ごとの構成の更新

以下の表では、各ロールについての Windows Server 2016 と以前のバージョン間での既定の構成の変更について説明します。 Windows Server 2016 と Windows 10 Anniversary Update (ビルド 14393) の設定が個別になりました。そのため、これらは別々の列に示されています。

ロール 設定 Windows Server 2016 Windows 10 Windows Server 2012 R2
Windows Server 2008 R2
Windows 10
スタンドアロン/Nano Server
"タイム サーバー" time.windows.com N/A time.windows.com
ポーリング頻度 64 - 1024 秒 N/A 週 1 回
"クロック更新頻度" 1 秒間に 1 回 N/A 1 時間に 1 回
スタンドアロン クライアント
"タイム サーバー" N/A time.windows.com time.windows.com
"ポーリング頻度" N/A 1 日 1 回 週 1 回
"クロック更新頻度" N/A 1 日 1 回 1 時間に 1 回
ドメイン コントローラー
"タイム サーバー" PDC/GTIMESERV N/A PDC/GTIMESERV
"ポーリング頻度" 64 - 1024 秒 NA 1,024 - 32,768 秒
"クロック更新頻度" 1 秒間に 1 回 N/A 1 時間に 1 回
ドメイン メンバー サーバー
"タイム サーバー" DC N/A DC
ポーリング頻度 64 - 1024 秒 NA 1,024 - 32,768 秒
"クロック更新頻度" 1 秒間に 1 回 N/A 5 分ごとに 1 回
ドメイン メンバー クライアント
"タイム サーバー" N/A DC DC
ポーリング頻度 NA 1,204 - 32,768 秒 1,024 - 32,768 秒
"クロック更新頻度" N/A 5 分ごとに 1 回 5 分ごとに 1 回
Hyper-V ゲスト
"タイム サーバー" ホストとタイム サーバーの Stratum に基づき最適なオプションが選択される ホストとタイム サーバーの Stratum に基づき最適なオプションが選択される ホストを既定値とする
ポーリング頻度 上のロールに基づく 上のロールに基づく 上のロールに基づく
"クロック更新頻度" 上のロールに基づく 上のロールに基づく 上のロールに基づく

Note

Hyper-V の Linux については、後述の「Linux で Hyper-V のホスト時刻を使用できるようにする」セクションをご覧ください。

ポーリング頻度とクロック更新頻度の増加の影響

より正確な時刻を提供するために、ポーリング頻度と時刻更新の既定値を増加させ、小さな補正をより頻繁に行うようにすることができます。 この変更により、ユーザー データグラム プロトコル (UDP)/NTP トラフィックが増えます。 これらのパケットは小さいため、ブロードバンド リンクに対する影響は、ほとんどまたは、まったくありません。 この利点は、より広範なハードウェアと環境において時刻が正確になることです。

バッテリーバックアップ式のデバイスの場合、ポーリング頻度を上げると問題が発生する可能性があります。 バッテリー デバイスの電源がオフになっている間は、時刻が保存されません。 それらを復旧したとき、 クロックの頻繁な修正が必要になる場合があります。 ポーリング頻度の増加によって、 クロックが不安定になり、より多くの電力が消費されます。 クライアントの既定の設定は変更しないことをお勧めします。

Active Directory ドメインの NTP クライアントからの更新増加が波及効果になっても、ドメイン コントローラーへの影響は最小限に抑える必要があります。 NTP のリソース消費量は他のプロトコルと比べてはるかに少なく、その効果もわずかです。 Windows Server 2016 の強化された設定による影響が生じる前に、他のドメイン機能の制限に到達する可能性が高くなります。 Active Directory はセキュリティで保護された NTP を使用します。これは、単純な NTP よりも同期時間が短い傾向があります。 プライマリ ドメイン コントローラー (PDC) から離れた 2 つの Stratum クライアントにスケールアップできることを確認しました。

控えめな計画としては、コアごとに 1 秒あたり 100 個の NTP 要求を想定する必要があります。 たとえば、それぞれ 4 コアの DC が 4 台で構成されているドメインの場合は、1 秒あたり 1,600 の NTP 要求を処理できるようにする必要があります。 64 秒ごとに時刻を同期するように構成されているクライアントが 10,000 台あり、それらの要求を均等な時間間隔で受信する場合、10,000/64 または約 160 の要求数/秒が、すべての DC 全体に分散されます。 この量は、この例に基づいた 1,600 の NTP 要求数/秒という範囲内に簡単に収まります。 これらの計画の推奨事項は控えめであり、ネットワーク、プロセッサの速度、および負荷に大きく依存します。 常に、環境でベースラインとテストを行います。

かなりの CPU 負荷 (40% 以上) で DC が実行されている場合、この負荷によってほぼ確実に NTP 応答にノイズが混入し、ドメインの時刻の精度に影響が生じます。 ここでも、実際の結果を把握するために、ご自分の環境内でテストする必要があります。

時刻の精度測定

Windows Server 2016 の時刻の精度を測定するために、さまざまなツール、方法、および環境が使用されました。 お客様はこれらの手法を使用して、ご自分の環境を測定および調整し、精度の結果が要件を満たしているかどうかを判断できます。

手法

使用されたドメインのソース クロックは、GPS ハードウェアを搭載した 2 台の高精度 NTP サーバーで構成されます。 また、測定用に個別の参照用テスト マシンが使用されました。これにも別の製造元の高精度 GPS ハードウェアが搭載されています。 一部のテストでは、ご自分のドメインのクロック ソースに加えて、参照として使用する正確で信頼性の高い クロック ソースが必要になります。

Microsoft では、物理マシンと仮想マシンの両方で精度を測定するために、4 つの異なる方法が使用されました。 複数の方法により、結果を検証するための独立した手段が提供されました。

  1. w32tm が補正したローカル クロックを、個別の GPS ハードウェアを搭載した参照用テスト マシンと比較して測定する。

  2. W32tm stripchart を使用して、NTP サーバーからクライアントへの NTP ping を測定する。

  3. W32tm stripchart を使用して、クライアントから NTP サーバーへの NTP ping を測定する。

  4. タイム スタンプ カウンター (TSC) を使用して、ホストからゲストへの Hyper-V の結果を測定する。 このカウンターは、両方のパーティションと、両方のパーティションのシステム時刻の間で共有されます。 VM のホスト時刻とクライアント時刻の差が計算されました。 次に、TSC クロックを使用して、ホスト時刻がゲストから補間されます。これは、同時に複数の測定は実行されないためです。 また、タイムセグメント化されたボリューム クロックを使用して、API の遅延とレイテンシを考慮しました。

W32tmは組み込みですが、テスト中に使用されたその他のツールは、お客様のテストと使用のために、オープンソースとして GitHub の Microsoft リポジトリから入手できます。 ツールを使用して測定する方法の詳細については、「Windows Time Calibration Tools の Wiki」 を参照してください。

テスト結果は、Microsoft によってテスト環境の 1 つで行われた測定値のサブセットです。 これらによって、時刻の階層の先頭で維持される精度と、時刻の階層の末尾の子ドメイン クライアントで維持される精度が示されます。 これらの結果は、比較用の 2012 ベースのトポロジ内の同じマシンと比較されます。

トポロジ

比較のために、Windows Server 2012 R2 と Windows Server 2016 に基づいてトポロジをテストしました。 どちらのトポロジも、GPS クロック ハードウェアを搭載した、Windows Server 2016 マシンを参照する 2 つの物理 Hyper-V ホスト マシンで構成されています。 各ホストでは、3 つのドメインに参加している Windows ゲストが実行されます。それらは、次のトポロジに従って配置されています。 それぞれの線は、時刻の階層と、使用されるプロトコル/トランスポートを表しています。

Diagram that shows the Windows time topology with only one child domain client running in the first Hyper-V host.

Diagram that shows the Windows time topology with two child domain clients. One runs in the first Hyper-V host and another runs in the second Hyper-V host.

グラフィカルな結果の概要

次の 2 つのグラフは、前述のトポロジに基づくドメインに含まれる 2 台の特定のメンバーの時刻の精度を表しています。 各グラフには、Windows Server 2012 R2 と 2016 の結果が重ねて表示され、機能強化が視覚的に示されています。 精度は、ゲスト マシン内からホストと比較して測定されました。 このグラフィカル データは、実行されたテストのセット全体のサブセットを表し、最良のケースと最悪のケースのシナリオが表示されています。

Diagram that shows the Windows time topology with the root domain PDC server and the child domain client servers in the first Hyper-V host called out.

ルート ドメイン PDC のパフォーマンス

ルート PDC は、(VMIC を使用して) Hyper-V ホストと同期されます。これは、精度と安定性の両方が実証された GPS ハードウェアを使用する Windows Server 2016 です。 この要件は、コールアウトが特定した網掛け領域で示された 1 ミリ秒の精度を実現するための、重要な要件です。

Diagram that shows the root domain.

子ドメイン クライアントのパフォーマンス

子ドメイン クライアントは、ルート PDC と通信する子ドメイン PDC に接続されています。 その時刻もまた、1 ミリ秒の要件に含まれます。

Diagram that shows the child domain client.

遠距離テスト

次のグラフでは、Windows Server 2016 での 1 つの仮想ネットワーク ホップと 6 つの物理ネットワーク ホップが比較されています。 2 つのグラフは、重なり合うデータを示すために、互いに透明に重ねて表示されています。 ネットワーク ホップの増加は長い待機時間を意味し、時刻の偏差も大きくなります。 このグラフは拡大されているため、領域で表される 1 ミリ秒の境界が大きくなっています。 ご覧のように、時刻は複数のホップで引き続き 1 ミリ秒以内に収まっています。 これは負の方向にシフトしており、ネットワークの非対称が示されています。 各ネットワークはすべて異なるため、測定値はさまざまな環境要因に依存しています。

Diagram that shows the long-distance test.

正確な時刻管理のためのベスト プラクティス

正確な時刻管理のためのベスト プラクティス。

固定ソース クロック

マシンの時刻は、同期先のソース クロックと同程度の精度にしかなりません。 1 ミリ秒の精度を実現するためには、ネットワーク上に、マスター ソース クロックとして参照する GPS ハードウェアまたはタイム アプライアンスが必要です。 既定値の time.windows.com を使用すると、安定したローカル タイム ソースが提供されない可能性があります。 ソース クロックからの距離が大きくなるにつれ、ネットワークが精度に影響を及ぼします。 最良の精度を得るには、各データセンターにマスター ソース クロックを用意する必要があります。

ハードウェア GPS オプション

さまざまなハードウェア ソリューションによって、正確な時刻を実現することができます。 一般的に、現在のソリューションは GPS アンテナに基づいています。 無線およびダイヤルアップ モデム ソリューションでは、専用回線を使用します。 これらは、アプライアンスとして、または PC へのプラグイン (例: PCIe または USB デバイスを介した Windows) としてネットワークに接続されます。 異なるオプションを使用すると、異なるレベルの精度が提供されます。また、ここでも結果は環境によって異なります。 精度に影響を与える変数としては、GPS の可用性、ネットワークの安定性と負荷、および PC ハードウェアなどがあります。 これらはすべて、安定した正確な時刻を得るための要件である、ソース クロックを選択する際の重要な要素となります。

ドメインと時刻の同期

ドメイン メンバーでは、ドメイン階層を使用して、時刻を同期するためのソースとして使用するマシンが決定されます。 各ドメイン メンバーでは、同期する別のマシンが検出され、そのクロック ソースとして保存されます。 各種類のドメイン メンバーでは、時刻の同期用のクロック ソースを検出するために、異なる規則のセットが適用されます。 フォレスト ルートの PDC は、すべてのドメインの既定のクロック ソースです。 さまざまなロールと、そのロールによってソースが検出される方法についての大まかな説明を、ここに示します。

  • PDC を含むドメイン コントローラー ロール – このマシンは、ドメインの権限を持つタイム ソースです。 これは、ドメインで利用可能な最も正確な時間を持っています。 親ドメインの DC と同期する必要があります (GTIMESERV ロールが有効になっている場合を除きます)。
  • その他のドメイン コントローラー – このマシンは、ドメイン内のクライアントおよびメンバー サーバー用のタイム ソースとして機能します。 DC は、自身のドメインの PDC か、親ドメイン内の任意の DC と同期できます。
  • クライアント/メンバー サーバー: このマシンは、自身のドメインの任意の DC または PDC、または親ドメイン内の DC または PDC と同期できます。

利用できる候補に基づいて、最適なタイム ソースを見つけるためにスコアリング システムが使用されます。 このシステムでは、タイム ソースの信頼性と、その相対的な場所が考慮されます。 このチェックは、時刻サービスが開始されたときに 1 回発生します。 時刻の同期方法をより細かく制御する必要がある場合は、特定の場所に適切なタイム サーバーを追加したり、冗長性を追加したりできます。 詳細については、「GTIMESERV を使用してローカルの信頼できるタイム サービスを指定する」セクションをご覧ください。

混在 OS 環境 (Windows Server 2012 R2 と Windows Server 2008 R2)

最良の精度を得るには純粋な Windows Server 2016 ドメイン環境が必要ですが、混在環境でもメリットがあります。 Windows Server 2012 ドメインに Windows Server 2016 Hyper-V をデプロイすると、前述の機能強化によってゲストにメリットが発生しますが、それはゲストも Windows Server 2016 である場合に限られます。 Windows Server 2016 の PDC では、強化されたアルゴリズムによってより正確な時刻を実現できます。これはより安定したソースとなります。 PDC を置き換えることができない場合は、代わりに、GTIMESERV ロールが設定された Windows Server 2016 の DC を追加することができます。これは、ドメインに対する精度のアップグレードになります。 Windows Server 2016 の DC によって、より正確な時刻を下流のタイム クライアントに提供することができます。ただし、その精度はそのソース NTP の時刻と同等です。

また、前述のように、Windows Server 2016 では クロックのポーリングと更新の頻度が変更されています。 これらの頻度は、下位レベルの DC に手動で変更することも、グループ ポリシーを使用して適用することもできます。 これらの構成はテストしていませんが、Windows Server 2008 R2 と Windows Server 2012 R2 で適切に動作し、いくつかの利点を提供する必要があります。

Windows Server 2016 より前のバージョンでは、正確な時刻管理に関して複数の問題があったため、補正が行われた直後にシステム時刻の誤差が発生しました。 この問題のため、正確な NTP ソースから頻繁にタイム サンプルを取得し、そのデータでローカル クロックを補正することで、サンプリング内の期間中のシステム時刻の誤差が小さくなります。 その結果、下位レベルの OS バージョンでのタイムキーピングが向上します。 高精度の設定で構成された Windows Server 2012 R2 NTP クライアントが、正確な Windows Server 2016 NTP サーバーから時刻を同期している場合、観測された最良の精度は約 5 ミリ秒でした。

ゲスト DC に関連する一部のシナリオでは、Hyper-V TimeSync のサンプルによって、ドメインの時刻の同期が中断されることがあります。 この問題は、Windows Server 2016 Hyper-V ホスト上で実行されている Windows Server 2016 ゲストでは発生しません。

Hyper-V TimeSync サービスから W32Time へのサンプルの提供を無効にするには、次のゲスト レジストリ キーを設定します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider "Enabled"=dword:00000000

Linux が Hyper-V のホスト時刻を使用できるようにする

Hyper-V で実行されている Linux ゲストの場合、クライアントは通常、NTP サーバーに対する時刻の同期に NTP デーモンを使用するように構成されます。 Linux ディストリビューションで TimeSync バージョン 4 プロトコルがサポートされていて、Linux ゲストで TimeSync 統合サービスが有効になっている場合は、ホスト時刻に対して同期されます。 このシナリオでは、両方の方法が有効になっている場合、時刻管理に不一致が生じる可能性があります。

ホスト時刻に対して排他的に同期するには、次の 2 つの方法のいずれかで NTP 時刻同期を無効にすることをお勧めします。

  • ntp.conf ファイル内のすべての NTP サーバーを無効にします。
  • NTP デーモンを無効にします。

この構成では、タイム サーバー パラメーターはこのホストになります。 そのポーリング頻度は 5 秒で、クロックの更新頻度も 5 秒です。

NTP 経由で排他的に同期するには、ゲストの TimeSync 統合サービスを無効にすることをお勧めします。

Note

Linux ゲストで正確な時刻をサポートするには、最新のアップストリーム Linux カーネルでのみサポートされている機能が必要です。 この機能は、すべての Linux ディストリビューションではまだ広く利用できるわけではありません。 サポート ディストリビューションの詳細については、「Windows 上の Hyper-V 向けにサポートされる Linux と FreeBSD 仮想マシン」を参照してください。

GTIMESERV を使用してローカルの信頼できるタイム サービスを指定する

GTIMESERV (Good Time Server) フラグを使用することで、正確なソース システム時刻として 1 台以上の DC を指定できます。 たとえば、GPS ハードウェアを搭載した特定の DC には、GTIMESERV というフラグを設定できます。 このフラグより、ドメインで GPS ハードウェアに基づく クロックが参照されることが保証されます。

Note

ドメイン フラグの詳細については、「MS-ADTS プロトコルのドキュメント」を参照してください。

TIMESERV は、現在マシンに権限があるかどうかを示す、もう 1 つの関連する Domain Services フラグです。これは、DC の接続が失われると変更される可能性があります。 この状態の DC は、NTP 経由でクエリを実行すると Unknown Stratum を返します。 複数回試行した後、DC はシステム イベントのタイム サービス イベント 36 をログに記録します。

DC を GTIMESERV として構成する場合は、次のコマンドを使用して手動で構成できます。 この場合、DC ではマスター クロックとして別のマシンが使用されます。 このマシンはアプライアンスまたは専用のコンピューターとなります。

w32tm /config /manualpeerlist:"master_clock1,0x8 master_clock2,0x8" /syncfromflags:manual /reliable:yes /update

Note

詳細については、「Windows タイム サービスを構成する」を参照してください。

DC に GPS ハードウェアが搭載されている場合は、次の手順を使用して NTP クライアントを無効にし、NTP サーバーを有効にする必要があります。

まず、次のレジストリ キーの変更を使用して、NTP クライアントを無効にし、NTP サーバーを有効にします。

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpClient /v Enabled /t REG_DWORD /d 0 /f

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpServer /v Enabled /t REG_DWORD /d 1 /f

次に、Windows タイム サービスを再起動します

net stop w32time && net start w32time

最後に、次を使用して、このマシンに信頼性の高いタイム ソースがあることを示します。

w32tm /config /reliable:yes /update

変更が正しく行われたことを確認するには、次のコマンドを実行します。これは、ここに示す結果に影響を与えます。

w32tm /query /configuration

Value|Expected Setting|
----- | ----- |
AnnounceFlags| 5 (Local)|
NtpServer |(Local)|
DllName |C:\WINDOWS\SYSTEM32\w32time.DLL (Local)|
Enabled |1 (Local)|
NtpClient| (Local)|

w32tm /query /status /verbose

Value| Expected Setting|
----- | ----- |
Stratum| 1 (primary reference - syncd by radio clock)|
ReferenceId| 0x4C4F434C (source name: "LOCAL")|
Source| Local CMOS Clock|
Phase Offset| 0.0000000s|
Server Role| 576 (Reliable Time Service)|

サード パーティの仮想プラットフォーム上の Windows Server 2016

Windows が仮想化されている場合、既定では、ハイパーバイザーによって時刻が提供されます。 ただし、Active Directory を正常に機能させるためには、ドメインに参加しているメンバーが DC と同期している必要があります。 サード パーティの仮想プラットフォームのゲストとホストの間では、時刻の仮想化を無効にすることをお勧めします。

階層の検出

ドメイン内のマスター クロック ソースへと続く時刻の階層のチェーンは動的であるため、ネゴシエートされた場合は、特定のマシンの状態を照会して、そのタイム ソースとマスター ソース クロックへのチェーンを把握する必要があります。 この情報は、時刻の同期に関する問題を診断するのに役立ちます。

特定のクライアントのトラブルシューティングを行う場合は、まず、w32tm コマンドを使用して、そのタイム ソースを把握します。

w32tm /query /status

その結果の表示には、ソースが含まれています。 このソースは、ドメイン内の時刻の同期先を示しています。 これが、このマシンの時刻の階層の最初のステップです。 次に、前述のコマンドからソース エントリを使用し、/stripchart パラメーターを使ってチェーン内の次のタイム ソースを探します。

w32tm /stripchart /computer:MySourceEntry /packetinfo /samples:1

また、指定したドメイン内で検出できる各 DC の一覧を表示し、各パートナーを特定するのに役立つ結果を表示する、次のコマンドも便利です。 このコマンドには、手動で構成されたマシンが含まれます。

w32tm /monitor /domain:my_domain

この一覧を使用して、各結果をトレースしてドメイン内を調べ、階層と各ステップの時刻補正を把握することができます。 タイム オフセットが著しく悪化する点を特定することで、不正確な時刻のルートを突き止めることができます。 そこから、w32tm のログ記録を有効にすることで、その時刻が正確でない理由を調査することができます。

グループ ポリシーを使用する

グループ ポリシーを使用すると、たとえば特定の NTP サーバーを使用するようにクライアントを割り当てたり、仮想化されている場合にダウンレベルの オペレーティング システムの構成方法を制御したりすることで、より高い精度を実現できます。 考えられるシナリオと関連するグループ ポリシー設定の一覧を、ここに示します。

仮想化ドメイン - Windows Server 2012 R2 で仮想化 DC を制御して、そのドメインと時刻を同期させるには、Hyper-V ホストを使用する代わりに、このレジストリ エントリを無効にすることができます。 PDC の場合は、Hyper-V ホストによって最も安定したタイム ソースが提供されるため、エントリを無効にする必要はありません。 このレジストリ エントリを変更した後は、W32Time サービスを再起動する必要があります。

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider] "Enabled"=dword:00000000

精度に依存する負荷 - 時刻の精度に依存するワークロードでは、マシンのグループを構成して、NTP サーバーおよび関連する時刻設定 (ポーリング頻度や時刻更新頻度など) を設定できます。 このタスクは通常、ドメインによって処理されますが、より細かく制御するために、特定のマシンを対象としてマスター クロックを直接指定することができます。

グループ ポリシー設定 新しい値
NtpServer ClockMasterName,0x8
MinPollInterval 6 - 64 秒
MaxPollInterval 6
UpdateInterval 100 - 毎秒 1 回
EventLogFlags 3 - すべての特別な時刻のログ記録

Note

NtpServer と EventLogFlags 設定は、[Windows NTP クライアントの構成] 設定を使用して、System\Windows Time Service\Time Providers に配置されます。 その他の 3 つは、[グローバル構成] 設定を使用して、System\Windows Time Service に配置されます。

リモートの精度に依存する負荷リモート: ブランチ ドメイン (小売および支払いクレジット業界 (PCI) など) のシステムの場合、Windows では、手動の NTP タイム ソースが構成されていない限り、現在のサイト情報と DC ロケーターを使用してローカル DC が検索されます。 この環境では 1 秒の精度が要求され、正確な時刻へのより高速な収束が使用されます。 このオプションを使用すると、W32Time で反時計回りにすることができます。 この挙動が許容範囲内であり、要件を満たしている場合は、次のポリシーを作成できます。 あらゆる環境と同様に、必ずネットワークのテストとベースライニングを行ってください。

グループ ポリシー設定 新しい値
MaxAllowedPhaseOffset 1 ただし、1 秒より大きい場合は、時計を正しい時刻に設定します。

MaxAllowedPhaseOffset 設定は、[グローバル構成] 設定を使用して、System\Windows Time Service 配下に配置します。

Note

グループ ポリシーと関連するエントリの詳細については、TechNet の「Windows タイム サービス ツールと設定」の記事を参照してください。

Azure と Windows IaaS に関する考慮事項

ここでは、Azure と Windows の IaaS (Infrastructure as a Service) について考慮すべきポイントをいくつか説明します。

Azure 仮想マシン: Active Directory Domain Services

Active Directory Domain Services を実行している Azure VM が既存のオンプレミスの Active Directory フォレストに含まれている場合は、TimeSync (VMIC) を無効にする必要があります。 これは、物理、仮想両方のフォレスト内のすべての DC で、1 つの時刻同期の階層を使用できるようにするためです。 詳細については、「Hyper-V でドメイン コントローラーを実行する」を参照してください。

Azure 仮想マシン: ドメインに参加しているマシン

既存の Active Directory フォレスト (仮想または物理) にドメイン参加しているマシンをホストしている場合のベスト プラクティスは、ゲストに対して TimeSync を無効にし、Type=NTP5 の時刻を構成することで、DC と同期するように W32Time を構成することです

Azure 仮想マシン: スタンドアロン ワークグループ マシン

Azure VM がドメインに参加しておらず、DC でもない場合は、既定の時刻構成を維持し、VM をホストと同期させることをお勧めします。

正確な時刻を必要とする Windows アプリケーション

Windows アプリケーションで正確な時間が必要な場合に実行できるいくつかのアクションを次に示します。

タイム スタンプ API

時間の経過ではなく、UTC に対する最大の精度を必要とするプログラムでは、GetSystemTimePreciseAsFileTime API を使用する必要があります。 この API を使用することで、お使いのアプリケーションでシステム時刻が取得され、それが Windows タイム サービスによって補正されることが保証されます。

UDP パフォーマンス

トランザクションに UDP 通信を使用するアプリケーションがあり、待機時間を最小限に抑えることが重要な場合は、関連するいくつかのレジストリ エントリを使用して、ベース フィルター エンジンのポートから除外するポートの範囲を構成できます。 この作業により、待機時間た短縮され、スループットが増加します。 ただし、レジストリの変更は、経験豊富な管理者だけが行うようにする必要があります。 この回避策によって、ポートがファイアウォールによるセキュリティ保護から除外されます。 詳細については、次を参照してください。

Windows Server 2012 および Windows Server 2008 の場合は、まず修正プログラムをインストールする必要があります。 詳細については、「Windows 8 および Windows Server 2012 でマルチキャスト受信アプリケーションを実行する場合のデータグラムの損失」を参照してください。

ネットワーク ドライバーの更新

一部のネットワーク ベンダーには、ドライバーの待機時間と UDP パケットのバッファリングに関するパフォーマンスを向上させる、ドライバーの更新プログラムが用意されています。 ネットワーク ベンダーに問い合わせて、UDP スループットの改善につながる更新プログラムがあるかどうかを確認してください。

監査目的のログ記録

時刻のトレースに関する規制に準拠するために、w32tm ログ、イベント ログ、およびパフォーマンス モニターの情報を手動でアーカイブできます。 後日、アーカイブされた情報を使用して、過去の特定の時点でのコンプライアンスを証明することができます。 精度を示すには、次の要素を使用します。

  1. 計算された時刻の補正パフォーマンス モニター カウンターを使用した時刻の精度。 このカウンターにより、目的の精度で時計が表示されます。
  2. w32tm ログで Peer Response from を探しているクロック ソース。 メッセージ テキストの後には、IP アドレスまたは VMIC が示されます。これは、タイム ソースと、検証する参照クロックのチェーンの次の部分を表します。
  3. ClockDispl Discipline: \*SKEW\*TIME\* の発生を検証する w32tm ログを使用したクロックの状態のステータス。 このステータスは、w32tm がその時点でアクティブだったことを示します。

イベント ログ

完全なストーリーを得るには、イベント ログの情報も必要です。 システム イベント ログを収集し、Time-Server、Microsoft-Windows-Kernel-Boot、Microsoft-Windows-Kernel-General でフィルター処理することにより、時刻を変更したその他の変更があるかどうかを検出できる場合があります (サード パーティなど)。 外部からの干渉を除外するために、これらのログが必要になる場合があります。 グループ ポリシーは、どのイベント ログがログに書き込まれるかに影響を与える可能性があります。 詳細については、前のセクション「グループ ポリシーを使用する」を参照してください。

W32time デバッグ ログ

監査目的で w32tm を有効にするには、次のコマンドを使用して、クロックの定期的な更新とソースクロックを示すログ記録を有効にすることができます。 新しいログ記録を有効にするには、サービスを再起動してください。

詳細については、「Windows タイム サービスのデバッグ ログを有効にする方法」を参照してください。

w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-73,103,107,110

パフォーマンス モニター

Windows Server 2016 の Windows タイム サービスでは、監査用のログの収集に使用できるパフォーマンス カウンターが公開されています。 これらのカウンターは、ローカルでもリモートでもログに記録できます。 [パソコンの時刻補正] および [ラウンドトリップ遅延] カウンターを記録できます。 パフォーマンス カウンターと同様に、それらをリモートで監視したり、System Center Operations Manager を使用してアラートを作成したりすることができます。 たとえば、アラートを使用して、時刻補正が目的の精度からずれたときにアラームが表示されるようにすることができます。 詳細については、「System Center 管理パック」を参照してください。

Windows の追跡可能性の例

w32tm ログ ファイルから、2 つの情報を検証することができます。 1 つ目は、ログ ファイルが現在調整時刻であることを示す情報です。 これにより、その時刻が、問題の時点で Windows タイム サービスによって補正されていたことを示します。

 151802 20:18:32.9821765s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:223 CR:156250 UI:100 phcT:65 KPhO:14307
 151802 20:18:33.9898460s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:1 CR:156250 UI:100 phcT:64 KPhO:41
 151802 20:18:44.1090410s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:1 CR:156250 UI:100 phcT:65 KPhO:38

重要な点は、メッセージに ClockDispln Discipline というプレフィックスが付いていることです。これは W32Time がシステム時刻と対話していることを証明しています。

現在参照クロックとして使用されているソース コンピュータが報告されている、問題の時点よりも前のログの最後のレポートを検索する必要があります。 この情報は、IP アドレス、コンピューター名、または VMIC プロバイダー (Hyper-V のホストと同期していることを示す) である場合があります。 次の例では、IPv4 アドレス 10.197.216.105 が表示されています。

151802 20:18:54.6531515s - Response from peer 10.197.216.105,0x8 (ntp.m|0x8|0.0.0.0:123->10.197.216.105:123), ofs: +00.0012218s

参照時刻のチェーンの最初のシステムを検証したので、参照タイム ソースのログ ファイルを調査して、同じ手順を繰り返す必要があります。 このプロセスは、GPS や NIST などの既知のタイム ソースなど、物理的な時刻に到達するまで続きます。 参照 クロックが GPS ハードウェアの場合は、製造時のログが必要になることもあります。

ネットワークに関する考慮事項

NTP プロトコルのアルゴリズムは、ネットワークの対称性に依存しています。 ネットワーク ホップの数が増えるにつれて、非対称の可能性が高くなります。 この理由により、使用する特定の環境でどのような種類の精度が発生するかを予測することが困難になります。

パフォーマンス モニターと Windows Server 2016 の新しい Windows タイム カウンターを使用して、環境の精度を評価し、ベースラインを作成することができます。 さらに、トラブルシューティングを行って、ネットワーク上の任意のマシンの現在のオフセットを確認することもできます。

ネットワーク上の正確な時刻については、2 つの一般的な標準があります。

  • Precision Time Protocol - IEEE 1588(PTP): PTP は、ネットワーク インフラストラクチャの要件がより厳しくなりますが、多くの場合、サブマイクロ秒の精度が得られます。
  • Network Time Protocol – RFC 1305(NTP): NTP は、より広範なネットワークや環境で動作するため、管理が容易になります。

Windows では、ドメインに参加していないマシンに対して、既定で Simple NTP (RFC2030) がサポートされています。 ドメインに参加しているマシンの場合は、MS-SNTP と呼ばれるセキュリティで保護された NTP が使用されます。このプロトコルではドメインにネゴシエートされたシークレットが活用され、RFC1305 および RFC5905 で説明されている認証済み NTP よりも大きな管理上の利点をもたらします。

ドメインに参加しているプロトコルとドメインに参加していないプロトコルの両方で、UDP ポート 123 が必要です。 NTP のベスト プラクティスの詳細については、「ネットワーク タイム プロトコルの現在のベスト プラクティスに関する IETF ドラフト」を参照してください。

信頼できるハードウェア クロック (RTC)

Windows では、特定の境界を越えない限り時刻はステップされず、代わりにクロックが統制されます。 つまり、w32tm は、[クロック更新頻度] 設定を使用して、一定の間隔でクロックの周波数を調整します。その既定値は、Windows Server 2016 では毎秒 1 回に設定されます。 時計が遅れている場合は、周波数が加速します。 先行している場合は、頻度が遅くなります。 ただし、クロック周波数を調整している間は、ハードウェア クロックによって制御が行われます。 ファームウェアまたはハードウェア クロックに問題があると、マシンの時刻の精度が下ります。

これが、環境内でテストとベースライニングを行う必要があるもう 1 つの理由です。 [計算された時刻補正] パフォーマンス カウンターが目標の精度で安定しない場合は、ファームウェアが最新の状態であることを確認することをお勧めします。 別のテストとして、重複するハードウェアによって同じ問題が再現されているかどうかを確認できます。

時刻の精度と NTP に関するトラブルシューティング

上記の「階層の検出」セクションを使用すると、不正確な時刻の原因を把握することができます。 時刻補正を確認して、時刻が NTP ソースから最も大きくずれている階層内の点を探してください。 階層を理解したら、その特定のタイム ソースが正確な時刻を受け取らない理由を調査することができます。

時刻がずれているシステムに焦点を当てると、以下のツールを使用して、問題の特定と解決策の発見に役立つ詳細情報を収集できます。 UpstreamClockSource 参照は、w32tm /config /status を使用した時刻の検出です。

  • システム イベント ログ
  • w32tm logs - w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-300 を使用してログの記録を有効にする
  • w32Time レジストリ キー HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time
  • ローカル ネットワーク トレース
  • パフォーマンス カウンター (ローカル コンピューターから、または UpstreamClockSource)
  • W32tm /stripchart /computer:UpstreamClockSource
  • 待機時間とソースへのホップ数を把握するための PING UpstreamClockSource
  • Tracert UpstreamClockSource
問題 現象 解決方法
ローカル TSC クロックが安定しない。 使用プラットフォーム: 物理コンピューター。同期クロックは安定クロックですが、1 - 2 分ごとに数百マイクロ秒発生します。 ファームウェアを更新するか、別のハードウェアで同じ問題が表示されないかを検証します。
ネットワーク待機時間。 w32tm stripchart には、10ms以上の RoundTripDelay が表示されます。 遅延が変化すると、ラウンドトリップ時間の半分と同じ長さのノイズが発生します。たとえば、一方向の遅延です。

UpstreamClockSource は、PING によって示されるように、複数のホップです。 TTL は 128 に近くなります。

各ホップの待機時間を調べるには、Tracert を使用します。		 より近い時刻のクロック ソースを探します。 解決策としては、同じセグメントにソース クロックを設置する方法、または地理的に近い場所にあるソース クロックを手動で指定する方法があります。 ドメインのシナリオでは、GTimeServ ロールを持つマシンを追加します。
NTP ソースに確実に接続できない。 W32tm /stripchart 断続的に「要求がタイムアウトしました」を返します。 NTP ソースが応答しない。
NTP ソースが応答しない。 パフォーマンス カウンターで NTP クライアントのソースの数、NTP サーバーの受信要求、NTP サーバーの送信応答をチェックし、ベースラインと比較した使用状況を判断します。 サーバーのパフォーマンス カウンターを使用して、ベースラインに関連して負荷が変化したかどうかを確認します。

ネットワークの輻輳に関する問題はありますか。
ドメイン コントローラーで最も正確なクロックが使用されない。 トポロジの変更、または最近追加されたマスター タイム クロック。 w32tm /resync /rediscover
クライアント クロックがずれている。 システム イベント ログのタイム サービス イベント 36 や、NTP Client Time Source Count カウンターが 1 から 0 に変化していることを示すログ ファイルのテキスト。 アップストリーム ソースのトラブルシューティングを行い、パフォーマンス上の問題が発生しているかどうかを把握します。

時刻のベースライニング

ベースライニングは、まずネットワークのパフォーマンスと精度を把握し、将来問題が発生したときにそのベースラインと比較できるため、重要です。 ルート PDC または GTIMESRV でマークされているすべてのマシンをベースライニングすることをお勧めします。 また、すべてのフォレストで PDC をベースライニングすることをお勧めします。 最後に、興味深い特性 (距離や高負荷など) を持つ重要な DC またはマシンを選択し、それらをベースライニングしてください。

また、Windows Server 2016 と 2012 R2 のベースラインを設定する場合にも役立ちます。 ただし、Windows Server 2012 R2 にはパフォーマンス カウンターがないため、比較に使用できるツールとして w32tm /stripchart のみ使用できます。 同じ特性を持つ 2 台のマシンを選択するか、マシンをアップグレードして更新後の結果を比較する必要があります。 Windows の時刻測定の補遺には、2016 と 2012 の間で詳細な測定を行う方法が詳しく記載されています。

すべての W32Time パフォーマンス カウンターを使用して、少なくとも 1 週間分のデータを収集します。 このデータにより、時間の経過に伴うネットワークのさまざまな情報を把握するための十分な参照が得られます。また、十分な実行回数により、時刻の精度の安定性に自信を持つことができます。

NTP サーバーの冗長性

ドメインに参加していないマシンまたは PDC と共に使用される手動の NTP サーバー構成では、可用性に関する冗長性のための手段として複数のサーバーを使用することをお勧めします。 また、すべてのソースが正確で安定していると仮定すると、これによって精度も向上します。 ただし、トポロジが適切に設計されていない場合や、タイム ソースが安定していない場合は、結果の精度が悪くなる可能性があるため、注意が必要です。 W32Time から手動で参照できる、サポートされるタイム サーバーの数の上限は、10 台です。

うるう秒

地球の自転周期は、気候上の事象や地質学的な事象によって、時間の経過と共に変化します。 通常は、数年ごとに約 1 秒変化します。 微小な時間による変化が大きくなりすぎると、1 秒の修正 (プラスまたはマイナス) が追加されます。これをうるう秒と呼びます。 この挿入は、誤差が 0.9 秒を超えないように行われます。 この修正は、実際の修正の 6 か月前に発表されます。 Windows Server 2016 より前では、Microsoft タイム サービスによってうるう秒が把握されることはなく、この問題は外部のタイム サービスに依存していました。 Windows Server 2016 の時刻の精度の強化に伴い、Microsoft では、うるう秒の問題に対するより適切なソリューションに取り組んでいます。

セキュリティで保護された時刻のシード処理

Server 2016 の W32Time には、セキュリティで保護された時刻のシード処理機能が含まれています。 この機能を使用すると、発信 SSL 接続から現在のおおよその時刻を判断できます。 この時刻の値は、ローカル システム クロックを監視し、明らかなエラーを修正するために使用されます。 この機能の詳細については、こちらのブログ記事を参照してください。 信頼できるタイム ソースと、(時刻補正の監視を含む) 十分に監視されたマシンを使用する展開では、セキュリティで保護された時刻のシード処理機能を使用せず、代わりに既存のインフラストラクチャに依存することを選択できます。

機能を無効にするには:

  1. グループ ポリシーを使用して SecureTimeSeeding を管理します。 設定については、「UtilizeSslTimeData の設定: 学習: ポリシー CSP - ADMX_W32Time」を参照してください。

  2. または、レジストリ値を手動で設定することもできます。 特定のコンピューター上で、UtilizeSSLTimeData レジストリ構成値を 0 に設定します。

    reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData /t REG_DWORD /d 0 /f

  3. 何らかの理由によりマシンをすぐに再起動できない場合は、構成の更新について W32Time に通知することができます。 この通知は、SSL 接続から収集された時刻データに基づく時刻の監視と適用を停止します。

    W32tm.exe /config /update

  4. マシンを再起動すると、設定は直ちに有効になります。また、SSL 接続からの時刻データの収集も停止されます。 この後半部分のオーバーヘッドは非常に小さいため、パフォーマンス上の問題にはならないはずです。

  5. この設定をドメイン全体に適用するには、[W32Time グループ ポリシー] のUtilizeSSLTimeData 値を 0 に設定し、設定を発行します。 この設定がグループ ポリシー クライアントによって適用されると、W32Time に通知が送信され、SSL の時刻データを使用した時刻の監視と適用が停止されます。 SSL の時刻データの収集は、各マシンの再起動時に停止されます。 ドメイン内にポータブルな薄型ノート PC やタブレットが含まれている場合は、このポリシーの変更からそのようなマシンを除外することをお勧めします。 このようなデバイスではいずれバッテリが消耗し、時刻をブートストラップするためにセキュリティで保護された時刻のシード処理機能が必要になります。