Шон Дьюби (sdeuby@windowsitpro.com) — старший аналитик в компании Platform Vision с 25-летним стажем работы в области корпоративных информационных систем. Внештатный редактор Windows IT Pro, имеет звание MVP

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

Active Directory была зоной без клонирования

Виртуальные диски и конфигурация виртуальной машины принципиально допускают возможность клонирования. Базовую операционную систему также можно клонировать, если отсутствует привязка к конкретным физическим компонентам (например, к транзитному физическому диску) и устранены другие потенциальные проблемы, в частности, связанные с именем системы и статическим IP-адресом. Еще одним источником конфликта является присоединение к домену виртуальной машины, поскольку ее идентификатор безопасности (SID) идентичен исходному. Существует ряд способов избежать конфликта (от программы подготовки системы Sysprep до утилиты Sysinternals NewSID) и сгенерировать новый SID для клонированной виртуальной машины.

Имеются также ограничения на уровне приложений. В случае доменной службы Active Directory (AD DS) основное ограничение возможности клонирования виртуальной машины связано с тем, что каждый контроллер домена (DC) является неотъемлемой частью единого целого – распределенной системы DC. Даже если каждый DC в случае отказа легко заменить, необходимо информировать всю распределенную систему о его состоянии. DC, у которого изменилось состояние (например, после восстановления из резервной копии), всегда уведомляет об этом своих партнеров по репликации. Однако применение такого самоконтроля имеет свои недостатки, и со временем были введены защитные механизмы, так что если DC обнаруживает определенные действия партнера по репликации (например, попытку реплицировать атрибуты объекта, который уже удален), то все последующие обновления он отклоняет.

Манипуляции с виртуализованным DC в Windows Server 2008 R2 или более ранних версий с применением незнакомых ему операций виртуализации могут кончиться плохо. Учитывая вероятность таких ошибок, для жизненного цикла продукта Windows Server 2012 группа разработки AD поставила в число высокоприоритетных задач обеспечение безопасной виртуализации AD. С этой целью в гипервизор введен идентификатор VM-GenerationID (VM Gen ID), а в операционную систему и AD встроена соответствующая логика. Подробнее об этом рассказано в статье «Безопасная виртуализация Active Directory в Windows Server 2012», опубликованной в этом же номере журнала.

Клонирование эквивалентно гибкости

Вернемся к клонированию. Безопасная виртуализация AD в Server 2012 дала положительный «побочный эффект» от безопасного клонирования AD. Особая польза клонирования для AD состоит в том, что оно позволяет увеличить производительность. До Server 2012 единственный способ добавления DC в лес AD предполагал создание новой виртуальной машины с последующим повышением ее статуса до DC с помощью Dcpromo. Здесь нет большой сложности, пока лес AD невелик и, соответственно, база данных (ntds.dit) не слишком объемна, либо если приходится лишь время от времени добавлять или заменять DC. Однако если вы обслуживаете большую и динамичную среду, то это сильно замедляет работу.

Способность быстро развертывать новые DC дает большие преимущества, поскольку позволяет оперативно восстанавливать домен или лес после аварии (подробнее об этом рассказано в статье «Аварийное восстановление Active Directory в Windows Server 2012», опубликованной в журнале Windows IT Pro/RE № 8 за 2012 год). Если вы создаете частное «облако», то клонирование DC позволит сделать инфраструктуру аутентификации и авторизации столь же гибкой, как прочие возможности. Если требуется быстро скомпоновать тестовую среду или повысить производительность в подразделении, то клонирование DC позволит это сделать.

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

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

Процедура клонирования

Чтобы обеспечить возможность клонирования VDC Server 2012, сервер, на котором функционирует исходный VDC (источник клонирования), и узел назначения должны поддерживать VM Gen ID. Сейчас VM Gen ID поддерживает только Hyper-V в Windows Server 2012, однако VMware и Citrix разработали спецификацию, содержащую требование о включении этой поддержки в их продукты. Эмулятор основного контроллера домена (PDC) также должен работать под управлением Server 2012 (но клонировать его нельзя). Клонировать можно только DC Server 2012; для более старых версий это не предусмотрено. Однако наличие DC Server 2012 означает, что лес и домен (домены) уже были обновлены до Server 2012 (об этом речь идет в статье «Windows Server 2012 – упрощение обновления и развертывания Active Directory», опубликованной в этом же номере журнала). Этапы клонирования DC перечислены ниже.

1. Чтобы разрешить клонирование, добавьте VDC в группу клонируемых контроллеров домена (Cloneable Domain Controllers). Это можно сделать с помощью средств управления AD, таких как центр администрирования Active Directory (ADAC), оснастка «Пользователи и компьютеры Active Directory» (ADUC) или команда PowerShell Add-ADGroupMember.

2. С помощью команды Get-ADDCCloningExcludedApplicationList выведите список программ и служб, функционирующих на клонируемом VDC, для которых клонирование может оказаться небезопасным.

3. Просмотрите этот список и в файл CustomDCCloneAllowList.xml добавьте программы и службы, которые, по вашему мнению, могут быть успешно клонированы (обратитесь к разработчику или проведите собственное тестирование). Эта часть процесса подтверждает рекомендацию, согласно которой на DC должно функционировать минимальное количество приложений и служб. Мне не известны какие-либо ограничения, препятствующие клонированию установок Server Core или Minimal Server Interface (MinShell).

4. На исходном VDC запустите команду New-ADDCCloneConfigFile, чтобы сгенерировать файл конфигурации с новыми параметрами клонируемого VDC, включая имя, IP-адрес, маску подсети, DNS-серверы и имя сайта AD, на который будет осуществляться развертывание.

5. Выключите исходный VDC и экспортируйте его (после этого перезапустите узел, если ему надлежит быть включенным).

6. Импортируйте клон на узел назначения и запустите его.

7. Процесс клонирования и необходимые условия для его выполнения подробно описаны в статье Microsoft «Active Directory Domain Services (AD DS) Virtualization» (http://technet.microsoft.com/en-us/library/hh831734.aspx#virtualized_dc_cloning). Всякий раз, когда требуется клонировать новый DC, приходится запускать New-ADDCCloneConfigFile на исходном VDC, а затем выключать его и экспортировать, поэтому в больших вычислительных центрах, где клонирование выполняется часто, может оказаться целесообразным размещение исходного VDC на собственном сайте без пользовательских подсетей. При такой организации внезапное выключение VDC никак не отразится на ходе рабочего процесса.

Таким образом, клонирование – новая возможность для AD в Server 2012, полезная как для больших вычислительных центров, где требуется увеличить производительность, так и для организаций среднего размера, желающих обеспечить необходимый уровень отказоустойчивости для подразделений, и малых предприятий, в которых клонирование VDC можно применять для послеаварийного восстановления AD.