Виртуализация контроллеров домена с помощью Hyper-V

• Применяется к:

  ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

Windows Server 2012 и более поздних версий поддерживают виртуализированные контроллеры домена (DCs) с защитой, чтобы предотвратить откат номера обновления (USN) на виртуальных контроллерах домена и возможность клонировать виртуальные контроллеры домена. Виртуализация объединяет различные роли сервера на одном физическом компьютере. Дополнительные сведения см. в разделе "Безопасная виртуализация домен Active Directory служб (AD DS)".

В этом руководстве описывается, как запускать контроллеры домена как 32-разрядные или 64-разрядные гостевые операционные системы.

Планирование виртуализации

В следующих разделах содержатся рекомендации по планированию, которые следует учитывать при виртуализации контроллера домена, включая требования к оборудованию, архитектуру, конфигурацию и управление безопасностью и производительностью.

Требования к Hyper-V

Чтобы установить и использовать роль Hyper-V, оборудование должно соответствовать следующим требованиям:

• У вас должен быть процессор x64.

• Процессор должен позволить включить функцию виртуализации с поддержкой оборудования.

  • Обычно этот параметр называется технологией Виртуализации Intel (Intel VT) или расширенной виртуализацией микро устройств (AMD-V).

• Процессор должен поддерживать защиту от аппаратного выполнения данных (DEP).

  • Вы можете использовать Hyper-V только при включении бита отключения выполнения Intel (XD) или бита AMD без выполнения (NX).

Избегайте отдельных точек сбоя

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

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

• Запустите по крайней мере два виртуализированных контроллера домена на разных узлах виртуализации. Эта конфигурация снижает риск потери всех контроллеров домена, если узел виртуализации перестает работать.

• Диверсификация оборудования, на котором выполняются ваши контроллеры домена. Например, используйте разные ЦП, материнской платы, сетевые адаптеры и т. д. Разнородное оборудование предотвращает повреждение устройства и оборудования или конфигурации поставщика.

• По возможности запустите контроллеры домена на оборудовании, расположенном в разных регионах. Этот подход снижает последствия стихийных бедствий, влияющих на один из сайтов, на которых размещаются ваши контроллеры домена.

• Добавьте физические контроллеры домена во все домены. При настройке системы физические контроллеры домена не позволяют хост-системам возникать сбои платформы виртуализации.

Вопросы безопасности

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

При планировании виртуализации контроллера домена следует учитывать следующие рекомендации по безопасности:

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

• Рекомендуется настроить систему на узле, на котором запущена установка основных серверных компонентов Windows Server без приложений, кроме Hyper-V. Эта конфигурация ограничивает количество установленных на сервере приложений и серверов. Это ограничение приводит к повышению производительности системы, а также приводит к снижению производительности атаки, в которой меньше точек входа для вредоносных атак с помощью приложений и служб.

• Для филиалов или других расположений, которые трудно защитить, рекомендуется использовать контроллеры домена только для чтения (RODCs). Если у вас есть отдельная сеть управления, рекомендуется подключить узел только к сети управления. Дополнительные сведения о контроллерах домена windows Server Active Directory (RODC) (уровень 200) см. в разделе "Установка контроллера домена только для чтения Windows Server Active Directory" (уровень 200).

• Вы можете защитить компьютеры с помощью BitLocker. В Windows Server 2016 и более поздних версий можно также использовать функцию виртуального доверенного платформенного модуля (TPM), которая предоставляет материал гостевого ключа, необходимый для разблокировки системного тома.

• Защищенные структуры и экранированные виртуальные машины могут предоставлять другие элементы управления для защиты контроллеров домена.

Дополнительные сведения о защите контроллеров домена см. в руководстве по защите установок Active Directory.

Границы безопасности для конфигураций узлов и гостей

Виртуальные машины можно реализовать во многих различных типах конфигураций контроллера домена. Поэтому необходимо тщательно рассмотреть, как эти виртуальные машины влияют на границы и доверие в топологии Active Directory. В следующем списке описаны две конфигурации, которые можно настроить для контроллеров домена Active Directory и узлов на сервере Hyper-V и гостевых компьютерах, работающих на сервере Hyper-V:

• Узел, который является рабочей группой или компьютером-участником с гостевым контроллером домена.
• Узел, который является рабочей группой или компьютером-членом с гостевым компьютером, который также является рабочей группой или компьютером-членом.

На следующей схеме показана конфигурация трех гостевых виртуальных машин контроллера домена, размещенных на сервере Hyper-V.

