Основной DHCP выключен, резервный работает, а новые компьютеры не получают IP: разбираем hot standby, MCLT и Partner Down

Я видел эту аварию не раз: основной DHCP недоступен, служба на резервном запущена, старые компьютеры продолжают работать, а новые ноутбуки, телефоны и терминалы получают адрес из APIPA-диапазона 169.254.0.0/16. Обычно в этот момент говорят, что failover сломан. На деле он защищает сеть от двойной выдачи адресов и действует ровно в пределах своего состояния. Разберём, как hot standby распоряжается резервом, зачем нужен MCLT, почему Communications Interrupted не равен Partner Down и какой рунбук помогает вернуть выдачу адресов без опасной импровизации.

Что происходит на самом деле: резерв работает, но не для всех

Первое, что нужно принять: «резервный DHCP отвечает» и «резервный DHCP может выдать любой свободный адрес» — разные вещи. В режиме hot standby активный сервер обслуживает клиентов, а партнёр в роли standby получает отдельную долю свободного IPv4-пула для новых аренд. Значение ReservePercent по умолчанию равно 5. Активные аренды и состояние привязок реплицируются между партнёрами, поэтому резервный сервер знает прежний адрес клиента и при потере связи может временно продлить его на период MCLT. Для продления он не обязан расходовать небольшой резерв новых адресов.

Отсюда и обманчивая картина. Компьютер с действующей восьмисуточной арендой обращается к живому партнёру, сохраняет прежний адрес и продолжает работу. Устройство, которому требуется новая аренда, зависит от адресов, выделенных standby-серверу. Если они закончились, новых выдач не будет, хотя известные аренды продолжат продлеваться. Официальный обзор Microsoft отдельно оговаривает: истечения MCLT самого по себе недостаточно, пока сервер остаётся в Communications Interrupted. Весь доступный пул он в этом состоянии не использует.

Диагностику усложняет нормальный на вид мониторинг. Служба DHCPServer запущена, область видна, база аренд на месте, запросы доходят до сервера. Ограничение находится не в статусе службы и не в ACL области, а в состоянии failover-отношения и распределении свободных адресов между партнёрами. Поэтому первой проверкой должны быть свойства отношения на каждом сервере, а второй — фактическая статистика области. По одному зелёному индикатору службы здесь нельзя сделать вывод о доступности выдачи новым устройствам.

Есть ещё одна ловушка в терминологии. ReservePercent в актуальной справке PowerShell описан как процент свободных IPv4-адресов, тогда как старая страница интерфейса говорит о проценте диапазона области. Для расчёта ёмкости я не спорю с формулировками, а смотрю результат на конкретной области после синхронизации. Если диапазон почти заполнен, 25 % от оставшегося свободного пула могут оказаться меньшим числом, чем ожидает администратор, который умножил процент на полный диапазон.

Проверять нужно оба конца. Объект, который возвращает Get-DhcpServerv4Failover, содержит State того DHCP-сервера, к которому выполнен запрос. Это не универсальное поле PartnerState, из которого можно надёжно прочитать состояние второго узла. В консоли отображаются сведения об обеих сторонах, а в автоматизации я опрашиваю DC01 и DC02 отдельно и сопоставляю результат. Так видно не только потерю связи, но и асимметричную картину после перезапуска или восстановления канала.

• Старые машины сохраняют адреса, а устройства без действующей аренды получают APIPA из 169.254.0.0/16.
• В hot standby значение ReservePercent по умолчанию равно 5 и предназначено для новых аренд на standby-сервере.
• Продление известной аренды возможно временно на срок MCLT и не означает, что сервер получил весь пул.
• Communications Interrupted не даёт standby-серверу права использовать адреса партнёра.
• State нужно проверять на каждом DHCP-сервере, а не судить о failover по состоянию службы.

Состояния failover и правило Partner Down плюс MCLT

Состояний у failover больше трёх, но аварийная логика начинается с Normal, CommunicationInterrupted и PartnerDown — именно так значения обычно выглядят в выводе PowerShell, а в документации их пишут как NORMAL, COMMUNICATION INTERRUPTED и PARTNER DOWN. В Normal партнёры связаны и работают по выбранному режиму. В Communications Interrupted сервер знает только, что обмен с партнёром прекратился. Он не может отличить выключенный узел от живого узла за оборванным каналом, поэтому действует консервативно и сохраняет возможность безопасной реинтеграции.

