Настройка аварийного восстановления для Active Directory и DNS

Корпоративные приложения, такие как SharePoint, Dynamics AX и SAP, зависят от Active Directory и инфраструктуры DNS для правильной работы. При настройке аварийного восстановления для приложений часто необходимо восстановить Active Directory и систему доменных имен (DNS) перед восстановлением других компонентов приложения, чтобы обеспечить правильную функциональность приложения.

Вы можете использовать Site Recovery для создания плана аварийного восстановления для Active Directory. В случае сбоя вы можете инициировать переключение на резервный сервер. Вы можете настроить и запустить Active Directory всего за несколько минут. Если вы развернули Active Directory для нескольких приложений на основном сайте, например для SharePoint и SAP, может потребоваться переключение на резервный сайт всего сайта. Сначала можно выполнить переключение Active Directory на резервный с помощью Site Recovery. Затем выполните переключение отказа других приложений, используя планы восстановления для этих приложений.

В этой статье объясняется, как создать решение аварийного восстановления для Active Directory. Здесь указаны предварительные требования и инструкции по отказоустойчивости. Перед началом работы вы должны ознакомиться с Active Directory и Site Recovery.

Предварительные требования

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

Репликация контроллера домена

  • Необходимо настроить репликацию Site Recovery по крайней мере на одной виртуальной машине, где размещается контроллер домена или DNS.
  • Если в вашей среде несколько контроллеров домена, на целевом сайте также необходимо настроить дополнительный контроллер домена. Дополнительный контроллер домена может находиться в Azure или в дополнительном локальном центре обработки данных.
  • При наличии небольшого количества приложений и одного контроллера домена может потребоваться выполнить переключение на резерв всего сайта целиком. В этом случае рекомендуется использовать Site Recovery для репликации контроллера домена на целевой сайт либо в Azure, либо в дополнительном локальном центре обработки данных. Этот же реплицированный контроллер домена или виртуальную машину с DNS можно использовать для тестовой отработки отказа.
  • Если в вашей среде имеется множество приложений и более одного контроллера домена, или вы планируете постепенно переключать несколько приложений, то, помимо репликации виртуальной машины контроллера домена с помощью Site Recovery, рекомендуется настроить дополнительный контроллер домена на целевой площадке (либо в Azure, либо в резервном локальном центре обработки данных). Для тестового переключения можно использовать контроллер домена, реплицируемый с помощью Site Recovery. Для резервирования можно использовать дополнительный контроллер домена на целевом сайте.

Включение защиты с помощью Site Recovery

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

Защита виртуальной машины

Контроллер домена, реплицируемый с помощью Site Recovery, используется для тестовой отработки отказа. Убедитесь, что он соответствует следующим требованиям.

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

Настройка параметров сети виртуальной машины

Для виртуальной машины, на которую размещен контроллер домена или DNS, в Site Recovery настройте параметры сети в разделе Network параметры реплицированной виртуальной машины. Это гарантирует, что виртуальная машина будет подключена к правильной сети после отказа.

Защита Active Directory

Защита "между сайтами"

Замечание

Windows Server 2008, 2008 R2, 2012 и 2012 R2 достигли окончания поддержки (EOS). Просмотрите, как вы используете операционную систему, и планируйте её обновления и миграции соответственно. Дополнительные сведения см. в разделе "Окончание поддержки"

Создайте контроллер домена на дополнительном сайте. При повышении роли сервера до роли контроллера домена укажите имя того домена, который используется на основном сайте. Вы можете использовать оснастку Сайты и службы Active Directory для настройки параметров объекта связи сайта, к которому добавлены сайты. Настраивая параметры связи между сайтами, можно указать время и периодичность репликации между двумя или несколькими сайтами. Дополнительные сведения см. в статье Расписание репликации между сайтами.

Защита Azure типа "сеть — сеть"

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

Затем перенастройьте DNS-сервер для виртуальной сети, чтобы использовать DNS-сервер в Azure.

