Третья, заключительная статья о DHCP. В завершение темы я расскажу о том, как обеспечить отказоустойчивую работы DHCP-сервера с помощью технологии DHCP failover.
Но сначала немного истории.
До выхода Windows Server 2012 единственным способом обеспечить отказоустойчивость DHCP-сервера была так называемая схема 80\20. Суть этой схемы заключается в том, что для обслуживания одной области используются два DHCP-сервера. Область делится между ними в пропорции 80\20, соответственно основному серверу отдается 80%, а резервному 20% имеющихся IP-адресов. В нормальном режиме работы область обслуживается основным сервером, а при выходе из его строя резервный берет на себя нагрузку и выдает клиентам адреса из оставшихся 20%, тем самым поддерживая работу сети.
Данный способ вполне рабочий и используется до сих пор, но у него есть некоторые недостатки:
• При разделении области имеющиеся адреса используются не самым оптимальным образом;
• Клиенты не могут продлить аренду с имеющимся адресом;
• Проблемы при использовании резервирования.
Примечание. Резервирование (DHCP reservation) — настройка DHCP-сервера, при которой к MAC-адресу клиента привязывается постоянный IP-адрес. Это гарантирует, что клиент всегда будет получать в аренду один и тот же адрес. Резервирование настраивается на конкретном сервере и при его недоступности клиент не сможет получить зарезервированный за ним адрес.
Недостатки конечно некритичные, но доставляющие много неудобств. Видимо поэтому в Windows Server 2012 была добавлена новая фича под названием DHCP failover, предназначенная для обеспечения высокой доступности DHCP-серверов. DHCP failover позволяет обеспечить высокую доступность службы DHCP и не имеет недостатков, описанных выше. При использовании DHCP failover два DHCP-сервера реплицируют между собой текущие настройки и данные об аренде, что позволяет одному серверу обслуживать всех клиентов (выдавать новые адреса, продлевать аренду и т.п.) в том случае, когда другой недоступен.
DHCP failover может работать в двух режимах.
Режим балансировки (Load balance)
В этом режиме область делится на две части в определенной пропорции и обслуживается обоими серверами одновременно. При получении запроса каждый сервер вычисляет хэш MAC-адреса клиента в соответствии с алгоритмом, описанным в RFC 3074. MAC-адреса хэшируются в диапазоне от 1 до 256, балансировка происходит по следующему принципу: если нагрузка распределена в пропорции 50\50 и если при вычислении хэша получено значение от 1 до 128, то отвечает первый сервер, если же от 129 до 256 — то отвечает второй. При изменении коэффициента распределения нагрузки распределение хэш-блоков между серверами изменяется в той же пропорции. Такой подход гарантирует, что за одного конкретного клиента отвечает только один сервер.
Если же один из серверов перестает отвечать, то второй забирает всю область и продолжает обслуживать как своих клиентов, так и клиентов партнера.
Режим горячей замены (Hot Standby)
В таком режиме область обслуживается одним сервером (основным). В отличие от режима балансировки в режиме горячего резерва сервера не вычисляют хэш MAC-адреса клиента. Основной сервер отвечает на все запросы клиентов, резервный в нормальном состоянии не отвечает вообще. Только когда основной сервер становится недоступным, резервный переходит в состояние потери партнера (PARTNER_DOWN) и начинает отвечать на запросы клиентов. Когда основной сервер возвращается в строй, резервный переходит в режим ожидания и перестает обслуживать клиентов.
Обратите внимание, что термин основной\резервный относится к конкретной DHCP-области. К примеру DHCP-сервер может являться основным для одной области и резервным для другой.
От теории перейдем к практике. Для создания отказоустойчивой конфигурации возьмем 2 сервера — SRV1 и SRV2, находящихся в одной подсети. На SRV1 создаем область (Scope) и полностью настраиваем ее, на SRV2 только устанавливаем роль DHCP, никаких настроек не производим. После этого приступаем к настройке DHCP failover.
Настройка DHCP failover
Для начала настроим режим балансировки (Load balance). Для этого заходим на сервер SRV1 и открываем оснастку DHCP. Выбираем область, кликаем на ней правой клавишей и в контекстном меню отмечаем пункт «Configure Failover».
Запускается мастер настройки. В первом окне мастера выбираем области, для которых будет настраиваться отказоустойчивость. Впрочем, в нашем случае выбора нет, поскольку область всего одна.
Добавляем сервер-партнер, на котором будет находится второй экземпляр области.
На следующем этапе выбирается режим работы и основные настройки.
В качестве имени для создаваемых доверительных отношений (Relationship Name) по умолчанию используются имена серверов, но в принципе можно указывать что угодно. Режим работы (Mode) выбираем балансировку (Load balance) и в поле «Load Balance Percentage» указываем в процентах пропорции, в которых будет разделена область между двумя серверами. По умолчанию нагрузка делится в соотношении 50\50, но мы сделаем по привычной схеме 80\20, т.е. 80% обслуживает основной сервер и 20% резервный.
Теперь два очень важных параметра, на которых надо обратить внимание:
• State Switchover Interval — интервал времени, по истечении которого партнер считается недоступным (PARTNER_DOWN). Если не задавать этот параметр, то при падении партнера автоматического переключения не произойдет и переключатся придется вручную;
• Maximum Client Lead Time — очень интересный параметр, определяющий срок продления аренды в случае падения основного сервера. Когда клиент пытается продлить аренду, полученную на основном сервере, то резервный сервер продлевает ее не на срок аренды, указанный в свойствах области, а на время, указанное в данном параметре. И так пока основной сервер не восстановит работу. Также этот параметр определяет, сколько времени сервер будет ждать возвращения партнера из состояния PARTNER_DOWN прежде чем забрать контроль над всей областью. А еще этот параметр определяет время перехода в нормальное состояние при возвращении партнера.
Примечание. Параметры State Switchover Interva и Maximum Client Lead Time определяют скорость срабатывания failover-а. Каждый из партнеров обслуживает свой диапазон адресов до того момента, пока один из серверов не перейдет в состояние PARTNER_DOWN и не пройдет время, указанное в параметре Maximum Client Lead Time. Только после этого ″оставшийся в живых″ сервер возьмет на себя контроль над всей областью.
Сервера должны безопасно общаться друг с другом. Для этого включаем параметр «Enable Message Authentication» и в поле «Shared Secret» задаем кодовое слово, которое сервера будет использоваться для связи.
В заключение проверяем настройки, подтверждаем создание failover-а
и ждем завершения процесса.
Посмотреть настройки и текущее состояние партнеров можно в свойствах области, на вкладке «Failover».
То же самое можно сделать с помощью PowerShell. Создаем доверительные отношения:
Add-DhcpServerv4Failover -ComputerName srv1.test.local -Name ″srv1-srv2″ -PartnerServer srv2.test.local -ScopeId 10.0.0.0 -LoadBalancePercent 80 -MaxClientLeadTime 00:10:00 -AutoStateTransition $true -StateSwitchInterval 00:10:00 -SharedSecret ″12345678″ -Force
Проверяем результат:
Get-DhcpServerv4Failover -Name ″srv1-srv2″ | fl
Теперь сменим конфигурацию, сначала отключив failover. Для этого в оснастке DHCP кликаем на область и выбираем пункт меню «Deconfigure Failover».
Затем подтверждаем удаление доверительных отношений,
еще раз подтверждаем удаление
и ждем завершения. При удалении на сервере-партнере будут удалены все области, для которых был настроен failover.
Для удаления с помощью PowerShell достаточно выполнить одну команду:
Remove-DhcpServerv4Failover -Name ″srv1-srv2″ -Force
Теперь настроим DHCP failover в режиме Hot standby. Для этого опять запускаем мастер на SRV1 и выбираем сервер-партнер. Обратите внимание, что если между серверами ранее уже были настроены доверительные отношения, то их можно использовать повторно.
Выбираем режим Hot standby и производим настройки. Для режима Hot standby они несколько отличаются:
• Role of Partner Server — серверы делятся на основной (Active) и резервный (Standby) и надо выбрать роль для сервера-партнера. Если мы выбираем Standby, то текущий сервер соответственно становится Active, и наоборот.
• Addresses reserved for standby server — еще один важный параметр, задающий процент адресов, выделенный для резервного сервера. Суть этого параметра в том, что после выхода из строя основного сервера и перехода в состояние PARTNER_DOWN должно пройти время, заданное в параметре Maximum Client Lead Time. Только после этого резервный сервер забирает контроль над над всем диапазоном IP-адресов. В промежутке между этими двумя событиями резервный сервер может обслуживать клиентов, выдавая им адреса из данного резерва. Если этот параметр установить в ноль, то резервный сервер не сможет выдавать адреса до тех пор, пока не захватит всю область.
Дальше все так же — проверяем настройки, подтверждаем их
и ждем завершения.
То же из консоли PowerShell:
Add-DhcpServerv4Failover -ComputerName srv1.test.local -Name ″srv1-srv2″ -PartnerServer srv2.test.local -ScopeId 10.0.0.0 -ReservePercent 10 -MaxClientLeadTime 00:10:00 -AutoStateTransition $true -StateSwitchInterval 00:10:00 -SharedSecret ″12345678″ -Force
Изменить настройки и режим работы DHCP failover можно ″на лету″, не удаляя текущую конфигурацию. Для этого в оснастке управления надо выбрать раздел IPv4 (или IPv6, если failover настраивался для этого протокола), кликнуть правой клавишей мыши и выбрать пункт «Properties».
Затем перейти на вкладку «Failover», выбрать доверительные отношения и нажать «Edit».
В открывшемся окне мы можем поменять абсолютно любые настройки и даже изменить режим работы failover-а, например перейти с Load Balance на Hot Standby.
А теперь с помощью PowerShell вернемся обратно к режиму балансировки, попутно изменив интервалы MaxClientLeadTime и StateSwitchInterval:
Set-DhcpServerv4Failover -Name ″srv1-srv2″ -Mode LoadBalance -LoadBalancePercent 80 -MaxClientLeadTime 00:02:00 -StateSwitchInterval 00:02:00 -Force
Тестирование работы DHCP failover
В завершение давайте протестируем работу DHCP failover. На предыдущем шаге мы уменьшили до 2 минут временные интервалы, отвечающие за переключение. Также для ускорения процесса в свойствах области уменьшим время аренды до 10 минут.
Теперь зайдем в свойства DHCP failover и проверим состояние серверов-партнеров.
Запомним полученные настройки на клиенте. Как видите, клиент имеет адрес 10.0.0.20, полученный с сервера 10.0.0.1 (SRV1).
Теперь погасим сервис DHCP на SRV1 и перейдем на SRV2. Здесь откроем оснастку DHCP и перейдем в настройки доверительных отношений. Как видите, после потери связи с партнером здесь стала активна кнопка ″Change to partner down″. С помощью этой кнопки можно перевести сервер в состояние PARTNER_DOWN, не дожидаясь пока истечет State Switcover Interval.
Еще раз проверяем состояние серверов. Резервный сервер перешел в состояние Partner down и готов к захвату контроля над областью.
Ждем 2 минуты и еще раз проверяем настройки на клиенте. Как можно увидеть, IP-адрес не изменился, при этом в качестве DHCP-сервера указан уже 10.0.0.2 (SRV2). Т.е. клиент успешно продлил на SRV2 аренду адреса, полученного от SRV1.
Возвращаем SRV1 в строй, ждем пока клиент обновит аренду и еще раз проверяем его настройки. Как видите, IP-адрес не изменился, а адрес DHCP-сервера опять SRV1.
Вот так и работает DHCP-failover.
DHCP-сервера являются одними из ключевых элементов сетевой инфраструктуры, однако, в отличии от DNS-серверов или контроллеров домена, в Windows Server отсутствовали штатные механизмы обеспечения высокой доступности. Начиная с Windows Server 2012 появилась возможность создания отказоустойчивых конфигураций DHCP, о чем мы сегодня и расскажем.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Перед тем, как приступать к рассказу о новых возможностях 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-адресах, при изменении настроек области, в том числе при резервировании адресов, изменения следует синхронизировать вручную.
Начнем с режима балансировки нагрузки. В этом случае область делится между серверами в указанной пропорции и все запросы равномерно распределяются между ними. При потере связи с сервером-партнером оставшийся сервер переходит в режим «связь потеряна», в это время он продлевает аренду существующим клиентам партнера на время, указанное во времени упреждения, а новым клиентам выдает адреса из своей части диапазона.
Если по истечении времени интервала переключения сервер партнер не вернется в строй, то оставшийся сервер перейдет в состояние «партнер отключен» и начнет самостоятельно выдавать адреса из всего диапазона. При этом обратившиеся за продлением аренды клиенты партнера вместо продления получат новый адрес. После того как партнер вернется в строй клиенты будут автоматически распределены между ними в заданной пропорции (но это не приведет к изменению адресов, просто переданные назад партнеру клиенты по истечении аренды получат новый адрес уже у него).
В режиме горячей замены сервер-партнер в режиме «связь потеряна», также продолжает продлевать аренду и выдает адреса новым клиентам из своего диапазона. При переходе в режим «партнер отключен» начинает обслуживать весь диапазон полностью и выдавать адреса всем клиентам. После того, как сервер-партнер вернется в строй, сервер горячей замены снова перейдет в ждущий режим и клиенты, по истечении времени аренды, получат адреса у основного сервера.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Сегодня будет практическая задача на тему, как настроить резервирование возможности присвоения устройствами в доменной сети сетевого IP—адреса от сервиса DHCP который поднят на домен контроллере. Предыстория: есть одна серверная и по воле случая в ней оказалось, что на системе виртуализации два домен контроллера и когда понадобилось по команде выключить доступ к ней, то у всего предприятия пропала возможность хоть как-то работать: нет работают принтера, рабочие станции, PDA клиенты. А все потому что устройства остались без IP-адреса.
В виду этого я решил, что нужен в другой серверной еще один домен контроллер с ролью DNS и DHCP, а между главным (srv-dc01) и еще одним (srv-dc03) настроить для роли DHCP Failover, но прежде чем это делать на боевом, все обкатываем на тестовом.
Шаг №1: Итак есть два домен контроллера на базе OS: Windows Server 2012 R2 Std и домен polygon.local
srv-dc01.polygon.local = 10.90.90.3srv-dc02.polygon.local = 10.90.90.4
Шаг №2: Основной домен контроллер srv-dc01.polygon.local, на нем поднята роль DНCP и настроена область выделения IP-адресов:
Шаг №3: На втором домен контроллере srv-dc02.polygon.local также стоит роль DHCP то область обслуживания не настроена:
Шаг №4: Переходим вот к такой вот настройке:
на srv-dc01.polygon.local авторизуюсь как Domain Admin и запускаю оснастку DHCP, затем через правый клик мышью на Scope [10.90.90.0] local выбираю Configure Failover…
Мне отображаются сети, которые я могу настроить:
нажимаю Next
Указываю какой сервер будет партнером
Partner Server: нажимаю Add Server и еще Browse нахожу srv-dc02Reuse existing failover relationships configured with this server (if any exist): галочку снимаю если хочу настройки выполнить с нуля
и нажимаю Next
Настраиваю работу Failover
Relationship Name: srv-dc01.polygon.local-srv-dc02.polygon.local-1Maximum Client Lead Time: 1 hoursMode: Hot standbyRole of Partner Server: StandbyAddresses reserved for standby server: 5%State Switchover Interval: 5 minutes (Отмечаю галочкой)Enable Message Authentication: отмечаю галочкойShared Secret: Aa1234567aA
и нажимаю Next, Finish.
Процесс создания Failover завершается без ошибок
Шаг №5: Проверим работу, допустим связь с srv-dc01 пропала:
а ничего не изменилось вроде как, перезагрузил систему Windows 10 Pro и через команду ipconfig /all отобразил все параметры и уже сейчас значится что DHCP-сервер — это 10.90.90.4, т.е. srv-dc02
Шаг №6: Смотрим информацию по Failover на srv-dc02
Logon on srv-dc02
оснастка DHCP — через правый клик мышью на Scope [10.90.90.0] local открываю Properties, перехожу на вкладку Failover и вижу
и сейчас активен srv-dc02.
На заметку: Думаю если устройств домена много, то есть смысл зарезервировать на 5% на 90% адресов + Addresses reserved for standby server — еще один важный параметр, задающий процент адресов, выделенный для резервного сервера. Суть этого параметра в том, что после выхода из строя основного сервера и перехода в состояние PARTNER_DOWN должно пройти время, заданное в параметре Maximum Client Lead Time. Только после этого резервный сервер забирает контроль над над всем диапазоном IP-адресов. В промежутке между этими двумя событиями резервный сервер может обслуживать клиентов, выдавая им адреса из данного резерва. Если этот параметр установить в ноль, то резервный сервер не сможет выдавать адреса до тех пор, пока не захватит всю область.
Шаг №7: Когда доступ к srv-dc01 возвращается, то через несколько минут если также открыть свойства области вкладка Failover видно
Сервис вернулся к нормальному состоянию, а рабочая станция пока также работает через srv-dc02, если она перезагрузится, то настройки IP получит уже от srv-dc01, т.к. он главный.
Шаг №8: Если нужно изменить что-то в настройках Failover для Scope, нужно с того который главный через правый клик по Scope [10.90.90.0] local выбрать "Deconfigure Failover"
Затем подтвердить свои действия
This action will remove the selected scopes from the associated failover relationships. The selected scopes will also be deleted from the partner server. Click OK to continue or Cancel to abort.
Нажимаю ОК
This action will remove all the scopes which are part of failover relationship.
The failover relationship can be deleted after the action.
Нажимаю ОК
Progress of removing scope 10.90.90.0 from failover relationship.
The log below shows the progress of the various steps for removing the selected scope from the failover relationship including errors encountered, of
Check status of the failover relationship… Successful
Deactivate scopes on the partner server… Successful
Remove scopes from failover relationship on the partner server… Successful
Remove scopes from failover relationship on this server… Successful
Delete scopes on partner server… Successful
Deconfigure failover successful.
что в свою очередь на srv-dc02 удаляет записи которые прилетели с srv-dc01
После успешного расконфигурирования заново запускаем процесс настройки "Configure Failover…" но уже с другими параметрами синхронизации, как и сказал выше увеличиваем в процентном соотношении резервирование IP-адресов.
На заметку: Советую на главное srv-dc01 выполнять периодически резервное копирование базы DHCP
Win + X -> Command Prompt(Admin)
C:\Windows\system32>if not exist c:\backup mkdir c:\backup
C:\Windows\system32>netsh dhcp server export c:\backup\dhcpexport.txt all
C:\Windows\system32>net stop "dhcp server"
C:\Windows\system32>copy /Y %systemroot%\system32\dhcp\dhcp.mdb c:\backup
C:\Windows\system32>net start "dhcp server"
Итого: с учетом сложившейся ситуации этот вариант резервирования DHCP в принципе имеет место быть, пусть будет как заметка, ее я уже применил к боевому использованию (srv-dc01 OS:Window Server 2012 R2) - (srv-dc03 OS:Windows Server 2016), наблюдаем.
На этом пока все, с уважением автор блога Олло Александр aka ekzorchik.
В процессе миграции серверных систем на Windows Server 2012 R2 дошли до служб DHCP и решили попробовать в действии новый механизм повышения доступности DHCP Failover появившийся еще в Windows Server 2012. Перед началом процедуры возьмём на заметку пару тезисов из документации по DHCP Failover:
Для отработки отказа DHCP можно использовать не более двух DHCP-серверов
Для правильной работы отработки отказа DHCP необходимо синхронизировать время на двух серверах в отношениях отработки отказа. Для синхронизации времени можно использовать протокол NTP или любой альтернативный механизм. Мастер настройки отработки отказа сравнивает текущее время на серверах, настроенных для отработки отказа. Если время на серверах отличается более чем на одну минуту, установка отработки отказа завершится с критической ошибкой, указывающей администратору на необходимость синхронизации времени на серверах.
Последовательность выполняемых действий:
1. Устанавливаем роль DHCP Server на два сервера с Windows Server 2012 R2.
2. Экспортируем данные действующего сервера DHCP с Windows Server 2008 R2
3. Импортируем все конфигурационные данные DHCP на первый сервер с Windows Server 2012 R2
4. Импортируем только серверную конфигурацию DHCP на второй сервер с Windows Server 2012 R2
5. Настраиваем DHCP Failover.
6. Заключительные процедуры
1. Устанавливаем роль DHCP Server на два сервера с Windows Server 2012 R2
1.1. Устанавливаем роль DHCP Server на первый сервер (KOM-AD01-NS01)
Выполним установку роли DHCP Server на первый сервер с помощью консоли Server Manager, где вызовем мастер добавления ролей в меню Manage > Add Roles and Features и на этапе выбора ролей отметим DHCP Server
тут же нам будет предложено установить компоненты управления ролью из состава RSAT (консоль DHCP и PS-модуль для работы с DHCP) – соглашаемся с их добавлением.
В конце процесса установки нам станет доступна ссылка пост-инсталляционной настройки роли – Complete DHCP configuration
Мастер настройки выполняет две основные вещи – добавляет на сервер две локальные группы безопасности для управления ролью и выполняет авторизацию службы DHCP в домене Active Directory.
Для выполнения авторизации при необходимости можно указать отдельные учетные данные…
Жмём Commit и убеждаемся в том, что процедуры создания локальных групп и авторизации выполнены без проблем…
После завершения работы мастера конфигурации выполняем перезапуск службы DHCP Server, чтобы изменения связанные с настройкой вновь созданных локальных групп безопасности вступили в силу. Перезагрузка сервера при этом не требуется.
1.2. Устанавливаем роль DHCP Server на второй сервере (KOM-AD01-NS02)
На втором сервере для наглядности установку роли выполним c помощью PowerShell.
Устанавливаем исполняемые компоненты DHCP:
Add-WindowsFeature -IncludeManagementTools DHCP
Создаем локальные группы безопасности DHCP (DHCP Administrators и DHCP Users) :
Add-DhcpServerSecurityGroup
Для вступления в силу настроек безопасности DHCP связанных с созданными локальными группами безопасности перезапускаем службу DHCP Server:
Restart-Service DHCPServer
Авторизуем DHCP сервер в Active Directory:
Add-DhcpServerInDC kom-ad01-ns02.holding.com 10.160.0.12
Однако после того, как роль DHCP установлена и выполнены пост-инсталляционные настройки с помощью PowerShell, — при подключении к этому серверу в консоли Server Manager будет висеть предупреждение о том, что требуется пост-инсталляционная настройка невзирая на то, что фактически она уже выполнена. При этом для исчезновения этого предупреждения не поможет даже перезагрузка сервера.
Чтобы скинуть этот статус , выполним изменение ключа реестра в значение определяющее то, что фактически роль DHCP Server уже сконфигурирована с помощью PowerShell:
Set-ItemProperty –Path registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ServerManager\Roles\12 –Name ConfigurationState –Value 2
2. Экспортируем данные действующего сервера DHCP
С сервера, на котором в данный момент выполняется служба DHCP на базе Windows Server 2008 R2 нам необходимо экспортировать конфигурацию службы DHCP, в том числе информацию о всех DHCP-областях и относящихся к ним резервированиях и арендованных IP-адресах. Сделать это можно непосредственно с сервера на базе Windows Server 2012 R2.
Итак, на сервере KOM-AD01-NS01 предварительно создаём папку, в которую будут экспортироваться данные, например C:\Temp и выполняем PS-командлет экспорта конфигурации со старого DHCP-сервера:
Export-DhcpServer -ComputerName "WS2008R2.holding.com" -Leases -File "C:\Temp\DHCPExport.xml" –Verbose
3. Импортируем все конфигурационные данные DHCP на первый сервер с Windows Server 2012 R2
На сервере KOM-AD01-NS01 выполняем команду полного импорта конфигурации DHCP
Import-DhcpServer -Leases –File "C:\Temp\DHCPExport.xml" -BackupPath "C:\Temp\DHCPBackup\" –Verbose
С параметром —File думаю всё понятно, он указывает на файл из которого будут браться данные для импорта. Параметр -BackupPath, несмотря на то, что он нам в данной ситуации не нужен, является обязательным и указывает путь к каталогу, в который перед импортом будет выполнено резервное копирование существующей конфигурации нового сервера, и поэтому его нужно указать, определив для него какой-нибудь временный каталог.
4. Импортируем только серверную конфигурацию DHCP на второй сервер с Windows Server 2012 R2
Так как в процессе установки партнёрских отношений по репликации между серверами с первого сервера на второй будут реплицированы области, их резервирования и информация о текущей аренде IP-адресов, то на второй сервер мы импортируем только основную серверную конфигурацию DHCP. То есть импорту подлежат только данные, специфичные для каждого отдельного сервера, которые не участвуют в процессе репликации в партнёрских отношениях между серверами, а именно:
— Vendor or User classes other than those which are built-in.
— Option definitions other than those which are built-in
— Server level option values
— MAC address based filters
— Conflict detection attempt (if set to something other than the default)
Перейдём на сервер KOM-AD01-NS02, скопируем файл с данными экспорта в C:\Temp\DHCPExport.xml и выполним команду импорта с специальным параметром определяющим состав импортируемых данных:
Import-DhcpServer –File "C:\Temp\DHCPExport.xml" –ServerConfigOnly -BackupPath "C:\Temp\DHCPBackup\" –Verbose
5. Настраиваем DHCP Failover
Переходим на первый сервер KOM-AD01-NS01 (где импортированы области DHCP) и в консоли DHCP в дереве навигации открываем меню действия для узла IPv4 > Configure Failover…
Откроется мастер настройки отказоустойчивой конфигурации областей DHCP. В нашем примере в отказоустойчивую конфигурацию будут включены все области сервера, и поэтому мы оставляем включенным чекбокс Select all
На следующем шаге мастера выберем имя второго сервера, который будет выступать в качестве партнёра по репликации для текущего сервера. Это можно сделать выбрав сервер кнопкой Add Server из открывающегося списка авторизованных в Active Directory DHCP серверов.
Далее нам предстоит выбрать режим повышения доступности. Существует два основных режима – Load balance и Hot standby. Первый режим представляет собой режим балансировки нагрузки Active/Active между двумя серверами-партнёрами, то есть клиентские запросы обрабатывают оба сервера в соответствии с процентным соотношением в Load Balance Percentage. Второй режим заставляет работать сервера в режиме Active/Passive, то есть второй сервер включается в работу только при недоступности первого.
В нашем примере выбран режим балансировки, при котором DHCP серверы-партнёры вычисляют хеш MAC-адреса из клиентского запроса на основе алгоритма описанного в RFC 3074. В результате применения хеш-алгоритма каждый MAC-адрес преобразуется в значение от 1 до 256, и если например балансировка между серверами настроена нами в соотношении 50/50 %, то первый сервер будет отвечать клиентам с хешем от 1 до 128, а второй соответственно — клиентам с хешем от 129 до 256.
Что касается параметров настройки выбранного режима работы, то их скудное описание можно найти в документе TechNet Library — DHCP Failover Settings
Насколько я понял, Maximum Client Lead Time это максимальное время аренды IP-адреса выдаваемого доступным сервером для клиентов, которые должны быть обслужены тем сервером, который в данный момент недоступен. А State Switchover Interval – это интервал времени по истечении которого доступный сервер при недоступности сервера-партнёра автоматически переводит партнёрские отношения из COMMUNICATION INTERRUPTED в PARTNER DOWN и берёт на себя функции по полному обслуживанию DHCP-областей, входящих в эти партнёрские отношения. В большинстве случаев для этих параметров можно оставить предложенные по умолчанию значения.
Для повышения безопасности механизмов репликации между серверами желательно использовать опцию Enable Message Authentication, для которой нам нужно задать пароль Shared Secret используемый для взаимной аутентификации серверов.
Далее мастер покажет нам сводную информацию по сделанным настройкам и выполнит конфигурирование партнёрских отношений между серверами.
Подключимся консолью DHCP ко второму серверу, куда мы ранее импортировали только серверную конфигурацию и убедимся в том, что на нём появились реплицируемые DHCP-области.
В дальнейшем при желании мы можем поменять режим работы DHCP Failover и все его опции на соответствующей вкладке настроек IPv4. Здесь же мы увидим текущий статус партнёрских отношений…
6. Заключительные процедуры
В качестве заключительных процедур по настройке DHCP Failover можно считать обновление агентов DHCP Relay для использования IP адресов двух серверов-партнёров (перенастройка маршрутизирующего сетевого оборудования) и последующее тестирование получившейся конфигурации.
Источники информации:
Microsoft Windows DHCP Team Blog — Ensuring High Availability of DHCP using Windows Server 2012 DHCP Failover
Microsoft Windows DHCP Team Blog — DHCP Failover Load Balance Mode
Microsoft Windows DHCP Team Blog — DHCP Failover Hot-Standby Mode
Microsoft Windows DHCP Team Blog — Installing and Configuring DHCP role on Windows Server 2012
Microsoft Windows DHCP Team Blog — Bringing PowerShell to DHCP Server
Microsoft Windows DHCP Team Blog — DHCP Failover using PowerShell
Microsoft Windows DHCP Team Blog — Migrating existing DHCP Server deployment to Windows Server 2012 DHCP Failover
TechNet Library — Step-by-Step: Configure DHCP for Failover
TechNet Library — What’s New in DHCP in Windows Server 2012 R2
The role of the Dynamic Host Configuration Protocol, or DHCP, server is a simple yet critical one. DHCP provides the IP address configuration to workstations, laptops, phones and tablets connected to an organization’s network. It may even provide IP address settings for some VMs, servers and network printers.
Examples of IP address settings include the following:
- IP address and corresponding subnet mask;
- default gateway, such as a router; and
- name resolution server IP addresses, such as DNS.
Many other configurations are possible, but these are the standard options.
The settings provided by DHCP are critical. The router address enables clients to communicate outside their local network. Name resolution converts easy-to-remember hostnames to difficult-to-remember IP addresses, enabling easier file sharing, web browsing, email communications and access to just about every other network service.
Initially, if the DHCP server fails, clients with existing leases maintain their addresses. By default, Windows leases are not renewed for eight days following the initial lease. That should give network admins sufficient time to fix the DHCP server. New clients, however, will not be able to lease addresses.
DHCP is essential, so how can network admins better protect it from going down?
The importance of DHCP failover
DHCP services are critical enough to warrant fault tolerance. Before Windows Server 2012, such fault tolerance was relatively cumbersome to implement and maintain. The more recent Windows Server versions, however, include a straightforward way to manage DHCP redundancy.
These settings are not just for fault tolerance, but can also provide load balancing for large networks where the DHCP servers support many transient clients on multiple subnets. For some administrators, the ability to load balance DHCP services may be just as critical as high availability.
Define redundancy requirements
For larger DHCP implementations involving many clients, scopes, subnets and servers, be sure to develop a plan. Know which scopes benefit from DHCP failover; it may not be necessary to configure this feature for all of them. For example, lab and classroom scopes may not need this option.
DHCP failover requirements
The requirements for Windows-based DHCP failover are no different from a standard Windows DHCP deployment. Both servers must have the DHCP Server role installed, and an enterprise administrator must authorize the servers in Active Directory (AD).
To begin the process, create a new scope, or choose an existing one. If you create a new scope, walk through the configuration wizard to define the values for the scope name, IP address range, subnet mask, default gateway name resolution and lease duration.
Once the initial scope is created, you can configure failover or load-balancing options.
Note that either or both DHCP servers can be VMs. They just need the appropriate network membership.
Steps to configure DHCP failover
First, select a Windows Server system as the second DHCP server. Install the DHCP Server role on this device.
Next, return to the original DHCP server, right-click the scope you wish to configure for failover and select Configure Failover. The wizard walks you through the remaining settings. The DHCP service must also be running on both systems.
Here are the detailed steps.
Step 1. Select Configure Failover
Right-click the selected DHCP scope, and select Configure Failover from the context menu.
Step 2. Specify the partner server
In the Specify the partner server to use for failover box, type the server name, or use the Add Server button to browse to it in AD.
The wizard validates the configuration of the partner server.
Step 3. Create new failover relationship
Fill in the following values to configure a failover partnership (I have set some example values):
Relationship Name: DHCP-Server01-Server02
Mode: Hot standby
Enable Message Authentication: Check the box
Shared secret: abc123
For the Hot Standby Configuration mode, fill in the following values:
Mode: Hot standby
Hot Standby Configuration
Role of Partner Server: Standby
Addresses reserved for standby server: 10%
Step 4. Select Finish to complete configuration
The wizard displays a settings summary. Select Finish to complete the configuration.
Switch to the second DHCP server. In the DHCP console, note the scope has been replicated.
DHCP load-balancing configuration
The load-balancing settings are nearly the same. When configuring a load-balancing mode, instead of Hot standby in the Mode pulldown menu, select Load balance. Then, configure the following settings:
Mode for Load balance:
Load Balance Percentage
Local Server: 50%
Partner Server: 50%
The other settings remain the same as with failover mode. Define the appropriate load-balancing ratio. In the example, I set 50% of the addresses for each server.
Manage DHCP failover
Recall that DHCP logs information in Event Viewer. It also generates text-based logs at C:\Windows\System32\DHCP. These detailed logs display lease generation attempts and provide invaluable information on DHCP functionality. Be sure to check these logs if you suspect any DHCP-related issues.
The DHCP console displays current lease information in the Address Leases node. If you’ve configured your DHCP servers in load-balancing mode, use this node to see which server provided IP configurations to the various clients.
Test the configuration
Testing is a key part of disaster recovery planning, and DHCP failover is no different. Consider disabling one of your DHCP servers to ensure client devices can still lease IP address configurations within your mean time to recovery window.
Wrap up
DHCP servers provide essential information to client computers, and Windows Server offers a simple configuration that supports either fault tolerance or load balancing. Take the time to consider the DHCP scopes on your servers and identify those that will benefit from redundancy. Then, follow these steps to add to the reliability and performance of your AD environment.