🖥️ Windows Server📅 09.04.2026⏱️ 12 мин чтения✍️ АйТи Фреш👁 —
Отказоустойчивый DHCP в Windows Server: настройка failover
Зачем нужен DHCP Failover
DHCP — это та служба, падение которой мгновенно парализует всю сеть. Клиенты не получают адреса, всё встаёт. До Windows Server 2012 у администраторов не было нормального встроенного решения: кто-то делил область в пропорции 80/20 между двумя серверами, кто-то городил Windows Failover Clustering. Оба варианта — костыли.
DHCP Failover — это встроенный механизм, при котором два DHCP-сервера обслуживают одну и ту же область с полной синхронизацией аренд. Никакого общего хранилища, никакого кластера Windows — работает на уровне приложения. Из коробки доступно два режима:
Hot Standby — один сервер тянет всё на себе, второй молча ждёт своего часа и подхватывает нагрузку, как только основной падает
Load Balance — оба сервера работают одновременно, деля клиентов между собой в настраиваемой пропорции
Чем это лучше старого подхода 80/20? База аренд синхронизируется полностью, переключение происходит автоматически, конфликты IP-адресов исключены, и каждый сервер имеет доступ ко всему пулу адресов — всем 100%, а не к урезанной половине.
Требования и ограничения
Прежде чем браться за настройку DHCP Failover, стоит знать об ограничениях — иначе потратите время впустую:
Failover работает только для IPv4-областей — для IPv6 это не применимо, там используется stateless DHCPv6
В отношении failover для одной области участвуют максимум два сервера — третий не добавить
Оба сервера должны работать под управлением Windows Server 2012 или новее
Время на серверах обязано быть синхронизировано — расхождение больше 1 минуты сломает репликацию
Между серверами должен быть открыт TCP-порт 647 — именно через него идёт репликация
Синхронизацию времени проверяйте командой:
w32tm /query /status
w32tm /query /peers
Если серверы в домене Active Directory — расслабьтесь, время синхронизируется автоматически через PDC Emulator. Рабочая группа? Тогда придётся настроить NTP руками.
Подготовка инфраструктуры
До того как настраивать failover, убедитесь: роль DHCP установлена и авторизована на обоих серверах. Если второй сервер только что введён в строй, роль ставится через PowerShell:
# Установка роли DHCP на втором сервере
Install-WindowsFeature DHCP -IncludeManagementTools
# Авторизация DHCP-сервера в Active Directory
Add-DhcpServerInDC -DnsName dhcp02.corp.local -IPAddress 10.0.0.12
# Проверка авторизации
Get-DhcpServerInDC
На первом сервере должна быть готова область со всем необходимым: диапазон адресов, исключения, опции — DNS-серверы, шлюз, домен. На второй сервер это всё копировать не нужно. При настройке failover конфигурация области уедет на партнёра автоматически.
Настройка области на первом сервере
Если область на основном DHCP-сервере ещё не создана — создайте её:
Убедитесь, что область активна и клиенты уже получают адреса от первого сервера. Только после этого двигайтесь дальше.
Открытие портов в брандмауэре
DHCP Failover использует TCP-порт 647 для общения между партнёрами. Открываем его на обоих серверах:
# На обоих серверах
New-NetFirewallRule -DisplayName "DHCP Failover" `
-Direction Inbound `
-Protocol TCP `
-LocalPort 647 `
-Action Allow `
-Profile Domain
# Проверка доступности порта с первого сервера
Test-NetConnection -ComputerName dhcp02.corp.local -Port 647
И не забудьте про стандартные DHCP-порты — UDP 67 и 68 должны быть открыты на обоих серверах, иначе клиенты просто не достучатся.
Настройка DHCP Failover через PowerShell
PowerShell — это то, чем мы пользуемся в первую очередь при настройке failover. Особенно когда областей не одна и не две, а десятки. Всё можно автоматизировать и зафиксировать в скрипте — никаких кликов по GUI.
Режим Load Balance
Load Balance — режим для тех случаев, когда оба сервера постоянно доступны и нет смысла держать один в режиме ожидания. Оба работают, оба выдают адреса:
# Настройка failover в режиме Load Balance
Add-DhcpServerv4Failover -Name "DHCP-FO-Office" `
-PartnerServer dhcp02.corp.local `
-ScopeId 10.0.1.0 `
-SharedSecret "K0mpl3xP@ssw0rd!" `
-LoadBalancePercent 50 `
-MaxClientLeadTime 01:00:00 `
-AutoStateTransition $true `
-StateSwitchInterval 00:30:00
# Проверка состояния failover
Get-DhcpServerv4Failover -Name "DHCP-FO-Office"
# Проверка на обоих серверах
Get-DhcpServerv4Failover -ComputerName dhcp01.corp.local
Get-DhcpServerv4Failover -ComputerName dhcp02.corp.local
LoadBalancePercent — это доля запросов, которую берёт на себя основной сервер. При значении 50 нагрузка делится поровну. MaxClientLeadTime задаёт, насколько сервер вправе продлить аренду сверх обычного срока, если партнёр недоступен. А StateSwitchInterval — это пауза перед тем, как сервер решит, что партнёр окончательно упал, и перейдёт в состояние Partner Down.
Режим Hot Standby
Hot Standby — выбор для сценариев с выделенным резервным сервером. Классический пример из нашей практики: основной DHCP в офисе или филиале, резервный — в ЦОД:
# Настройка failover в режиме Hot Standby
Add-DhcpServerv4Failover -Name "DHCP-FO-Branch" `
-PartnerServer dhcp02.corp.local `
-ScopeId 10.0.2.0 `
-SharedSecret "K0mpl3xP@ssw0rd!" `
-ServerRole Active `
-ReservePercent 5 `
-MaxClientLeadTime 01:00:00 `
-AutoStateTransition $true `
-StateSwitchInterval 00:30:00
# На резервном сервере роль будет Standby автоматически
Get-DhcpServerv4Failover -ComputerName dhcp02.corp.local
ReservePercent — доля пула, зарезервированная за standby-сервером. При значении 5 резервный сервер в нормальном режиме выдаёт не больше 5% адресов. Но как только партнёр падает и сервер переходит в Partner Down — в его распоряжении оказывается весь пул целиком.
Добавление нескольких областей в failover
Если нужно добавить несколько областей в уже существующее отношение failover — используйте Add-DhcpServerv4FailoverScope:
# Добавление дополнительных областей
Add-DhcpServerv4FailoverScope -Name "DHCP-FO-Office" `
-ScopeId 10.0.3.0,10.0.4.0,10.0.5.0
# Просмотр всех областей в failover
Get-DhcpServerv4Failover -Name "DHCP-FO-Office" | Select-Object -ExpandProperty ScopeId
# Принудительная репликация после добавления
Invoke-DhcpServerv4FailoverReplication -Name "DHCP-FO-Office"
Все настройки области — опции, исключения, резервирования — реплицируются на партнёра сами. Но есть один нюанс, на котором мы пару раз обжигались: серверные опции (Server Options) не реплицируются. Их придётся настраивать на каждом сервере отдельно.
Настройка Failover через графический интерфейс
Настройка через графическую консоль DHCP
Любите мышку больше терминала? Failover настраивается и через графическую консоль DHCP — dhcpmgmt.msc. Всё наглядно, но когда областей много, GUI превращается в пытку. PowerShell всё-таки удобнее.
Открываем консоль DHCP на основном сервере, раскрываем узел IPv4, правой кнопкой по нужной области — Configure Failover. Запустится мастер. Он последовательно проведёт через все этапы настройки:
Выбор областей для включения в failover — можно сразу несколько
Указание сервера-партнёра по имени или IP-адресу
Имя отношения failover (Relationship Name) — придумайте что-то понятное, потом скажете себе спасибо
Выбор режима: Load Balance или Hot Standby
Для Load Balance — процентное соотношение нагрузки между серверами
Для Hot Standby — роль текущего сервера и процент адресов, резервируемых для него
Shared Secret для аутентификации между серверами — не оставляйте пустым
Параметры MCLT и State Switchover Interval — от них зависит, как быстро сработает переключение
Как только мастер завершит работу, конфигурация области уедет на партнёра автоматически. Открываете консоль DHCP на втором сервере — области должны появиться с пометкой «Failover». Если не появились, значит что-то пошло не так ещё на этапе настройки.
Рекомендации по параметрам
Для продакшен-среды мы используем такие параметры:
Параметр
Рекомендация
Обоснование
Maximum Client Lead Time
1 час
Баланс между быстрым переключением и стабильностью
State Switchover Interval
30-60 минут
Достаточно для кратковременных сбоев сети
Auto State Transition
Включено
Автоматическое переключение без вмешательства администратора
Load Balance %
50/50
Равномерная нагрузка при одинаковых серверах
Reserve % (Hot Standby)
5-10%
Минимальный пул для standby на время переключения
Shared Secret — это не место для «qwerty123». Делайте его сложным, уникальным для каждого отношения failover, и обязательно кладите в защищённое хранилище паролей. Потеряете — будете пересоздавать failover вручную.
Мониторинг и управление состояниями
DHCP Failover живёт в нескольких состояниях. Знать их наизусть не обязательно, но когда что-то сломается в три ночи — вы скажете спасибо, что разобрались заранее:
Normal — всё хорошо: оба сервера работают, связь есть, репликация идёт
Communication Interrupted — серверы потеряли связь друг с другом и работают независимо. Клиенты адреса получают, но это уже тревожный звонок
Partner Down — вы или автоматика явно подтвердили, что партнёр недоступен. Оставшийся сервер берёт на себя весь пул
Recover — поднявшийся сервер синхронизирует базу аренд с партнёром
Recover Wait — сервер ждёт истечения MCLT, прежде чем вернуться в Normal. Не торопите этот процесс
# Мониторинг состояния failover
Get-DhcpServerv4Failover | Select-Object Name, State, Mode, `
PartnerServer, LoadBalancePercent
# Детальная статистика аренд
Get-DhcpServerv4ScopeStatistics -ScopeId 10.0.1.0 -Failover
# Просмотр событий DHCP в журнале
Get-WinEvent -LogName "Microsoft-Windows-DHCP-Server/Operational" `
-MaxEvents 50 | Where-Object { $_.Message -like "*failover*" }
Ручное переключение состояний
Если автоматическое переключение отключено или нужно ускорить процесс вручную:
# Перевод в состояние Partner Down (когда партнёр точно недоступен)
Set-DhcpServerv4Failover -Name "DHCP-FO-Office" `
-State PartnerDown
# Возврат в нормальное состояние после восстановления партнёра
# Сначала запустите репликацию
Invoke-DhcpServerv4FailoverReplication -Name "DHCP-FO-Office"
# Затем переведите в Normal
Set-DhcpServerv4Failover -Name "DHCP-FO-Office" `
-State Normal
Важно: переводить failover обратно в Normal до того, как партнёр реально восстановлен и репликация завершена — плохая идея. Результат предсказуемый: конфликты IP-адресов и звонки от пользователей.
Синхронизация и репликация
База аренд реплицируется в реальном времени — каждая выдача, продление или освобождение адреса сразу уходит на партнёра. А вот изменения конфигурации области — опции, исключения, резервирования — сами никуда не едут. Их нужно реплицировать явно:
# Принудительная репликация всех failover-отношений
Get-DhcpServerv4Failover | ForEach-Object {
Write-Host "Replicating $($_.Name)..."
Invoke-DhcpServerv4FailoverReplication -Name $_.Name
}
# Репликация конкретного отношения
Invoke-DhcpServerv4FailoverReplication -Name "DHCP-FO-Office"
# Репликация конкретной области
Invoke-DhcpServerv4FailoverReplication -ScopeId 10.0.1.0
Это, пожалуй, самая частая ошибка, которую мы видим у новых администраторов. Добавили резервирование, поменяли опции, подправили исключения — и забыли запустить репликацию. Второй сервер ничего об этом не знает и продолжает жить по-старому.
Автоматизация репликации
Чтобы не забывать про репликацию, создайте задачу в планировщике для периодической синхронизации конфигурации:
Процентов в 80 случаев виноват один из двух виновников — порт 647 заблокирован где-то по пути между серверами, или время на машинах разошлось больше чем на 60 секунд. Начинайте диагностику именно с этого.
Конфликты IP-адресов после восстановления
Один из серверов долго лежал, а после подъёма начались конфликты адресов? Вот порядок действий:
Мастер или командлет падает с ошибкой при создании отношения failover? Смотрите сюда:
# Проверка, что область не входит в другое отношение failover
Get-DhcpServerv4Failover | Select-Object -ExpandProperty ScopeId
# Удаление некорректного отношения и пересоздание
Remove-DhcpServerv4Failover -Name "DHCP-FO-Office" -Force
# На втором сервере удалите реплицированную область
Remove-DhcpServerv4Scope -ScopeId 10.0.1.0 -ComputerName dhcp02.corp.local -Force
# Пересоздайте failover
Add-DhcpServerv4Failover -Name "DHCP-FO-Office" `
-PartnerServer dhcp02.corp.local `
-ScopeId 10.0.1.0 `
-SharedSecret "NewP@ssw0rd!" `
-LoadBalancePercent 50
Лучшие практики и рекомендации
Несколько лет эксплуатации DHCP Failover в корпоративных сетях дали нам вот какой список практических правил:
Используйте Load Balance для одной площадки — оба сервера активны, нагрузка делится, переключение при сбое мгновенное
Используйте Hot Standby для распределённых площадок — локальный сервер тянет всю нагрузку, удалённый сидит в резерве и не гоняет трафик через WAN
Документируйте Shared Secret — без него перенастроить или восстановить failover не получится. Просто поверьте на слово
Мониторьте состояние — настройте оповещения на переход в Communication Interrupted, иначе узнаете о проблеме последним
Регулярно проверяйте репликацию — сравнивайте количество аренд на обоих серверах. Большое расхождение — повод разбираться
Планируйте обновления серверов — обновляйте по одному, и только убедившись, что первый вернулся в состояние Normal
# Скрипт мониторинга для Zabbix/PRTG
$failovers = Get-DhcpServerv4Failover
foreach ($fo in $failovers) {
if ($fo.State -ne "Normal") {
Write-Output "CRITICAL: DHCP Failover '$($fo.Name)' state: $($fo.State)"
exit 2
}
}
Write-Output "OK: All DHCP failover relationships in Normal state"
exit 0
И последнее — тестируйте переключение вживую, не дожидаясь реального инцидента. Остановите службу DHCP на одном сервере и посмотрите, продолжают ли клиенты получать адреса от второго. Делаем это раз в квартал. Пару раз именно так мы выловили проблемы, которые тихо жили в конфигурации месяцами.
Часто задаваемые вопросы
Да, домен не нужен. DHCP Failover аутентифицирует серверы через Shared Secret, а не через Kerberos — доменная структура здесь вообще ни при чём. Единственное условие: оба сервера должны быть авторизованы в своих доменах, либо в одном общем при наличии доверия. Если работаете в рабочих группах — авторизация не требуется вовсе.
Клиенты с действующей арендой вообще ничего не заметят — они продолжают работать как обычно. Продление аренды обработает тот сервер, который в этот момент доступен. Новые клиенты тоже не останутся без адреса. В режиме Load Balance переключение происходит мгновенно: оба сервера и так работают параллельно, так что никакой паузы нет. А вот в Hot Standby придётся немного подождать — standby-сервер подхватит клиентов только после того, как истечёт MCLT.
Нужно заменить один из серверов? Мы делали это не раз, схема отработанная. Сначала удаляете failover-отношение на старом сервере через Remove-DhcpServerv4Failover, потом разворачиваете роль DHCP на новой машине и создаёте failover-отношение уже с новым партнёром. Аренды реплицируются сами — вручную ничего перетаскивать не придётся. И не забудьте деавторизовать старый сервер командой Remove-DhcpServerInDC, иначе в Active Directory останется мусор.
Реплицируются — да, но не автоматически. Это важный нюанс, на котором несколько раз спотыкались даже опытные администраторы. Аренды синхронизируются в реальном времени, а вот резервирования — нет. Добавили резервирование на одном сервере? Сразу запускайте Invoke-DhcpServerv4FailoverReplication вручную, иначе на партнёре его не будет.
Да, с суперобластями всё работает — но есть нюанс. Failover настраивается не для суперобласти целиком, а для каждого scope внутри неё по отдельности. Суперобласть — это просто логическая группировка для удобства, на механизм failover она никак не влияет. На практике мы добавляем все области суперобласти в одно failover-отношение сразу — так и управлять проще, и не запутаешься потом.
Столкнулись с похожей задачей? Обращайтесь — решим
Если у вас происходит что-то из описанного в этой статье — или любая другая проблема с ИТ-инфраструктурой, — обращайтесь в любое время. Мои специалисты и я лично разберём ситуацию, найдём настоящую причину и доведём до решения.
Возьмёмся и за разовую задачу, и за постоянное обслуживание. Первичная консультация — бесплатно и без обязательств.
Каждую неделю мы выпускаем практические гайды для руководителей IT и системных администраторов. Это не просто теория! Здесь вы найдёте всё: безопасность, 1С, миграции, резервные копии и проверенные лайфхаки из наших реальных проектов.
Реквизиты оператора персональных данных
ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.
Оставить комментарий