Еще во времена, когда еще не было Windows Server 2012, казалось, что рекомендуется установить хотя бы один физический контроллер домена рядом с виртуализированными контроллерами домена.
Одно из оправданий этого заключалось в том, что если ваши хосты Hyper-V были кластеризованы, то им требовалось, чтобы DC был доступен во время загрузки. Для меня это имеет смысл.
Однако я часто слышу, как люди говорят, что по-прежнему важно иметь физический контроллер домена, даже если у вас нет кластерной настройки (например, в простой настройке с одним сервером Hyper-V, на котором работает пара виртуальных машин, одна из них DC). Обоснование для этого казалось (и я никогда не мог быть полностью уверен), что у вас все еще будет проблема в том смысле, что при первой загрузке хоста Hyper-V в сети нет DC. Кэшированные учетные данные означают, что вы все еще можете войти в систему, но как насчет всех тех битов, которые происходят во время загрузки, что означает, что наличие постоянного контроллера домена полезно? Это действительно проблема? Есть ли на самом деле какие-либо операции, которые могут выполняться только что при загрузке вызовет проблему? Например, какие-нибудь групповые политики? Я в основном спрашиваю, действительно ли аргумент о физическом постоянном токе выдерживает критику только тогда, когда задействована кластеризация, или (до 2012 года) существовал значительный технический аргумент в пользу этого без кластеризации? это статья из Altaro (см. раздел «Миф о курице и яйце») предполагает, что в этом нет необходимости, но я все еще не уверен.
А теперь перейдем ко второй (и основной) части моего вопроса:
В Windows Server 2012 появилось несколько функций, направленных на решение проблем, связанных с виртуализацией контроллеров домена, в том числе:
Итак, мой второй вопрос похож на первый, но на этот раз для 2012+. Предполагая, что и виртуальный ЦОД, и хост - 2012+, и вы исключили кластеризацию из уравнения, есть ли какие-либо другие проблемы, подобные упомянутым выше, которые означают, что мне все же следует рассматривать физический DC? Следует ли мне по-прежнему рассматривать возможность наличия физического контроллера домена рядом с моим единственным некластеризованным хостом Hyper-V 2012/2012 R2, на котором есть один виртуализированный контроллер домена? Я слышал, что некоторые люди предлагают разместить AD на хосте Hyper-V, но мне эта идея не нравится по разным причинам (для начала отключен кеш WB).
В качестве примечания в моем вопросе неявно предполагается, что имеет смысл подключить ваш хост Hyper-V к домену для улучшения управляемости. Выдерживает ли это утверждение проверку?
ОБНОВИТЬ:
Прочитав несколько ответов, мне пришло в голову, что я могу сформулировать вещи несколько иначе, чтобы понять суть того, о чем я спрашиваю:
Даже с улучшениями 2012 года и более поздних версий, факт остается фактом: без каких-либо физических или виртуальных контроллеров домена на другом хосте, хост по-прежнему загружается, когда нет доступных контроллеров домена. Это действительно проблема? В некотором смысле, я полагаю, что это тот же (или очень похожий) вопрос, если полностью исключить виртуализацию. Если вы регулярно запускаете рядовые серверы раньше любых контроллеров домена, это проблема?
Одно из оснований для сохранения одного физического контроллера домена в каждом домене заключается в том, что в случае серьезного инцидента, который влияет на хост или приводит к уничтожению хранилища кадров для виртуализированных контроллеров домена, у вас должен быть по крайней мере один физический контроллер домена с локальным хранилищем для выполнения восстановления и поддержания непрерывности. Microsoft продолжает выполнять эту проверку и давать эту рекомендацию во время RAP Active Directory (оценка и планирование рисков).
«Поддерживайте физические контроллеры домена в каждом из ваших доменов. Это снижает риск сбоя платформы виртуализации, который влияет на все хост-системы, использующие эту платформу».
Я бы тоже не стал делать хост Hyper-V DC.
Что касается того, нужен ли вам физический контроллер домена, я считаю, что с изменениями, внесенными Microsoft в отношении виртуализированных контроллеров домена в целом и начальной загрузки кластера без постоянного тока, я лично не вижу необходимости и не поддерживаю имея физический DC. Поддержание физического контроллера домена кажется нелогичным по сравнению с переходом вашей инфраструктуры на платформу виртуализации. Виртуализировать всю мою инфраструктуру, но все зависит от наличия единственного физического контроллера домена? Какой в этом смысл?
Есть способы ограничить вашу «открытость», продолжая виртуализировать контроллеры домена. Один из способов - развернуть несколько DC на разных хостах в вашем кластере и использовать анти-сродство, чтобы держать их разделенными в случае сбоя хоста (в зависимости от того, сколько хостов находится в кластере).
Хотя в ответе Грега есть ссылка на некоторые рекомендации MS, этой статье, тем не менее, два года, и она касается Windows Server 2008 и 2008 R2. Я бы не стал считать эту статью лучшей практикой в отношении Windows Server 2012 и 2012 R2. Я не могу найти официальный документ MS, но этот парень считается ведущим специалистом по Hyper-V - http://www.aidanfinn.com/?p=13171
Мне кажется, вы ищете однострочный ответ, так что вот он:
Если вы не уверены в способности виртуальной среды противостоять сбоям, вам следует иметь физический контроллер домена.
Мы могли бы подробно рассказать об особенностях и исключениях для каждого сценария, но я думаю, что это затрагивает корень вопроса.
Давайте выделим из уравнения кластеры и сосредоточимся на одной строчке в вашем вопросе, которая заставляет меня содрогаться.
Стоит ли мне все еще рассматривать возможность наличия физического контроллера домена рядом с моим единственным некластеризованным хостом Hyper-V 2012/2012 R2, который имеет не замужем виртуализированный DC на нем?
Зачем, зачем, зачем вам нужен один DC? В любой конкретной среде мы стараемся избегать единых точек отказа для любой конкретной инфраструктуры. Контроллеры домена - это ваш хлеб с маслом - они обеспечивают DNS, основу Active Directory. Серьезно, перестройте настольный ПК с Windows 7 на 2008R2 и продвигайте его. Там есть всегда веский аргумент для физического DC.
Hyper-V с AD DS? Нет, просто нет. Во-первых, Microsoft этого не поддерживает. Во-вторых, как вы упомянули, обработка резервных копий станет проблемой, зависящей от конфигурации вашего диска. Не говоря уже о том, что прелесть виртуализации заключается в возможности выводить из строя физические хосты так быстро, как мы можем их построить (и я понимаю, что dcpromo - это не большая проблема (в зависимости от размера вашей среды)), а размещение AD DS просто усложняет имеет значение. Вы также вводите еще одну сложность Windows Time.
Лично я оставляю свои автономные хосты Hyper-V вне домена, но на самом деле у меня нет реальных аргументов в пользу любой конфигурации.
Чтобы ответить на последний вопрос о том, действительно ли это когда-либо проблема: я заметил, что мои узлы Hyper-V с включенным RDP, но требующие NLA, не разрешают RDP до тех пор, пока я не перезапущу службу Network Location Awareness, если нет DC включается при загрузке. У меня также были случайные проблемы с удаленным подключением к VMMS в этих точках, но только тогда, когда что-то еще ломалось. Когда вы не можете подключиться по RDP или подключиться к диспетчеру Hyper-V удаленно, очень сложно выяснить, что сломано, и исправить что-то. Наличие физического контроллера домена предотвратило это со мной в любой момент.