В Partner Down сервер исходит из того, что партнёр не обслуживает клиентов, и отвечает на клиентские запросы. Но право использовать весь диапазон появляется не мгновенно: после перехода в Partner Down нужно выдержать MCLT. Старая официальная страница DHCP Failover Settings формулирует это однозначно: hot standby принимает весь диапазон только после перехода в Partner Down и по прошествии MCLT с момента этого перехода. Практическая формула для дежурного инженера поэтому проста: полный пул равен Partner Down плюс выдержанный MCLT.

MCLT, Maximum Client Lead Time, — не обычный срок аренды области. Это максимальное время, на которое один сервер может вывести срок аренды вперёд относительно информации, известной партнёру. Microsoft также использует MCLT как период временной аренды при аварийном продлении и как защитную выдержку в Partner Down перед использованием всего диапазона. Значение по умолчанию — один час; нулевое значение не допускается. Именно эта выдержка не позволяет вернувшемуся серверу сразу выдать адрес, который другой узел ещё считает занятым.

Автоматический переход из Communications Interrupted по умолчанию выключен. Если включить AutoStateTransition, сервер ждёт StateSwitchInterval и затем переходит в Partner Down. Для интервала в старом интерфейсе указано значение по умолчанию 60 минут, но в выводе отношения с выключенным автопереходом поле может быть пустым. У PowerShell есть дополнительная тонкость: если передать StateSwitchInterval, AutoStateTransition автоматически становится True. Я всё равно задаю оба параметра явно, чтобы намерение читалось без обращения к справке.

При восстановлении появляются Recover, RecoverWait и RecoverDone. В Recover узел догоняет базу привязок; в Recover Wait он уже получил обновления, но ждёт MCLT и не отвечает клиентам. Recover Done нужен для согласованного возвращения сторон в Normal и отвечает только на запросы продления и повторного связывания. Potential Conflict опаснее: он означает, что автоматическая реинтеграция не гарантирована и возможна проверка конфликтующих выдач; сервер в этом состоянии входящие DHCP-запросы не обрабатывает.

Здесь важно не смешивать два таймера. StateSwitchInterval отвечает только за то, сколько сервер проведёт в Communications Interrupted перед автоматическим объявлением партнёра недоступным. MCLT отсчитывает защитное окно, связанное с арендой и переходом к полному пулу. Если поставить StateSwitchInterval 60 минут и MCLT 15 минут, автоматический доступ ко всему диапазону при устойчивом отказе наступит не через 15, а примерно через 75 минут после обнаружения потери связи. При ручном Partner Down первая часть ожидания исчезает, вторая остаётся.

• NORMAL — штатная работа по режиму отношения.
• COMMUNICATION INTERRUPTED — связи нет, но партнёр не признан выключенным; весь пул недоступен.
• PARTNER DOWN — партнёр считается неработающим; весь пул открывается после MCLT.
• RECOVER и RECOVER WAIT — вернувшийся сервер обновляет базу и проходит защитную выдержку.
• POTENTIAL CONFLICT — возможен конфликт привязок, клиентские DHCP-запросы не обрабатываются.

Разбор практики: интернет-магазин «Домовой», 35 сотрудников и склад

Интернет-магазин «Домовой», 35 сотрудников и склад, использует два контроллера домена на Windows Server 2025: DC01 и DC02. Оба стоят в одной серверной, на обоих установлена роль DHCP. Одно failover-отношение работает в hot standby, DC01 назначен Active. В него входят офисная область 192.168.10.0/24 с диапазоном 192.168.10.50–192.168.10.240 и арендой 8 суток, а также складская область 192.168.20.0/24 с диапазоном 192.168.20.30–192.168.20.250. Во втором диапазоне 221 адрес, срок аренды — 8 часов; там работают Wi-Fi, терминалы сбора данных и телефоны кладовщиков.

