Я хочу использовать опцию nopreempt с настройкой vrrp keepalived для запуска резервного узла в качестве ведущего, когда ведущий выходит из строя и снова возвращается в сеть.
Я устанавливаю опцию nopreempt на обоих серверах и устанавливаю состояние как резервную копию на обоих серверах, но из-за высокого приоритета nopreempt не работает.
Пожалуйста, помогите решить эту проблему?
Master Machine:
! Configuration File for keepalived
vrrp_instance VI_1 {
state BACKUP
nopreempt
interface eth0
virtual_router_id 1
priority 250
advert_int 1
virtual_ipaddress {
192.168.1.2/24
}
}
Backup Machine :
! Configuration File for keepalived
vrrp_instance VI_1 {
state BACKUP
nopreempt
interface eth0
virtual_router_id 1
priority 200
advert_int 1
virtual_ipaddress {
192.168.1.2/24
}
}
С уважением, Бен
Изменены оба состояния сервера как BACKUP. Первичный с более высоким приоритетом и без приоритета, оба имеют одинаковый идентификатор маршрутизатора. У меня это работает.
Прежде всего: я использую CentOS 6 и keepalived 1.2.7 (21.02.2013)
Я также попробовал nopreempt, и после некоторого тестирования он работает должным образом.
Запуск главного сервера и резервного копирования с одинаковым приоритетом vrrp - плохая идея, потому что есть ошибка (AFAICT), которая приводит к ситуации, когда оба сервера keepalived запускают VIP. в соответствии с http://tools.ietf.org/html/rfc5798#page-26 Keepalived с наивысшим IP-адресом должен остаться / стать главным. Я не мог наблюдать такое поведение!
(Снова AFAICT). Вы должны удалить оператор "state" из файла конфигурации, если хотите, чтобы nopreempt работал. Если keepalived с "state MASTER" в конфигурационном файле запускается, он запускается как master и объявляет себя таковым = bad. Если в конфигурационном файле нет оператора «state», keepalived запускается в состоянии BACKUP и слушает vrrp. из-за «nopreempt» он не станет ГЛАВНЫМ, даже если он работает с наивысшим приоритетом. это противоречит странице man 5 keepalived.conf, где состояние не имеет большого значения.
Keepalived с prio 255 всегда становится главным - независимо от того, включена или выключена опция nopreempt.
Если вы тестируете keepalived, внимательно изучите правила firewall / nat. Всегда рекомендуется запускать что-то вроде tcpdump, чтобы проверить, проходят ли объявления vrrp и имеют ли они правильный IP-адрес отправителя (один от другого keepalived (ов), а не стандартный gw!) Это особенно верно, если вы используете kvm / qemu гостей, так как есть правила nat по умолчанию, которые изменяют рекламу vrrp.
nopreempt работает только для поддержки активности в состоянии BACKUP. (RTFM), если keepalived (1.2.7) запущен и сетевой канал не работает, keepalived меняет состояние на FAULT. когда сетевое соединение возвращается, keepalived становится ГЛАВНЫМ, если prio достаточно высокое. Я не знаю, является ли это ошибкой, но это делает nopreempt как-то бесполезным. Я отправлю вопрос в список рассылки.
Радоваться, веселиться! С уважением
Стефан Карст
Это может быть или не быть правильным решением для вас, но у меня только два сервера поддержки активности.
Если вы не хотите, чтобы один сервер опережал другой, один сервер с более высоким приоритетом, чем другой, на самом деле не имеет значения в сценарии с двумя серверами, подобном моему. У меня работает, если я включу nopreempt
и установите для обоих серверов одинаковый приоритет.
ОБНОВИТЬ
Пример конфигурации по запросу:
vrrp_sync_group VRRP_SYNCS {
group {
public_http_ips
}
}
vrrp_instance public_http_ips {
state MASTER
interface eth0
virtual_router_id 18
priority 100
advert_int 1
nopreempt
virtual_ipaddress {
192.168.0.254/24 dev eth0
}
}
Резервная копия точно такая же, но в ней написано «состояние РЕЗЕРВНОЕ КОПИРОВАНИЕ».
Я перепробовал множество конфигураций для достижения этой цели, и единственная, которая работает, - это установка обоих серверов на состояние РЕЗЕРВНОЕ КОПИРОВАНИЕ, один сервер с приоритет 51, другой с 50 и установка nopreempt. Вот пример конфигурации:
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 51
nopreempt
advert_int 1
authentication {
auth_type PASS
auth_pass XXXXXXXX
}
virtual_ipaddress {
192.168.69.100/28
}
}
Просто установите приоритет 50 на втором сервере, и все должно работать.
В скрипте vrrp необходимо установить параметры «падение» и «подъем». Пример рабочей конфигурации:
vrrp_script chk_haproxy {
script "killall -0 haproxy"
interval 1
fall 2
rise 2
}
vrrp_instance VI_1 {
interface eth0
track_interface {
eth0
eth1
}
state BACKUP # same as other node
priority 101 # your choice
virtual_router_id 53
advert_int 1
nopreempt
authentication {
auth_type PASS
auth_pass 8CHARPASS
}
unicast_src_ip 172.31.10.11 # other node: 172.31.10.12
unicast_peer {
172.31.10.12 # other node: 172.31.10.11
}
virtual_ipaddress {
172.31.20.20 dev eth1
}
track_script {
chk_haproxy
}
}