Отказоустойчивый DHCP в Windows Server: настройка failover
Москва, Щёлковское шоссе, д. 92, корп. 7 · Пн–Пт 9:00–19:00 · +7 903 729-62-41

Отказоустойчивый DHCP в Windows Server: настройка failover

Отказоустойчивый 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-сервере ещё не создана — создайте её:

# Создание области
Add-DhcpServerv4Scope -Name "Office LAN" `
  -StartRange 10.0.1.100 `
  -EndRange 10.0.1.250 `
  -SubnetMask 255.255.255.0 `
  -LeaseDuration 8.00:00:00 `
  -State Active

# Добавление исключений (для серверов, принтеров)
Add-DhcpServerv4ExclusionRange -ScopeId 10.0.1.0 `
  -StartRange 10.0.1.100 -EndRange 10.0.1.110

# Настройка опций области
Set-DhcpServerv4OptionValue -ScopeId 10.0.1.0 `
  -Router 10.0.1.1 `
  -DnsServer 10.0.0.10,10.0.0.11 `
  -DnsDomain corp.local

# Проверка конфигурации
Get-DhcpServerv4Scope | Format-Table -AutoSize
Get-DhcpServerv4OptionValue -ScopeId 10.0.1.0

Убедитесь, что область активна и клиенты уже получают адреса от первого сервера. Только после этого двигайтесь дальше.

Открытие портов в брандмауэре

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) не реплицируются. Их придётся настраивать на каждом сервере отдельно.

Настройка через графическую консоль DHCP
Настройка Failover через графический интерфейс

Настройка через графическую консоль DHCP

Любите мышку больше терминала? Failover настраивается и через графическую консоль DHCP — dhcpmgmt.msc. Всё наглядно, но когда областей много, GUI превращается в пытку. PowerShell всё-таки удобнее.

Открываем консоль DHCP на основном сервере, раскрываем узел IPv4, правой кнопкой по нужной области — Configure Failover. Запустится мастер. Он последовательно проведёт через все этапы настройки:

  1. Выбор областей для включения в failover — можно сразу несколько
  2. Указание сервера-партнёра по имени или IP-адресу
  3. Имя отношения failover (Relationship Name) — придумайте что-то понятное, потом скажете себе спасибо
  4. Выбор режима: Load Balance или Hot Standby
  5. Для Load Balance — процентное соотношение нагрузки между серверами
  6. Для Hot Standby — роль текущего сервера и процент адресов, резервируемых для него
  7. Shared Secret для аутентификации между серверами — не оставляйте пустым
  8. Параметры MCLT и State Switchover Interval — от них зависит, как быстро сработает переключение

Как только мастер завершит работу, конфигурация области уедет на партнёра автоматически. Открываете консоль DHCP на втором сервере — области должны появиться с пометкой «Failover». Если не появились, значит что-то пошло не так ещё на этапе настройки.

Рекомендации по параметрам

Для продакшен-среды мы используем такие параметры:

ПараметрРекомендацияОбоснование
Maximum Client Lead Time1 часБаланс между быстрым переключением и стабильностью
State Switchover Interval30-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

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

Автоматизация репликации

Чтобы не забывать про репликацию, создайте задачу в планировщике для периодической синхронизации конфигурации:

# Скрипт для автоматической репликации (сохраните как C:\Scripts\dhcp-replicate.ps1)
$failovers = Get-DhcpServerv4Failover
foreach ($fo in $failovers) {
    try {
        Invoke-DhcpServerv4FailoverReplication -Name $fo.Name -Force
        Write-EventLog -LogName Application -Source "DHCP-Failover-Script" `
          -EventId 1000 -EntryType Information `
          -Message "Репликация $($fo.Name) выполнена успешно"
    } catch {
        Write-EventLog -LogName Application -Source "DHCP-Failover-Script" `
          -EventId 1001 -EntryType Error `
          -Message "Ошибка репликации $($fo.Name): $_"
    }
}

# Создание задачи в планировщике (каждые 4 часа)
$action = New-ScheduledTaskAction -Execute "PowerShell.exe" `
  -Argument "-ExecutionPolicy Bypass -File C:\Scripts\dhcp-replicate.ps1"
