Виртуализация Active Directory

. Обычно компании начинают с консолидации своих физических серверов на хост-машинах в виде виртуальных машин. Естественно, руководство компаний стремится виртуализировать максимально возможное число серверов. Осуществляя этот процесс, компании часто следуют принципу «объект является виртуальным по умолчанию»: все приложения виртуализируются, если администраторы не могут представить веские основания для того, чтобы отказаться от этой процедуры. А можно ли виртуализировать Active Directory (AD)? Следует ли делать виртуальным весь лес AD или только его часть?

Каталоги виртуальные и физические

Первый и самый важный вопрос формулируется так: поддерживает ли Microsoft виртуальные контроллеры доменов (VDC)? Ведь если вы переведете часть жизненно важной инфраструктуры в официально не поддерживаемую среду, ваша карьера будет явно под угрозой. К счастью, Microsoft поддерживает VDC как часть серверного программного обеспечения на продуктах виртуализации как собственной разработки, так и созданных сторонними производителями; с подробным описанием политики поддержки можно ознакомиться в подготовленной сотрудниками Microsoft статье «Microsoft server software and supported virtualization environments» (support.microsoft.com/kb/957006). Но имейте в виду, что существует ряд важных рекомендаций, на которые следует обратить внимание. Ведь, даже удостоверившись, что та или иная среда поддерживается производителем, вы не можете застраховать себя от неприятностей. Конечно, сотрудники подразделения Microsoft Problem Resolution Services будут рады помочь вам — за соответствующее вознаграждение, но, если вы будете следовать сформулированным в данной статье рекомендациям, их помощь вам не потребуется.

Вам придется принять решение о том, в каких случаях нужно виртуализировать контроллер домена, а в каких — оставлять его в физической форме. По большому счету такой фактор, как рабочие характеристики, здесь уже не нужно принимать во внимание: разработанные компаниями VMware и Microsoft 64?разрядные гипервизоры обеспечивают превосходную производительность по сравнению с физическими компонентами; к примеру, в статье Microsoft «Performance and capacity requirements for Hyper-V» (technet.microsoft.com/library/dd277865 (office.12).aspx) приводятся результаты работы Microsoft Office SharePoint Server 2007 в виртуальной среде. Виртуальные кластеры на хосте дают возможность использовать такие средства, как VMware VMotion или Hyper-V Live Migration, позволяющие создавать высокодоступные контроллеры доменов с большей легкостью, чем когда-либо раньше. И все же, как я полагаю, существуют две веские причины для того, чтобы сохранять в лесу по крайней мере несколько физических контроллеров доменов: эти причины — отказоустойчивость и безопасность.

AD — отказоустойчивая система, ибо она является распределенной. Компания может иметь любое число контроллеров доменов, предоставляющих службу AD, — от рекомендуемого минимума в два DC до сотен контроллеров. Домен или лес могут продолжать функционировать после выхода из строя одного или большего числа контроллеров доменов, поскольку ни один из них не содержит уникальных данных, которые нельзя было бы восстановить или переустановить каким-либо иным образом. В сетях, где служба AD организована без применения средств виртуализации, отказоустойчивость реализуется по определению, поскольку каждый контроллер домена представляет собой отдельную физическую систему и эти системы размещаются в различных местах. При использовании виртуальной инфраструктуры ситуация иная. К примеру, на одной хост-системе может размещаться несколько контроллеров доменов, и в случае отказа этой системы все они могут выйти из строя. Или такой пример. Допустим, в соответствии со стандартным планом виртуализации вашей компании все серверы должны задействовать не локальные диски, а сети устройств хранения данных SAN. Из этого следует, что при выходе из строя сети SAN под угрозой оказывается функционирование большинства компонентов службы AD или вся служба целиком. Более подробную информацию о средствах хранения данных для AD можно найти во врезке «Контроллеры доменов: чем проще хранилище, тем лучше». Так что при составлении плана виртуализации для леса AD вам следует внимательно присмотреться к поддерживающей инфраструктуре и сотрудничать со специалистами по виртуализации, чтобы исключить возможность появления точек отказа. О диктуемых соображениями безопасности основаниях для того, чтобы не осуществлять виртуализацию контроллеров доменов, я расскажу ниже.

Я рекомендую оставлять в каждом домене по меньшей мере по два физических контроллера; один из них должен быть главным контроллером домена — владельцем соответствующей роли Flexible Single-Master Operation (FSMO) — хозяином PDC. Даже в случае сбоя, затрагивающего всю виртуальную инфраструктуру, такая архитектура гарантирует, что в вашем распоряжении будет полностью функциональный домен с распределенной отказоустойчивостью. Решайте сами, какой запас прочности вам может потребоваться. Но имейте в виду: расходы на эксплуатацию двух физических серверов не идут ни в какое сравнение с потенциальным ущербом, который понесет ваша компания в случае выхода из строя целого домена.

