Должен ли я иметь физический DC, даже после Server 2012?


30

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

Одним из оправданий этого было то, что если ваши хосты Hyper-V были кластеризованы, то для них требовался доступ к DC во время загрузки. Это имеет полное значение для меня.

Тем не менее, я часто слышу, как люди говорят, что все еще важно иметь физический DC, даже если у вас нет кластерной установки (скажем, например, в простой установке с одним сервером Hyper-V, на котором работает пара виртуальных машин, одна из которых является DC). Это оправдывало впечатление (и я никогда не мог быть полностью уверен), что у вас все еще будет проблема в том смысле, что при первой загрузке хоста Hyper-V в сети нет постоянного тока. Кэшированные учетные данные означают, что вы все еще можете войти в систему, но как насчет всех тех битов, которые происходят во время загрузки, которые означают, что наличие постоянного тока полезно? Это на самом деле проблема? Есть ли на самом деле какие-либо операции, которые могут выполняться толькопри загрузке это вызовет проблему? Какие-нибудь групповые политики, например? В основном я спрашиваю: действительно ли физический аргумент DC действительно удерживает воду, когда задействована кластеризация, или существовал (до 2012 года) существенный технический аргумент для этого без кластеризации? Эта статья из Altaro (см. Раздел «Миф о курице и яйце») предполагает, что в этом нет необходимости, но я все еще не уверен.

Теперь ко второй (и основной) части моего вопроса:

Windows Server 2012 представил несколько функций, направленных на решение проблем виртуализации контроллеров домена, в том числе:

  1. Идентификатор генерации виртуальной машины - устранение проблемы отката USN, которая означала, что моментальный снимок (или, точнее, откат к моментальному снимку) не был поддержан / действительно плохая идея
  2. Cluster Bootstrapping - это решение проблемы «курицы и яйца», связанной с отказоустойчивой кластеризацией, о которой я упоминал выше. Отказоустойчивая кластеризация больше не требует наличия постоянного тока во время загрузки.

Так что мой второй вопрос похож на первый, но на этот раз на 2012+. Предполагая, что vDC и хост 2012+, и вы исключаете кластеризацию из уравнения, есть ли другие проблемы, подобные упомянутым выше, которые означают, что я все еще должен рассмотреть физический DC? Должен ли я по-прежнему подумывать о том, чтобы иметь физический DC рядом с моим единственным некластеризованным хостом 2012 / 2012R2 Hyper-V, на котором установлен один виртуализированный DC? Я слышал, что некоторые люди предлагают разместить AD на хосте Hyper-V, но мне не нравится эта идея по разным причинам (кеш WB отключен для начала).

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

ОБНОВИТЬ:

Прочитав некоторые ответы, мне пришло в голову, что я могу сформулировать вещи немного по-другому, чтобы понять суть того, что я спрашиваю:

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


4
Лично я бы никогда не установил AD на ваш хост Hyper-V. Возьмите все, что связано с кластером, на данный момент. Вы теряете свой единственный виртуальный контроллер домена - вы теряете свой единственный источник DNS.
PnP

Ответы:


11

Я бы тоже не сделал хост Hyper-V DC.

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

Есть способы ограничить вашу «подверженность» при виртуализации контроллеров домена. Одним из способов является развертывание нескольких контроллеров домена на разных хостах в кластере и использование анти-сходства, чтобы разделить их в случае сбоя хоста (в зависимости от того, сколько хостов в кластере).

Хотя ответ Грега содержит ссылку на некоторые рекомендации MS, этой статье, тем не менее, два года, и она касается Windows Server 2008 и 2008 R2. Я бы не стал считать эту статью лучшей практикой в ​​отношении Windows Server 2012 и 2012 R2. Я не могу найти официальный документ MS, но этот парень считается ведущим авторитетом в Hyper-V - http://www.aidanfinn.com/?p=13171


Спасибо, Джо. Я на самом деле прочитал статью Эйдана некоторое время назад, и она частично дала ответ на мой вопрос. Что меня поразило, так это то, что, следуя ему логически, на физическом DC до 2012 года не было и дела, если только вы не запустили кластерную среду (за исключением, возможно, подготовки установки «готов к кластеру»). Вот почему я добавил еще кое-что о людях, которые до сих пор оправдывают необходимость в pDC даже без кластеризации, которая, похоже, не изменилась с 2012 года.
dbr

согласитесь ли вы с моим комментарием, что если вы решите проблему с кластеризацией, ситуация в действительности не изменилась между 2008 и 2012 годами?
февраля

@dbr Я бы только добавил к ответу Джо, что для hyper-v (не xen или esx) я бы тестировал hyper-v mmc раньше. Как это случилось со мной, мертвый хост с DC на нем и hyperv mmc нуждался в живом AD, чтобы открыться. Я застрял, даже если вошел в систему как администратор домена с кэшированными учетными данными. Может быть исправлено с последним обновлением, но это важный факт. (в отличие от esx, который может использовать встроенного пользователя, поскольку вы все еще можете открыть vsphere или vcenter)
yagmoth555 - GoFundMe Monica

