Windows Server 2016 の正確な時刻
適用対象: Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012、Windows 10 以降、Azure Stack HCI、バージョン 21H2 および 20H2
Windows タイム サービスは、クライアントとサーバーの時刻の同期プロバイダーにプラグイン モデルを使用するコンポーネントです。 Windows には 2 つの組み込みクライアント プロバイダーがあり、サードパーティのプラグインを利用できます。 1 つのプロバイダーは NTP (RFC 1305) または MS-NTP を使用して、ローカル システム時刻を NTP や MS-NTP に準拠した参照サーバーと同期します。 もう 1 つのプロバイダーは Hyper-V 用で、仮想マシン (VM) を Hyper-V ホストと同期させます。 複数のプロバイダーが存在する場合、Windows は最初に Stratum レベル、次にルート遅延、ルート分散、そして最後に時間オフセットを使用して最適なプロバイダーを選択します。
注意
Windows Time サービスの概要については、こちらの概要ビデオをご覧ください。
このトピックでは、正確な時刻の有効化に関連して、次のことについて説明します。
- 改善
- 測定
- 推奨する運用方法
重要
Windows 2016 の正確な時刻の記事で参照されている補遺は、こちらからダウンロードできます。 このドキュメントでは、テストと測定の手法についてより詳しく説明しています。
注意
Windows タイム プロバイダー プラグイン モデルについては、TechNet に記載されています。
ドメイン階層
ドメインとスタンドアロンの構成では、動作が異なります。
ドメイン メンバーでは、セキュア NTP プロトコルが使用されます。これは、認証を使用して、時間参照のセキュリティと信頼性を確保します。 ドメイン メンバーは、ドメイン階層とスコアリング システムで決定されるマスター クロックと同期します。 ドメインには、時刻階層の階層レイヤーがあります。それにより、各 DC は、より正確な時刻階層を持つ親 DC を指します。 階層は、PDC、またはルート フォレスト内の DC、あるいはドメインの適切なタイム サーバーを示す GTIMESERV ドメイン フラグを持つ DC に解決されます。 下記の「GTIMESERV を使用してローカルの信頼できるタイム サービスを指定する」セクションを参照してください。
スタンドアロン マシンは、既定で time.windows.com を使用するように構成されています。 この名前は、DNS サーバー (Microsoft が所有するリソースを指している必要がある) によって解決されます。 リモートに配置されているすべての時間参照と同様に、ネットワークが停止すると、同期が妨げられる可能性があります。 ネットワーク トラフィックの負荷と非対称ネットワーク パスにより、時刻の同期の精度が低下する場合があります。 1 ミリ秒の精度を確保する場合、リモートの時刻源に依存することはできません。
Hyper-V ゲストには、選択できる Windows タイム プロバイダーが少なくとも 2 つ (ホスト時刻と NTP) あるため、ゲストとして実行しているときに、ドメインまたはスタンドアロンで動作が異なる場合があります。
注意
ドメイン階層とスコアリング システムの詳細については、Windows タイム サービスの概要に関するブログの投稿を参照してください。
注意
Stratum とは、NTP と Hyper-V の両方のプロバイダーで使用される概念であり、その値は階層内のクロックの位置を示します。 Stratum 1 は最上位のクロック用に予約されており、Stratum 0 は正確であると想定され、それに関連する遅延がほとんどまたはまったくないハードウェア用に予約されています。 Stratum 2 は Stratum 1 のサーバーに、Stratum 3 は Stratum 2 に問い合わせます。 多くの場合、下位の Stratum の方がより正確なクロックを示しますが、相違が検出される可能性もあります。 また、W32time では、Stratum 15 以下からの時刻のみを受け入れます。 クライアントの Stratum を表示するには、"w32tm /query /status" を使用します。
正確な時刻のための重要な要因
どの場合においても、正確な時間のためには、次の 3 つの重要な要因があります。
- 確かなソース クロック - ドメイン内のソース クロックは、正確で安定している必要があります。 これは通常、GPS デバイスをインストールするか、Stratum 1 のソースを参照しつつ、3. を考慮することを意味します。 たとえば、水面に 2 艘のボートがあり、その海面からの高さを測定してもう一方と比較しようとしているとします。その場合、ソースのボートが非常に安定して、動いていない状態であれば、正確さは最良となります。 時刻でも同じことが言えます。ソース クロックが安定していなければ、同期されたクロックのチェーン全体が影響を受け、それが各段階で拡大します。 また、アクセス可能である必要もあります。それは、接続が中断された場合、時間の同期が妨げられるからです。 そして最後に、セキュリティで保護されている必要があります。 時刻の参照が適切に管理されていない場合や、悪意のある可能性があるユーザーによって操作された場合、ドメインが時間ベースの攻撃にさらされる可能性があります。
- 安定したクライアント クロック - 安定したクライアント クロックにより、オシレーターの自然なドリフトを抑制できます。 NTP は、複数の NTP サーバーからの複数のサンプルを使用して、ローカル コンピューターのクロックを調整できます。 時刻の変更を行うのではなく、むしろローカル クロックを遅らせたり速めたりして、正確な時間にすばやく近づけて、NTP 要求間の正確さを維持します。 ただし、クライアント コンピューター クロックのオシレーターが安定していないと、調整間の変動が大きくなる可能性があり、Windows でクロックを調整するために使用されるアルゴリズムが正しく機能しません。 場合によっては、正確な時刻を得るために、ファームウェアの更新が必要になる可能性があります。
- 対称 NTP 通信 - NTP 通信の接続は対称であることが重要です。 NTP では、ネットワーク パスが対称であることを想定した計算を使用して時刻の調整を行います。 NTP パケットがサーバーへの送信に使用するパスで、復路にかかる時間量が異なる場合は、精度に影響があります。 たとえば、パスは、ネットワーク トポロジにおける変更や、インターフェイス速度が異なるデバイス経由でパケットがルーティングされたことが原因で変わる可能性があります。
バッテリ駆動型デバイス (モバイルとポータブルの両方) については、異なる戦略を検討する必要があります。 この推奨事項に従って、正確な時間を保持するには、クロックを毎秒 1 回調整する必要があります。これは、クロック更新頻度に相関しています。 これらの設定は、予想より多くのバッテリ電力を消費し、そのようなデバイスに対して Windows で利用可能な省電力モードを阻害する可能性があります。 バッテリ駆動型デバイスには、すべてのアプリケーションの実行を停止する特定の電源モードもあります。これにより、クロックを調整して正確な時刻を維持するという W32time の能力が阻害されます。 また、そもそもモバイル デバイスのクロックはそれほど正確ではない可能性があります。 周囲環境の条件がクロックの精度に影響を与えます。モバイル デバイスは、ある周囲条件から次へと移行する可能性があり、それによって、時間を正確に保つ能力が阻害される場合があります。 そのため、高精度の設定でバッテリ駆動型ポータブル デバイスをセットアップすることはお勧めしません。
なぜ時刻は重要なのでしょうか
正確な時刻が必要になる可能性として、さまざまな理由があります。 Windows の典型的なケースは Kerberos です。これは、クライアントとサーバーの間で 5 分間の精度を必要とします。 ただし、他にも時刻の精度の影響を受ける可能性がある多くの領域があります。次に例を示します。
- 次のような政府の規制:
- 米国における FINRA の 50 ミリ秒の精度
- EU における 1 ミリ秒の ESMA (MiFID II)
- 暗号化アルゴリズム
- クラスター/SQL/Exchange およびドキュメント DB などの分散システム
- ビットコイン取引のためのブロックチェーン フレームワーク
- 分散ログと脅威分析
- AD レプリケーション
- 現在の PCI (Payment Card Industry) における 1 秒の精度