До аварии использовались исходные параметры: ReservePercent 5, MaxClientLeadTime 01:00:00 и AutoStateTransition False. В субботу в 23:10 у DC01 отказал блок питания. Офис был пуст, поэтому событие заметили не сразу. DC02 перешёл в Communications Interrupted и продлевал известные аренды тем устройствам, которые продолжали обращаться. Автоматического Partner Down не случилось, потому что соответствующая настройка была выключена.

В понедельник в 08:00 склад включил 23 терминала, чьи восьмичасовые аренды давно закончились. Им потребовалась новая выдача. По фактическому распределению в консоли за standby-сервером было 11 свободных адресов. Первые 11 терминалов получили конфигурацию, оставшиеся 12 и подключавшиеся следом телефоны — нет. В 08:12 пришла заявка «терминал не видит сеть». Офис в ту же минуту выглядел здоровым: компьютеры с восьмисуточной арендой сохраняли прежние адреса и не создавали массового спроса на новые выдачи.

К диагностике мы приступили в 08:40. Сначала проверили не DHCP, а судьбу партнёра: сетевую доступность, TCP 647, состояние питания через iDRAC и консоль операционной системы. iDRAC подтвердил, что DC01 обесточен, то есть это был отказ узла, а не разрыв между двумя живыми серверами. В 09:02 на DC02 отношение перевели в Partner Down. Полный пул стал доступен в 10:02 — через настроенный час MCLT. Шесть критичных терминалов на этот час пришлось временно настроить вручную с адресами, заранее исключёнными из динамического диапазона. Общий простой склада приблизился к 1 часу 50 минут.

После разбора для интернет-магазина «Домовой», 35 сотрудников и склад, MCLT сократили до 15 минут, ReservePercent увеличили до 25, а автоматический переход включили с StateSwitchInterval 60 минут. На полностью свободном диапазоне из 221 адреса четверть — около 55 адресов, но рабочее число мы проверили в консоли после применения настроек, потому что командлет определяет процент от свободного пула. Срок аренды складской области подняли с 8 часов до 4 суток, чтобы перерыв на выходные не превращал включение всех терминалов в одновременный спрос на новые аренды.

В марте сценарий повторили планово при отключении DC01 на замену дисков. Перед отключением зафиксировали Normal на обоих узлах, число свободных адресов и время последней репликации. После отключения включили новые тестовые устройства в офисном и складском VLAN, а не ограничились проверкой старого компьютера. Резерва хватило, пользователи склада простоя не заметили, ждать полного открытия пула не пришлось. Этот тест оказался важнее красивого скриншота мастера: он проверил и отношение, и relay, и реальную ёмкость резерва.

• Было: ReservePercent 5, MCLT 1 час, AutoStateTransition False, аренда склада 8 часов.
• Стало: ReservePercent 25, MCLT 15 минут, AutoStateTransition True, StateSwitchInterval 60 минут, аренда склада 4 суток.
• В аварии 23 терминалам потребовалась новая выдача; фактический резерв составлял 11 адресов.
• Простой при аварии — около 1 часа 50 минут; при следующем плановом отключении — 0.
• Короткая аренда увеличивала пиковый спрос после выходных и делала малый резерв заметнее.

Как я подбираю MCLT, резерв и автоматический переход

Начинаю с бизнес-сценария, а не с любимого универсального значения. MCLT по умолчанию равен одному часу, но это исходная настройка продукта, а не обещание восстановления за час. Для двух серверов в одной серверной я обычно рассматриваю 15 минут: после ручного или автоматического перехода в Partner Down это и будет защитная выдержка до полного пула. Для географически разнесённых площадок оставляю больший запас, потому что там отказ канала вероятнее отказа сервера, а ошибочный Partner Down опаснее дополнительного ожидания.

Слишком короткий MCLT тоже имеет цену. В аварийном режиме известному клиенту выдаётся временное продление на MCLT; при обычных DHCP-таймерах попытка продления часто начинается примерно в середине аренды. Если поставить несколько минут, серверы и клиенты будут чаще обмениваться сообщениями, а при динамической регистрации имён вырастет и активность DNS. Поэтому 15 минут в этом кейсе — инженерный выбор для конкретной небольшой сети, а не рекомендация Microsoft и не универсальный минимум.

