Windows Server 2012: DHCP Failover

Роль сервера DHCP является стандартной для многих корпоративных сетей, так как сильно упрощает процесс настройки клиентов. Это накладывает определённые требования по обеспечению доступности серверов DHCP в локальной сети предприятия. Обесепечние высокой доступности для серверов DHCP позволяет добиться следующих целей:

• Любой авторизованный компьютер, который подключается к сети имеет возможность получить ip-адрес и дополнительные настройки сети от службы DHCP в любой момент времени
• После получения ip-адреса, компьютер имеет возможность продлить аренду ip-адреса и продолжить использовать тот же ip-адрес

Windows Server 2012 предоставляет новый механизм обеспечения высокой доступности для роли DHCP. Два DHCP-сервера могут быть настроены для обеспечение высокой доступности сервиса DHCP через отказоустойчивость (failover relationship) (по аналогии с отказоустойчивым кластером). Отказоустойчивость имеет несколько параметров, влияющих на поведение серверов DHCP в случае сбоя: режим отказоустойчивой работы, области (scopes), защищённые отказоустойчивой связью. Последние полностью совпадают друг с другом в случае настройки отказоустойчивости. Если отказоустойчивость настроена, то DHCP серверы реплицируют информацию об арендованных ip-адресах и дополнитульную информацию о клиентах между собой, и, таким образом, всегда содержат актуальную информацию обо всех клиентах в сети. Если один из DHCP серверов становится по какой-то причине недоступен, то другие DHCP серверы будут содержать актуальную информацию о клиентах и смогут обслуживать их запросы.

Режим отказоустойчивой работы (Failover Operation). Существует два режима настройки отказоустойчивости DHCP для разных топологий внедрения: балансировка нагрузки (Load Balance) и горячее резервирование (Hot Standby). Балансировка нагрузки используется, когда все настроенные DHCP серверы обрабатывают клиентские запросы, при этом процент обрабатываемых запросов конкретным сервером настраивается дополнительно (Active-Active конфигурация). Горячее резервирование соответствует Active-Passive конфигурации. Необходимо будет указать, какой DHCP сервер будет обрабатывать клиентские запросы, второй в это время будет находиться в резерве. Резервный сервер не занимается обслуживанием клиентских запросов пока работает первый сервер. При этом он получает все обновления информации об аренде адресов от работающего сервера и сохраняет её в своей базе.

Отказоустойчивые DHCP сервера могут находиться в разных подсетях и даже в разных географических регионах.

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

Более сложная топология внедрения отказоустойчивых DHCP серверов в разных сайтах показана ниже. Сайты Hyderabad и Redmond имеют локальные DHCP серверы, обслуживающие клиентские запросы в своём сайте. Для обеспечения высокой доступности сервиса DHCP можно настроить отказоустойчивость DHCP в режиме горячего резервирования. Одна отказоустойчивая конфигурация будет содержать все сети и области в сайте Hyderabad. Локальный DHCP сервер будет выступать в качестве активного сервера, сервер в сайте Redmond будет находиться в резерве. Вторая отказоустойчивая конфигурация будет содержать все сети и области в сайте Redmond. Локальный DHCP сервер будет выступать в качестве активного сервера, сервер в сайте Hyderabad будет находиться в резерве.

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

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

Старые механизмы обеспечения высокой доступности. До текущего момента DHCP сервер мог обеспечить высокую доступность через размещение на отказоустойчивом кластере или через объединение областей. Оба этих решения имеют свои недостатки.

