[2018/5/10 Q&A追記] Azure 仮想マシンの時刻同期の仕組み


更新履歴

2018/5/10 FAQ の末尾に追記

2018/3/28 FAQ の末尾に追記

2018/3/28 以下を訂正

: Windows の Active Directory ドメインでは、kerberos 認証をするにあたって、システム時刻に 15の差異が出ると認証が出来なくなります。

: Windows の Active Directory ドメインでは、kerberos 認証をするにあたって、システム時刻に 5の差異が出ると認証が出来なくなります。


こんにちは、Azure プラットフォーム サポート部の石井です。

 

IaaS で VM を構築いただく場合に、Windows と Linux OS によって、時刻同期の仕組みが異なります。
Azure では、仮想化基盤に Hyper-V を採用しています。基本的には、Hyper-V 環境と同じ動きとなりますので Windows と Linux それぞれ、特徴と考慮点をご説明します。

 

Windows VM の場合

Windows VM の場合、Hyper-V 環境での動作を円滑化させるため、Hyper-V 統合コンポーネントというサービスが当該の Windows Server OS 上で稼働しています。
その統合コンポーネントにおいては、"Hyper-V Time Synchronization Service" というサービスが動作しており、5 秒に一度といった頻度で Azure 基盤上のホスト OS との時刻を一致させています。

 

Azure 基盤としても、時刻同期は最重要なものですので、過去、Azure 基盤側のホスト OS が時刻異常になった、という過去事例は一件もありません。(おそらく、そのような状態が検知されたら、そのようなブレード サーバーは即修理行きとなるでしょう)
Azure データセンター間の Windows VM 同士でやりとりをする場合に、時刻の差が出るということは考えられませんので、特に気にせず、この動きに任せて運用しても OK、ということが大原則になります。

 

ここから、少し長くなりますが、オンプレミス側にドメイン コントローラーがあるケースでは、場合によっては当該の時刻同期の仕組みを無効化することが選択肢となる例がありますので、ご紹介します。

 

- ホスト OS との時刻同期を無効にしたほうがよいケース

Windows OS では、ドメイン参加をしているケースでは、ドメイン コントローラーを NTP サーバーとして時刻同期をします。しかしながら、NTP で同期をされるのは数時間に一度です。"Hyper-V Time Synchronization Service" というサービスによって、ホストとの同期がより頻繁にされることを考えると、実際には NTP の設定は機能しないということになります。

ドメイン コントローラー自体が Azure にある VM であるケースでは、全く問題はありません。ドメイン コントローラー自体が Azure VM として、ホスト OS の時刻に同期されるからです。
しかしながら、オンプレ側と VPN もしくは ExpressRoute (専用線) で繋いでいて、オンプレ側のドメイン コントローラーを参照している、といったケースでは、オンプレ側のドメイン コントローラーと Azure 上の Windows VM において微妙に時刻が違う、ということが生じ得ます。

 

Windows の Active Directory ドメインでは、kerberos 認証をするにあたって、システム時刻に 5 分の差異が出ると認証が出来なくなります。つまり、そこまで大きなずれがなければ気にすることではありません。
ただし、万が一、ドメイン コントローラーの時刻が大きく狂うケースが生じると、Windows VM がいっせいに Kerberos 認証ができなくなり、ドメインとしての機能が失われます。
本来であれば、オンプレ側のハードウェア クロックの故障が問題ですので、ハードウェアの修理・交換をするなり、修復をすることが本筋です。しかしながら、そういった事があったとき、瞬時に動けないというケースも多いかと思います。この点が心配ということでしたら、"Hyper-V Time Synchronization Service" というサービスを無効化する、という選択肢もあります。

 

Hyper-V 時刻同期サービス の無効への手順 (Windows)
-----------------------------------------------------
1. 左下にある、Windows ボタン (スタートボタン) を右クリックし、[ファイル名を指定して実行] を選択します。
2. 「services.msc」と入力し、[サービス] 画面を起動します。
3. [Hyper-V Time Synchronization Service] を探し、右クリックし、[プロパティ] を選択します。
4. [Windows Time サービスのプロパティ] 画面の [全般] タブを開きます。
5. スタートアップの種類を "無効" を選択し、[適用] [OK] をクリックします。

※ 再度、設定をもとに戻すには、上記のサービスを自動起動にし、開始します。

 

ただし、上記サービスの無効化を広くお奨めするわけではなく、多くの場合、オンプレミス側のドメイン コントローラーのハードウェア クロックが故障でもしないかぎり、 5 分も差が出るということはありません。上記手順は、あくまでも裏技のようなものと考えていただき、基本的には、Azure に時刻同期を任せてしまう、という考えで、既定のままにしていただくことが便利です。

 

時刻同期サービスの無効化は、リスクを考えた場合の回避手段のひとつですが、公式に推奨される手順ではありません。

これからオンプレ・Azure のハイブリッド構成を設計される方や、上記リスクを見直されるお客様は、Azure 側にあるドメイン コントローラーを PDC エミュレーターとし、Azure 側の時刻を標準とする、という手もあります。そうすれば、オンプレ側のハードウェア クロックの故障が大規模な影響をもたらすというリスクが無くなります。

Linux VM の場合

Linux VM の場合、Hyper-V の Linux Integration Service (LIS) の機能を使って、VM の起動時や VM の一時停止を行うメンテナンスからの復帰時のみ、ホスト OS と時刻同期を行います。
Windows VM であれば、 5 秒に一度、ホスト OS と時刻を同期させる動きをしていますが、Linux VM ではこのような動作は無く、一度 VM があがってからは、NTP サーバーを参照して時刻の修正処理が行われます。

