Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Настраиваем высокодоступный DHCP-сервер в Windows Server 2012

Настраиваем высокодоступный DHCP-сервер в Windows Server 2012

DHCP-сервера являются одними из ключевых элементов сетевой инфраструктуры, однако, в отличии от DNS-серверов или контроллеров домена, в Windows Server отсутствовали штатные механизмы обеспечения высокой доступности. Начиная с Windows Server 2012 появилась возможность создания отказоустойчивых конфигураций DHCP, о чем мы сегодня и расскажем.

Перед тем, как приступать к рассказу о новых возможностях DHCP-сервера сделаем краткий экскурс в историю. До выхода Windows Server 2012 задача обеспечения высокой доступности решалась путем разделения области DHCP на две части, каждую из которых обслуживал свой сервер. Но такой подход имел множество неудобств, начиная от того, что все настройки нужно было дублировать между серверами и заканчивая тем, что в случае отказа все равно потребуется ручное вмешательство, особенно если оставшаяся часть области меньше, чем количество обслуживаемых ПК.

В Windows Server 2012 появилась возможность объединить два DHCP-сервера в конфигурацию высокой доступности, которая может работать в двух режимах: балансировки нагрузки или горячей замены.

Режим балансировки нагрузки является предпочтительным, в этом случае оба сервера одновременно обслуживают одну и ту же область, реплицируя данные между собой. Запросы клиентов делятся между серверами в заданной пропорции, по умолчанию 50/50. В случае отказа одного из серверов обслуживание продолжает оставшийся сервер.

Схема работы предельно проста и аналогична работе других сетевых сервисов, таких как DNS или AD — клиентские запросы обслуживаются до тех пор, пока в сети есть хоть один сервер, способный обработать запрос. Однако есть ограничение: два сервера на область DHCP. Следует помнить и понимать, высокая доступность DHCP реализуется не на базе серверов, а на базе областей. Если один сервер содержит несколько областей, то он, соответственно, может входить в несколько конфигураций высокой доступности.

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

Такая схема может быть удобна для распределенных сетей и филиалов, когда резервный сервер располагается в другой части сети, связь с которой ограничена медленным каналом. На схеме ниже показана структура, где два сервера основной сети (область 192.168.31.0) работают в режиме балансировки нагрузки, в тоже время один из этих серверов является сервером горячей замены для филиала (область 192.168.44.0).

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

Как видим, возможностей вполне достаточно для реализации самых разных схем и сценариев. Перейдем от теории к практике.

На двух серверах сети, в нашем случае это контроллеры домена SRV-DC01 и SRV-DC02, добавим роль DHCP-сервера, который обязательно авторизуем в Active Directory.

На одном из серверов добавляем и настраиваем область DHCP.

Затем щелкнув правой кнопкой мыши на нужную область, в выпадающем меню, выбираем Настройка обработки отказа.

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

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

Разберем доступные опции:

• Максимальное время упреждения для клиента — время на которое сервер-партнер продлевает аренду адресов клиентам второго сервера, если связь с ним потеряна.
• Процент распределения нагрузки — все понятно из названия, задает пропорцию распределения запросов между серверами.
• Интервал переключения состояния — время, после потери связи с партнером, когда сервер перейдет из состояния «связь потеряна» в состояние «партнер отключен»
• Проверять подлинность сообщений — между серверами устанавливается защищенный канал связи с использованием парольной фразы.

В режиме горячей замены набор опций несколько иной:

• Роль сервера-партнера — позволяет выбрать роли серверов, по умолчанию активным становится сервер, на котором настраивается обработка отказа, партнер переводится в ждущий режим.
• Адреса, выделенные для резервного сервера — часть диапазона, выделяемая резервному серверу для обслуживания новых клиентов в режиме «связь потеряна».

Указав все необходимые настройки жмем Далее и завершаем работу мастера.

На этом настройка высокодоступного DHCP-сервера закончена и самое время разобраться как это работает.

Важно! В настоящее время между серверами реплицируется только информация о выданных IP-адресах, при изменении настроек области, в том числе при резервировании адресов, изменения следует синхронизировать вручную.

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

Если по истечении времени интервала переключения сервер партнер не вернется в строй, то оставшийся сервер перейдет в состояние «партнер отключен» и начнет самостоятельно выдавать адреса из всего диапазона. При этом обратившиеся за продлением аренды клиенты партнера вместо продления получат новый адрес. После того как партнер вернется в строй клиенты будут автоматически распределены между ними в заданной пропорции (но это не приведет к изменению адресов, просто переданные назад партнеру клиенты по истечении аренды получат новый адрес уже у него).

В режиме горячей замены сервер-партнер в режиме «связь потеряна», также продолжает продлевать аренду и выдает адреса новым клиентам из своего диапазона. При переходе в режим «партнер отключен» начинает обслуживать весь диапазон полностью и выдавать адреса всем клиентам. После того, как сервер-партнер вернется в строй, сервер горячей замены снова перейдет в ждущий режим и клиенты, по истечении времени аренды, получат адреса у основного сервера.

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Как установить dhcp windows 2012

Если вы не хотите воспользоваться нашей службой WTDHCP, то для настройки DHCP-сервера вам пригодится следующая методичка на примере Windows Server 2012, любезно предоставленная нашим пользователем Rushmore .