Схема примера развертывания трех виртуальных машин (виртуальных машин) и сервера Hyper-V. Три виртуальных машины находятся внутри синего прямоугольника с меткой "гостевые компьютеры". Все три виртуальные машины являются контроллерами домена. Виртуальная машина 1 находится в домене Corp и в лесу Contoso.com. VM2 находится в домене Fabrikam и лесу Fabrikam.com. Виртуальная машина 3 находится в домене HQ и лесу Fineartschool.net. Сервер Hyper-V находится за пределами синего прямоугольника. Это сервер-член, расположенный в домене Corp и лесу Contoso.com.

На основе примера конфигурации на предыдущей схеме ниже приведены некоторые важные аспекты, которые следует учитывать при планировании развертывания следующим образом:

• Доступ администратора

  • Учетные данные администратора на хост-компьютере должны рассматриваться так же, как и у администратора домена на записываемом контроллере домена. Для гостя RODC учетные данные администратора хост-компьютера должны рассматриваться так же, как и у локального администратора в гостевом RODC.

• Права администратора контроллера домена на хост-компьютере

  • Администратор виртуализированного контроллера домена имеет права администратора на узле при присоединении узла к тому же домену. Однако эта привилегия доступа также может предоставить злоумышленникам возможность компрометировать все виртуальные машины, если они могут получить доступ к виртуальной машине 1. Этот сценарий создает возможный вектор атаки. Этот вектор атаки можно предотвратить, убедившись, что все контроллеры домена, настроенные для нескольких доменов или лесов, имеют доверенный домен централизованного администрирования всеми доменами, и сделать узел виртуализации членом домена с высоким уровнем привилегий. Такой подход предотвращает управление узлом и другими доменами отдельных администраторов домена.

• Предотвращение атак

  • Злоумышленники могут атаковать виртуальную машину 1, даже если установить ее как RODC. Хотя администраторы RODC явно не имеют прав администратора домена, они по-прежнему могут использовать RODC для применения политик к хост-компьютеру. Эти политики могут включать скрипты запуска, например. Если злоумышленник находит способ получить права администратора RODC и отправить политику с вредоносным скриптом запуска, он может скомпрометировать главный компьютер и использовать его для компрометации других виртуальных машин на узле.

• Безопасность файлов виртуального жесткого диска (VHD)

  • VHD-файлы для виртуального контроллера домена похожи на физический жесткий диск физического контроллера домена. Вы должны быть так же осторожны, чтобы защитить VHD-файл, как и с жестким диском. Убедитесь, что доступ к этим файлам VHD разрешен только надежным и доверенным администраторам.

• КОНТРОЛЛЕРЫ контроллеров домена

  • Вы можете разместить контроллеры домена в местах, где физическая безопасность не гарантируется, например филиалы. Вы можете защитить свои VHD-файлы с помощью шифрования диска Windows BitLocker от атак на узел, в котором участвует кража физического диска. Однако эти защиты не применяются к файловыми системам внутри RODC.

Замечания, связанные с быстродействием

64-разрядная архитектура Microkernel имеет лучшую производительность Hyper-V на предыдущих платформах виртуализации.

Производительность виртуальной машины зависит от используемой рабочей нагрузки. Мы рекомендуем протестировать определенные топологии виртуальных машин, чтобы убедиться, что вы удовлетворены производительностью развертывания Active Directory. Вы можете оценить производительность в рамках рабочих нагрузок за определенный период времени с помощью таких средств, как надежность и Монитор производительности (Perfmon.msc) или набор средств microsoft Assessment and Planning (MAP). Средство MAP также помогает выполнять инвентаризацию всех серверов и ролей сервера в сети.

Чтобы получить представление о том, как работает тестирование производительности виртуализированного контроллера домена, мы создали пример теста производительности с помощью средства тестирования производительности Active Directory (ADTest.exe).

Тесты протокола LDAP выполняются на физическом контроллере домена ADTest.exe. Те же тесты выполнялись на виртуализированном контроллере домена, состоящем из виртуальной машины, размещенной на сервере, идентичной физическому контроллеру домена. В этом примере используется только один логический процессор для физического компьютера и только один виртуальный процессор для виртуальной машины. Эта конфигурация позволяет развертыванию легко достичь 100 процентов использования ЦП.

В следующей таблице перечислены результаты теста для физических и виртуальных контроллеров домена. Буквы и цифры в скобках рядом с именами тестов являются их метками в ADTest.exe. Эти данные показывают, что производительность виртуализированного контроллера домена составляет от 88 до 98 процентов от физической производительности контроллера домена.

