VM で NTP を構成する

Linux Windows

イベントの注意深いシーケンシングに依存する多くのソフトウェア システムでは、安定していて一貫性のあるシステム クロックが利用されます。これらのシステムでは、タイムスタンプ付きのシステムログを使用して、時間の同期を確保し、問題が発生したときにデバッグすることがよくあります。システム クロックとの同期を維持するために、Compute Engine インスタンスは、時刻同期ハードウェアとソフトウェアのバンドル ソリューションであるネットワーク タイム プロトコル（NTP）を使用するように事前に構成されています。

NTP は、まれな事例である、うるう秒（地球の回転の変化に合わせるために、UTC 時間を 1 秒調整すること）でも役立ちます。地球の回転速度は気候や地質学的な出来事に応じて不定期に変化するため、うるう秒は定期的な間隔で起こるわけではありません。これまでのうるう秒は、ウェブ上のさまざまなサービスやアプリケーションに大きな影響を与えてきました。NTP サーバーにより、うるう秒の間でも、すべてのサーバーが同じ時刻を報告するようになります。

このドキュメントでは、うるう秒の適切な処理など、コンピューティング インスタンスで NTP サーバーを構成する方法について説明します。

Google NTP サーバーと leap smear

Unix オペレーティング システムでは、うるう秒は通常、1 日の最後の 1 秒を繰り返すことで実装されます。これは、タイムスタンプの増加のみを想定しているソフトウェアで問題が発生する可能性があります。この問題を回避するために、 Google Cloudのタイムサーバーは、24 時間（つまり、うるう秒イベントの前後 12 時間）をかけて、追加の 1 秒を「不鮮明」にします。これによりコンピュータは、追加の 1 秒を、繰り返されるタイムスタンプのように一度に認識しなくなります。この方法によって、一貫性のあるタイムスタンプに依存するシステムでのリスクが減少します。すべてのコンピューティング インスタンスで、Google NTP 内部サービスを使用するように構成することをおすすめします。

インスタンスの NTP の構成

Google Cloud では、pool.ntp.org など、外部の NTP サービスがどのようにうるう秒を処理するか予測できません。コンピューティング インスタンスで外部 NTP ソースを使用しないことを強くおすすめします。Google の NTP サービスと外部サービスの両方を使用すると、システム時間に予測できない変更が発生する可能性があります。外部の NTP ソースを 1 つだけ使用する方が、混在して使用するよりは望ましいですが、pool.ntp.org などの外部 NTP サービスは、うるう秒の処理にステッピングを使用する傾向があります。その結果、インスタンスでタイムスタンプの繰り返しが発生する可能性があります。

最も安全なアプローチは、コンピューティング インスタンスが NTP サーバーを 1 つだけ使用するようにし、そのサーバーを、Google が提供する内部 NTP サーバーにするよう構成することです。Google が提供する内部 NTP サーバーについて詳しくは、Google Public NTP に関するよくある質問をご覧ください。

コンピューティング インスタンスが正しく構成されていることを確認するには、次の手順を行います。

Linux（Chrony）

デフォルトでは、新しい Linux リリースの多くは chrony を使用して NTP 設定と時刻の同期を管理します。chrony が内部 NTP サービスのみを使用するようにするには、chrony 構成を確認して外部 NTP サーバーを削除します。

1. ssh を使用して、コンピューティング インスタンスに接続します。

   コンソール

   コンソールを使用して SSH でコンピューティング インスタンスに接続する手順は次のとおりです。

   1. Google Cloud コンソールの [VM インスタンス] ページに移動します。

      [VM インスタンス] に移動

   2. 構成するインスタンスの [SSH] ボタンをクリックします。

      

   gcloud

   Google Cloud CLI を使用して SSH でコンピューティング インスタンスに接続するには、次のコマンドを実行します。

   gcloud compute instances ssh INSTANCE_NAME
   

   INSTANCE_NAME は、接続するインスタンスの名前に置き換えます。