Механизм объединения областей реализуется через настройку одинаковых областей на двух DHCP серверах и настройкой диапазонов исключения. 80% ip-адресов используется первым сервером, 20% – вторым. Второй сервер часто настраивался реагировать на запросы клиентов с небольшой задержкой. В итоге клиенты работали в основном с первым сервером. Такая конфигурация имеет две проблемы. Подсети часто используют больше 80% доступных ip-адресов. В таких подсетях механизм объединения областей мало эффективен в связи с недостатком свободных адресов в пуле. Вторая проблема такой конфигурации связана с невозможностью клиентом использовать старые настройки в случае выхода из строя первого сервера. Так как ip-адрес, полученный клиентом от первого сервера, находится в диапазоне исключения на втором сервере, то второй сервер будет вынужден выдать клиенту новый адрес. Возможности продлить аренду старого адреса не будет. В случае использования механизма объединения областей два DHCP сервера не будут синхронизировать информацию о выданных адресах.

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

Маханизм отказоустойчивости DHCP устраняет недостатки обоих решений и значительно упрощает процесс развёртывания. Кроме этого он поддерживается во всех версиях Windows Server 2012, что позволяет построить недорогое отказоустойчивое решение для сервиса DHCP.

Как работает режим балансировки нагрузки. Каждый DHCP сервер при получении запроса клиента вычисляет хэш MAC-адреса клиента, используя алгоритм хэширования, описанный в RFC3074. Каждый сервер получает значение хэша в диапазоне от 1 до 256. Если распределение нагрузки между узлами выставлено в 50:50, то клиентский запрос, содержаший MAC-адрес хэш которого будет в интервале от 1 до 128 будет обработан первым сервером, если хэш будет в интервале от 129 до 256, то запрос будет обрабатываться вторым сервером. Это даёт гарантию, что на запрос клиента ответит только один сервер. Если распределение нагрузки будет другим, распределение значений хэшей между серверами изменится пропорционально. Таким образом, администратор не участвует в настройке распределения MAC-адресов между серверами.

Обработка ip-адресов при использовании режима балансировки нагрузки. Свободные ip-адреса в каждой отказоустойчивой области будут распространяться в той же пропорции что и балансировка нагрузки. Например, у нас есть отказоустойчивая область 10.10.10.0/24 с диапазоном доступных адресов 10.10.10.1 – 10.10.10.250. Предположим, что адреса с .10.10.1 по 10.10.10.50 выданы в аренду, а начиная с 10.10.10.51 свободны. В этой ситуации адреса с 10.10.10.51 по 10.10.10.150 будут использоваться первым сервером, а с 10.10.10.151 по 10.10.10.250 вторым, соответствуя таким образом распределению нагрузки 50:50. Таким образом, клиент с MAC-адресом, хэш которого будет в диапазоне, закреплённом за первым сервером, получит ip-адрес начиная с 10.10.10.51.

Как видно из этого примера, когда настроена отказоустойчивость для области, два сервера будут выдавать ip-адреса из разных частей доступного диапазона адресов, в отличие от ситуации с одним сервером, который будет использовать весь доступный диапазон ip-адресов.

Когда клиенты запрашивают адреса, свободные адреса из пула одного сервера могут кончаться быстрее чем свободные адреса из пула второго сервера. Чтобы гарантировать соответствие пропорции доступных ip-адресов, основной (primary) сервер каждые пять минут проверяет распределение свободных ip-адресов между двумя серверами и занимается перераспределением доступных ip-адресов между серверами. Это называется периодической перебалансировкой пула свободных ip-адресов.

Количество свободных ip-адресов на каждом сервере отказоустойчивой области можно посмотреть через статистику области. Поля Addresses Available (this Server’s Pool) и Addresses Available (Partner Pool) показывают количество свободных ip-адресов доступных соответствующему серверу. Окно статистики можно открыть из контекстного меню области, выбрав Display Statistics, либо используя командлет Get-DhcpServerv4ScopeStatistics с ключём  –failover. В статистике доступны два дополнительных поля – Addresses granted (this Server’s Pool) и Addresses granted (Partner Pool), указывающие количество зарезервированных адресов.