このため、NTP サーバーを設定していただくことが重要です。

 

Linux VM の時刻同期について、よくご質問をいただく内容についてもご紹介させていただきます。


Q. Azure データセンター内に、専用の NTP サーバーはありますか?

A. Azure データセンターには NTP サーバーはありません。Linux ディストリビューションによって、外部の NTP サーバーが設定されていますので、特に差し支えなければ既定のものを参照ください。

CentOS の場合の設定 (/etc/ntp.conf より)
------------------
server 0.centos.pool.ntp.org iburst
server 1.centos.pool.ntp.org iburst
server 2.centos.pool.ntp.org iburst
server 3.centos.pool.ntp.org iburst
------------------

また、弊社の NTP サーバーである、time.windows.com を指定いただいても、Linux OS でも特に問題は生じません。

 

Q. Azure データセンターから外部に接続させていない環境の場合、どうしたらいいですか?

A. 意図的に、VM からインターネット方向のアクセスを完全に遮断しているようなケースでは、Azure 上に NTP サーバーを構築していただき、Azure 内の NTP サーバーに向けることが一案です。
NTP サーバー自体は、適切に外部との疎通を許可して、適切にインターネット時刻サーバーと同期をすることが重要です。

※ Windows では、全 VM が Azure 基盤上のホスト OS に同期されますので、この点を心配する必要はありません。

 

Q. Windows のゲスト OS から Azure のホスト OS との時刻同期を停止したい場合に、  レジストリ[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider] の「'Enabled'=dword:00000001」 を 「'Enabled'=dword:00000000」に変更する必要はありますか?

A. 不要です。Hyper-V Time Synchronization Service の停止・無効化のみでホスト OS との時刻同期は停止します。(レジストリを変更すること自体は特に問題はありませんが、特に動作に変化は生じません)

 

Q. 一部の Linux ベースのゲスト OS にて、再起動時のみ、一時的に時刻がおかしくなる (messages ログの記載時刻がおかしい)

A. Linux OS の messages に記録される boot 時のログの時刻がずれる動作は、Azure プラットフォームとして稼働する Hyper-V のハイパーバイザーの動作に起因している可能性が考えられます。なお、この動作につきましては Hyper-V 仮想環境の設計上生じる動作であり、異常事態ではありませんので、ご安心ください。

Linux OS では boot 時に利用する時刻をハードウェアクロックより取得しています。ハードウェア クロックは Azure のホスト OS の Hyper-V により仮想化されています。
その生成フローは、ゲスト OS がハードウェア クロックへの書き込みを行う際に、ホスト OS の時刻との差分であるデルタ値を作成保持し、ハードウェア クロックを読み込む際にホスト OS の時刻にデルタを追加しゲスト OS へ渡します。このデルタ値の生成はハードウェア クロックへの書き込みを行う際に実施されるため、場合によってはゲスト OS で保持しているデルタ値が古く、その値が実際とはずれた値になっている場合があります。
時刻が変わる問題は、ゲスト OS 起動時の Linux 上の時刻同期ドライバーの起動により元の時間に戻りますので、時刻が変わる問題は再起動時のみに限定され、その後修正されます。

なお弊社にて確認する限り、ハードウェア クロックへの書き込みは RHEL 6 までは停止時に行っていた為、起動時に取得するハードウェア クロックの生成に新しいデルタ値を利用することが可能でした。しかし、RHEL 7 以後停止時に書き込みを行わない動作へと変わりましたので、今回のような問題が一部環境で現れる、といった見え方となる可能性があります。
また同様の事象は RedHat 以外の Linux OS でも発生していることを、過去の調査情報から確認しています。

 

回避策について
===============
最新のデルタ値を利用する事で、正しいハードウェア クロック生成が出来ることが期待されます。
OS シャットダウン時に以下コマンドを実施しハードウェア クロックの書き込みを行うように構成してください。

- 実施コマンド

"hwclock --systohc"


Comments (2)

  1. Aoken より:

    いつもありがとうございます!
    ちょうど探していた記事で大変参考になりました!

    QAの内容について確認させてください。
    Azureの時刻信頼度が高いことを踏まえると”Hyper-V Time Synchronization Service” で時刻同期している
    Azure上のWindows Server OSのVirtualMachineにNTPサーバを立て、それにLinuxOSのVirtualMachineは
    NTPクライアントとして時刻同期させるべきということで正しいでしょうか。

    普段構築するシステムではlinuxOSにNTPサーバを立てがWindowsOSをNTPクライアントとする
    時刻同期の構成でlinuxOSがWindowsOSに立てたNTPサーバに時刻同期する構成を組んだことがないため
    経験値からの不安解消のため念のため確認させてください。

    1. Teppei Ishii より:

      Aoken様、暖かいコメントありがとうございます!

      Linux VM の時刻同期先ですが、Azure 内の Windows VM を NTP サーバーとする、ということは一案かと存じます。

      弊社のエンタープライズ向け、ハイブリッド クラウド構成 (オンプレミス Hyper-V と Azure Hyper-V を接続するような構成) でも、Azure 側で時刻同期をさせた NTP サーバーを構築し、特に Windows の Active Directory の NTP サーバーとするような構成を推奨することがあるようです。

      Windows VM を建てるのはもったいない、というような事でしたら、NTP サーバーは外部のインターネット上のものを参照することをおすすめします。

      [訂正]Linux と Windows は NTP の精度の要件が異なるため、Windows OS を NTP とすることは困難であると判明しました。お詫び申し上げます。

Skip to main content