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

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

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

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

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

Еще одно соображение касается серверов глобального каталога. В сети с одним доменом вы можете сделать каждый контроллер домена сервером глобального каталога. Однако в больших сетях у вас должен быть хотя бы один сервер глобального каталога на каждом сайте Active Directory.

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

Сайты Active Directory

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

Я уверен, вы знаете, что каждый лес Active Directory содержит сайт по умолчанию. Если вы хотите создать дополнительные сайты, вы должны назначить один контроллер домена в каждом сайте, который будет действовать как плацдарм для сайта. Сайты объединяются путем создания сайтов-связей между серверами-плацдармами.

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

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

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

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

Некоторые заключительные мысли

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

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

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

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

В некоторых случаях вы можете обнаружить, что виртуальные серверы даже более надежны, чем физические серверы. Например, и Microsoft, и VMware предоставляют отказоустойчивые механизмы для виртуальных серверов. Например, в Hyper-V вы можете создать отказоустойчивый кластер, который будет продолжать работать, даже если один из узлов кластера выйдет из строя. Напротив, вы обычно не найдете такого уровня избыточности на физическом контроллере домена. Таким образом, виртуальный контроллер домена может быть более надежным, чем физический контроллер домена.

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

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

Вывод

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