Могу ли я иметь несколько DHCP-серверов в одной сети?

Это канонический вопрос о резервных DHCP-серверах.

Можно ли иметь более одного DHCP-сервера в одной и той же LAN? Каковы последствия этого?

1. Что происходит, если доступно более одного DHCP-сервера? Как мои клиенты знают, какой использовать?
2. Как я могу сделать так, чтобы DHCP-серверы предоставляли адреса более чем одному подсегментов сети?
3. Как настроить несколько DHCP-серверов для предоставления адресов для одной и той же подсети.

Я предполагаю, что вы обладаете базовыми знаниями о том, что делает DHCP и как настроить ваш предпочтительный DHCP-сервер для ответа на этот вопрос, но перед тем, как мы поговорим о нескольких DHCP-серверах в одной сети, давайте сначала быстро напомним, как клиенты получают IP-адреса от DHCP на самом базовом уровне.

DHCP в простой сети работает по принципу DORA.

• Обнаружение — клиент транслирует сообщение в локальном сегменте сети, к которому он подключен, чтобы обнаружить доступные DHCP-серверы.

• Предложение — соответствующим образом настроенный DHCP-сервер получает запрос от клиента и предлагает ему адрес из своего пула доступных адресов.

• Запрос — клиент отвечает на предложение, запрашивая полученный адрес в предложении.

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

Любое устройство в сегменте сети может быть DHCP-сервером; это не обязательно должен быть маршрутизатор или контроллер домена или какое-то другое “особое” устройство в сети.

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

Несколько DHCP-серверов Часть 1: Охватываем несколько подсетей.

Если у вас есть несколько VLAN или физических сегментов сети, которые разделены на разные подсети, и вы хотите предоставлять DHCP-обслуживание устройствам во всех этих подсетях, то здесь есть два способа сделать это.

1. Если маршрутизатор / коммутатор уровня 3, разделяющий их, может выступать в качестве агента ретрансляции BOOTP/DHCP, вы можете продолжать держать все свои DHCP-серверы в одной или двух центральных частях вашей сети и настроить свои DHCP-серверы для поддержки нескольких диапазонов адресов. Для поддержки этого ваш маршрутизатор или коммутатор уровня 3 должен поддерживать спецификацию агента ретрансляции BOOTP, изложенную в разделе 4 RFC 1542.

2. Если ваш маршрутизатор не поддерживает агентов ретрансляции BOOTP по RFC 1542 или если некоторые из ваших сегментов сети географически распределены по медленным ссылкам, тогда вам нужно будет разместить один или несколько DHCP-серверов в каждой подсети. Этот «локальный» DHCP-сервер будет обслуживать только потребности своего локального сегмента и не будет взаимодействовать с другими DHCP-серверами. Если это то, что вам нужно, то вы можете просто настроить каждый DHCP-сервер как автономный сервер с деталями пула адресов для своей подсети и не беспокоиться о других DHCP-серверах в других частях сети. Это самый простой пример наличия более одного DHCP-сервера в одной и той же сети.

Несколько DHCP-серверов Часть 2: DHCP-серверы, обслуживающие один и тот же сегмент сети.

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

Это вполне возможно, хотя требует некоторого размышления и планирования.

С точки зрения «сетевого трафика», процесс DORA, описанный в начале этого ответа, объясняет, как на одном сегменте сети может быть представлено более одного DHCP-сервера; клиент просто транслирует запрос Обнаружения, и первый DHCP-сервер, который ответит с Предложением, является «победителем».

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

Другими словами, если у вас есть диапазон DHCP-адресов для выдачи клиентам от 192.168.1.100 до 192.168.1.200, то оба сервера должны быть настроены на обслуживание отдельных частей этого диапазона, так что первый сервер может использовать части этого диапазона от 192.168.1.100 до 192.168.1.150, а второй сервер будет выдавать адреса с 192.168.1.151 до 192.168.1.200.

Более новые реализации DHCP от Microsoft имеют мастер для упрощения разделения области подобным образом, описанный в статье на Technet, которая может быть полезна для изучения, даже если вы не используете реализацию DHCP от Microsoft, так как она хорошо иллюстрирует обсуждаемые здесь принципы, и этот ответ уже достаточно длинный.

Разделение области — лучшая практика

Одна из вещей, которые вы услышите, упоминается как лучшая практика — это правило 80/20 для разделения области DHCP, что означает, что один сервер будет обслуживать 80% адресов в этой области, а другой DHCP-сервер, который фактически находится «в резерве», будет обслуживать 20% адресов.

Идея разделения адресов 80/20 заключается в том, что 80% доступных адресов должны, возможно, быть достаточными для всех нужных адресов в подсети, и аренды DHCP обычно выдаются на несколько дней; таким образом, если ваш основной DHCP-сервер выходит из строя на несколько часов, то маловероятно, что более 20% машин в этой подсети потребуется обновить свои адреса во время простоя, что делает пул из 20% адресов достаточным.

Это все еще разумный совет, но он предполагает две вещи:

1. Что вы можете быстро решить любую проблему с вашим «основным» DHCP-сервером, чтобы избежать исчерпания небольшого пула адресов на вашем резервном DHCP-сервере.
2. Что вы не заинтересованы в балансировке нагрузки.

В наше время (как видно из моих примеров) я склонен предпочитать разделение 50/50, которое, по моему мнению, более реалистично в ответ на вышеуказанные пункты.

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

Совмещение этих идей

Наконец, стоит помнить, что вы можете совмещать обсуждаемые выше принципы – вы можете разместить все ваши DHCP-сервера в одной или нескольких “центральных серверных” VLAN и использовать агентов ретрансляции BOOTP на всех ваших маршрутизаторах, чтобы отправлять все DHCP-запросы из очень большой и сегментированной сети на централизованное DHCP-обслуживание (что я делаю, см. ниже). Или вы можете иметь DHCP-серверы, распределенные по всей вашей сети, с “основным” DHCP-сервером в его локальной подсети и “резервным” DHCP-сервером на “близлежащем” сетевом сегменте, предоставляющим небольшое количество адресов в качестве резервной копии – вы даже можете иметь два DHCP-сервера в своих собственных сегментах сети, настроенные для предоставления диапазона адресов 80/20 друг для друга. Наиболее разумный выбор будет зависеть от того, как ваши физические и логические сети связаны друг с другом.

Я принял этот подход несколько лет назад для небольшой и средней (500 пользователей) сети с значительными преимуществами. DHCP перестало быть единой точкой отказа. Постоянно связывая MAC и IP-адреса, мы обеспечивали, что оба DHCP-сервера давали один и тот же ответ на каждый DHCP-запрос. Знание IP-адреса каждого сетевого актива также упростило администрирование сети, и DNS мог работать на той же базе данных. Система использовала Internet Software Corporation BIND и DNS, и связанные скрипты можно скачать на https://web.archive.org/web/20121031051901/http://www.pearbright.com/index.php/download/25-dns-dhcp-download.

Альтернативой было использовать настоящую отказоустойчивость ISC DHCPD: https://kb.isc.org/docs/aa-00502