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

Microsoft, Linux, Lync и etc……

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Послесловие

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

Высокодоступный DHCP-сервер на Windows Server 2012 R2

В Windows Server 2000/2003 отказоустойчивость DHCP можно было организовать только с помощью кластера Microsoft, в Windows Server 2008 уже без кластера, но с помощью довольно ограниченной функции DHCP Failover. В Windows Server 2012 R2 появился новый встроенный функционал высокой доступности (High Availability) DHCP, позволяющий с легкостью обеспечить HA для сервиса DHCP.

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

Есть два режима обеспечения высокой доступности DHCP:

• балансировка нагрузки – запросы клиентов распределяется между серверам
• горячая замена – второй сервер реплицирует данные зоны с основного сервера, и при выходе его их строя активируется и начинает обслуживать клиентов

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

Установка роли DHCP Server в Windows Server 2012 R2

Установка роли DHCP крайне проста и не требует перезагрузки сервера.

1. Откройте консоль Server Manager.
2. Нажмите Add Roles and Features.
3. В списке ролей выберите 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 на Windows Server

Выбираем архитектуру отказоустойчивого 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-сервиса выглядит следующим образом:

1. Сервис dhcp01.itisok.ru — кластеризованная отказоустойчивая служба DHCP, главная реплика настроек DHCP-сервиса. Администрирование DHCP следует проводить через эту главную реплику сервиса DHCP. Сервис работает в кластерном режиме «актив-пассив» на серверах: srv05.itisok.ru, srv06.itisok.ru. Для администрирования DHCP не важно в каком состоянии находится кластер и его ноды.
2. Сервис srv07.itisok.ru — второстепенная реплика настроек DHCP-сервиса. Администрирование DHCP НЕ СЛЕДУЕТ проводить через эту второстепенную реплику, т.к. все введенные изменения в конфигурации будут затерты конфигурацией главной реплики DHCP-сервиса (dhcp01.itisok.ru) в течении 30 минут в автоматическом режиме.

Репликация между DHCP-службами dhcp01.itisok.ru и srv07.itisok.ru реализована функцией DHCP Failover Load Shared mode (подробнее…). Прошу заметить, что в нашей инфраструктуре работает два способа отказоустойчивости одновременно:

1. DHCP in a Windows failover cluster: кластер clister02.itisok.ru, его ноды srv05.itisok.ru, srv06.itisok.ru, в кластере поднята отказоустойчивая роль dhcp01.itisok.ru. Управление этим кластером осуществляется через консоль «Управление отказоустойчивостью кластеров» с любого компьютера под управлением ОС Windows 8/2012, в рядовом администрировании управление им не требуется.
2. 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 осуществляется:

1. Консолью DHCP на компьютере под управлением Windows 8/2012 и выше, введенным в домен itisok.ru, под учетной записью, являющейся членом группы itisok.ru: Администраторы домена, Администраторы DHCP
2. Консолью DHCP на компьютере под управлением Windows 7/2008 R2 с ограниченным функционалом в администрировании DHCP, введенным в домен itisok.ru, под учетной записью, являющейся членом группы itisok.ru: Администраторы домена, Администраторы DHCP

Правила администрирования DHCP:

1. Включить компьютер или Avaya ip-телефон в сеть. С этого момента ими можно пользоваться. Переписать полученный ip-адрес (в Avaya ip-телефоне переписать MAC-адрес).
2. На компьютере или сервере под управлением Windows, включенном в домен itisok.ru, под учетной записью пользователя с необходимыми правами доступа, открыть консоль DHCP. На скриншоте пример запуска из командной строки.
   
3. В открывшейся консоли, при отсутствии dhcp01.itisok.ru, добавить его в консоль:
   
4. Раскрыть необходимый раздел администрирования 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. Нижеследующий список формулирует зоны ответственности и прав администрирования между сотрудниками:

1. Старшие системные администраторы ответственны за управление всеми DHCP-серверами в домене itisok.ru и внутренней сети любого из vlan.
2. Сотрудники службы ТП ответственны за управление:

Ограниченное управление только сервиса 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 не применяются.

Политики:

1. 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 дней.