ReservePercent считаю в устройствах. Беру число клиентов, которые способны впервые появиться или вернуться без действующей аренды в окно аварии: смена склада, гостевые ноутбуки, телефоны, новые виртуальные машины, терминалы после выходных. Затем добавляю разумный запас и проверяю, сколько адресов реально оказалось у standby. Значение 20–30 % бывает удобным в свободной области, но бессмысленно в почти заполненной: процент от малого остатка не спасает от исчерпания. Если свободных адресов мало, сначала расширяю или очищаю пул.

AutoStateTransition выбираю по топологии. Когда оба сервера и путь между ними находятся в одной контролируемой серверной, устойчивый обрыв failover-соединения с большей вероятностью означает отказ узла или локальной сети. Тогда автоматический переход с StateSwitchInterval 60 минут может быть оправдан. Когда партнёры разделены WAN или VPN, я часто оставляю автоматику выключенной: при сетевом разделении оба узла могут остаться живы, а преждевременный Partner Down повышает риск конфликтующей выдачи.

Интервал автоперехода должен переживать обычное обслуживание: перезагрузку после обновлений, запуск служб и краткую нестабильность канала. Мои 60 минут — осознанная настройка для этой площадки; Microsoft не требует именно такого значения для всех сетей. Перед изменением я записываю исходные свойства, согласую допустимое время деградации и отдельно считаю сумму StateSwitchInterval плюс MCLT. Иначе руководство услышит «MCLT 15 минут» и ошибочно решит, что без вмешательства полный пул откроется через четверть часа после отказа.

Ниже две проверенные команды. TimeSpan для 15 минут записан как 00:15:00, для часа — 01:00:00. В Add-DhcpServerv4Failover значение ServerRole Active относится к локальному серверу DC01, поэтому партнёр DC02 становится standby. ScopeId принимает массив IPv4-адресов. Секрет считывается интерактивно как строка и не хранится в тексте статьи или истории команды в открытом виде.

# Изменение существующего отношения hot standby
Set-DhcpServerv4Failover -ComputerName 'dc01.corp.domovoy.local' `
  -Name 'DC01-DC02-Failover' `
  -ReservePercent 25 `
  -MaxClientLeadTime 00:15:00 `
  -AutoStateTransition $true `
  -StateSwitchInterval 01:00:00 `
  -PassThru

# Создание отношения: локальный DC01 — Active, партнёр DC02 — Standby
$sharedSecret = Read-Host 'Введите общий секрет failover'
Add-DhcpServerv4Failover -ComputerName 'dc01.corp.domovoy.local' `
  -Name 'DC01-DC02-Failover' `
  -PartnerServer 'dc02.corp.domovoy.local' `
  -ScopeId 192.168.10.0,192.168.20.0 `
  -ServerRole Active `
  -ReservePercent 25 `
  -MaxClientLeadTime 00:15:00 `
  -AutoStateTransition $true `
  -StateSwitchInterval 01:00:00 `
  -SharedSecret $sharedSecret `
  -Force -PassThru
Remove-Variable sharedSecret

• MCLT: выбирать по допустимому окну риска и проверять вместе со сроком аренды области.
• ReservePercent: переводить в фактическое число свободных адресов на standby.
• AutoStateTransition: включать только с учётом вероятности сетевого разделения.
• StateSwitchInterval: должен переживать штатную перезагрузку и краткий обрыв связи.
• Итоговое автоматическое ожидание до полного пула: StateSwitchInterval плюс MCLT.

Рунбук: как безопасно перевести резерв в Partner Down

Шаг первый — подтвердить, что партнёр действительно не обслуживает клиентов. Переводить отношение в Partner Down только из-за неудачного ping нельзя: ICMP мог быть закрыт, маршрут мог исчезнуть, а второй DHCP — остаться живым рядом со своими клиентами. Я использую независимые признаки: TCP 647 и соседство на доступном сегменте, консоль гипервизора или iLO/iDRAC, состояние питания, сведения системы мониторинга и, если управление доступно, состояние службы DHCPServer на партнёре. Для удалённых площадок дополнительно проверяю, не разделилась ли сеть на две рабочие половины.

