Варианты DHCP серверов с отказоустойчивой конфигурацией
Всем привет. Сегодня речь пойдет об DHCP сервере. Этот сервер в сети
играет одну из наиболее значимых функций и при его отказе у клиентов не
будет работать абсолютно все, все связанной с сетью и разумеется
интернет.
Что бы этого избежать нужно обеспечить безотказную работу сервера.
Разумеется RAID, гарантированное питание и 2 блока питания нас не всегда
спасут. Бывает накрывается и материнка и память и да все что угодно.
Что бы было спокойно до конца нужно использовать 2 независимых сервера.
Вот про варианты этой реализации и пойдет речь в статье.
1 - Вариант HA кластер (heartbeat)
Рассмотрим такую схему:
1 и 2 это физические сервера, а 0 это логический сервер, который и будет обрабатывать наши запросы.
Расскажу, что мы получим. 2 физических сервера у одного из них у
главного будет прописан плавающий адрес и только на главном будет
работать DHCP демон. Если главный по каким либо причинам умрет, то
плавающий адрес перейдет на резервный и на нем же запустится сервер
DHCP.
Я предполагаю, что вы сами сможете установить heartbeat и сервер DHCP, но вдруг нет, то это делается как-то так:
aptitude install heartbeat dhcpd
или
yum install heartbeat dhcpd
Файл конфигурации сервера dhcpd будет одинаковый на обоих нодах /etc/dhcp/dhcpd.conf:
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:
192.168.1.1 dhcp-0
192.168.1.2 dhcp-1
192.168.1.3 dhcp-2
Переходим в директорию /etc/ha.d приводим файл authkeys к примерно такому виду:
auth 1
1 sha1 mypasswordfordhcp
Далее на DHCP-1 правим ha.cf:
logfacility local0
keepalive 1 # Как часто посылать пинги
deadtime 3 # Через какое время считать партнера умершим
ucast eth1 192.168.1.3 # Адрес партнера
auto_failback off # Не переключаться обратно
node dhcp-1 dhcp-2
И наконец последнее haresources:
dhcp-1 192.168.1.1/24/eth0:1 isc-dhcp-server
Переходим на DHCP-2 правим ha.cf:
logfacility local0
keepalive 1 # Как часто посылать пинги
deadtime 3 # Через какое время считать партнера умершим
ucast eth1 192.168.1.2 # Адрес партнера
auto_failback off # Не переключаться обратно
node dhcp-1 dhcp-2
И наконец последнее haresources:
hcp-2 192.168.1.1/24/eth0:1 isc-dhcp-server
Замечу, что имя скрипта запуска (isc-dhcp-server) должно совпадать с тем, что лежит в /etc/in/it.d/
Все после этого запускаем кластер на обоих машинах и смотрим что происходит:
/etc/init.d/heartbeat start
А будет следующее:
Адрес 192.168.1.1 поднимется на DHCP-1 и на нем же запустится сервер DHCP.
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 будет работать в стандбай (standby) режиме, ожидая падения dhchp-1.
Судя по статьям из интернета, данный метод является не полным, но
вполне достаточным для работы отказоустойчивого кластера. О плюсах и
минусах можно говорить долго, но самый главный недостаток это то, что
при работе один из демонов dhcpcd должен быть выключен и он понятия не
имеет о том сколько и каких адресов выдал рабочий сервер. Хотя функция
ping-check нас спасет. Зато мы всегда будем знать какой сервер выдал
аренду DHCP-0.
2 - Вариант DHCP FAILOVER
Теперь схема будет такая:
Heartbeat нам не понадобится достаточно только isc-dhcp-server.
Почему не dhcpd, а потому что данный функционал не совместим в данный
момент с другими dhcp серверами. Его разрабатывает http://www.isc.org/ и
как они говорят сейчас функционал проходит стадию сертификации, что бы
он мог попасть в RFC.
Немного расскажу как работает DHCP FAILOVER. Во время запуска сервер
ищет соседа и если он его находит начинает обмен с ним данных из
dhcpd.leases, как только обмен закончен оба сервера переходят в режим
normal и начинают работу балансируя нагрузку между собой. Из недостатков
можно отметить, что всего 2 сервера могут участвовать в таком кластере.
Поехали, нам нужно будет править только файл /etc/dhcp/dhcpd.conf
Общее для нодов:
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;
}
}
Теперь на главном добавляем в этот же файл:
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 то нужно изменить работу ядра:
vconfig set_flag eth1.523 1 1
В результате dhcpd смомжет корректно обрабатывать запросы, где 523
это метка vlan id. Странно конечно, что приложение работающее на уровне
приложений лезет в канальный уровень, но видимо это связано с исходным
кодом демона.
liinuxforum.kz
| 
