ISC DHCP Failover управление через API

[B@F]

ISC DHCP Failover управление через API

В статье "dhcp сервер с отказоустойчивой конфигурацией" http://linuxforum.kz/index.php?topic=5912.0 я пытался рассказать как настроить DHCP Failover. Сейчас я хочу рассказать о некоторых особенностях такой конфигурации и способах их устранения. И так начнем.

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

1. STARTUP state - как понятно из названия это первое состояние после запуска. Во время этого состояния сервер обновляет информацию от соседа, если такой уже работает, и заносит информацию в свою базу данных dhcpd.leases. В этом состоянии на все запросы от клиентов он отвечает unrespon, что можно видеть в логах.

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

dhcpd: failover peer test: I move from normal to startup
dhcpd: DHCPDISCOVER from d0:54:2d:02:5a:7f via 10.43.28.1: not responding (startup)
dhcpd: DHCPDISCOVER from d0:54:2d:02:4d:27 via 10.43.28.1: not responding (startup)
Стартовый период обусловлен несколькими правилами. Так например если сервер был в нерабочем состоянии меньше чем значение MCLT, то период составит от 5 до 10 секунд. Если он не работал больше чем MCLT то время запуска будет от 30 до 60 секунд, а может и больше.

2. NORMAL state - тут должно быть то же все понятно. Нормальная работа сервера согласно конфигурации.

3. COMMUNICATIONS-INTERRUPTED state - состояние невозможности соединиться с другим сервером, для обмена информации. Вот от сюда и и начинается особенность. В этом состоянии сервер работает как и работал обслуживая все ранее выданные адреса и добавляя в базу новых клиентов. Он не считает, что его партнер не работает, а предполагает, что партнер всего лишь не может с ним связаться. Таким образом он располагает только половиной выделенного пула. Так же в этом состоянии не работает балансировка нагрузки, что и правильно.

4. PARTNER-DOWN state - состояние, при котором сервер считает, что его партнер не работает. Это состояние похоже на MMUNICATIONS-INTERRUPTED state но только в этом сервер располагает всем пулом адресов.

У партнеров есть еще много различных состояний, но я остановился на этом.

Теперь возникает вопрос когда сервер переходит из состояния COMMUNICATIONS-INTERRUPTED в состояние PARTNER-DOWN? Согласно документа http://tools.ietf.org/html/draft-ietf-dhc-failover-12 для этого есть специальный период называемый "Safe Period". Целью данного периода дать возможность персоналу определить неисправность или восстановить связь с партнерами. Кто знает может STP решил дерево перестроить.

Длина этого периода зависит в основном от числа не занятого ip пула в пределах данной подсети и частоты появления новых клиентов DHCP. Таким образом этот период может длится до нескольких дней. В Cisco, к примеру, данный период составляет 24 часа.

А вот с ISC DHCP не повезло, у него нет данного периода и если один из партнеров перестанет работать, то состояние PARTNER-DOWN так и не наступит. Печалька. 

Перевести сервер в состояние PARTNER-DOWN можно только в ручную используя OMAPI. Для этого в настройках сервера в global секции нужно добавить параметр

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

omapi-port 7911;
Производитель рекомендует

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

omapi-port 7911;
omapi-key omapi_key;

key omapi_key {
     algorithm hmac-md5;
     secret Ofakekeyfakekeyfakekey==;
}

Для генирации ключа нужно использовать команду

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

Key Generation Hint


You can generate good random OMAPI keys using the dnssec-keygen utility, distributed with BIND.

e.g.:  dnssec‐keygen ‐a HMAC‐MD5 ‐b 512 ‐n USER DHCP_OMAPI
У меня закрытая сеть и настроенный фаервол, я ключи не использовал.

После того как вы добавили порт и рестартанули демон, можно начинать использовать omshell. Самый простой способ и самый удобный использовать скрипт, вот мой вариант:

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

#!/bin/sh
omshell << EOF
connect
new failover-state
set name = "tste"
open
set local-state = 8
update
EOF
Где имя - это имя вашего Failover, а 8 - это в какое состояние ему перейти.

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

