NTP サーバを vSphere 上の仮想マシンとして構築する
ことは推奨されていませんでしょうか。
Red Hat の記事ではそのような事が記載されてますが、
vSphere における類似記事が見当たらずご存知でしたら
ご教示いただけますと幸いです。
<Red Hat 記事>
・仮想マシンの NTP サーバーが信頼できる NTP サービスを提供することはできますか?
https://access.redhat.com/ja/solutions/2914311
・19.7. 仮想マシン上での時間管理
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/system_administrators_...
結局のところ、ESXi からのリソース割り当て待ち等が発生
し得るような場合などには NTP サーバ自体の時刻ズレが
起こる可能性があるため、推奨されないといった認識で
間違えないでしょうか。
(上位の NTP に物理のちゃんとしたものを置いておけば
問題なし....?)
逆に仮想マシン上に NTP を構築することは問題ないという
ことであれば、そのような記事等をご教示いただけますと
幸いです。
厳密な精度の時刻管理が求められる場合は専用の物理 NTP アプライアンスや PTP を仮想環境とは別の外部に用意するのが好ましいですが、
参照先で外部の NTP ソースから正しい時刻を同期できていれば大きな問題は起きないと思います。
※ 精度の高い時刻管理が求められる場合は専用アプライアンスなどの利用が推奨なことは確実です。
CPU リソースの割当や、仮想マシンのホスト間の移動による NTP サーバー VM そのものの時刻のズレが起きにくくするために、
DRS での自動 vMotion の対象外にしたり、
遅延感度の調整 や 仮想マシンでの仮想ハイパースレッドのサポート の設定などで CPU 割当の専有を利用することも有効かもしれません。
※ 上記設定利用する場合は DRS の自動移行対象から外れます。
Redhat の KB は私のアカウントではアクセスできませんでした。
Product Documentの記載では以下の部分が根拠となっていますね。
仮想マシンは実際のハードウェアクロックにアクセスできず、仮想クロックの安定性はホストシステムの作業量に依存することから、十分な安定性がありません。 |
ESXiの仮想化においては以下のドキュメントにもある通り、タイマーデバイスも仮想化されているため、Guest OSが直接ハードウェアクロックを参照することは無いようです
Timekeeping in VMware Virtual Machines
ドキュメント自体が古いため現在では当てはまらない可能性もありますが、資料中ではTSCなどのCPU 割り込みが発生しない仕組みであっても、遅延する可能性について示されております。
NTPを利用すれば、より正確に時刻同期をすることができますが、NTPの同期間隔のカウントにも仮想タイマーデバイスが利用されていると考えると、物理マシン上のOSのほうが精度は高いと考えられます。
仮想化によって仮想タイムデバイスが提供する時刻がリアルタイムとどれくらいズレるのかについては環境に依存しますので実際に測定してみていただくくらいしかないと思います。
NTPを利用する場合はNTP自体の精度の考慮も必要かと思います。
Wikiの記載ではNTPはLAN内でミリSec程度、PTPであればサブマイクロSec程度の精度だと記載があります。
Precision Time Protocol - Wikipedia
Network Time Protocol - Wikipedia
そもそもNTPでも精度が足りないということであればPTPを検討いただくのが良いでしょう。
PTPについては以下のブログが参考になります。
プレシジョンクロックデバイスで ESXi とゲストOSを時刻同期 | vSoliloquy (jangari-ntk.github.io)
ここからは完全に私見となりますが、仮想化(CPU時間のスケジューリング等)による時刻のズレを気にするよりも、vMotionやSnapshotに起因する瞬間的なフリーズが作り出すズレを修正するための時間のほうが問題になるのではないかと思います。
以下の記事によるとNTPのSkewモードでは1秒の誤差を直すのに2000秒もかかるとあります。
時刻の後戻りを発生させずにシステム全体の時刻を確実に同期させたい | 日経クロステック(xTECH) (nikkei.com)
実際に仮想マシンのvMotionやSnapshotなどで1秒もフリーズするようなことはほぼ起こりえないと思いますが、もし何かの拍子にずれが発生してしまうとそれを修正するのに何倍もの時間がかかってしまいますので、信頼のある時刻同期が必要な場合は専用の物理サーバで用意するのが良いとおもいます。
逆に数秒くらいのズレを許容できるような環境であれば仮想マシン(NTP同期)でも問題ないと思います。
結局のところはNTP Client側でどの程度正確な時刻同期が要求されるのかが一番重要ですね。
厳密な精度の時刻管理が求められる場合は専用の物理 NTP アプライアンスや PTP を仮想環境とは別の外部に用意するのが好ましいですが、
参照先で外部の NTP ソースから正しい時刻を同期できていれば大きな問題は起きないと思います。
※ 精度の高い時刻管理が求められる場合は専用アプライアンスなどの利用が推奨なことは確実です。
CPU リソースの割当や、仮想マシンのホスト間の移動による NTP サーバー VM そのものの時刻のズレが起きにくくするために、
DRS での自動 vMotion の対象外にしたり、
遅延感度の調整 や 仮想マシンでの仮想ハイパースレッドのサポート の設定などで CPU 割当の専有を利用することも有効かもしれません。
※ 上記設定利用する場合は DRS の自動移行対象から外れます。
Redhat の KB は私のアカウントではアクセスできませんでした。
Product Documentの記載では以下の部分が根拠となっていますね。
仮想マシンは実際のハードウェアクロックにアクセスできず、仮想クロックの安定性はホストシステムの作業量に依存することから、十分な安定性がありません。 |
ESXiの仮想化においては以下のドキュメントにもある通り、タイマーデバイスも仮想化されているため、Guest OSが直接ハードウェアクロックを参照することは無いようです
Timekeeping in VMware Virtual Machines
ドキュメント自体が古いため現在では当てはまらない可能性もありますが、資料中ではTSCなどのCPU 割り込みが発生しない仕組みであっても、遅延する可能性について示されております。
NTPを利用すれば、より正確に時刻同期をすることができますが、NTPの同期間隔のカウントにも仮想タイマーデバイスが利用されていると考えると、物理マシン上のOSのほうが精度は高いと考えられます。
仮想化によって仮想タイムデバイスが提供する時刻がリアルタイムとどれくらいズレるのかについては環境に依存しますので実際に測定してみていただくくらいしかないと思います。
NTPを利用する場合はNTP自体の精度の考慮も必要かと思います。
Wikiの記載ではNTPはLAN内でミリSec程度、PTPであればサブマイクロSec程度の精度だと記載があります。
Precision Time Protocol - Wikipedia
Network Time Protocol - Wikipedia
そもそもNTPでも精度が足りないということであればPTPを検討いただくのが良いでしょう。
PTPについては以下のブログが参考になります。
プレシジョンクロックデバイスで ESXi とゲストOSを時刻同期 | vSoliloquy (jangari-ntk.github.io)
ここからは完全に私見となりますが、仮想化(CPU時間のスケジューリング等)による時刻のズレを気にするよりも、vMotionやSnapshotに起因する瞬間的なフリーズが作り出すズレを修正するための時間のほうが問題になるのではないかと思います。
以下の記事によるとNTPのSkewモードでは1秒の誤差を直すのに2000秒もかかるとあります。
時刻の後戻りを発生させずにシステム全体の時刻を確実に同期させたい | 日経クロステック(xTECH) (nikkei.com)
実際に仮想マシンのvMotionやSnapshotなどで1秒もフリーズするようなことはほぼ起こりえないと思いますが、もし何かの拍子にずれが発生してしまうとそれを修正するのに何倍もの時間がかかってしまいますので、信頼のある時刻同期が必要な場合は専用の物理サーバで用意するのが良いとおもいます。
逆に数秒くらいのズレを許容できるような環境であれば仮想マシン(NTP同期)でも問題ないと思います。
結局のところはNTP Client側でどの程度正確な時刻同期が要求されるのかが一番重要ですね。
追加ですみません。
ちなみになのですが、ESXi / vCenter Server に仮想マシン上の NTP
を参照させるような構成は問題ありますでしょうか。
仮想マシン上のNTPが信頼のおける上位NTPと同期しているのであれば問題はないと思います。
vCenterやESXiであれば動作的には数秒のズレが発生したとしても許容範囲と思います。
障害調査時にログのタイムスタンプがズレてしまって前後関係がわかりにくくなるようなことはあるかもしれません。