Failover - ближе всего термин «отказоустойчивость», был придуман для обеспечения высокой доступности каких-либо сервисов. Вы дублируете какую-то часть системы или даже систему целиком для того, чтобы при отказе ваши пользователи не остались ни с чем. Круто, когда для пользователя отказ пройдет незаметно. Неплохо, когда отказ повлечет небольшое снижение качества услуги. Плохо, когда пользователя пошлют далеко и надолго просто потому, что всё сломалось. Это было так, лирическое отступление.

Теперь что касается DHCP. Задача сервера тут состоит из двух частей: выдавать адреса (каждый раз добавляйте мысленно «и сопутствующие настройки») новым пользователям и продлять аренду адресов для уже существующих клиентов.

Классические принципы построение отказоустойчивого сервиса предусматривали распиливание диапазона выдаваемых адресов в некотором процентном соотношении между двумя серверами (80 на 20, например). Первый сервер раздавал адреса, второй тихо был в резерве. Когда первый становился недоступен, включался в систему второй и «поддерживал штаны», пока первый снова не становился доступным. Безусловно, если «распилить» диапазон 50/50, то теоретически всё хорошо. НО! Во-первых, а что если вами используется больше половины диапазона? Во-вторых, вспомним, что в жизни есть резервации (запомненные пары MAC-IP), которые делаются не просто так, а с какой-то целью (на этот адрес прописываются особые разрешения в firewall и т.д.). Если для компа запомнен адрес из одной половины, то его нет во второй половине, очевидно.

Вторая классическая схема – кластер. Это когда у вас есть несколько железок, а поверх них некоторая программная надстройка, которая обеспечивает единую виртуальную «точку входа» для сервиса. Короче, клиент обращается к DHCP всегда одинаково, а виртуалка с сервисом может практически мгновенно съебаться с одного физического сервака на другой абсолютно незаметно для этого самого клиента. Это нехило страхует от физических проблем, а страховку от логических обеспечивают своевременные бэкапы и предыдущая схема. Но дорого и не избавляет от проблем с резервациями в случае сочетания с предыдущей схемой.

И третий вариант, который предлагает нам виндовый сервер начиная с версии 2012. Два сервера полностью дублируют друг-друга. При этом возможно как распределение нагрузки в определенном процентном соотношении, так и «горячее резервирование», при котором резервный сервер исправно реплицируется с основным, но запросы не обрабатывает до отказа основного. Справедливости ради: linux тоже так умеет. Вот, например. И в той и в другой ОС такая связка может состоять только из двух серверов, однако сервер может участвовать уже в максимум 31 связке. Также при желании можно пошаманить с репликацией файлов dhcp.leases и dhcp.static в linux, но зачем городить колхоз, когда есть готовые решения?

Пара схем. Одна область (scope) может участвовать только в одной связке одновременно.

Я буду рассматривать настройку виндового варианта. Просто потому, что использую его. Предполагается, что работающий DHCP у вас уже есть, просто вы дозрели до того, что хотите сделать failover. Сервер1 – на нем работает dhcp сейчас, Сервер2 – пустой.

1) Поднимете роль DHCP на Сервере2

2) В свойствах области на Сервере1, которую реплицируем выберите «только DHCP».

3) На Сервере2 в свойствах сервера (ipv4) создать все нестандартные опции. Нестандартные – это те, которых не было в дефолтных списках и вам их когда-то приходилось создавать на Сервере1. Например, опция для Forefront TMG клиента 252-WPAD. Нестандартные опции сами не отреплицируются.

4) На Сервере1 там же на «IPv4» нажать правой кнопкой мыши и выбрать «Configure failover»

5) Настроить всё в соответствии со своим представлением о прекрасном. Например, по мануалу отсюда. Ну, собственно, пройти мастер, задать парольную фразу и расставить галочки в соответствии с задачами все смогут.

6) Чудесно, у вас два активных DHCP с одинаковым пулом в одной сети и никаких конфликтов =)

Из граблей – резервации не реплицируются автоматом, их надо пинать руками (на области, на том сервере, где делали изменения ПКМ и «реплицировать эту область»). Все дополнительные настройки области (добавления новых опций dhcp, например) тоже требуют пинка для репликации. Есть вроде отдельная софтина, которая делает это автоматом, но меня, как практически единоличного админа DHCP, устраивает и этот вариант.

В чем разница «hot standby» и «load balance». Для объяснения нам потребуется знать о параметре maximum client lead time (MCLT). Вы его задаете при настройке failover.

Комменты к предыдущему посту про dhcp были унылы, там не хватало срача экшена. Тут же куча поводов для обсуждения, есть шанс узнать много нового и полезного в комментариях.