Измерение	Тест	Физически	Виртуальная	Разностная версия
Поиск/с	Поиск общего имени в базовой области (L1)	11508	10276	-10.71%
Поиск/с	Поиск набора атрибутов в базовой области (L2)	10123	9005	-11.04%
Поиск/с	Поиск всех атрибутов в базовой области (L3)	1284	1242	-3.27%
Поиск/с	Поиск общего имени в области поддерев (L6)	8613	7904	-8.23%
Успешные привязки/с	Выполнение быстрых привязок (B1)	1438	1374	-4.45%
Успешные привязки/с	Выполнение простых привязок (B2)	611	550	-9.98%
Успешные привязки/с	Использование NTLM для выполнения привязок (B5)	1068	1056	-1.12%
операции записи в секунду	Запись нескольких атрибутов (W2)	6467	5885	-9.00%

Чтобы повысить производительность в тестовом развертывании, мы установили компоненты интеграции (IC) в этой тестовой сборке, чтобы позволить гостевой ОС использовать искусственные драйверы с поддержкой гипервизора. При установке IC иногда необходимо использовать эмулированные драйверы встроенной электроники (IDE) или сетевого адаптера. В рабочих средах следует заменить эти эмулированные драйверы искусственными драйверами, чтобы повысить производительность.

На основе этого теста рассмотрите следующие рекомендации по повышению производительности:

• При мониторинге производительности виртуальной Perfmon.msc машины с помощью средства иногда данные ЦП для виртуальной машины не совсем точны. Эта неточность обусловлена тем, как виртуальный ЦП планируется запускать на физическом процессоре. Чтобы получить более точные сведения о ЦП для виртуальных машин, работающих на серверах Hyper-V, используйте счетчики логического процессора Hyper-V в разделе узла. Дополнительные сведения о настройке производительности ad DS и Hyper-V см . в рекомендациях по настройке производительности для Windows Server.

• Рекомендуется избегать использования виртуальных жестких дисков разных дисков на виртуальной машине, настроенной как контроллер домена, так как виртуальные жесткие диски разных дисков могут снизить производительность. Дополнительные сведения о типах дисков Hyper-V, включая разностные диски, см . в мастере создания виртуального жесткого диска.

• Мы также рекомендуем ознакомиться с информацией о том, как использовать AD DS в виртуальных средах размещения, прочитав сведения о том, как размещать контроллеры домена Active Directory в виртуальных средах размещения.

Рекомендации по развертыванию

В следующих разделах описаны распространенные методики виртуальных машин, которые позволяют избежать при развертывании контроллеров домена и специальных рекомендаций по синхронизации времени и хранилищу.

Рекомендации по развертыванию

Платформы виртуализации, такие как Hyper-V, имеют множество функций, которые упрощают управление, обслуживание, резервное копирование и перенос компьютеров. Однако существуют некоторые рекомендации, которые необходимо выполнить, чтобы воспользоваться этими функциями для виртуальных контроллеров домена.

• Чтобы убедиться, что записи Active Directory устойчивы, не развертывайте файлы базы данных виртуального контроллера домена, например NTDS. База данных Active Directory DIT , журналы и SYSVOL на виртуальных дисках интегрированной среды разработки. Вместо этого создайте второй виртуальный жесткий диск (VHD), подключенный к виртуальному контроллеру интерфейса SCSI и убедитесь, что файлы базы данных находятся на диске SCSI виртуальной машины при установке контроллера домена.

• Не реализуйте разностные виртуальные жесткие диски на виртуальной машине, которую вы настраиваете в качестве контроллера домена. Хотя этот подход упрощает восстановление развертывания до предыдущих версий, он также снижает производительность. Дополнительные сведения о типах виртуальных жестких дисков см . в мастере создания виртуального жесткого диска.

• Не развертывайте домены и леса Active Directory в копии ОС Windows Server без первого использования средства подготовки системы (sysprep) для подготовки к развертыванию. Дополнительные сведения о запуске Sysprep см. в обзоре Sysprep (Подготовка системы).

  Предупреждение

  Запуск Sysprep в повышенном контроллере домена не рекомендуется, так как он может отрицательно повлиять на базу данных AD и связанные компоненты и вызвать следующие проблемы:

  • Потеря данных
  • Повреждение базы данных AD
  • Проблемы стабильности и функциональности
  • Проблемы с приложениями, службами и драйверами

• Не развертывайте другие контроллеры домена с копией VHD-файла из развернутого контроллера домена. Не использование копий предотвращает потенциальные сценарии отката USN. Дополнительные сведения о откате USN см. в статье об откате USN и USN.

  • В Windows Server 2012 и более поздних версиях администраторы могут клонировать образы контроллера домена для развертывания дополнительных контроллеров домена, но только в том случае, если они используют правильно подготовленные образы.