Создание и развертывание виртуальных контроллеров доменов

Итак, вы определили, какие контроллеры следует виртуализировать. Что ж, пришло время настроить ваши виртуальные контроллеры доменов. С технической точки зрения это достаточно просто. Если ваши контроллеры доменов функционируют под управлением систем Windows Server 2008 или Server 2008 R2, рассмотрите возможность использования в качестве операционной системы версию Server Core, характеризующуюся малой площадью атаки. Для процессора и памяти установите такие требования, которые способны обеспечить эмуляцию текущей конфигурации — или конфигурации, которую вы хотели бы иметь, если бы не ограничения бюджета. Удостоверьтесь в том, что на виртуальном контроллере домена установлены средства расширения возможностей виртуальной машины для вашего средства виртуализации (например, VMware Tools). Если вы работаете с платформой Hyper-V, позаботьтесь о том, чтобы виртуальный контроллер домена был оснащен современным сетевым адаптером, а не устаревшим; новейшие сетевые интерфейсные платы имеют гораздо более высокую производительность.

Для типов жестких дисков вы можете использовать либо базовые, либо динамически расширяющиеся диски; согласно последним утверждениям представителей Microsoft, по своей производительности динамические диски Hyper-V R2 почти не уступают базовым. Однако требования к диску контроллера домена довольно статичны; поэтому, после того как вы определите оптимальный размер диска для вашего контроллера домена — опираясь на данные об использовании диска физического контроллера домена, — я рекомендую создать базовый диск того же размера. Кэширование записей на томах, содержащих базы данных AD и регистрационные файлы, по умолчанию отключено, для того чтобы прерывания в процессе ввода-вывода не приводили к повреждению данных.

Кроме того, стоит рассмотреть возможность развертывания в вашем лесу контроллеров доменов только для чтения, Read-Only Domain Controllers (RODC). Такой контроллер имеет лишь копию AD, предназначенную для чтения; пароли по умолчанию не предусмотрены. В результате снимается острота некоторых проблем обеспечения безопасности, связанных с эксплуатацией виртуальных контроллеров доменов. Для функционирования RODC требуется, по меньшей мере, версия Server 2008.

На своем VDC отключите функцию Synchronize time with host. Контроллеры доменов имеют собственную архитектуру синхронизации времени, и другие варианты синхронизации им не требуются. Если вы используете платформу Hyper-V, проследите за тем, чтобы антивирусная программа в родительском разделе исключала из проверок файлы VHD, расположенные в дочерних разделах, иначе при попытках запуска виртуальных машин вы можете столкнуться с проблемой снижения производительности и с сообщениями об ошибках.

Виртуальный контроллер домена можно разворачивать таким же образом, как и другие виртуальные машины, — как правило, с помощью средства управления, например Microsoft System Center Virtual Machine Manager (VMM) или VMware vCenter. Есле же вам требуется создать контроллер домена и широко использовать средства автоматизации, вы можете создать сценарий, предписывающий процессу Dcpromo выполняться факультативно по завершении развертывания; см. статьи Microsoft «Configuring the Automatic Installation of Active Directory» (tinyurl.com/22umult) и «How to Configure Guest Operating System Profile Scripts» (tinyurl.com/2fzotwg).

Администрирование виртуальных контроллеров

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

Почему? Не забывайте, что AD — распределенная система. Если бы служба AD размещалась всего на одном контроллере домена, упомянутые операции можно было бы выполнять безо всяких опасений. Но поскольку различные контроллеры доменов внутри домена или леса должны взаимодействовать друг с другом, каждый контроллер домена должен иметь четкое представление о состоянии любого другого контроллера домена. Средства виртуализации, такие как моментальные снимки, функции восстановления на основе образов и средства клонирования, не передают сведений об изменении состояния службе каталога на целевой виртуальной машине; последняя не имеет представления о том, как ее изменили, а значит, об этом не знают и ее партнеры по процедуре репликации. Это обстоятельство может привести к полному разрушению домена или леса. Давайте посмотрим, какие операции по виртуализации контроллеров доменов поддерживаются, а какие — нет.

