Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Настраиваем высокодоступный DHCP-сервер в Windows Server 2012

Настраиваем высокодоступный DHCP-сервер в Windows Server 2012

DHCP-сервера являются одними из ключевых элементов сетевой инфраструктуры, однако, в отличии от DNS-серверов или контроллеров домена, в Windows Server отсутствовали штатные механизмы обеспечения высокой доступности. Начиная с Windows Server 2012 появилась возможность создания отказоустойчивых конфигураций DHCP, о чем мы сегодня и расскажем.

Перед тем, как приступать к рассказу о новых возможностях DHCP-сервера сделаем краткий экскурс в историю. До выхода Windows Server 2012 задача обеспечения высокой доступности решалась путем разделения области DHCP на две части, каждую из которых обслуживал свой сервер. Но такой подход имел множество неудобств, начиная от того, что все настройки нужно было дублировать между серверами и заканчивая тем, что в случае отказа все равно потребуется ручное вмешательство, особенно если оставшаяся часть области меньше, чем количество обслуживаемых ПК.

В Windows Server 2012 появилась возможность объединить два DHCP-сервера в конфигурацию высокой доступности, которая может работать в двух режимах: балансировки нагрузки или горячей замены.

Режим балансировки нагрузки является предпочтительным, в этом случае оба сервера одновременно обслуживают одну и ту же область, реплицируя данные между собой. Запросы клиентов делятся между серверами в заданной пропорции, по умолчанию 50/50. В случае отказа одного из серверов обслуживание продолжает оставшийся сервер.

Схема работы предельно проста и аналогична работе других сетевых сервисов, таких как DNS или AD — клиентские запросы обслуживаются до тех пор, пока в сети есть хоть один сервер, способный обработать запрос. Однако есть ограничение: два сервера на область DHCP. Следует помнить и понимать, высокая доступность DHCP реализуется не на базе серверов, а на базе областей. Если один сервер содержит несколько областей, то он, соответственно, может входить в несколько конфигураций высокой доступности.

Режим горячей замены предусматривает наличие второго сервера, который реплицируется с основным в режиме реального времени, но не обслуживает запросу клиентов до тех пор, пока основной сервер является активным. Свою работу сервер горячей замены начинает только при отказе основного сервера и прекращает с его возвращением в строй.

Такая схема может быть удобна для распределенных сетей и филиалов, когда резервный сервер располагается в другой части сети, связь с которой ограничена медленным каналом. На схеме ниже показана структура, где два сервера основной сети (область 192.168.31.0) работают в режиме балансировки нагрузки, в тоже время один из этих серверов является сервером горячей замены для филиала (область 192.168.44.0).

В штатном режиме все запросы сети филиала будет обслуживать сервер филиала, а в случае его отказа — сервер основного офиса. Это позволяет поддерживать высокую доступность DHCP в сети филиала без затрат на дополнительное оборудование.

Как видим, возможностей вполне достаточно для реализации самых разных схем и сценариев. Перейдем от теории к практике.

На двух серверах сети, в нашем случае это контроллеры домена SRV-DC01 и SRV-DC02, добавим роль DHCP-сервера, который обязательно авторизуем в Active Directory.

На одном из серверов добавляем и настраиваем область DHCP.

Затем щелкнув правой кнопкой мыши на нужную область, в выпадающем меню, выбираем Настройка обработки отказа.

Откроется мастер, который будет содержать указанную вами область, на первом экране ничего менять не надо, поэтом сразу жмем Далее. Следующим шагом будет предложено выбрать сервер-партнер. В этом качестве может выступать любой доступный DHCP-сервер на базе Windows Server 2012. В доменной сети вам будет доступен список авторизованных серверов, в рабочей группе выберите сервер воспользовавшись кнопкой Обзор.

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

Разберем доступные опции:

• Максимальное время упреждения для клиента — время на которое сервер-партнер продлевает аренду адресов клиентам второго сервера, если связь с ним потеряна.
• Процент распределения нагрузки — все понятно из названия, задает пропорцию распределения запросов между серверами.
• Интервал переключения состояния — время, после потери связи с партнером, когда сервер перейдет из состояния «связь потеряна» в состояние «партнер отключен»
• Проверять подлинность сообщений — между серверами устанавливается защищенный канал связи с использованием парольной фразы.

В режиме горячей замены набор опций несколько иной:

• Роль сервера-партнера — позволяет выбрать роли серверов, по умолчанию активным становится сервер, на котором настраивается обработка отказа, партнер переводится в ждущий режим.
• Адреса, выделенные для резервного сервера — часть диапазона, выделяемая резервному серверу для обслуживания новых клиентов в режиме «связь потеряна».

Указав все необходимые настройки жмем Далее и завершаем работу мастера.

На этом настройка высокодоступного DHCP-сервера закончена и самое время разобраться как это работает.

Важно! В настоящее время между серверами реплицируется только информация о выданных IP-адресах, при изменении настроек области, в том числе при резервировании адресов, изменения следует синхронизировать вручную.

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

Если по истечении времени интервала переключения сервер партнер не вернется в строй, то оставшийся сервер перейдет в состояние «партнер отключен» и начнет самостоятельно выдавать адреса из всего диапазона. При этом обратившиеся за продлением аренды клиенты партнера вместо продления получат новый адрес. После того как партнер вернется в строй клиенты будут автоматически распределены между ними в заданной пропорции (но это не приведет к изменению адресов, просто переданные назад партнеру клиенты по истечении аренды получат новый адрес уже у него).

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

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

blog.eaglenn.ru | Заметки IT инженера

Microsoft, Linux, Lync и etc……

Автоматическая репликация областей отказоустойчивого DHCP сервера Windows Server 2012

С выходом Windows Server 2012 у администратора DHCP сервера появилась возможность использования DHCP сервера в режиме отказоустойчивости с репликацией зарезервированных адресов на вторичный DHCP сервер в режиме балансировки нагрузки либо в режиме горячей замены. Это большой шаг вперед, который позволил добиться высокой доступности DHCP серверов, снижения времени простоя на обслуживание, установку обновлений и прочие операции. Как водиться среди огромного количества плюсов не обошлось без небольшого, но неудобного минуса. Проблема заключается в том, что после создания резервирования на одной из нод отказоустойчивого кластера DHCP, обновленные данные, автоматически не реплицируются на вторичный сервер. Для репликации данных приходится использовать ручной режим, для этого необходимо щелкнуть правой кнопкой мыши по области в которую были внесены изменения и из выпадающего меню выбрать «Репликация отношений»

Для репликации можно использовать командную строку, а именно оболочку PowerShell запущенную в режиме Администратора, в которой необходимо выполнить команду:

Invoke-DhcpServerv4FailoverReplication -ComputerName « имя dhcp сервера с которого необходимо реплицировать данные «

Пример использования команды Invoke-DhcpServerv4FailoverReplication

Команда ниже проведет репликацию всех областей участвующих в группе репликаций с именем MS-NN-Failover:

Этот пример запустит процесс репликации всех областей находящихся на сервере dhcpserver.example.com

Пример ниже выполнит репликацию областей имеющих ScopeID 10.10.10.0 и 20.20.20.0

Следует помнить, что ScopeID это не имя области, а именно пул адресов выделенных для области:

Автоматическая репликация областей отказоустойчивого DHCP сервера Windows Server 2012

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

Скрипт репликации

Создадим на диске C:\ файл PowerShell с произвольным названием, например: DhcpServerFailoverReplication.ps1. Откроем его на редактирование и добавим строку:

Invoke-DhcpServerv4FailoverReplication -ComputerName dhcp.example.com -force

Ключ -force позволит выполнить команду без вывода подтверждения действий.

