Третья, заключительная статья о 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 на Windows Server: WinServer 2012 DHCP Failover vs DHCP в отказоустойчивом кластере. Сочетание двух технологий в одной супер-устойчивой службе DHCP с возможностью территориального распределения нод.
Планирование
Выбор ПО/вендора
Почему служба DHCP разворачивается на ОС от Microsoft Windows 2012? Все просто: популяризация серверных ОС высока в компаниях, DHCP-сервисы вполне логично разворачивать на Windows Servers. В моем случае — это еще исторический момент: уже давно работала серия отдельных DHCP-серверов, которые требовалось заменить на более удобный в администрировании инструмент с единой точкой управления. Служба ТП, состоящая из эникеев (junior admins), пользуется mmc-консолями управления DHCP и управляет резервациями ip-адресов.
Требования к отказоустойчивости
Необходимо определиться, сколько часов/минут/секунд в год допустимо, чтобы сервис простаивал. Если это значение равняется 2 дням и более, это значение можно реализовать и без кластерных служб, а уделив внимание на хорошее охлаждение серверной комнаты, надежную электроподачу, правильный рейд-массив, и регулярный бэкап DHCP-сервера. Если значения между значениями 1-2 дней, следует рассмотреть DHCP-сервер внутри виртуальной машины. Эта виртуалка будет находиться на Hyper-V хосте 2012 версии, и реплицироваться на второй Hyper-V хост в целях отказоустойчивости. Данная реализация не потребует больших денежных растрат и серьезного оборудования в арсенале ИТ. Однако сегодня мы рассматриваем инфраструктуру в компании, где допустимое время простоя составляет минимальные значения. Таких результатов можно добиться, поместив виртуальную машину с DHCP-сервером на отказоустойчивый гипервизор. Однако такая реализация имеет большой минус: когда происходит авария, вируальная машина перемещается на другой гипервизор, однако вируалка «ресетится» (с точки зрения виртуальной машины, в момент аварии ее просто неправильно выключили и включили вновь на новом сервере). Виртуальной машине нужно время на загрузку, перед тем как она возобновит предоставлять услуги DHCP-сервера. Следующая веха развития — реализация DHCP-сервиса в отказоустойчивом кластере, в аварийной ситуации служба простаивает на момент переноса служб с одного сервера на другой (оба они включены, работают ОС и готовы к запуску необходимых служб), что на практике обусловлено временем запуска необходимых служб и назначения их ip-адресов, а для DHCP-сервера это в общей сложности около 5-15 секунд.
Ну, и конечно, стоит поговорить о новой фиче Windows Server 2012: DHCP Failover. Эта фича представляет из себя обычную синхронизацию двух standalone-серверов с WinServer 2012 на борту с поднятой DHCP-ролью. Что интересно, репликация настраивается на отдельный scope! Т.е. имея один DHCP с двумя областями, можно каждую область реплицировать на разные DHCP-партнеры. При этом фича DHCP-репликация с DHCP-серверами в Windows Failover Cluster ничем не ограничена и доступная для реализации. Картинка прилагается:
Требования к оборудованию
Требования к ресурсам у службы DHCP низкие. Однако при развороте служб в отказоустойчивом кластере от Майкрософт, следует выполнять его требования при планировании.
Отказоустойчивый кластер Микрософт используется практически во всех реализациях отказоустойчивый и высокодоступных сервисов на основе продуктов от Microsoft, будь то MS Sharepoint или MS SQL Server. Поэтому на Technet в разделе требований для постройки кластера МС очень много информации. В случае разворота DHCP-кластера, нам из всего этого списка нужно только Центральное хранилище данных для хранения базы DHCP. Это может быть NAS от вендора; iSCSI-target сервер (на рынке ПО этого добра навалом, в том числе от Microsoft; связка отказоустойчивого drbd и SCST на двух и более Линукс-машинках. Главное, чтобы решение поддерживало SCSI-3 persistent reservation (требование для постройки кластера).
Имея в арсенале центральное хранилище, мы сможем собрать кластер из двух DHCP-серверов. Однако, эти два сервера можно сделать виртуальными, в том числе каждая виртуальная машина может сама по себе работать в Hyper-V-кластере (отказоустойчивом ESX, или другом гипервизоре). И все это привносит свои новые коррективы к списку требований к оборудованию.
В данной документации я не буду рассматривать тонкости разворачивания кластера Гипер-В, а остановлюсь на обсуждении DHCP-серверов.
Архитектура
Следующая архитектура была реализована в центральном офисе компании. Как видно на схеме, у меня DHCP-сервер работает вместе с файловым сервером.
Сервисы DHCP и файлов предоставляют виртуальные машины (ВМ): srv05, srv06, srv07. Виртуальная машина srv05 находится в кластере виртуальных машин cluster01, подключенном к дисковому хранилищу nas01 (ДХ), и может работать на любом хосте этого кластера. srv06 работает на отдельном Hyper-V хосте sov09, подключенном к ДХ. ВМ srv05 и srv06 подключены непосредственно к разделам ДХ с помощью Virtual SAN Adapter в настройках ВМ, на каждом Hyper-V хосте для этого настроен Virtual SAN Switch. srv05 и srv06 видят разделы ДХ, и объединены в кластер cluster02.itisok.ru с общим ДХ. srv07 работает на отдельном Hyper-V хосте sov11, не подключенном к ДХ, однако sov11 имеет локальный объемный дисковый массив. Для srv07 выделен этот локальный дисковый массив, подключенный как обычный виртуальный жесткий диск через Virtual SCSI Controller.
Конечные сервисы:
- Storage-cl01.itisok.ru – роль кластера cluster02.itisok.ru, файловый сервис SMB. Синхронизируется с помощью DFS Replication с файловым сервисом SMB на srv07.itisok.ru
- dhcp01.itisok.ru – роль кластера cluster02.itisok.ru, сервис DHCP. Имеет отношения с DHCP сервисом на srv07.itisok.ru в качестве DHCP Failover Load Sharing Mode. dhcp01.itisok.ru является главной репликой базы DHCP, настройки DHCP реплицируются каждые 30 минут С ПЕРЕЗАПИСЬЮ на srv07.itisok.ru. Администрирование DHCP следует проводить на dhcp01.itisok.ru
- srv05.itisok.ru, srv06.itisok.ru, srv07.itisok.ru – сервера пространства имен доменных DFS-корней \\itisok.ru\public, \\itisok.ru\system, \\itisok.ru\private, для конечного использования создан DNS-CNAME (псевдоним) storage01.itisok.ru, который обслуживает всю DFS-инфраструктуру
Сервера DHCP , инфраструктура отказоустойчивости
На текущую дату 16.08.2013 архитектура DHCP-сервиса выглядит следующим образом:
- Сервис dhcp01.itisok.ru — кластеризованная отказоустойчивая служба DHCP, главная реплика настроек DHCP-сервиса. Администрирование DHCP следует проводить через эту главную реплику сервиса DHCP. Сервис работает в кластерном режиме «актив-пассив» на серверах: srv05.itisok.ru, srv06.itisok.ru. Для администрирования DHCP не важно в каком состоянии находится кластер и его ноды.
- Сервис srv07.itisok.ru — второстепенная реплика настроек DHCP-сервиса. Администрирование DHCP НЕ СЛЕДУЕТ проводить через эту второстепенную реплику, т.к. все введенные изменения в конфигурации будут затерты конфигурацией главной реплики DHCP-сервиса (dhcp01.itisok.ru) в течении 30 минут в автоматическом режиме.
Репликация между DHCP-службами dhcp01.itisok.ru и srv07.itisok.ru реализована функцией DHCP Failover Load Shared mode (подробнее…). Прошу заметить, что в нашей инфраструктуре работает два способа отказоустойчивости одновременно:
- DHCP in a Windows failover cluster: кластер clister02.itisok.ru, его ноды srv05.itisok.ru, srv06.itisok.ru, в кластере поднята отказоустойчивая роль dhcp01.itisok.ru. Управление этим кластером осуществляется через консоль «Управление отказоустойчивостью кластеров» с любого компьютера под управлением ОС Windows 8/2012, в рядовом администрировании управление им не требуется.
- DHCP Failover Load Shared mode: когда два абсолютно независимых DHCP реплицируются между собой и одновременно работают в одной сети. Здесь в качестве независимых DHCP-сервисов работают dhcp01.itisok.ru и srv07.itisok.ru. Режим работы двух реплик — «актив-актив» (оба отвечают на запросы клиентов, оба раздают ip-адреса). Отказоустойчивость управляется через консоль DHCP с любого компьютера под управлением ОС Windows 8/2012, в рядовом администрировании управление им не требуется.
Особенности работы DHCP Failover:
- Репликация между сервисами ограничена информацией об аренде ip-адресов, но не конфигураций областей DHCP, в том числе, не реплицируются новые резервации ip-адресов. Полную репликацию всех параметров всех областей можно провести через консоль DHCP (только ОС Windows 8/2012 и выше) или командой PowerShell.
- При смене конфигураций области (например, добавление резервирования ip-адреса), необходимо реплицировать эту область на реплику DHCP. Для упрощения администрирования, это реализовано автоматической репликацией при загрузке сервера srv07.itisok.ru и далее каждые 30 минут, при этом путь репликации строго указан от «основной» реплики dhcp01.itisok.ru к «второстепенной» реплике srv07.itisok.ru С ПЕРЕЗАПИСЬЮ всей конфигурации на srv07. Такая задача реализована через Диспетчер задач сервера srv07.itisok.ru, где создано задание «Invoke-DhcpServerv4FailoverReplication», которая запускает команду PowerShell:
$log = Invoke-DhcpServerv4FailoverReplication -ComputerName dhcp01.itisok.ru -Name dhcp01.itisok.ru-srv07.itisok.ru -Force -verbose 4>&1 | Out-String -width 500; Write-EventLog -LogName Application -Source "DhcpFailoverReplicat" -EntryType Information -EventID 1 -Message "$log". Команда пишет в Application Log событие о репликации (перед этим надо зарегистрировать Log Source командойNew-EventLog –LogName Application –Source "DhcpFailoverReplicat") - Максимум два сервера на одну область в режиме DHCP Failover, на 16.08.2013 имеется единственная область 172.16.0.0/20.
Администрирование DHCP
Администрирование DHCP осуществляется:
- Консолью DHCP на компьютере под управлением Windows 8/2012 и выше, введенным в домен itisok.ru, под учетной записью, являющейся членом группы itisok.ru: Администраторы домена, Администраторы DHCP
- Консолью DHCP на компьютере под управлением Windows 7/2008 R2 с ограниченным функционалом в администрировании DHCP, введенным в домен itisok.ru, под учетной записью, являющейся членом группы itisok.ru: Администраторы домена, Администраторы DHCP
Правила администрирования DHCP:
- Включить компьютер или Avaya ip-телефон в сеть. С этого момента ими можно пользоваться. Переписать полученный ip-адрес (в Avaya ip-телефоне переписать MAC-адрес).
- На компьютере или сервере под управлением Windows, включенном в домен itisok.ru, под учетной записью пользователя с необходимыми правами доступа, открыть консоль DHCP. На скриншоте пример запуска из командной строки.
- В открывшейся консоли, при отсутствии dhcp01.itisok.ru, добавить его в консоль:
- Раскрыть необходимый раздел администрирования dhcp01.itisok.ru:
Администрирование DHCP сводится к правке области [172.16.0.0] lan01, являющейся основной областью назначения ip-параметров офиса, включая в себя:
Адреса 172.16.0.1 — 172.16.0.255 для серверов, их сервисов, роутеров и т.п., только для служебного администрирования старшими системными администраторами. Адреса назначаются статическими в этом диапазоне.
Адреса 172.16.1.0 — 172.16.1.255 — для служебного администрирования только старшими системными администраторами. Адреса назначаются статическими в этом диапазоне.
Адреса 172.16.2.0 — 172.16.2.255 — для сетевых принтеров, МФУ и т.п. Адреса назначаются резервацией ip службой ТП.
Адреса 172.16.3.0 — 172.16.7.255 — для рабочих станций рядовых пользователей. Адреса назначаются резервацией ip службой ТП.
Адреса 172.16.8.0 — 172.16.9.255 — для новых рабочих станций рядовых пользователей. Адреса назначаются резервацией ip службой ТП.
Адреса 172.16.10.0 — 172.16.10.255 — для рабочих станций исключительных пользователей, для служебного администрирования только старшими системными администраторами. Адреса назначаются статическими в этом диапазоне.
Адреса 172.16.11.0 — 172.16.13.255 — резервный пул ip-адресов, пустой, для служебного администрирования только старшими системными администраторами. Адреса не назначаются.
Адреса 172.16.14.0 — 172.16.14.19 — для серверного оборудования ip-телефонии, для служебного администрирования только старшими системными администраторами. Адреса назначаются статическими в этом диапазоне
Адреса 172.16.14.20 — 172.16.14.255 — для конечных устройств ip-телефонии головного офиса: телефоны Avaya и т.п. Адреса назначаются автоматически только Avaya ip-телефонам (политика avaya ip-tel, см. ниже) или резервацией DHCP-сервера службой ТП.
Адреса 172.16.15.0 — 12.16.15.254 — для конечных устройств ip-телефонии удаленных офисов (филиалов), подключающихся через VPN-туннель к головному офису: телефоны Avaya и т.п. Для служебного администрирования только старшими системными администраторами. Адреса назначаются DHCP-службой ВПН-сервера.
В консоли управления DHCP, развернув нужную область, открыв раздел «Арендованные адреса» найти записанный ip или MAC-адрес. Если работа проводится через консоль на Windows 8/2012 — нажать правой кнопкой мыши по нужной записи и выбрать «Добавить к резервированию»:
Если работа производится через консоль на Windows 7/2008 R2 и ниже (не рекомендуется), графа «Добавить к резервированию» не отображается в консоли. В этом случае надо запомнить пару ip-адрес = MAC-адрес, перейти в раздел «Резервирование», и создать новое резервирование с этой парой в ручном режиме:
При создании резервации настоятельно рекомендуется соблюдать пару уже арендованного ip-MAC. Если это невозможно (к примеру, настраивается сетевой принтер) — следует перегрузить ip-оборудование и проверить, что ему выдан правильный ip-адрес, перед вводом оборудования в эксплуатацию.
На этом этапе работа с DHCP закончена, резервация добавлена и готова к работе.
Разделение зон ответственности и прав администрирования
В связи с невозможностью гибкого распределения прав доступа к отдельным веткам администрирования DHCP-сервисом, все системные администраторы и сотрудники службы ТП имеют полные права на администрирование любых DHCP-серверов в домене itisok.ru. Нижеследующий список формулирует зоны ответственности и прав администрирования между сотрудниками:
- Старшие системные администраторы ответственны за управление всеми DHCP-серверами в домене itisok.ru и внутренней сети любого из vlan.
- Сотрудники службы ТП ответственны за управление:
Ограниченное управление только сервиса dhcp01.itisok.ru, являющегося главной репликой всей DHCP-инфораструктуры
Ограничение управления сервиса dhcp01.itisok.ru следующими разделами:
Область [172.16.0.0] lan01
- Арендованные адреса
- Резервирование
Текущие настройки DHCP
DHCP-сервис настроен следующим образом:
Настройка сервиса DHCP:
- Всегда обновлять DNS-записи DHCP-клиентов без запроса клиента
- НЕ удалять A-запись по истечении аренды
- Учетные данные динамической регистрации DNS: itisok.ru\DHCP-DNS-Dynam-Upd01
- Параметры сервера не указаны
- Параметры политики не указаны
- Параметры фильтров не указаны
Область: [172.16.0.0] lan01
- Маска подсети: 255.255.240.0
- Диапазон выдаваемых адресов: 172.16.0.1 — 172.16.15.254
- Исключения: 172.16.0.1 — 172.16.7.255; 172.16.10.0 — 172.16.15.254
- Выдаваемые в аренду адреса без резерваций: 172.16.8.0 — 172.16.9.255
- Срок аренды: 8 дней
- Всегда обновлять DNS-записи DHCP-клиентов без запроса клиента
- НЕ удалять A-запись по истечении аренды
Параметры области:
- 003 Маршрутизатор: 172.16.0.1
- 006 DNS Серверы: 172.16.0.101 172.16.0.102 172.16.0.103
- 015 DNS-имя домена: itisok.ru
- [Политика avaya ip-tel] 176 Avaya option 176: MCIPADD=172.16.14.3,MCPORT=1719,TFTPSRVR=172.16.14.4
- [Политика avaya ip-tel] 242 Avaya option 242: MCIPADD=172.16.14.3,MCPORT=1719,HTTPSRVR=172.16.14.4
Два параметра выше отображаются в свойствах области, но пренадлежат политике avaya ip-tel, настраивающаяся как показано ниже.Если DHCP-клиент не соответствует условиям применения данной политики, то параметры 176 Avaya option и 242 Avaya option не применяются.
Политики:
- avaya ip-tel:
- Порядок 1
- Диапазон адресов: 172.16.14.20 — 172.16.14.255
- Срок аренды: 60 дней
- Уровень: область (применяется на область [172.16.0.0] lan01, в которой политика указана)
- Условия: (при которых политика применяется DHCP-клиентам) MAC-адрес равен:
— или 2CF4C5*
— или CCF954*
— или 3CB15B*
— или 001A64*
— или001B4F*
— или 00073B*
— или 00215E*
— или B4B017*
— или 7038EE*
Перечисленные выше MAC-адреса принадлежат всей серии ip-телефонов Avaya, используемых в офисе.
- Параметры:
- 176 Avaya option 176: MCIPADD=172.16.14.3,MCPORT=1719,TFTPSRVR=172.16.14.4
- 242 Avaya option 242: MCIPADD=172.16.14.3,MCPORT=1719,HTTPSRVR=172.16.14.4
- Всегда обновлять DNS-записи DHCP-клиентов без запроса клиента
- НЕ удалять A-запись по истечении аренды
Данная политика avaya ip-tel в итоге применяется в случае совпадения начала MAC-адреса с перечисленными (MAC-адреса серии ip-телефонов Avaya), и назначает отобранным DHCP-клиентам диапазон адресов 172.16.14.20 — 172.16.14.255 (срок аренды неограниченный), и параметры политики: 176 Avaya option, 242 Avaya option (поиск серверов Avaya и сервера прошивок), а также политики области: 003 Маршрутизатор, 006 DNS Серверы, 015 DNS-имя домена.
Любой новый Avaya-телефон, не настроенный в резервации, будет получать адрес из правильного диапазона 172.16.14.20 — 172.16.14.255 и сразу получать параметры серверов Avaya и сервера прошивок, при этом аренда адреса составит 60 дней.
Windows Server Core не пользуется большой популярностью у ряда администраторов и, на наш взгляд, совершенно зря. Благодаря меньшему количеству работающих приложений и служб он более прост в обслуживании, ему требуется меньшее количество обновлений, а также он безопаснее, за счет сужения возможного периметра атаки. Windows Server Core отлично подходит для тех систем, где от пользователя не требуется интерактивное взаимодействие с рабочим столом, например, контроллеров домена. В этой статье мы рассмотрим, как развернуть минимальную конфигурацию Active Directory с отказоустойчивым DHCP.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Для полноценного функционирования Active Directory вам потребуется не менее двух контроллеров домена, это могут быть как физические, так и виртуальные машины, но мы рекомендуем иметь хотя бы один контроллер на физическом узле. В нашем случае будет использоваться два ПК с Windows Server 2022 в варианте Core, тем не менее данный материал подходит для всех актуальных версий Windows Server.
Перед тем как приступать к установке сделаем небольшое планирование, прежде всего определимся с адресным пространством и адресами основных узлов сети. В нашем случае это будет:
- 192.168.78.0/24 — используемая сеть
- 192.168.78.1 — основной шлюз сети
- 192.168.78.7 — CORE-DC01 — первый контроллер домена
- 192.168.78.8 — CORE-DC02 — второй контроллер домена
- 192.168.78.100 — 199 диапазон адресов к раздаче через DHCP
- it-31.lab — полное имя домена
При выборе диапазона адресов избегайте широко используемых в сетевом оборудовании 192.168.0.0/24, 192.168.1.0/24 и т.п. чтобы при расширении сети или подключении удаленных пользователей не столкнуться с проблемами, связанными с пересечением адресного пространства. Также напоминаем, что в Active Directory нет первичных и вторичных контроллеров домена, все контроллеры равноправны.
Перейдем к практической части и установим на два сервера Windows Server 2022 в режиме Core, во время первой загрузки вам будет предложено установить пароль для встроенной учетной записи Администратор, обратите внимание, что если вы использовали русскую редакцию, то по умолчанию у вас будет использоваться русская раскладка.
После чего будет запущена утилита SConfig для базовой настройки сервера, но автоматический ее запуск присутствует только в Windows Server 2022, в других редакциях для ее вызова введите:
sconfigИспользование утилиты простое: выбираем нужный нам цифровой пункт и следуем дальнейшим подсказкам.
Начать следует с пункта 2 и установить имя компьютера согласно запланированному. Затем перейти к пункту 7 и включить удаленный рабочий стол для доступа к серверу по RDP. После чего переходим в пункт 8 и настраиваем сеть и указываем адреса DNS-серверов. На последних следует остановиться более подробно. Текущие рекомендации советуют указывать в качестве первичного сервера DNS адрес любого иного контроллера домена, дополнительным — адрес локальной петли (127.0.0.1). Таким образом для первого сервера укажем 192.168.78.8 и 127.0.0.1, для второго: 192.168.78.7 и 127.0.0.1.
Тот факт. что никаких DNS-серверов по этим адресам у нас пока нет смущать не должен, дальнейшим действиям это не помешает, но избавит вас от необходимости повторно изменять сетевые настройки.
Выше были приведены минимально необходимые настройки, после их внесения сервер обязательно требуется перезагрузить.
После перезагрузки перейдем в командную строку PowerShell и установим необходимые компоненты:
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Install-WindowsFeature DHCP -IncludeManagementTools
Дальнейшие действия мы будем выполнять на CORE-DC01.
Так как у нас нет никакой структуры AD, то нам потребуется сначала создать лес, а потом первый домен в нашем лесу. Для этого используется командлет Install-ADDSForest, в сети можно встретить огромные «заклинания» с перечислением кучи параметров, но в большинстве случаев они дублируют параметры по умолчанию и приводить их нет никакой необходимости, поэтому укажем только необходимые:
Install-ADDSForest -DomainName "it-31.lab" -InstallDNSЭта команда повысит сервер до контроллера, создаст новый лес с указанным доменом в нем, а также установит DNS-сервер и сделает контроллер Глобальным каталогом. При этом вам потребуется указать пароль для режима восстановления и подтвердить автоматическую перезагрузку.
Из дополнительных опций вам может понадобиться -DomainNetbiosName — которое задает NetBIOS-имя домена, NetBIOS-имя автоматически формируется из префикса (первой части до первой точки) полного доменного имени и не может быть длиннее 15 символов, если префикс длиннее 15 символов, то имеет смысл указать NetBIOS-имя отдельно.
Следующие две опции -ForestMode и —DomainMode указывают уровень леса и уровень домена. Уровень домена не может быть ниже уровня леса, но может быть выше его. Уровень определяет нижнюю версию контроллеров, которые можно использовать в лесу или домене. По умолчанию выбираются максимальные уровни. Всего же доступны следующие значения:
- Windows Server 2003: 2 или Win2003
- Windows Server 2008: 3 или Win2008
- Windows Server 2008 R2: 4 или Win2008R2
- Windows Server 2012: 5 или Win2012
- Windows Server 2012 R2: 6 или Win2012R2
- Windows Server 2016: 7 или WinThreshold
Максимальный уровень домена на текущий момент — Windows Server 2016.
По окончании настройки контроллер домена будет автоматически перезагружен. Как видим, создание контроллера домена при помощи PowerShell даже быстрее и проще, чем использование привычного графического мастера. Всего одна команда против клацанья мышкой на нескольких экранах.
Теперь перейдем на CORE-DC02 и первым делом попробуем ввести его в домен, воспользовавшись цифровым пунктом 1 в SConfig, если нигде не допущено ошибок, то эта задача увенчается успехом. Таким образом мы убедились, что созданный нами контроллер работает, поэтому перезагружаемся и идем дальше.
Для добавления контроллера в существующий домен мы будем использовать иной командлет — Install-ADDSDomainController, и, точно также, вместо огромных заклинаний будем использовать только необходимые параметры, в командной строке PowerShell выполните:
Install-ADDSDomainController -DomainName "it-31.lab" -InstallDns -Credential (Get-Credential "IT-31\Администратор")Данная команда добавит контроллер в указанный домен, установит DNS и сделает его глобальным каталогом, в качестве дополнительной опции мы указали учетные параметры администратора домена.
На этом базовое развертывание Active Directory завершено, как видим, использование Windows Server Core ни капли не усложняет процесс, наоборот, использование командной строки позволяет выполнить эту операцию быстрее и проще.
Для получения дополнительной информации о всех возможных ключах в использованных командлетах рекомендуем обратиться к документации.
Install-ADDSForest
Install-ADDSDomainController
Для дальнейшей настройки и управления созданной инфраструктурой мы будем использовать привычные инструменты из пакета RSAT, в Windows 10 / 11 их можно получить в разделе Приложения — Дополнительные компоненты приложения Параметры. Нам потребуются оснастки для управления Active Directory, DNS и DHCP, а также редактор групповых политик.
Продолжим настройку с DNS, а именно добавим обратную зону. В минимальной конфигурации она не нужна, но многие приложения, интернирующиеся с AD, могут не работать или работать неправильно без обратной зоны.
Поэтому откроем оснастку управления DNS и подключимся к любому из серверов, там перейдем к разделу Зоны обратного просмотра и создадим новую зону, при этом укажем параметры: Основная зона — Для всех серверов — Зона обратного просмотра IPv4, после чего укажем Идентификатор сети — первые три октета IP-адреса, на его основе будет сформировано имя зоны.
После создания обратной зоны заглянем в свойства самого DNS-сервера и укажем сервера пересылки — список DNS-серверов которым будут отправляться запросы, которые наш сервер неспособен разрешить самостоятельно, в их качестве следует указать адреса серверов имен провайдера или публичные сервера.
На этом настройка DNS-сервера закончена, и мы переходим к финальной части — настройке DHCP. Откроем оснастку управления DHCP-сервером и подключимся к одному из них, прежде всего сервер нужно авторизовать в Active Directory, для этого щёлкните на нем правой кнопкой мыши в открывшемся меню выберите Авторизовать.
Теперь создадим в Active Directory пользователя, например, dhcp-dns-update и сделаем его членом единственной группы DnsUpdateProxy.
Раскроем дерево сервера, перейдем в свойства IPv4 на закладку Дополнительно и нажмем Изменить рядом с надписью Учетные данные для регистрации динамических обновлений DNS, в открывшемся окне введем данные созданного нами пользователя.
Указанные выше настройки следует выполнить для обоих серверов.
Теперь на одном из них настроим область при помощи мастера, укажем диапазон выдаваемых адресов и маску сети:
Шлюз и DNS-сервера, напоминаем, что клиентам следует выдавать только адреса доменных DNS-серверов:
Завершив создание зоны, убеждаемся, что DHCP сервер работает нормально: выдает адреса клиентам и регистрирует динамические записи для них на DNS-сервере. После чего перейдем к созданию отказоустойчивой конфигурации. Открываем меню правой кнопкой мыши для области и выбираем в нем Настройка наработки отказа, в открывшемся мастере выбираем сервер-партнер (второй сервер), настраиваем режим работы — по умолчанию балансировка 50 / 50 — и задаем секретный ключ.
По окончанию работы мастера будет выполнена автоматическая настройка второго сервера и выполнена репликация данных между ними.
В процессе эксплуатации DHCP-сервера помните, что автоматически реплицируются только данные об аренде, если вы изменили настройки области или выполнили резервирование, то следует запустить репликацию данных вручную, для этого щелкните на области правой кнопкой мыши и в меню выберите Репликация области. Если вы изменили настройки обработки отказа, то следует выполнить Репликацию отношения.
На этом настройка базовой конфигурации Active Directory с отказоустойчивой конфигурацией DHCP завершена. Как видим, сделать это на основе Windows Server Core абсолютно несложно, поэтому не следует пугаться и избегать этого сценария, а, наоборот, использовать вариант установки Core там, где он более всего подходит, например, как в нашем случае.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
В Windows Server 2000/2003 отказоустойчивость DHCP можно было организовать только с помощью кластера Microsoft, в Windows Server 2008 уже без кластера, но с помощью довольно ограниченной функции DHCP Failover. В Windows Server 2012 R2 появился новый встроенный функционал высокой доступности (High Availability) DHCP, позволяющий с легкостью обеспечить HA для сервиса DHCP.
Рассмотрим механизм работы высокодоступного DHCP сервера. На двух серверах устанавливаются роли DHCP, и настраивается репликация нужных DHCP зон, которым нужно обеспечить отказоустойчивость. По сути отказоустойчивость реализуется за счет распределения зоны между серверами, которые одновременно обслуживают одну область и реплицируют информацию между собой.
- Установка роли DHCP Server в Windows Server 2012 R2
- Настройки отказоустойчивости DHCP
- Несколько полезных замечаний о DHCP HA
Содержание:
Есть два режима обеспечения высокой доступности DHCP:
- балансировка нагрузки – запросы клиентов распределяется между серверам
- горячая замена – второй сервер реплицирует данные зоны с основного сервера, и при выходе его их строя активируется и начинает обслуживать клиентов
Как правило, режим балансировки нагрузки является оптимальным. Запросы клиентов делятся в заданном соответствии, а в случае выхода из строй одного сервера, обслуживание клиентов продолжит оставшийся сервер.
Установка роли DHCP Server в Windows Server 2012 R2
Установка роли DHCP крайне проста и не требует перезагрузки сервера.
- Откройте консоль Server Manager.
- Нажмите Add Roles and Features.
- В списке ролей выберите DHCP Server .
При помощи PowerShell установить роль еще проще
Add-WindowsFeature DHCP –IncludeManagementTools
Даже если система запросит перезагрузку сервера, можно проигнорировать этот запрос. После установки роли, администратор должен настроить DHCP зоны и их параметры. В нашем примере на первом DHCP сервере мы создадим одну DHCP зону с именем Servers, настроим параметры шлюза, DNS сервера и другие настройки зоны. В качестве динамического диапазона адресов укажем диапазон с 10.60.1.100 по 10.60.1.150.
Затем нужно установить роль DHCP на втором сервере (зону настраивать при этом не нужно).
Настройки отказоустойчивости DHCP
Отказоустойчивость DHCP настраивается с помощью мастера, который можно вызвать, щелкнув ПКМ по зоне и выбрав Configure Failover.
На первом этапе мастер DHCP Failover предлагает выбрать зоны, отказоустойчивость которых нужно обеспечить. У нас она одна, поэтому нажимаем Next.
На втором шаге нужно будет указать имя второго DHCP сервера партнера.
В следующем окне нужно указать имя связи (Relationship name), режим балансировки нагрузки между серверами (в каком соотношении будет разделена область между двумя серверами), время аренды ip адреса новым клиентом (это же время определяем время ожидания восстановления канала связи с партнёром), интервал автоматического переключения.
Знакомимся с результирующими настройками и жмем Finish.
На этом все. Реплицированная область появится на втором DHCP сервере.
Несколько полезных замечаний о DHCP HA
Есть несколько полезных премов, которые могут сэкономить администратору много времени при работе с новой конфигурацией отказоустойчивого DHCP.
- В ваших сетях могут быть настроены DHCP relay (IP Helper) на уровне VLAN для пересылки запросов на определенный сервер. В этом случае нужно добавить адреса обоих DHCP серверов в конфигурацию сетевого оборудования
- С помощью команды
ipconfig /allна клиенте можно узнать имя DHCP-сервера, выдавшего IP адрес. Это бывает полезно при поиске неисправностей. - DHCP репликация выполняется только на уровне зоны. Если вы настроили некие параметры на уровне сервера (как правило, это имя домена, DNS сервера и т.д.), убедитесь что они одинаковые на обоих DHCP серверах.
- При удаленном подключении к компьютеру клиента, чтобы освободить текущий адрес и запросить новый, пользуйтесь командой:
ipconfig /release && ipconfig /renew
Как известно, DHCP – важнейший компонент сетевой инфраструктуры. В большинстве сетей компьютеры пользователей применяют протокол DHCP для получения информации об IP-адресах. Проблема в том, что, в отличие от DNS, достижение высокой доступности серверов DHCP не всегда было такой уж простой задачей.
В случае отказа сервера DHCP и невозможности быстро вернуть его в строй компьютеры не могут получить доступ к сети, потому что у них нет действительных IP-адресов. И если у вас отсутствуют средства мониторинга, вероятно, вы узнаете о сбое DHCP, только когда возрастет число пользователей с самоназначаемыми IP-адресами в диапазоне действия службы Automatic Private IP Addressing (APIPA).
В предыдущих версиях Windows, таких как Windows Server 2008 R2 и Windows Server 2003, у нас было две основные возможности для обеспечения высокой доступности протокола DHCP.
— Установить сервер DHCP на отказоустойчивом кластере, а информация о настройке при этом хранится в общей папке.
— Настроить разделенные области адресов. При настройке область адресов разделяется таким образом, что 80% диапазона используется для аренды адресов на первичном сервере DHCP отдельной подсети, чтобы отвечать на запросы клиентов. Оставшиеся 20% адресов аренды находятся на сервере DHCP удаленной подсети. Эти адреса используются клиентами только тогда, когда DHCP-сервер с 80% адресов недоступен.
Windows Server 2012 облегчает доступность DHCP, предоставляя функцию отказоустойчивости протокола DHCP в служебной роли DHCP. Отказоустойчивость DHCP позволяет обеспечить высокую доступность службы DHCP без настройки разделенных областей или развертывания отказоустойчивого кластера. Сначала я подробно расскажу о новой функции, а потом покажу, как ее настроить.
Условие отказоустойчивости DHCP
Отказоустойчивость DHCP подразумевает настройку двух компьютеров Server 2012 со служебной ролью DHCP и установку их в паре. Эта пара способна обеспечить высокую доступность DNS, благодаря следующим техническим возможностям.
*Режим балансировки нагрузки (Load balance mode). Режим балансировки нагрузки (в документации он иногда называется режимом распределения нагрузки, load sharing mode) – это способ настройки отказоустойчивости DHCP по умолчанию. Когда вы настраиваете два сервера DHCP в режиме балансировки нагрузки, каждый сервер будет предоставлять IP-адреса из одной и той же области, и при этом адреса не дублируются. Балансировка нагрузки позволяет каждому серверу выдавать адреса в аренду из указанного диапазона. При отказе одного из серверов DHCP другой продолжает предоставлять адреса, пока первый сервер DHCP снова не начнет работать. На экране 1 приведен пример настройки диапазона адресов DHCP в режиме балансировки нагрузки.
|
| Экран 1. Просмотр свойств диапазона DHCP при использовании режима Load Balance |
*Режим горячей замены (Hot standby mode). Когда вы настраиваете два сервера с ролью DHCP, реализованной в режиме горячей замены, или горячего резервирования, серверы работают в отношениях отказоустойчивости. Активный сервер предоставляет IP-адреса и информацию о настройке клиентам. Второй же сервер выполняет эту функцию в том случае, если первый недоступен. На экране 2 показана область DHCP, настроенная в режиме горячей замены.
|
|
| Экран 2. Просмотр свойств диапазона DHCP при включении режима Standby Mode |
Настройка отказоустойчивого DHCP
Отказоустойчивый DHCP подразумевает взаимодействие двух серверов DHCP. Только два сервера DHCP могут взаимодействовать друг с другом, но вы можете настроить различные партнерские отношения между серверами DHCP. Например, в вашей инфраструктуре партнерами могут быть DHCP-ОДИН и DHCP-ДВА, DHCP-ДВА и DHCP-ТРИ или DHCP-ОДИН и DHCP-ТРИ. Тем не менее, отдельная область DHCP может использоваться исключительно в одном партнерстве. Например, вы можете настроить диапазон SCOPE-ALPHA с высокой доступностью на серверах DHCP-ОДИН и DHCP-ДВА, но этот диапазон не может быть представлен и для DHCP-ТРИ.
Чтобы настроить отказоустойчивый вариант DHCP, выполните следующие шаги.
- Установите роль DHCP на двух отдельных серверах под управлением Server 2012, которые являются членами одного и того же домена Active Directory (AD).
- Убедитесь, что роль DHCP на каждом сервере авторизована в AD.
- Создайте соответствующие области на первом сервере DHCP.
- Выберите область адресов, для которой вы включаете функцию отказоустойчивости. В меню Action нажмите Configure Failover.
- На странице Introduction to DHCP Failover мастера Configure Failover убедитесь в наличии выбранной вами области и нажмите Next.
- На странице Specify the partner server to use for failover нажмите Add Server. На экране 3 в окне Add Server вы видите список всех компьютеров Server 2012, выполняющих служебную роль DHCP и авторизованных в домене. Выберите сервер DHCP, который хотите использовать в качестве сервера-партнера, и нажмите OK.
- На странице Specify the partner server to use for failover нажмите Next.
- На странице Create a new failover relationship выберите либо режим Load balance, либо Hot standby в раскрывающемся списке Mode.
- Если вы настраиваете сервер в режиме балансировки нагрузки, определите приоритет weight, который нужно назначить каждому серверу. По умолчанию каждый сервер работает в варианте равномерного распределения нагрузки equal load, как показано на экране 4. Если вы настраиваете сервер в режиме горячей замены, задайте роль сервера-партнера (Active, либо работающий в режиме ожидания Standby) и процент адресов, выделенный для резервного сервера из диапазона, как показано на экране 5.
- При желании задайте параметр State Switchover Interval. Данная настройка определяет временной интервал до начала выдачи резервным сервером адресов клиентам сети.
- Выберите общий секретный ключ shared secret. Это позволит вам объединить в пару серверы DHCP. Щелкните Next.
- На последней странице нажмите Finish.
|
|
| Экран 3. Выбор DHCP Server в качестве партнера |
|
|
| Экран 4. Настройка DHCP в паре при использовании режима Load Balance |
|
|
| Экран 5. Настройка DHCP в паре при использовании режима горячей замены |
Вы можете настроить только один тип отношений отказоустойчивости между двумя серверами DHCP. Так, если вы настраиваете отношения отказоустойчивости при использовании режима балансировки нагрузки между DHCP-ОДИН и DHCP-ДВА, все настроенные отказоустойчивые области DHCP будут использовать режим load balance. Если вы настраиваете отношения между DHCP-ONE и DHCP-THREE, эти отношения могут задействовать различные способы обеспечения отказоустойчивости. Вы можете видеть взаимосвязи сервера DHCP в таблице Failover диалогового окна IPv6 Properties или IPv4 Properties, как показано на экране 6.
|
|
| Экран 6. Просмотр взаимосвязей отказоустойчивости DHCP сервера DHCP |
Доступный DHCP с минимальными усилиями
Отказоустойчивый сервер DHCP на базе Server 2012 обеспечивает решение высокой доступности для службы DHCP, при этом не требуется настройка раздельных областей или использование отказоустойчивого кластера. В большинстве случаев удобнее будет применить по умолчанию отказоустойчивую настройку DHCP в режиме балансировки нагрузки. Вы можете настроить разные взаимоотношения отказоустойчивости между различными серверами DHCP, но вам удастся создать область высокой доступности, применяя только один тип отношений.