Резервные копии на основе образов (резервные копии на основе хостов). Восстановление с резервных копий на основе образов, в ходе которого администратор копирует либо иным образом резервирует содержащие VDC файлы виртуального жесткого диска, не поддерживается (за одним исключением). При выполнении такого рода операций операционная система и база данных AD возвращаются в предшествующее состояние без переустановки идентификатора вызова (версии локальной базы данных), так что всем остальным контроллерам домена ничего не известно о восстановлении целевого контроллера домена. В этой ситуации нарушается целостность данных AD, могут возникать устаревшие объекты, а также сценарии с возвратом номеров последовательного обновления update sequence number (USN); более подробные сведения об этой проблеме можно найти в подготовленной сотрудниками Microsoft статье «How to detect and recover from a USN rollback in Windows Server 2003» (support.microsoft.com/kb/875495).

Исключение составляет тот случай, когда в гостевой операционной системе выполняется система Windows Server 2003 или более новые версии, и утилита резервного копирования на хосте, скажем Windows Server Backup, вызывает гостевой модуль записи службы VSS (Volume Shadow Copy Service), чтобы гарантировать корректное резервирование гостевой системы. Windows 2003 была первой операционной системой, включающей эту службу. Гостевой модуль записи VSS выполняет моментальный снимок тома гостевой системы, обеспечивая тем самым целостность данных резервной копии. В случае восстановления VSS-совместимая программа восстановления извещает службу каталогов гостевой системы о том, что процедура восстановления выполнена. Во время этого процесса сбрасывается идентификатор вызова базы данных AD и партнеры по репликации данного контроллера домена извещаются о том, что восстановление состоялось, а значит, репликация, поступающая от этого контроллера, имеет законную силу.

Резервирование клиентов. Другой поддерживаемый метод резервирования содержимого виртуального контроллера домена состоит в снятии резервных копий клиентов, как это делается при работе с физическим контроллером домена. По скорости выполнения этот процесс уступает резервному копированию на основе хоста, в котором используется модуль записи VSS, однако он превосходит многие приложения резервного копирования на основе хоста в том отношении, что позволяет восстанавливать индивидуальные файлы в гостевой системе. Большинство таких приложений не поддерживают восстановление данных на уровне файлов, но наиболее развитые из них (например, Microsoft System Center Data Protection Manager 2010) также позволяют восстанавливать индивидуальные файлы гостевых операционных систем, поддерживающих VSS. Специалисты Microsoft привели свои рекомендации по резервному копированию и восстановлению виртуальных контроллеров доменов в статье «Backup and Restore Considerations for Virtualized Domain Controllers» (tinyurl.com/ydw8b5w).

А нужно ли резервировать содержимое каждого VDC? Мне представляется, что в небольших лесах целесообразно делать резервные копии состояния системы двух контроллеров в каждом домене. В лесах большего размера с крупными (свыше 5 Гбайт) базами данных AD (ntds.dit) или с географически рассредоточенными контроллерами доменов требуется большее количество. Здесь нужно руководствоваться следующим принципом: резервная копия должна находиться в той же локальной сети, что и контроллер домена, — это дает возможность ускорять процесс выполнения Dcpromo с использованием резервных носителей информации. Если у вас по какой-либо причине выйдет из строя тот или иной виртуальный контроллер домена, имейте в виду, что существуют более быстрые методы восстановления, чем восстановление с резервной копии. Информацию о других вариантах можно найти на странице DC Recovery моего ресурса Active Directory Recovery Flowchart по адресу tinyurl.com/adrecovery.

Моментальные снимки виртуальных машин. Восстановление виртуальных контроллеров доменов с использованием моментальных снимков виртуальных машин не поддерживается. Эти моментальные снимки (не путать с моментальными снимками каталогов, выполняемыми с помощью Ntdsutil, а также с моментальными снимками томов, выполняемыми с помощью VSS) формируются посредством ввода данных о состоянии виртуальной машины на определенный момент времени. При восстановлении виртуального контроллера домена до его предшествующего состояния с помощью сохраненного моментального снимка в каталоге возникают те же ошибки несоответствия, что и при резервировании на основе образа.

Клонирование. Клонирование контроллера домена посредством дублирования файла жесткого диска VDC не поддерживается. Если клонированный VDC подключается к сети в том же лесу, что и исходный контроллер, и вы разрешаете тут же возникающие проблемы с идентичными именами серверов и IP-адресами, перед вами встанут проблемы с повторяющимися глобальными уникальными идентификаторами агента службы каталога Directory Service Agent (DSA), повторяющимися идентификаторами безопасности, повторяющимися пулами относительных идентификаторов Relative Identifier (RID), причем ситуация усугубляется в случае, когда клонированный VDC является хозяином роли RID — c проблемами защищенного канала, с обновлениями пароля учетной записи системы — словом, лучше со всем этим не связываться.

