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

Введение

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

Основная идея модели размещения контроллеров домена, которую я обсуждал, заключается в том, что два новых физических сервера подключаются к сети как новые контроллеры домена. Затем все ранее существовавшие контроллеры домена виртуализируются, как показано на рисунке A.

Рисунок A. Это одна из возможных моделей размещения контроллера домена.

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

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

При этом вы заметите, что каждый из контроллеров домена связан с доменом с именем Contoso.com и что контроллеры домена помечены номерами от 1 до 6. Это число представляет собой порядок, в котором контроллеры домена были изначально добавлен в домен. Например, DC1.contoso.com представляет первый контроллер домена, подключенный к сети. Таким образом, на этом контроллере домена размещаются гибкие операционные роли с одним мастером, а также он выступает в качестве основного DNS-сервера для леса/домена.

На этой диаграмме также показано, что мы подключили два физических сервера (DC5.contoso.com и DC6.contoso.com) к сети в качестве контроллеров домена до виртуализации четырех исходных контроллеров домена. Это служит двум целям. Во-первых, физические контроллеры домена обеспечивают определенную степень балансировки нагрузки, поскольку теперь запросы Active Directory распределяются между шестью контроллерами домена вместо четырех. Это может показаться пустяком, но помните, что виртуальные серверы должны конкурировать за конечный пул ресурсов. Если сеть достаточно загружена, чтобы потребовать четыре контроллера домена, то перенос части рабочей нагрузки на физические контроллеры домена, вероятно, поможет дать нашим виртуальным контроллерам домена немного передышки. Конечно, единственный способ сказать наверняка — это провести некоторый мониторинг производительности.

Однако, что более важно, добавление двух наших физических контроллеров домена помогает защитить домен от сбоя хост-сервера. Например, предположим, что произошел сбой VM-Host1.contoso.com, что привело к отключению DC1.contoso.com и DC2.contoso.com. Как вы помните, DC1.contoso.com действует как основной DNS-сервер для сети. Поскольку Active Directory полностью зависит от DNS, такой сбой может нарушить работу всей сети. Вот почему я настроил один из физических серверов в качестве вторичного DNS-сервера. Если хост-сервер, содержащий первичный DNS-сервер, выходит из строя, вторичный DNS-сервер может взять на себя управление, что предотвратит серьезный сбой.

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

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

Даже если у вас есть простая сеть, подобная этой, все равно важно распределить ваши виртуальные контроллеры домена по нескольким хостам. Чтобы понять почему, представьте, что на VM-Host1.contoso.com размещены все четыре виртуальных контроллера домена, а VM-Host2.contoso.com не существует. Теперь предположим, что на VM-Host1.contoso.com произошел катастрофический сбой.

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

Теперь, когда я объяснил, почему сеть, показанная на рисунке А, спроектирована именно так, есть еще одна проблема, о которой я хочу поговорить в этой статье. Если вы снова посмотрите на рисунок, то заметите, что оба хост-сервера (VM-Host1, Contoso.com и VM-Host2.contoso.com) являются членами домена. Это позволяет хост-серверам иметь доступ к той же информации Active Directory, что и другие серверы в сети, что потенциально значительно упрощает управление сетью.

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

Вывод

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