Шаг второй — снять факты до изменения: State отношения на обоих серверах, текущее время, параметры MCLT и StateSwitchInterval, статистику проблемной области. Командлет Get-DhcpServerv4Failover возвращает состояние запрошенного сервера, поэтому DC01 и DC02 опрашиваются отдельно. Такой снимок помогает понять последовательность событий и не потерять её после восстановления связи. Журнал событий находится по пути Applications and Services Logs\Microsoft\Windows\DHCP-Server; для переходов состояний полезен канал Admin.

Шаг третий — на живом сервере вызвать Set-DhcpServerv4Failover с ключом -PartnerDown. Отдельного командлета смены состояния нет. Официальная справка определяет этот ключ узко: он меняет состояние службы DHCP с Communication Interrupted на Partner Down. После команды начинается защитное ожидание MCLT; повторный запуск, перезапуск службы или хаотичная правка области не сокращают таймер и только усложняют разбор.

Шаг четвёртый — после MCLT проверить не только статус, но и результат глазами нового клиента. Статистика области показывает свободные и используемые адреса, однако она не доказывает прохождение DHCPDISCOVER через relay и обратный путь DHCPOFFER. Поэтому я подключаю заранее подготовленное тестовое устройство в проблемном VLAN, фиксирую выданный адрес и сверяю новую аренду на живом сервере. Если адреса не выдаются после полного окна, возвращаюсь к relay, VLAN, фильтрам и журналам, а не объявляю MCLT неисправным.

Шаг пятый — спокойно вернуть основной узел. После запуска он может пройти Recover, RecoverWait и RecoverDone, прежде чем оба конца покажут Normal. В Recover Wait сервер не отвечает клиентам, и это предусмотренное поведение. Не существует обязательной «обратной кнопки», которую нужно немедленно нажать после включения: стороны обмениваются состояниями и реинтегрируются. Если процесс застрял или возникает Potential Conflict, я сначала сохраняю события и проверяю связь, а не удаляю отношение.

Настройки области требуют отдельной дисциплины. Изменения failover-области не реплицируются автоматически после каждой правки. Invoke-DhcpServerv4FailoverReplication копирует конфигурацию от сервера, на котором инициирована операция, к партнёру и перезаписывает его соответствующие настройки. Поэтому до команды нужно назначить эталонную сторону. Если версии Windows Server различаются, Microsoft рекомендует изменять настройки и запускать репликацию с более нового сервера.

# 1. Снимаем состояние каждого конца отдельно
$servers = 'dc01.corp.domovoy.local','dc02.corp.domovoy.local'
foreach ($server in $servers) {
  Get-DhcpServerv4Failover -ComputerName $server -Name 'DC01-DC02-Failover' |
    Select-Object @{Name='Server';Expression={$server}},Name,Mode,State,PartnerServer,`
                  ReservePercent,MaxClientLeadTime,AutoStateTransition,`
                  StateSwitchInterval,ScopeId
}

# 2. Проверяем failover-порт и соседство с DC01 со стороны DC02
Test-NetConnection 'dc01.corp.domovoy.local' -Port 647
Get-NetNeighbor -IPAddress 192.168.10.11 -ErrorAction SilentlyContinue

# 3. Только после подтверждения отказа переводим DC02 в Partner Down
Set-DhcpServerv4Failover -ComputerName 'dc02.corp.domovoy.local' `
  -Name 'DC01-DC02-Failover' -PartnerDown -Force

# 4. После MCLT проверяем статистику складской области
Get-DhcpServerv4ScopeStatistics -ComputerName 'dc02.corp.domovoy.local' `
  -ScopeId 192.168.20.0

# 5. После восстановления реплицируем настройки с выбранного эталона DC01
Invoke-DhcpServerv4FailoverReplication `
  -ComputerName 'dc01.corp.domovoy.local' `
  -Name 'DC01-DC02-Failover' -Force

• Не объявлять Partner Down, пока отказ партнёра не подтверждён вне самого failover-канала.
• До изменения сохранить State обоих серверов, параметры отношения и статистику области.
• После Partner Down выдержать MCLT и проверить выдачу новым клиентом в нужном VLAN.
• Не перезапускать службу ради ускорения Recover Wait: сервер в этом состоянии ожидаемо молчит.
• Репликацию запускать с сервера, чьи настройки области выбраны эталонными.