1 - startup
2 - normal
3 - communications interrupted
4 - partner down
5 - potential conflict
6 - recover
7 - paused
8 - shutdown
9 - recover done
10 - resolution interrupted
11 - conflict done
254 - recover wait
Ну и пример:
[spoiler]root@test:~# omshell << EOF               
connect
new failover-state
set name = "test"
open
set local-state = 4
update
EOF

> obj: <null>
> obj: failover-state
> obj: failover-state
name = "test"
> obj: failover-state
name = "test"
partner-address = 70:2a:ce:38
partner-port = 00:00:02:08
local-address = 70:2a:cd:d8
local-port = 00:00:02:07
max-outstanding-updates = 00:00:00:0a
mclt = 00:00:0e:10
load-balance-max-secs = 00:00:00:05
load-balance-hba = ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
partner-state = 00:00:00:02
local-state = 00:00:00:08
partner-stos = 52:e8:95:74
local-stos = 52:e9:d9:83
hierarchy = 00:00:00:00
last-packet-sent = 00:00:00:00
last-timestamp-received = 00:00:00:00
skew = 00:00:00:00
max-response-delay = 00:00:00:3c
cur-unacked-updates = 00:00:00:00
> obj: failover-state
name = "test"
partner-address = 70:2a:ce:38
partner-port = 00:00:02:08
local-address = 70:2a:cd:d8
local-port = 00:00:02:07
max-outstanding-updates = 00:00:00:0a
mclt = 00:00:0e:10
load-balance-max-secs = 00:00:00:05
load-balance-hba = ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
partner-state = 00:00:00:02
local-state = 4
partner-stos = 52:e8:95:74
local-stos = 52:e9:d9:83
hierarchy = 00:00:00:00
last-packet-sent = 00:00:00:00
last-timestamp-received = 00:00:00:00
skew = 00:00:00:00
max-response-delay = 00:00:00:3c
cur-unacked-updates = 00:00:00:00
> obj: failover-state
name = "test"
partner-address = 70:2a:ce:38
partner-port = 00:00:02:08
local-address = 70:2a:cd:d8
local-port = 00:00:02:07
max-outstanding-updates = 00:00:00:0a
mclt = 00:00:0e:10
load-balance-max-secs = 00:00:00:05
load-balance-hba = ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
partner-state = 00:00:00:02
local-state = 4
partner-stos = 52:e8:95:74
local-stos = 52:e9:d9:83
hierarchy = 00:00:00:00
last-packet-sent = 00:00:00:00
last-timestamp-received = 00:00:00:00
skew = 00:00:00:00
max-response-delay = 00:00:00:3c
cur-unacked-updates = 00:00:00:00

dhcpd: failover peer test: I move from communications-interrupted to shutdown[/spoiler]

Остается только придумать костыль, который спустя время переводил бы сервер в состояние PARTNER-DOWN, а потом когда партнер возвращается в NORMAL. Но я решил этого не делать, полюбому в течении суток я восстановлю сломанный сервер dhcp.

Все необходимое о работе протокола DHCP FAILOVER можно почитать тут http://tools.ietf.org/html/draft-ietf-dhc-failover-12

[B@F]

Нашел решение автоматического перехода в состояние PARTNER-DOWN

Просто в конфиг failover добавляем

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

auto-partner-down sec;

auto-partner-down sec; This statement specifies a sec seconds time delay upon entering the communications-interrupted state when the server is unable to communicate with its failover peer. The default is 0. This option should be used with care.

Как раз по умолчанию отключено. Вот же изверги. Ну хоть бы в каком-то мане написали это. Уже проверил работает.

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

Jan 30 22:45:17 test dhcpd: failover peer test: I move from communications-interrupted to startup
Jan 30 22:45:33 test dhcpd: failover peer test: I move from startup to communications-interrupted
Jan 30 22:46:33 test dhcpd: failover peer test: I move from communications-interrupted to partner-down
Взято тут http://ipamworldwide.com/dhcp-failover-a-load-balancing/declarations.html
Ну хоть бы в одном мане про это написали!!!! нету нигде!!!