dhcp сервер с отказоустойчивой конфигурацией.

[B@F]

Всем привет.

Сегодня речь пойдет об DHCP сервере.Этот сервер в сети играет одну из наиболее значимых функций и при его отказе у клиентов не будет работать абсолютно все, все связанной с сетью и разумеется интернет. Что бы этого избежать нужно обеспечить безотказную работу сервера. Разумеется RAID, гарантированное питание и 2 блока питания нас не всегда спасут. Бывает накрывается и материнка и память и да все что угодно. Что бы было спокойно до конца нужно использовать 2 независимых сервера. Вот про варианты этой реализации и пойдет речь в статье.

1 - Вариант HA кластер (heartbeat)

Рассмотрим такую схему:
[attachimg=1]
1 и 2 это физические сервера, а 0 это логический сервер, который и будет обрабатывать наши запросы.

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

Я предполагаю, что вы сами сможете установить heartbeat и сервер DHCP, но вдруг нет, то это делается как-то так

aptitude install heartbeat dhcpd

yum install heartbeat dhcpd

Файл конфигурации сервера dhcpd будет одинаковый на обоих нодах /etc/dhcp/dhcpd.conf

Код [Выделить] Expand

ddns-update-style none;
ddns-updates off;

default-lease-time 600;
max-lease-time 7200;

ping-check true;
ping-timeout 1;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

subnet 192.168.1.0 netmask 255.255.255.0 {
        }

Дальше заходим на DHCP-1 и правим файл /etc/hosts и тоже самое на DHCP-2

Код [Выделить] Expand

192.168.1.1 dhcp-0
192.168.1.2 dhcp-1
192.168.1.3 dhcp-2

Переходим в директорию /etc/ha.d приводим файл authkeys к примерно такому виду

Код [Выделить] Expand

auth 1
1 sha1 mypasswordfordhcp

Далее на DHCP-1
Правим ha.cf

Код [Выделить] Expand

logfacility     local0
keepalive 1               # Как часто посылать пинги
deadtime 3                # Через какое время считать партнера умершим
ucast eth1 192.168.1.3 # Адрес партнера
auto_failback off # Не переключаться обратно
node dhcp-1 dhcp-2
И наконец последнее haresources

Код [Выделить] Expand

dhcp-1 192.168.1.1/24/eth0:1 isc-dhcp-server

Переходим на DHCP-2
Правим ha.cf

Код [Выделить] Expand

logfacility     local0
keepalive 1               # Как часто посылать пинги
deadtime 3                # Через какое время считать партнера умершим
ucast eth1 192.168.1.2 # Адрес партнера
auto_failback off  # Не переключаться обратно
node dhcp-1 dhcp-2
И наконец последнее haresources

Код [Выделить] Expand

dhcp-2 192.168.1.1/24/eth0:1 isc-dhcp-server

Замечу, что имя скрипта запуска(isc-dhcp-server) должно совпадать с тем, что лежит в /etc/in/it.d/

Все после этого запускаем кластер на обоих машинах и смотрим что происходит.

Код [Выделить] Expand

/etc/init.d/heartbeat start
А будет следующее:
Адрес 192.168.1.1 поднимется на DHCP-1 и наи нем же запустится сервер DHCP.

Код [Выделить] Expand

eth0:0    Link encap:Ethernet  HWaddr 00:23:7D:ED:B7:6A 
                       inet addr:192.1681.1  Bcast: 192.1681.255 Mask:255.255.255.0

А нода dhcp-2  будет работать в стандбай режиме, ожидая падения dhchp-1

Судя по статьям из интернета, данный метод является не полным, но вполне достаточным для работы отказоустойчивого кластера.
О плюсах и минусах можно говорить долго, но самый главный недостаток это то, что при работе один из демонов dhcpcd должен быть выключен и он понятия не имеет о том сколько и каких адресов выдал рабочий сервер. Хотя функция ping-check нас спасет. Зато мы всегда будем знать какой сервер выдал аренду DHCP-0.


2 - Вариант DHCP FAILOVER

Теперь схема будет такая:
[attachimg=2]

heartbeat нам не понадобится достаточно только isc-dhcp-server. Почему не dhcpd, а потому что данный функционал не совместим в данный момент с другими dhcp серверами. Его разрабатывает http://www.isc.org/ и как они говорят сейчас функционал проходит стадию сертификации, что бы он мог попасть в RFC.

Немного расскажу как работает DHCP FAILOVER. Во время запуска сервер ищет соседа и если он его находит начинает обмен с ним данных из dhcpd.leases, как только обмен закончен оба сервера переходят в режим normal и начинают работу балансируя нагрузку между собой. Из недостатков можно отметить, что всего 2 сервера могут участвовать в таком кластере.

Поехали, нам нужно будет править только файл /etc/dhcp/dhcpd.conf
Общее для нодов:

Код [Выделить] Expand

ddns-update-style none;
ddns-updates off;

default-lease-time 600;
max-lease-time 7200;

ping-check true;
ping-timeout 1;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

shared-network test {
        subnet 192.168.1.0 netmask 255.255.255.0 {
                option subnet-mask 255.255.255.0;
                option ntp-servers 192.168.1.1;
                next-server 192.168.1.1;
                pool {
                        failover peer "test";
                        deny dynamic bootp clients;
                        range 192.168.1.2 192.168.3.254;
                        }
                option routers 192.168.1.1;
                }
}


Теперь на главном добавляем в этот же файл

Код [Выделить] Expand

failover peer "test" {
  primary;
  address 192.168.1.1;
  port 519;
  peer address 192.168.1.2;
  peer port 520;
  max-response-delay 60;
  max-unacked-updates 10;
  mclt 3600;
  split 128;
  load balance max seconds 3;
}
address - на каком адресе слушать
peer address - на какой адрес слать
порты по аналогии

Переходим к ведомому все тот же файл /etc/dhcp/dhcpd.conf
failover peer "test" {
  secondary;
  address 192.168.1.2;
  port 520;
  peer address 192.168.1.1;
  peer port 519;
  max-response-delay 60;
  max-unacked-updates 10;
  load balance max seconds 3;
}

Готова, после запуска в логах примерно следующее

secondary dhcpd: failover peer dhcp-failover: I move from communications-interrupted to normal
secondary dhcpd: pool 98e82b8 192.168.200.0/24 total 155  free 38  backup 37  lts 0

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

bind update on 192.168.1.227 from test rejected: incoming update is less critical than outgoing update

Я долго гадал что это значит. Оказалось, что данный адрес был выдан сразу 2-мя серверами и оба сервера при получении пакета DHCPREQUEST шлют клиенту DHCPACK. Очень хорошо, что оба сервера работают в кластере, т.к. Клиенту отсылается один и тот же адрес, а это сообщение пройдет спустя max-lease-time и выдаст в лог

192.168.1.227 lease owned by peer

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

П.С. Если будите использовать 802.1q то нужно изменить работу ядра

Код [Выделить] Expand

vconfig set_flag eth1.523 1 1
В результате dhcpd смомжет корректно обрабатывать запросы, где 523 это метка vlan id. Странно конечно, что приложение работающее на уровне приложений лезет в канальный уровень, но видимо это связано с исходным кодом демона.