• Не используйте функцию экспорта Hyper-V для экспорта виртуальной машины под управлением контроллера домена.

  • В Windows Server 2012 и более поздних версиях система обрабатывает экспорт и импорт виртуальных гостей контроллера домена, таких как неавторитетное восстановление. Этот процесс определяет, изменился ли идентификатор создания и если контроллер домена не настроен для клонирования.

  • При экспорте гостевой виртуальной машины необходимо убедиться, что никто его не использует. Чтобы упростить работу, можно использовать репликацию Hyper-V для создания неактивной копии контроллера домена. При запуске использования реплицированного образа необходимо также выполнить очистку, как и для исходного образа после экспорта гостевого образа контроллера домена.

Физическое преобразование в виртуальную

System Center VM Manager (VMM) позволяет управлять физическими машинами и виртуальными машинами единой системой. Вы также можете использовать VMM для переноса физического компьютера на виртуальную машину. Этот процесс миграции называется преобразованием физической и виртуальной машины или преобразованием P2V. Чтобы запустить процесс преобразования P2V, необходимо убедиться, что виртуальная машина и физический контроллер контроллера домена, которые вы переносите, не выполняются одновременно. Обеспечение одновременного запуска двух компьютеров не позволяет предотвратить сценарии отката USN, как описано в откате USN и USN.

Вы должны выполнять преобразование P2V в автономном режиме, чтобы обеспечить согласованность данных каталога при включении контроллера домена. Вы можете переключать автономный режим в установщике "Преобразовать физический сервер". Дополнительные сведения об использовании автономного режима см. в статье P2V. Преобразование физических компьютеров в виртуальные машины в VMM.

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

Предотвращение отката USN

При создании виртуальных контроллеров домена следует избегать создания сценариев отката USN. Чтобы избежать отката, можно настроить новый виртуальный контроллер домена с регулярным повышением, повышение от установки из мультимедиа (IfM) или клонирование контроллера домена, если у вас уже есть хотя бы один виртуальный контроллер домена. Этот подход также позволяет избежать проблем с оборудованием или платформой, преобразованными виртуальными гостями P2V.

Предупреждение

Чтобы предотвратить проблемы с репликацией Active Directory, убедитесь, что в какой-либо момент времени существует только один физический или виртуальный контроллер домена. Вы можете снизить вероятность возникновения проблемы старого клона с помощью одного из следующих методов:

• При запуске нового виртуального контроллера домена выполните следующую команду дважды, чтобы изменить пароль учетной записи компьютера:

  netdom resetpwd /Server:<domain-controller>
  

• Экспортируйте и импортируйте нового виртуального гостя, чтобы заставить его стать новым идентификатором поколения и идентификатором вызова базы данных.

Тестовая среда и миграция P2V

Миграцию P2V можно использовать в сочетании с VMM для создания тестовых сред. С помощью этого метода можно перенести рабочие контроллеры домена с физических компьютеров на виртуальные машины, чтобы создать тестовую среду без постоянного уменьшения рабочих контроллеров домена. Однако необходимо создать тестовую среду в отдельной сети из рабочей среды, чтобы обеспечить наличие двух экземпляров одного контроллера домена. Важно избежать откатов USN при создании тестовых сред с помощью миграции P2V.

Создание тестовой среды

Рекомендуется выполнить следующие действия при создании тестовых сред с помощью P2V:

• Перенос одного из рабочих контроллеров домена из каждого домена в тестовую виртуальную машину с помощью P2V на основе рекомендаций в преобразовании "Физический — виртуальный".

• Поместите физические рабочие машины и тестовые виртуальные машины в разные сети при их возврате в сеть.

• Чтобы избежать откатов USN в тестовой среде, отключите все контроллеры домена, которые планируется перенести из сети. Вы можете отключить контроллеры домена, остановив службу NTDS или перезагрузив компьютеры в режиме восстановления служб каталогов (DSRM).

• Не вводите новые обновления среды после отключения контроллеров домена от сети.

• Не подключайте компьютеры к сети во время миграции P2V. После завершения миграции всех компьютеров их можно повторно подключить.

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

Служба времени и синхронизация

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

Чтобы отключить поставщик синхронизации времени Hyper-V, отключите виртуальную машину, а затем перейдите к параметрам виртуальной машины, выберите службы Integration Services и снимите флажок синхронизации времени.

Хранение и оптимизация

Мы рекомендуем следовать рекомендациям по хранилищу в этом разделе, чтобы оптимизировать производительность виртуальной машины контроллера домена и убедиться, что записи Active Directory являются устойчивыми.

