Решения для виртуализации контроллеров домена (часть 1)

Введение

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

Подумаешь?

Прямо сейчас вам может быть интересно, почему размещение контроллера домена является такой спорной темой. Я слышал, что размещение контроллера домена сравнивают со старым вопросом о том, что было раньше, курица или яйцо. С одной стороны, контроллеры домена устанавливают структуру Active Directory, к которой привязаны все остальные серверы Windows. С другой стороны, вам нужно создать и настроить хост-серверы виртуализации (обычно серверы Hyper-V или VMware), прежде чем вы сможете что-либо виртуализировать. Поэтому вы должны решить, должны ли ваши хост-серверы быть членами домена. Если вы решите сделать хост-серверы частью домена, вы должны выяснить, как это сделать таким образом, чтобы обеспечить стабильность сети.

Исключение хост-серверов из домена

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

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

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

В моей сети я запускаю Hyper-V на всех узлах виртуализации и использую System Center Data Protection Manager 2007 (DPM 2007) в качестве решения для резервного копирования. Проблема в том, что DPM 2007 сильно зависит от Active Directory. Это означало, что у меня не было выбора, кроме как присоединить свой сервер DPM 2007 к моему домену. В результате у DPM 2007 нет проблем с резервным копированием моих виртуальных машин, но у меня нет возможности резервного копирования хостов виртуализации в целом (по крайней мере, с DPM 2007).

Еще одна проблема с исключением узлов виртуализации из Active Directory заключается в том, что почти все программное обеспечение для управления сетью извлекает информацию из Active Directory. Таким образом, этот тип дизайна может ограничить ваши возможности по управлению хостами виртуализации с помощью любого программного обеспечения для управления.

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

Поскольку моя сеть продолжала развиваться, я решил установить System Center Virtual Machine Manager 2008 (SCVMM 2008) на сервер, на котором размещались мои лабораторные машины. Вы можете увидеть снимок экрана из консоли SCVMM 2008 на рисунке A.

Рисунок A. SCVMM 2008 не видит другие мои хост-серверы

Обратите внимание на рисунок, что в контейнере All Hosts указан только один хост-сервер, хотя в моей сети присутствует несколько хост-серверов Hyper-V. Такое поведение является прямым результатом того, что другие хост-серверы не являются членами домена. Мало того, что SCVMM 2008 не может видеть другие мои хост-серверы (или виртуальные машины, находящиеся на них, если на то пошло), вы даже не можете установить SCVMM 2008 на сервер, который не принадлежит домену.

Создать отдельный домен

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

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

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

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

Наличие отдельного домена для хост-серверов виртуализации означает, что вам понадобится по крайней мере один физический сервер, который будет действовать как контроллер домена. Конечно, иметь домен только с одним контроллером домена — рискованное предложение, поэтому в действительности вы, вероятно, выделили бы два или более физических сервера для выполнения задачи в качестве контроллеров домена.

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

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

Вывод

До сих пор я говорил о двух разных моделях размещения контроллера домена в виртуализированной среде. Хотите верьте, хотите нет, но существует множество других моделей размещения контроллеров домена, которые вы можете использовать. Подробнее об этих моделях я расскажу во второй части этой серии.