2. インスタンスで chronyc sources を実行し、NTP 構成の現在の状態を確認します。

   $ chronyc sources
   

   出力は次のようになります。

    210 Number of sources = 2
    MS Name/IP address         Stratum Poll Reach LastRx Last sample
    ===============================================================================
    ^* metadata.google.internal      2   6   377     4    -14us[  -28us] +/-  257us
    ^- 38.229.53.9                   2   6    37     4   -283us[ -297us] +/-   28ms
   

   1 つのレコードが metadata.google か metadata.google.internal を指している場合、変更を加える必要はありません。複数のソース（metadata.google と pool.ntp.org などの公開されているソースが一緒に使用されている）が表示されている場合は、ソースを更新して外部 NTP サーバーを削除します。

   この出力例では 2 つのレコードがあり、1 つは metadata.google.internal を指し、もう 1 つは外部アドレスを指します。 複数のソースがあるので、次のステップで説明するように、NTP サーバーを更新して 38.229.53.9 アドレスを削除します。

3. 外部 NTP サーバーを削除して NTP サーバーを構成します。

   追加の NTP サーバーをリストから削除するには、任意のテキスト エディタで /etc/chrony/chrony.conf ファイルを編集します。server external_source_ip_or_name で始まる行をすべて削除します。

   /etc/chrony/chrony.conf ファイルを編集した後、chrony サービスを再起動します。再起動のコマンドは、次の例に示すように、Linux ディストリビューションによって異なる場合があります。

   sudo service chrony restart
   

   sudo systemctl restart chrony
   

4. chronyc sources コマンドを再度実行して、構成を確認します。

   $ chronyc sources
   

   出力は次のようになります。

    210 Number of sources = 1
    MS Name/IP address         Stratum Poll Reach LastRx Last sample
    ===============================================================================
    ^* metadata.google.internal      2   7   377    98  -1343ns[-1588ns] +/-  396us
   

Linux（ntpd）

古いバージョンの Linux ディストリビューションの多くでは、NTP 設定と時間同期の管理に ntpd が使用されています。ntpd が内部 NTP サービスのみを使用するようにするには、ntpd 構成を確認して外部 NTP サーバーを削除します。

1. ssh を使用して、コンピューティング インスタンスに接続します。

   コンソール

   コンソールを使用して SSH でコンピューティング インスタンスに接続する手順は次のとおりです。

   1. Google Cloud コンソールの [VM インスタンス] ページに移動します。

      [VM インスタンス] に移動

   2. 構成するインスタンスの [SSH] ボタンをクリックします。

      

   gcloud

   Google Cloud CLI を使用して SSH でコンピューティング インスタンスに接続するには、次のコマンドを実行します。

   gcloud compute instances ssh INSTANCE_NAME
   

   INSTANCE_NAME は、接続するインスタンスの名前に置き換えます。

2. インスタンスで ntpq -p を実行し、NTP 構成の現在の状態を確認します。

   $ ntpq -p
   

   出力は次のようになります。

   remote           refid           st t when poll reach   delay   offset  jitter
   
   ==============================================================================
   *metadata.google 255.28.23.83     2 u   27   64    1    0.634   -2.537   2.285
   *217.162.232.173 130.149.17.8     2 u  191 1024  176   79.245    3.589  27.454
   

   1 つのレコードが metadata.google か metadata.google.internal を指している場合、変更を加える必要はありません。複数のソース（metadata.google と pool.ntp.org などの公開されているソースが一緒に使用されている）が表示されている場合は、ソースを更新して外部 NTP サーバーを削除する必要があります。

   この出力例では 2 つのレコードがあり、1 つは metadata.google を指し、もう 1 つは外部アドレスを指します。複数のソースがあるので、次のステップで説明するように、NTP サーバーを更新して *217.162.232.173 アドレスを削除する必要があります。

