Назад | Перейти на главную страницу

Машина Hyper-V дрейфует во времени, даже с NTP

Решено Проблема заключалась в Hyper-V на этой машине. Я удалил Hyper-V, установил VMware Server, запустил ту же виртуальную машину. Проблемы с синхронизацией времени исчезли (разница <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 имеют точную синхронизацию - ленточная диаграмма показывает разницу менее 100 мс.

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 с, через несколько минут он вернется обратно примерно на 2 секунды. За ночь оно увеличилось с ~ 2 до ~ 5 с. Виртуальная машина Linux внутри 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

Я посмотрел журнал событий, и, кроме предупреждений о синхронизации (после того, как он вышел из синхронизации), других предупреждений нет.

Как я могу решить эту проблему? Это единственная машина, у которой есть эта проблема. Все остальные машины (физические и виртуальные) работают нормально.

Редактировать: Чтобы уточнить: у виртуальной машины (AD1) отключена интеграция, и она синхронизируется с time.nist.gov. AD1 в порядке. Это физическая машина S1, которая не может синхронизироваться с AD1 и постоянно дрейфует. Все остальные физические серверы могут нормально синхронизироваться с AD1.

Обновить Итак, похоже, проблема в запуске виртуальной машины. Часы медленно скользят при выключенной виртуальной машине. При включении сразу начинает терять секунды. Я переключил виртуальную машину на использование только половины ресурсов, и на данный момент это, похоже, немного смягчило ее. Спасибо!

Из вашего описания похоже, что есть реальная проблема с оборудованием RTC (http://en.wikipedia.org/wiki/Real-time_clock) на материнской плате сервера S2.

Гость Hyper-V сначала получает часы от хоста (HYV1), но, поскольку у вас отключена синхронизация времени Hyper-V, он получает все дальнейшие обновления часов от NIST (который работает нормально). Ваша виртуальная машина Linux не интегрирована с Hyper-V, поэтому ей пора из домена, который также работает нормально. Остальные ваши физические машины работают нормально, это всего лишь один физический сервер, дрейф которого составляет 1 секунду каждые 20 секунд (что является сумасшедшим дрейфом). Время дрейфует намного быстрее, чем сетевая синхронизация времени может сбросить часы на правильное время (что, если я правильно помню, происходит каждые 8 ​​часов).

Если вы хотите исключить Hyper-V как причину ошибки на S2, создайте загрузочную запись «без гипервизора», перезагрузитесь без 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 - это включить выключен HyperV обеспечил синхронизацию часов для вашей гостевой машины, а затем используйте adjtimex для настройки времени. В гостевой ОС Ubuntu сделайте это ...

# 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 сможет поддерживать его синхронизацию, потому что он больше не должен сильно смещаться.

Некоторое время мы использовали Hyper-v на Core. Сначала у нас были проблемы с синхронизацией времени ... Я вернулся к лучшей практике из моих старых дней Windows NT.

Смотрю серверы по ОС. Создаю мастер Linux, Router, Windows, Novell.

Возможно, у вас сейчас нет Novell, но потерпите меня.

Каждый «главный» сервер синхронизируется с маршрутизатором. Маршрутизатор на страту. Затем каждый рядовой сервер имеет свой главный сервер ОС и вторичный по отношению к одному из других главных серверов.

  • Linux на маршрутизатор, затем на Novell
  • Novell к маршрутизатору, затем к Windows
  • Windows на маршрутизатор, затем на Linux
  • Маршрутизатор на Stratum, затем на основной коммутатор
  • Основной переключатель на Stratum, затем на маршрутизатор

Последняя часть этой стратегии ... У ВСЕХ есть сервер времени. Если у него нет сервера времени, он не будет подключен к сети. От тостера до телефона переходить от АТС к серверам.

Когда я приступаю к новой работе, я в первую очередь трачу время на отображение сети и установку времени. Затем я могу просто проверить это здесь и там и с этого момента устранить синхронизацию времени как проблему.

Кажется, это очень распространенная проблема с виртуальными машинами. См. Следующие веб-сайты:

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

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

Я предлагаю синхронизировать только с внешним сервером времени и отключить любую синхронизацию времени интеграции.

Надеюсь, это поможет.

Время в виртуальных машинах движется повсюду. Вы действительно хотите убедиться, что сервер NTP не использует локальные часы в каких-либо «серверных» операторах, так как локальные часы слишком ненадежны. Одна вещь, которую я сделал, чтобы помочь, - это установить атрибут «maxpoll» для серверов на виртуальных машинах. Это заставляет службу ntp проверять свои часы восходящего потока гораздо чаще, чем настроено по умолчанию, что помогает поддерживать его в истинном состоянии.

server [timeserver] maxpoll 12

Попробуйте выполнить несколько настроек, чтобы увидеть, как далеко вам нужно зайти, чтобы время было относительно надежным. 12 работает для меня, но каждая среда отличается.

Это может показаться забавным, но держу пари, что у вас многопроцессорная установка? У некоторых производителей есть известные проблемы с уходом часов кашель AMD кашель это случается с многоядерными / многопроцессорными материнскими платами. Активные прерывания - например, запуск одной или двух виртуальных машин - усугубляют дрейф. Дрейф, который вы испытываете, звучит очень подозрительно как это.

Как бы то ни было, я предпочитаю предложения AMD, а не Intel, поэтому не воспринимайте это как удар против них.

Предполагая, что AD1 был контроллером домена, я думаю, что проблема здесь могла быть связана с тем, что ваш сервер Hyper-V установил свое время с одной из своих гостевых виртуальных машин. Вот почему проблема исчезла, когда вы переключились на VMware: сервер VMware не чувствует себя обязанным синхронизировать свои часы с контроллером домена Windows.