$trigger = New-ScheduledTaskTrigger -RepetitionInterval (New-TimeSpan -Hours 4) `
  -Once -At (Get-Date)
Register-ScheduledTask -TaskName "DHCP Failover Replication" `
  -Action $action -Trigger $trigger `
  -User "SYSTEM" -RunLevel Highest
Диагностика типичных проблем
Диагностика проблем репликации DHCP

Диагностика типичных проблем

За годы работы с DHCP Failover мы видели одни и те же грабли снова и снова. Вот что чаще всего ломается и как это чинить:

Состояние Communication Interrupted

Failover завис в Communication Interrupted? Первым делом проверьте:

# 1. Проверка сетевой связности
Test-NetConnection -ComputerName dhcp02.corp.local -Port 647

# 2. Проверка службы DHCP на партнёре
Get-Service DHCPServer -ComputerName dhcp02.corp.local

# 3. Проверка брандмауэра
Get-NetFirewallRule | Where-Object {
  $_.DisplayName -like "*DHCP*" -or $_.LocalPort -eq 647
} | Format-Table DisplayName, Enabled, Direction, Action

# 4. Проверка синхронизации времени
w32tm /monitor /computers:dhcp01.corp.local,dhcp02.corp.local

# 5. Просмотр журнала аудита DHCP
Get-Content "C:\Windows\System32\dhcp\DhcpSrvLog-*.log" -Tail 100 |
  Select-String "failover|partner"

Процентов в 80 случаев виноват один из двух виновников — порт 647 заблокирован где-то по пути между серверами, или время на машинах разошлось больше чем на 60 секунд. Начинайте диагностику именно с этого.

Конфликты IP-адресов после восстановления

Один из серверов долго лежал, а после подъёма начались конфликты адресов? Вот порядок действий:

# Просмотр конфликтных аренд
Get-DhcpServerv4Lease -ScopeId 10.0.1.0 | Where-Object {
  $_.AddressState -like "*Declined*"
} | Format-Table IPAddress, HostName, AddressState

# Очистка отклонённых адресов
Get-DhcpServerv4Lease -ScopeId 10.0.1.0 | Where-Object {
  $_.AddressState -like "*Declined*"
} | Remove-DhcpServerv4Lease

# Полная пересинхронизация
Invoke-DhcpServerv4FailoverReplication -Name "DHCP-FO-Office" -Force

Чтобы такого не повторялось, включите обнаружение конфликтов на обоих серверах:

Set-DhcpServerSetting -ConflictDetectionAttempts 2

Ошибка при добавлении failover

Мастер или командлет падает с ошибкой при создании отношения 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-отношение сразу — так и управлять проще, и не запутаешься потом.

#DHCP failover#отказоустойчивый DHCP#Windows Server DHCP#DHCP кластер#Hot Standby DHCP#Load Balance DHCP#настройка DHCP failover#репликация DHCP

Столкнулись с похожей задачей? Обращайтесь — решим

Если у вас происходит что-то из описанного в этой статье — или любая другая проблема с ИТ-инфраструктурой, — обращайтесь в любое время. Мои специалисты и я лично разберём ситуацию, найдём настоящую причину и доведём до решения.

Возьмёмся и за разовую задачу, и за постоянное обслуживание. Первичная консультация — бесплатно и без обязательств.

📞 +7 903 729-62-41 ✈ Telegram @ITfresh_Boss

С уважением, Семёнов Евгений Сергеевич, директор «АйТи Фреш» — IT-аутсорсинг для компаний до 50 рабочих мест, 15+ лет практики

Комментарии 0

Оставить комментарий

загрузка...

Источники

Подпишитесь на рассылку ITfresh

Каждую неделю мы выпускаем практические гайды для руководителей IT и системных администраторов. Это не просто теория! Здесь вы найдёте всё: безопасность, 1С, миграции, резервные копии и проверенные лайфхаки из наших реальных проектов.

Письмо придёт в течение минутыНе нашли его во «Входящих» — загляните в папку «Спам» или «Промоакции» и нажмите «Не спам». Так все следующие выпуски будут приходить прямо в основную почту.
Реквизиты оператора персональных данных

ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.