Сеть Azure

защита Azure к Azure

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

Затем перенастройьте DNS-сервер для виртуальной сети, чтобы использовать DNS-сервер в Azure.

Рекомендации по тестированию переключения на резервный сервер

Чтобы избежать воздействия на производственные нагрузки, тестирование сбоя проводится в сети, изолированной от производственной сети.

Для работы большинства приложений требуется контроллер домена и DNS-сервер. Таким образом, прежде чем приложение перейдёт в режим отказоустойчивости, необходимо создать в изолированной сети контроллер домена для использования в тестовом переключении. Самый простой способ сделать это — использовать Site Recovery для репликации виртуальной машины, на которую размещается контроллер домена или DNS. Запустите тестовую отработку отказа виртуальной машины с контроллером домена, прежде чем запускать тестовую отработку отказа плана восстановления для приложения.

  1. Используйте Site Recovery для репликации виртуальной машины, на которой размещен контроллер домена или DNS.

  2. Создайте изолированную сеть. Любая виртуальная сеть, созданная в Azure, изолирована от других сетей по умолчанию. Рекомендуем использовать для этой сети такой же диапазон IP-адресов, как у вашей рабочей сети. Не включайте для этой сети подключение между сайтами.

  3. Укажите IP-адрес DNS в изолированной сети. Используйте IP-адрес, который должна получить виртуальная машина DNS. Если вы реплицируете в Azure, укажите IP-адрес виртуальной машины, которая используется в случае отказа. Чтобы ввести IP-адрес, в реплицированной виртуальной машине в разделе параметров Сеть выберите параметры Целевой IP-адрес.

    Azure тестовая сеть

    Совет

    Site Recovery пытается создать тестовые виртуальные машины в подсети с тем же именем и с помощью того же IP-адреса, который указан в параметре Network параметры виртуальной машины. Если подсеть с тем же именем недоступна в виртуальной сети Azure, предоставленной для тестирования аварийного переключения, тестовая виртуальная машина создается в первой подсети по алфавитному порядку.

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

Тестовое переключение на резервный сайт

  1. Если вы выполняете репликацию на другой локальный сайт и используете DHCP, настройте DNS и DHCP для тестирования отказоустойчивости.
  2. Выполните тестовое переключение на резервный режим на виртуальной машине с контроллером домена, работающей в изолированной сети. Используйте последнюю доступную приложению согласованную точку восстановления виртуальной машины контроллера домена для тестовой отработки отказа.
  3. Выполните тестовую отработку отказа для плана восстановления, содержащего виртуальные машины, на которых работает приложение.
  4. После завершения тестирования очистите отказоустойчивость в тестовом режиме на виртуальной машине доменного контроллера. Этот шаг удаляет контроллер домена, который был создан для тестового переключения в случае отказа.

Удаление ссылок на другие контроллеры домена

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

Вопросы, связанные с мерами по обеспечению безопасности виртуализации

Внимание

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

Начиная с Windows Server 2012, дополнительные меры безопасности встроены в доменные службы Active Directory (AD DS). Эти меры безопасности помогают защитить виртуализированные контроллеры домена от откатов USN (последовательного номера обновления) при условии, что базовая платформа низкоуровневой оболочки поддерживает VM-GenerationID. Azure поддерживает VM-GenerationID. Из-за этого контроллеры домена, которые выполняют Windows Server 2012 или более поздней версии на Azure виртуальных машинах, имеют эти дополнительные средства защиты.

Когда выполняется сброс VM-GenerationID, значение InvocationID базы данных AD DS также сбрасывается. Кроме того, пул относительных идентификаторов (RID) удаляется, а папка SYSVOL помечается как неавторитетная. Дополнительные сведения см. в Введение в виртуализацию доменные службы Active Directory и Безопасная виртуализация репликации распределенной файловой системы (DFSR).

