web-dev-qa-db-ja.com

Hyper-Vマシンは、NTP

解決済み問題はそのマシンの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を押すと、リソースの半分しか使用されません。とりあえず、少し緩和してくれてありがとう。

windowswindows-server-2008hyper-vntptime-synchronization
10
MichaelGG

あなたの説明から、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

-ショーン

5
Sean Earp

問題は、さまざまなクロックソース（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はあまりドリフトしないため、同期を保つことができます。

3
Matt Keenan

これは、VMの非常に一般的な問題のようです。次のWebサイトを参照してください。

http://www.vmwareinfo.com/2008/04/enabling-ntp-on-esx-servers.html

http://social.technet.Microsoft.com/Forums/en-US/winserverhyperv/thread/6fff3eef-1b5b-4059-8618-22ab3f5c293c

私の提案は、外部のタイムサーバーとのみ同期し、統合時間の同期を無効にすることです

うまくいけば、これが役立ちます。

2
rmwetmore

コアでHyper-vをしばらく実行しています。最初は、時間同期の問題がありました.....私は、古いWindows NT時代のベストプラクティスに戻しました。

サーバーはOSごとに見ています。 Linux、ルーター、Windows、Novellマスターを作成します。

あなたは今ノベルを持っていないかもしれませんが、私と一緒に耐えます。

各「マスター」サーバーはルーターと同期します。ストラタムへのルーター。次に、各メンバーサーバーには、マスターOSサーバーと、他のマスターのいずれかのセカンダリがあります。

  • Linuxからルーター、次にNovell
  • Novellからルーターへ、次にWindowsへ
  • Windowsからルーターへ、次にLinuxへ
  • ルータをStratum、次にコアスイッチに
  • Stratum、次にルーターへのコアスイッチ

この戦略の最後の部分は...すべてにタイムサーバーがあります。タイムサーバーがない場合は、ネットワークに接続されません。トースターから電話に切り替えるPBX to server.

これは、新しい仕事にたどり着いたときに最初に行うことの1つは、ネットワークをマップして時間を設定する時間を費やすことです。その後、あちこちで確認して、その時点から問題として時間同期を排除できます。

2
Thomas Denton

面白そうに聞こえるかもしれませんが、マルチプロセッサセットアップを実行しているのではないでしょうか。 特定の製造元には既知のクロックドリフトの問題がありますcoughAMDcoughマルチコア/マルチソケットのマザーボードで発生します。たとえば、1つまたは2つの仮想マシンを実行するなど、割り込みアクティビティが多いと、ドリフトが悪化します。このような音が非常に疑わしく発生しているドリフト。

価値があるので、私はIntelよりもAMDの製品を好むので、これをノックとして受け取らないでください。

1
Avery Payne

VM内のあらゆる場所で時間がドリフトします。 NTPサーバーが 'server'ステートメントでローカルクロックを使用していないことを確認してください。ローカルクロックの信頼性が低すぎるためです。 VMedマシン上のサーバーの「maxpoll」属性を設定します。これにより、ntpサービスは、設定されたデフォルトよりもはるかに頻繁にアップストリームクロックをチェックするように強制され、trueを維持できます。

server [timeserver] maxpoll 12

いくつかの設定を試して、比較的信頼できる時間を維持するために必要な距離を確認します。 12でうまくいきますが、環境はそれぞれ異なります。

1
sysadmin1138

AD1がドメインコントローラーであると仮定すると、ここでの問題は、Hyper-Vサーバーが独自のゲストVMの1つから時間を設定していることに関連している可能性があります。これが、VMwareに切り替えたときに問題がなくなった理由です。VMwareサーバーは、そのクロックをWindowsドメインコントローラーと同期させる必要がありません。

1
Skyhawk