У нас простая сетка 192.168.1.0/24. Роутер во внешний мир пусть будет по адресу 192.168.1.1, на нем же DNS сервер.

DHCP сервер будет 192.168.1.2. Устанавливаем на нем Windows 2012 R2, добавляем роль DHCP Server. Серверу надо дать статический IP-адрес!

Сервер терминалов будет 192.168.1.3, на нем установлены WTware 5.4.16, все настройки по умолчанию. WTware DHCP отключен, TFTP включен.

Логинимся в DHCP сервер администратором, запускаем консоль управления DHCP.

Создаем новый диапазон адресов (scope).

Назовем наш диапазон LAN.

Исключим первые 15 адресов из раздачи (в принципе можно это не делать, потом внести все статические адреса в резервации).

Длительность аренды адреса оставим по умолчанию.

Роутер (шлюз по умолчанию).

Адрес сервера DNS и имя локального домена (если нужно).

WINS — укажите, если используете этот анахронизм.

Диапазон адресов создан.

На этом этапе рабочие станции будут получать адреса и базовые настройки от DHCP сервера. Теперь приступим к конфигурированию загрузки по сети (network boot).

Загружать по сети будем два типа клиентов:

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

При получении запроса от клиента DHCP сервер назначает адреса и опции в следующем порядке:

1. Политики, назначенные для диапазона (Scope Policies) в порядке приоритета.
2. Опции, назначенные для диапазона (Scope Options)
3. Политики, назначенные для сервера (Server Policies) в порядке приоритета.
4. Опции, назначенные для сервера (Server Options)

У каждой политики есть приоритет. Приоритеты нумеруются начиная с 1. Чем меньше номер, тем приоритетнее политика. Если в двух политиках определены одинаковые опции, клиенту отправляется та, которая определена в политике с более высоким приоритетом. Приоритет политики можно менять через GUI, кликнув правой кнопкой мыши по названию политики и выбрать «Up» или «Down».

На MAC-адреса, прописанные в резервациях (Reservations) действие политик не распространяется!

Условия применения политик могут быть следующие:

1. Vendor Class
2. User Class
3. MAC-адрес
4. PXE GUID клиента
5. Доменное имя клиента (опция 12)
6. DHCP Relay, обслуживающий запрос клиента.

Нас интересуют в основном Vendor Class. Перед созданием политики надо создать нужные нам Vendor Class.

Надо определить пять классов:

1. PXE Client x86
2. PXE Client UEFI x64
3. PXE Client UEFI BC
4. WTware

Жмем «Add…» чтобы добавить новый Vendor Class.

Заполняем имя класса: PXE Client x86

Заполняем ID класса: PXEClient:Arch:00000

Можно заполнять либо Binary (16-ричные значения), либо ASCII (просто набивать текст). Тут важно не ошибиться, иначе ничего не заработает.

Нажимаем OK и видим:

Аналогично добавляем следующие классы:

• Имя класса: PXE Client EFI BC
• ID класса: PXEClient:Arch:00007

Имя класса: PXE Client EFI x64

ID класса: PXEClient:Arch:00009

Имя класса: wtware

ID класса: wtware

Классы определены. Нажимаем «Close» и приступаем к созданию политик, которые будут пользоваться нашими классами.

Имя политики: pxeclient-x86

Политика будет определять загрузку BIOS клиентов.

Добавляем условие для нашей политики.

Устанавливаем так, как на картинке:

Обратите внимание на чекбокс «Append wildcard(*)». Это означает, что любой Vendor Class, который начинается с «PXEClient:Arch:00000», будет соответствовать условию.

Условие добавлено, жмем Next.

Нам не нужно резервировать IP-адреса, поэтому жмем No и Next.

Конфигурируем опцию 66.

192.168.1.3 — адрес нашего TFTP сервера, на котором лежат загрузочные файлы WTware.

Конфигурируем опцию 67.

Имя загрузочного файла: 5.4.16/wtware.pxe

Жмем Next и завершаем конфигурирование политики.

Следующая политика будет определять загрузку UEFI x64 клиентов. Имя политики: pxeclient-uefi64

Добавляем первое условие.

Добавляем второе условие.

Условие политики будет срабатывать при совпадении с любым из двух Vendor Class.

Конфигурацию IP-адресов пропускаем, как в предыдущей политике.

Далее конфигурируем опции по аналогии с предыдущей политикой:

• опция 66: 192.168.1.3
• опция 67: 5.4.16/bootx64.efi

Завершаем конфигурирование политики.

Вторая политика готова.

Осталась последняя политика — для WTware. Она читает опции 66 и 67 для определения пути загрузки пакетов. Делаем аналогично предыдущей политике:

Имя политики: wtware

В условии политики устанавливаем Vendor Class «wtware»

• Опция 66 = 192.168.1.3
• Опция 67 = 5.4.16/wtware.pxe

Сюда же можно добавить специфические для WTware опции 18 и 179, по желанию.

Конфигурация завершена. Все типы клиентов должны загружаться.

Здесь, конечно, рассмотрен простейший случай. В реальных сетях все намного сложнее.

Важное дополнение: Поскольку политики несовместимы с резервациями, если вам потребуется указать имя хоста (опция 12) или дать определенному клиенту выделенный IP-адрес, создайте новую политику по условию «MAC-address» и настройте нужные параметры для этого MAC-адреса через свойства политики