Контроллеры домена Active Directory в среде реплики Hyper-V (часть 1)

на информационный бюллетень WindowsNetworking.com, посвященный обновлению статей в реальном времени

Реплика Hyper-V предназначена для репликации измененного содержимого виртуальной машины на сервер-реплику. В случае каких-либо запланированных и незапланированных отработок отказа, а также при запуске реплики виртуальной машины на сервере реплики вам предоставляются резервные копии для восстановления данных виртуальной машины и приложений. Реплика Hyper-V предоставляет две резервные копии; «Стандартная резервная копия» и «Резервная копия, согласованная с приложением». Эти резервные копии иногда называют «точками восстановления». «Стандартная резервная копия» — это «на определенный момент времени» копия VHD-файлов виртуальной машины, созданная основным сервером. «Резервная копия, согласованная с приложением» создается модулем записи Hyper-V VSS, который в основном представляет собой моментальный снимок VSS томов внутри виртуальной машины. Эти резервные копии отправляются на сервер реплик по истечении интервала репликации. Вы применяете стандартные резервные копии для восстановления хранилища виртуальной машины, а согласованные с приложением моментальные копии используются для восстановления данных приложения.

Реплика Hyper-V не знает, что работает внутри виртуальной машины. Например, у вас может быть запущен контроллер домена Active Directory или вы можете развернуть приложение базы данных на виртуальной машине. По сути, существует два типа приложений, которые можно размещать в среде реплики Hyper-V; приложения, которые знают о технологии VSS, и приложения, которые не знают о технологии VSS. Приложения, поддерживающие VSS, предоставляют собственный модуль записи VSS. Модуль записи VSS приложений работает с модулем записи VSS Hyper-V, чтобы сделать непротиворечивый моментальный снимок томов внутри виртуальной машины. Затем эта непротиворечивая копия отправляется на сервер реплик по истечении интервала репликации. Существуют некоторые недостатки, связанные с размещением приложений, не поддерживающих технологию VSS. Поскольку в приложениях нет модуля записи VSS, вы можете увидеть несогласованный моментальный снимок приложения, отправляемый на сервер-реплику.

Вы можете размещать любое приложение, использующее технологию VSS, чтобы согласованные с приложением моментальные снимки, созданные модулем записи VSS Hyper-V, можно было использовать для восстановления данных приложения. Но не всегда обязательно, чтобы ваши приложения имели модуль записи VSS, прежде чем они смогут работать в среде Hyper-V Replica. Есть несколько приложений, которые работают по-другому и не обязательно должны поддерживать VSS. Например, технология Active Directory не обязательно должна поддерживать VSS для работы в среде реплики Hyper-V. Вместо объяснения того, как каждое приложение работает в среде реплики Hyper-V, я предпочитаю объяснять, как виртуальные контроллеры домена Active Directory работают в среде реплики Hyper-V.

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

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

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

Microsoft представила VM-GenerationID (VMGenID), который позволяет хосту Hyper-V связываться с гостевыми операционными системами при возникновении значительных изменений. Например, узел Hyper-V может обмениваться данными с виртуализированным контроллером домена под управлением Windows Server 2012 и более поздних версий всякий раз, когда выполняется операция гипервизора. Как только виртуальный контроллер домена получает это сообщение от узла Hyper-V, ему необходимо выполнить действие в пользу базы данных Active Directory.

Чтобы лучше проиллюстрировать случай контроллера домена, участвующего в запланированных/незапланированных аварийных переключениях реплики Hyper-V, давайте предположим, что у вас есть два контроллера домена, работающих на одном сайте, и эти два контроллера домена являются прямыми партнерами репликации. Контроллеры домена VMDC1 и VMDC2 работают на первичном сайте, тогда как VMDC2-Copy — это копия-реплика VMDC2, работающая на сайте-реплике.

Вот что происходит при аварийном переключении (запланированном или незапланированном) для контроллера домена под управлением Windows Server 2012 или более поздних версий:

Реплика Hyper-V «Запланированная отработка отказа» для Windows Server 2012 или более поздних версий:

1. Виртуальный администратор включает репликацию для VMDC2 на основном сайте.
2. В рамках репликации копия VMDC2 создается на сайте реплики.
3. VMDC2, работающий на основном сайте, выключается, и выполняется отработка отказа на VMDC2-Copy, работающий на сайте-реплике.
4. После запуска VMDC2-Copy на сайте реплики он проверяет значение VMGenID, которое есть в его базе данных.
5. VMDC2-Copy сбрасывает свой InnovcationID, отбрасывает свой пул RID и устанавливает требование начальной синхронизации, прежде чем сможет возобновить работу.
6. VMDC2-Copy сохраняет новое значение VMGenID в своей базе данных и фиксирует все новые обновления, полученные от партнерского контроллера домена или сделанные локально администратором.
7. Поскольку InnovocationID сбрасывается, VMDC1 будет учитывать изменения, сделанные VMDC2-Copy, и любые новые обновления будут успешно реплицированы на VMDC1, работающий на основном сайте.

Реплика Hyper-V «Незапланированная отработка отказа» для Windows Server 2012 или более поздних версий:

В случае «незапланированного аварийного переключения» у VMDC2 не будет возможности реплицировать изменения, полученные от VMDC1. Это связано с тем, что незапланированная отработка отказа происходит при аварии на основном сайте или VMDC1. В случае аварии VMDC2-Copy не узнает об изменениях и в результате изменения будут потеряны.

Следующие шаги помогут вам понять, когда инициируется запланированная или незапланированная отработка отказа для Windows Server 2008 R2 или более ранних версий в среде реплики Hyper-V.

Реплика Hyper-V «Запланированная отработка отказа» для Windows Server 2008 R2 и более ранних версий:

Если вы используете более раннюю версию виртуального контроллера домена (Windows Server 2008 R2 или более раннюю), поскольку механизм репликации AD 2008 R2 или более ранней версии не понимает технологию VMGenID, это подвергает эти контроллеры домена риску отката USN. В следующем примере показано, что происходит, когда запускается запланированная отработка отказа для Windows Server 2008 R2 и более ранних виртуальных контроллеров домена.

1. VMDC1 и VMDC2 работают под управлением Windows Server 2008 R2 или более ранних версий.
2. VMDC2 выключается, и на VMDC2-Copy выполняется запланированная отработка отказа. Все данные на VMDC2 реплицируются на VMDC2-Copy до завершения отключения.
3. Поскольку VMDC2-Copy не понимает VMGenID, после запуска VMDC2-Copy он возобновляет репликацию с VMDC1, используя тот же идентификатор вызова, что и DC2.

«Незапланированная отработка отказа» для Windows Server 2008 R2 и более ранних версий не представляет опасности, если вы используете только один контроллер домена в одном лесу Active Directory, но это не поддерживается группой Microsoft PSS.

Резюме

Вы узнали, как технология VMGenerationID помогает размещать виртуальные контроллеры домена под управлением Windows Server 2012 и более поздних версий, не беспокоясь об откате USN. Хотя вы можете успешно размещать виртуальные контроллеры домена под управлением Windows Server 2012 и более поздних версий, существует небольшой риск отката USN, связанный с Windows Server 2008 R2 и более ранними виртуальными контроллерами домена.

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

на информационный бюллетень WindowsNetworking.com, посвященный обновлению статей в реальном времени