• Для гостевого хранилища сохраните файл базы данных Active Directory (Ntds.dit) и файлы журнала и SYSVOL на отдельном виртуальном диске из файлов ОС. Рекомендуется хранить эти файлы на виртуальном диске SCSI во втором виртуальном жестком диске, подключенном к виртуальному контроллеру SCSI. Виртуальный диск SCSI повышает производительность и поддерживает принудительный доступ к единицам (FUA). При использовании FUA ОС записывает и считывает данные непосредственно из носителя, обходя любые механизмы кэширования.

• Если вы используете BitLocker для защиты виртуального контроллера домена, настройте дополнительные тома для автоматической разблокировки с помощью командлета Enable-BitLockerAutoUnlock PowerShell.

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

• Система физического диска узла должна соответствовать по крайней мере одному из следующих критериев, чтобы соответствовать требованиям к целостности данных виртуализированной рабочей нагрузки:

  • Узел использует диски класса сервера, такие как SCSI или Fibre Channel.

  • Узел гарантирует, что диски подключены к кэшу с поддержкой батареи.

  • Узел использует контроллер хранилища, например избыточный массив независимых дисков (RAID) в качестве своего устройства хранения.

  • Узел использует неинтерпретируемый источник питания (UPS) для питания диска.

  • Узел по умолчанию отключает функцию кэширования записи диска.

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

• Мы рекомендуем использовать виртуальные контроллеры SCSI, чтобы снизить вероятность повреждения данных Active Directory.

  • На серверах Hyper-V, на которых размещаются виртуальные контроллеры домена, следует использовать физические диски SCSI. Если ваш сценарий не позволяет использовать диски SCSI, необходимо отключить кэширование записи на диске Advanced Technology Attachment (ATA) или встроенного диска IDE. Дополнительные сведения см. в разделе "Код события 1539 — целостность базы данных".

Операционные ограничения для контроллеров домена виртуальной машины

Контроллеры домена, работающие на виртуальных машинах, имеют операционные ограничения, которые не применяются к контроллерам домена, работающим на физических компьютерах. При использовании виртуализированного контроллера домена необходимо выполнить следующие рекомендации.

• Не приостанавливайте, не остановите или сохраните сохраненное состояние контроллера домена на виртуальной машине дольше, чем время существования могилы леса. Возобновление сохраненного состояния, которое вы приостанавливали или сохранили дольше, чем время существования могилы, может повлиять на репликацию. Чтобы узнать, как определить время существования могилы для леса, см. статью "Определение времени существования могилы для леса".

• Не копируйте или клонируйте виртуальные жесткие диски.

• Не используйте моментальные снимки виртуальных контроллеров домена. Вместо этого следует использовать более постоянный и надежный метод резервного копирования.

• Не используйте функцию экспорта на виртуальной машине под управлением контроллера домена.

• Не восстанавливайте или откатите контроллер домена или содержимое базы данных Active Directory с помощью неподдерживаемого метода резервного копирования.

Вопросы резервного копирования и восстановления

Необходимо создать резервную копию контроллеров домена, чтобы предотвратить потерю данных из-за сбоев или административных ошибок. Метод резервного копирования, поддерживаемый Active Directory, использует приложение резервного копирования для восстановления резервного копирования состояния системы, сделанного из текущей установки контроллера домена. Приложение должно быть совместимым с Active Directory, например с Windows Server Backup. Дополнительные сведения о поддерживаемых методах резервного копирования см . в пошаговом руководстве по резервному копированию и восстановлению AD DS.

В виртуализированных развертываниях необходимо обратить особое внимание на определенные требования к операциям резервного копирования Active Directory. Например, если вы восстанавливаете контроллер домена с помощью копии VHD-файла и не обновляете версию базы данных контроллера домена после его восстановления, это может вызвать проблемы с репликацией из-за неточных номеров отслеживания среди реплик контроллера домена. В большинстве случаев репликация не обнаруживает эту проблему и не сообщает об ошибках, но несоответствия между контроллерами домена могут вызвать проблемы в определенных сценариях.

Рекомендуемый метод для резервного копирования и восстановления виртуализированных контроллеров домена

Этот метод рекомендуется использовать для резервного копирования и восстановления виртуализированных контроллеров домена для запуска резервного копирования Windows Server в гостевой ОС. Дополнительные сведения см. в разделе "Восстановление виртуального контроллера домена".

Хотя вы можете технически использовать моментальные снимки или копии VHD-файлов для восстановления резервной копии, мы не рекомендуем использовать эти методы по следующим причинам:

• При копировании или клонировании VHD-файла база данных становится устаревшей, так как ее номер версии базы данных не обновляется автоматически при восстановлении. Это несоответствие в номерах отслеживания означает, что при запуске виртуального жесткого диска в обычном режиме вы можете вызвать откат USN.

• Хотя Windows Server 2016 и более поздних версий совместим с моментальными снимками, моментальные снимки не предоставляют тип стабильного, постоянного журнала резервного копирования, необходимого для последовательного восстановления системы во время аварийных сценариев. Моментальные снимки на основе теневого копирования томов (VSS) можно создавать в Windows Server 2016 Hyper-V, а также не совместимы с BitLocker, что может вызвать потенциальные проблемы с безопасностью. Эта проблема предотвращает доступ ядра СУБД Active Directory к базе данных, содержащей моментальный снимок при попытке Hyper-V подключить том моментального снимка.

Примечание.

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

Откат USN и USN

В этом разделе описываются проблемы репликации, которые могут возникнуть в результате неправильного восстановления базы данных Active Directory с более старой версией виртуальной машины. Дополнительные сведения о процессе репликации Active Directory см . в концепциях репликации Active Directory.

Как AD DS и DCs используют USN

AD DS использует USN для отслеживания репликации данных между контроллерами домена. Каждый раз, когда вы изменяете данные в каталоге, приращение usN указывает на новое изменение.

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

Таблицы метаданных репликации, содержащие USN, можно найти в векторе актуальности и высокой водяной отметке. Исходные и целевые контроллеры домена используют эти таблицы для фильтрации необходимых обновлений для целевого контроллера домена.

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

Целевой контроллер домена поддерживает таблицу с высокой водяной меткой для отслеживания последних изменений, полученных от определенного источника контроллера домена для определенной секции. Таблица с высокой водяной меткой запрещает исходному контроллеру домена отправлять изменения, которые целевой контроллер домена уже получил от него.

Удостоверение базы данных каталога

Помимо USN, контроллеры домена отслеживают базу данных каталогов партнеров по репликации источника. Система сохраняет удостоверение базы данных каталогов, работающей на сервере отдельно от удостоверения самого объекта сервера. Удостоверение базы данных каталогов NTDS Settings на каждом контроллере домена хранится в invocationID атрибуте объекта, который находится в пути cn=NTDS Settings, cn=ServerName, cn=Servers, cn=*SiteName*, cn=Sites, cn=Configuration, dc=*ForestRootDomain*LDAP.

Система сохраняет удостоверение объекта сервера в objectGUID атрибуте NTDS Settings объекта. Удостоверение объекта сервера никогда не изменяется. Однако удостоверение базы данных каталогов изменяется в следующих обстоятельствах:

• При выполнении процедуры восстановления состояния системы на сервере.

• При добавлении раздела каталога приложений на сервер удалите его, а затем снова добавьте его.

• Когда экземпляр Hyper-V активирует записи VSS в секции, содержащей VHD виртуального контроллера домена.

  В этом сценарии гость активирует собственные записи VSS. Это действие является тем же механизмом, который использует процесс резервного копирования и восстановления. Этот метод сбрасывает invocationID атрибут.

Атрибут invocationID относится к набору исходных обновлений в контроллере домена с определенной версией базы данных каталогов. Вектор актуальности и таблицы высокой водяной метки используют invocationID GUID контроллера домена соответственно, чтобы контроллеры домена распознали копию базы данных Active Directory, из которой поступает информация о репликации.

Атрибут invocationID — это глобально уникальное значение идентификатора (GUID), которое отображается в верхней части выходных данных после выполнения repadmin /showrepl команды. Следующий текст представляет пример выходных данных из команды:

Repadmin: running command /showrepl against full DC local host
Default-First-Site-Name\VDC1
DSA Options: IS_GC
DSA object GUID: 966651f3-a544-461f-9f2c-c30c91d17818
DSA invocationID: b0d9208b-8eb6-4205-863d-d50801b325a9

При восстановлении AD DS на контроллере домена система сбрасывает invocationID атрибут. Это изменение увеличивает трафик репликации с длительностью относительно размера секции, которую вы реплицируете.

Для демонстрации этого сценария на следующей схеме показан пример среды, в которой виртуальный контроллер домена VDC1 и контроллер домена DC2 являются двумя контроллерами домена в одном домене. На этой схеме показано, как DC2 обнаруживает invocationID значение в VDC1 после сброса в поддерживаемом сценарии восстановления.