Просто нужно добавить другие способы повышения устойчивости: иметь более одного хост-кластера виртуализации (либо в одном и том же месте, либо в другом месте) и / или создать VPN для Azure (или AWS - у Azure есть несколько преимуществ для магазинов MS) и поставить один или два DC там.
Тодд Уилкокс

18

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

https://technet.microsoft.com/en-us/library/virtual_active_directory_domain_controller_virtualization_hyperv%28v=ws.10%29.aspx

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


2
Хотя не уверен, что это имеет смысл - посмотрите, например, я знаю, что компания, которая на 100% виртуальна с DC, регулярно делает резервные копии и имеет 3 постоянных тока на 2 континентах (2 в Европе, 1 в США) .... трудно представить здесь что-нибудь, что дует таким образом, что вещи невозможно восстановить.
TomTom

Я предполагаю, что смысл, который они пытаются высказать, заключается в том, что если есть какая-то проблема, которая затрагивает Hyper-V в целом, то вы (временно) облажаетесь, пока не сможете восстановить DC, тогда как наличие pDC означало бы меньше разрушений. Не уверен, что я бы согласился, так как вы все равно были бы облажаны, если бы была проблема с перебоями в Hyper-V!
DBR

1
Приятно и модно, но опять же совершенно не имеет значения, ЕСЛИ тогда у вас нет значительной части вашей инфраструктуры вне Hyper-V. DC работает, но файловые ресурсы, sharepoint, exchange, печать и все остальное не работает - это означает, что мне, скорее всего, наплевать на то, что DC снова будет работать; обе стороны (Hyper-V и физическая).
TomTom

@TomTom Это то, к чему я клонил с моим комментарием «в любом случае, вы были бы чертовски милы» :) Я предполагал, что почти все остальное будет виртуализировано в любом случае. Полностью согласен, что все сводится к тому, чтобы «иметь несколько DC и делать резервные копии»
dbr

Компания @TomTom, в которой я работаю, полностью виртуальна и для инфраструктуры AD. И так было с W2K3. Но мы не используем HyperV: ESX полностью. 2 отдельных набора кластерной инфраструктуры ESX на каждом континенте. Каждый домен имеет (как минимум) 3 DC: 1 DC на другом континенте и 1 DC в каждой из 2 сред ESX на «домашнем» континенте.
Тонни

10

Я чувствую, что вы ищете однострочный ответ, так что вот оно:

У вас должен быть физический DC, если вы не доверяете способности вашей виртуальной среды противостоять сбоям.

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


3

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

Должен ли я по-прежнему подумывать о том, чтобы иметь физический DC рядом с моим единственным некластеризованным хостом 2012 / 2012R2 Hyper-V, на котором установлен один виртуализированный DC?

Почему, почему, почему, вы хотите один DC? В любой конкретной среде мы стараемся избегать единой точки отказа для любой данной инфраструктуры. Контроллеры домена - ваш хлеб и масло - они предоставляют DNS, основу Active Directory. Серьезно, восстановите настольный ПК с Windows 7 на 2008R2 и продвигайте его. Существует всегда сильный случай для физического DC.

Hyper-V с AD DS? Нет, просто нет. Во-первых, Microsoft не поддерживает это. Во-вторых, как вы упомянули, обработка резервных копий станет проблемой, зависящей от конфигурации вашего диска. Не говоря уже о том, что прелесть виртуализации заключается в том, что физические хосты удаляются настолько быстро, насколько мы можем их построить (и я ценю, что dcpromo не так уж и сложен (в зависимости от размера вашей среды)), а хостинг AD ​​DS просто усложняет. вопросы. Вы также вводите другую сложность Windows Time.

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


3
Большая часть вашего ответа неоправданно критична, поскольку в ней содержатся пункты, которые полностью обоснованы, но не имеют ничего общего с вопросом. Конечно, наличие нескольких DC почти всегда является обязательным - цитируемая часть используется для иллюстрации вопроса / вопроса. Комбинация HV + AD опять-таки является лишь второстепенной запиской, и я думаю, что мне было совершенно ясно, что я не являюсь любителем комбо.
DBR

2
Если «всегда есть веские основания для физического DC». [vs. например, второй vDC] - не могли бы вы объяснить этот случай? Это действительно мой вопрос.
февраля

1

Чтобы ответить на последний вопрос о том, действительно ли это когда-либо является проблемой: я заметил, что мои хосты Hyper-V с включенным RDP, но требующие NLA, не разрешают RDP до тех пор, пока я не перезапущу службу информирования о сетевом расположении, если нет DC, когда он загружается. У меня были случайные проблемы с удаленным подключением к VMMS в этих точках, но только когда что-то еще было сломано. Когда вы не можете подключиться к RDP или удаленно подключиться к диспетчеру Hyper-V, очень сложно выяснить, что сломано, и что-то исправить. Поддержание физического DC вокруг себя предотвратило это в любой момент.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.