Виртуализация контроллера домена

Question

[tentakle]

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

Answer 1

[Speedimon]

Тут все зависит от масштабов инфраструктуры и ее особенностей. Почему вообще советуют виртуализовать DC? Ответ прост — это очень слабая нагрузка для сервера даже в масштабах достаточно большой службы каталогов, и любой относительно современный сервер будет тупо простаивать если сделать DC на самом хосте. С другой стороны, с точки зрения безопасности — не очень хорошо на сервер контроллера домена вешать что-либо еще. В случае виртуализации надо понимать одну вещь — наш DC должен в случае чего запуститься. И если мы делаем его виртуальным, а потом сам хост на котором он расположен включаем в домен — это до первого падения сервера. Поэтому с одним хостом — никогда так делать нельзя.
Рассмотрим второй вариант — у нас например 3 хоста с Hyper-V, вот в этом случае уже можно поднять 3 виртуальных DC (им по одному виртуальному процессору и 512 Мб памяти хватит, поверьте) и включить сами хосты Hyper-V в домен. В этой конфигурации если даже хост падает — на каком-то другом хосте контроллер будет живой и наш упавший сможет загрузиться и поднять виртуалку со своим контроллером.
Если же компания большая — там могут быть десятки DC, и опасность того что не будет «живого» DC вообще сводится к нулю. Если интересует конкретная реализация — могу посоветовать, пишите в личку, AD и Hyper-V это как раз то чем я занимаюсь.
Ну и в общем случае надо всегда помнить принцип KISS (Keep It Stupid Simple): если у вас всего пара Hyper-V хостов — оставьте их просто в рабочей группе, автоматизации там сильно не нужно, но зато от варианта когда нет DC и не можем загрузить Hyper-V-хост — будете избавлены.

Comments

[tentakle]

Спасибо. Именно то, что хотел узнать.

[Speedimon]

И да, забыл упомянуть — для контроллеров домена желательно выключить фичу синхронизации времени с хостом через Hyper-V, это официальная рекомендация Microsoft. Но вот некоторые наоборот говорят что выключать не надо, например тут интересный пост на эту тему — kevingreeneitblog.blogspot.com/2011/01/hyper-v-time-synchronization-on-windows.html. В идеале надо просто понимать как время расползается по инфраструктуре, оно идет от контроллера с ролью эмулятора PDC и синхронизируется со всеми DC. При этом если хосты Hyper-V в домене — они будут брать время от ближайшего DC, а потом через службу синхронизации корректировать время на своих виртуалках. Самая опасная ситуация тут как мне видится — когда роль PDC-эмулятора расположена на виртуалке, которая на хосте, включенном в домен. Тогда получится некоторое «кольцо» в синхронизации времени. В любом случае я бы отключил синхронизацию времени с хостом для виртуалки с PDC-эмулятор-ролью и настроил её синхронизацию с внешним достоверным источником времени, так спокойнее.

Answer 2

[Gasoid]

виндоус сервер ставим в hyper-v, далее на виртуалке настраиваем контроллер домена,

Comments

[tentakle]

Hyper-v остается в рабочей группе.

[Иван Тихонов]

С точки зрения того, что в небольших компаниях хост- серверов не так много обычно, я бы не рекомендовал их вводить в домен. Да, DC как виртуалка- удобно, но если нет необходимости постоянно рулить большим количеством хост-серверов, то нечего им делать в домене. Будет много всяких подводных камней, от того же времени до необходимости ковырять групповые политики(или перекидывать в соответствующие OU), чтобы запретить пользователям домена заходить на хост-серверы.

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