解決済み問題はそのマシンのHyper-Vでした。 Hyper-Vを削除し、VMware Serverをインストールして、同じVMを実行しました。時間同期の問題は解消されました(1日後に100ミリ秒未満の差)。
私の設定は次のとおりです:
HYV1 - HyperV machine (non domain) - sync irrelevant
AD1 - VM AD server on HYV1, sync'd to time.nist.gov. HyperV time sync off.
S1 - Physical machine, sync'd to domain.
S2 - Physical machine running HyperV, sync'd to domain.
V1 - Linux VM machine on S2, sync'd to AD1. No HyperV integration.
AD1とS1の同期は良好です-ストリップチャートは100ms未満の差を示します。
S2は狂ったようにドリフトします。 AD1に対するストリップチャートの一部を以下に示します。
18:33:22 d:+00.0010138s o:+05.4101899s
18:33:24 d:+00.0010138s o:+05.4319765s
18:33:26 d:+00.0000000s o:+05.4788429s
18:33:28 d:+00.0000000s o:+05.6089942s
18:33:30 d:+00.0010138s o:+05.7240269s
18:33:32 d:+00.0000000s o:+06.0421911s
18:33:34 d:+00.0081104s o:+06.5613708s
18:33:37 d:+00.0000000s o:+06.9096594s
18:33:39 d:+00.0000000s o:+06.8867838s
18:33:41 d:+00.0010127s o:+06.8936401s
20秒で、1秒以上ドリフトしました。手動で1秒以内にリセットした場合、数分以内に約2秒ドリフトします。一晩で2秒から5秒になりました。 Linux VM S2内はAD1と完全に同期しています。
これが設定です:
C:\Users\mgg>w32tm /dumpreg /subkey:Parameters
Value Name Value Type Value Data
------------------------------------------------------------
ServiceDll REG_EXPAND_SZ %systemroot%\system32\w32time.dll
ServiceMain REG_SZ SvchostEntry_W32Time
ServiceDllUnloadOnStop REG_DWORD 1
Type REG_SZ NT5DS
NtpServer REG_SZ ad01.mydomain ad02.mydomain
C:\Users\mgg>w32tm /dumpreg /subkey:Config
Value Name Value Type Value Data
-----------------------------------------------------------
FrequencyCorrectRate REG_DWORD 4
PollAdjustFactor REG_DWORD 5
LargePhaseOffset REG_DWORD 50000000
SpikeWatchPeriod REG_DWORD 900
LocalClockDispersion REG_DWORD 9
HoldPeriod REG_DWORD 5
PhaseCorrectRate REG_DWORD 1
UpdateInterval REG_DWORD 30000
EventLogFlags REG_DWORD 2
AnnounceFlags REG_DWORD 5
TimeJumpAuditOffset REG_DWORD 28800
MinPollInterval REG_DWORD 2
MaxPollInterval REG_DWORD 8
MaxNegPhaseCorrection REG_DWORD -1
MaxPosPhaseCorrection REG_DWORD -1
MaxAllowedPhaseOffset REG_DWORD 300
イベントログを確認したところ、同期に関する警告(同期が外れた後)を除いて、他に警告はありません。
これをトラブルシューティングするにはどうすればよいですか?この問題が発生している唯一のマシンです。他のすべてのマシン(物理および仮想)は正常に動作しています。
編集:明確にするためにVM(AD1)は統合がオフになっており、time.nist.govに同期しています。AD1は問題ありません。物理マシンS1は、他のすべての物理サーバーはAD1に正常に同期できます。
更新つまり、VMの実行に問題があるようです。時計はVMオフの状態でゆっくりスリップします。オンにすると、すぐに秒の損失が始まります。VMを押すと、リソースの半分しか使用されません。とりあえず、少し緩和してくれてありがとう。
あなたの説明から、RTC( http://en.wikipedia.org/wiki/Real-time_clock )に実際のハードウェアの問題があるようですサーバーS2のマザーボード。
Hyper-Vゲストは、最初にホスト(HYV1)からクロックを取得しますが、Hyper-Vの時刻同期を無効にしているため、NIST(これは正常に機能しています)からさらにすべてのクロック更新を取得します。 Linux VMはHyper-Vと統合されていないため、ドメインからの時間を取得しています。これも正常に機能しています。他の物理マシンは正常に機能しています。単一の物理マシンです。 20秒ごとに1秒のドリフトがあるサーバー(これは、狂った量のドリフトです)。ネットワークの時刻同期がクロックを適切な時刻にリセットできるよりもはるかに速く時刻がずれています(正しくリコールすると、8回ごとに行われます)時間)。
S2のエラーの原因としてHyper-Vを除外する場合は、「ハイパーバイザなし」のブートエントリを作成し、Hyper-Vなしで再起動して、時間のずれが続くかどうかを確認します。ここでの手順: http://blogs.msdn.com/virtual_pc_guy/archive/2008/04/14/creating-a-no-hypervisor-boot-entry.aspx
-ショーン
問題は、さまざまなクロックソース(tsc、jiffies、acpi_pm、cmos_trc)の仮想実装にあります。 HyperVでこの問題を修正するために私が見つけた最良の方法は、ゲストマシンのHyper-V提供のクロック同期をoffにしてから、adjtimexを使用して時刻を調整することです。 UbuntuゲストOSでは次のようにします...
# rm /var/log/clocks.log
# /etc/init.d/ntp-server stop
# ntpdate ntp.ubuntu.com
# hwclock -u --systohc
# adjtimex -l -u -h ntp.ubuntu.com
両方の質問に「いいえ」と答えます
# while [ /bin/true ] ; do yes | adjtimex -l -u -h ntp.ubuntu.com ; sleep 60 ; done
キャリブレーションのために数時間実行するには、そのままにしておき、Ctrl-Cを押して終了します。
# adjtimex -r -a -u -h ntp.ubuntu.com
これはあなたの時計の最小二乗分析を行い、適切な調整を見つけるでしょう
# ntpdate ntp.ubuntu.com
# hwclock -u --systohc
# /etc/init.d/ntp-server start
これにより、マシンの時刻が再同期され、ntpはあまりドリフトしないため、同期を保つことができます。
これは、VMの非常に一般的な問題のようです。次のWebサイトを参照してください。
http://www.vmwareinfo.com/2008/04/enabling-ntp-on-esx-servers.html
私の提案は、外部のタイムサーバーとのみ同期し、統合時間の同期を無効にすることです
うまくいけば、これが役立ちます。
コアでHyper-vをしばらく実行しています。最初は、時間同期の問題がありました.....私は、古いWindows NT時代のベストプラクティスに戻しました。
サーバーはOSごとに見ています。 Linux、ルーター、Windows、Novellマスターを作成します。
あなたは今ノベルを持っていないかもしれませんが、私と一緒に耐えます。
各「マスター」サーバーはルーターと同期します。ストラタムへのルーター。次に、各メンバーサーバーには、マスターOSサーバーと、他のマスターのいずれかのセカンダリがあります。
この戦略の最後の部分は...すべてにタイムサーバーがあります。タイムサーバーがない場合は、ネットワークに接続されません。トースターから電話に切り替えるPBX to server.
これは、新しい仕事にたどり着いたときに最初に行うことの1つは、ネットワークをマップして時間を設定する時間を費やすことです。その後、あちこちで確認して、その時点から問題として時間同期を排除できます。
面白そうに聞こえるかもしれませんが、マルチプロセッサセットアップを実行しているのではないでしょうか。 特定の製造元には既知のクロックドリフトの問題がありますcoughAMDcoughマルチコア/マルチソケットのマザーボードで発生します。たとえば、1つまたは2つの仮想マシンを実行するなど、割り込みアクティビティが多いと、ドリフトが悪化します。このような音が非常に疑わしく発生しているドリフト。
価値があるので、私はIntelよりもAMDの製品を好むので、これをノックとして受け取らないでください。
VM内のあらゆる場所で時間がドリフトします。 NTPサーバーが 'server'ステートメントでローカルクロックを使用していないことを確認してください。ローカルクロックの信頼性が低すぎるためです。 VMedマシン上のサーバーの「maxpoll」属性を設定します。これにより、ntpサービスは、設定されたデフォルトよりもはるかに頻繁にアップストリームクロックをチェックするように強制され、trueを維持できます。
server [timeserver] maxpoll 12
いくつかの設定を試して、比較的信頼できる時間を維持するために必要な距離を確認します。 12でうまくいきますが、環境はそれぞれ異なります。
AD1がドメインコントローラーであると仮定すると、ここでの問題は、Hyper-Vサーバーが独自のゲストVMの1つから時間を設定していることに関連している可能性があります。これが、VMwareに切り替えたときに問題がなくなった理由です。VMwareサーバーは、そのクロックをWindowsドメインコントローラーと同期させる必要がありません。