Шон Дьюби (sdeuby@windowsitpro.com)- старший аналитик в компании Platform Vision с 25-летним стажем работы в области корпоративных информационных систем. Внештатный редактор Windows IT Pro, имеет звание MVP
Вы уже освоились с виртуализацией Active Directory? Если да, то выполняете ли вы рекомендации Microsoft относительно того, что следует при этом делать? .
ИТ-специалистам хорошо известно, что виртуализация проникает во все аспекты информационной службы. Самая старая и наиболее развитая область виртуализации – на уровне сервера. А поскольку виртуализация – один из основополагающих аспектов «облака», это еще быстрее расширяет сферу ее применения.
Если вы – администратор AD, то группа, отвечающая за виртуализацию, стремится подвести вас к виртуализации всех контроллеров домена (DC) AD. Администраторы AD обычно не склонны к риску (однажды при проведении обновления я ухитрился в одно мгновение сделать 30 000 учетных записей пользователей компании Intel, несмотря на многоуровневые меры предосторожности), поэтому вашей первой реакцией, скорее всего, будет отказ. Однако специалисты по виртуализации упрямы, и им нужно убедительное обоснование отказа от преобразования контроллеров всего леса AD в виртуальные машины. Работая в компании Intel, я успешно отстаивал свою позицию. В то время можно было ссылаться на две веские причины, и хотя они сегодня все еще актуальны, одна из них уже отходит в прошлое.
Причины для осторожности в отношении виртуализации AD
Безопасность – первый повод для отказа от виртуализации. Когда я противился специалистам по виртуализации, обеспокоенность в сфере безопасности вызывали два аспекта: изоляция гостевых виртуальных машин и администрирование хоста. Что касается безопасного сосуществования гостевых виртуальных машин, то здесь тревога была связана с отсутствием уверенности в том, что одна виртуальная машина не может получить доступ к другой. По мере развития виртуализации серверов это опасение практически осталось в прошлом. Однако второй аспект, связанный с операционной безопасностью администрирования хоста, сегодня актуален и останется таковым в обозримом будущем.
Операционная безопасность администрирования хоста открывает простор для рассуждений о том, что администраторы сервера узла виртуализации могут не все знать об обслуживании и поддержке виртуализованных DC AD. Используя любую версию Windows Server, администратор хост-сервера или администратор по виртуализации действительно может вывести из строя действующую систему AD, применяя какие-либо базовые возможности, предлагаемые любым продуктом виртуализации: восстановление на основе образа, отмена с применением моментальных снимков, дубликаты виртуальных DC и т.д.
Распределенный характер AD в Windows Server 2008 R2 и более ранних версиях не позволяет системе понять, как продукты виртуализации способны изменить состояние виртуального DC. А поскольку этого нельзя понять и средств обработки этих изменений не предусмотрено, логическая структура распределенной системы может потерять свою целостность, в частности, в форме отмены присвоения USN. Такую проблему целостности данных AD трудно обнаружить, а еще труднее устранить ее последствия. В Microsoft разработан подробный документ на тему виртуализованных DC «Running Domain Controllers in Hyper-V». Этот документ включает раздел об отмене присвоения USN. Если вы подозреваете, что уже стали жертвой невозможности отмены USN, то прочитайте статью Microsoft «How to detect and recover from a USN rollback in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2», чтобы получить узнать, как решить эту проблему.
Как Server 2012 делает виртуализацию AD безопасной
Обеспечение полной безопасности AD в виртуализованной среде было главной задачей группы разработчиков AD, и в Server 2012 эта задача решена. Обеспечена не только безопасность, но и способность AD в полной мере использовать преимущества виртуализации. Идея решения проста. Вначале необходима осведомленность DC об отмене сделанных ранее действий. Затем DC должен принять меры по сохранению целостности и продолжению нормального функционирования.
Для выполнения первого шага слой, где осуществляется изменение (гипервизор), должен устанавливать флаг, указывающий на то, что произошла отмена сделанных изменений, и передавать его через стек виртуализации. Затем приложение должно распознать этот флаг. Этот процесс, конечно, требует внесения конструкционных изменений в гипервизор, операционную систему и приложение AD. Механизм создания флага реализуется с помощью уникального идентификатора VM-Generation ID.
VM-GenerationID (или VM Gen ID) представляет собой 128-разрядную величину, фиксируемую в гипервизоре и представляющую текущее состояние виртуальной машины. Пока виртуальная машина меняется во времени без прерываний, VM Gen ID не меняется. Если же виртуальная машина «отматывает» сделанные действия назад (восстановление на основе образа или применение моментального снимка), то значение идентификатора изменяется. Этот идентификатор ассоциирован с адресом в памяти виртуальной машины и в любой момент доступен для приложений, работающих в виртуальной машине. Как DC узнает об изменении VM Gen ID? При первоначальном повышении роли сервера до DC в Server 2012 значение VM Gen ID сохраняется как значение атрибута msDS-GenerationID на объекте-компьютере DC в его копии AD в ходе установки DC. При каждой перезагрузке DC или обработке транзакции (например, при обновлении атрибута) DC сравнивает текущее значение VM Gen ID в памяти со значением, хранящимся в AD. Если значения различаются, это указывает на то, что виртуальная машина совершила возврат во времени, и DC должен принять определенные меры для сохранения целостности. Идентификатор VM Gen ID не зависит от гипервизора, и другие поставщики гипервизоров (например, VMware) встраивают этот механизм в свои продукты.
Обнаружив возврат состояния виртуальной машины, DC выполняет два действия по предотвращению отмены USN, а именно, сбрасывает идентификатор invocationID базы данных AD и выгружает локальный пул относительных идентификаторов (RID). Сброс invocationID (номер версии локальной базы данных) аналогичен действию, инициируемому при запуске нормального процесса восстановления DC, а другие механизмы вводятся, чтобы гарантировать на DC реализацию последних обновлений – как пришедших от других DC, с которыми данный DC связан репликацией, так и созданных им самим (но информация о них утрачена из-за отмены последних действий). Пул RID – это совокупность нескольких сотен относительных идентификаторов (составляющих часть уникального доменного SID), назначаемых DC, мастером RID, для формирования SID при создании новых участников безопасности на DC. Выгрузка пула RID и запрос нового назначения от мастера RID исключает создание дублированных SID в домене. Заметим, однако, что это не освобождает от необходимости регулярно создавать резервные копии!
Таким образом, с технологической точки зрения AD станет полностью виртуализуемой, хотя на момент написания статьи группа разработчиков AD в Microsoft еще не решила, будет ли это сделано на официальном уровне. Прежде чем принять решение о полной виртуализации AD, необходимо оценить общую картину. Современный информационный центр имеет (или наверняка будет иметь) различные слои абстракции взаимосвязей между службой AD и оборудованием, которое повсеместно подвержено отказам. Помня о принципе «не класть все яйца в одну корзину», проанализируйте каждый уровень, являющийся нижестоящим по отношению к вашей службе, проработайте все возможные сценарии отказов на всех уровнях и их влияние на службу и соответствующим образом спланируйте конфигурацию службы. В частности, рассмотрите реализацию нескольких решений виртуализации для некоторых критически важных частей инфраструктуры, чтобы проблема одного из них (например, неисправный драйвер в ядре VMware ESXi или проблема, вызывающая фатальный сбой родительского раздела Hyper-V) не стала единичной точкой отказа службы. Аналогичным образом, даже в случае нахождения виртуальных машин на разных узлах и при использовании различных технологий виртуализации, если виртуальные жесткие диски хранятся в одной сети хранения SAN, то возникает единичная точка отказа. Если единственный способ минимизировать негативный сценарий предполагает наличие несколько физических DC, не отказывайтесь от этого! Отвечая на возражения со стороны группы виртуализации, сошлитесь на то, что стоимость обслуживания нескольких физических устройств ничтожна по сравнению с риском тотальной неспособности всех сотрудников корпорации однажды утром зарегистрироваться в системе.
Доменная служба Active Directory (AD DS), реализованная в Server 2012, устраняет один из поводов для беспокойства. Однако любое нововведение необходимо проанализировать в контексте существующей инфраструктуры и решить, как наилучшим образом использовать его.