Переключение на Azure может привести к сбросу VM-GenerationID. Сброс VM-GenerationID активирует дополнительные средства защиты при запуске виртуальной машины доменного контроллера в Azure. Это может привести к значительной задержке при входе на виртуальную машину с контроллером домена.

Так как этот контроллер домена будет использоваться только в тестовом сценарии отказа, меры предосторожности виртуализации не требуются. Чтобы значение VM-GenerationID для виртуальной машины с контроллером домена не изменялось, присвойте следующему параметру DWORD на локальном контроллере домена значение 4.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\gencounter\Start

Признаки применения мер по обеспечению безопасности виртуализации

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

  • Значение GenerationID изменилось.

  • Значение InvocationID изменилось.

  • Папка SYSVOL или общие папки NETLOGON недоступны.

    Общая папка SYSVOL

    Папка NtFrs SYSVOL

  • Базы данных DFSR удалены.

Устранение неполадок контроллера домена при тестовом отказе

Внимание

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

  1. В командной строке выполните следующую команду, чтобы проверить наличие совместного доступа к папкам SYSVOL и NETLOGON:

    NET SHARE

  2. В командной строке выполните следующую команду, чтобы убедиться, что контроллер домена работает правильно:

    dcdiag /v > dcdiag.txt

  3. В журнале выходных данных найдите следующий текст. Текст подтверждает, что контроллер домена работает правильно.

    • passed test Connectivity
    • passed test Advertising
    • passed test MachineAccount

Если эти условия выполняются, скорее всего контроллер домена будет работать правильно. Если нет, сделайте следующее:

  1. Выполните заслуживающее доверия восстановление контроллера домена. Примите во внимание указанные ниже сведения.

  2. Пропустите требование начальной синхронизации, задав следующему разделу реестра значение 0 на локальном контроллере домена. Если DWORD не существует, его можно создать в узле Parameters.

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Repl Perform Initial Synchronizations

    Дополнительные сведения см. в статье Troubleshoot DNS Event ID 4013: The DNS server was unable to load AD integrated DNS zones (Устранение события DNS с идентификатором 4013: DNS-серверу не удалось загрузить зоны DNS, интегрированные с AD).

  3. Отключите требование, чтобы сервер глобального каталога был доступен для проверки входа пользователя. Для этого в локальном контроллере домена задайте следующий параметр реестра на 1. Если DWORD не существует, его можно создать в узле Lsa.

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\IgnoreGCFailures

    Дополнительные сведения см. в статье Как работает глобальный каталог.

Контроллер домена и DNS на разных компьютерах

Если вы запускаете контроллер домена и DNS на одной виртуальной машине, вы можете пропустить эту процедуру.

Если служба DNS не размещена на той же виртуальной машине, что и контроллер домена, необходимо создать виртуальную машину DNS для тестирования отказа. Вы можете использовать новый DNS-сервер и создать все необходимые зоны. Например, если домен Active Directory contoso.com, можно создать зону DNS с именем contoso.com. Записи, соответствующие Active Directory, должны быть обновлены в DNS следующим образом:

  1. До включения любой другой виртуальной машины в план восстановления убедитесь, что настроены указанные ниже параметры:

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

  2. Выполните в виртуальной машине с контроллером домена следующую команду:

    nltest /dsregdns

  3. Выполните следующие команды, чтобы добавить зону на DNS-сервер, разрешите небезопасные обновления и добавьте запись для зоны в DNS.

    dnscmd /zoneadd contoso.com  /Primary

dnscmd /recordadd contoso.com  contoso.com. SOA %computername%.contoso.com. hostmaster. 1 15 10 1 1

dnscmd /recordadd contoso.com %computername%  A <IP_OF_DNS_VM>

dnscmd /config contoso.com /allowupdate 1

Следующие шаги

Узнайте больше о защите корпоративных рабочих нагрузок с помощью Azure Site Recovery.

  • Last updated on