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

Введение

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

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

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

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

Один из возможных подходов — настроить два физических сервера в качестве контроллеров домена для вашего рабочего домена. Затем вы можете настроить один из двух физических контроллеров домена для работы в качестве интегрированного DNS-сервера Active Directory.

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

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

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

Еще одна проблема, которую вам придется рассмотреть, если вы будете следовать этому подходу, — это роль гибких одиночных основных операций. Windows 2000 Server и более поздние версии используют модель репликации с несколькими мастерами, в которой обновления базы данных Active Directory могут быть записаны на любой доступный контроллер домена. Тем не менее, некоторые контроллеры домена считаются более важными, чем другие. Контроллеры домена, которым назначены гибкие операционные роли с одним хозяином, отвечают за поддержание целостности Active Directory. Например, контроллер домена, которому принадлежит роль хозяина схемы, отвечает за поддержку схемы Active Directory. Все изменения схемы должны быть записаны на этот контроллер домена.

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

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

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

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

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

Причина, по которой я считаю безопасным виртуализировать контроллер домена, содержащий роли Flexible Single Master Operations, заключается в том, что сбой этого контроллера домена не является катастрофическим (при условии, что в сети есть другие контроллеры домена). Пока некоторые контроллеры домена и DNS-сервер остаются в вашей сети, Active Directory будет продолжать нормально функционировать некоторое время.

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

Вывод

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