Отказоустойчивый 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-failover-scheme

Требования к оборудованию

Требования к ресурсам у службы 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-and-File-Services-v0.1-itisok

Сервисы 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. На скриншоте пример запуска из командной строки.
    dhcpmgmt
  3. В открывшейся консоли, при отсутствии dhcp01.itisok.ru, добавить его в консоль:
    dhcpmgmt-add-server-01 dhcpmgmt-add-server-02
  4. Раскрыть необходимый раздел администрирования dhcp01.itisok.ru:
    dhcp-administration-01

Администрирование 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 — нажать правой кнопкой мыши по нужной записи и выбрать «Добавить к резервированию»:
dhcp-administration-reserve-ip-01

Если работа производится через консоль на Windows 7/2008 R2 и ниже (не рекомендуется), графа «Добавить к резервированию» не отображается в консоли. В этом случае надо запомнить пару ip-адрес = MAC-адрес, перейти в раздел «Резервирование», и создать новое резервирование с этой парой в ручном режиме:
dhcp-administration-reserve-ip-02 dhcp-administration-reserve-ip-03

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