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

  • Статья

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

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

Обзор клонирования виртуализированного контроллера домена

Процесс клонирования виртуализированного контроллера домена подробно описан в статье "Введение в домен Active Directory службы (AD DS) Виртуализация (уровень 100) и технический справочник по виртуализированному контроллеру домена (уровень 300). С точки зрения поставщика приложений, это некоторые рекомендации, которые следует учитывать при оценке влияния клонирования в приложение:

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

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

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

    • Протокол DHCP

    • Службы сертификатов Active Directory (AD CS)

    • Службы Active Directory облегченного доступа к каталогам (AD LDS)

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

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

Что интересно для поставщиков приложений?

CustomDCCloneAllowList.xml

Контроллер домена, на котором выполняется приложение или служба, не может быть клонирован до тех пор, пока приложение или служба не будет:

  • Добавлен в файл CustomDCCloneAllowList.xml с помощью командлета Get-ADDCCloningExcludedApplicationList Windows PowerShell

-или-

  • Удалено из контроллера домена

При первом запуске командлета Get-ADDCCloningExcludedApplicationList он возвращает список служб и приложений, работающих на контроллере домена, но не входит в список служб и приложений, поддерживаемых для клонирования по умолчанию. По умолчанию служба или приложение не будут перечислены. Чтобы добавить службу или приложение в список приложений и служб, которые можно безопасно клонировать, пользователь снова запускает командлет Get-ADDCCloningExcludedApplicationList с параметром -GenerateXML, чтобы добавить его в файл CustomDCCloneAllowList.xml. Дополнительные сведения см. в шаге 2. Запуск командлета Get-ADDCCloningExcludedApplicationList.

Взаимодействие с распределенной системой

Обычно службы, изолированные на локальном компьютере, передаются или завершаются сбоем при участии в клонирование. Распределенные службы должны быть обеспокоены наличием двух экземпляров хост-компьютера в сети одновременно в течение короткого периода времени. Это может проявляться как экземпляр службы, пытающийся извлечь информацию из партнерской системы, где клон зарегистрирован в качестве нового поставщика удостоверения. Или оба экземпляра службы могут отправлять сведения в базу данных AD DS одновременно с разными результатами. Например, это не детерминировано, с каким компьютером будет взаимодействовать, если две компьютеры с службой Windows Testing Technologies (WTT) находятся в сети с контроллером домена.

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

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

Самым большим фактором, который зависит от времени клонирования, является то, сколько объектов требуется реплика te из PDC. Старый носитель увеличивает время, необходимое для завершения клонирования.

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

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

Дополнительные сценарии, предлагаемые для тестирования

Сбой клонирования

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

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

Клонирование эмулятора PDC

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

Контроллеры домена, доступные только для чтения и доступные для чтения

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