Схема, изображающая блок-диаграмму представления VDC1 о себе и представлении DC2 VDC1. В строке VDC1 VDC1 начинается с имени участника-пользователя 1000 и идентификатора вызова B. Затем он восстанавливается до предыдущей версии, которая имеет номер USN 500 и значение InvocationID B. Изменения происходят в VDC1, при этом она будет выполняться до USN 600, а идентификатор вызова остается прежним. В строке с надписью "Представление DC2 vDC1", DC2 начинается с идентификатора вызова VDC1(A)@USN1000. После восстановления VDC1 dc2 сбрасывает ожидаемый usN с 1000 по 500, что делает его значение для идентификатора вызова B VDC1(B)@USN500. Он продолжает отслеживать идентификатор вызова A и идентификатор вызова B. После следующего набора изменений в VDC1 DC2 теперь отслеживает вызов VDC1 id A of USN 1000 и новый идентификатор вызова B USN 600.

Откат USN

Откат USN возникает, когда система не может обновить usN как обычное, пользователь обойти обновления USN или контроллер домена пытается использовать USN ниже последнего обновления. При обнаружении отката USN система останавливает репликацию, прежде чем несоответствие может привести к расхождению в лесу.

Многие факторы могут вызвать откат USN. Например, это может произойти, если вы используете старые VHD-файлы или выполняете преобразование P2V без окончательного отключения физического компьютера после преобразования.

Предотвращение отката USN

Вы можете предотвратить откаты USN, выполнив следующие меры предосторожности:

• Если windows Server 2012 или более поздней версии не используется, не используйте моментальный снимок виртуальной машины контроллера домена.

• Не копируйте VHD-файл контроллера домена.

• Если windows Server 2012 или более поздней версии не используется, не экспортируйте виртуальную машину под управлением контроллера домена.

• Восстановление контроллера домена или откат содержимого базы данных Active Directory с помощью поддерживаемых решений резервного копирования, таких как резервное копирование Windows Server.

Иногда система не может обнаружить откат USN, прежде чем она может вызвать ошибки репликации. При возникновении ошибок репликации необходимо определить степень проблемы и устранить ее как можно скорее. Дополнительные сведения об удалении неустранимых объектов, которые могут возникать в результате отката USN, см. в разделе Идентификатор события репликации Active Directory 1388 или 1988: обнаружен задерживающийся объект.

Обнаружение отката USN

В большинстве случаев система может обнаруживать откаты USN путем отслеживания несоответствий в invocationID атрибуте, вызванных восстановлением контроллера домена без сброса атрибута. Windows Server 2008 обеспечивает защиту от ошибок репликации после неподдерживаемых операций восстановления контроллера домена. Эти защиты активируются, когда неподдерживаемое восстановление создает USN ниже исходных версий, представляющих изменения, которые партнеры репликации уже получили.

В Windows Server при изменении целевого контроллера домена с использованием ранее используемого имени пользователя контроллер домена назначения интерпретирует ответ партнера репликации, что означает, что метаданные репликации устарели. Устаревшие метаданные означает, что база данных Active Directory на исходном контроллере домена откатила к предыдущему состоянию, поэтому система отвечает соответствующим образом.

Например, предположим, что VHD-файл виртуальной машины откатился до предыдущей версии. В этом случае целевой контроллер домена инициирует следующие меры карантина на контроллере домена, который он определил как прошедший неподдерживаемое восстановление:

• AD DS приостанавливает службу входа в сеть, которая предотвращает изменение паролей учетных записей пользователей и учетных записей компьютеров. Это действие предотвращает потерю таких изменений, если они происходят после неправильного восстановления.

• AD DS отключает входящие и исходящие репликации Active Directory.

• AD DS создает идентификатор события 2095 в журнале событий службы каталогов для записи того, что произошло.

На следующей схеме показана последовательность событий, возникающих при обнаружении отката AD DS в VDC2, целевом контроллере домена, работающем на виртуальной машине. На этом рисунке обнаружение отката USN происходит на VDC2, когда партнер репликации обнаруживает, что VDC2 отправил текущее значение USN, которое ранее видел целевой контроллер домена. Это условие указывает, что база данных VDC2 испытала откат.

Схема, изображающая блок-схему обновлений VDC2 и значение актуальности DC1 для VDC2. VDC2 начинается с usN 100 и идентификатора вызова A. Затем он обновляет свои USN с 101 по 200, который реплицируется на DC1. Однако пользователь также создает копию VHD VDC2 USN 200. Затем VDC2 обновляет usN 201 до 350 и реплицирует эти изменения в DC1. Однако VDC2 завершается ошибкой. Затем пользователь восстанавливает VDC2 с копией, сделанной на виртуальном жестком диске USN 200. После этого пользователь выполняет другое обновление до VDC2 для новой версии USNs 201-355. Запросы DC1 изменяются больше USN 350 из VDC2 и реплицируются, так как usN на VDC2 выше, чем DC1. Однако новая версия USN 201–350 не совпадает с версиями в DC1, что приводит к откату USN.

