Назад | Перейти на главную страницу

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

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

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

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

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

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

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

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

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

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

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

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

Несколько серверов DHCP PT 1: охват нескольких подсетей.

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

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

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

Несколько DHCP-серверов PT 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 на это, возможно, стоит обратить внимание, даже если вы не используете реализацию Microsoft DHCP, поскольку она довольно хорошо иллюстрирует принципы, о которых здесь говорится, и этот ответ уже достаточно длинный.

Разделение объема - передовая практика

Одна вещь, которую вы услышите как лучшую практику, - это правило 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-серверы в одной или нескольких виртуальных локальных сетях «центрального сервера» и использовать ретрансляционные агенты BOOTP на всех ваших маршрутизаторах для отправки всех DHCP-запросов от очень большого и сегментированного сеть к централизованной службе DHCP (чем я занимаюсь, см. ниже). Или вы можете распределить DHCP-серверы по сети, с «основным» DHCP-сервером в его локальной подсети и «резервным» DHCP-сервером в «соседнем» сегменте сети, предоставляя небольшое количество адресов в качестве резервных - вы даже можете иметь два DHCP-сервера в своих сегментах сети, настроенных для предоставления друг другу адресов 80/20 диапазона. Наиболее разумный выбор будет зависеть от того, как ваши физические и логические сети соотносятся друг с другом.

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

Альтернативой было бы использование истинного аварийного переключения ISC DHCPD: https://kb.isc.org/article/AA-00502/0/A-Basic-Guide-to-Configuring-DHCP-Failover.html