Сеть, время, relay и DNS: тихие причины отказа

DHCP failover поддерживает постоянное TCP-соединение партнёров и слушает TCP 647. При установке роли DHCP Windows добавляет входящее и исходящее правила Microsoft-Windows-DHCP-Failover-TCP-In и Microsoft-Windows-DHCP-Failover-TCP-Out. Новая групповая политика брандмауэра, микросегментация или ACL между VLAN способны нарушить этот обмен, не остановив службу DHCPServer. Результат — Communications Interrupted на живых узлах. Проверять TCP 647 нужно в обоих направлениях, потому что односторонняя проверка не доказывает симметричную связность.

Время — часть протокола, а не косметика журнала. Мастер создания отношения сравнивает часы серверов и останавливается с критической ошибкой, если разница превышает одну минуту. Каждое сообщение failover несёт отметку UTC; при разнице более одной минуты принимающая сторона регистрирует критическое событие рассинхронизации. На виртуальных контроллерах я проверяю всю цепочку W32Time и настройки синхронизации гостя с гипервизором, чтобы два механизма не тянули часы в разные стороны.

DHCP relay обязан доставлять клиентский трафик обоим партнёрам, если серверы находятся не в клиентской подсети. Один ip helper-address, направленный только на DC01, делает исправный DC02 невидимым для этого VLAN. Microsoft прямо указывает, что клиент должен иметь возможность общаться с обоими failover-серверами напрямую или через relay. Если оба сервера размещены в одной удалённой от клиентов подсети, обычно на клиентском интерфейсе указывают два адреса relay; допустимость широковещательного адреса подсети зависит от топологии и возможностей сетевого оборудования.

Дублирующиеся relay-пакеты — отдельная тема. Официальный обзор Microsoft предупреждает, что при нескольких relay-агентах один и тот же клиентский запрос может прийти на сервер несколько раз и породить события 20291 и 20292; Microsoft описывает такие события как не вызывающие фактической ошибки сами по себе. Поэтому я не делаю вывод о поломке failover только по числу повторов. Сначала сопоставляю идентификатор транзакции, интерфейс relay и реальный результат выдачи клиенту.

Для кластера в отношении указывают имя или IP-адрес DHCP-кластера, а не отдельного узла. Иначе после перемещения кластерной роли партнёр потеряет связь и перейдёт в Communications Interrupted. Если используется общий секрет, Microsoft отдельно требует вручную распространить его на все узлы кластера. Эта мелочь часто всплывает только после первого планового failover кластера, поэтому её стоит включить в приёмочные испытания.

При динамических обновлениях DNS оба DHCP-партнёра должны работать с одинаковыми учётными данными. Первый сервер создаёт DNS-имя клиента и становится владельцем записи; второй с другими credentials не сможет обновить её после переключения. Это не мешает самой выдаче IPv4-адреса, но оставляет устаревшие A- и PTR-записи и выглядит как сетевой сбой прикладного уровня. Проверку DNS я поэтому выполняю после тестовой аренды вместе с проверкой прямой и обратной записи.

Failover Microsoft применяется только к DHCPv4-областям. DHCPv6-область добавить в такое отношение нельзя. Для stateless DHCPv6 Microsoft предлагает два сервера с одинаковыми параметрами опций, поскольку сервер не ведёт состояние адресных аренд; для stateful DHCPv6 официальный обзор называет split scope допустимым вариантом высокой доступности. Эти схемы нужно проектировать отдельно, не считая IPv4 failover автоматическим резервом для IPv6.

! Оба DHCP-сервера указаны на клиентском SVI склада
interface Vlan20
 description SKLAD-WIFI
 ip address 192.168.20.1 255.255.255.0
 ip helper-address 192.168.10.11
 ip helper-address 192.168.10.12

# Штатные правила Windows Firewall для DHCP failover
Get-NetFirewallRule -Name 'Microsoft-Windows-DHCP-Failover-*' |
  Select-Object Name,Direction,Enabled,Action

# Проверка TCP 647 выполняется с каждого партнёра к другому
Test-NetConnection 'dc01.corp.domovoy.local' -Port 647
Test-NetConnection 'dc02.corp.domovoy.local' -Port 647