Устранение проблем с идентификатором события 2095

Если в журнале событий службы каталогов отображается идентификатор события 2095, выполните следующие инструкции немедленно:

1. Изолируйте виртуальную машину, записающую ошибку из сети.

2. Проверьте, были ли внесенные изменения из этого контроллера домена и распространялись на другие контроллеры домена. Если событие было результатом использования моментального снимка или копии виртуальной машины, попробуйте выяснить, когда произошел откат USN. Когда у вас есть время, вы можете проверить партнеров репликации этого контроллера домена, чтобы определить, произошла ли репликация после отката.

   Вы можете использовать средство Repadmin, чтобы проверить, откуда произошли изменения. Сведения об использовании Repadmin см. в статье "Мониторинг и устранение неполадок репликации Active Directory с помощью Repadmin". Если вы не можете принять решение, обратитесь служба поддержки Майкрософт за помощью.

3. Принудительно понижение контроллера домена. Эта операция включает очистку метаданных контроллера домена и захват ролей главных операций, также известных как гибкие роли основных операций (FSMO). Дополнительные сведения см. в разделе "Восстановление после отката USN".

4. Удалите все бывшие VHD-файлы для контроллера домена.

Необъявленный откат USN

Контроллер домена может не обнаружить откат USN в следующих сценариях:

• VHD-файл подключен к разным виртуальным машинам, работающим одновременно в нескольких расположениях.

• USN на восстановленном контроллере домена увеличилось за последний USN, полученный другим контроллером домена.

В сценарии VHD-файла другие контроллеры данных могут реплицироваться с одной из виртуальных машин, а изменения могут возникать на любой виртуальной машине без репликации на другую. Это расхождение леса трудно обнаружить, и это приводит к непредсказуемым ответам каталога. Эта ситуация может произойти после миграции P2V, если физический контроллер домена и виртуальная машина выполняются в одной сети. Эта ситуация также может произойти, если несколько виртуальных контроллеров домена создаются из одного физического контроллера домена, а затем выполняются в одной сети.

В сценарии USN диапазон USN применяется к двум разным наборам изменений. Этот сценарий может продолжаться в течение длительных периодов без обнаружения. При изменении объекта, созданного в течение этого периода, система обнаруживает задерживающийся объект и сообщает его как идентификатор события 1988 в Просмотр событий. На следующей схеме показано, почему контроллер домена может не обнаружить откат USN в этом сценарии.

Схема, показывающая блок-диаграмму для процесса обнаружения отката в примере сборки. Существует два контроллера домена с меткой "VDC1" и "DC2". На начальном этапе блок-диаграммы показан виртуальный контроллер домена, VDC1, моментальный снимок, когда его usN составляет 2000. После создания моментального снимка VDC1 создает 100 пользователей, а обновленный VDC1 теперь имеет USN 2100. Обновления VDC1 реплицируются в DC2, которая теперь использует USN 2100. Однако VDC1 затем использует моментальный снимок, который он взял для возврата к своей версии USN 2000. Отмененная версия VDC1 создает 150 новых пользователей, что приводит к 2150 usN до 2150. Обновленный VDC1 реплицируется в DC2, но DC2 не обнаруживает несовпадения изменений, так как его имя USN выше usN DC2 в 2100 году. Текст в нижней части говорит: "Откат USN не обнаружен, что приводит к незамеченному расхождению, в котором usNs 2001–2100 не совпадают между двумя контроллерами домена.

Контроллеры доменов только для чтения

Контроллеры домена только для чтения (RODCs) — это контроллеры домена, на которых размещаются копии секций только для чтения в базе данных Active Directory. Контроллеры домена избежать большинства проблем с откатом USN, так как они не реплицируют какие-либо изменения в других контроллерах домена. Однако если rodC реплицируется из записываемого контроллера домена, затронутого откатом USN, откат также влияет на RODC.

Не рекомендуется использовать моментальный снимок для восстановления RODC. Необходимо восстановить только РОДК с помощью приложения резервного копирования, совместимого с Active Directory. Кроме того, как и при использовании записываемых контроллеров домена, вы не должны разрешать родК быть автономным в течение большей мере, чем время существования могилы. Это условие может привести к задерживающимся объектам в RODC.

Дополнительные сведения о реализации контроллеров домена см . в пошаговом руководстве по контроллерам домена только для чтения.

Дополнительные материалы

Узнайте, как восстановить виртуализированные контроллеры домена при восстановлении виртуализированных контроллеров домена.