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

Синхронизация времени для контроллеров домена, виртуализированных через Hyper-V

Я хотел бы знать, может ли кто-нибудь порекомендовать лучший способ настройки синхронизации времени домена для группы серверов Windows Server 2008 R2, чем тот, который я сейчас настроил. У меня есть три контроллера домена, все они являются гостевыми Hyper-V. Для всех этих контроллеров домена функция синхронизации времени хоста в службах интеграции отключена. Контроллеры домена настроены как полномочные серверы времени, а сервер FSMO DC1 использует общедоступные серверы nist-a и nist-b в качестве источника времени. DC2, DC3 и все другие серверы в этой среде, как хосты, так и гости, являются членами одного домена и обращаются к DC1 в поисках времени. Для всех остальных гостей (т.е. не для контроллеров домена) включена функция синхронизации времени служб интеграции. Причина этого сообщения в том, что я время от времени вижу сообщение, которое следует в следующем абзаце, и я хотел бы, чтобы время всех моих серверов (как хостов, так и гостей) было максимально точным:

Служба времени обнаружила разницу во времени более 5000 миллисекунд за 900 секунд. Разница во времени может быть вызвана синхронизацией с источниками времени с низкой точностью или неоптимальными условиями сети. Служба времени больше не синхронизируется и не может предоставлять время другим клиентам или обновлять системные часы. Когда от поставщика службы времени получена действительная отметка времени, служба времени исправит себя.

Если кто-то имеет аналогичную настройку с виртуализированными контроллерами домена и достиг высокоточной синхронизации времени на всех серверах в домене, ваш вклад будет признателен.

Спасибо.

Да. Не выключайте синхронизацию, КРОМЕ на одном сервере, который фактически также является физическим контроллером домена.

У меня такая же установка, и я убедился, что машина, которая обслуживает время, представляет собой небольшой физический контроллер домена. Все виртуальные DC синхронизируются по времени с Hyper-v.

Реальная опасность - это петля обратной связи между хостом и клиентом, и таким образом петля разрывается.

Это НЕ очень точный BTW - окна никогда не. Только синхронизируется с очень плохой степенью точности. У меня есть другая машина, которая собирает финансовые данные и синхронизируется с мс с внешним хостом (средний перекос в час: 37 мс по статистике);) ЭТО верно.

Самый надежный метод поддержания времени в среде виртуализированного домена - сохранить физический PDC, увеличить частоту синхронизации и устойчивость к дрейфу для всех виртуализированных контроллеров домена и членов домена, а также отключить синхронизацию времени между хостом и гостем для всех рассматриваемых виртуальных машин.

Вот псевдо-объяснение проблемы (я давно не смотрел на это):

Когда машина (рабочая станция, сервер, виртуальная машина) запускается, она считывает время с RTC (микросхема часов с батарейным питанием на материнской плате / BIOS) и вычисляет продолжительность каждого такта ЦП. Затем ОС считает количество тактов часов, которые произошли с момента снятия первоначального показания, и добавляет время от этого времени к исходному считыванию времени, полученному при загрузке. Это дает вам текущее время.

Проблема в том, что хосты скрывают истинные тактовые циклы виртуальных машин. Виртуальная машина могла иметь 100 тактовых циклов, когда на хосте фактически произошло 500 тактовых циклов. Таким образом, этот метод расчета времени не работает, и время на виртуальной машине выходит из строя.

Синхронизация времени между хостом и гостем с помощью установленных пакетов инструментов / расширений vm в vSphere и Hyper-V в некоторой степени исправляет это, но они не идеальны (в некоторых настройках они могут вытащить виртуальную машину вперед, если она отстает от реального времени, но они не перескакивайте виртуальную машину вперед, если она опережает реальное время).

Это усложняется еще и тем, что тактовые циклы подсчитываются в многоядерных установках (счетчик времени по существу эмулируется на каждом ядре) и на установках, которые могут изменять тактовые частоты на лету (я понятия не имею, как это поддерживается). Учитывайте идею о том, что виртуальная машина может выполнять один тактовый цикл на одном ядре, а затем переходить на другое ядро. на другом процессоре для следующего цикла, и это становится действительно ужасно.

Итак, вернемся к исходной точке: время домена по умолчанию начинается с основного контроллера домена, затем переходит к другим контроллерам домена, а оттуда - к рядовым серверам и рабочим станциям. Таким образом, если вы убедитесь, что ваш PDC является действительно надежным источником времени (сохраняя его физическим), и отключите синхронизацию хост-гость для всех других членов домена, вы обеспечите стабильную и относительно точную инфраструктуру времени.

Обратите внимание, что запуск вашего PDC в качестве физического сервера, а затем включение Hyper-V на этом сервере и добавление к нему некоторых гостей, вероятно, также не является подходящим решением, поскольку я считаю, что при включении Hyper-V `` базовая '' ОС фактически становится виртуализированной. ОС тоже (тихо). Так что используйте один физический сервер в качестве основного контроллера домена и не используйте Hyper-V.

Интересное замечание: официальная позиция Microsoft в отношении синхронизации времени Windows, даже с использованием совместимой службы NTP, которая была встроена в Windows с XP / 2003, составляет 15 секунд. На практике вы можете снизить его до менее 100 мс, но все, что они поддерживают, - это синхронизация с точностью до 15 секунд. Вроде логично, единственный чувствительный ко времени ключевой компонент в ядре большинства сред MS - это Kerberos, и по умолчанию он будет работать нормально, пока вы находитесь в пределах 5-минутного допуска.