# Три измерения смещения времени относительно DC01
w32tm /stripchart /computer:dc01.corp.domovoy.local /samples:3 /dataonly

• TCP 647 должен проходить между партнёрами в обоих направлениях.
• Штатные правила: Microsoft-Windows-DHCP-Failover-TCP-In и Microsoft-Windows-DHCP-Failover-TCP-Out.
• Разница времени более одной минуты останавливает мастер настройки и вызывает критическое событие протокола.
• Relay должен обеспечивать связь клиентов с обоими DHCP-партнёрами.
• Для DHCP-кластера указывают имя или IP кластера, а не отдельного узла.
• Оба DHCP-сервера используют одинаковые учётные данные динамического обновления DNS.
• DHCPv4 failover не резервирует DHCPv6-области.

Что мониторить вместо одной службы DHCPServer

Проверка «служба DHCPServer запущена» необходима, но недостаточна. В аварии интернет-магазина «Домовой», 35 сотрудников и склад, она оставалась зелёной все выходные. Основная метрика — State failover-отношения на каждом сервере. Я опрашиваю оба узла и поднимаю предупреждение, если хотя бы один вернул значение, отличное от Normal. Одновременно собираю MaxClientLeadTime, AutoStateTransition и StateSwitchInterval: эти параметры нужны дежурному, чтобы сразу оценить ожидаемое окно восстановления.

Вторая группа метрик — ёмкость каждой области: PercentageInUse и фактические счётчики свободных адресов. Порог 20 % для предупреждения и 10 % для аварии — мой эксплуатационный выбор, а не встроенный стандарт Windows Server. Для небольшой области его полезно дополнить абсолютным минимумом: десять свободных адресов могут составлять приличный процент маленького диапазона, но не выдержать утреннюю смену. Отдельно сверяю резерв standby после изменения ReservePercent.

Третья проверка ищет области, не включённые ни в одно failover-отношение. Новую область легко создать на основном сервере, активировать, прописать в relay и забыть добавить к партнёру. Microsoft поддерживает командлет Add-DhcpServerv4FailoverScope именно для присоединения существующих областей к отношению; автоматического включения каждой будущей области нет. Поэтому список исключений должен быть явным: лабораторные области допускаются, случайно забытые — создают заявку.

События дополняют опрос. Microsoft документирует каналы Admin и Operational по пути Applications and Services Logs\Microsoft\Windows\DHCP-Server. В Admin видны переходы состояния локального сервера и партнёра, потеря и восстановление связи, а также рассинхронизация времени. Operational фиксирует создание и удаление отношений, добавление и удаление областей, изменение MCLT, резервного процента и интервала автоперехода. Эти события удобно отправлять в Zabbix, SIEM или централизованный Windows Event Collector.

Для Partner Down я ставлю отдельное напоминание, если состояние держится дольше 24 часов. Это не технический предел Microsoft, а защита от незавершённого ремонта: основной сервер уже подняли, но реинтеграция не прошла или никто не проверил оба конца. Алерт должен содержать имя отношения, сервер, время первого ненормального состояния, MCLT и список ScopeId. Сообщение «DHCP error» без этих данных заставляет дежурного начинать расследование с нуля.

Раз в квартал я провожу контролируемую проверку. Отключаю активный DHCP на согласованное окно 20 минут, включаю новое тестовое устройство в каждом важном VLAN и фиксирую, с какого сервера пришла аренда. Если MCLT равен 15 минутам, можно отдельно проверить ручной Partner Down в учебной среде; в рабочей сети такую команду выполняю только по рунбуку и с подтверждённым отключением партнёра. Учения проверяют отношение, relay, правила TCP 647, DNS-обновления и запас адресов одной процедурой.

Скрипт ниже печатает отдельную строку для каждого сервера и каждой области. Он использует документированные свойства State, ScopeId и PercentageInUse. Процент свободного места вычисляется как 100 минус PercentageInUse; для алерта стоит также забирать числовые поля статистики в вашей системе мониторинга, а не полагаться только на округлённую строку. Вторая часть показывает области локального DC01, которые не входят ни в одно отношение.

$relationship = 'DC01-DC02-Failover'
$servers = 'dc01.corp.domovoy.local','dc02.corp.domovoy.local'

