У меня есть несколько филиалов с одним сервером на каждом сайте. Каждый из этих серверов функционирует как контроллер домена, DNS, DHCP, файловый сервер и сервер печати, а также точка распространения ConfigMgr. В настоящее время они работают под управлением Windows Server 2003. Это все небольшие офисы для 5-15 пользователей с дрянным кабельным Интернетом, поэтому короткие WAN и сбои питания довольно часты.
Я заменяю серверы на новое оборудование и перехожу на сервер 2012.
Я намерен использовать hyperv, чтобы сделать будущие миграции и изменения оборудования менее болезненными, поэтому обновление оборудования может быть таким же простым, как миграция виртуальной машины в реальном времени. Но я не уверен, что будет лучше всего. Я придумал несколько вариантов:
Опция 1
Физическая машина: ядро Server 2012r2, присоединение к домену, только роль HyperV.
VM1: ядро 2012r2, контроллер домена (возможно, RODC), DHCP, DNS
VM2: 2012r2 full, File, print и ConfigMgr.
Вариант 2
Вариант 3
Физическая машина: ядро Server 2012r2, Hyper-V, контроллер домена (возможно, RODC), DNS, DHCP.
ВМ: 2012r2 полный, файловый и принт-сервер и ConfigMgr.
Меня беспокоит то, что после продолжительных отключений электроэнергии (которые случаются каждые несколько месяцев) хост-сервер начнет резервное копирование до того, как их соединение VPN будет готово, и не сможет разговаривать с какими-либо контроллерами домена. Это вызвало у нас проблемы в более крупных офисах - хотя это было в кластере HyperV с хранилищем CSV, который, как мне кажется, вызывает больше проблем с аутентификацией.
Вариант 2 устраняет зависимость хоста от AD за счет увеличения объема работы по управлению и более сложного выполнения таких действий, как миграция виртуальных машин на другие хосты.
Вариант 3 выглядит так, как будто он наиболее устойчив к сбоям глобальной сети, но нарушает лучшие практики, когда хосты HyperV просто выполняют HyperV. Это тот, к которому я склоняюсь - хотя я бы предпочел вариант 1, если бы я был достаточно уверен, что не будет проблем с загрузкой сервера, пока WAN не работает.
Есть вопросы или другие варианты, которые мне не хватает? Какой маршрут лучше всего здесь выбрать?
Я бы использовал вариант №1, больше управляемости хостом.
Я бы сосредоточил другие усилия на том, чтобы сделать ваши удаленные сайты более устойчивыми ...
В случае филиала защитить питание несложно. Купить батареи повышенной емкости. Например. у моих клиентов, работающих в условиях нестабильного энергоснабжения Лос-Анджелеса, время работы от аккумулятора составляет от 60 до 240 минут.
В случае сбоя VPN типа "сеть-сеть" туннель (и сетевое оборудование) скорее всего будет восстановлен до загрузки сервера.
Для резервирования ISP рассмотрите балансировщик каналов, например Эльфик и обеспечить разнообразное подключение к каждому удаленному сайту.