Преобразование физического объекта в виртуальный (physical to virtual conversion, P2V). Преобразование типа P2V поддерживается, но лишь в том случае, если исходный физический контроллер домена не подключен к сети; это требование поддерживает VMM 2008. При преобразовании P2V контроллера домена в ситуации, когда исходный контроллер подключен к сети, возникают те же проблемы, что и при клонировании. В целом я считаю, что подготовка и повышение уровня нового виртуального контроллера домена связаны с меньшим риском и выполняются почти так же быстро, как преобразование P2V существующего контроллера домена.

Приостановка. Приостановка виртуального контроллера домена (то есть перевод его в автономное состояние), в сущности, допускается, но «не приостанавливайте контроллер домена на длительное время», как говорится в статье Microsoft «Considerations when hosting Active Directory domain controller in virtual hosting environments» (support.microsoft.com/kb/888794). Что происходит во время приостановки контроллера домена? С точки зрения его партнеров по репликации, контроллер внезапно изымается из сети — как если бы кто-то выдернул сетевой кабель. Когда приостановленный контроллер домена вновь «оживает», создается впечатление, что произошел скачок во времени. Срок действия его билетов Kerberos истек, системные пароли, возможно, требуют обновления, а если приостановка длилась дольше времени жизни отмеченного для полного удаления объекта, контроллер уже нельзя использовать для репликации, его нужно перестраивать. Я бы рекомендовал не злоупотреблять приостановками работы контроллера домена и следить за тем, чтобы паузы не были слишком длинными.

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

Безопасность виртуальных контроллеров доменов

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

Защита виртуальных дисков. Доступ к виртуальным дискам VDC равнозначен предоставлению физического доступа к физическому контроллеру домена; если вы предоставляете такой доступ, то уже не можете гарантировать безопасность. Доступ к файлам этих виртуальных дисков должен быть соответствующим образом защищен, особенно с учетом того обстоятельства, что в соответствии с потребностями администрации виртуального хоста доступ к ним будет требоваться большему числу людей. Следовательно, администраторы хостов, администраторы филиалов, администраторы хранилищ сетей SAN и администраторы центров обработки данных — все это группы, членов которых, возможно, придется вносить в список служащих, имеющих доступ к данным корпоративных каталогов.

Доступ через консоль. Админи­стра­торам DC следует предоставлять доступ к виртуальным контроллерам доменов через консоль — таким же образом, каким они получали бы доступ к физическим DC через внешнюю консольную утилиту, не требующую установки операционной системы. В организациях, эксплуатирующих продукты VMware, управлять доступом через консоль можно с помощью vCenter Server, а в компаниях, где используется платформа Hyper-V, с этой целью можно применять диспетчер Authorization Manager (AzMan) или портал VMM Self-Service Portal.

Сведения о состоянии контроллеров доменов. Образно выражаясь, полнофункциональные виртуальные DC содержат «ключи от всего королевства», и сотрудники с правами административного доступа к хосту имеют возможность влиять и, возможно, мешать работе VDC на этом хосте. Важно довести до всех сотрудников, имеющих доступ к хостам, информацию о последствиях, вытекающих из того факта, что на их физических серверах размещаются контроллеры доменов.

Контроллеры доменов только для чтения RODC. Угрозы безопасности, связанные с эксплуатацией виртуальных контроллеров доменов, можно снизить, развертывая везде, где это возможно, системы RODC вместо полнофункциональных DC. Контроллеры RODC не выполняют записей в AD и, кроме того, по умолчанию пароли для учетных записей пользователей и компьютеров на них не реплицируются. Так, если, к примеру, файл виртуального жесткого диска RODC попадет в руки злоумышленника, последний не сможет получить из него пароли. Повреждение файла жесткого диска RODC не может нанести ущерб остальным системам леса; к тому же ни одно из изменений, внесенных в этот контроллер, не будет реплицироваться на остальные контроллеры доменов леса. Это не означает, что, если содержимое RODC попадет в чужие руки, сей факт не будет иметь никаких отрицательных последствий, ведь будут раскрыты организационные структуры, записи DNS — масса сведений, которые лучше держать подальше от посторонних глаз.

Предварительная подготовка

Виртуализация части инфраструктуры AD может быть выгодна для корпорации, но администратору AD она не сулит никаких преимуществ. Конечно, эту операцию можно осуществить, и Microsoft ее поддерживает, но, перед тем как приступать к виртуализации, следует провести тщательную подготовку. Основные файлы документации Microsoft по VDC можно найти в статье TechNet «Running Domain Controllers in Hyper-V» (tinyurl.com/2fm7hd8). Не подвергайте VDC каким-либо манипуляциям, непонятным для их служб каталогов, и помните, что преимущества, которые несет виртуализация контроллеров доменов, оборачиваются необходимостью прилагать дополнительные усилия по обеспечению их безопасности.

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