Поведение балансировки нагрузки в случае сбоя. Когда отказоустойчивая конфигурация области находится в рабочем состоянии, алгоритм хэширования срабатывает для каждого клиентского запроса. В случае прерывания связи между серверами алгоритм хэширования перестаёт использоваться для обслуживания запросов клиентов. Сервер начинает отвечать всем клиентам, работая в обычном режиме, обеспечивая, таким образом, доступность сервиса.

Когда отказоустойчивая конфигурация области находится в рабочем состоянии, сервер так же может обслуживать повторные запросы клиента, которые должен (на основании алгоритма хэширования) обрабатывать второй сервер. Сервер определяет, что это повторный запрос на основании поля sec в DHCP-запросе клиента. Согласно RFC2131 поле sec показывает количество секунд прошедших с того момента, как клиент послал запрос на получение ip-адреса или на продление аренды. Если sec больше шести секунд, то DHCP сервер ответит клиенту, даже если хэш MAC-адреса клиента не входит в диапазон обслуживаемых сервером хэшей. Идея этого подхода заключается в том, что нужно отвечать на запросы клиентов даже в том случае, если сервер, который должен ответить на запрос клиента не доступен, и при этом каких либо ошибок в работе отказоустойчивой конфигурации области не показывается (это может быть связано с задержкой в 30 секунд, которая возникает прежде чем первый сервер обнаруживает, что второй сервер недоступен).

Maximum Client Lead Time (MCLT). Протокол отказоустойчивости DHCP содержит параметр Maximum Client Lead Time (MCLT), который задаёт временный период аренды ip-адреса для нового клиента. Этот параметр так же определяет время, в течение которого DHCP сервер, работающий в режиме отказоустойчивости, будет ждать восстановления канала связи с партнёром. После этого, если партнёр будет находиться в нерабочем состоянии, управление распределением ip-адресов перейдёт полностью под контроль первого сервера. MCLT не может быть равно нулю, и по умолчанию составляет один час.

Процент зарезервированных адресов. При настройке отказоустойчивости DHCP в режиме горячего резервирования администратор может указать процент диапазона адресов в области для резервного сервера. Количество адресов, соответствующее указанному проценту будет закреплено за резервным сервером. Резервный сервер будет их использовать для обслуживания запросов клиентов в случае, если основной сервер станет недоступен и до того момента, когда контроль над всем диапазоном перейдёт резервному серверу. Резервный сервер возьмёт контроль над диапазоном адресов области только после того, как основной сервер будет недоступен в течение интервала времени указанного в MCLT. Если администратор установит этот параметр в ноль, то резервный сервер не сможет обслуживать запросы клиентов, пока не получит контроль над всем диапазоном адресов. По умолчанию процент зарезервированных адресов – 5%.

Интервал автоматического переключения. Сервер, который теряет канал связи с партнёром переходит в режим прерванной связи. Потеря связи может быть связана с проблемами в сети или с выключением сервера-партнёра. Так как сервер не имеет возможности выявить причину потери связи, то он будет находиться в режиме прерванной связи до тех пор, пока администратор вручную не укажет, что сервер-партнёр не работает. Кроме этого, имеется возможность автоматически указать, что партнёр не работает, которая основана на временном интервале. Этот настраиваемый параметр называется интервалом автоматического переключения. По умолчанию составляет 10 минут.

Аутентификация сообщений протокола отказоустойчивости DHCP. Windows Server 2012 для аутентификации сообщений протокола отказоустойчивости DHCP реализует криптографический стандарт SHA-2. По умолчанию используется SHA-256. Для настройки аутентификации сообщений мастер настройки отказоустойчивости DHCP предложит ввести общий секрет. В продолжении процесса настройки отказоустойчивости мастер распространит общий секрет на каждый сервер, который будет работать в режиме отказоустойчивости.

Исходные материалы:
Ensuring High Availability of DHCP using Windows Server 2012 DHCP Failover
DHCP Failover Load Balance Mode
Understand and Troubleshoot DHCP Failover in Windows Server “8” Beta