Рубрика: Администрирование и сети

Общий пост про DHCP-failover  тут

И теперь моё личное впечатление:

Было время, лет 7-8 назад, у нас начал помирать сервак с dhcp. Был он физический в те времена, не виртуальный, и помирал внезапно и всегда не вовремя. На винде DHCP был, потому что там приятненький интерфейс, так исторически сложилось, а также потому что, так или иначе, в dhcp лазили четыре человека, а в роли линух-админа наблюдалась только я (не то чтобы я считала себя гуру, но на фоне остальных вполне прокатывала за линуксоида). Я тогда полезла изучать вопрос, а может придумали нормальное резервирование без бубнов, да на винде — и таки да, с Windows Server 2012 завезли failover. Не нужно пилить диапазоны или извращаться, настрой и пользуйся.

Божечки, какой же это кайф! Отказоустойчивость в случе, собственно, отказа занимает только половину профита. Представьте, что у вас человек (ваш сервис dhcp) стоит на двух кубиках (серверах) двумя разными ногами, а рядом есть ещё кубики. Он может поднять одну ногу с кубика и переступить на соседний, не потеряв равновесия. Или постоять на одной ноге, пока вы поменяете кубик.  То есть, надо винду на серверах проапгрейдить? Разрушаете failover, обновляете на одном сервере, восстанавливаете faillover, потом то же самое, но со стороны обновленного сервера. Перевезти сервера в новую сеть? Разрушил failover, создал отношения с сервером в новой сети, разрушил с нового сервера, создал со вторым сервером в новой сети. Только relay не забывай прописывать на сетевом оборудовании. Всё, 8 кликов, бесшовно, без потери текущих лизов. Огонь же, до сих пор кайфую, когда надо перевезти dhcp и это не требует усилий, работы ночами и вообще не напрягает.

Речь про обычные офисные сети с пользаками/телефонами где из выебонов максимум пару не включенных в стандартную поставку опций, типа 150 и 252, вкачены.  Да, ок, если есть нестандартные опции, добавляется ещё пару кликов — создать их на новом сервере. Всё равно охуенно удобно.

Мой канал в тежке про всякое админское:

https://t.me/sysadmin_how_it_is

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. Например, опция для cisco телефонов опция 150. Нестандартные опции сами не отреплицируются.
4. На Сервере1 там же на «IPv4» нажать правой кнопкой мыши и выбрать «Configure failover»
5. Настроить всё в соответствии со своим представлением о прекрасном. Например, по мануалу отсюда. Ну, собственно, пройти мастер, задать парольную фразу и расставить галочки в соответствии с задачами все смогут.
6. Чудесно, у вас два активных DHCP с одинаковым пулом в одной сети и никаких конфликтов =)

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

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

Мой телеграм канал о том, как выглядит работа систменого админитсратора:

https://t.me/sysadmin_how_it_is

А моё впечетление от DHCP Failover тут