Окружающая среда:
Как вы думаете, что является лучшим подходом к синхронизации времени фермы Hyper-V с контроллерами AD в качестве гостей? Получилось 2 плана :)
какой источник времени лучше всего подходит для серверов Hyper-V?
План 1
План 2 (Я думаю о реализации этого, потому что уровень гипервизора не будет зависеть от гостевого PDC)
Может у кого-то попался хороший вариант №3?
С одной стороны, это интересный вопрос, но с другой стороны, он может быть в первую очередь основанным на мнении. На самом деле нет единого способа сделать это. У вас есть варианты, и многие из них также действительны.
Из чтения сообщений в блогах вроде вот этот, складывается впечатление, что даже сотрудники Microsoft разрываются по этому поводу:
Наша первоначальная рекомендация заключалась в том, чтобы отключить синхронизацию времени и оставить на усмотрение собственных функций DC синхронизацию времени с другими DC.
Какое-то время я следовал этому совету без каких-либо негативных последствий, потому что мне было настолько комфортно работать с NTP и синхронизацией времени в домене AD, что я чувствовал, что синхронизация времени Hyper-V только мешает. У меня это сработало.
Но Бен Армстронг, менеджер программы Hyper-V, говорит следующее:
Вопрос №8 - Когда мне следует отключить службу синхронизации времени Hyper-V (в настройках виртуальной машины или внутри гостевой операционной системы)?
Никогда.
Определенно есть моменты, когда вы захотите расширить функциональность служб интеграции времени Hyper-V с помощью удаленного источника времени (будь то источник домена или внешний сервер времени), но это единственный способ получить наилучшие впечатления от загрузки виртуальной машины / restore - оставить включенными службы интеграции времени Hyper-V.
Когда я запускаю следующие команды на виртуализированном гостевом компьютере Win8.1 (присоединенном к домену AD, чьи контроллеры домена также виртуализированы, а службы интеграции синхронизации времени включены на всех) на Hyper-V 2012 R2, я вижу следующее:
C:\>w32tm /query /source
VM IC Time Synchronization Provider
C:\>w32tm /query /peers
#Peers: 1
Peer: DC01.labs.myotherpcisacloud.com
State: Active
Time Remaining: 254.6744551s
Mode: 3 (Client)
Stratum: 2 (secondary reference - syncd by (S)NTP)
PeerPoll Interval: 10 (1024s)
HostPoll Interval: 10 (1024s)
Вывод кажется противоречивым.
И этот парень Переговоры о частично отключение синхронизации времени для гостей вашего домена с помощью настройки реестра для всех членов вашего домена. Но я лично избегаю такого подхода. Меня это беспокоит, когда я захожу в чужую среду (без сомнения, чтобы исправить их проблемы с синхронизацией времени), и я вижу, что они вручную перенастроили службу времени Windows каждого отдельного члена домена. Оставь это в покое, это мой девиз.
Вот мой личный контрольный список:
Оставьте везде включенной службу интеграции синхронизации времени.
Предполагая, что все контроллеры домена являются виртуальными машинами, настройте контроллер домена PDCE корневого леса для синхронизации с внешним источником времени, например * .pool.ntp.org. PDCE вашего корня леса должен быть единственным компьютером в вашем лесу AD, настроенным для обращения к внешнему источнику времени. Все остальные члены домена и контроллеры домена будут органически определять местонахождение контроллера домена с помощью традиционных механизмов Windows Time.
Настройте хосты Hyper-V так, чтобы они указывали на тот же внешний источник (и) времени, что и корневой PDCE виртуализированного леса. Независимо от того, присоединены ли ваши узлы Hyper-V к одному домену или нет, вы хотите, чтобы они могли достичь надежного источника времени, если виртуализированные контроллеры домена, работающие внутри них, не работают.
Это отлично работает ... это не единственный способ снять шкуру с кошки, но он отлично работает.
После нескольких проблем с синхронизацией времени на Hyperv я рекомендую, если возможно, использовать один физический контроллер домена в качестве эмулятора PDC, синхронизирующегося с внешним источником времени. Это может быть старый устаревший сервер, так как он не будет много использоваться (мой также использует dhcp и dns на довольно старом оборудовании).
Это также помогает избежать проблем, если все контроллеры домена работают в одном гипервокластере. В случае сбоя кластера узлы теперь являются серверами, присоединенными к домену, без доступного контроллера домена, что может вызвать проблемы. Конечно, есть и другие способы избежать этой конкретной проблемы.
В противном случае перейдите к плану 1 и убедитесь, что он синхронизируется с NTP довольно часто. Лучше всего, чтобы все системы, присоединенных к домену, синхронизировались из одного источника. Неправильное время будет раздражать людей. РАЗЛИЧНОЕ время между системами может нарушить аутентификацию и вызвать проблемы со входом
Я бы использовал Plan 1. Члены DC и домена должны синхронизироваться с иерархией домена (за исключением эмулятора PDC корня леса, который должен использовать внешний источник времени).
Вот приоритеты в порядке важности:
Если вы запустите w32tm / query / status / verbose, "Источник:" должен никогда отобразите «Local CMOS Clock» или «Free-Running System Clock».