☰

仮想マシンで NTP サーバーを実行する場合の制限は何ですか? (2010)

tag-icon • tag-icon virtualization ntp
仮想マシンで NTP サーバーを実行する場合の制限は何ですか? (2010)

ローカル ネットワークに複数の Stratum 2 タイム サーバーをセットアップしたいと考えています。仮想マシンは、1U サーバーを 3 台購入するよりも確実に安価です。これを行うと、どのような制限が課せられますか。つまり、精度にどの程度悪影響があるのでしょうか。

さらに、ハードウェアの不規則性を軽減するために、これらのローカル タイム サーバーは別の物理マシン上に配置する必要があるというのが私の直感です。この直感は正しいでしょうか?

編集 「仮想マシン」という言葉は具体的には平均ヴイエムウェアむしろ、仮想化インスタンスの一般的な概念を意味していました。

答え1

今は2023年であり、この質問に対するこれまでの答えはすべて間違っている(少なくとも 2016 年後半から)、少なくとも Linux VM に関してはそうです。[以下のアドバイスは Windows VM には当てはまらない可能性があります。]

2023 年以降にこの記事を読んでいる場合は、2013 年以前の回答で最大 20 ～ 100 ミリ秒の精度が主張されていることを信じないでください。最新の VM の時刻同期では、LAN 上で 1 ミリ秒未満の精度を実現でき、コンシューマー グレードのインターネット接続では 1 ミリ秒に近い精度を実現できます。

次の ServerFault の質問には、より最新の議論が含まれています。

私の主張を裏付けるために、オフセット グラフの例をいくつか示します (時系列順)。一部のケースでは、生のログ ファイルがまだ残っているので、自分で調べたい方には喜んで提供します。各インスタンスのグラフのスケールに注目してください。

  1. ntpd2016 年後半に KVM ハイパーバイザー (何らかの Intel Xeon 上) の下にある OpenStack プライベート クラウドで 実行されている VM :オフセット-kvm
  2. ntpd2020 年半ばにスタンドアロン KVM ホスト (Intel Celeron 1037U 上) で 実行されている VM :オフセット-KVM-Celeron
  3. 2021 年後半に t3a.micro実行されている AWS (AMD) インスタンスの数:chronydオフセット-aws-t3a
  4. 2021 年後半に t4g.micro実行されている AWS (ARM) インスタンスの数:chronydオフセット-aws-t4g
  5. 2022 年初頭に Standard_B1s実行される Azure (Intel) インスタンスの数:chronydオフセット-Azure-B1S
  6. chronyd2022 年後半に AWS ECS/Fargate (Intel) で 実行されているコンテナの数:オフセットファーゲート

答え2

単純な事実は、2010 年でも VM 内のクロック精度がまだ非常に悪いということです。これはいくつかの点で発生しますが、致命的なのは、時間のずれが一定ではなく、ずれ係数が刻々と変化することです。NTP はクロック補正が組み込まれたプロトコルですが、静的なずれ係数が組み込まれた状態で設計されています。たとえば、物理マシンが 30 日ごとに 12 秒遅れる場合、NTP はそれを補正でき、非常にうまく機能します。しかし、そのマシンが 30 日ごとに 4 秒から 70 秒遅れる場合、NTP はそのレベルの変化を追跡するのがあまり得意ではありません。

VM 環境で NTP が遅れないようにすることが非常に難しいのは、NTP が参照するローカル クロックが 1 分間でドリフト係数を変更する可能性があるためです。親のタイム ソースをチェックする頻度によっては、ドリフト係数が大きく変化し、同期がとれなくなる頻度がはるかに高くなります。同期がとれていない時間は、組織全体に波及します。

ローカル ネットワーク用の NTP は、メモリ使用量が非常に小さく、比較的影響の少ないプロトコルであり、DNS サーバーや DHCP サーバーなどの他のネットワーク インフラストラクチャ サーバーに問題なく連携できます。一部のルーターは NTP 機能も提供できるため、その点も検討するとよいかもしれません。

理想的には、別々の場所に 2 つの別々のサーバーを配置し、それぞれが異なる上位階層のサーバー セットと同期するようにします。両方のタイム サーバーが、もう一方のサーバーを「ピア」として使用するように構成することも非常に良いアイデアです。これにより、上流のタイム ソースの 1 つが故障した場合のタイム サービスへの影響を最小限に抑えることができます。階層は変更されますが、少なくとも同期がずれているとは報告されません。最後に、上流のタイム プロバイダーに配慮し、時間が十分に確立されたら、ポーリングの間隔を非常に長くするようにサーバーを構成します。これは、「server」行の「maxpoll」パラメーターで、同期試行の間隔を秒単位で 2 の累乗で表します。

どうしても VM を使用する必要がある場合は、このような NTP サーバーを 3 つ以上セットアップします。各サーバーは異なるホスト上に、可能であれば異なるデータ センターに配置する必要があります。先ほど提案したように、サーバーには異なるタイム ソースが必要であり、相互にピアリングする必要があります。次に、すべての NTP クライアントが 3 つすべてを親ソースとして使用するように構成します。maxpoll 値が十分に低く、ネットワーク外の同期パケットの間隔が 1 時間半を超えず、ネットワーク内で 30 分を超えないようにしてください。3 つのうち少なくとも 1 つは、常に同期している可能性が高いです。1 つのタイム ホストとしか通信できないクライアントは、時折発生する同期外れイベントを我慢するしかありません。全体として、このシナリオの時間品質は、物理サーバーの場合ほど正確ではありません。

大まかに言うと、純粋な VM 環境でのコンセンサス時間は、おそらく実際の値から 30 ～ 100 ミリ秒以内になると思います。純粋な物理環境では、タイム サーバーが十分な時間稼働して時間が安定すると、コンセンサス時間はおそらく 10 ミリ秒以内になります。

答え3

VMwareのタイムキーピングを見る書類VM で NTP デーモンを実行するのは、特に信頼性の高い時間が必要な場合には、おそらく良い考えではありません。

答え4

仮想化環境で NTP を実行すると、20 ミリ秒の精度を達成できれば幸運です (これは VMware を使用して実現したものです)。仮想化クロックのずれは、特にリソース競合のある仮想化環境では悪影響を及ぼします。

どの程度の精度が必要かによって異なります。秒単位の精度のみを気にする場合 (Web サーバーなど)、リソースの競合がない限り、おそらく問題ないでしょう。ミリ秒単位の精度が必要な場合 (ビジーなデータベース、ログ サーバー、研究プロジェクトなど)、仮想化タイム サーバーは忘れてください。

NTP サーバーは常に物理ホスト上に存在する必要があります。プール内でピアリングするサーバーを少なくとも 3 つ用意する必要があります (これにより、不正なサーバーがプールによって排除されます)。また、可能であれば、インターネット経由ではなく、GPS またはその他のローカル ティア 0 ソースから時間を取得します。

関連情報