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.
Третья, заключительная статья о 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.
В процессе миграции серверных систем на 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.
Выбираем архитектуру отказоустойчивого 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 дней.