Как небольшой магазин (~ 10 ПК), у нас есть только один физический сервер. На этом физическом сервере работают две следующие виртуальные машины:
Теперь все руководства по передовой практике говорят мне, что настоятельно рекомендуется иметь второй контроллер домена AD («резервный DC»).
Размещение его на той же физической машине, что и основной контроллер домена, кажется бессмысленным, поэтому я подумал о том, чтобы разместить его как виртуальную машину на одной из более мощных рабочих станций, которая обычно работает круглосуточно. Поскольку это всего лишь резервный контроллер домена, я бы выделил ему очень мало ресурсов ЦП / ОЗУ, поэтому он не должен сильно влиять на пользователя.
Это звучит как хороший план или есть какие-то подводные камни, о которых мне следует знать?
Я считаю, что общее мнение - «нет», особенно когда вы планируете разместить второй DC как виртуальную машину с хостом рабочей станции.
Причина, по которой вы используете два DC, заключается в том, что выход из строя одного из них не приведет к падению вашей сети на колени, а в более крупных средах - для предоставления большего количества ресурсов, выполняющих задачи DC.
Если вы разместите один из контроллеров домена в качестве виртуальной машины в выделенном гипервизоре в своем серверном шкафу со статическими IP-адресами вокруг, вы не нанесете существенного вреда отказоустойчивости системы. И Windows Server 2016, в частности, решает многие проблемы с контроллерами домена в виртуальной среде, такие как авторитетные записи, резервное копирование и восстановление и тому подобное.
Но если вы разместите контроллер домена как виртуальную машину на рабочей станции, виртуальная машина постоянного тока будет зависеть от возможности подключения главного компьютера, что сводит на нет большинство преимуществ избыточности.
Если основной физический контроллер домена выходит из строя, хост вашей рабочей станции теряет возможность подключения, и, следовательно, резервный контроллер домена тоже: бесполезен.
Единственная избыточность, которую вы получите, - это если DC виртуальной машины выйдет из строя, и в этом случае физический DC будет продолжать работать и обеспечивать потребности сети.
Другими словами: никакой пользы нет.
ОБНОВЛЕНИЕ: вариант
Имея такое лицензирование, вы могли бы за цену небольшого количества оборудования и одной стандартной лицензии Windows Server установить гипервизор (могу я предложить Nano?) И запустить на нем 2 сервера виртуальных машин. Запустите один как второй DC, а другой как стандартный сервер, предоставляющий услуги.
Думаю, это решает большинство проблем за небольшую сумму денег.
Предполагается, что гипервизор и виртуальные машины, работающие на нем, будут статическими IP-системами, и сетевые прерывания с меньшей вероятностью повлияют на них.
Программное обеспечение гипервизора серверного класса также с меньшей вероятностью будет нуждаться в перезагрузке после установки исправлений (отсюда и моя рекомендация Nano), а это означает, что гипервизору не потребуется перезагрузка так часто, как обычному рабочему столу.
Это просто лучшее универсальное решение и не намного дороже.
Мне не нравится эта идея. На рабочей станции вы будете запускать какой-то бесплатный гипервизор с сервером 20xx и ролью AD.
Вы должен иметь уникальную лицензию Windows Server 20xx, которую вы бы установили на эту машину, и если вы зашли так далеко, я бы порекомендовал купить выделенную машину или что-нибудь почистить.
В вашей ситуации AD требует очень мало ресурсов, поэтому подойдет что-то с 4 ГБ ОЗУ и жестким диском SATA на 120 ГБ. Хотелось бы как минимум 2 ядра видеть. Может быть, поищите подержанный сервер на аукционе.
В свое время мы делали нечто подобное в среде малого бизнеса. Бюст вместо того, чтобы иметь второй DC на рабочей станции. Я только что установил сервер Hyper-V на этот компьютер и создал реплику нашей виртуальной машины PDC. В тех редких случаях, когда мы теряли наш PDC (физический сервер гипервизора работал несколько нестабильно), мы просто вручную запускали сервер реплики на второй машине. Это можно легко настроить с помощью сценариев PowerShell и запланированных задач для автоматизации.
Это было далеко от идеального решения, когда де PDC вышел из строя, когда я находился за пределами офисной сети (например, дома), было очень болезненно (но выполнимо) попасть на вторичный компьютер для запуска реплики, но это определенно сработало, однако я не могу рекомендовать его в производственной среде.
Позже эта рабочая станция умерла, и я просто не стал ее восстанавливать. Установил второй контроллер домена на новой виртуальной машине на другом сервере гипервизора. Теперь никому не нужно заботиться о проблемах PDC, второй DC остается полностью функциональным, за исключением случаев, когда у нас есть проблемы с сетью, но тогда DC не является нашей самой большой проблемой.
Это тоже рабочее решение (по крайней мере, для нас), но, как всегда, если вы запускаете контроллер домена на виртуальной машине, а гипервизор является членом того же домена, вам нужно позаботиться о нескольких вещах (особенно о синхронизации времени).
P.S .: мы не используем DHCP в этой сети, только статические адреса.
Рекомендуется запускать DC на физическом сервере, а не на виртуальном хосте. Вы можете держать ADC на виртуальном хосте
В случае каких-либо проблем или необходимости перезагрузки на хост-сервере vm. Могут возникнуть проблемы с аутентификацией домена