Назад | Перейти на главную страницу

Членство в домене Active Directory для размещенного сервера и размещенных на нем виртуальных машин

Я буду настраивать единое оборудование, которое будет размещено в центре обработки данных для размещения нескольких гостей Hyper-V, на всех из которых будет установлена ​​операционная система Windows Server 2012. Я буду управлять приложениями и виртуальными машинами и следить за ними из своего офиса, где у меня всего два компьютера под управлением Windows 8.

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

В общем, мой вопрос в том, как и где мне развернуть контроллер домена. У меня не может быть очень быстрого и надежного соединения между моим офисом и центром обработки данных, поэтому я хочу, чтобы сервер продолжал работать, когда мой офис не может подключиться. Я буду использовать VPN для подключения к серверу из моего офиса (IPv6 недоступен для DirectAccess). Итак, моя логика подсказывает мне, что я должен (по крайней мере) иметь DC на размещенном сервере.

На ум приходит несколько конкретных вопросов:

  1. Должен ли я развертывать AD DS на хосте или на виртуальной машине? Мне бы очень хотелось, чтобы хост выполнял ТОЛЬКО роль Hyper-V в целях изоляции и управления.
  2. Должен ли я присоединять ОС хоста к домену? Разве не рискованно, если по какой-то причине ВМ с ролью AD DS не запускается?
  3. А как насчет избыточности AD DS? Имеет ли смысл использовать ВТОРОЙ ВМ в качестве резервного контроллера домена ?!
  4. Я знаю, что присоединение моих офисных компьютеров к удаленному контроллеру домена вызовет некоторые проблемы из-за возможности подключения, поэтому следует ли мне оставить офисные ПК в качестве рабочей группы или развернуть локальный контроллер домена, который копирует исходный?

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

Должен ли я развертывать AD DS на хосте или на виртуальной машине? Мне бы очень хотелось, чтобы хост выполнял ТОЛЬКО роль Hyper-V в целях изоляции и управления.

Без сомнения, на вашем хосте не должно быть AD DS. Определенно создайте виртуальный контроллер домена.

Должен ли я присоединять ОС хоста к домену? Разве не рискованно, если по какой-то причине ВМ с ролью AD DS не запускается?

Лично я бы не стал. Я не думаю, что с одним хостом вы получите какие-либо преимущества, а из-за отсутствия избыточности AD вы создаете опасную единую точку отказа, как вы указываете. Этот ответ меняется, когда вы масштабируете и имеете приличную инфраструктуру AD. Также убедитесь, что ваш хост настроен со статическим IP и DNS.

А как насчет избыточности AD DS? Имеет ли смысл использовать ВТОРОЙ ВМ в качестве резервного контроллера домена ?!

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

Я не собираюсь сидеть и говорить «ВЫ НЕ ДОЛЖНЫ ЭТО ДЕЛАТЬ», но вы должны знать, насколько хрупко все будет сидеть на одном хосте.

Должен ли я оставить офисные ПК в составе рабочей группы или развернуть локальный контроллер домена, который копирует исходный?

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

Хотя, это могло бы служить резервным физическим DC, что было бы неплохо.