3. 外部ソースを削除して NTP サーバーを構成します。

   NTP サーバーを構成するには、任意のテキスト エディタで /etc/ntp.conf ファイルを編集します。構成の servers セクションを探して、Google 以外の NTP ソースをすべて削除します。次に例を示します。

   vim /etc/ntp.conf
   

   # You do need to talk to an NTP server or two (or three).
   #server ntp.your-provider.example
   ...
   server metadata.google.internal iburst
   

   /etc/ntp.conf ファイルを編集した後、NTP サービスを再起動します。再起動のためのコマンドは、Linux のディストリビューションによって異なる可能性があります。

   sudo service ntp reload
   

   注: デフォルトでは、DHCP クライアントは NTP サーバーのリストを ntp.conf ファイルに追加します。エンタープライズ Linux ディストリビューションを使用していて、DHCP クライアントから提供される NTP 構成を無視する場合は、/etc/sysconfig/network ファイルに PEERNTP=no を追加します。

4. ntpq -p コマンドを再度実行して、構成を確認します。

   ntpq -p
   

   remote           refid           st t when poll reach   delay   offset  jitter
   ==============================================================================
   *metadata.google 255.28.23.83     2 u   27   64    1    0.634   -2.537   2.285
   

Windows

1. Google Cloud コンソールの [VM インスタンス] ページに移動します。

   [VM インスタンス] に移動

2. 接続する Windows インスタンスの横にある [RDP] ボタンをクリックします。

   

3. ログインした後、PowerShell アイコンを右クリックし、[管理者として実行] を選択します。

   

4. コマンド プロンプトが読み込まれたら、次のコマンドを実行して、現在の NTP 構成を確認します。

   w32tm /query /configuration
   

   [Configuration]
   ...
   Type: NTP (Local)
   NtpServer: metadata.google.internal,
   ...
   

   1 つのレコードが metadata.google か metadata.google.internal を指している場合、変更を加える必要はありません。複数のソース（metadata.google と公開されているソースが一緒に使用されている）が表示されている場合は、外部サーバーを削除する必要があります。NTP サーバーの構成については、Windows のガイドに従ってください。

5. Windows VM で最も広範なソフトウェア互換性を確保するために、gVNIC ドライバを使用して、metadata.google で NTP の精度を 1 ミリ秒未満にすることをおすすめします。

   Windows VM で VirtIO を使用する必要がある場合、NTP サーバーでミリ秒未満の精度を得るには、Windows タイムサービス（w32tm の停止と登録解除）を使用しないことをおすすめします。

   1. Windows タイムサービスを停止します。

      net stop w32time
      

   2. レジストリから Windows タイムサービスを削除します。

      w32tm /unregister
      

   3. Windows タイムサービスが停止し、レジストリから削除されたら、Meinberg NTP クライアントをインストールします。

      Meinberg のドキュメントに記載されている構成手順に沿って操作します。

   4. Meinberg NTP クライアントの NTP サーバーを metadata.google.internal として構成します。

      NTP の構成が完了したら、VM のシステム クロックが NTP サーバーで安定するまで 5 ～ 15 分待ちます。

      w32tm の使用が推奨されない理由については、既知の問題のドキュメントをご覧ください。

Google Cloud外部のシステムでうるう秒の調整を実行する

Google の NTP サーバーの leap smearing 機能は、時間に影響を受けやすいシステムで 1 秒を繰り返すリスクを管理できる便利な方法です。NTP サービスの中には、ほとんどのソフトウェア システムで受け入れることができる回避策を提供しているものがあります。ただし、Google の leap smearing NTP サービスと、公開されている NTP ステッピング サービスを一緒に使用しないでください。

Google Cloud 外のデバイスを「不鮮明にされた（smeared）」時間に同期させるには、それらのデバイスに Google Public NTP を使用します。 Google Public NTP は、Compute Engine VM に提供されるのと同じうるう秒の調整を使用します。

次のステップ

• PCI データ セキュリティ基準の遵守について学習する。
• Google Public NTP に関するよくある質問をご確認ください。