Сохраняем файл и переходим к созданию пользователя.

Создание пользователя

Так как мой сценарий работает в среде Active Directory я не буду использовать локального пользователя, а создам доменного. Он нам понадобиться для запуска задачи по расписанию. И так, создадим обычного пользователя с именем DhcpServerReplication, добавим его в группу локального администратора на каждом DHCP сервере участвующем в сценарии отказоустойчивости.

Далее добавим нашего пользователя в локальную группу Администраторы DHCP.

Напомню еще раз, что пользователя необходимо добавить в указанные группы на каждом DHCP сервере.

Создание задания в планировщике

Самое время перейти к созданию задания в планировщике. Казалось бы, можно создать простое задание и запускать его планировщиком, например, каждые 5 минут. Но такой вариант запуска будет бесполезно грузить канал трафиком репликации, не зависимо от того была обновлена запись резервирования или нет. Мы воспользуемся запуском задачи по событию. При создании нового резервирования сервер регистрирует в журнале Microsoft-Windows-DHCP Server Events/Работает событие с кодом 106.

его мы и будем использовать при создании задания:

На странице настройки триггера выберете: При занесении в журнал указанного события.

В целях безопасности PowerShell скрипты могут выполняться только интерактивно, то есть сначала надо запустить оболочку PowerShell и уже в ней указать путь к скрипту. Поэтому в поле «Action» указываем запуск powershell.exe, а в поле «Add Arguments» параметр -File и путь к нашему скрипту, вот так:

-WindowStyle Hidden -File «C:\DhcpServerFailoverReplication.ps1»

-File — путь к исполняемому файлу PowerShell

-WindowStyle Hidden — не показывать окно оболочки PowerShell

Также в поле аргументы можно указать:

-Command — выполняет указанные команды и любые другие параметры. Этот параметр тоже можно использовать для запуска скрипта, например: -Command ″& ″. Кроме того, с его помощью можно передавать в скрипт параметры: -Command ″& ″;
-ExecutionPolicy — задает политику выполнения скриптов для текущего сеанса, может принимать значения Unrestricted, RemoteSigned, AllSigned и Restricted. Заданная политика будет действовать только в текущем сеансе и имеет приоритет над любыми ранее созданными политиками;
-NonInteractive — отключить вывод интерактивных запросов к пользователю;
-WindowStyle Hidden — запуск окна PowerShell в скрытом режиме, незаметно для пользователя;
-NoProfile — предотвращает загрузку профиля, что может несколько ускорить выполнение скрипта;
-NoExit — оставить оболочку открытой после отработки скрипта. Это может понадобиться при проверке и отладке скрипта.

После создания задачи запуска скрипта по событию, откройте закладку Действия и проверьте правильность строки запуска.

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

Откройте закладку Триггеры, проверьте источник и событие запуска.

В результате этих не сложных действий, наш планировщик заданий будет реагировать на появление события с кодом 106 и выполнять репликацию базы. Но это еще не все. Мы забыли настроить автоматическую репликацию DHCP при удалении резервации из базы данных. Для этого нам понадобиться событие с кодом 107.

Откроем еще раз закладку Триггеры и нажмем кнопку Создать. В окне мастера заполним необходимые поля, как на примере ниже:

Журнал: Microsoft-Windows-DHCP Server Events/Работает
Источник: DHCP-server
Код события: 107

После создания этого триггера, при регистрации в журнале события с кодом 107, так же будет запускать репликация базы DHCP на вторичный сервер.

Послесловие

Администратор DHCP сервера создает резервацию для компьютера. В журнале событий Microsoft-Windows-DHCP Server Events/Работает возникает событие, планировщик заданий получает информацию о возникшем событие и автоматически запускает задачу, которая в свою очередь запускает команду репликации. Вот таким не хитрым способом мы настроили автоматическую репликацию отказоустойчивого DHCP сервера.