foreach ($server in $servers) {
  $fo = Get-DhcpServerv4Failover -ComputerName $server -Name $relationship
  foreach ($scopeId in $fo.ScopeId) {
    $stats = Get-DhcpServerv4ScopeStatistics `
      -ComputerName $server -ScopeId $scopeId
    $freePercent = [math]::Round(100 - $stats.PercentageInUse)
    '{0} {1} {2} {3} {4}%' -f `
      $server,$fo.Name,$fo.State,$scopeId,$freePercent
  }
}

# Области DC01, которые не состоят ни в одном failover-отношении
$inFailover = @(
  Get-DhcpServerv4Failover -ComputerName 'dc01.corp.domovoy.local' |
    ForEach-Object { $_.ScopeId }
)
Get-DhcpServerv4Scope -ComputerName 'dc01.corp.domovoy.local' |
  Where-Object { $_.ScopeId -notin $inFailover }

• State каждого конца отношения: предупреждение на любое значение, кроме Normal.
• Свободные адреса: процент и абсолютное количество по каждой области.
• Список областей, не входящих ни в одно failover-отношение.
• События Admin и Operational из журнала Microsoft\Windows\DHCP-Server.
• Эксплуатационное напоминание, если Partner Down сохраняется более 24 часов.
• Квартальная проверка новым клиентом в каждом критичном VLAN.

Как принять настройку после изменений

После изменения параметров я не закрываю задачу по успешному выводу Set-DhcpServerv4Failover. Сначала повторно читаю отношение с DC01 и DC02 и проверяю одинаковые Mode, ReservePercent, MaxClientLeadTime, AutoStateTransition, StateSwitchInterval и набор ScopeId. Затем запускаю репликацию конфигурации с выбранного эталона и сохраняю результат. Если одна сторона работает на более новой версии Windows Server, именно с неё инициирую изменение и репликацию, как рекомендует Microsoft.

Далее проверяю путь клиента. Для каждого VLAN нужен либо прямой доступ к обоим серверам, либо корректный relay. Тестовый клиент освобождает старую конфигурацию только в согласованном окне, получает новую аренду, разрешает имя шлюза и внутреннего ресурса, а в DHCP и DNS появляются ожидаемые записи. Такой сценарий выявляет ошибки, которые не видны в свойствах отношения: забытый helper, ACL на UDP 67/68, неверные опции области или разные DNS credentials.

Отдельно моделирую исчерпание именно резервной доли в лаборатории или на временной тестовой области. Цель — увидеть границу: известные клиенты продлеваются, новые после исчерпания резервных адресов не получают аренду, а после подтверждённого Partner Down и MCLT становится доступен остальной пул. В продуктивной области искусственно заполнять адреса нельзя; достаточно рассчитать пик, проверить назначенное standby число в консоли и использовать контролируемую тестовую область с теми же параметрами.

Документация должна отвечать на четыре вопроса без звонка автору: какой сервер Active для каждого отношения, сколько новых клиентов выдерживает standby, кто имеет право объявить Partner Down и сколько займут StateSwitchInterval плюс MCLT. Туда же записываю адреса управления iLO/iDRAC, контакты ответственного за сеть и перечень критичных VLAN. Секрет failover в рунбук не помещаю: он хранится в принятом у компании хранилище секретов.

Наконец, фиксирую критерий успеха. Для интернет-магазина «Домовой», 35 сотрудников и склад, это одновременное включение 23 терминалов после выходных при недоступном DC01 без пользовательского простоя, сохранение DNS-регистрации и возврат обоих серверов в Normal после восстановления. Конкретный критерий полезнее фразы «резервирование настроено»: через квартал другой инженер сможет повторить тест и сравнить результат.

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

• Свойства отношения совпадают при отдельном опросе DC01 и DC02.
• Набор ScopeId полон, а конфигурация реплицирована с назначенного эталонного сервера.
• Новый клиент получает адрес через relay в каждом критичном VLAN.
• Фактическая ёмкость standby покрывает рассчитанный пик новых клиентов.
• Рунбук содержит роли серверов, таймеры, адреса внешнего управления и ответственных.
• После возврата партнёра оба конца достигают состояния Normal.

Частые вопросы